从单体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跑起来之后工具、状态与记忆的工程化前面聊的都是逻辑架构真正把架构跑成稳定服务还要解决三个工程问题工具如何统一暴露给AgentAgent运行状态如何持久化以及跨会话的记忆怎么管理和隔离。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类应用我的第一个建议是先花一倍的时间把“每个角色能碰什么工具、必须产出什么格式结果、什么情况下算失败”这三件事定清楚模型的选择反而是后面顺水推舟的事。想清楚边界再让模型入场这套架构才能真正发挥出协作的威力。 
长河君 · 2026/10/10 4:22:37 · 阅读 1.2k 从单体Agent到Agent组织：多智能体协作架构的设计与落地
从单体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跑起来之后工具、状态与记忆的工程化前面聊的都是逻辑架构真正把架构跑成稳定服务还要解决三个工程问题工具如何统一暴露给AgentAgent运行状态如何持久化以及跨会话的记忆怎么管理和隔离。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类应用我的第一个建议是先花一倍的时间把“每个角色能碰什么工具、必须产出什么格式结果、什么情况下算失败”这三件事定清楚模型的选择反而是后面顺水推舟的事。想清楚边界再让模型入场这套架构才能真正发挥出协作的威力。