面试题 · Agent
搜索「RAG 架构」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请介绍几种主流的大模型Agent实现框架，并简要说明它们的特点和适用场景。
学习内容与项目面试，在同一条路上。
| 场景 | 推荐框架 |
|---|---|
| 快速验证/POC | LangChain + LangSmith |
| 复杂多步骤任务 | LangGraph 或 自研状态机 |
| 软件生成类任务 | MetaGPT |
| 生产级低代码平台 | Dify |
| 极致性能/可控性 | 原生Function Calling + 自研编排 |
实际落地建议：从简单开始，先用原生API验证可行性，复杂场景再引入框架，避免过度工程化。
场景切入
假设我们做一个客服智能助手，需要让大模型自己决定调用查订单、查物流等工具。除了直接用OpenAI function calling，市面上还有哪些框架能帮我们快速搭起来？你实际落地时会选哪个？
层层追问
你了解哪些大模型Agent框架？……它们各自的核心设计思路是什么？……假如要做一个多角色协作的软件生成任务，你觉得哪个框架更合适？
直球架构
请直接对比LangChain、AutoGPT和MetaGPT这三个主流Agent框架，说说它们各自的特点、适用场景和主要局限。
面试官问[[Agent]]框架，我觉得本质上是在考察选型能力，就是面对一个具体业务场景，你能不能判断出用什么框架落地最稳。市面上框架很多，但真正生产里我不会只用一个，往往是混着来。我重点说三个方向。
先说 LangChain，它最出名，特点是模块化、链式调用，后来加了LangGraph支持状态图。适合快速搭原型或者做[[RAG]]加Agent的混合系统。但我实际用下来有个坑：抽象层太厚，调试起来非常痛苦。比如一个多步推理流程，中间某步[[Function Calling]]返回异常，你得一层层剥开才知道是哪里的prompt写崩了。所以我的建议是，POC阶段可以用，但一旦进入生产，要么换更轻量的方案，要么你团队有足够精力去啃它的源码。说白了，LangChain适合'先跑通再说'的场景，但别指望它开箱即稳。
再一个是 MetaGPT，它模拟软件公司，有PM、架构师、工程师这些角色，多个Agent协作按照SOP走。这个框架特别适合做复杂软件生成，比如你给一个需求，它自动产出设计文档、代码、测试用例。但适用边界很窄，只适合结构化任务，而且前提是你的业务能拆成标准流程，否则Agent之间消息一多，协调成本就上去了。举个例子，一个电商后台的满减政策生成，规则是确定的，可以用MetaGPT让一个Agent写规则，另一个Agent验证边界情况，效果很好。但如果需求本身模糊，比如'做个好用的用户中心'，那它就容易陷入无休止的讨论。
最后是原生方案，就是直接调用模型的Function Calling能力，或者用OpenAI Assistants API。这个适合生产环境，尤其是你已经有工程体系的时候。它的核心优势是可控，没有框架的黑盒，每一步你都能精确干预。但缺点是你要自己处理状态管理、重试、记忆这些事。我倾向在关键链路上用原生API，在非关键环节比如日志分析、简单查询上，可以用LangChain快速搭。
说到多Agent协作，其实有个容易被忽略的问题：Agent之间的消息格式和上下文一致性。比如MetaGPT里，PM输出需求文档，架构师读的时候可能理解偏差，这种协调成本怎么量化？我觉得比单Agent难一个量级，这也是我目前更关注的方向。
所以回到选型，我会把框架看成工具，不是信仰。简单场景原生最稳，复杂场景先看能不能拆成标准SOP，能就用MetaGPT，不能就自研状态机加LangGraph做编排。上线前我一定关注两个点：一是Token消耗，二是异常恢复。很多Agent框架跑着跑着就死循环了，没有熔断机制的话，线上会出大问题。