企业官网建设流程全解析

先给自己提个醒：本文不是某个开源框架的评测，也不是"跑通一个多智能体 Demo"的教程。我分享的是过去几个月，在公司内部把一个中大型研发团队的工作流，逐步拆解、重组、交给一组大模型 Agent 去协作的过程。我们内部把这套方案统称为 Agency Agents，它不是一个现成产品，而是我们自己定义的一种多智能体协作范式：用一组各司其职的角色代理，去接管软件开发流程里那些标准化、可编排、可审计的环节，把人类工程师从重复劳动里解放出来，专心做决策和创造。

如果你正在纠结"多智能体系统到底怎么落地"、"多个 Agent 是放一个对话里开会还是分层调度"、"接入之后会不会代码没写完先烧掉一堆 Token"，那这篇文章值得你花十分钟看完。

1. 为什么要把开发团队"重构"成智能体：从一次需求变更说起

1.1 传统团队协作的真实瓶颈

触发我想法的导火索，是一次看起来很小的需求变更。产品要把订单列表的排序规则从"按下单时间"改成"按优先级排序"，影响范围却牵扯到后端查询、缓存策略、前端列表渲染、埋点口径和帮助文档。按传统流程走一遍：需求评审一轮，接口设计一轮，后端开发两天，前端联调一天，测试发现两处边界问题，改完重新跑回归，文档最后拖了两周才补上。

这中间的信息丢失发生在哪？评审会上讨论过的边界条件，开发时只记住了 80%；联调时口头确认过的字段语义，没有沉淀到接口契约里；测试报告里写了一个偶发问题，但没人定位根因，最后不了了之。人没有偷懒，但信息通道本身是有损的。

这里有个残酷的事实：团队规模越大，角色越多，信息传递的损耗就越严重。即便有 Wiki、有项目管理工具，真正在运行的是大家脑子里的隐式知识。传统管理靠流程文档和会议去对抗这种损耗，但流程文档本身又会滞后，会议本身又会增加沟通成本。我想找一条更直接的路：能不能让信息在整个研发链路里，以结构化、可追踪的方式自动流转？

1.2 单个聊天机器人解决不了的问题

一开始我以为接一个大模型对话机器人就能解决：把项目文档全部喂进去，让它回答问题。结果发现单个对话窗口有三个硬伤。第一，上下文窗口有限，文档一多就开始遗忘前面的约定，问到最后它经常前后矛盾。第二，工具不专，它既要读代码又要改接口文档还要看测试日志，但每个场景都需要不同的工具和不同的决策规则，全部混在一个上下文里，提示词越写越长，效果越来越差。第三，缺少角色约束，同一个模型用同一套语气回答需求问题和代码审查问题，输出的深度和格式都不对。

我换了一个思路：与其训练一个全能助手，不如模拟一个团队。让每个角色拥有独立的 Agent，每个 Agent 有自己的提示词、工具集和记忆策略。它们之间通过结构化消息协作，而不是挤在一个聊天窗口里各说各话。

先声明一点，这里说的"重构"不是裁员。我们不是让智能体替代人，而是重新分配人和机器的分工：人可以退到决策点和审批点，AI 去执行那些可以标准化、可以被反复校验的中间环节。

1.3 Agency Agents 这个名字想表达什么

Agency 在英文里有"代理权"和"代办"两层意思，我们取的是"把一件事放心地交给某个角色去推进"的含义。Agency Agents 强调的是角色代理能力：每个智能体不是为了聊天而存在，而是为了在某段流程里负起责任、完成一个具体的职位性任务。

这套范式的核心原则，一句话就能概括：流程定义清楚，分工定义清楚，边界定义清楚，然后才轮到模型发挥智力。很多人把多智能体系统当成"模型堆在一起就会自动变强"，实际恰恰相反。模型是最容易替换的部分，流程、协议、边界、上下文治理，才是系统能不能稳定跑起来的关键。

2. Agency Agents 整体架构：编排器、角色代理、共享黑板与工具层

2.1 三层一板的设计

先给整体架构画个轮廓。

