7 篇博文 含有标签「orchestration」

Agent A 向 Agent B 请求完成其任务所需的一项数据。Agent B 在回答之前，向 Agent A 请求生成该数据所需的一项上下文。这两项请求在发出途中都跨越了“需要人工审核”的边界。第一项请求落入了由 Priya 监看的 Slack 审批频道。第二项落入了由 Marcus 监看的 Jira 队列。Priya 正在吃午饭。Marcus 正在接听客户电话。两人都不知道对方的存在。工作流挂起了 19 个小时，直到一次客户投诉迫使有人去询问为什么汇总结果从未送达，才有人注意到。

这不是一种新颖的失败模式。它是分布式系统中最古老的失败模式，只是换了一身新装。Coffman 条件——互斥（mutual exclusion）、占有且等待（hold and wait）、不可剥夺（no preemption）、循环等待（circular wait）——早在 1971 年就被命名了，而一个带有“人机协同”（human-in-the-loop）审批队列的多 Agent 系统默认满足这所有四个条件。新的麻烦在于，死锁中的“资源”之一是人的注意力，这意味着你的活性保证（liveness guarantee）现在受限于两个互不相识的人独立进行上下文切换的速度。

客服工单在上午 9:41 送达：“我被扣了三次费。”链路追踪看起来无异常。一条用户消息，一次规划器轮转，三次对 charge_card 的调用 —— 每次都有唯一的工具调用 ID，每次都返回 200 OK，每次都写入了不同的 Stripe 扣款。工具本身有幂等键，后端有去重表，支付处理器也遵循 Idempotency-Key。每一层都是幂等的，但客户依然支付了三次。

如果你构建 Agent 的时间足够长，这类 Bug 迟早会出现在你的桌上。它不是任何工具的 Bug，而是 Agent 循环与工具之间契约的 Bug，而这种契约几乎总是只存在于资深工程师的脑海中。

Agent 以“全部搞定——如果需要任何修改请告诉我！”结束它的回合，而你的编排器必须决定是将工单标记为已解决、启动下一次交接，还是重试。这句话不是一个返回码。它只是一个训练出来的、为了在聊天结束时听起来很贴心的礼貌语，而它下游的每一行自动化代码都继承了这种模糊性。那些将此视为解析问题的团队会编写捕获 \b(done|complete|finished)\b 的正则并收工。而那些在生产环境中运行 Agent 的团队最终会明白，完成是一个事件，而不是一种情绪。

失败模式通常是双峰且枯燥的。要么是 Agent 在未完成时宣布完成——过早终止——而编排器愉快地在一个半成品产物上推进工作流。要么是 Agent 确实完成了，但表述方式与检测器不匹配（“我已经落地了更改，尽管边界情况的测试仍然不稳定”），编排器于是发起重试，导致重复工作、产生重复的副作用，有时甚至会推翻成功的第一次尝试。这两种模式都会静默地退化。在有人阅读 Trace 并注意到 Agent 说了“我想这些就是全部了”而计费系统将其视为一次提交（commit）之前，任何仪表盘都不会显示异常。

解决方法不是更智能的解析。而是给 Agent 一个结构化的终止方式——一个具有枚举状态、原因代码和你的流水线可以路由的句柄（handle）的“完成工具（done-tool）”——并将编排器改为等待该事件，而不是监听聊天流。

高层级智能体框架承诺将三天的集成工作转化为三小时的原型开发。这个承诺是真实的。问题在于接下来发生的事情：在一家开发 AI 驱动的浏览器测试智能体的公司中，工程师们在进入生产阶段六个月后发现，他们花在调试 LangChain 上的时间竟然和开发功能的时间一样多。他们的解决方案很彻底——完全弃用了框架，并回退到模块化的构建块。“一旦我们移除了它，”他们写道，“我们就不再需要将需求转化为符合 LangChain 规范的方案。我们可以直接编码。”

他们并不孤单。大约 45% 尝试使用高层级 LLM 编排框架的开发者从未将其部署到生产环境。另有 23% 的开发者在上线后最终将其移除。这些数字并不意味着框架是糟糕的工具——它们意味着框架是具有特定有用范围的工具，而那个范围比演示中展示的要窄。

当单智能体（single-agent）系统在研究任务中失败时，人们的直觉是增加更多内存、更好的工具或更强大的模型。但在某些点上，问题不在于能力——而在于并发性（concurrency）。深度研究任务需要同时推进多个线程：从不同角度验证论点、跨领域扫描来源、实时交叉引用发现。单智能体按顺序执行这些操作，就像研究人员在做笔记之前先逐本阅读每一本书。回想起来，多智能体（multi-agent）的替代方案似乎显而易见，但在生产环境中正确实现它比架构图所示的要困难得多。

这篇文章讨论了多智能体研究系统是如何实际构建的——行之有效的架构选择、在生产环境中才显现的故障模式，以及在大规模应用中保持其有用性所需的工程纪律。

当团队从单智能体系统转向多智能体 AI 系统时，一个模式会反复出现：单个智能体在独立运行时表现完美，但系统作为一个整体却表现得难以预测。问题不在于智能体本身，而在于它们之间的边界。

针对生产环境多智能体部署的研究表明，在缺乏正式编排的情况下，失败率在 41% 到 86.7% 之间。最常见的复盘结果并非“LLM 给出了错误的答案”，而是“错误的上下文在错误的时间传达给了错误的智能体”。智能体之间的接缝正是系统悄然崩塌的地方。

一家公司交付了 7,949 个 AI Agent。其中只有 15% 能够正常工作。其余的要么静默失败，要么陷入死循环，或者在执行任务中途前后矛盾。这并非个别现象——企业级分析一致发现，88% 的 AI Agent 项目从未进入生产阶段，95% 的生成式 AI 试点项目以失败告终或表现严重不及预期。引人入胜的演示 (Demo) 与可靠系统之间的差距并非模型问题，而是架构问题。

那些成功交付了实际可用 Agent 的工程师们，在架构决策上达成了一系列共识，而这些决策与框架教程中的玩具示例截然不同。本文将探讨这些决策：层级如何划分、故障集中在哪里，以及为什么最难的问题从来不是提示词 (Prompt)。