Agent 编排框架选型：LangGraph、Claude Agent SDK、自研，到底怎么选

### —— 当"选框架"变成战略决策，FOMO 不能再做主 --- ## 引言：被严重低估的选型成本 如果你正在搭一个 Agent 系统，迟早会撞上一个看起来不大的问题—— **"我们用什么框架？"** 听起来像一个 30 分钟的技术选型会议。实际上，这是你未来 18 个月里最难撤销的决定之一。 为什么？因为编排框架不是"工具库"，而是**你的业务代码长在哪根树上**。 - 选了 LangGraph，你的状态机、checkpoint、HITL 模式都和它的抽象绑定； - 选了 Claude Agent SDK，你的能力栈和 Anthropic 模型深度耦合； - 选了自研，你扛起的不是代码，是一支需要长期养着的"框架小团队"。 **换框架的成本，比你预估的高一个数量级。** 见过太多团队在第六个月才发现"选错了"，但已经写了几万行业务代码——这时候要么咬牙重写，要么继续在错误的抽象上叠加复杂度，没有第三条路。 这篇文章不卖某个框架，不站任何阵营。我们只做一件事：**把 LangGraph、Claude Agent SDK、自研三条路的真实成本与适用边界，逐项拆透**。 读完之后，你应该能回答： 1. 编排框架到底要解决什么问题？哪些是它解决的，哪些不是？ 2. LangGraph 强在哪？弱在哪？什么团队适合？ 3. Claude Agent SDK 强在哪？弱在哪？什么团队适合？ 4. 自研到底是"工程能力"还是"工程债务"？ 5. 怎么用一份决策矩阵，把"FOMO 选型"变成"基于约束的选型"？ 6. Adapter 层是什么？为什么它是这场选型中**最重要的工程实践**？ **不绕弯子，直接进入正文。** --- ## 一、先校准前提：编排框架到底负责什么 在选型之前，必须先回答一个常被跳过的问题——**"编排"到底指什么？** 很多团队对这个词的理解是模糊的，结果选型时各说各话。 ### 1.1 一个 Agent 运行时要承担的八件事 把"agent 运行"拆到底，至少包含八件事： | # | 职责 | 说明 | |---|------|------| | 1 | 模型调用与测试 | LLM API 调用、错误处理、速率控制 | | 2 | Tool / MCP / Skill 注册路由 | 把能力暴露给模型，并接收调用 | | 3 | 上下文管理 | 窗口压缩、history 修剪、checkpoint | | 4 | 流程控制 | 顺序、分支、并行、循环、条件中断 | | 5 | 错误处理与回退 | 重试策略、降级、circuit breaker | | 6 | 人类介入（HITL） | 中断、审批、恢复 | | 7 | 流式输出与 UI 桥接 | SSE / WebSocket / 增量渲染 | | 8 | 可观测性 | trace、cost、debug、回放 | **这八件事，每一件框架都可能帮你做，也可能不做**。 选型的本质不是"哪个框架最好"，而是： > **这八件事里，我自己愿意做哪几件？剩下的让框架做哪几件？这个分工是否长期可持续？** ### 1.2 编排不解决什么 也要说清楚编排框架**不解决**的事，避免错误期待： - **不解决 prompt 工程**：再好的框架也救不了一个糟糕的 prompt； - **不解决模型质量**：底层模型不行，框架抽象再优雅也白搭； - **不解决业务逻辑**：业务复杂度该多少还是多少，框架只是搬运它； - **不解决能力封装**：那是 Skill 和 MCP 的事（参见前两篇）； - **不解决评测**：评测是独立的工程基础设施。 **框架是"把八件事的接线方式标准化"**——别指望它替你做思考。 ### 1.3 与 Skills / MCP 的层级关系 回顾一下前两篇的能力栈图：  **编排框架是站在 Skill / MCP / Tool 之上的"驱动层"**。它决定： - 谁先谁后； - 状态怎么流转； - 错误怎么处理； - 用户什么时候介入。 理解了这个站位，才知道选型在选什么。 --- ## 二、三个候选：先看清各自的"形状" 我们要对比的不是"LangGraph vs Claude SDK vs 自研"——而是它们各自代表的**不同设计哲学**。 ### 2.1 候选 A：LangGraph —— 显式状态图 **定位**：基于显式状态机的 agent 运行时，与 LangChain 生态深度集成。 **核心抽象**： - `State`：贯穿整个执行流程的状态对象（你定义其 schema）； - `Node`：图的节点，每个节点是一个函数，读 state 写 state； - `Edge`：节点之间的连接，可条件、可循环； - `Checkpointer`：状态持久化器，让流程可中断可恢复。 **它的世界观**：**Agent 是一台显式定义的状态机**。你画出这台状态机的图，框架负责让它跑起来、跑得稳、可恢复。  **强项**： - 控制流**显式可视化**——复杂分支/循环/多 agent 可读性好； - **Checkpoint + 中断恢复**是一等公民——HITL 体验最完整； - **time-travel 调试**——可以回到任意历史状态重跑； - 与 **LangSmith** 可观测性原生打通； - **模型/厂商解耦**——理论上换模型只改一行。 **弱项**： - **学习曲线陡**——State / Reducer / Channel 的概念需要消化； - **LangChain 历史包袱**——很多人对早期 LangChain 的不稳定有阴影（但 LangGraph 本身相对稳）； - **Skill / MCP 集成需要写胶水层**——不是开箱即用； - **强抽象 = 调试多一层间接**； - 对**简单任务过度复杂**——一个 50 行能写完的 agent，用 LangGraph 可能写出 150 行。 **它适合什么团队**： - 流程**确实复杂**（多分支、需要 HITL、长流程、多 agent）； - 模型可能**多家混合**或会替换； - 团队**有人愿意吃透抽象**——不是"会 import 就行"，而是出问题时能读源码。 ### 2.2 候选 B：Claude Agent SDK —— 厂商一等公民 **定位**：Anthropic 官方 agent 运行时，与 Claude、Claude Code、Skills、MCP **同源**。 **核心抽象**： - 模型调用 + tool loop 是内置的； - Skills 是**原生概念**，零胶水加载； - MCP 客户端是**原生集成**，registry 配置即可用； - 内置 file / bash / edit 等基础 tool。 **它的世界观**：**Agent 是 Claude + 工具集 + Skill 集 + MCP servers 的协同**。框架的工作是把这套协同变得"无摩擦"。  **强项**： - **与 ADR-0001 三层模型零摩擦**——Skill / MCP / Tool 都是原生； - 由**模型厂商维护**，跟随 Claude 能力演进最快； - **默认行为合理**，模板代码少； - 起步成本**最低**——一个文件就能跑。 **弱项**： - **厂商绑定**——换模型成本最高。理论上可以接其他模型，但官方优化与 best practice 都围绕 Claude； - **复杂图式控制流**不如 LangGraph 显式——它更偏"线性 + tool loop"； - **生态成熟度**低于 LangGraph（社区组件少）； - **长期维护承诺**取决于 Anthropic 的产品战略——这是不可知风险。 **它适合什么团队**： - Claude 是**主力模型**（且不打算 6 个月内换走）； - 大量使用 **Skills**——Skill / MCP 原生支持是关键收益； - 控制流以"**模型自主决策 + tool/skill 调用**"为主，不需要复杂状态图； - 能接受**厂商绑定**的长期成本。 ### 2.3 候选 C：自研 —— 完全可控的运行时 **定位**：基于模型 SDK（Anthropic SDK / OpenAI SDK）+ 自己的状态管理、tool 路由、流式处理。 **核心抽象**：**你的抽象**。 **它的世界观**：**没有外部框架能精确匹配我的需求，而且我有能力长期维护**。  **强项**： - **零抽象成本**——调试路径最短，错误信息最直接； - **完全契合团队需求**，无冗余概念； - **无锁定**——可在多个模型/厂商间切换； - **性能可优化到极致**。 **弱项**： - **重新发明轮子的常见陷阱**——checkpoint、中断恢复、tool 路由都不是"写个 while 循环"那么简单； - 团队需要**持续投入维护**——**人员流动是最大风险**； - 失去**生态红利**（调试工具、评测工具、社区组件）； - **跟随生态**需要团队自己跟（新 MCP 特性、新 Skill 规范字段）； - **隐性技术债**积累快——半年后你可能造出了"难用版 LangGraph"。 **它适合什么团队**： - 框架方案在 POC 中被证明**实质性不满足某个硬约束**（延迟、内存、特殊协议）； - 团队**已有**长期维护编排层的工程师**承诺**——不是临时抽调； - 复杂度可控——只是"加一层薄壳"，**不是"重写 LangGraph"**； - 通过 ADR 评审，列出明确的不可妥协约束。 ### 2.4 还有其他候选吗？ 简短回答：有，但不在主推荐内。 | 候选 | 定位 | 为什么不主推 | |------|------|------------| | AutoGen | 多 agent 对话隐喻 | 对确定性流程支持弱，不适合生产 | | CrewAI | 多 agent 角色扮演 | 同上，"角色"代替"职责"是反模式 | | LlamaIndex Workflows | 事件驱动 | 生态偏 RAG，编排能力较轻 | | OpenAI Agents SDK | OpenAI 阵营对应 Claude SDK | 评估方式类似 Claude SDK | | Vercel AI SDK | 边缘 + 流式 UX | 编排能力较轻，偏 UI 层 | **这些不是不能用，是不建议作为默认选项**。它们各有适用场景，但都不是"通用编排框架"。 --- ## 三、决策矩阵：把感觉变成判断 光看"强项弱项"还不够。我们需要一个**多维度对比矩阵**，把直觉转换成可对比的指标。 ### 3.1 12 维对比 | 维度 | LangGraph | Claude Agent SDK | 自研 | |------|-----------|------------------|------| | 控制流表达力 | 高（显式图） | 中（线性 + tool loop） | 任意 | | Skill 原生支持 | 需胶水层 | 原生 | 需自己实现 | | MCP 原生支持 | 支持但需配置 | 原生 | 需实现 client | | Checkpoint / 中断恢复 | 一等公民 | 部分支持 | 自己造 | | HITL | 强 | 中 | 自己造 | | 多 agent 编排 | 强 | 弱 | 任意 | | 流式输出 | 支持 | 支持 | 自己造 | | 模型可替换性 | 高 | 低（绑定 Claude） | 成本高 | | 可观测性 | LangSmith 原生 | 需接入 trace 协议 | 自己造 | | 学习曲线 | 陡 | 缓 | N/A | | 锁定风险 | 框架锁定（中） | 厂商锁定（高） | 团队锁定（高） | | 生态成熟度 | 高 | 中（增长快） | — | **两个观察**： 1. **没有一个候选在所有维度都赢**——这就是为什么必须用决策矩阵，不能凭"感觉"； 2. **"锁定"在每个选项里都存在**——只是锁定的对象不同（框架 / 厂商 / 团队）。**没有零锁定的选择**。 ### 3.2 引入"权重"：你团队真正在乎什么 矩阵本身不能直接给答案——因为不同团队的权重不同。 下面三个典型场景，权重完全不一样： #### 场景 1：内部 Coding Agent 团队（5 人） | 维度 | 权重 | 原因 | |------|------|------| | Skill 原生支持 | 高 | Skills 是产品形态核心 | | MCP 原生支持 | 高 | 内部 MCP server 多 | | 学习曲线 | 高 | 团队小，不能消化复杂抽象 | | 模型可替换性 | 低 | Claude 是确定选择 | | 复杂图式控制流 | 低 | 流程相对线性 | → **倾向 Claude Agent SDK**。 #### 场景 2：金融领域 Multi-Agent 工作流（30 人） | 维度 | 权重 | 原因 | |------|------|------| | 控制流表达力 | 高 | 复杂审批流程 | | HITL | 高 | 合规必需 | | Checkpoint | 高 | 长流程必需 | | 多 agent 编排 | 高 | 风控 / 审核 / 执行多角色 | | 模型可替换性 | 中 | 监管可能要求模型多样性 | → **倾向 LangGraph**。 #### 场景 3：高频实时建议 Agent（延迟敏感） | 维度 | 权重 | 原因 | |------|------|------| | 性能 | 极高 | 用户感知 | | 抽象开销 | 极高 | 多一层抽象就是延迟 | | 灵活性 | 高 | 需要做框架不支持的优化 | | 团队投入 | 可承诺 | 已有专人 | → **倾向自研**。 **核心信号**：**先想清楚你的权重，再看矩阵**。反过来做永远会得到错误结论。 ### 3.3 一句话决策规则 把上面浓缩成可执行的规则：  **最后一条最重要**——自研的诱惑往往来自"我看不惯框架的某个抽象"。**这不是充分理由**。 --- ## 四、真正的工程实践：Adapter 层 读到这里如果你觉得"还是好难选"——好消息是，**有一个工程实践能让选错的代价降到最低**。 这就是 **Adapter 层**。 ### 4.1 为什么需要 Adapter 回到引言里的问题：**换框架的成本，比你预估的高一个数量级**。 为什么这么贵？因为业务代码长在了框架的抽象上： ```python # 反模式：业务代码直连框架 API from langgraph.graph import StateGraph from langgraph.checkpoint.sqlite import SqliteSaver # ... 几千行业务代码深度依赖 LangGraph 抽象 ... class MyBusinessAgent: def __init__(self): self.graph = StateGraph(MyState) self.checkpointer = SqliteSaver(...) # 业务概念被翻译成 LangGraph 概念 ``` 某天你想换到 Claude Agent SDK 或自研——**几千行代码都要改**。 **Adapter 层的核心思想**：业务代码只和**你自己的抽象**对话；具体框架被关在 Adapter 后面。 ### 4.2 Adapter 层架构  **关键点**： 1. 业务代码**只 import Adapter**，不 import 任何框架； 2. Adapter 定义**最小够用**的接口（run、checkpoint、interrupt、observe），不暴露框架特有概念； 3. 每个框架有一个**实现类**，做翻译工作； 4. **CI lint 规则**强制业务代码不直接 import 框架。 ### 4.3 Adapter 最小接口示意 ```python # orchestrator/base.py from typing import Protocol, AsyncIterator from dataclasses import dataclass @dataclass class RunInput: messages: list[dict] tools: list[ToolSpec] skills: list[SkillRef] metadata: dict @dataclass class RunEvent: kind: str # "token" | "tool_call" | "skill_activated" | "done" | "error" data: dict class Orchestrator(Protocol): async def run(self, input: RunInput) -> AsyncIterator[RunEvent]: """执行一次 agent run，返回事件流""" ... async def checkpoint(self, run_id: str) -> str: """持久化当前状态，返回 checkpoint id""" ... async def resume(self, checkpoint_id: str, additional_input: dict | None = None) -> AsyncIterator[RunEvent]: """从 checkpoint 恢复""" ... async def interrupt(self, run_id: str, reason: str) -> None: """中断一个正在运行的 agent""" ... ``` 业务代码用法： ```python # business/customer_agent.py from orchestrator import get_orchestrator orch = get_orchestrator() # 从配置决定用哪个实现 async for event in orch.run(RunInput(...)): if event.kind == "token": yield event.data["text"] elif event.kind == "skill_activated": log_skill_event(event.data) elif event.kind == "done": break ``` **这段业务代码不知道下面跑的是 LangGraph 还是 Claude SDK**——这正是目标。 ### 4.4 Adapter 的代价（必须诚实） Adapter 不是免费的： | 代价 | 说明 | |------|------| | 抽象一致性 | 不同框架的能力不完全等价（如 LangGraph 的 time-travel 在 Claude SDK 没有） | | 维护成本 | 每个框架升级都可能影响 Adapter | | 性能开销 | 多一层调用 | | 过度抽象风险 | Adapter 容易膨胀成"我们自己的框架" | **关键反模式**：**把 Adapter 做成"通用 agent 框架"**。 不要这样做。Adapter 只覆盖团队**实际用到**的能力，不是框架全部表面积。 **正确的 Adapter 是薄的**——`run / checkpoint / resume / interrupt` 几个核心接口够了。 ### 4.5 Adapter 的实际收益 设想一个真实场景： > 团队 A 用 LangGraph 起步，做了 6 个月。某天 Claude 推出了一个杀手级特性，需要切到 Claude Agent SDK 才能用。 > > - **没有 Adapter**：业务代码深度依赖 LangGraph，迁移需要 3 人 × 2 个月。 > - **有 Adapter**：重写 Adapter 的 Claude 实现（≈ 1 人 × 2 周），业务代码不动。 **Adapter 是对未来变化的对冲**。一次性投入 1-2 周，换来未来 3-5 倍的迁移弹性。 --- ## 五、被忽视的"软约束"：你团队真正能消化什么 技术维度之外，选型还有一类被严重低估的约束——**团队消化能力**。 ### 5.1 三个软约束 #### 软约束 1：调试能力 **框架越抽象，调试越难**。 报错信息穿过 3 层抽象后变得无意义： ``` Traceback (most recent call last): File ".../langgraph/pregel/runner.py", line 287, in _step ... File ".../langgraph/channels/last_value.py", line 42, in update ... TypeError: Cannot infer reducer for channel 'state' ``` 新人看这个报错，要花一小时才知道问题出在自己的 `State` schema 上。 **问题不在框架——问题在团队能否长期消化这种抽象**。 **自评问题**： - 团队里有人能读 LangGraph 源码吗？ - 出问题时谁负责定位？ - 这个人离职了怎么办？ #### 软约束 2：演进负担 框架会演进。每个 minor 版本可能 break 你的代码： - LangGraph 2024 → 2025 之间有过非平凡的 API 变化； - Claude SDK 在快速演进期，API 不稳定； - 自研更不用说，演进负担 100% 在你头上。 **自评问题**： - 你愿意每 3-6 个月跟一次升级吗？ - 升级 broken 时谁来修？ - 你有 lock 版本 + 灰度升级的流程吗？ #### 软约束 3：招聘与培训 技术选型也是**招聘选型**： - LangGraph 有大量教程和社区，新人上手相对快； - Claude Agent SDK 较新，社区资料少，但概念简单； - 自研——新人必须读你的代码才能贡献，**onboarding 成本最高**。 **自评问题**： - 半年后招新人，他能多快上手？ - 团队知识只在 1-2 个人头上吗？ - 文档化覆盖到什么程度？ ### 5.2 一个常被忽视的事实 **技术债不是代码——技术债是"只有 X 能维护"的状态**。 自研最大的风险不是代码质量，而是**"如果 X 离职会怎样"**。如果答案是"我们就完了"——自研就是不可接受的选择，无论它在技术上多优雅。 --- ## 六、过渡策略：怎么从"现在"走到"目标" 很多团队的现状是——**已经在某个框架上写了一堆代码了，现在怎么办？** 不要一刀切。给三种典型现状的过渡建议。 ### 6.1 现状 A：还在 POC 阶段 **好消息**：你有最大的选择自由。 **建议路径**： 1. 用**最简单的方式**做 POC：直接调模型 API + 几个 tool。**不要先选框架**。 2. POC 验证主链路通了之后，再回头看八件事里你真正需要框架帮的是哪几件。 3. **基于真实痛点选框架**，不是基于猜测。 4. 即使在 POC 阶段，也**立刻引入 Adapter 层**——薄薄一层，但能让你以后无痛切换。 ### 6.2 现状 B：已经在用 LangGraph / Claude SDK，业务代码深度耦合 **坏消息**：迁移成本不低。 **建议路径**： 1. **不要立刻迁移**首先评估痛点是否真到迁移阈值。 2. 引入 **Adapter 层作为重构目标**——从最容易剥离的部分开始，逐步把业务代码从框架 API 解耦。 3. **新模块直接走 Adapter**——存量代码慢慢迁。 4. 等业务代码 80% 通过 Adapter 后，**框架切换才变得可行**。 **关键纪律**：**不要在没有 Adapter 的情况下做"重写 + 换框架"**——这是最坏的组合。 ### 6.3 现状 C：在自研但越来越吃力 **典型症状**： - 修一个 bug 牵动半个 codebase； - 新功能比想象中难加； - 团队抱怨"我们自己造了一个难用版 LangGraph"。 **建议路径**： 1. **承认现实**——这是工程决策，不是技术失败。 2. 评估**保留多少自研部分**：通常是性能关键路径 + 业务特有逻辑。 3. **不该自研的部分**（通用编排、checkpoint、tool 路由）迁移到框架。 4. Adapter 层成为新自研代码和框架之间的桥。 **反模式**：**"我们已经投入这么多了，不能放弃"**。沉没成本不是继续错下去的理由。 --- ## 七、十大反模式：选型与落地一定会踩的坑 ### AP1：FOMO 驱动选型 错误：因为社区在讨论 LangGraph，所以我们也用。 正确：基于八件事和团队权重做决策。 **为什么致命**：选错的代价不是社区给的，是你团队承担的。 ### AP2：业务代码直连框架 API 错误：从第一行业务代码开始就 `from langgraph import ...`。 正确：Adapter 层在第一行业务代码之前就引入。 **为什么致命**：迁移成本翻 5-10 倍。 ### AP3：把 Adapter 做成"通用框架" 错误：Adapter 试图覆盖所有可能的框架能力。 正确：Adapter 只覆盖团队实际用到的。 **为什么致命**：Adapter 自己变成了维护噩梦。 ### AP4：跨运行时混用 错误：一个 agent 内同时用 LangGraph 和 Claude SDK。 正确：单 agent 单运行时；跨运行时通过 MCP 通信。 **为什么致命**：状态不一致，调试地狱。 ### AP5：自研但没有专人长期承诺 错误：抽个工程师"先做着"。 正确：自研需要明确 owner，至少 1 人长期负责。 **为什么致命**：人一离职，整个 codebase 就成了无主之地。 ### AP6：把 multi-agent 当默认隐喻 错误：默认招"AI 同事"——产品 agent、工程 agent、QA agent。 正确：先用 single agent + skills；多 agent 仅在职责正交时引入。 **为什么致命**：multi-agent 的 demo 很惊艳，生产中常常退化成不可调试的对话。 ### AP7：不锁定框架版本 错误：`requirements.txt` 里写 `langgraph>=0.2.0`。 正确：固定到具体 minor 版本；major 升级走 ADR。 **为什么致命**：某天 CI 自动升级，半个团队的 agent 同时崩。 ### AP8：把 checkpoint 用框架原生格式直接落库 错误：直接把 LangGraph 的 SqliteSaver 文件作为业务 state。 正确：业务状态独立 schema，框架原生格式仅作运行时缓存。 **为什么致命**：换框架时 state 不可读。 ### AP9：在 production 用 AutoGen / CrewAI 跑确定性流程 错误：用"AI 团队协作"隐喻做合规审核。 正确：确定性流程用 LangGraph 或 Claude SDK 显式编排。 **为什么致命**：multi-agent 对话流程不可重现，合规审计无法做。 ### AP10：选型不写 ADR 错误：技术 lead 拍板定了，没人记录原因。 正确：每次重大框架决策必须写 ADR，含触发条件、退出条件、复审周期。 **为什么致命**：18 个月后没人记得当初为什么这样选，复盘无据。 --- ## 八、收尾：从"选框架"到"选边界" 这篇文章拆得很细，但所有内容可以凝练成几条核心判断： **1. 编排框架的本质是"八件事的分工方案"。** 先想清楚你愿意做哪几件，剩下让框架做哪几件。**不要先选框架再倒推需求**。 **2. 三个候选各有清晰的适用边界。** LangGraph 适合复杂状态图 + 模型多样性；Claude SDK 适合深度 Claude + 重度 Skills；自研适合有硬约束 + 长期承诺。**不要跨界使用**。 **3. 锁定不可避免。** 你不是在"零锁定"和"锁定"之间选，是在**框架锁定 / 厂商锁定 / 团队锁定**之间选。承认这一点，决策才会清晰。 **4. Adapter 层是这场选型中最重要的工程实践。** 一次投入 1-2 周，换来未来 3-5 倍的迁移弹性。**这是对未来变化的对冲，不是过度工程**。 **5. 软约束往往比技术维度更重要。** 团队能消化什么抽象、能跟随什么演进、能招到什么人——**这些决定了框架能不能长期跑下去**。 **6. 自研不是禁区，但门槛很高。** 有硬约束、有长期承诺、复杂度可控、走 ADR 评审——四条都满足才考虑。**否则默认拒绝**。 **7. 选型必须可复审。** 每 6 个月复审一次。模型变了、规模变了、团队变了，决策可能要变。**写进 ADR，不要凭记忆**。 --- ### 三个可操作的下一步 **如果你刚开始**： **不要先选框架**。先用最简单的方式做 POC。三周后回头看八件事，再决定。**Adapter 层从第一行业务代码就引入，哪怕只是个空壳**。 **如果你已经在某个框架上**： 评估"换框架"的实际成本。如果 Adapter 不存在，**先建 Adapter，不急着换**。让存量代码逐步通过 Adapter，新代码立即走 Adapter——这是最低风险的演进路径。 **如果你在自研**： 诚实回答两个问题——"如果 X 离职会怎样"和"我们造的是薄壳还是事实上的难用版 LangGraph"。**答案决定了你是该继续还是该止损**。 --- ## 延伸阅读 / 验证路径 > 提示：编排框架生态演化极快，以下链接请以**官方域名当前内容**为准。 - LangGraph：`langchain-ai.github.io/langgraph/` - Claude Agent SDK / Building agents：`docs.anthropic.com`（搜 "Agent SDK"、"Building effective agents"） - OpenAI Agents SDK：`openai.github.io/openai-agents-python/` - Anthropic《Building Effective Agents》（2024-12 工程博客）——反对过度框架化的官方观点 - 社区讨论：r/ClaudeAI、r/LocalLLaMA 搜 "LangGraph vs"、"agent framework" **Knowledge Boundary**：本文涉及的所有框架都在快速演进期（Evolving）。具体 API、能力矩阵、稳定性评估请以引用链接的当前版本为准。本文的**决策原则与 Adapter 层实践**预计相对稳定；具体框架特性细节可能在数月内变化，**建议每 6 个月复审一次选型决策**。 --- > **写在最后** > 编排框架的选型，本质是为团队的未来 18 个月画一道边界。 > 这道边界画得好，业务跑得顺；画得不好，每天都在和框架打架。 > **选边界，不是选明星**——这是这篇文章想留下的唯一一句话。 --- *如果这篇文章让你重新审视了团队的编排框架决策，欢迎转发给身边那些"先把 demo 跑起来再说"的工程师。* *这是「AI 能力工程系列」的第三篇。前两篇分别拆了 Skills 规范与构建、MCP server 治理。三篇配合，构成 AI 工程的完整决策框架——从能力封装、能力暴露、到能力编排。下一篇我们会拆「Agent 可观测性与评测：从 trace 到回放的完整链路」，把"能跑"变成"敢上"。*