LangGraph / OpenAI Agents SDK / ADK / CrewAI 怎么选？为什么不少团队最后自己写循环？
谁在问：一二面通用；面试官用「为什么很多团队最后自己写循环」这一问区分调包与掌控
口语化问法
- 你们用的什么框架？当初怎么选的？
- 这几个主流框架你怎么比较？
- 听说很多团队做着做着就把框架扔了自己写，你怎么看？
考察意图
框架名单会随时间变，所以面试官不会以"你知不知道某个框架"论英雄，他要看的是：
- 有没有选型判据。 能说出"我需要在循环的哪一层插手、需不需要持久化、能不能拿到最终请求体"的人，换个框架名单照样会选。
- 理解不理解框架的价值边界。 核心循环本身只有几十行（见 Q3-06），框架的价值在周边——持久化、人在环、可观测。看不到这一点的人，会把框架当成"Agent 能力的来源"。
- 有没有被抽象泄漏坑过。 说得出"排障时要读框架源码才知道 prompt 长什么样"的，是真用过。
- 会不会平衡。 一味吹"自己写更可控"的人，通常没算过持久化、并发、trace、人在环这些要自己补的账。
参考答案
60 分答案（及格线）
我不会先看框架名单，先看四个需求维度：
| 维度 | 问自己什么 | 影响什么 |
|---|---|---|
| 控制粒度 | 要不要在每一步插手（注入指令、条件分支、中断）？ | 图/状态机类框架 vs 轻量 SDK |
| 状态与持久化 | 任务会不会跑很久、要不要断点续跑、有没有人工审批？ | 是否需要 checkpoint 能力 |
| 可观测 | trace 是否内建、能否接入现有体系 | 排障成本 |
| 绑定风险 | 是否绑定某家模型或云生态 | 长期迁移成本 |
截至 2026-08 的粗略定位（以官方文档为准）：LangGraph 走图/状态机路线，控制力和持久化、断点续跑是强项，代价是概念多、学习曲线陡；OpenAI Agents SDK 轻量、贴近原生接口，上手快，但生态倾向明显；Google ADK 面向企业部署，和自家云与模型整合紧；CrewAI 用角色协作的抽象，做 demo 极快，但控制粒度偏粗、深度定制时容易顶到天花板。
至于"很多团队最后自己写循环"，原因是核心循环本身很短，而框架的抽象在排障时反而挡路。
90 分答案（有生产经验的回答）
补三层。
1. 加两条选型硬指标，比功能列表更实用。
- 能不能一行代码拿到最终请求体？ 上下文和提示词是产品的核心资产，看不到发出去的是什么，调优和排障都无从谈起。这条我会在技术选型时当场试，试不出来就淘汰。
- 能不能只用一部分？ 好的库允许你只取持久化或只取 trace；框架式的全家桶往往要么全用要么不用。可拆卸性直接决定了将来的迁移成本。
再加一条现实考量：这个领域 2024–2026 的破坏性变更非常频繁，升级成本要计入选型。
2. "自己写循环"的真实动因，三条。
- 核心逻辑短：一个带预算、指纹、降级的循环几十行就够（Q3-06）。框架替你省下的这部分，其实不是瓶颈。
- 抽象泄漏：出问题要读源码才知道框架偷偷加了什么系统提示、重写了工具描述、吞掉了哪个错误、token 统计为什么对不上。调试成本从"写代码"转移到"读别人的代码"，而且发生在最紧急的时候。
- 上下文控制被挡：上下文工程恰恰是差异化所在（见 Q1-11），而框架的默认封装往往正好挡在这一层。
3. 但要说清自己写的代价，否则这个答案是偏的。 自建意味着持久化与恢复、并发与限流、重试与幂等、trace 接入、人在环审批、提示词版本管理，全部自己建；团队新人上手也没有现成文档可依。所以正确表述是：框架的价值随团队成熟度和场景特殊性递减——早期用框架跑通业务假设是划算的，跑通之后再逐层收回控制权。
4. 我的实际选择通常是折中：自己写核心循环，周边用库不用框架——schema 校验用一个库、持久化用现成的工作流引擎、trace 直接对 OTel（截至 2026-08，GenAI 语义约定 v1.41 已定义 invoke_agent → chat → execute_tool 的嵌套与 token 指标，虽然多数属性仍是实验性，但对齐它能避免将来重做）。这样每一块都可替换，没有哪一块能绑架我。
5. 三段式看框架：解决脚手架、持久化、可观测、社区验证过的模式；代价是抽象泄漏、上下文控制被挡、破坏性变更、生态绑定；不该用在核心竞争力就是上下文编排、已有成熟基础设施、或需要极致定制的场景。
追问链
长任务 + 中途人工审批 + 断线能续跑，你怎么选？
期望三条指向同一个能力 —— 状态外置且可恢复，执行状态不能只活在进程内存。两条路径：带checkpoint的图类框架；或自己写循环 + 挂公司已有的工作流引擎管持久化与恢复。约束：审批等待是小时到天级，循环必须能挂起—唤醒，每步幂等（唤醒后不重跑已完成的写），状态要人看得懂信号抓住「状态外置 + 步骤幂等」、提到公司已有工作流引擎 → 做过长任务；只答「选 LangGraph 有 checkpoint」→ 记住功能没想清约束自己写循环，要补的东西里哪三样最容易低估？
期望① 持久化与恢复（进程重启、滚动更新时在跑的任务）；② 提示词与工具定义的版本管理：能对比、回滚、关联评测，出事才建；③ 人在环：审批、中断、接管的状态流转，比循环复杂。其余：并发限流、重试幂等、trace、成本核算 —— 没一样是 Agent 特有，后端越成熟自建成本越低信号给得出「后端成熟度决定自建成本」这个结论 → 想通了；只答「要自己实现重试和日志」→ 低估了工作量抽象泄漏具体长什么样？举个你遇到过的例子
期望框架往 system prompt 偷加内容；工具描述被重写或截断，选择准确率莫名下降；内置重试吞错误，日志里看不到真实原因；token统计和账单对不上（内部有隐藏调用）；流式与非流式行为不一致。共同点：问题都在你看不见的那一层，只能读源码；选型第一件事是打印最终请求体信号举得出至少两种具体形态 → 用过且踩过；只会说「抽象泄漏就是封装太深」→ 是名词不是经历怎么避免被框架绑死？
期望把领域资产和框架隔离：工具实现、提示词、评测集、trace 四样必须能脱离框架单独跑和评估；接口层用自己的契约包一层，核心逻辑不import框架类型。工程手段：pin版本、升级走灰度、升级前用评测集跑回归（升级引发行为漂移很常见且不报错）。检验标准：能不能一个下午换掉框架信号给出「评测集与 trace 必须独立于框架」和那条一下午的检验标准 → 吃过迁移的苦；只答「多写抽象层」→ 太笼统团队用某框架半年，处处受限想推倒重写，评估要两个月，你怎么决策？
期望先把「处处受限」落成三五条清单，逐条判是框架必然导致还是用法／需求问题 —— 不少是后者，重写后原样重现 → 前置：先有能跨新旧对比的评测集，没有就拦下 → 拒绝一次性重写，走绞杀者式渐进替换：先自建收益最大又最独立的上下文组装层与框架并存，再动 trace 或持久化 → 分阶段验收：成功率不降、成本不升，达不到就停。沉没成本不参与决策，只看未来六个月总成本信号要求把抱怨落成清单、走渐进替换、把「先有评测集」设为前置 → 主导过技术债偿还；直接支持重写或直接否决 → 都缺决策方法
评分要点
- 先给选型判据（控制粒度、持久化、可观测、绑定风险），而不是先背框架名单
- 能对主流框架给出定位差异（截至 2026-08，并声明以官方文档为准）
- 提出可操作的硬指标：能否拿到最终请求体、能否只用一部分
- 说得清"自己写循环"的三条动因（核心逻辑短、抽象泄漏、上下文控制被挡）
- 同时说得清自建的代价（持久化、人在环、版本管理、trace 都要自己补）
- 结论平衡：框架价值随团队成熟度与场景特殊性递减
- 加分：折中做法——自己写循环 + 用库不用框架 + trace 对齐 OTel
- 加分：领域资产（工具、提示词、评测集、trace）独立于框架
- 加分：重写决策走渐进替换，且以评测集为前置条件