从单体Agent到Agent组织：关于“agency-agents”的设计思路与落地经验
这两年做大模型应用的人，八成都有过类似的尴尬：单个Agent在Demo里跑得挺欢，一放到真实业务场景里就变回了“人工智障”——目标稍复杂就迷路、工具调用上下文一长就开始乱套、该并行处理的任务老老实实排队等。所以我这两年把工作重心从“调Prompt”挪到了“设计Agent组织”上。所谓agency-agents，直白点讲，就是把原来一个Agent的大而全能力，拆成一个有角色分工、有汇报关系、有协作机制的小团队，让每个Agent做自己最擅长的事，再由一个“调度中枢”统一协调。这套思路在业界也叫多Agent协作架构，但它并不是简单地把多个Agent拼在一起，而是涉及任务拆解策略、上下文隔离机制、工具权限设计、模型选型搭配等一系列工程问题。
这篇文章我就从自己实操过的几个项目出发，把agency-agents这套架构从零拆开讲清楚。我尽量不用PPT语言，直接讲我在代码里怎么拆、在配置里怎么调、线上踩过哪些坑。准备做多Agent应用、或者在单体Agent里折腾半天觉得不痛快的，可以先收藏再看。
1. 前提认知：为什么单体Agent会撞到天花板
先花点篇幅讲清楚一个认知问题，不然直接堆架构方案，你很难理解“为什么非要拆”。
1.1 单体Agent的“能力天花板”来自哪里
Agent的底层推理过程，本质上是在一个上下文窗口内同时处理三件事：理解用户意图、决定调用哪些工具、根据中间结果修正下一步计划。这个“串行决策”模式在任务只有两三个步骤时没问题，但任务一旦拉长，问题就全暴露出来了。
我举个实际例子。做个“查询近30天四类核心渠道的投放消耗，对比ROI变化，输出异常渠道分析报告”这类任务。单体Agent的推理链路是这样的：
- 先判断用户想问什么，决定调用BI工具的接口
- 拿到投放消耗数据
- 要算ROI，得再查收入数据
- 要对“异常”做判断，需要历史基线
- 要把上面所有中间结果组织成报告
这条链路每一步都会产生上下文。等执行到第4步时，Agent的注意力早就被前几步的原始数据占据了大半，它既要在已污染的上下文里维持“最初目标”的记忆，又要理解新拿到的数据。结果就是：原始目标被稀释、工具参数传错、中间结果被张冠李戴。这不是模型能力不够，是“在单一上下文里做长链路多步决策”这个模式本身就有瓶颈。
1.2 拆开之后为什么问题变小了
agency-agents的核心思路，是把“长链路工作”转成“短链路协作”。每个Agent只管一段相对独立、上下文干净的子任务，父Agent只负责拆解和验收子Agent的结果。这样每个Agent的上下文窗口都只承载自己那个环节的数据，不会被其他环节的中间结果干扰。
我自己实测过一个对比：同一个“竞品动态监控日报”任务，单体Agent跑到第7轮工具调用后，开始出现目标漂移——它把“提取竞品功能更新”和“汇总自家功能待办”混在一起了。拆成“信息采集Agent + 差异分析Agent + 日报编写Agent”之后，同样的任务跑20轮，每个Agent的上下文都保持干净，输出质量明显稳定。这个对比支撑了我后面所有设计决策。
2. 架构拆分：三层职责怎么划分才能不出乱子
如果你打开一个多Agent框架的示例代码，会发现里面Agent一堆，但到底谁指挥谁、谁调用谁，很多时候是糊的。“把任务拆给多个Agent”和“把任务拆给一套有效率的Agent组织”是两回事。
2.1 决策层、协调层、执行层的角色定位
我常用的分层方式分三层。第一层是决策Agent，也叫主管或Planner，它的工作就是听懂用户要什么，然后把目标拆成可执行的子任务。它不直接接触数据工具，也不写最终交付物。第二层是协调层，它负责把子任务分发给合适的执行者，接收执行结果，判断是否需要重试、是否需要追加信息。有些场景里决策和协调可以合并成一个Agent，但任务复杂时最好拆开，因为“定义任务”和“管理任务状态”是两种完全不同的思维方式。第三层是执行Agent，每个执行Agent只负责某个具体工具域或知识域，比如数据分析Agent只碰SQL和BI看板，内容生成Agent只负责文本输出。
这套结构的核心好处是上下文隔离。子任务之间即使数据有关联，也通过“结构化消息”传递，而不是直接共享上下文。决策Agent能看到所有子任务的最终摘要，但看不到执行Agent的原始工具日志。
2.2 一个研报场景的Agent组织实战拆解
我做过一个产品，输入某行业关键词，自动生成一份结构化行业研报。单体Agent版本跑了不到两周就扛不住了，后来按agency-agents思路重构成了五个角色的组织：
- 规划Agent：接收关键词，拆分出行业概况、产业链图谱、头部企业动态、技术趋势、投资建议五个章节作为子任务
- 数据采集Agent：负责真实性信息检索，只输出结构化事实列表，每条事实带来源和日期
- 分析师Agent：基于采集结果做归因和趋势判断，输出结论性要点
- 写作Agent：拿到所有结论，按研报模板组织语言
- 质检Agent：最后统一检查，看事实是否有来源支撑、结论是否前后矛盾
你发现没有，这几个Agent里面，真正需要强推理能力的其实只有“分析师Agent”和“规划Agent”。写作和数据采集环节，用中等规模的模型也能干得很好。所以拆开之后连带的好处是：每个环节可以根据难度选不同的模型，成本比“所有任务都让最强模型扛”低很多。
3. 协作机理：Agent与Agent之间是怎么配合的
3.1 共享盘、消息队列还是显式传递？三种协作模式比较
Agent之间的协作方式，业内没有统一标准，但主流上可以分三类：
第一种是共享盘模式，所有Agent把中间产物写到一个共享空间里，重要信息用“写文档”的方式沉淀。这种模式适合异步流水线场景，一个Agent产出后，下一个Agent轮询或者被触发后消费。优点是实现简单，缺点是容易产生脏数据，没人实时清理废弃中间文件。
第二种是消息队列模式，Agent之间通过事件消息通信，每个Agent订阅自己关心的主题。这种模式适合高并发场景，多个任务同时流转时不会互相阻塞。缺点是调试链路比较长，出了问题要从消息日志里翻因果。
第三种是显式传递模式，父Agent显式调用子Agent，等子Agent返回后再继续。这是最直观的模式，也最适合大多数业务系统集成，调试时调用链清晰。缺点是在超长任务链路里父Agent容易变成瓶颈。
我自己做业务落地时，默认用第三种模式，保证问题可排查；只有遇到周期性数据流水线任务，才把采集环节改成队列模式。绝大多数项目，先别急着上复杂架构，显式传递足够用。
3.2 子Agent的结果如何被有效消费
子Agent返回的结果，绝对不能是一大段自由文本让父Agent自己“理解”。我踩过这个坑：最早子Agent返回的是纯文本分析，父Agent需要自己从中提取结构化字段，一旦子Agent输出格式不稳定，父Agent的解析逻辑就全线崩溃。
解决办法是设计“结构化交付物协议”。每个子Agent的任务说明里明确输出格式，例如数据采集Agent的输出必须是JSON数组，每条包含字段名、字段值、来源URL、采集时间；分析师Agent的输出必须是带有置信度分值的断言列表；写作Agent的输出必须包含章节标题和正文字符数。父Agent消费这些结构化输出时，先做严格校验，不通过就触发重试，而不是硬着头皮继续。
重要提示：多Agent协作里，绝大多数“好像模型不够聪明”的问题，其实都是输出协议定义得不够严格。模型不是不听话，是你没把“听话”的标准量化成可校验的规则。
3.3 谁来决定“这个任务得重做”
协作过程中一定会遇到子Agent产出不达标的情况。我的经验是在父Agent的决策逻辑里设置三个固定追问，提高重做判断的可靠性：子Agent的输出和输入任务要求是否一致；输出中的关键断言是否有数据支撑；输出的格式能不能被下游安全解析。这三个追问我写成结构化的检查清单让父Agent逐项打分，任何一项不通过，就把具体的失败原因拼进新的任务指令，回传给子Agent重做。
这套“反馈回路”比单纯让父Agent“凭感觉判断好坏”可靠得多。我用过一段时间纯Prompt式判断，父Agent经常在两个子结果之间摇摆，或者因为整体印象分就把不合格的结果放行了。改成逐项打分之后，虽然代码量多了一点，但输出质量的方差明显下降了。
4. Agent跑起来之后：工具、状态与记忆的工程化
前面聊的都是逻辑架构，真正把架构跑成稳定服务，还要解决三个工程问题：工具如何统一暴露给Agent，Agent运行状态如何持久化，以及跨会话的记忆怎么管理和隔离。
4.1 工具的统一暴露和权限边界
Agent要干活就得用工具。风格粗放的项目会让每个Agent自己定义工具函数，想怎么调就怎么调，结果就是AgentA的API Key泄漏到了AgentB的上下文里，或者某个Agent调了它本不该碰的写操作接口。
我现在的做法是“工具网关”模式。所有工具集中在网关里注册，每个工具声明四样信息：工具名称、参数Schema、允许被哪些角色调用、调用是否需要审批。执行Agent在执行工具前，先向网关发起调用申请，网关校验角色的权限边界之后再放行。Agent自己是不知道工具列表全貌的，它只知道自己角色允许看到的那几个工具。
这个设计还有另一个好处：所有工具调用都有审计日志，出了问题时能查清楚是哪个Agent在什么上下文下调了什么工具，排查效率高非常多。单体Agent时代你根本做不到这种粒度。
4.2 状态持久化：Agent中途宕机了怎么办
多Agent协作的任务往往要跑几十甚至上百次模型调用。一个执行Agent中途出错了，如果整个流程从头重跑一遍，成本很高。所以一定要做状态持久化。
我的做法是在调度层维护一个任务状态库，记录每个子任务的阶段、输入快照、输出快照和重试次数。子Agent挂掉之后，调度器从最近的“已完成节点”恢复执行，而不是从零开始。状态库可以用关系数据库存，也可以用对象存储存JSON快照。
这一步在开发环境里很容易被忽略，因为本地重跑成本低。但是一旦部署到线上，任务跑着跑着基础设施抖动一下，如果没有状态持久化，用户看到的就是“任务莫名失败”。有了状态库，你可以很从容地让调度器定期扫描失败任务并按节点恢复。
4.3 记忆隔离：别让A任务污染B任务
多Agent系统里，记忆管理不好会造成严重的“串味”问题。比如同一个Agent服务同时服务多个用户会话，如果记忆是全局共享的，A用户的私有数据会被B用户的下游任务读到。
我的原则是：执行Agent默认无记忆，每次任务只依赖传入的上下文；规划Agent记忆做成用户级隔离；项目级知识库记忆的读写也要通过权限校验，不允许执行Agent直接写入全局记忆。宁可让Agent“金鱼记忆”一点，也不能让数据边界模糊。
5. 实操落地：一个真实业务系统的工程改造记录
前面都是方法论，这一节我拿一个自己在线上跑了大半年的项目当例子，完整记录一次从单体Agent到agency-agents架构的改造过程，包括数据设计、配置样本和实际踩坑。
5.1 基础设施与模型选型清单
项目名字就叫模拟项目X，核心功能是“自动化内容合规审校”，输入一篇文章，输出风险点标注和修改建议。早期版本是一个大模型Agent直接读全文、直接给结论，准确率大概在七成上下。改造后的架构用了四个执行Agent加一个协调Agent。
模型选型上，协调Agent用能力较强的前沿模型，负责全局判断；执行Agent分两类，涉及时效性信息核验的用支持工具调用的模型，其他文本分析环节用中等规模模型。实际跑下来，整体成本比“全链路用大模型”降低了接近一半，准确率从七成提升到了九成以上。
5.2 任务路由的动作路径拆解
改造后的主流程长这样。协调Agent先读取文章全文，做第一轮粗分类：是事实性内容还是观点性内容，涉及哪些敏感主题。然后根据分类决定触发哪些执行Agent。
比如一篇文章同时涉及数据引用和外部事件描述，协调Agent会把文章全文派给两个执行Agent做并行分析：一个执行Agent只负责“数据引用真实性核验”，它会逐个检查文中的数据，和材料库做比对，返回结构化差异列表；另一个执行Agent负责“内容上下文合规性检查”，按敏感类型输出风险点清单。两个执行Agent互不感知对方的存在，各自返回独立的结构化结果。协调Agent最后汇总所有结果，去重合并，生成一份最终审校报告。
这个流程和单体Agent相比，最大的变化是执行Agent的任务极窄。数据核验Agent不需要理解整篇文章的立场，只需要把数据和事实库比对，哪怕上下文里只有五条待核验数据也同样能干活。出错概率自然被压得很低。
注意：同样的任务，Agent的能力上限并没有变强，变强的是“每一项子任务占用Agent注意力时”的上下文纯净度。这是agency-agents这套架构能提升输出质量的最直接原因。
5.3 关键配置示例与参数解读
下面这段配置是这个系统里协调Agent任务路由规则的一个精简版本，我用伪代码形式展示，方便你理解“决策提示词里应该包含什么”。
[role] 你是总控协调Agent，负责把输入内容拆解为若干子任务，并分发给下方执行Agent。 你本身不产出终稿，你的职责是拆解、分发、汇总、验收。 [input_schema] 文章全文: {article_text} 历史审校记录: {history_records} [subtask_rules] 1. 如果文章包含统计数值，必须触发“数据核验Agent”。 2. 如果文章包含外部实体描述，必须触发“事实核查Agent”。 3. 如果文章总字数超过3000字，按章节拆分为多个并行任务。 4. 每个子任务必须附带独立的指令，指令必须包含：输入材料、输出格式要求、验收标准。 [tool_boundary] 你可以读取任务状态，但不可直接修改执行Agent的中间输出。这里我重点说下“附带独立指令”这一条。很多人在实际代码里只是简单地把父任务全文传给子Agent，指望子Agent自己“理解该干什么”。这是不对的。子Agent收到的应该是“已经加工过的任务指令”，它不应该看到完整的用户原始诉求，只需要看到自己负责的那部分材料加上清晰的验收标准。就像真实团队里，主编不会把读者来信原封不动转给记者，而是会说“你去核实第三段那个数据”并划好范围。
5.4 改造前后的效果对比
改造完成后，我对线上两个多月的任务数据做了一次抽样分析，直接看两个指标：端到端任务成功率（指一次通过不需要人工干预的比例）和平均每次任务的模型调用成本。
改造前单体Agent的成功率大约在68%到72%之间波动，碰到长文或者多主题混杂的文章，成功率会掉到60%以下。改造成agency-agents之后，成功率稳定在90%到93%之间，长文场景的掉点问题也消失了，原因是执行Agent接收的上下文被控制在很小范围，长文拆成章节后每段处理都很干净。
成本方面，单体Agent方案下每个任务平均要调用约11次模型接口，改造成多Agent方案后这个数字反而降到了8次左右。虽然多个执行Agent并行调用看起来调用次数更多，但因为子任务失败重试的比率大幅下降，无效调用少了很多。
6. 常见问题与排查经验速查表
这一节整理我在社群答疑和实际项目支持里遇到的高频问题，直接按“现象-原因-解法”结构给结论。
6.1 多Agent比单体Agent更容易“答非所问”
我见过不少团队拆了Agent之后反而觉得输出变差了，原因大多是“拆解过度，验收缺失”。任务被拆成很细的碎片之后，每个执行Agent只看到局部信息，做的是局部最优决策，但父Agent又没有认真做全局汇总，最终拼出来的结果自然整体性差。
解法不是不拆，而是要在父Agent的职责里明确加一条“全局一致性校验”：汇总各个子Agent结果后，强制检查是否存在前后矛盾、关键实体是否全文保持一致。这步校验做完再输出终稿，可以大幅减少“答非所问”体感。
6.2 子Agent之间出现“重复劳动”
两个执行Agent可能同时在做高度重叠的事情，比如一个查数据可用性，一个查数据准确性，结果两边都在访问同一个数据源、产出几乎一致的结论。
这问题我在早期的内容审校系统里就遇到过。解法之一是在规划阶段给每个子任务声明“数据依赖和产出变量”，父Agent在分配任务时先做冲突检测，发现两个子任务产出的关键变量高度重合时，就会合并成一个任务；解法之二是放宽执行Agent的并行度，让重叠任务串行执行，第二个任务在第一个任务的结果上做增量工作，而不是从头开始。
6.3 模型在工具调用时频繁“手滑”传错参数
工具调用参数错误，是所有Agent上线后最先遇到的稳定性问题。原因也很好理解，大模型要在生成自然语言的同时输出结构化的工具参数，这对中等规模模型来说是双重压力的叠加。
解决思路有两条。一条是给工具参数Schema做更严的约束，包括枚举值校验、必填项校验、格式校验，让错误参数“传不出去”而不是“传出去之后再重试”。另一条是在工具调用失败的回传信息里包含具体错误原因，让执行Agent下一次调用时能读懂错误并自我修正。这两条配合使用之后，我的项目里工具调用失败重试率下降了约四成。
6.4 临时问题速查表
| 现象 | 大概率原因 | 第一排查动作 |
|---|---|---|
| 子Agent返回内容格式不稳定 | 任务指令里输出协议约束不足 | 检查输出Schema是否带枚举值和必填校验 |
| 某个Agent频繁触发重试 | 工具参数校验太松导致错误传参进入执行层 | 查看工具调用日志的失败错误码 |
| 多个Agent产出结论冲突 | 汇总阶段缺少全局一致性校验 | 检查父Agent提示词里有没有“冲突消解规则” |
| 长任务跑到一半超时 | 单次任务内串行调用过多 | 把可并行子任务改成并行执行并设置超时降级 |
| 线上偶发数据串味 | 记忆隔离没做或做了但共享了全局缓存 | 逐会话检查记忆读写路径的Session隔离 |
7. 一些踩过坑之后归纳的选型参考
最后聊点软的。Agent架构选型，不是越复杂越好。我看到很多团队一上来就上编排引擎、事件总线、向量记忆库，结果就是基建工作量比业务逻辑还大，项目根本跑不到上线那一步。
我的选型经验是这样：如果你的应用只需要解决一个固定场景内的任务，比如“做周报”“查竞品”，单体Agent加一个规划器就完全够用。如果你的任务类型多、输入结构不稳定，但是任务之间很少有依赖关系，那只需要做一层任务路由，让分类Agent把任务分给不同的技能Agent就行。如果你的核心场景是长流程、多步骤、且步骤之间有严格先后依赖，这时候再引入agency-agents式的完整分层架构才有性价比。
成本方面也别光看模型调用费用，还要算维护成本。多Agent架构意味着你要维护角色定义、协作逻辑、输出协议、状态持久化四套系统的稳定性。每新增一个Agent角色，就要配套定义它的指令模板、工具权限和验收标准。这些工作本身都有工作量。所以每次有人问我“这个场景要不要上多Agent”，我给的答案永远是：先从单体Agent开始，等你在日志里明确看到了上下文污染或者目标漂移的具体证据，再动手拆，不要为了架构而架构。
我自己在实际操作中还有一个体会：多Agent系统最容易翻车的点不在模型选择，而在“边界清晰度”。角色定义模糊、权限边界模糊、输出格式模糊，系统就一定不稳定。如果你现在准备做一个Agent类应用，我的第一个建议是先花一倍的时间把“每个角色能碰什么工具、必须产出什么格式结果、什么情况下算失败”这三件事定清楚，模型的选择反而是后面顺水推舟的事。想清楚边界，再让模型入场，这套架构才能真正发挥出协作的威力。
