多代理协作系统设计：从agency-agents看任务分解与调度架构

1. 从“agency-agents”这个名字说起：它到底想解决什么问题

第一次看到agency-agents这个项目名，我的直觉是：这大概率是一个围绕“代理（agent）”概念构建的框架或工具集，而且“agency”这个词放在前面，暗示它强调的不是单个 agent 的能力，而是多个 agent 之间的协作关系、组织形态，或者说“代理机构”式的运作模式。换句话说，它想做的可能不是“一个更聪明的 agent”，而是“一群 agent 如何像一个团队一样干活”。

这个判断来自我过去几年在自动化工作流和多智能体系统里踩过的坑。单 agent 的场景其实相对好做——给它一个目标、一套工具、一个循环，它就能跑起来。但一旦涉及多 agent，问题就成倍放大：谁来决定任务怎么分？agent 之间怎么传递上下文？一个 agent 卡住了谁来兜底？多个 agent 同时改同一份数据怎么办？这些问题的本质不是模型能力问题，而是协作架构问题。agency-agents这个名字里的“agency”恰好指向的就是这一层——它关心的应该是“代理组织”的运转机制，而不是单个代理的推理能力。

从关键词和摘要描述为空这一点来看，这个项目可能还处于早期阶段，或者它的定位更偏向于一个概念验证、一个架构实验，而不是一个已经包装得很完整的商业产品。这反而给了我更多空间去从“一个合格从业者会怎么设计这类系统”的角度，把它的核心逻辑、技术选型、实操要点和避坑经验补全出来。

这篇文章适合几类人看：一是正在做多 agent 编排、想找一套可参考的协作模式的开发者；二是对 agent 系统感兴趣、但还没想清楚“多 agent 到底比单 agent 强在哪”的技术决策者；三是已经动手写过 agent、但在任务分发和状态同步上反复踩坑的实践者。我会尽量把“为什么这样设计”讲透，而不是只丢一堆代码和配置。

提示：本文中涉及的具体实现细节，部分是基于该类系统常见实践做的合理推演，并非对某个特定代码库的逐行解读。你在实际使用时，应以项目实际文档和源码为准。

2. 多代理协作的核心矛盾：为什么“多”不一定比“单”好

2.1 单代理的天花板在哪里

先说说单 agent 为什么会在某些场景下不够用。一个典型的单 agent 系统，本质上是一个“感知—决策—行动”的循环：它读取当前状态，决定下一步做什么，调用工具执行，然后观察结果，继续循环。这个模式在任务边界清晰、步骤线性、上下文可控的场景下非常有效。比如“帮我查一下某个数据并生成一份摘要”，单 agent 完全能胜任。

但一旦任务变成“帮我调研三个方向，分别产出报告，再综合成一份决策建议”，单 agent 就会开始吃力。原因有三：第一，上下文窗口是有限的，三个方向的调研资料堆在一起，很容易把关键信息挤掉；第二，单 agent 的“注意力”是串行的，它很难同时维护多条独立的工作线；第三，也是最关键的，单 agent 没有“分工”的概念，它不会主动说“这部分我不擅长，交给另一个更合适的角色来做”。

这就是多 agent 系统要解决的核心问题：把一个大任务拆成多个子任务，让不同的 agent 各自负责自己擅长的部分，最后再汇总。听起来很合理，但真正动手做的时候，你会发现“拆”和“合”这两件事本身就非常难。

2.2 多代理带来的三个新问题

第一个问题是任务分解的粒度。拆得太粗，等于没拆，每个 agent 还是面对一个模糊的大目标；拆得太细，agent 之间的通信开销会爆炸，而且很容易出现“每个 agent 都只看到自己那一小块，没人对整体负责”的局面。我在实际项目里试过一种做法：先用一个“规划 agent”把任务拆成若干步骤，每个步骤标注输入、输出和验收标准，然后再分配给执行 agent。这个做法的问题是，规划 agent 本身的能力决定了整个系统的上限——如果它拆错了，后面全错。

