这篇学完你能回答什么
- LangGraph / OpenAI Agents SDK / Google ADK / CrewAI 这些框架怎么选？
- 为什么不少团队做到最后，反而自己写了个循环？
- 框架、运行时、harness 是三个不同的层，分别买错会付什么代价？
从一个真实故障讲起
一个合同审查 Agent。选型时团队的标准很朴素：哪个上手快选哪个。两周做出了能演示的版本，角色分工清晰（提取 Agent、比对 Agent、风险标注 Agent），演示效果很好，项目通过评审。
进入生产准备阶段，法务和合规提了三个需求：
- 高风险条款的判定要人工确认后才能进报告；
- 单份合同处理动辄 20 分钟，服务重启要能从断点续跑，不能从头再来；
- 每一条风险结论要能追溯到原文位置和判定依据，供审计。
这三条在传统业务系统里属于基本要求。但在当时选的框架上，每一条都撞墙：
- 框架把 Agent 之间的协作封装成了一个"跑起来就跑到底"的高层调用，中途插入人工确认没有官方支持，团队只能在工具函数里
input()式阻塞，等于把一个分布式问题塞进了单机假设里； - 没有可持久化的执行状态，进程重启就是从头开始。团队试着自己序列化中间状态，发现框架把关键状态藏在内部对象里，序列化不出来；
- 日志里能看到每个 Agent 说了什么，但看不到完整的调用树，"这条结论从哪来的"追不到。
最后的结果是：三个月重写，换成显式状态机 + 自己控制持久化。两周省下来的时间，用三个月还了回去。
复盘时最有价值的一句话是团队负责人说的：
"我们当时以为在选一个'能不能做出来'的工具，其实是在选'做出来之后能不能改'。"
只问哪个上手快
两周做出能演示的版本，评审通过
法务提三个需求
人工确认、断点续跑、结论可追溯
三条条条撞墙断点
框架把协作封装成「跑起来就跑到底」
三个月重写
换显式状态机 + 自己控制持久化
input()核心概念：先打比方，再给定义
比喻：选框架像装修选套餐。
全包套餐（高层抽象框架）省心，两周入住，但你想把承重墙上的一个插座挪个位置——对不起，方案是打包好的。清包（自己写循环）什么都得自己盯，但每一根线在哪你都清楚。大多数团队的错误不是选了套餐，而是在选套餐时没问"半年后我要改什么"。
三层区分（这是 2026 年讨论框架选型时最有价值的一个切分，面试里很少有人说得清）：
| 层 | 回答什么问题 | 提供什么 |
|---|---|---|
| 框架（Framework） | 怎么构建一个 Agent？ | 循环、工具抽象、记忆接口、多 Agent 编排原语 |
| 运行时（Runtime） | 怎么让它持久地跑？ | 状态持久化、重试、流式、断点续跑、长周期工作流 |
| Harness（治理外壳） | 怎么在生产里安全可重复地跑？ | 身份与作用域、权限、审计、回滚、隔离（详见 T3-10） |
开篇故障的本质是：团队买了框架层，却以为顺带买到了运行时层和 harness 层。 这三层的能力边界不重合，混淆它们是选型翻车最常见的原因。
省心，两周就能入住
想把承重墙上的插座挪个位置 —— 方案是打包好的
循环、工具抽象、记忆接口、编排原语
错的不是选了套餐，是选的时候没问「半年后我要改什么」
每一根线在哪你都清楚
什么都得自己盯，起步慢得多
上下文控制权留在自己手里
T3-3 那 40 行是完整的，加上退出条件与重复检测也不到 150 行
原理拆解
| 你要做的事 | 抽象泄漏点 |
|---|---|
| 改一句 system prompt | 框架有自己的模板，你的内容被包了一层，看不到最终发出去的 prompt |
| 在第 N 步插入人工确认 | 高层 API 是「一次跑完」，没有中断 / 恢复语义 |
| 控制上下文里放什么 | memory 组件自作主张地拼接历史 |
| 按自己的规则做压缩 | 压缩逻辑内置且不可替换 |
| 定制重试与降级 | 异常被框架吞掉，你拿不到原始错误 |
| 换模型供应商 | 抽象只覆盖公共子集，缓存、推理档位、并行工具这些特有能力用不上 |
最快的判别法：问它能不能把「实际发出去的完整 prompt」打印出来。打不出来，说明你对上下文没有控制权 —— 而上下文正是 Agent 产品的核心资产。
自己写循环不是反框架情绪，是五条具体理由：核心循环本来就短；出问题时读自己的 150 行比猜抽象内部便宜；prompt 与压缩策略要反复打磨；大版本变更或转入维护模式会打断你；缓存前缀、模型分级路由这些优化常要绕过框架默认行为。
框架到底替你做了什么
把 T3-3 里那个 40 行的循环拆开看，框架能替你接管的其实是这五块：
① 循环骨架 ← 最不值钱，你自己写只要几十行 ② 工具抽象与调用分发 ← 有点价值，主要是省样板代码 ③ 状态持久化 / 检查点 ← 真正值钱，自己实现很累 ④ 多 Agent 编排原语 ← 值钱，但只在你确实需要多 Agent 时（T3-8） ⑤ 可观测 / trace 接入 ← 真正值钱，尤其是跨 Agent 串联
很多人选框架是冲着 ① 和 ④ 去的，但真正难自己造的是 ③ 和 ⑤。 这个认知错位，是"为什么最后自己写循环"这个现象的根源——团队发现自己付出的抽象代价买回来的主要是最不值钱的那部分。
抽象泄漏发生在哪
框架的抽象层在下面这些地方最容易漏：
你要做的事 抽象泄漏点
─────────────────────────────────────────────────────────
改一句 system prompt → 框架有自己的模板，你的内容被包了一层，
而你根本看不到最终发出去的 prompt 长什么样
在第 N 步插入人工确认 → 高层 API 是"一次跑完"，没有中断/恢复语义
控制上下文里放什么 → 框架的 memory 组件自作主张地拼接历史
按自己的规则做压缩 → 压缩逻辑内置且不可替换
定制重试与降级 → 异常被框架吞掉，你拿不到原始错误
换模型供应商 → 抽象只覆盖了公共子集，特有能力（缓存、
推理档位、并行工具）用不上判断一个框架适不适合你的最快方法：问它能不能把"实际发出去的完整 prompt"打印出来。 打不出来的，说明你对上下文没有控制权——而上下文正是 Agent 产品的核心资产。
为什么不少团队最后自己写循环
这不是反框架情绪，是有具体原因的工程选择：
- 核心循环本来就很短。T3-3 那 40 行是完整的，加上退出条件、重复检测也不到 150 行。
- 调试成本反转。出问题时，读自己的 150 行 vs 读框架的调用栈 + 猜抽象内部发生了什么——后者往往更贵。
- 上下文控制权是产品核心。prompt、工具描述、压缩策略都是要反复打磨的东西（T3-2、T3-6），中间隔一层模板会让迭代变慢。
- 升级风险。框架大版本变更、被转入维护模式、API 重构，都会打断你。
- 性能与成本的最后一公里：缓存前缀设计、工具返回裁剪、模型分级路由（T3-12），这些优化经常要绕过框架的默认行为。
但"自己写循环"不等于"什么都自己造"。 成熟团队的实际形态是：
自己写：循环 + 上下文组装 + 工具分发 + 退出条件 ← 掌握控制权
借生态：可观测/trace（OTel 生态）、持久化（工作流引擎或数据库）、
评测框架、MCP SDK（协议实现别自己撸） ← 不重复造轮子面试里能给出这个分界，比站队"用框架"或"不用框架"高一个层级。
工程实践（截至 2026-08）
主流选择的定位速览
生态变化很快，下表是定位归纳而非排名，具体版本能力请以官方文档为准。
| 框架 | 核心特征 | 适合 | 主要代价 |
|---|---|---|---|
| LangGraph | 显式图 + 状态机；可持久化执行、检查点、人工中断是一等公民；生态与可观测工具链完整 | 生产级有状态工作流、需要审批与断点续跑、合规场景 | 学习曲线陡；概念多；简单场景显重 |
| OpenAI Agents SDK | 轻量原语：agents / handoffs / guardrails / sessions，内置 tracing | 围绕单一模型生态的中小型 Agent，追求最短上线路径 | 抽象薄也意味着复杂编排要自己补；生态绑定 |
| Claude Agent SDK | 面向编码/计算机操作类任务，工具执行能力强 | 编码 Agent、需要强工具执行的场景 | 模型生态绑定 |
| Google ADK | 层级式 agent 树（父派子、子返父）；多语言；GCP/多模态深度集成 | GCP 技术栈、多模态 Agent | 相对年轻，社区与文档积累较薄 |
| Microsoft Agent Framework | 面向 .NET/Azure 生态，承接 AutoGen 与 Semantic Kernel 的路线 | 微软技术栈企业 | 强生态绑定 |
| CrewAI | 角色化多 Agent DSL，几十行起步 | 快速原型、角色分工天然清晰的任务 | 编排控制力有限，团队常会长出去 |
| AutoGen | 已进入维护模式（仅安全修复） | 存量系统 | 新项目不要选；迁移优先考虑显式图类框架 |
另有 Pydantic AI（类型优先）、Mastra（TypeScript 生态）、LlamaIndex Workflows（RAG 重的系统）、Strands / Agno / smolagents 等，各有取舍。
选型判据（比看功能表有用）
按顺序问自己这六个问题，答案基本就定了：
- 需要人工审批 / 断点续跑 / 审计吗？ 需要 → 选把持久化执行与中断做成一等公民的框架，或自己写 + 接工作流引擎。这是开篇故障的直接教训。
- 是不是真的需要多 Agent？ 先看 T3-8 的三问。不需要就别为编排原语买单。
- 会不会换模型供应商？ 会 → 避开强绑定单一生态的 SDK。
- 团队语言栈是什么？ Python 之外的选择面明显更窄。
- 上下文控制权重要吗？（几乎总是重要）→ 要求框架能导出最终 prompt。
- 谁来维护？ 一个人维护的项目，选生态大、文档全的；有平台团队的，可以自己写循环换取控制权。
进阶技术三段式：使用高层 Agent 框架
- 解决什么：省掉循环、工具分发、状态管理、多 Agent 编排的样板代码；直接获得成熟的持久化、trace、人工中断等生产能力；团队协作有共同语汇。
- 代价是什么：① 抽象泄漏——最需要精细控制的地方（prompt、上下文、压缩、重试）恰恰最容易被挡住；② 调试链路变长；③ 版本升级与生态绑定风险；④ 性能与成本优化的天花板被框架默认行为限制；⑤ 认知代价：框架的默认多 Agent 原语会诱导你过早拆分（T3-8）。
- 什么时候不该用：单一简单循环 + 少量工具的场景（自己写更清楚）；对上下文有极致控制需求的产品（面试引擎、编码 Agent 这类，prompt 就是核心资产）；团队已有成熟的工作流/编排基础设施，只缺一个模型调用循环时。
避坑清单
- 别用"上手快"当唯一标准。上手快的框架通常抽象最高，也最早撞墙。
- PoC 阶段就把三个生产需求验一遍：能不能中断续跑、能不能导出完整 prompt、trace 能不能跨 Agent 串联。这三条各花半天验证，能省下三个月。
- 别为"未来可能要多 Agent"提前选重框架。等真需要时再迁移，通常比一开始就背着抽象跑更划算。
- 框架不是 harness。审计、权限、回滚、隔离这些治理能力，绝大多数框架不提供，要单独规划（T3-10）。
- AutoGen 存量系统要有迁移计划（截至 2026-08 已是维护模式），别在上面加新功能。
| 框架 | 核心特征与适合 | 主要代价 |
|---|---|---|
| LangGraph | 显式图 + 状态机；可持久化执行、检查点、人工中断是一等公民；适合生产级有状态工作流、审批与断点续跑、合规场景 | 学习曲线陡；概念多；简单场景显重 |
| OpenAI Agents SDK | 轻量原语 agents / handoffs / guardrails / sessions，内置 tracing；适合围绕单一模型生态、追求最短上线路径 | 抽象薄，复杂编排要自己补；生态绑定 |
| Claude Agent SDK | 面向编码 / 计算机操作类任务，工具执行能力强 | 模型生态绑定 |
| Google ADK | 层级式 agent 树（父派子、子返父）；多语言；GCP / 多模态深度集成 | 相对年轻，社区与文档积累较薄 |
| CrewAI | 角色化多 Agent DSL，几十行起步；适合快速原型、角色分工天然清晰的任务 | 编排控制力有限，团队常会长出去 |
| AutoGen | 已进入维护模式（仅安全修复），只适合存量系统 | 新项目不要选；迁移优先考虑显式图类框架 |
- 六条判据
- ① 要人工审批/断点续跑/审计吗 ② 真需要多 Agent 吗 ③ 会换供应商吗 ④ 语言栈 ⑤ 上下文控制权 ⑥ 谁维护
- 自己写
- 循环 + 上下文组装 + 工具分发 + 退出条件 —— 这四样是掌握控制权的部分
- 借生态
- 可观测/trace（OTel 生态）、持久化（工作流引擎或数据库）、评测框架、MCP SDK（协议实现别自己撸）
- PoC 必验三项
- 能不能中断续跑、能不能导出完整 prompt、trace 能不能跨 Agent 串联；各半天，省三个月
- 表外还有谁
- Microsoft Agent Framework（.NET/Azure）、Pydantic AI、Mastra、LlamaIndex Workflows
- 框架不是 harness
- 审计、权限、回滚、隔离这些治理能力绝大多数框架不提供，要单独规划（T3-10）
面试视角
- 开口先切三层框架 / 运行时 / harness，点明很多团队买错层
- 报出判据顺序第一条就是要不要人工审批与断点续跑
- 讲一次踩坑抽象泄漏泄在哪、代价是多少
- 给「自己写」的分界自己写循环与上下文，借生态做 trace、持久化、协议 SDK
- 收在中立那句「框架没有好坏，只有你愿不愿意交出这部分控制权」
- 背功能对比表，说不出自己的判据
- 用 GitHub star 数或「社区活跃」当主要理由
- 认为「用框架」和「自己写」是立场问题
- 没意识到人工审批、断点续跑这类需求会决定选型
- 不知道 AutoGen 已转维护模式之类的生态变化
- 切得出框架 / 运行时 / harness 三层，并点出常见的买错层
- 说得出抽象泄漏的具体位置：prompt 模板、memory 拼接、异常吞掉
- 分得清什么值得自己写（循环、上下文）、什么不该自己写（trace、协议 SDK）
- 把可持久化执行、可中断、可导出完整 prompt当硬性验收项
- 有迁移经验，或给得出具体的迁移计划
面试官怎么问
Q3-17 常见于一二面，问法是"你用过哪些框架、怎么选的"。这题最大的陷阱是把它答成功能对比表——面试官早就看过那些表，他想知道的是你有没有自己的判据，以及有没有被框架坑过。
高频追问："你们为什么选 X 不选 Y？"、"如果让你重新选会怎么选？"、"听说不少团队最后自己写循环，你怎么看？"（这一问是送分题，前提是你知道该答什么值钱、什么不值钱）。
答题结构建议
- 先切三层：框架 / 运行时 / harness，说明很多团队买错层。
- 给自己的判据顺序，第一条就是"要不要人工审批和断点续跑"——这最能体现生产经验。
- 讲一次踩坑：抽象泄漏在哪、代价多少。
- 回答"自己写循环"时给分界：自己写循环和上下文组装，借生态做 trace、持久化、协议 SDK。
- 保持中立："框架没有好坏，只有你愿不愿意交出这部分控制权。"
分水岭信号
只读过资料的回答：
- 背功能对比表，说不出自己的判据。
- 用 GitHub star 数或"社区活跃"作为主要理由。
- 认为"用框架"和"自己写"是立场问题。
- 没意识到人工审批、断点续跑这类需求会决定选型。
- 不知道 AutoGen 已转维护模式之类的生态变化。
真做过的回答：
- 能切出框架 / 运行时 / harness 三层，并指出常见的买错层。
- 把持久化执行、可中断、可导出完整 prompt当作硬性验收项。
- 说得出抽象泄漏的具体位置（prompt 模板、memory 拼接、异常吞掉）。
- 回答"自己写循环"时能区分什么值得自己写（循环、上下文）、什么不该自己写（trace、协议 SDK、持久化引擎）。
- 提到框架的多 Agent 原语会诱导过早拆分——这是把 T3-8 的判断力带进选型题。
- 有迁移经验或迁移计划的具体描述。
小结与延伸
继续深入
本篇归属第 3 章「Agent 开发」，去做这一章的题。