多智能体编排（Multi-Agent Orchestration）最近很热。它指的是让多个专门化的AI代理协同解决复杂问题，比如一个负责检测、一个负责分析、一个负责行动。但热不代表成熟。

斯坦福大学系统智能实验室（Stanford Systems Intelligence Lab）刚发了一篇综述，把多代理编排的各种架构、权衡和设计模式系统梳理了一遍。作者是Daniel Hsu, Mira Venkataraman, Alexei Petrov。monokern转推时评价：This paper is f*cking genius。

这篇综述覆盖了Router、Planner-Worker、Supervisor、Hierarchical等主流架构，并拆解了核心编排循环：Intake、Plan、Execute、Merge、Evaluate。还重点讨论了共享状态工程。它给了一张全景图，让开发者能看清每个架构背后的系统级权衡。下图是论文截图，包含高层次编排架构图和编排生命周期。


但真正让很多开发者有共鸣的，可能是另一篇实操文章。monokern在X上发了一篇长文，标题是《Why Multi-Agent Pipelines Fail for Complex Analytics (And Control Plane Pattern That Replaces Them)》。文章用ZS Associates在制药商业分析中的真实案例，解释了为什么多代理流水线看着合理，一上线就废。

案例里的工作流是典型的四步：信号检测、源定位、驱动归因、综合预测。传统做法是给每一步配一个专用Agent，再用一个编排Agent串起来。看起来像把人工作业流程自动化，但实际跑起来问题全出来了。文章指出三个核心缺陷：

第一，用LLM做统计任务。让模型扫描原始数据表找异常，等于让文科生做精算。LLM会漏掉真正的异常，甚至把噪声当信号。

第二，上下文交接衰减。每传一次手，前面发现的权重和细节就丢一层。比如归因Agent已经查明处方量下降是因为医保支付方把药品调到了更低覆盖层级，但传到综合Agent那里，这个关键信息已经丢失，最后建议派更多销售代表去拜访医生——和实际问题完全脱节。

第三，缺少领域关系。Agent们直接对着原始数据库表操作，没有共享的业务逻辑和实体关系知识，只能临时猜表之间的关系，结果就是无效连接和虚假因果。

monokern算了一笔账：四个Agent各吃10k tokens上下文，跑一次诊断就是几十万token，成本高，准确率还低。更糟的是，Agent A传给Agent B的摘要会把统计置信区间和驱动权重等关键量化证据剥掉，下游根本没法做准确判断。

他给出的解法绕开了Prompt拓扑，也绕开了模型档次，核心是干掉分布式推理。具体是三根支柱：

1. 确定性信号队列。信号检测彻底移出LLM，用纯统计方法（移动平均、Z-score、趋势突变算法）在数据仓库上跑批处理，只有触发阈值才生成结构化信号事件进入执行队列。模型只在有数学证据时被唤醒，不再负责“找问题”。

2. 集中式推理所有权。一个主Agent独占整个诊断生命周期，所有上下文、SQL查询、中间发现都保持在同一个上下文窗口里。为了并行，可以启动动态子Agent做窄的、隔离的数据抓取任务，但它们只能返回原始事实，不拥有判断权。判断和结论只属于主Agent。

3. 知识图谱控制平面。领域专家把实体（地区、支付方、销售账户、品牌）和它们与核心KPI的关系（TRX、准入层级变化、代表互动率）建成知识图谱。这个图谱就是控制面，不是被动的查表工具。Agent被严格限制只能沿着图谱边遍历来生成假设和验证路径，不能发明关系，不能瞎查表。

这样，当信号到达时，主Agent沿着知识图谱做受限调查循环：查询邻居节点、通过边生成假设、用SQL验证证据、通过或剪枝、继续深入。整个循环可以跑50多个执行步，直到根因被数据证据固定。最终的行动方案会直接指向支付方合同团队，而不是派销售代表。

文章还列出几个常见失败模式：把知识图谱当被动查表、让LLM做统计检测、跨Agent分配判断权、无界假设遍历。每个都给了具体修复方法。如果本周就想改，他建议分三阶段：先拆信号层，把扫描数据的Prompt全删掉，换成确定性脚本；再画知识图谱控制面；最后集中Agent循环。

这篇综述和实操文章放在一起，指向同一个事实：多代理堆得越多，并不代表越智能。瓶颈在上下文所有权和推理边界。与其搭复杂流水线，不如让确定性系统干脏活，让一个Agent在明确边界内做判断。

有网友在回复里说，这些系统还需要更多时间学习。也有人认为，算法化Agent状态机比单一集中推理更强，还贴了自己的开源项目。众说纷纭，但至少这篇综述提供了一个讨论的基准。