┌──────────────────────────────────────────────┐ │ 人工控制台（审批点） │ ├──────────────────────────────────────────────┤ │ 编排器 Orchestrator │ │ 需求解析 / 任务分解 / 状态机 / 调度决策 │ ├────────┬────────┬────────┬────────┬──────────┤ │ 需求 │ 编码 │ 测试 │ 审查 │ 文档 │ │ Agent │ Agent │ Agent │ Agent │ Agent │ ├────────┴────────┴────────┴────────┴──────────┤ │ 共享黑板：需求基线 / 接口契约 / 测试报告 │ ├──────────────────────────────────────────────┤ │ 工具层：代码仓库 / CI / 静态检查 / 文档站点 │ └──────────────────────────────────────────────┘

最上面是人工控制台，所有 Agent 不能触碰的关键动作——合并代码、发布、改权限——都在这里等待审批。中间是编排器 Orchestrator，它负责接收需求、拆解任务、维护状态机、调度各个角色。再往下是真正干活的角色 Agent，包括需求、编码、测试、审查、文档等。值得留意的是，这些角色 Agent 不直接互相调用，它们通过共享黑板读写公共信息，所有跨角色协作都由编排器中转。

2.2 每个角色 Agent 的内部结构

每个 Agent 不是简单的一句提示词，我把它实现成四件套：角色配置、工具清单、工作记忆、知识记忆。

角色配置包含 System Prompt 和能力边界。最难写的是能力边界。比如编码 Agent 的 System Prompt 里必须写清楚：它只能修改指定模块目录下的代码文件，不得修改 CI 配置文件、部署脚本和依赖锁定文件。这些边界不写清楚，后面权限事故一定找你。

工具清单要按角色裁剪。测试 Agent 只能调用测试框架和静态检查工具，不能调用写部署脚本的工具；文档 Agent 只能读代码结构、生成文档草稿，不能直接推送发布。工具本身就是权限的一部分，比提示词里的"请勿操作"可靠得多。

工作记忆指短期会话，负责承接当前任务的上下文片段。知识记忆则是长期记忆，我们放在向量数据库里，按任务按需检索。需求 Agent 主要检索历史需求与用户反馈，编码 Agent 主要检索接口契约与代码结构说明，测试 Agent 主要检索验收标准和历史缺陷。

2.3 为什么我选择编排者-工作者模型，而不是纯群聊

设计时我对比过两种多智能体协作模型。一种是群聊式，让所有 Agent 在一个共享会话里自由发言，谁都能接话，谁都能干活。另一种是编排者-工作者模型，所有通信都经过编排器，任务路由由编排器统一决定。

群聊式在演示场景很热闹，落地就是灾难：上下文爆炸、责任不清、无法审计。谁先发言、谁插话都不受控制，一个 bug 讨论会蔓延成十个子话题，最后你不知道该信谁的结论。编排者-工作者模型看起来绕路，但换来了可控性——每条消息都有 sender、receiver、task_id，每个决策都有记录。

我当时的取舍准则是：如果你希望系统可审计、可回滚、可干预，就别让 Agent 自己开会。想要多智能体系统真正进生产环境，编排器带来的这点"结构冗余"绝对值回票价。

3. 角色 Agent 之间的协作协议：状态机、消息格式与上下文共享

3.1 任务状态机：从 ready 到 done 的完整流转

协作系统的地基是状态机。我把每个任务的生命周期定义为：pending → ready → running → review → blocked → done，外加一个 canceled。排程器只把 ready 状态的任务分发给对应角色 Agent，Agent 拿到任务后在 running 状态执行；如果依赖缺失就转 blocked，等待前序任务完成；只有通过人工或自动审查的任务才能进入 done。

这里最容易犯的错误是把状态机做得太"活"。一开始我给任务加了十几个子状态，想让系统显得智能，结果运维成本暴涨。后来砍到只剩这些，所有分支逻辑一页纸能写完。

3.2 消息协议长什么样

Agent 之间不传自然语言长文本，传结构化消息。我们用的消息格式是 JSON，核心字段包括 message_id、task_id、sender、receiver、msg_type、payload、created_at。

