多Agent编排系统实践：从单Agent极限到虚拟机构架构

去年年底我把一个单Agent处理流程全面重构成多Agent编排系统，代码仓库名就叫“agency-agents”。当时接到的需求并不复杂：公司内部有大量工单、邮件和文档需要自动分类、提取要点、生成回复草稿，早期用单个大模型Agent硬扛，指令稍微绕一点就开始丢上下文，工具调用一多就互相污染。后来我意识到问题不在模型能力，而在组织方式——就像一个人身兼销售、客服、财务容易出错，但一个分工明确的团队不会。所以我决定把Agent当成“员工”，按角色、职责和协作协议组织成一个虚拟机构，这就是这套系统的由来。

这篇内容适合正在做Agent应用、考虑从单Agent迁移到多Agent协作，或者被上下文混乱、工具调用冲突折磨过的朋友。我会把架构设计、核心实现、踩坑排查、成本优化四条线全部展开，基于我自己跑生产环境的实际经历，不写广告，只讲能直接落地的方案。

1. "agency-agents"到底解决什么问题：单Agent的极限在哪里

1.1 单Agent不是笨，是请求一多就"精神分裂"

很多人最开始都会问：一个Agent什么都能干，为什么还要搞多Agent？我先说结论：单Agent在小任务上确实够用，但一旦任务链路变长、工具变多，它就会表现出三个典型的“崩溃前兆”。

• 上下文污染：前面步骤的中间结果残留在对话历史里，后面的任务被无关信息干扰，模型开始答非所问。
• 角色冲突：同一个Agent既要做信息抽取，又要做严谨审核，还要生成对外文案，三种指令风格在同一段上下文里反复拉锯，输出风格会变得极其不稳定。
• 工具调用错乱：Agent拿着A工具的结果去喂B工具，参数对不上还不报错，只是默默生成了一堆垃圾输入。

我在生产里最直观的感受是：单Agent处理简单工单分类还行，但一旦涉及“先提取客户诉求，再匹配知识库，再生成回复，最后走审核”，它就频繁出现把“投诉类型”和“解决方案”混在一起写的情况。这很像我刚带团队时犯的错误——让一个人干了三个人的活，结果每件事都只做到了六十分。

1.2 多Agent的核心是"机构化"，不是简单堆数量

“agency-agents”这个词我理解有两层含义：agency是能动性，agents是多主体。合在一起，就是要让多个Agent具备组织化的行动能力，而不是简单地把任务丢给多个模型并行跑。

机构化设计有几个核心特征：

• 角色有明确边界：每个Agent只听自己职责范围内的指令，调用自己权限内的工具。
• 任务有明确路由：上游任务经过调度器分段、分优先级，按角色派发。
• 结果有明确验收：产出必须经过结构化校验或专门的Reviewer Agent确认，才算完成。

换句话说，多Agent不能只是“多个人”，得是“多个岗位清晰的人”。这个思路直接决定了后面整套架构的走向。

1.3 什么场景适合引用agency-agents这种架构

我踩过一遍之后总结出适用场景的判断标准，不一定全面，但很实用：

• 任务链长度超过三个环节，且环节之间有先后依赖。
• 需要多种不同类型工具参与，比如外部API、数据库、文档检索。
• 输出物需要人工审核或强一致性，不能接受“看起来差不多”。
• 团队希望保留对每个环节的可观测性，出了问题能定位到具体环节。

如果你的场景只满足第一条，单Agent加一个状态机就够了，不必强行上多Agent。但四条都满足，单Agent的维护成本会指数上升，这时候agency-agents这套架构才有真正的收益。

2. 架构设计：我是怎么把"虚拟机构"拆成可编排单元的

2.1 三层拆法：编排层、角色层、工具层

我的实践经验是，不要一开始就纠结用哪个框架，先把逻辑分层想清楚。整个系统我拆成三层：

• 编排层（Orchestrator）：负责拆解任务、管理依赖、调度Agent、聚合结果。这是大脑，也是整篇架构里最不能偷懒的部分。
• 角色层（Agents）：一组职责单一、Prompt独立、工具受限的Agent实例。每个Agent有名字、职责说明、输入输出Schema。
• 工具层（Tools）：所有外部能力以注册表形式暴露，Agent不能直接调API，只能通过工具层调用。

这么拆有个明显好处：任何一个Agent挂了或者输出异常，我可以只重启角色层，不需要动编排逻辑；工具升级也只影响工具层，角色层不用改。类比公司架构：老板不亲自写代码，员工不自己采购设备，所有资源走行政统一调配。

2.2 编排层的调度循环怎么做

调度是整个系统的心脏。我用一个最简可运行的循环来说明，这个循环在工程里可以无限扩展，但核心骨架就四个动作：

# 简化的编排循环示意 def orchestrate(task): plan = planner_agent.plan(task) # 1. 拆解计划 for step in plan.steps: # 2. 按依赖顺序执行 result = route_to_agent(step) # 3. 路由到对应角色 validated = validator.check(result) # 4. 校验结果 store_context(step, result) return aggregator.merge(plan.steps)