第二个问题是上下文传递。agent A 产出的结果，怎么让 agent B 准确理解？直接传原始文本，B 可能抓不住重点；传摘要，摘要过程本身可能丢信息；传结构化数据，又需要提前定义好 schema。我见过一种比较稳妥的做法是“双层传递”：一层是结构化的关键字段（比如任务 ID、状态、产出物路径），另一层是自然语言的简要说明。结构化字段保证机器可解析，自然语言说明保证语义不丢失。

第三个问题是冲突与回滚。多个 agent 并行工作时，很可能出现两个 agent 对同一份资源做出不一致的修改。比如一个 agent 在更新配置文件，另一个 agent 同时在读取它，读到的就是中间状态。这类问题在单 agent 场景下几乎不会出现，但在多 agent 场景下是常态。常见的应对策略包括：给共享资源加锁、用版本号做乐观并发控制、或者干脆让所有写操作都通过一个“协调 agent”串行化。

2.3 “agency”这个词暗示的组织形态

回到项目名。agency-agents里的“agency”如果理解成“代理机构”，那它暗示的组织形态可能更接近“一个由多个专业角色组成的团队”，而不是“一堆同质化的 worker”。这两者的区别很大：同质化 worker 的调度逻辑是“谁空闲谁上”，而专业角色团队的调度逻辑是“这个任务需要什么能力，就找具备该能力的角色”。

如果按后者来设计，系统里至少需要几类不同的 agent：规划者（负责拆解任务）、执行者（负责具体操作）、审查者（负责检查产出质量）、协调者（负责处理冲突和汇总）。这四类角色的职责边界、通信协议、失败处理策略都不一样，不能用一个通用的 agent 模板套到底。

3. 拆解 agency-agents 的架构骨架：从角色定义到消息流转

3.1 角色定义层：每个 agent 的“岗位说明书”

在一个多 agent 系统里，角色定义是最先要确定的东西。我习惯把它类比成公司的岗位说明书：这个岗位负责什么、需要什么技能、向谁汇报、产出什么交付物。对应到 agent 上，就是几个关键字段：

这张表看起来简单，但实际设计时有几个容易忽略的点。第一，capabilities不要写得太泛，比如“擅长处理任务”这种描述等于没写，要具体到“能把自然语言目标拆成带依赖关系的步骤列表”。第二，input_schema和output_schema最好用可校验的格式（比如 JSON Schema），这样在 agent 之间传递数据时能提前发现格式错误，而不是等到执行到一半才报错。第三，timeout和max_retries要根据角色的实际行为来定，规划类 agent 通常比执行类 agent 需要更长的思考时间。

3.2 消息总线：agent 之间怎么“说话”

角色定义好之后，下一个问题就是 agent 之间怎么通信。最直接的做法是让 agent 直接调用另一个 agent 的函数，但这会带来强耦合——A 要知道 B 的存在和接口，B 改了接口 A 就得跟着改。更常见的做法是引入一个消息总线（message bus），所有 agent 都只跟总线打交道，不直接互相调用。

消息总线的核心是一个“发布—订阅”模型：agent 把消息发到某个主题（topic），关心这个主题的 agent 订阅并消费。这样做的好处是解耦，坏处是调试变难了——你很难一眼看出“这条消息到底被谁消费了、处理结果是什么”。我的经验是，在开发阶段一定要给消息总线加详细的日志，记录每条消息的发送者、接收者、时间戳和 payload 摘要。没有这层日志，多 agent 系统出问题基本没法排查。

消息的格式也值得说道。我倾向于把消息分成三类：任务消息（我要你做什么）、结果消息（我做完了，这是产出）、状态消息（我当前在干什么、进度如何）。任务消息和结果消息是必须的，状态消息则看系统复杂度——如果 agent 数量少、任务链路短，状态消息可以省；但如果 agent 多、链路长，没有状态消息你就不知道整个系统卡在哪一环。

3.3 调度器：谁来决定下一个该谁干活

