企业官网建设流程全解析

过去这大半年，我把大部分精力压在同一个问题上：把一个多智能体协作系统真正接进开发流程，而不是停在 Demo 层。最终跑通的这套系统，代号叫 Agency Agents，它做的事情用一个词概括就是“重构开发团队”——不是让一个超级智能体包揽所有工作，而是组建一支有分工、有汇报关系、有质量门禁的智能体队伍，用接近真实团队的协作结构去完成软件交付。这篇文章就把它的架构设计和落地过程完整拆开讲，适合正在研究多智能体协作、想把 AI 接入研发流程但不知道从哪下手的团队负责人和一线开发者。

我先说结论：多智能体协作系统能不能用，不取决于单个智能体的聪明程度，而取决于架构能不能支撑“协作”。Agency Agents 的价值不在它用了多强的模型，而在它把软件团队的岗位逻辑搬进了消息系统里。下面我会分六部分讲：先解释为什么值得这么做，再给架构总览，然后是协作机制细节，接着是可复制的实施路径、落地后的组织变化，最后是我踩过的一串坑。

1. 为什么要把开发团队“重构”成多智能体协作模式

1.1 单智能体的天花板：上下文与角色的双重夹击

过去两年，大多数团队接入 AI 的方式是同一个智能助手干所有事：让它写接口就写接口，让它看日志就看日志，让它补测试就补测试。短任务它做得很好，一旦任务链条拉长，问题就暴露了。最典型的症状是做着后端的活突然忘了前面的技术决策，写着写着把命名风格都换了，甚至把一个模块里刚定的接口约束在另一个模块里推翻。

这不是模型笨，而是单智能体同时承担了“理解需求、做方案、写代码、自查、改 bug”五个角色，而它在任意时刻只能维护一份对话上下文。上下文窗口再大，也扛不住跨文件、跨服务、跨迭代的信息累积。角色一多，上下文就开始互相干扰，这是结构性问题，不是提示词能解决的。

所以我的判断是：与其让一个全能智能体硬撑，不如学真实开发团队的做法——让不同岗位各管一段，通过明确交接来减少上下文压力。这就是多智能体协作的第一个动机。

1.2 现有开发流程中的信息断裂点

看一个团队迭代，你会发现大量时间不是花在写代码上，而是花在信息传递上：需求文档和代码实现对不上，接口设计改了但调用方不知道，测试只覆盖了用例编号没有覆盖意图。这些问题本质上是流程里没有“自动校验信息一致性”的环节。

传统工具链用文档和会议来对齐信息，但文档会过期，会议会漏人。多智能体系统天然适合做这件事：需求解析智能体把口语化需求转成结构化任务卡，编码智能体按任务卡实现，测试智能体按验收标准验证，评审智能体核查任务卡和代码之间的一致性。每一条信息都有来源、有去向、有对应物，断点自然消失。

我见过太多团队给 AI 配了昂贵的模型，最后产出的代码却没人敢合。原因不是代码质量不够，而是团队无法确认它和整个系统的约束一致。Agency Agents 把“校验一致性”变成了独立岗位，等于给流程装上了监督机制。

1.3 “重构”不是推翻流程，而是重排责任

很多人一听“重构开发团队”，以为是要裁员或替换工具链。我实际做完之后的体会完全不同：AI 重构的是责任分配，不是人事结构。原来一个人要从需求分析一路做到联调，现在他把需求讲清楚之后，后续的拆解、实现、验证由一组智能体接力完成，人只在关键节点做裁决。

这套思路可以类比管理一个外包团队：你不会让外包方自己定义验收标准，也不会把生产环境权限随手交给他们。Agency Agents 就是把这种管理逻辑显性化了，只不过执行者是智能体，管理规则全部写在编排层。理解了这一层，后面讲架构时你会更清楚每个组件为什么存在。

2. Agency Agents 的架构成分：从消息总线到角色执行体

2.1 四层架构：接入层、编排层、执行层、模型层

我们内部把系统拆成四层，每一层只解决一件事。

接入层负责和外部系统打交道，包括 Git 仓库的读取、工单系统的拉取、CI 平台触发构建、IM 机器人推送通知。它的核心是适配器模式，每一种外部系统就是一个独立适配器，上层不直接感知外部接口差异。

编排层是整个系统的大脑，包含 Coordinator（调度中枢）、Planner（任务拆解）、Task Queue（任务队列）、状态机。它不负责具体干活，只负责决定“谁在什么时候干什么，干完交给谁”。这里的核心数据结构是一个任务图（Task Graph），节点是任务卡，边是依赖关系。

