把 agency-agents 这个标题展开来说它指的是一个由多个 AI 智能体Agent组成的协作系统这些智能体不再各自孤立地处理单次对话而是像一家数字代理机构那样分工、协作、互相审核共同完成一个完整任务。我从年初开始折腾这类架构一开始用单个 Agent 做内容创作输出效果飘忽不定后来把任务拆给策划、写作、审查三个角色质量立刻稳了一个档次。这篇博文会把我在模拟项目X中从技术选型、框架搭建到调试优化的完整过程记录下来适合正在考虑引入多智能体协作机制的开发者参考。1. agency-agents 到底在解决什么问题1.1 单 Agent 的天花板在哪单独一个大模型 Agent 日常处理问答、总结、写邮件都没问题但一旦面对多步骤、多角色、需要交叉验证的复杂任务性能就会急剧下滑。我做过一个实验让单个 Agent 写一篇三千字的行业分析文章要求包含数据支撑和风险提示。结果它要么把数据编得乱七八糟要么开头写得很漂亮、后半段开始重复车轱辘话根本没有一个监督者来帮它修正。核心原因在于单个 Agent 的上下文窗口有限任务一旦变长前面的指令会被后续内容冲淡。更麻烦的是它缺少角色隔离——一个人又要当策划又要当写手又要当编辑提示词里的角色要求会相互干扰模型很难在不同身份之间频繁切换而不出错。这就是 agency-agents 这类系统出现的原因与其让一个超长上下文硬扛不如拆成一堆专职 Agent每个只干一件事再把结果交给下一环节。1.2 代理机构式协作的三大优势把 Agent 组织成代理机构而不是简单排队调用我实测下来有三个很明显的收益。第一是职责边界清晰。策划 Agent 只负责输出大纲和方向写作 Agent 只负责把大纲扩展成成稿审查 Agent 只负责挑毛病。每个 Agent 的提示词都非常短模型不需要记一堆前后矛盾的约束行为稳定很多。第二是质量闭环。审查 Agent 发现写作 Agent 跑偏之后不是直接改稿子而是把修改意见打回去让它重写。这个打回—重写—再审的循环非常像真实团队里的评审流程能显著减少胡说八道。第三是可扩展性。想新增一个图表生成 Agent或者接入一个数据查询工具只需要在注册表里多填一个条目其他 Agent 不需要改动。单 Agent 方案每次加能力都要重写整套提示词代价完全不同。2. 整体架构设计与技术选型2.1 五个核心模块怎么划分我在模拟项目X里把一个可用的 agency-agents 系统拆成了五个模块编排核心、角色 Agent 池、工具注册表、记忆存储、任务队列。编排核心是大脑负责接收用户任务、拆解子任务、按流程调度 Agent。角色 Agent 池是执行层每个 Agent 实例绑定一个系统提示词比如策划、写作、审查、数据。工具注册表是所有外部能力的统一入口包括搜索、数据库查询、计算脚本等。记忆存储用来保存每个 Agent 的中间产物和上下文摘要避免所有信息都堆在 token 里。任务队列则管理并发和重试。这里最容易犯的错误是一上来就设计复杂状态机。我第一版想用图数据库记录所有 Agent 之间的关系结果连节点定义都没定完就放弃了。后来改用简单的管道模式任务按顺序流转每个 Agent 在上一个输出基础上工作。对绝大多数业务场景这套简化已经够了。2.2 主流编排框架怎么选市面上的多 Agent 编排框架大致可以分成三类。第一类偏底层只提供任务编排和状态管理自由度高但是要把上下文传递、失败重试全都自己写。第二类是角色协作框架内置了 Agent 之间的消息通信和任务分配适合快速搭建原型。第三类是把多 Agent 当成对话参与者让它们像群聊一样讨论适合头脑风暴但不容易控制收敛。我给的建议是如果不是做学术实验优先选第二类框架起步先跑通一个最小闭环再逐步替换底层模块。我在模拟项目X里用的就是这类方案角色 Agent 池 简单规则调度器。它不强制我用某一种特定模式同时送了一套现成的对话路由逻辑省掉了最头疼的部分。2.3 任务规划与协作模式确定多 Agent 协作通常有三种模式。顺序链是最简单的A 做完给 BB 做完给 C并行分组适合互不依赖的子任务层级规划则是有一个主管 Agent先拆任务再把子任务派给执行 Agent最后汇总结果。我在做带审核闭环的内容系统时采用的组合策略是策划和检索并行执行写作在它们之后审查放在最后。如果审查发现漏洞就进入打回重写的循环最多循环三次。一旦超限直接挂起并提醒人工介入。这个设计参考了现实团队的协作逻辑不能让审查无限制打回否则成本和延迟都会失控。给循环设置硬上限是 agency-agents 系统上线前必须做的事也是最容易被忽略的一件事。3. 核心实现细节与实操要点3.1 角色提示词怎么写才有约束力很多新手写 Agent 提示词的时候喜欢把角色描述得非常宏大比如你是一位资深内容专家。实测下来这种措辞对模型输出的约束力很弱因为它没有给出可执行的标准。我的写法是给出可验证的输出格式。策划 Agent 的提示词里会明确规定三件事必须输出五个要点、每个要点必须有支持理由、不支持的部分单独列出待核实清单。审查 Agent 的提示词则规定必须逐条检查事实类语句、必须给出具体修改意见而不是很好、必须标注风险等级。这里有一个很实用的技巧把什么是好结果的直接描述换成什么情况下返回重写。模型对负面约束更敏感给它一个明确的失败判断准则输出质量提升比说一百句你要负责任都管用。3.2 实现规划—执行—审查闭环一个完整的闭环流程我是这样跑的。先让规划模块拆解任务明确目标、负责人、交付物格式。紧接着数据 Agent 和策划 Agent 并行开工数据 Agent 负责从数据库和文档里拉事实信息策划 Agent 负责把任务的大纲和核心论点写出来。写作 Agent 拿到大纲和事实信息之后开始生成初稿它会尽量把数据引用标记成占位符比如成本增速约12%待核。审查 Agent 拿到初稿之后会重点做三件事一是检查事实陈述有没有超出数据 Agent 提供的信息范围二是检查结构和目标是否对齐三是判断整体语气是否符合场景要求。如果审查不通过就把修改意见连同原稿一并打回。这个闭环看起来简单但实现的时候要特别注意任务状态管理。我给每个任务定义了一个字段叫 status只有 ready、running、reviewing、done、failed 五档。所有 Agent 都从读取状态开始结束的时候写回状态编排核心通过轮询状态来推动流程避免用复杂的回调机制把逻辑绕晕。3.3 工具注册与调用结果校验工具注册表是这套系统最值得花时间的模块。每个工具在注册表里都要有名称、入参格式、出参格式、超时时间和失败策略。比如数据查询工具超时设置十秒失败后策略是从缓存里读上一次结果并在返回里标记可能过期。我踩过最大的坑是 Agent 调用工具之后直接相信结果。模型有时候会拿一个工具的输出去回答另一个问题或者把工具返回的原始 JSON 误当成最终结果。后来我在工具调用的外层包了一层统一解析器强制把返回结果转成结论摘要 完整详情 可信度评分三段式结构。模型拿到这个结构之后再胡说八道的概率明显下降。对于外部搜索类工具我还会额外加一道白名单校验。工具只能返回白名单域名或者白名单数据源的内容从源头卡住垃圾信息和污染数据流入 Agent 上下文。3.4 状态管理与上下文传递多 Agent 系统里最容易被低估的是上下文传递。每个 Agent 不应该看到整个任务的全部历史只需要看到与自己相关的片段。我在实现里维护了一个会话快照机制每个 Agent 启动时只拿到三类数据当前任务指令、上游交付物摘要、共享的事实库。摘要由专门的压缩模块生成不是简单截断。压缩模块会先提取关键信息再按实体和时间线重新组织。这样即使原始文档很长Agent 拿到的摘要也能控制在比较小的 token 范围内。实操中还发现一个细节所有中间产物都最好不要直接覆盖而是按版本存储。因为审查打回重写的时候可能要用上一次的版本做对比。我见过有人用固定文件名保存中间结果结果审查打回后数据被覆盖再也找不回原始稿整个流程只能从头跑白白浪费大量 API 费用。4. 实测效果与参数参考4.1 用内容生产场景做压力测试模拟项目X第一个落地场景是批量生成技术文档这个场景对事实准确性和结构一致性要求较高非常适合验证多 Agent 系统的稳定性。我用同一批任务对比了单 Agent 直出和 agency-agents 流程产出跑了三十组。单 Agent 组有九组出现了明显的重复段落七组存在事实和引用不匹配。agency-agents 组里审查 Agent 打回重写了十二次其中十一次都指向缺数据一次是语气不对。最终通过审核的三十份文档里事实类错误明显减少。成本上 agency-agents 确实更高单次任务平均多消耗约四成 token。但考虑到返工率下降整体账是划算的。如果任务本身的容错率很低比如直接对外发布的内容多花的 token 属于必要成本。4.2 一套可用参数模板我最终确认下来的一套参数配置可以用作起步参考。大模型采样温度策划 Agent 设成 0.7写作 Agent 设成 0.8审查 Agent 设成 0.2。审查 Agent 之所以用低温是因为它要稳定输出判断而不是发挥创意温度一高就会开始瞎提意见。打回重试次数上限设成三次超过三次直接发到人工队列。单 Agent 超时时间设成 90 秒工具调用超时设成 15 秒。上下文摘要保留最近两轮会话事实库单独存储全局保留时间为项目周期。这套参数跑了两周没有出现过一次死循环代价是偶尔有任务被误挂到人工队列。用误报换稳定性在真实业务里是完全可以接受的。4.3 效果对比与收益分析把结果放在一起对比最明显的变化是产出质量的方差变小了。单 Agent 方案有时候给惊喜更多时候给惊吓而 agency-agents 系统稳定在八十分到八十五分之间。对于需要批量交付的内容生产来说稳定比偶尔一百分更重要。团队侧也发生了改变。以前人工审核要通读全文找问题现在只需要处理系统打出来的风险提示和待核实清单效率提升非常直观。而且因为每个 Agent 的职责被固定出现问题时可以直接回溯到具体环节排查成本低了很多。5. 常见问题与排查技巧实录5.1 智能体陷入循环怎么办我遇到最典型的循环有两种一种是审查 Agent 不断发现新问题另一种是两个 Agent 互相踢皮球。比如审查让写作改得更有深度写作改完审查又说深度不够但没说具体哪里不够于是又打回。解法就三招。第一循环次数必须硬设置。第二审查 Agent 的修改意见必须结构化写明问题位置、问题类型、修改建议不允许笼统表述。第三增加一个意见仲裁模块当同一问题被打回两次以上就直接把它升级为人工任务。稳定之后我再没碰到过跑飞的情况。5.2 上下文污染与记忆错乱上下文污染是隐蔽陷阱。场景是写作 Agent 生成了末尾标注待核实的占位符审查 Agent 看到了也把它当成事实用了。另一个常见问题是数据 Agent 的过期数据没有清理导致后续 Agent 引用陈旧信息。后来我用一套强制清理规则解决任何带待核实标记的文本在进入下一 Agent 前都必须被解析器摘出去放到独立的待处理清单里。数据结果带上有效期超过期限的直接禁止被读取。上下文干净了模型的判断才可信。5.3 工具调用失败的常见原因工具调用的失败大多不是网络问题而是入参格式对不上。Agent 以为自己在调用查询接口传进来的参数却缺少必填字段或者把英文逗号写成了中文逗号。这类错误在日志里并不会提示参数错误反而会触发重试。我在工具注册表里加了一层入参示例和类型校验同时让工具返回的错误信息更友好。如果 Agent 连续两次调用同一工具失败编排核心会直接把原始错误附到提示词里让模型自己反思哪里有问题。这个反思指令成本很低效果却很好。5.4 成本失控怎么压多 Agent 系统的成本最容易被低估。三十组测试跑完以后我复盘过百分之六十的成本消耗来自打回重写和重复调用工具。后来做了三处优化一是把可缓存的结果尽量走缓存二是相同任务的多次运行共用摘要三是将确定性强的子任务从模型调用切换成脚本执行。比如固定格式的数据整理以前是让数据 Agent 用自然语言生成后来直接改成了脚本加渲染模板成本瞬间降下来。我的体会是能不用模型完成的步骤就不要用模型Agent 应该只负责真正需要推理的部分。跑完这个项目我个人的体会是agency-agents 不是靠堆更多大模型调用来提升质量而是靠清晰的职责边界和可靠的反馈闭环。相比幻想机器取代人让一群专职 Agent 像真实团队一样各管一摊再用审查机制兜底才是这类系统真正落地的地方。如果你也在做类似的多智能体项目先把每个角色提示词写窄把循环上限设好其他细节慢慢优化就好。