实践者视角：AI 智能体系统的三种构建路径

在生产环境中真正可用的 AI 智能体系统，几乎都收敛到三种架构形态上：串行链条、并行图，以及事件驱动的运行时。一名长期搭建智能体系统的工程师在博客中给出这一分类，并用自己的真实事故说明：多数团队并不是主动选择，而是被所用框架「默认」带上某条路径，撞到天花板后才意识到还有别的走法。

路径一：智能体瀑布（Agentic Waterfall）

最直觉的写法是一条链：Agent A 做分析，把结果交给 Agent B 推理，再交给 Agent C 写成最终输出。绝大多数框架教程画出来的就是这种形状，因为它最容易画。

这种架构的真正问题不是「简单」，而是依赖链变成了系统架构本身。每加一种能力，就要多一次交接、多一段等待、多一个失败点。插入评审者？下游一切都要等它；插入调研者？又是一个新的串行节点。

在生产账单上，这种模式会带来四类成本：

• 执行时间：每次交接都是同步屏障，系统总耗时 = 各环节耗时之和。
• Token 浪费：上下文每过一站就要被重新拉取、重新解释，因为每个 agent 都从冷启动开始。
• 僵化：加一个 agent 要重画整张顺序图，组织结构被焊进代码里。
• 脆弱的恢复：流程中一旦出现意外情况，没有合适的地方承接新知识，只能「抛掉、重来」。

对于规模小、目标明确、线性可拆的工作，瀑布并不算错；只要任务不再线性、开始变得「有意思」，它就会失灵。

路径二：并行图（Parallel Graph）

顺理成章的改进是扇出（fan-out）：让后端 agent、前端 agent、测试 agent 同时跑，再把结果合并、继续往下走。这就是 DAG 工作流、扇出/扇入模式——可以理解为「多了几步的 Promise.all」。

它确实带来显著收益，也是大多数成熟团队当前停留的地方，原因藏在一个不容易说清的属性里：分支是并行的，但系统并不是。

在一条分支内部发生的事，无法在合并点之前影响它的兄弟分支。唯一能沟通的通道是末尾的 join。一个测试 agent 在第 10 秒就发现了致命问题，但没有任何方式告诉后端 agent「别再浪费 token 了」——它们只会在屏障处碰面，届时钱已经花出去了。

而且并行图必须在工作开始之前就画好。任务可以预测时这没问题；任务是在执行过程中才被发现——而这恰恰是 agent 存在的意义——并行图就会失效。

路径三：事件驱动集体（Event-Driven Collective）

第三种路径放弃了对执行路径的建模，转而去建模「agent 工作的环境」。Agent 成为共享运行时的参与者：它们发出语义事件（「S1 已合并」「校验失败」「我发现了计划之外的工作」），并订阅自己关心的内容。没有人向任何人交接。系统只在真正需要等待的地方等待：某个故事确实需要另一个故事的文件，就等那次合并；其余一切都在流动。

协调逻辑不再是硬编码进工作流里的分支，而是关于「情境」的规则：用户消息到达且有空闲容量时，再去跑推理。预算、失败、意外都被提炼成可复用的系统规则，而不是散落在图里的特例。

更准确的心智模型是操作系统同时跑很多程序——不是一个步骤图，而是一个工作真正发生的地方。

一个 planner 「中途死亡」的案例

作者之所以此时写这篇文章，是因为他们自己的 agent 刚刚踩到了第三种模式的边界。

他们的 agent 系统名为 baro，由一群协作的编码 agent 组成。执行层已经按「事件驱动集体」的方式跑了几个月：并发运行、互相交换事件、在工作的同时感知彼此的合并。但 planner——负责把目标拆解为故事的那个 agent——架构上仍是一个「瀑布公民」：一个独立进程，挂在单向管道末端，只往下游发布计划片段，听不到任何回响。

由此产生两类被实际测量到的成本：

• 脆弱的恢复代价：因为 planner 在运行时之外，宿主只能用一种方式监督黑箱——墙钟超时。某次高效规划进行到第 8 分钟、刚刚发布了一个片段——本是最明确的「我还活着」的信号——看门狗却把它杀了。同样的超时阈值此前已经为同一个原因上调过一次，代码注释里坦然承认了这一点。这正是「脆弱恢复」从内部看到的样子：当一个组件没法告诉你它还活着，你只能猜，而每一次猜终会杀掉一个无辜者。
• 沟通代价：planner 的发布调用返回的回执，是它自己进程算出来的——一种礼貌的本地回声，并非运行时真正的接纳。当宿主按超时策略进行剪枝……

作者由此得出结论：只要一个组件仍处在第一种模式里，它就会成为整个系统的瓶颈与故障源；真正可用的多 agent 系统，必须把每一类角色都放进同一套事件驱动的运行时。