调度器是多 agent 系统里最容易被低估的组件。很多人一开始会觉得“调度嘛，不就是轮询或者队列”，但实际做起来会发现，调度策略直接决定了系统的吞吐量和稳定性。

最简单的调度是 FIFO 队列：任务按到达顺序排队，有空闲 agent 就分配。这个策略实现简单，但在任务异构的场景下效率很低——一个需要复杂推理的任务和一个简单的格式转换任务排在同一个队列里，后面的任务可能被前面的长任务堵住。改进的做法是按任务类型分队列，不同类型的任务走不同的队列，每个队列独立调度。

更进一步的调度策略是“能力匹配”：调度器维护每个 agent 的能力标签和当前负载，新任务进来时，先看哪些 agent 具备所需能力，再从中选负载最低的。这个策略听起来更合理，但实现复杂度也更高，而且需要解决“能力标签怎么维护、负载怎么度量”的问题。我的建议是，如果系统规模不大（agent 数量在 10 个以内），用简单的分队列策略就够了；规模再大，再考虑能力匹配。

3.4 状态存储：任务执行到哪一步了

多 agent 系统必须有一个地方记录“每个任务当前处于什么状态”。这个状态存储可以是内存里的一个字典，也可以是数据库里的一张表，但不管用什么，关键是要保证状态更新是原子的。我见过一个典型的 bug：agent A 完成了任务，把状态从“进行中”改成“已完成”，但在改之前 agent B 刚好读取了状态，读到的还是“进行中”，于是 B 又触发了一次重复执行。

解决这个问题的常见做法是用乐观锁：每次更新状态时带上版本号，更新时检查版本号是否一致，不一致就重试。或者更简单粗暴一点，所有状态更新都通过一个单线程的“状态管理 agent”来做，虽然牺牲了一点并发度，但换来了确定性。

状态存储里除了任务状态，还应该记录执行历史：谁在什么时候做了什么、产出了什么、耗时多久。这些历史数据在排查问题时非常有用，也是后续做性能优化的依据。

4. 实操中真正会卡住你的几个地方

4.1 上下文膨胀：为什么你的 agent 越跑越慢

多 agent 系统跑着跑着变慢，最常见的原因就是上下文膨胀。每个 agent 在执行时，往往需要把之前的相关消息都带上作为上下文，如果消息总线不做清理，这个上下文会越滚越大。我实测过一个场景：一个任务链路跑了 20 步之后，单个 agent 的输入上下文已经膨胀到几万 token，不仅慢，而且贵。

应对策略有几个。一是定期压缩：把历史消息做摘要，只保留关键决策和产出物引用，丢弃中间的冗余对话。二是分层上下文：每个 agent 只拿自己需要的上下文，而不是全量上下文。比如执行 agent 只需要知道“我的任务是什么、上游给了我什么输入”，不需要知道整个系统的所有历史。三是设置硬上限：给每个 agent 的上下文设一个 token 上限，超过就触发压缩或截断。

注意：上下文压缩本身也可能丢信息，所以压缩策略要跟任务类型匹配。对于需要精确回溯的任务（比如代码修改），压缩时要保留完整的变更记录；对于探索性任务，可以压缩得更激进一些。

4.2 死循环与活锁：agent 之间互相等待

多 agent 系统里另一种常见的卡死是“活锁”：agent A 在等 agent B 的输出，agent B 在等 agent A 的输入，两边都不动。这种情况在任务依赖关系设计不当时很容易出现。比如规划 agent 把任务拆成“先做 X 再做 Y”，但执行 agent 理解成了“X 和 Y 可以并行”，于是两个执行 agent 互相等对方的中间结果。

排查这类问题的关键是把依赖关系显式化。任务拆解时，每个步骤都要标注它依赖哪些前置步骤，调度器在执行前检查依赖是否满足。如果依赖关系是环形的，调度器应该直接报错，而不是让 agent 去猜。另外，给每个任务加一个“最长等待时间”，超时后自动标记为失败并触发告警，避免系统无限期挂起。

4.3 产出质量不稳定：审查环节不能省