执行层是干活的智能体集合，按岗位划分，比如需求分析 Agent、编码 Agent、测试 Agent、评审 Agent、文档 Agent。每个执行体只持有与自己岗位相关的角色说明、工具白名单和输出模板。

模型层做统一网关，屏蔽不同大模型 API 的差异，统一管理上下文长度、温度参数、重试策略和成本配额。一个执行体在同一个任务里可能调用两次模型，两次走的模型不完全一样——这层就是做智能路由的。

2.2 核心组件和它们的真实职责

Coordinator 是整个系统的单点入口，也是唯一允许调用 Planner 的组件。它接收外部任务后先做一次意图分类：是新功能开发、bug 修复、代码评审还是文档同步？不同意图进入不同的子流程。

Planner 拿到意图后，把任务拆成若干张任务卡。每张任务卡包含任务编号、目标描述、输入引用、输出物、验收标准、依赖关系。我要求 Planner 拆出的任务粒度必须满足一个硬性标准：一个智能体在自身上下文窗口内能够独立完成，如果它需要反复查看超过两个大文件，就说明拆粗了。

执行层的每个 Agent 有自己的角色提示词，但不允许私自修改。角色提示词由专门配置统一管理，改配置需要走版本库评审。这一点极其重要——我们在测试阶段发现，允许 Agent 自己改角色设定，运行二十个任务后它的行为就完全走样了。

Critic（评审 Agent）是质量门禁的执行者。它不产代码，只做三件事：核对任务卡到实现的覆盖率、检查是否符合团队规范、判断是否有明显安全隐患。Critic 的意见不是参考性的，而是阻塞性的，返回值不合格，编码 Agent 的任务状态就直接回到“待修改”。

2.3 智能体之间的通信协议：消息不是聊天

多智能体系统最容易做错的是让智能体互相“聊天”。两个 Agent 之间来回自然语言对话，看起来智能，实际上不可控、不可审计、还会迅速污染上下文。我们在 Agency Agents 里用的是结构化消息协议。

每条消息包含消息类型、发送者、接收者、关联任务卡编号、负载、时间戳。负载按消息类型定义 schema，比如 CodeProduced 消息的负载包含变更文件列表、关键实现说明、需要评审人关注的风险点。智能体收到消息后只解析 schema，不做自由发挥。

另外还有一个“共享黑板”机制，用于存放全局可见但低频读取的信息，比如架构决策记录、当前迭代目标、禁止事项清单。智能体平时不读取黑板，只在 Planner 下发任务卡时把相关黑板条目作为引用塞进任务卡。这样既保证信息能查到，又不让全局信息占据上下文。

2.4 为什么这样设计：解耦、容错与可观测

这套架构不是一次性拍脑袋定的，而是被踩坑逼出来的。最早版本我们让所有 Agent 共享上下文，结果一个 Agent 的幻觉污染了整条链路；后来改成全隔离，任务交接时信息又丢失严重。最终的四层架构是妥协后的最优解。

解耦让故障被隔离在单个 Agent 内，某个编码 Agent 连续输出不合格，Coordinator 可以直接替换它的模型配置或角色描述，不影响其他模块。容错体现在重试机制：任务失败不会无限重试，而是带着失败日志回到 Planner 重新规划，由 Planner 决定是缩小任务范围还是换执行体。

可观测是我们最看重的收益。结构化消息流本身就是日志，我可以按任务编号回放“这个功能是怎么一步步做出来的”，这对于做复盘、找责任方、向管理层解释成本都极其有用。过去人工协作是黑盒，现在多智能体协作是白盒，这是架构带来的额外红利。

3. 协作不靠堆 Agent 数量：角色、任务与冲突处置的设计细节

3.1 角色划分的两种思路与初始配置

角色设计有两个方向：按工种分，类似前端、后端、测试；按流程阶段分，类似需求、设计、实现、验证。我在实践中的结论是，初期按流程阶段分更稳，因为阶段之间的交接边界清晰，工种分法容易出现多个 Agent 改同一个文件的冲突。

第一版我配置了六个角色：需求解析 Agent、架构规划 Agent、编码 Agent、测试 Agent、代码评审 Agent、文档 Agent。你可以按照团队规模增减，但有一个原则保持不变：同一时刻，同一个文件最多只能有一个写权限的 Agent。编码 Agent 写，评审 Agent 只读，测试 Agent 只跑不改。

角色描述文件不要写得太玄，重点是写清楚输入、输出、工具边界。需求解析 Agent 的工具清单里只有读取工单和写任务卡两项权限，它甚至不能读代码文件，强制它专注于需求结构化。

