多 Agent 协作 | Agent 与 Skill | 做产品

多 Agent 协作

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

你会遇到的现象

• 看到演示里的「多 Agent 系统」很炫，想直接照搬

• 单 Agent 做一件事，上下文动不动就爆

• 拆成多个之后，调试时根本说不清是哪个环节出的错

为什么要拆

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

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

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

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

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

三种拆法

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

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

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

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

三种拆法可以混用，但每种都有自己那笔账

主从

主管

执行 执行 执行

流水线

A B C

对等

方案 A 方案 B 方案 C

汇总

任务可切块 每步角色单一，好评测 多方案里挑最优

主管成了新的单点 总时延是各步之和 谁来判、按什么判

拆之前先确认这一条 「最终谁对结果负责」——没有明确的负责人，多 Agent 就是一群人在没主持人的会议室里开会。 也别一次拆成五个：先把最吃窗口的那一步拎出来，验证收益再继续。

三种拓扑解决的是不同的痛：主从治「任务要统一把控」，流水线治「角色互相干扰」，对等治「需要并行」。单 Agent 没在这三处出问题，拆就只是纯成本。

成本涨在哪

拆的账，主要在这四处：

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

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

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

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

该不该拆

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

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

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

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

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

Agent 循环 多 Agent 里的每一个，底下都是一个循环。

上下文窗口 拆最主要就是拆窗口——先搞清楚窗口为什么不够。

提示词的分层 每个 Agent 的「角色」要靠分层提示词固定住。