多 agent 系统的一个优势是可以引入“审查者”角色，但很多人为了省事会跳过这一步，直接让执行 agent 的产出进入下一步。我踩过的坑是：执行 agent 在大多数情况下产出是合格的，但偶尔会漏掉关键字段或者格式不对，这些错误在后续步骤里被放大，最后导致整个任务失败。

引入审查 agent 之后，情况会好很多，但审查 agent 本身也需要设计好。审查标准要具体，不能只说“检查质量”，而要说“检查输出是否包含 A、B、C 三个字段，字段类型是否正确，数值是否在合理范围内”。审查不通过时，是把任务打回给原 agent 重做，还是交给另一个 agent 修复，也要提前定好策略。我的经验是，简单错误打回重做，复杂错误交给修复 agent，因为原 agent 很可能“不知道自己错在哪”。

4.4 日志与可观测性：出问题时你怎么知道发生了什么

多 agent 系统的调试难度远高于单 agent，因为问题可能出在任何一个 agent、任何一次消息传递、任何一个状态更新上。没有好的可观测性，排查基本靠猜。

我建议至少记录以下几类信息：每个 agent 的每次执行（输入、输出、耗时、状态）、每条消息的流转（发送者、接收者、时间、payload 摘要）、每次状态变更（旧状态、新状态、触发者）。这些日志最好能用一个统一的 trace ID 串起来，这样你可以顺着一个任务从头看到尾。如果系统规模再大一点，可以考虑接入分布式的追踪工具，把 agent 执行做成 span，直观看到时间花在哪。

5. 从零搭一个最小可用的多代理协作原型

5.1 先定协议，再写代码

很多人一上来就写 agent 的实现，结果写到一半发现 agent 之间对不齐。我的建议是先把通信协议定下来，哪怕只是几个 JSON 示例。协议里至少要明确：任务消息长什么样、结果消息长什么样、错误消息长什么样、状态更新长什么样。定好之后，所有 agent 都按这个协议来，谁不遵守就是谁的 bug。

一个简化的任务消息可以长这样：

{ "trace_id": "t-001", "task_id": "task-001", "from": "planner", "to": "executor", "type": "task", "payload": { "action": "generate_report", "inputs": {"topic": "xxx", "sources": ["src-1", "src-2"]}, "deadline": 120 } }

结果消息则带上产出物和状态：

{ "trace_id": "t-001", "task_id": "task-001", "from": "executor", "to": "reviewer", "type": "result", "payload": { "status": "success", "output_ref": "artifact-001", "summary": "报告已生成，包含三个章节" } }

5.2 用最笨的方式跑通第一条链路

协议定好之后，不要急着做通用调度器，先用最笨的方式跑通一条链路：手动把任务从 planner 传给 executor，再把结果传给 reviewer，最后汇总。这个过程中你会很快发现协议里缺了什么字段、哪些状态没考虑到。等这条链路跑顺了，再把手动传递换成消息总线，把硬编码的流程换成调度器。

这个“先手动后自动”的顺序很重要。我见过太多项目一上来就搭大框架，结果框架搭好了，发现 agent 之间的协议根本对不上，又得回头改。先用最笨的方式验证核心逻辑，再逐步抽象，是更稳妥的路径。

5.3 给每个 agent 加“自检”能力

agent 在执行任务前，最好先做一次自检：我收到的输入是否完整？我是否具备完成任务所需的能力？如果答案是否定的，直接返回错误，而不是硬着头皮往下做。这个自检逻辑看起来简单，但能避免很多“垃圾进垃圾出”的问题。

自检的内容可以包括：必填字段是否缺失、输入格式是否符合 schema、依赖的资源是否可用。如果自检不通过，agent 应该返回一个明确的错误消息，说明缺什么、需要谁补，而不是返回一个模糊的“执行失败”。

5.4 用真实任务做压力测试

原型跑通之后，一定要用真实任务做压力测试。我一般会准备三类任务：简单任务（单步可完成）、中等任务（需要 3-5 步协作）、复杂任务（需要 10 步以上、涉及多个 agent 角色）。然后观察系统在不同负载下的表现：响应时间、失败率、资源占用。