3.2 任务分解的粒度标准：一个任务一张任务卡

任务卡是协作的最小单位，它决定了 Planner 的拆解质量。我在系统里把任务卡做成了强制 schema，除了目标描述，还必须包含验收标准、涉及文件的白名单、相关任务卡引用、禁止触碰的模块列表。

一个反复出现的问题是，Planner 容易把“修复登录超时”这种模糊任务直接甩给编码 Agent，编码 Agent 就会自己脑补方案。后来我给 Planner 加了一条规则：如果任务卡无法写出可验证的验收标准，就退回需求解析 Agent 补信息，不允许带着模糊目标进入执行层。

粒度控制在实战中比想象中更难。我最后摸索出的经验是：一个任务卡涉及的代码 diff 控制在二百行以内，涉及的模块不超过两个；如果需要动数据库表结构或对外接口，必须拆出独立的架构评审任务。

3.3 共享上下文与记忆管理：少共享，多引用

多智能体协作最大的技术陷阱是“上下文共享”。最开始我们让所有 Agent 都能访问全局记忆库，结果只是让幻觉传播得更远。现在的方案是少共享、多引用。

短期记忆挂在任务卡上，任务卡关联哪些需求原文、哪些接口定义、哪个版本的代码，执行 Agent 只读取关联内容。长期记忆存在项目知识库里，包括架构决策记录、技术选型理由、历史踩坑笔记，用向量检索按需召回。

关键操作是写摘要而不是贴原文。编码 Agent 完成一个模块后，必须输出一段不超过三百字的实现摘要，存入黑板，而不是把整个 diff 同步给所有相关 Agent。摘要由专门接口生成，强制压缩，避免上下文膨胀。

维护记忆库也需要成本。我们每周末有一个“记忆整理”任务，由文档 Agent 扫描本周新增摘要，合并重复、标记过期、更新架构决策记录。没有这一步，知识库会在运行一个月后变成大型垃圾场。

3.4 冲突仲裁与质量门禁：让 Critic 拥有一票否决权

多个 Agent 协作，冲突不可避免。最常见的冲突是接口约定不一致：前端 Agent 期望返回字段是 user_name，后端 Agent 实现的是 username。这类冲突不靠聊天解决，靠仲裁机制。

我们的仲裁流程是：Coordinator 收到双方的状态报告，将冲突描述和各自引用的接口定义发给架构规划 Agent，由它判断哪一方符合全局架构。如果架构规划 Agent 也无法确定，就升级为人工裁决，并在任务卡上标注“需要人工确认”。流程写死后，冲突处理时间平均从小时级降到分钟级。

质量门禁是最后一道防线。Critic 的输出标记为 Approved 或 RequestChanges，RequestChanges 附带必须修正的具体问题列表。编码 Agent 只能根据列表修改，不得反驳，修改后重新提交给 Critic。连续两次 RequestChanges 后任务自动升级给人工负责人，不允许无限循环。这条规则挽救了我们的 token 预算。

4. 从概念到落地：实施路径与可复制的接入步骤

4.1 环境准备：模型网关、沙箱与配额

落地第一步不是写代码，而是搭好运行环境。我强烈建议先做一个模型网关，把不同模型的调用统一到一个服务里。原因很实际：同一套系统跑在弱模型上可能完全跑不通，跑在强模型上成本又承受不了，只有网关才能让不同任务路由到不同模型，并且随时切换。

执行环境用沙箱容器跑，容器内限制网络访问，只允许拉取依赖和推送产物到指定目录。编码 Agent 的写盘权限限定在仓库的 feature 分支工作目录，任何对系统目录的写操作都会被拦截。容器的文件系统是临时的，一次任务结束自动销毁，防止脏数据残留。

配额和超时提前设好。我们初期每个任务的 token 预算上限是 15 万，超时上限是十分钟，超预算的任务自动触发 Planner 重新规划。没有这些限制，你会在第一个不眠之夜收到六位数的账单。

4.2 先拿一个小项目做探索：选型和范围边界

多智能体系统最忌讳上来就接核心业务仓库。我挑选实验项目时用了四个标准：独立仓库、代码量不超过五万行、有完整的自动化测试、业务边界清晰。一个内部管理系统的一站式模块，恰好符合所有条件。

接入步骤是固定的：先把仓库全部代码和关键文档向量化，塞进项目知识库；再编写项目说明文件，描述模块目录、技术栈、常用命令和禁止事项；最后用三张历史工单做回归验证，看系统能不能从工单文本走到可合并的代码。

