14 子 Agent 与编排

为什么要拆

回想上下文工程那章:窗口太满会让我变笨(context rot)。一个长任务跑下来,我的窗口塞满了各种中间产物,后期越来越糊。多智能体的第一个动机就是让每个 Agent 的上下文保持干净:与其一个我啃到底、窗口越来越乱,不如把任务拆给几个各自上下文清爽的子 Agent。

第二个动机是并行:如果任务能拆成互不依赖的几块(同时调研三个竞品、同时读五个文件),让子 Agent 并行跑,墙钟时间大幅缩短。第三个动机是专业分工:一个负责研究、一个负责写作、一个负责审校,各司其职,每个都在自己擅长的窄任务上表现更好。

三种拓扑

1. 单体(Monolithic)

就一个我,一个循环啃到底。上下文最连贯、最省 token(没有跨 Agent 的信息重述),但长任务里容易目标漂移、后期被历史淹没。大多数任务的正确默认。

2. 流水线(串行子 Agent)

把任务拆成几棒接力:研究者 → 写作者 → 审校者,前一个的产出交给后一个。每棒上下文干净、聚焦。代价是总 token 略增(交接时要重述上下文),而且是串行的,不省时间——省的是每一步的清晰度。

3. 主管 + 并行子 Agent(Orchestrator-Worker)

一个主管 Agent 把任务拆成几份,派给多个子 Agent并行调查,再把结果汇总。墙钟时间最短(并行),但 token 成本会数倍暴涨——每个子 Agent 都有自己的完整上下文、自己的循环。只有当任务真能并行、且值这个价时才用。

编排拓扑成本对比DEMO

玩一下上面的对比:切换三种拓扑,看步数、并行度、token 成本怎么此消彼长。你会发现没有免费的午餐——并行度上去了,token 成本也跟着窜。多智能体的本质,就是拿 token 换专注度和时间。这笔交易划不划算,完全取决于任务。

Android 类比

这几乎就是并发模型的取舍。单体 = 单线程顺序执行,简单、无同步开销,但慢。流水线 = 责任链模式,每个 handler 干一段。主管+并行 = 开一个线程池 fan-out 一堆任务再 join——快,但每个线程都有自己的栈和资源开销,而且你还得处理协调与合并。你在 Android 上不会为了打印个日志就开线程池;同理,别为了一个简单任务就上多智能体。

那个必须先问的问题:真能并行吗?

多智能体最常见的误用,是给一个本质上串行的任务硬套并行编排。判断一个任务能不能从多智能体受益,先问:这几步真的互不依赖、能同时做吗?

「同时调研 4 个不同的竞品,最后汇总」——能并行,主管+并行合适。
「先设计数据库,再基于它写 API,再基于 API 写前端」——强依赖,并行没意义,老老实实串行。

如果步骤之间层层依赖,并行只会增加协调成本而没有收益。经验法则:能一个循环解决就别拆;要拆,先确认能并行。

子 Agent 的一个高价值用法:独立验证

上一章埋的伏笔:让一个上下文干净的子 Agent 来验证主 Agent 的成果,往往比主 Agent 自查更靠谱。因为主 Agent 对自己一路做下来的产出有「灯下黑」——它带着做题时的假设,不容易发现自己的错。而一个全新的验证者,以旁观者的清白视角审查,更容易揪出问题。这是多智能体不为了并行、纯为了质量的一种用法,很值得记住。

⚠ 坑

「多智能体」被严重过度使用——很多项目一上来就搞五个 Agent 互相喊话,结果 token 烧光、协调混乱、还不如一个 Agent 干得好。新一代模型甚至默认会克制地少拆(它知道拆是有代价的)。请把多智能体当成一件重型武器:先默认单体,只有当你明确遇到「上下文塞不下」「必须并行提速」「需要独立视角验证」这些具体信号时,才动它。hackathon 上尤其别炫技——评委见过太多华而不实的多 Agent 编排。

◉ Agent 自白

当我派出子 Agent 时,发生的事其实是:我为每个子任务开一个「新的我」,给它一段干净的上下文和一个明确的小目标,让它跑完把结果交回来。这些子 Agent 之间不共享我的记忆和思路——它们只知道我交代给它们的那点。所以用多智能体最容易犯的错,是误以为它们心有灵犀:如果我要子 Agent 做某件事,我必须在派它的那句话里把该说的全说清楚,不能指望它「懂我」。它就是一张白纸带着一个任务上路。到这里,卷三「心智」讲完了——上下文、记忆、检索、规划、多智能体,这五样决定了我聪不聪明。但聪明的 Demo 和可靠的产品,中间隔着一条鸿沟。接下来卷四「修行」,就是过这条河:评估、失败模式、安全、成本。这是把玩具变成工具的地方。