{ "message_id": "msg_8f3a91", "task_id": "task_1207", "sender": "test_agent", "receiver": "orchestrator", "msg_type": "task_result", "payload": { "exit_code": 1, "summary": "订单排序接口的边界用例未通过", "evidence": ["test_case_ids:tc_001,tc_004"], "suggestion": "需要编码 agent 检查排序参数为空时的处理" }, "created_at": "2025-06-11T15:04:21Z" }

这个例子很有代表性：测试 Agent 上报失败时，必须带 evidence 和 suggestion。这个约束不是可有可无——它逼着测试 Agent 在失败时做出初步诊断，而不是扔出一堆原始日志让下游猜。

3.3 共享黑板：不把所有上下文都塞进每个 Agent

上下文共享是另一个大坑。第一版设计里，我把所有 Agent 的输出都汇总给下一个 Agent，结果每经过一手，内容就膨胀一次，很快就把大模型窗口撑爆。

后来引入了共享黑板模式。黑板上只放四类稳定信息：需求基线、接口契约、测试报告、变更记录。普通消息直接传递，需要黑板信息时，Agent 按需做向量检索取回相关资料。这样每个 Agent 每次只读取和当下任务相关的 5 到 10 个片段，而不是拿着全量项目文档做聊天。

用大白话说：过去是每个人进会议室听三小时汇报，现在是大家共享一个在线文档，谁需要看哪一段就翻哪一段。

3.4 工具调用与人机审批点

Agent 要真正干活，必须能调用工具。我们封装了统一的工具执行层，暴露给 Agent 的是函数签名加说明。工具执行层负责鉴权、超时、重试、日志记录，Agent 本身不直接接触底层执行命令。

人机审批点我放在三个地方：合并代码前、发布前、以及任何涉及项目配置文件修改前。审批点是"重构开发团队"和"完全裁掉开发团队"之间的安全阀。无脑全自动不是目标，可控才是。尤其在上线初期，哪怕流程已经很顺，也要保留人工审批，等数据证明系统稳定了再逐步放宽。

4. 落地踩坑实录：死循环、上下文污染和权限越权是怎么定位的

4.1 编码 Agent 与测试 Agent 的死循环

第一个坑出现在试运行第三周。一个模拟项目 X 的任务被调度后，编码 Agent 提交了实现，测试 Agent 跑出一条失败用例，编码 Agent 修改后再提交，测试 Agent 又报出另一条失败。如此反复了 20 轮，Token 烧了不少，问题没解决。

我把消息日志全量拉出来，一条条看。真相是：测试 Agent 每次失败后只报"第几行断言失败"，而编码 Agent 完全不知道测试用例的意图——它只是机械地改到报错消失为止。更要命的是，测试 Agent 并不了解编码 Agent 改了什么，两边各修各的，像两个人互不交流地改同一篇作文。

修复分三步走。第一，测试 Agent 的失败消息必须附带最小复现说明和它理解的预期行为，不只给断言输出。第二，编码 Agent 在提交变更时必须写清楚设计意图，测试 Agent 在判断是否回归通过时要参考这个意图。第三，强化最大循环次数，超过 4 轮立即转人工。

这个坑其实揭示了多智能体协作的一个本质问题：Agent 之间没有真正的"共同理解"，协议里不带上下文的对话，本质上还是互相猜。后来我把"消息必须携带足够诊断信息"写进协议规范，类似的死循环减少了 80%。

4.2 上下文污染导致的"变笨"

第二个坑很隐蔽。需求 Agent 为了让编码 Agent 理解完整背景，把一份 60 页的 PRD 原样传了过去。编码 Agent 的窗口立刻被无关内容占满，核心接口定义反而没进入有效上下文。结果生成的代码接口和契约不一致，审查 Agent 怒气冲冲地打回，编码 Agent 一脸懵。

定位方法也很简单：把每次请求的上下文做采样记录，看看编码 Agent 实际看到的内容里，真正相关的占比是多少。我们发现大量任务的有效上下文占比不足 20%，有些甚至不到 10%。

