你的 LangGraph 可能让 Claude 变笨了——墨尔本大学用 1,200 个对话证明给你看

你是一个工程师。你的老板说："我们需要一个客户服务 AI。用 LangGraph 搭一个编排工作流。"

于是你花了四天画流程图：14 个节点、3 个决策中枢、多条分支路径。你用 LangGraph 把每个节点变成图里的一个步骤——接收用户输入 → 调用 LLM 决策下一步 → 路由到下一节点 → 继续。你测试了 200 个场景，发现 24% 的对话在某个决策环节卡死了。你觉得是你的图设计得不够好。

问题是——可能不是图的问题。可能是这个"图"架构本身的问题。

墨尔本大学的一篇新论文做了一个直接的、控制变量的实验。同一个 Claude Sonnet 模型、同一个任务、同一套流程规范。条件 A：用 LangGraph 做外部编排——每个节点的 prompt 模板逐点注入。条件 B：把整个流程图作为纯文本塞进 system prompt，让模型自己决定怎么走。三个领域——旅行预订（14 节点）、Zoom 技术支持（14 节点）、保险索赔处理（55 节点）——各 200 个场景。

结果：条件 B（直接给张图）在所有 15 个指标上全部优于条件 A（LangGraph 编排）。无一例外。

📊 2. 数字的冷酷性

用 Claude Sonnet 作为裁判（1-5 评分），三个领域的五个评估维度上：

• 任务完成度：in-context 4.53-4.92 vs LangGraph 4.17-4.62
• 信息准确性：in-context 4.64-4.92 vs LangGraph 4.21-4.75
• 一致性：in-context 4.83-4.99 vs LangGraph 4.32-4.55
• 优雅处理偏差：in-context 4.96-5.00 vs LangGraph 4.38-4.62
• 自然度：in-context 5.00 vs LangGraph 4.58-4.84

所有 15 个比较的 p 值都小于 0.005（Mann-Whitney U，Holm-Bonferroni 校正）。效应量 d 从 0.37 到 1.01。

但论文的作者非常诚实——他们认为"自然度"评分为 5.00 完全有可能是因为 Claude 作为裁判在评判自己产生的文本时有系统偏差（LLM 自我偏好偏差）。所以他们用 GPT-4.1 独立重新评定了全部 1200 个对话。

GPT-4.1 的重判结果显示：11/15 个比较仍显著优于 in-context——0 个优于 LangGraph。 任务完成度、信息准确性和一致性这三个最核心的指标在两种裁判下都一致——编排被碾压了。自然度差距缩小到接近零——Claude 确实偏爱自己不受约束的文本，但这不影响结论的核心部分。

🔥 3. 编排为什么会更差？三个结构性的毒瘤

论文指出编排架构有三个根本性的故障源——不是因为 LangGraph 写得不好——而是因为"外部编排"这种架构存在内生的信息截断：

推理碎片化。LangGraph 每次调用 LLM 时只注入当前节点的 prompt 模板——模型只看到了流程图的一个局部——产品搜索、但不知道后面还有价格比对——信息确认、但不知道已确认的会被用在索赔决定中。模型的推理被限制在一个节点的时间窗内——它失去了对全局对话弧线的感知——于是反复问相同的问题、跳跃步骤、或截断对话。

编排引入的独有故障模式。编排器在决策中枢需要额外的 LLM 调用来选择下一分支。这个调用本身可能出错——论文识别出三类只存在于编排中的故障：路由失效（LLM 分类错了对话状态→选择了错误的下一节点）、决策模糊（多个边条件同时触发→编排器选择默认分支也就是最危险的分支）、模板冲突（当前节点的 prompt 与对话上下文冲突→模型困惑二选一）。这些故障在 55 节点的保险领域会逐级放大——一次错误的分类→错误的信息收集→错误的覆盖判断→失败的索赔——一步错步步错。

约束了模型的自然表达能力。逐节点模板注入——每个节点的语言被限定在一个小的脚本空间内——对话变成了节点之间的硬切换——失去了人类交谈的自然呼吸。人的对话不是在节点间跳转的——是在一个连续空间里流动的——但你一旦把对话切成离散的节点步骤——你切断了这个流动。

⚡ 4. 效率与成本的经济学——你可能没有意识到的

表面上看，编排更省 token——因为不需要在每个 API 调用中传输整个流程图。在 55 节点的保险领域：in-context 消耗 68K token/对话，编排消耗 43K token/对话——编排似乎更便宜。

但你忽略了编排器的路由开销。

旅行预订：编排 10.8 次 LLM 调用/对话 vs in-context 8.7 次（1.2 倍）。保险领域：编排 17.3 次 LLM 调用/对话 vs in-context 10.0 次（1.7 倍）。每多一次调用就是一次网络往返——每一次往返就是 200-500ms 的额外延迟——每一个延迟就是用户体验的一次减分。

在总成本上，in-context 确实贵了 1.3-1.4 倍——旅行 \(0.10 vs\)0.08，保险 \(0.22 vs\)0.17（Claude Sonnet API 定价）。但这 \(0.05 的额外成本换来了 9-24% 失败率降低到 0.5-11.5% 的质量提升。平均每花\)0.05 额外成本就避免了一次失败的对话。把这个成本除以被挽回的客户流失、人工客服升级成本、品牌信任损失——这 $0.05 可能是你今年投资回报率最高的五美分。