探索阶段不要追求完美，目标定成“任务完成率不低于百分之六十，且失败原因可复现”就够了。我们第一周只跑到百分之四十三，但每一个失败案例都能定位到具体的断点，这就说明系统基线可改进，值得继续推。如果连日志都解释不了失败原因，说明架构有问题，要回头改因子而不该调参硬推。

4.3 对接现有仓库与 CI：让评审堵在合并之前

跑通单任务后，下一步是把 Agency Agents 挂到真实研发流程上。第一步接入点是分支创建事件：每次新功能分支创建，Coordinator 自动拉取关联工单，生成任务卡并派发给规划 Agent。第二步接入点是 PR 创建事件：评审 Agent 自动对 diff 做初评，结果回写在 PR 评论里，状态是 ready 或 needs-work。

接入 CI 时，我坚持在 CI 里跑一个“Agent 回归任务”：每次构建完成后，用测试 Agent 独立生成一条冒烟测试用例清单，和 CI 已有的测试结果做比对，用来发现测试盲区。这个设计不是为了替代 CI，而是提供第二双眼睛。

权限上有一个铁律：智能体绝对不能拥有直接合并主分支的权限。机器人的账号权限收紧到只能推送分支、创建评论、读取构建结果。真正合并动作始终由人工触发，这是底线，后面第六部分我还会展开。

4.4 可观测与评测：不只盯着代码通过率

落地之后怎么评判它到底值不值？我建议分三层看：任务层指标看任务完成率、一次通过率、平均返工次数；流程层指标看单个需求从工单到合并的时间中位数；系统层指标看 token 成本、故障升级次数、人工介入次数。

一开始我只盯代码测试通过率，后来发现这是最不可靠的指标——测试通过只说明当前用例过了，根本不能说明需求实现了。后来我把“需求解析 Agent 的结构化任务卡与验收标准匹配度”也纳入评测，每两周抽十个任务做人工抽查，这个指标比测试通过率更能预测是否会返工。

日志系统必须闭环。每条消息流都要进检索系统，支持按任务编号、Agent 名、时间范围查回放。我踩过最大的坑是日志只记录成功消息，导致失败定位全靠猜。现在所有失败消息照样落库，只是标注状态，这个改动让问题定位时间缩短了百分之八十。

5. 落地之后，开发团队的工作方式被改成了什么样

5.1 人机分工的新边界：人做裁决，Agent 做执行

系统稳定跑起来之后，团队内部最明显的变化是每个人都在重新定义自己的工作。常规的枚举型修改、接口适配、批量测试，Agent 完成得又快又好；而需求存在二义性、跨模块改造、系统性能调优这类工作，Agent 会频繁找人或产生误判，这时候人的介入价值最高。

我们最后沉淀下来一句话：人负责定方向和守边界，Agent 负责填细节。开发者在任务卡上写清楚“不要动公共库的接口签名”，编码 Agent 在实现时就真的不会碰，这比事后 review 拦截要省力得多。把约束写在任务卡前端，是这套系统让人越用越顺手的关键。

5.2 开发者的角色迁移：从写代码的人变成定义任务的人

组织里最不适应的其实是老手。过去他们的优势在写代码快、经验足，但在多智能体模式下，写代码这部分价值被大幅稀释。新的优势变成了能不能把模糊需求拆清楚、能不能设计出 Agent 也能遵守的约束、能不能在评审冲突里快速做出正确裁决。

反应快的人已经主动转向“Agent 流程设计师”的角色：设计任务卡模板、调优角色描述、整理知识库的边界规则。他们说到底就是在做一件事——把团队过去只可意会的经验，显性化成机器能读的规则。这个角色我现在觉得是未来研发团队最重要的岗位之一。

5.3 迭代节奏与质量前移的实际变化

流程改变后，最直观的变化是例行功能迭代变快了。过去一个中等模块从工单到提测要三天，现在理想情况下一天内能从需求解析走到 PR，人工只需要在最后做合并确认。时间主要省在两点：Agent 之间交接不用等人，Critic 在编码阶段就打回了大部分问题，而不是等人力评审时才发现。

质量前移的收益比速度更值钱。过去 bug 是在测试阶段被发现的，现在很多问题在编码 Agent 提交前就被 Critic 拦截，修复成本从“改完再走一遍全流程”变成“在沙箱里改一下再提交”。人力评审的关注点也从“有没有低级错误”变成了“整体方案是否合理”。

5.4 组织层面的边界意识：别把 Agent 当员工

我们必须反复提醒自己：Agent 没有连续性判断能力，它今天的表现在很大程度上取决于今天任务卡和上下文的质量。把 Agent 当稳定员工用，早晚会被坑。

