Appearance
Q65 · 各类 Agent 开发框架应该如何选取？
面试官问“LangChain、LangGraph、OpenAI Agents SDK、Google ADK、CrewAI、AutoGen 这么多，你会选哪一个”，如果立刻背一张“谁最强”的排行榜，往往答不到工程问题。**先问业务要 Agent 做到哪里、哪些步骤必须由程序控制、失败后怎样恢复，再用一个小而真实的场景验证候选方案。**不同框架的能力会更新，品牌名也不能代替权限、日志、成本和测试设计。
用同一家公司客服系统想象三个任务：
- 任务 A：用户问“订单 A123 到哪了？”模型选择订单查询工具，拿到结果后给用户解释。
- 任务 B：用户要求退款。要查询订单和现行政策；证据缺失时补查，额度过高时等人工批准，服务重启后继续，最后才调用退款接口。
- 任务 C：一份复杂故障报告需要售后、硬件质检、物流三个专业角色各自调查，再由一个负责人核对证据并给出结论。
任务 A 通常先用一个高层 Agent；任务 B 需要清楚的分支、状态和审批关口；任务 C 可能从多 Agent 协作受益，但也可能用“一个 Agent + 三个专门工具”更简单。只有真的比较任务质量、运行代价和维护成本，才能确定“多”有没有价值。LangChain 官方概览、LangGraph 官方概览、OpenAI Agents SDK 官方概览
术语解释：先分清你在选择哪一层
| 词 | 对小白的解释 | 选型时要问什么 |
|---|---|---|
| Agent | 把模型放进能看任务、选工具、看结果并继续行动的运行过程 | 是单次回答，还是要多轮决策？ |
| 工具调用循环 | 模型提出工具调用，应用执行，结果回给模型，再继续 | 是否只是常规“查一查再回答”？ |
| 框架 | 帮你写 Agent 的代码抽象和现成组件 | 它帮你管理哪些重复代码？ |
| Runtime（运行时） | 真正执行状态、步骤、暂停、恢复和重试的部分 | 长任务与故障恢复靠什么？ |
| 高层抽象 | 把常见 Agent 循环封装好，少写编排代码 | 现成流程够不够用？ |
| 图编排 | 用状态、节点和连接显式规定可能的路径 | 是否要逐步控制分支与审批？ |
| 多 Agent | 不同职责的 Agent 分工处理一个大任务 | 分工的收益是否大于通信与协调成本？ |
| Handoff（交接） | 一个 Agent 把任务和必要上下文转给另一个 | 谁对最终答复负责？ |
| Guardrail（校验关口） | 检查输入、输出或工具动作是否满足规则 | 它执行在什么时机，能否阻止写操作？ |
| 可观测性 | 看到每一步模型、工具、状态、耗时和错误 | 出错时能否定位是哪一步？ |
| POC | Proof of Concept，小规模验证原型 | 用真实难例验证，而非只跑一个演示 |
| 平台 | 通常还包含可视化配置、托管、发布、权限和运营界面 | 团队需要自己写代码还是快速搭应用？ |
这里的 A123 是虚构订单编号，不代表真实用户。文章提到的“高层”和“底层”是需要自己掌控多少流程细节，不是质量排名；底层框架给更多控制，也要自己承担更多设计工作。另有一个容易混淆的东西：MCP 是连接工具与资源的协议，不能替你选 Agent 的业务流程；一个框架能接 MCP，并不说明它自带退款审批规则。
从业务路径出发，而不是从框架名字出发
图中三座岛屿表示三种常见抽象层级，不是要求系统从左到右全部经历。左边的机器人与扳手构成常规“模型选工具→工具返回→模型继续”的循环；中间把业务条件与人工关口画在节点之间；右边让两个角色协作。工程师手里的“需求”卡片提醒：先说清任务，再选择岛屿。三个岛并不互斥，一个图流程里也可以放一个高层 Agent 节点；但每增加一层协调，就要说明它解决了哪项真实需求。
先把任务 A 写成验收行为：用户提供订单号；系统确认用户有权看该订单；查询工具返回最新状态；回答“已发货”时附上查询时间。若订单服务失败，就说暂时无法核实。这里最难的是工具参数、权限与错误处理，未必需要自行设计几十个节点。一个现成 Agent 循环，加上后端业务校验和观测，往往是合理起点。
任务 B 则写成另一套行为：金额超过阈值进入人工审批；在审批结果返回之前，退款工具绝不可调用；审批跨天时保存状态；继续执行前重新读取订单现状；重复请求要用幂等键挡住重复退款。这些行为必须能测试到具体步骤。若高层框架已有可满足的暂停、审批和持久化能力，直接配置即可；若业务流程明显超出封装范围，才选择显式图编排。框架提供暂停机制，不等于替你实现资金安全。退款接口仍要做权限、状态核验和业务幂等。LangGraph 官方概览、LangGraph 持久化
任务 C 则先证明多角色的必要性。如果“质检 Agent”只是在调用质检知识库，“物流 Agent”只是在调用物流 API，把它们做成两个工具可能更简单。若两个角色有各自独立的任务过程、需要分别查证与产出、可能异步等待外部信息、还要由负责人综合冲突，才有较充分的多 Agent 理由。多角色会带来上下文传递、结论冲突、循环交接、成本与责任归属问题；给每个角色固定输入、交付物、最多往返次数和超时回退，才能避免“看上去很热闹，最后没人负责”。OpenAI Agents SDK：Agent orchestration、CrewAI 官方介绍
几类常见框架各适合验证什么
下面是截至 2026 年 9 月查阅各家官方文档后的定位，用于确定要试哪些候选，不是永久的功能排行榜。不同版本、语言和部署方式会改变实际可用能力，落地前应以所用版本文档与 POC 为准。
| 方案 | 官方资料里可确认的定位 | 优先放入候选的情况 | 选型时特别核对 |
|---|---|---|---|
LangChain create_agent | 高层、可配置的模型与工具循环，支持通过中间件扩展；当前 Agent 建立在 LangGraph 上 | 常规工具型 Agent、已有 LangChain 组件 | 现有中间件是否足以表达业务关口；不要沿用旧 AgentExecutor 教程 |
| LangGraph | 低层图运行时，强调状态、持久执行、人工介入，能混合确定性与模型步骤 | 分支、长任务、人工审批和恢复需要细控 | 自己要维护状态结构、边、节点与副作用边界 |
| OpenAI Agents SDK | 以 Agent、Runner、工具、交接、校验和追踪组织代码中的运行过程 | 想较快构建有工具或角色交接的代码 Agent | 使用的模型和部署环境、guardrail 执行位置、状态保存方式 |
| Google ADK | 官方提供 Agent、工具、会话、流程与多 Agent 组件，也有多语言实现 | 团队已采用相应生态，想用其 Agent 运行模型 | 所需语言与版本的具体功能、运行与部署边界 |
| CrewAI | 官方把协作的 Crews 与管理状态、执行的 Flows 组合 | 分工明显、以角色协作和流程协调为主要建模方式 | Crew 的任务边界、Flow 状态和外部写入如何测试 |
| Microsoft AutoGen | 官方文档将 AgentChat 作为对话式单/多 Agent 开发层，Core 作为事件驱动的底层 | 需要试验对话式多 Agent 或事件驱动编排 | 选 AgentChat 还是 Core，以及目标版本的部署和观测能力 |
这张表故意不写“某框架最快”“某框架最安全”这样的结论，因为官方支持某种组件不代表你的业务就能安全上线。例如 OpenAI Agents SDK 官方对 guardrail 的说明区分输入、输出与工具关口，且它们不是在所有交接位置都执行；具体保护资金动作仍应放在服务端的权限和审批检查上。OpenAI Agents SDK 概览、Guardrails。Google ADK 官方列出顺序、循环、并行及多 Agent 工作流；CrewAI 官方介绍将 Flow 与 Crew 分层；AutoGen 官方文档区分 AgentChat 与 Core。Google ADK 技术概览、CrewAI 官方介绍、AutoGen 官方文档
还要看组织现实：项目主要用 Python、Java 还是 TypeScript？运维是否能托管长任务状态？模型能否更换？现有订单工具已经是什么协议？团队是否有人能调试状态与异步错误？如果只因展示页漂亮就选框架，半年后可能发现业务审批无法表达；如果只因功能清单最长就选底层运行时，简单问答也可能被过度工程化。
把选型变成一次可以复现的 POC
可用任务 A 与 B 各做一组小型对照实验。候选方案至少使用同一模型、同一提示词版本、同一工具数据快照与同一评测样本，否则结果混进了模型和数据差异，没法判断框架影响。测试样本不必一开始上万条，但必须覆盖真正会出错的情况：正确订单、别人的订单、政策过期、订单服务超时、审核拒绝、审批后状态变化、退款调用超时与重复请求。
先定“过线要求”，再看开发体验：
- 正确与安全：无权限订单不能查，没依据不能肯定退款，审批前写操作次数必须为零，重复请求不能双重退款。
- 运行可靠性：外部服务断一下能否有界重试或停在清楚状态；跨进程重启后是否能正确恢复待审批任务。
- 可观测性：能否从某次失败找到模型决定、工具参数、状态变更、审批记录和最终动作。
- 性能与成本：记录端到端时间、尾部延迟、模型调用次数、输入输出 token、工具次数、持久化存储和人工处理成本。
- 维护成本：新增一个审批条件需要改多少代码或配置，测试能否独立运行，依赖升级和旧状态迁移是否可控。
以下数字只是说明评估口径的虚构小样本，不是任何框架真实性能：若方案甲在 40 个案例里答对 37 个、其中一个越权泄露；方案乙答对 35 个、无越权；即使甲的“答对率”更高，它也没通过安全门槛。若方案丙能完成全部 40 个，但每次产生三倍模型调用、人工队列无法承受，也不一定适合当前业务。应把“必须为零的错误”与“可权衡的质量、成本”分开看。重复运行同一批案例，并记录失败轨迹，比只展示一次演示成功更有说服力。
迁移成本也要纳入 POC。例如原系统已有 LangChain 工具包装、对话历史和日志。如果改用另一套 SDK，工具接口、消息对象、状态持久化、追踪字段、测试夹具和运维告警都可能要重新适配。对长任务还要处理在途状态：旧版本留下的待审批单，新版本能否继续？若不能，是否让旧版本处理完？框架选型是一笔总工程账，不是只看第一天写几行代码。
一个实用的决策顺序
**先排除根本不需要 Agent 的场景。**固定的“读取表单→查订单→按明确规则判断→返回模板”用普通程序或工作流更可靠。如果确实需要模型理解开放问题、选择工具，再优先试一个高层 Agent；遇到明确的分支、长期状态与审批需求，再试图运行时；多角色只有在单 Agent 加工具无法有效完成、且协作收益经 POC 证明后才加。这个顺序是降低工程复杂度的起点，并非某家的强制架构路线。
选定后还要明确谁负责最后的事实判断与外部动作。框架管理“步骤怎样运行”，业务服务负责“这个用户是否有权查订单、这笔退款是否获批、是否已经执行”。模型输出是一种输入，不是权限证明。把这条边界写入设计和测试，才能让“选到了合适框架”真正落地。
面试时可以这样回答
我不会先按热门程度给框架排第一名，而会先描述任务的控制要求。如果只是模型选工具、看结果、回答，我先试高层 Agent，例如 LangChain
create_agent或合适的 Agents SDK；如果要明确状态、条件分支、人工审批、长任务恢复，我会评估 LangGraph 这类图编排；只有专业分工带来可量化收益时才增加多 Agent。候选方案要用相同模型、工具数据和失败样本做 POC，比较正确性、越权和副作用、恢复、追踪、延迟成本及维护负担。最终选的是满足业务门槛、团队能维护的最简单方案。框架不替代业务权限和幂等，版本能力还要查官方文档并实测。
若追问“LangChain 和 LangGraph 要二选一吗”，回答：不是。当前 LangChain Agent 基于 LangGraph，定制图也可以使用 LangChain 的模型与工具组件；选的是高层现成编排还是更细的流程控制。LangChain 官方概览。若追问“多 Agent 是否必然更准确”，回答：不必然；它增加协调与上下文损耗，必须与单 Agent 加工具的基线比较。