压力测试中最容易暴露的问题是资源竞争。比如多个 agent 同时读写同一个文件、同时调用同一个外部接口，很容易触发限流或数据不一致。这时候就需要回头检查共享资源的访问策略，该加锁的加锁，该排队的排队。

6. 几个值得提前想清楚的取舍

6.1 集中式调度还是去中心化协商

集中式调度就是有一个“大脑”统一分配任务，去中心化协商则是 agent 之间自己商量谁来做。集中式的好处是逻辑清晰、容易调试，坏处是调度器可能成为瓶颈和单点故障。去中心化的好处是扩展性好，坏处是行为难以预测，出了问题很难定位。

我的建议是，除非你有非常明确的扩展性需求，否则优先选集中式。多 agent 系统本身的复杂度已经够高了，再叠加去中心化的不确定性，调试成本会高到难以承受。等系统稳定运行、瓶颈确实出现在调度器上时，再考虑拆分。

6.2 同步等待还是异步回调

agent A 把任务发给 agent B 之后，是原地等 B 的结果，还是先去做别的、等 B 完成了再通知？同步等待实现简单，但会浪费 A 的时间；异步回调效率高，但需要处理“B 失败了怎么办”“B 超时了怎么办”这些边界情况。

实际项目中，我倾向于对短任务用同步等待（比如 30 秒内能完成的），对长任务用异步回调。判断标准是任务的预期耗时和 agent 的时间成本。如果一个 agent 等待一分钟的成本远低于它去做其他事情带来的收益，那就同步等；反之则异步。

6.3 通用 agent 还是专用 agent

通用 agent 就是一个 agent 什么都能干，专用 agent 是每个 agent 只干一件事。通用 agent 的好处是数量少、管理简单，坏处是能力不聚焦、容易在复杂任务上表现不稳定。专用 agent 的好处是每个角色都能针对性优化，坏处是数量多、协调成本高。

我的经验是，在系统早期用少量通用 agent 快速验证，等流程稳定后再逐步拆成专用 agent。不要一上来就设计十几个角色，那样你会在协调逻辑上花掉大部分时间，而不是在核心能力上。

7. 我在实际搭建中总结的几条经验

第一条经验是：先把单 agent 跑稳，再考虑多 agent。很多多 agent 系统的问题，其实根源在于单 agent 本身就不稳定。如果单个 agent 在给定任务上的成功率只有 70%，那三个 agent 串起来的成功率可能只有 30% 多。先把单 agent 的成功率提到 90% 以上，再去做协作，会省很多事。

第二条经验是：消息格式宁严勿宽。我一开始为了灵活，消息里很多字段都是可选的，结果 agent 之间经常因为字段缺失而出现难以排查的错误。后来改成必填字段严格校验、可选字段显式标注默认值，问题少了一大半。

第三条经验是：给每个 agent 设“熔断”机制。如果一个 agent 连续失败超过阈值，就暂时把它从可用列表里摘掉，避免它继续拖累整个系统。等过一段时间或者人工介入修复后，再重新加入。这个机制在多 agent 系统里特别重要，因为一个坏掉的 agent 可能会不断接收任务、不断失败，把整个队列堵死。

第四条经验是：不要追求一步到位。多 agent 系统的设计空间很大，你不可能一开始就设计出最优解。更现实的做法是先跑通一个最小闭环，然后在真实使用中不断调整角色划分、调度策略和通信协议。我自己的系统迭代了五六轮之后，才慢慢稳定下来。

最后说一个容易被忽略的点：文档和注释。多 agent 系统的逻辑分散在多个 agent、多个消息类型、多个状态转换里，如果没有清晰的文档，过两周你自己都看不懂当时为什么这么设计。我现在的习惯是，每加一个 agent 角色或改一次协议，都同步更新一份“系统行为说明”，写清楚每个角色的职责、每条消息的触发条件、每个状态的转换规则。这份文档在排查问题时能救命。