所以我们定了三条红线：生产配置变更必须人工执行；对外承诺的口径必须人工复核；影响核心数据的操作必须保留人工审批。这几条红线写进了项目说明文件，Agent 在任务卡里看到相关关键词就会自动打上需人工介入标签。这不是教条，是拿真实事故换来的。

6. 高频踩坑清单：上下文污染、失控循环与权限边界

6.1 上下文污染：一个任务卡带坏一片代码

最大的坑，没有之一。第一次大规模运行两周后，我们开始发现某些模块的命名风格突然从下划线变成驼峰，细查之后发现是编码 Agent 在处理任务时引用了黑板里一条过期的接口约定，然后把它当成当前任务约束执行了。

完整复现链路是这样的：Planner 拆任务时把黑板里的架构决策全文贴进了任务卡，其中一条关于“字段命名使用下划线”的旧记录没有标注有效期；编码 Agent 把它当作硬性规范，产生了和现有代码风格冲突的改动；Critic 因为只检查任务卡覆盖率，没有发现风格漂移，于是这条代码被合进了主干。

修复方案分两层：黑板条目全部加元信息，包括生效版本、维护人、过期日期；任务卡引用改用摘要与指针，不再复制全文。这次之后我们又加了一条规则——凡是涉及命名风格的约束，必须附上代码仓库里现有代码的正反示例。上下文是资源也是污染源，给信息的程度远比信息本身重要。

6.2 失控循环：Critic 与编码 Agent 的无限拉扯

Case 来自一个前端模块重构。评审 Agent 第一次驳回后，编码 Agent 修改了；第二次驳回理由是“代码可读性不足”，这一次编码 Agent 无法精准理解，改出来的东西反而更糟；第三次驳回后，两个 Agent 开始在消息里互相解释，token 消耗以秒级速度上涨。

问题根源是驳回理由太模糊，编码 Agent 的修改没有收敛方向。我们改了评审规则：Critic 的 RequestChanges 必须附带“具体修改点 + 修改后验收方式”，比如“把函数拆成三个单一职责函数，然后跑新增单元用例”而不是“提升可读性”。

同时加上硬性上限：同一个任务的修改循环最多两次，超过后自动升级给人。任何参数调优都是辅助，只有强制升级机制才能真正止血。自从加了这个限制，系统再没烧过异常账单。

6.3 权限边界：最小权限的智能体也会犯错

机器人账号权限收紧到最小时，整体是安全的，但细看仍有漏洞。第一次事故是编码 Agent 在沙箱里跑测试时，使用了有网络权限的镜像，导致它把依赖解析到外网源，行为不可控，而且日志里看不出它访问了哪些域名。

之后我们给沙箱网络加了白名单，只允许访问公司内部的包镜像源。文件的写权限也做了进程级限制，Agent 只能通过一个受控的文件操作接口改动工作目录，不能直接落盘到任意路径。

审计日志的保存时长不能太短。我们保留三十天，并且要求所有 Agent 的外部调用都带唯一 traceId。有一次排查问题，就是靠 traceId 串起了“某 Agent 误读配置→错误连接测试环境→覆盖了测试数据”的完整链路，才定位到是配置读取逻辑的问题，而不是 Agent 本身瞎写。

6.4 成本控制：别让全线模型为你打工

多智能体系统比单智能体调用贵得多，因为角色多了，单条任务链路的模型调用次数翻了几倍。第一版全部用同一档强模型跑，一周的成本比几十人的团队人力还贵，立刻被要求下线。

现在的路由策略是分级用模型：需求解析和文档摘要这类任务用性价比模型，代码生成和评审用能力最强的模型，测试用例生成用中间档。同时加了结果缓存，相同任务卡重复运行时直接返回上次结果。经过这轮优化，成本降到最初的百分之三十，而关键任务的质量不降反升。

我现在还会按周跑一次成本报表，按 Agent 排行。谁花的钱多、产出是否值得、有没有必要换模型，一目了然。多智能体系统落地到最后，拼的不是模型而是工程管理。

最后分享一个我实际操作中的心得。如果你准备在自己团队落地这套系统，第一个要写的文件不是架构文档，而是一份“AGENTS.md”，就是给智能体看的团队说明，比 README 更精确。里面写清楚技术栈、模块目录、编码规范、禁止事项、常用命令、以及“不确定时必须停下询问”。这份文件决定了智能体理解你项目的起始水位，它写得好不好，直接决定后续跑多个任务时是丝滑还是处处卡壳。等你能把团队的隐性约定写成这份文件，重构的第一步就算真正落地了。