这里最容易犯的错误是：把plan步骤设计成完全线性的。真实业务很少有纯线性的流程，工单可能是“分类→检索→生成→审核”，但突发异常情况（比如审核不通过、检索无结果）就会打破线性。所以我在编排层加了一个“分支重试”的概念：每个step允许有n个后继节点，失败时走备用路径，而不是整个任务回滚。

2.3 角色设计的"一官一责"原则

我给每个Agent写system prompt时，会强制遵循“一官一责”原则：一个Agent只对一类输出负责，不搞“全能型人才”。

举例来说，我系统里至少有这几种角色：

每个角色的system prompt里，我会明确写出“你不负责XX”，比“你负责XX”更重要。比如Extractor的prompt里会写“你不负责判断信息是否合法，你只负责提取”；Reviewer的prompt里写“你不负责改写文案，只负责打回”。这样Agent之间不会越权，输出边界清晰，后面的校验逻辑也好写。

3. 核心实现细节：任务分发、上下文传递和结果聚合

3.1 任务分发：用消息还是直接函数调用

第一版我用的是直接函数调用，planner解析完步骤后在进程内直接调agent.execute()。这个方案在小规模没问题，但一旦加并发、重试、优先级，函数调用就把编排逻辑和Agent执行逻辑耦合死了。

我最终调整成“轻量消息队列”模式。每个Agent有一个input queue，编排层往队列里投递任务消息，Agent异步消费。消息体设计成固定schema，包含request_id、step_id、input_payload、context_token。

这样做的收益很直接：Agent可以独立横向扩容，可以暂停单个Agent的消费速率，可以做失败重投，还可以留审计日志。投入成本并不高——用Python的asyncio.Queue或者Redis Stream就能实现，不需要引一个重量级MQ。

3.2 上下文传递：我放弃了大而全的共享记忆

早期我踩的最大的坑，就是把所有Agent的中间结果都塞进一个全局context里。这个设计在演示时很酷，看起来每个Agent都“知道所有事情”，但实际跑起来上下文长度飞速膨胀，OpenAI的token开销翻了四五倍，还出现模型被无关信息干扰的问题。

后来我改成了“按需传递”的策略：

• 每个任务步骤只接收它真正依赖的字段，比如Writer只接收Extractor提取的摘要，不接收原始全文。
• 历史信息不再全部平铺，而是定期压缩成摘要块，压缩由专门的Condense Agent完成。
• 每个Agent的输入schema里明确列出必选字段和可选字段，缺字段直接报校验错误，而不是让模型“自由发挥”。

这个改动让token消耗降了差不多一半，同时输出稳定性显著提升。所谓“上下文”，不该让所有Agent共享，而应该像公司里的工作交接单一样，只传递该传的东西。

3.3 结果聚合：不要直接把多个输出拼起来

多Agent跑完之后，最后一个环节是把各个步骤的结果合并成最终交付物。这个环节我曾经“偷懒”，直接把多个Agent的输出concat成一个长文本返回给上游。结果就是开头还行、中间断裂、结尾莫名其妙。

聚合的正确做法是单独用一个Aggregator Agent负责“重新组织”。它不仅拼接内容，还会做结构重整——比如把Retriever给出的多条候选片段去重、排序，把Reviewer的意见合并进修改建议，最终输出一段连贯且符合交付格式的内容。同时聚合器要保证输出走一遍输出schema校验，字段缺失或者格式不对就直接触发重新生成。

4. 踩坑实录：多Agent系统里四个最容易翻车的环节

4.1 Agent无限循环：调用链条断不了

第一个生产事故就是Agent循环。Retriever查不到结果，返回了一个“继续尝试其他关键词”的建议，Planner看到之后不知怎么地又把同一个关键词重新下发一次，两个Agent互相踢皮球踢了十几轮，token烧掉了好几万，任务也没完成。

排查过程是这样的：我先查日志，看调度循环的每条记录，发现请求里request_id没有变化，说明同一个步骤被反复投递；再对比输入输出，确认Agent的output没有被规整，计划步骤里的检索参数原样带回；最后查终止条件，发现编排循环里只判断了“步骤是否执行完”，没有判断“同一个步骤是否执行过多次”。

修复方案分两层。编排层加入循环检测：同一个request_id在N步内再次出现，直接中断并走降级路径。Agent层加入输出约束：Retriever的返回必须包含found字段，找不到就明确返回“无结果”，而不是生成一串开放式的建议。

这里我学到最重要的排查思路——多Agent系统出问题时，永远从调度日志入手，别从Agent的回复内容猜。因为回复内容只是结果，调度日志才能还原过程。

4.2 上下文爆炸：模型开始“胡言乱语”

跑两周之后，我发现部分长任务的输出质量明显下滑，甚至出现把文档标题当成正文内容的情况。查了token用量才发现，某个Agent的上下文已经堆到了接近10万token，里面全是前面环节的中间产物。

这个问题最典型的排查链路是：先看哪个环节耗时最长，再看该环节的上下文构造逻辑，最后定位到是“全局历史累积”导致。我上面提到的“按需传递”方案就是针对这个坑的彻底整改。