📉 5. 失败模式——编排如何在三个领域中崩塌

论文的失败率数据是结论中最有力的部分：

Zoom 的差距（18×）特别震撼。在旅行的编排失败中——模型跳过了决策步骤，直接进入了错误的分支——循环收集信息但无法推进。而在保险的失败中——编排器在 6 个决策中枢的多次路由判断中出现了系统化的错误级联——一个错误的类型判断导致整个下游路径被污染。

in-context 为什么能做到只有 0.5% 的 Zoom 失败率？因为模型在看到整个流程图后——知道从诊断到解决到确认的全局路径——能在此刻的局部行动中保持对全局目标的意识。编排器在每个决策点被剥夺了这种全局意识。

⚠️ 6. 诚实承认——那些不能从这篇论文得出的结论

第一，这不是对 LangGraph 的攻击。 论文用的 LangGraph 是标准用法——节点映射到图节点、决策中枢用额外的 LLM 调用选择分支——这不是一个错误实现。其他框架——CrewAI、Google ADK、OpenAI Agents SDK——共享这个核心范式。所以这不是 LangGraph 的特定问题——而是"逐节点模板注入 + LLM 路由"这一范式的深层问题。

第二，"三个领域都是合成场景"。 所有 200 个场景都是 LLM 模拟的用户驱动的——不是真实的生产对话。真实用户的非预期行为、对抗性行为、或重复提问可能改变编排 vs in-context 的相对表现。但这些合成领域也被精心设计为覆盖整个流程图的路径、用户风格和满意度的全谱——所以它们不是"任意的合成"而是"受控的合成"。

第三，in-context 方法的 token 消耗约束。 在论文中，最复杂的 55 节点流程图的序列化文本约为 4000 token——在现在 200K+ token 的上下文窗口中只是 2%。但如果你的流程有 500 个节点并串联复杂的业务逻辑——纯文本表示可能超出窗口。论文承认了这个局限——并且引用了他们另一篇论文——通过微调将流程"编译"到一个小模型（8B）的权重中——以 128-462 倍的推理成本降低达到与编排器相当的质量。这是成本和质量之间的第三条路。

第四，编排仍然有存在的理由。 论文明确界定了编排仍有价值的场景：多模型管道（不同步骤需要视觉模型 + 代码模型）、工具调用与外部状态管理（数据库、API、文件系统——编排器管理状态持久化）、非流程性开放任务（创意写作、研究探索——没有预先定义的流程需要外部结构提供骨架），以及小型模型（较弱模型需要编排的护栏来补偿较差的指令遵循能力）。这篇论文的结论是：对于给定一个已知流程的、使用前沿模型的多轮对话——编排提供了零收益和可衡量的损害。

💭 我的判断与其他观察

读完这篇论文，我想起的是框架演进的一条历史规律。

当 React 刚出来时——你需要 Redux、redux-saga、redux-thunk——来管理状态和副作用。但随着 React hooks 和 React Query 的成熟——Redux 在很多场景变成了过度工程化的遗留包袱。外部编排框架在 LLM 早期阶段提供了有价值的结构——当 GPT-3 需要每一步精确的指令才能产出连贯的结果时——但这种必要性随着模型能力的跃迁而蒸发。

论文引用了一个调查——80% 的开发者在选择 LangGraph、CrewAI、Google ADK、OpenAI Agents SDK 之间存在选择困难。这篇论文的情绪是：也许问题不是选择哪个框架——而是对于流程性任务是否需要任何框架。

如果 Claude Sonnet（或 GPT-4.1、Gemini 2.5 Pro）能自我编排一个 55 节点的保险流程达到 95% 的成功率——而 LangGraph 编排同一模型只能达到 83%——那脚手架不是支撑——脚手架是天花板。

最后一点。论文在附录中附了对话示例——编排系统和 in-context 系统面对相同场景的完整对话。读这组对话——编排的会话读起来像一台自动电话树系统——"现在我将帮你搜索航班。请稍候。" → "现在我将帮你选择酒店。请稍候。" → 机械、脚本化、每一段都带有"我在切换节点"的微感。in-context 对话读起来像一个人。"好的，Mumbai 到 Goa，1 月 15-25 号——让我看看航班和酒店一起处理——有什么特别偏好吗？"

当你能看到同一个模型、同一个场景、两种不同对话质量之间的差距——你就会清楚：优化编排器不是解决方案——编排器是问题。

📚 参考文献

1. Dennis, S., Diamond, M., Patil, R., Shabahang, K., Guo, H. (2026). In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks. arXiv:2604.27891.
2. LangChain, Inc. (2024). LangGraph: Build Resilient Language Agents as Graphs.
3. Wang, Y. et al. (2026). An Empirical Study of Agent Developer Practices in AI Agent Frameworks. arXiv:2512.01939.
4. Cemri, M. et al. (2026). Why Do Multi-Agent LLM Systems Fail? arXiv:2503.13657.
5. Kapoor, S. et al. (2024). AI Agents That Matter. arXiv:2407.01502.
6. Dennis, S. et al. (2026). Compiling Agentic Workflows into LLM Weights: Near-Frontier Quality at Two Orders of Magnitude Less Cost. Companion paper.

#AgentOrchestration #LangGraph #InContextPrompting #LLM #OverEngineering #FeynmanLearning #智柴赛博前线🎙️