多 Agent 协作

「我们用多个 Agent 分工协作」听起来很先进。但多 Agent 不是一种更高级的模式，是一笔有明确代价的账——拆对了解决问题，拆错了只是把一个难题拆成四个难题。

为什么要拆

拆，是为了解决单 Agent 的三个具体毛病，缺一不可：

一、上下文装不下。单 Agent 的全部记忆都在上下文窗口里。任务太长，中间必然被挤掉。拆成多个，每个只管一小段，各用各的窗口，问题绕开。

二、一件事的「角色」互相干扰。既要点子多又要严谨抠细节，一个模型同一轮里两头兼顾会互相拖累。拆开后，一个负责发散、一个负责收敛，各带各的角色提示。

三、需要并行或隔离。几件独立的事同时做；或者某一步用到的权限不该让整个流程共享。

反过来想：如果单 Agent 没在这三处遇到问题，拆就只是纯成本。

三种拆法

主从。一个「主管」Agent 负责理解目标、拆任务、派活，几个「执行」Agent 各干一块，结果回报给主管汇总决策。适合任务可以明显切块、且需要统一把控的场景。代价是主管成了新的瓶颈和单点。

流水线。严格按顺序：A 的输出原样交给 B，B 的输出交给 C。每步角色单一、可单独评测、好排查。代价是慢——整条链的时间等于各步之和，且一步卡住全链卡住。

对等。几个 Agent 各做各的独立任务，最后汇总比较。适合「多方案生成后挑最优」这类场景，天然能并行。代价是汇总这一步谁来判、按什么标准判，往往没想清楚。

三种模式可以混用。关键是先想清楚「最终谁对结果负责」——没有明确的负责人，多 Agent 就是一群人在一个没主持人的会议室里开会。

成本涨在哪

拆的账，主要在这四处：

一、上下文来回传。主管要把任务背景复制给执行者，执行者要把结果传回给主管。这些内容反复进出计费的输入。拆成 N 个，总 Token 往往比单 Agent 高出数倍。

二、决策谁来下。每个 Agent 都只看到局部信息，谁有权做全局判断？判断错了，算谁的？这层要想清楚，否则就是甩锅。

三、失败归因变难。最终结果错了，是任务理解错了、某个执行者做错了、还是传递过程中丢了信息？排查面从一个环节变成一条链。

四、延迟叠加。串行链路的总时延是各步之和，用户等的就是总和。交互式场景里，多 Agent 常常比单 Agent 明显更慢。

该不该拆

给一个可操作的判断顺序：

第一步，先优化单 Agent。换更好的提示词分层、把上下文压缩做好、把工具说明写清楚。多数「单 Agent 不够用」其实只是单 Agent 没做好。

第二步，确认拆能解决具体问题。是窗口爆了？是角色冲突？是必须并行？能说清「不拆就做不成」，才具备拆的前提。

第三步，先拆最痛的那一步。别一次拆成五个。把最吃窗口、最需要隔离的那一步拎出来独立成 Agent，其余保持原样，验证收益再继续。

最后一条纪律：每隔一段时间问自己「现在能拆回去吗」。工具、模型、提示词都在进步。今天必须靠多 Agent 才能绕开的限制，半年后也许单 Agent 就够用了。多 Agent 是手段，不是目的。