额外补充一个实操小技巧：给每个Agent的上下文设置软上限，超过阈值就触发摘要压缩。摘要不是简单截断，而是用Condense Agent生成“这个阶段已经确认的事实列表+未解决问题列表”，下一环节只看到这两张表。

4.3 角色串味：一个Agent干了别人的活

有一次我在测试里发现，Extractor的输出里居然出现了“建议你联系客户经理”这种话，这明显是Writer该干的活儿。深挖原因，是因为训练时大家习惯在一个system prompt里把所有指令都写全，导致模型对“边界”认知很模糊，稍微换个表达方式就越界。

修复有三个动作：

• 在prompt里明确写“你不负责XX，即使任务描述提到相关内容，你也只输出你的职责字段”。
• 输出schema用强制JSON校验，Extractor的输出如果夹带额外字段，直接校验失败。
• Review环节增加“角色越界检测”，让Reviewer检查每个Agent的输出是否只包含该角色允许的字段。

三种手段一起上，基本杜绝了串味问题。这也验证了一个观点：多Agent系统里，约束越清晰，模型越稳定。不要把Agent之间的协作建立在“模型自己理解”上。

4.4 结果不一致：同样的输入，两次跑出不同答案

模型本身是概率性的，多Agent链路会放大这种随机性。同一个工单，上午跑出的回复是“建议退款”，下午跑出的却是“建议换货”，审核没法做。

这个问题不能完全消除，但可以控制。我的方案是给关键决策步骤加“确定性约束”：Reviewer在审核时，如果发现答案在两个候选之间摇摆，就触发一次Re-ranker，用固定规则（比如“优先选择成本更低”策略）而不是让模型再生成一次。

另外，重试策略要注意：不能用同一个Prompt反复让Agent重新生成，而是在Prompt里附带“上一次输出与失败原因”，强迫模型基于差异做修正，不然每次重试都是独立抽样，毫无收敛趋势。

5. 性能与成本优化：让多Agent集群跑得又稳又省

5.1 模型分级：别让贵模型干杂活

多Agent系统最大的成本陷阱，就是所有角色都用同一个旗舰模型。实际上，Extractor这种“抽取字段”任务，用小模型完全够用；Planner这种“复杂决策”任务，才需要旗舰模型。我做了分级：

这个分级让我的系统成本降了将近六成，而输出质量几乎没有变化。

5.2 并发控制：别把Agent全部放出去跑

多Agent天然适合并发，但无脑并发会把上下游的依赖顺序打乱。我采用的策略是：按依赖层限流。同一层的Agent可以并行，但上一层没跑完，下一层绝不启动。编排层维护一个依赖计数器，每个步骤执行完只“解锁”下游步骤。

同时在Agent内部加超时保护，单个步骤超过30秒直接返回超时错误，由编排层决定重试还是降级。超时时间一开始设的60秒，后来发现有些工具调用会卡死在外部API的等待上，30秒以内就该暴露问题，拖到60秒纯粹浪费成本。

5.3 缓存策略：同样的结果不跑第二遍

多Agent系统里重复计算非常常见。同一个知识库片段，不同工单可能都需要检索；同一个客户历史，也可能被多个任务反复拉取。

我在工具层做了一层缓存：对工具的输入参数做哈希，命中缓存就直接返回历史结果，不再触发Agent调用。这里有个关键点：缓存只用于“检索类工具”和“确定性工具”，不能用于生成类Agent的输出，否则会引入陈旧结果风险。

5.4 可观测性建设：没有日志就没有排查

多Agent系统的黑盒程度比单Agent高很多，不做观测，出了问题就只能靠猜。我强烈建议从第一天就给每个Agent接入结构化日志，至少包含四个字段：request_id、agent_role、step_id、input_summary。每步执行完，记录耗时、token用量、输出校验结果。

实际排查时，我80%的问题都可以靠日志定位：超时问题查耗时记录，上下文爆炸查token用量，循环问题查request_id重复，角色串味查输出字段越界统计。日志表格的样式大概像这样：

6. 一些关于下一步扩展的个人体会

系统上线稳定运行快两个月了，我现在正在做的改动是把编排规则从硬编码改成DSL配置化。也就是说，以后新加一个角色不需要改Python代码，只需要在配置文件里写清角色名、职责描述、工具权限、输出schema，编排层启动时自动加载。这个方向适合团队协作，也方便非技术人员参与角色定义。

另外，我在尝试把Reviewer的角色升级成“双通道校验”：一条通道走模型审核，另一条走规则引擎校验，比如必填字段是否完整、输出长度是否超限、引用来源是否存在。两条通道同时通过才放行。这个设计对需要强审核的场景很有价值，比如对外客服回复、合规性文档生成等。

最后给准备入坑多Agent系统的朋友一句实在话：别被框架迷了眼，先把角色边界、上下文传递、调度循环、日志四件事想清楚。这四件事没有解决前，上什么框架都会在某个深夜给你打电话。我自己就是活生生的例子。