解法是内容裁剪和摘要分层。黑板上保存全文，传给 Agent 的是按角色需要裁剪过的视图：编码 Agent 只需要接口契约、边界条件和相关模块文件树；测试 Agent 只需要需求验收标准和变更 diff；审查 Agent 只需要代码 diff 和测试结论。信息不是越多越好，越精准越好，这个原则在 LLM 场景下比任何场景都适用。

4.3 工具返回失败但 Agent 反复重试

这个坑属于工具层设计问题。最开始工具执行层只返回一个 exit_code，失败时 Agent 看不到标准输出，只能盲目重试。有次 CI 脚本因为环境变量缺失挂了，Agent 重试了 6 次，每次都触发一次完整的构建，白白浪费了半个小时的算力。

我把工具返回值改成了结构化对象，包含 exit_code、stdout_summary、stderr_sample、logs_url、suggested_action。更重要的是在工具层做失败分类：网络类错误可以重试，逻辑类错误禁止重试，必须先生成诊断报告再决定下一步。

这里有个通用经验：多智能体系统的错误处理逻辑，90% 要在工具层解决，而不是指望模型"变聪明"。模型擅长生成代码，不擅长猜编译器的脾气。工具层把错误分类做好了，Agent 的愚蠢行为就会被限制在可控范围内。

4.4 权限越权：Agent 真的会乱改文件

有次编码 Agent 在修改订单模块时，顺手改掉了一个公共配置文件里的超时参数。原因是它检索到的历史上下文中包含类似操作，于是自主复制了那种改法。这个案例给我提了个醒：Agent 没有"边界感"，它只会忠实执行提示词和上下文暗示的东西。

我们的对策是三层权限控制。第一层 Scoped Token，每个 Agent 的令牌只能访问自己的目录；第二层文件规则，用匹配规则禁止 Agent 修改非授权路径，例如配置目录和部署脚本；第三层敏感操作审批，凡是碰流水线配置，一律弹人工审批。这套下来权限事故基本清零。

顺便说一句，权限规则要写进工具层，不是写进提示词。提示词可以随时被上下文挤掉，工具层的强制校验不会。

4.5 Token 成本失控的计算

还有一笔账必须算清楚。多智能体的成本不是每个 Agent 各自调用一次模型，而是消息、上下文、重试共同叠加。用一个中等复杂度需求举例：编码 10 次调用、测试 15 次调用、审查 5 次调用，如果每次上下文中都带 8000 token，一次需求光上下文就吃掉几百万 token。

我的压缩策略有三条。第一，上下文只传摘要和裁剪视图，减少重复加载。第二，简单任务走小参数模型，复杂任务才走大参数模型——不是所有 Agent 都需要最强的那个脑子。第三，对历史结果做缓存，比如测试 Agent 已经验证过同一 commit 的某一用例，就不重复跑。

成本控制不是优化项，是必选项。不做这三条，多智能体系统的运行成本能比人工还贵。

5. 重构前后怎么度量：交付周期、缺陷逃逸率与技术成本

5.1 我们用什么指标证明"重构"有效

聊架构和协议，最终还要回答一个问题：这套东西到底有没有用？我们选了四个指标：需求交付周期、代码审查轮次、缺陷逃逸率、文档完整率。

需求交付周期从需求拆分完成开始算，到代码合并、测试通过、文档更新完成为止。代码审查轮次反映协作质量，轮次越多说明上下文传递越差。缺陷逃逸率看的是测试 Agent 放过的 bug 在联调阶段被人工发现的占比。文档完整率就简单统计关键文档是否齐全、有没有过期。

5.2 两组对比数据

我们在内部找了两组需求背景相近的模块做对比。样本量不大，但趋势很能说明问题。

交付周期缩短接近一半，来源不是 AI 写代码更快，而是上下文不丢失，测试和审查的反馈更及时。过去审查轮次多，是因为编码者没有把设计意图写清楚，审查者靠猜；现在结构化的任务协议把意图带过去了。

最意外的收获是文档完整率。过去文档总是最后写、没人写，现在文档 Agent 跟着每次变更实时更新接口文档和变更记录，文档不再滞后。这比代码生成给我的触动更大——多智能体系统最大的价值，可能不是把代码写出来，而是把过程中失去的显性信息找回来。

