有没有用到类似AutoGen或LangChain的框架?为什么选这个框架
1️⃣ 考察意图
面试官想看你是否真正用过 Agent 框架，而非只背过概念。这道题考察“工程选型能力”——不是让你二选一，而是看你能否根据项目场景（多 Agent 协作 vs 工具链集成）、团队规模、迭代速度做出合理取舍。刁钻点在于：很多人只会说“LangChain 灵活，AutoGen 开箱即用”，但答不出具体 trade-off（如 LangChain 的 callback 地狱、AutoGen 的群聊死锁）。答好了能展示你对 Agent 系统落地问题的理解，以及从 demo 到生产环境的工程判断力。
2️⃣ 标准答
我的选型逻辑：先看场景，再定框架，不迷信“全家桶”。
场景 1：多 Agent 协作（如客服转接、多角色辩论）→ AutoGen
- 为什么选：AutoGen 内置了
ConversableAgent和GroupChatManager，天然支持角色定义（如UserProxyAgent模拟用户、AssistantAgent调用工具）。在构建一个“客户-客服-质检员”三 Agent 协作系统时，我直接用GroupChat的speaker_selection_method="round_robin"控制发言顺序，省去自己写状态机。 - 实际坑 + 解法：AutoGen 的群聊容易死锁——当两个 Agent 都等待对方回复时，
GroupChatManager会超时。我通过设置max_turns=10和termination_msg条件（如检测到“结束”关键词）强制终止，并加了human_input_mode="NEVER"避免阻塞。 - Trade-off：AutoGen 的灵活性低——自定义工具必须用
register_function装饰器，且不支持 LangChain 的Tool抽象。如果工具链复杂（如调用 10+ 个 API），代码会膨胀。
场景 2：工具链集成（如 RAG + 搜索 + 数据库）→ LangChain
- 为什么选：LangChain 的
AgentExecutor+Tool抽象让我能快速组合WebSearchTool、RetrievalQA、SQLDatabaseTool。在构建一个“智能客服知识库”时，我用create_react_agent（ReAct 模式）配合ChatOpenAI，3 天就完成了原型。 - 实际坑 + 解法：LangChain 的 callback 机制（如
CallbackHandler）在异步调用时容易丢失上下文。我改用langfuse做 tracing，并手动在AgentFinish回调中记录 token 消耗，避免生产环境 debug 困难。 - Trade-off：LangChain 学习曲线陡——
LCEL语法（|链式调用）在复杂逻辑下可读性差，且版本升级频繁（如 v0.1 到 v0.2 的Runnable重构）。如果团队新手多，我会优先用 AutoGen。
场景 3：混合方案（生产环境）→ 自研轻量框架
- 为什么：两个框架都有“黑盒”问题——AutoGen 的
GroupChat内部用asyncio调度，难以 debug；LangChain 的AgentExecutor在max_iterations耗尽时抛出AgentExecutionError，且不支持自定义重试策略。我最终用pydantic+asyncio自建了一个 200 行的 Agent 调度器，核心逻辑： - 用
BaseModel定义AgentState（含tools、memory、max_steps） - 用
while循环 +asyncio.gather并行调用工具 - 用
tenacity库实现指数退避重试 - 效果：代码量减少 40%，可测试性提升（单元测试覆盖 90%），且无框架版本依赖风险。
总结：Demo 用 LangChain（快），多 Agent 用 AutoGen（省事），生产环境自研（可控）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，场景决定框架——多 Agent 协作选 AutoGen（内置群聊管理），工具链集成选 LangChain（模块化 Tool 抽象）；第二，实际落地有坑——AutoGen 的群聊死锁需设
max_turns，LangChain 的 callback 丢失需用 tracing 工具；第三，生产环境我倾向自研轻量框架，用pydantic+asyncio控制状态机，避免黑盒问题。总结一句：没有银弹，选型取决于团队对灵活性和开箱即用度的权衡。”
4️⃣ 高频追问 & 应对
追问 1：你提到 LangChain 的 callback 丢失，具体怎么发生的？怎么定位的？
在异步调用
AgentExecutor时，如果CallbackHandler未实现on_chain_end方法，AgentFinish的 token 统计会漏掉。我用langfuse的LangchainCallbackHandler替换自定义 handler，并在on_llm_end中手动累加token_usage。定位时，通过langfuse的 trace 视图对比输入输出 token 数，发现差值超过 10% 就报警。
追问 2：如果团队只有 3 个人，你会选哪个框架？为什么？
选 LangChain。因为 3 人团队需要快速验证业务逻辑，LangChain 的社区生态（如
langchain-community的 500+ 集成）能减少重复造轮子。但我会强制用langchain_core的抽象层（BaseTool、Runnable），避免直接依赖langchain的版本耦合。同时，用pytest+vcrpy录制 API 调用，确保测试不依赖外部服务。
追问 3：你自研的框架怎么处理 Agent 的长期记忆？
用
langgraph的MemorySaver思路：在AgentState中维护一个messages列表（List[BaseMessage]），每次迭代后追加。但为了控制上下文窗口，我加了summarizer步骤——当messages长度超过 50 条时，用ChatOpenAI生成摘要并替换前 40 条。Trade-off：摘要会丢失细节，所以对关键信息（如用户 ID、订单号）用Redis持久化，不走摘要。
5️⃣ 避坑 · 常见错误答法
- ❌ “我用了 LangChain，因为它最流行。” → ✅ “我选 LangChain 是因为项目需要集成 5 个外部 API（搜索、数据库、邮件），它的
Tool抽象和AgentExecutor能让我 3 天出原型，但生产环境我换了自研框架以避免版本升级风险。” - ❌ “AutoGen 比 LangChain 好，因为它更简单。” → ✅ “AutoGen 适合多 Agent 场景，但它的
GroupChat在复杂对话中容易死锁，我通过设max_turns和termination_msg解决。如果工具链简单，AutoGen 更快；如果工具多，LangChain 更灵活。” - ❌ “我两个都用过，但说不出区别。” → ✅ “我对比过：用 AutoGen 实现客服转接系统（3 Agent 协作）比 LangChain 少写 50% 代码，但自定义工具时需用
register_function，不如 LangChain 的Tool装饰器直观。最终根据场景选型。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“工具链集成”切入——用 LangChain 的
RetrievalQA+WebSearchTool构建混合检索 Agent，并对比 AutoGen 的AssistantAgent在调用多个检索工具时的代码复杂度。 - 如果你只做过传统 NLP：用“状态机类比”——传统 NLP 的 pipeline（分词→NER→分类）对应 LangChain 的
Chain，多 Agent 协作对应 AutoGen 的GroupChat，强调从串行到并行的工程迁移。 - 如果你是校招无项目：聚焦“论文复现”——用 AutoGen 复现 ReAct 论文中的“搜索+推理” Agent，用 LangChain 复现 Reflexion 论文的“自我反思”机制，展示对框架底层原理的理解。
- AutoGen 论文：Wu et al., "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation", 2023
- LangChain 官方文档：Agent 模块（
AgentExecutor、Tool、CallbackHandler） - 自研框架参考：LangGraph 的
StateGraph和MemorySaver设计模式 - 生产环境坑点：LangChain 的
Runnable重构指南（v0.1→v0.2 迁移） - 多 Agent 协作最佳实践：Microsoft 的 "AutoGen: A Framework for Multi-Agent Conversations" 博客