企业官网建设流程全解析

把 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 做完给 B，B 做完给 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 像真实团队一样各管一摊，再用审查机制兜底，才是这类系统真正落地的地方。如果你也在做类似的多智能体项目，先把每个角色提示词写窄，把循环上限设好，其他细节慢慢优化就好。