5.3 成本账：多智能体不是免费的

要泼一盆冷水：多智能体系统会把一部分人工成本转移到模型调用成本上。上面那个 8 人日的需求，按我们当时的模型定价，智能体调用成本大约相当于半个开发工程师一天的人力成本。这是可接受的，因为同时释放了一个后端和一个测试的重复劳动。

但如果之前提到的压缩、缓存、模型分层不做，成本会涨到人力成本的 2 到 3 倍。我见过有团队把不相干的上下文全喂进去，一个简单需求烧出一顿大餐的钱。所以我的建议是：上线前先把成本预算和监控做好，别让成本账变成事故。

6. 多智能体适合谁：引入前的边界评估与渐进式落地

6.1 适合引入的条件

不是所有团队都适合上多智能体。我总结出三类高度适合的先决条件。

第一，需求边界清晰，有明确的验收标准和字段级规格。Agent 最怕的是连需求文档都写不清楚，因为你不给它明确边界，它就会自己脑补一个。

第二，自动化测试体系成熟。测试 Agent 才有判断依据。没有测试基线，代码 Agent 根本不知道什么叫"改对了"，审查 Agent 也只能靠代码风格猜。

第三，流程已经模板化。固定的分支模型、固定的发布流程、固定的接口文档格式。这些流程可以被编排器翻译成状态机，模板化程度越高，编排成本越低。

6.2 不适合的场景

反过来，三类场景千万别急着上。

第一类是探索型需求，方向不明，需要大量人造讨论和拍板，Agent 的产出只会增加噪声。第二类是需求变化极其频繁、连文档都来不及更新的场景，黑板上永远是一堆过期信息，Agent 越勤快错得越离谱。第三类是责任边界极度敏感的场景，比如涉及对外审计或不可回滚的操作，除非你能把每一步决策都完整记录，否则宁可保守。

我自己的判断是：多智能体是流程的放大器。流程清晰，它放大效率；流程混乱，它放大混乱。它不是一个能代替你把流程梳理清楚的东西，而是一个在流程清晰基础上锦上添花的执行引擎。

6.3 渐进式落地路径

如果条件合适，不建议一步到位。我建议分三步走。

第一步只上文档 Agent 和代码审查 Agent，让它们做辅助角色，数据同步到人工流程里。这一步的风险最小，收益也很直观——文档质量和审查质量都会有提升。

第二步把测试 Agent 接进去，和现有 CI 集成，跑失败用例并自动生成缺陷报告。这时候测试 Agent 开始和代码仓库、CI 系统交互，工具层和权限规则要配齐。

第三步才考虑编码 Agent 真正写代码，并且一定要保留人工审批点。以我们团队的经验，第三个月才让编码 Agent 接触主仓库，目的是先让基础链路足够稳，再逐步放开写代码的权限。

7. 一点个人体会与后续要补的课

写到最后说点掏心窝的话。这次"重构开发团队"最大的收获，并不是某个环节的自动化，而是系统逼着我们把过去那些藏在人脑里的隐式流程全部显式化了。权限边界怎么写、消息格式怎么定、状态机怎么流转、审批点放在哪里——这些工作在传统管理里模模糊糊，在多智能体协作里却必须一清二楚。

一个常见误区是把多智能体当成"大模型堆在一起就会自动变强"。实际恰恰相反，模型是最容易替换的部分，协议、边界、上下文治理才是系统能不能稳定运行的关键。编码 Agent 代码写不好，换一个更强的模型就好；但如果消息协议混乱、上下文膨胀、没有人工审批点，换再强的模型也救不回来。

后续我打算做两件事。一是给每个 Agent 增加更细粒度的操作审计，让每一次工具调用都能追溯到决策链，这样出了问题可以直接复盘是哪条消息带偏了方向。二是把黑板存储从文件式改成事件溯源式，让信息变更历史可以被完整回放，而不是只看最新快照。

如果你也在折腾多智能体系统，我的建议是：先别急着追求酷，先把流程边界画清楚。多智能体的上限取决于模型能力，下限取决于流程设计。而真正决定一个团队能不能从中获益的，是后者。