企业官网建设流程全解析

开头先讲清楚一件事：Agency Agents 不是又一套多 Agent 框架的轮子，而是一个把“软件开发团队”整体搬到 Agent 协作体系里的落地实践。它解决的不是单 Agent 写代码的能力问题，而是多个 Agent 在一个项目里如何分工、如何对齐上下文、如何互审代码、如何把需求最后变成可部署产物的问题。我实际拆过它的源码，也把它接到一个模拟项目X的迭代流程里跑过，这篇文章不想讲概念，直接讲架构分层、任务编排、Agent 间协作协议、以及真实落地时最容易翻车的几个地方。

如果你正打算把研发流程彻底交给 Agent 来重构，或者你已经在用多个 Agent 但发现它们各干各的、互相覆盖代码、上下文经常打架，这篇文章会比较适合你。

1. 整体设计思路：为什么要用多智能体重构开发团队

需要先理解一个反直觉的结论：单 Agent 在“写函数”这类原子任务上已经够用，但在完整软件开发流程里会迅速失效。失效的原因不是模型能力差，而是上下文失配。软件开发本质上是一个长链路任务——从需求理解到系统设计、从接口定义到代码实现、从测试编写到缺陷修复，每个环节对上下文的要求差别极大。需求分析需要的是粗粒度的业务语境，代码生成需要的是精确的函数签名和数据结构定义，代码评审需要的是同时看到实现方案和约束条件。把所有这些塞进同一个上下文窗口，结果是每个环节都拿不到最优的上下文状态。

我最初也试过用一个具备全流程能力的 Agent 来跑模拟项目X，给它需求文档，让它自己生成设计、代码、测试。前几轮看着还行，但项目规模一上来，问题开始暴露，比如架构设计与编码阶段使用同一上下文导致的约束遗忘，再比如测试生成和代码生成之间互相干扰。最典型的现象是，让 Agent 在同一个会话里先写 REST API 再写对应的集成测试，它往往会把接口的行为改得更“可测”，而不是更符合需求。

Agency Agents 的设计思路正好绕开了这个问题。它的核心原则是：把软件开发过程拆分成交互的 Agent 角色，每个 Agent 维护独立的上下文空间，通过一种结构化的协作协议交换信息。这个思路借鉴了组织管理里的专业分工人效理论。就好比一个真实团队里，产品经理不会去写实现细节，后端工程师也不会在评审测试用例时纠结 Schema 设计。每个角色只维护自己领域的完整上下文，而跨角色的信息传递通过文档、接口约定和评审意见完成，而不是把所有人都拉进同一个共享大脑。

这个思路在工程上的直接收益有三个：

1. 上下文隔离。每个 Agent 只加载自己需要的那部分上下文。架构 Agent 需要的是全局模块划分和服务拓扑，编码 Agent 需要的是当前模块的接口定义和实现约束。隔离之后，context overhead 大幅降低，模型对关键信息的注意力反而更集中。

2. 约束收敛。需求的传递过程是逐层收紧的。产品 Agent 把需求解析为业务规则，架构 Agent 把业务规则解析为模块边界，编码 Agent 把模块边界解析为具体实现。每一层都是上一层输出的消费方，同时也是下一层输入的约束方，开发过程中的随意性被结构性地压缩。

3. 质量埋点前置。评审 Agent 不是等代码写完再介入，而是在每个阶段出口设置质量检查点。比如接口设计完成后先过一遍契约评审，再进入编码阶段。问题发现越靠前，修复成本越低，这个在 human team 里成立的规律，在 Agent 团队里同样成立。

所以我的判断是，Agency Agents 瞄准的不是替代 IDE 里的编程助手，而是替代“整个开发团队的协作流程”。理解了这一层，再去研究它的架构才有意义。

2. 核心架构解析：Agent 的角色划分与通信拓扑

2.1 六类角色：不是拍脑袋分的，是对齐真实研发流程

Agency Agents 的默认角色配置是六类，我先把它们是什么、各自维护什么上下文、产出什么交付物讲清楚。

产品 Agent，对应真实团队里的产品经理。它消费的是原始需求文本，输出是结构化的需求文档。这个文档不是给人看的 PRD，而是一个机器可解析的中间产物，包含业务目标、用户画像、功能清单、验收标准和边界条件。在模拟项目X的实践里，我发现产品 Agent 输出的验收标准特别关键，后期测试 Agent 生成的测试用例基本是从这里推导的。

架构 Agent，类似系统架构师。它消费的输入是产品 Agent 输出的需求文档，产出是技术方案，包括模块划分、服务拓扑、数据模型、接口契约。架构 Agent 的输出通常是一组文档加代码骨架，这个代码骨架不是为了运行，而是为了给后续编码 Agent 提供边界约束。相当于把“不要在这里写死业务规则”这类隐性知识，变成代码结构上的显性约束。

开发 Agent，承担编码职责。它拿到的输入很收敛：当前模块的接口契约、数据模型定义、依赖的外部服务接口、以及开发规范文档。开发 Agent 不需要理解全局业务逻辑，它只需要在当前模块约束下产出符合接口定义的实现。这个角色的上下文最精简，也因此能保持较高的生成质量。

审查 Agent，对应技术负责人或 Code Reviewer。它消费的输入是开发 Agent 的产出，包括代码 diff、接口定义、测试报告。输出是结构化的评审意见，按严重级别分为阻断项和建议项，阻断项会打回给开发 Agent 修复，建议项可以进入待办积累。这里需要注意，审查 Agent 不是简单地“检查有没有 bug”，它要验证实现是否满足契约，有没有偏离架构约束，有没有引入不必要的复杂度。

测试 Agent，对应测试工程师。它基于需求文档中的验收标准和架构 Agent 输出的接口契约，生成两类东西：单元测试和集成测试。测试 Agent 的工作与其他 Agent 最大的不同在于，它的产出不是业务功能，而是验证逻辑。在协作流程里，测试 Agent 往往要同时看设计文档和实现代码两边的上下文，所以它的上下文管理需要特殊处理，这点后面实操部分我再细说。

运维 Agent，处理交付和部署相关的事。它消费开发产物和部署配置，负责生成 Dockerfile、编排文件、初始化脚本，以及一份部署说明。在偏业务系统的落地场景里，运维 Agent 的产出质量直接决定了项目能不能从“代码能跑”走到“服务可用”。

这六类角色的划分，本质上是把复杂软件开发拆成六个具有清晰语义边界的工作域。边界清晰之后，每个域内的 prompt 设计、上下文管理、质量评估标准都能独立优化，而不是一个 Agent 里塞进所有规则。

2.2 协作拓扑：为什么是星型编排而不是全员互连

多智能体系统的一个必然问题是：Agent 之间怎么通信。如果让所有 Agent 自由互连，那消息复杂度会爆炸，调试起来灾难。Agency Agents 采用的是一种星型加总线混合的拓扑：所有 Agent 不直接点对点通信，而是通过一个中央协调组件交换消息，同时共享一个结构化的事件总线。

这个设计的原因有两个。

第一，可观测性。星型拓扑意味着所有消息都要经过协调器，这意味着每一步状态变化都能被记录、回放、审计。实际开发中你会频繁需要回答一个问题：“这个接口定义是谁在什么时候改的？为什么改的？”没有中央记录的通讯拓扑，这类排查基本只能靠猜。

第二，控制流管理。真实软件开发是有状态机的：需求分析完成后才能开始架构设计，架构评审通过后才能开始编码。自由互连的拓扑很难管控这类有序性。中央协调器可以把状态转换逻辑集中管理，Agent 之间没有隐式的执行顺序依赖，而是由协调器根据当前状态决定下一个分派给谁。

我补充一个实操细节：协调器节点不存业务上下文，它只存状态和消息路由信息。业务上下文始终留在各个 Agent 的本地 memory 里。这个隔离非常关键，否则协调器会变成新的上下文瓶颈。

3. 落地实操：从配置到任务协作分发的完整过程

3.1 构建协作环境：最小可用配置

Agency Agents 部署起来没有想象中复杂。我以模拟项目X为例，给出一套可直接复现的最小配置思路。需要准备的核心组件包括：协调器节点、各 Agent Worker 节点、消息总线、向量存储库，以及一个任务定义文件。任务定义文件是启动协作的入口。

任务定义文件大约长这样（配置结构已简化，便于说明）：

project: mock-project-x roles: product: model: deepseek-v3 prompt_template: prompts/product.md context_window: 32k architect: model: deepseek-v3 prompt_template: prompts/architect.md context_window: 48k developer: model: deepseek-coder prompt_template: prompts/developer.md context_window: 96k reviewer: model: deepseek-r1 prompt_template: prompts/reviewer.md context_window: 64k tester: model: deepseek-coder prompt_template: prompts/tester.md context_window: 48k devops: model: deepseek-v3 prompt_template: prompts/devops.md context_window: 32k coordinator: state_store: redis message_queue: rabbitmq max_retry_per_task: 3

这里有个关键技术选型：不同角色的模型配置可以不一样。我在实践里用混合配置的效果明显更好，架构和产品角色用通用对话模型，对语义理解要求高；开发角色用代码专项模型，对语法和框架熟悉度要求高；审查和测试角色用了带推理增强的模型，因为这两类任务本质上是逻辑判断，不只是知识复现。

注意：这里不追求所谓“最强模型”，实践下来不同任务角色的模型差异化配置，比全域使用同一模型再用 prompt 调整更有效。模型不是越强越好，而是要匹配角色的任务类型。

3.2 阶段化流程编排：Agent 们如何排队干活

多 Agent 协作流程不能一股脑全上，需要按阶段推进。Agency Agents 的默认编排是把开发过程分成五个阶段：需求解析、架构设计、编码实现、评审修正、验证交付。我用模拟项目X的实际跑法来说明每个阶段的 Agent 交互细节。

阶段一：需求解析。在这个阶段，只有产品 Agent 被激活。整个输入是一份原始需求说明，输出是一份结构化需求文档。这个阶段的重点是约束提炼，需求里往往隐含很多没写出来的限制条件，产品 Agent 的任务就是把这部分显性化。比如需求里说“用户可以通过手机号登录”，产品 Agent 应该识别出这里隐含了验证码、手机号格式校验、频控策略等多个子规则。这些规则会直接决定后续架构 Agent 的模块设计。

阶段二：架构设计。产品 Agent 完成输出后，协调器把结构化需求文档投递给架构 Agent。架构 Agent 的工作包括模块拆解、接口规划、数据模型定义和技术栈选型。它输出的技术方案会和产品 Agent 的需求文档一起存入共享存储，作为后续所有 Agent 的上下文基线。

我在跑项目X的时候发现一个规律：架构 Agent 的输出质量，基本决定了整个项目的成败。如果架构 Agent 给出的模块边界模糊，后续开发 Agent 的代码大概率也会纠缠不清；如果接口契约定义有歧义，测试 Agent 生成的测试用例也会无所适从。因此在这个阶段，值得多花轮次让架构 Agent 自检，甚至可以把架构方案丢给审查 Agent 先压一轮评审。

阶段三：编码实现。架构方案确认后，协调器会按模块粒度拆分编码任务，并分发给开发 Agent。这里注意，不同模块之间的开发是并行还是串行，取决于模块间依赖关系。如果模块 A 的接口被模块 B 依赖，那 A 的编码应该先完成，B 的编码才能开始。Agency Agents 在协调器层面处理了这层依赖，实际效果是它维护了一张有向无环图，按拓扑序排队分发任务。

开发 Agent 的工作循环是：拉取任务卡片、加载当前模块的接口契约和数据模型定义、读取相关历史代码、生成代码、提交产出物。这里的 prompt 质量非常关键。开发 Agent 的上下文里没有整个项目的全局信息，只有当前模块的约束，所以任务卡片的描述必须精确到“这个接口要接收什么参数、返回什么结构、依赖哪些已存在的函数”。

阶段四：评审修正。每个模块的代码完成之后，都需要经过审查 Agent。审查 Agent 会执行一个动作序列：读取代码 diff、对比接口契约、检查模块边界、扫描明显的 anti-pattern、生成评审报告。评审报告分为阻断项和建议项，阻断项会通过协调器打回给开发 Agent，开发 Agent 修正后再次提交审查，直到没有阻断项为止。

这里有一个我踩过的坑：如果没有在编排层限制“最大重试次数”，Agent 之间会陷入无限循环。开发 Agent 改了代码，审查 Agent 又提出新的意见，开发 Agent 再改，再被驳回……这种循环在 human 团队里会被人的常识打断，但 Agent 不会。所以必须在协调器里设置最大迭代轮数，超过之后由人接管，或者升级到架构 Agent 重新审视方案。

阶段五：验证交付。代码通过审查后，测试 Agent 开始介入，生成单元测试和集成测试，再交给执行环境跑。测试通过后，运维 Agent 接手生成部署配置和发布产物。到这一步，一个完整的迭代就算走完了。

3.3 任务编码与工作流定义：告诉 Agent 团队怎么干活

Agency Agents 允许用工作流描述文件来定义协作逻辑，我把常用的两种模式说说。

模式一：线性阶段流。所有 Agent 严格按阶段顺序执行，前一个阶段的输出是后一个阶段的输入。适合整体架构清晰、需求变化不大的项目。

workflow = [ ("product", ["parse_requirement"]), ("architect", ["design_system"]), ("developer", ["implement_module"], {"parallel": ["module_a", "module_b"]}), ("tester", ["generate_tests"]), ("reviewer", ["review_code"]), ]

模式二：反馈循环流。在阶段之间存在回环，比如审查 Agent 发现问题会回到开发 Agent，测试 Agent 发现问题也会回到开发 Agent。适合需求复杂、需要迭代收敛的场景。

workflow = [ ("product", ["parse_requirement"]), ("architect", ["design_system"]), ("developer", ["implement_module"]), ("reviewer", ["review_code"], {"on_blocking": ("developer", "implement_module")}), ("tester", ["generate_and_run_tests"], {"on_failure": ("developer", "fix_bug")}), ]

这两种模式的表达能力差异很大。线性模式好理解，适合从零开始建模；反馈循环流更贴近真实开发，但要注意设置收敛条件，避免无限循环。

3.4 上下文管理与记忆持久化

这是多 Agent 系统里最容易翻车的地方。我见过很多人把多 Agent 做成多轮对话拼接，本质上还是一个长上下文，只是在用户视角上“感觉像是多个 Agent”。

Agency Agents 的上下文管理思路值得抄：每个 Agent 有独立的本地工作内存，只保存自己负责的那部分信息；跨 Agent 的知识传递通过共享存储完成，共享存储里保存的是阶段产物，比如需求文档、架构方案、接口契约、测试报告。共享存储本身是一份结构化文档库，而不是聊天记录。这样设计的好处是，Agent 重新加载上下文时，不用重放整个对话历史，直接加载相关文档就行。

具体到代码实现上，每一次任务完成后，Agent 会把自己的产出物序列化，写入共享存储。协调器在分派新任务时，会把任务相关的共享文档组装成新的上下文，传送给下一个 Agent。整个过程中，没有哪个节点保存过全量对话历史，上下文开销被大幅压低。

4. 实战效果与对比数据：多 Agent 协作比单 Agent 强在哪

4.1 用模拟项目X跑出来的实测数据

我在模拟项目X上跑了三种模式做对比：单 Agent 全流程模式、多 Agent 无编排模式（多个 Agent 自由协作）、Agency Agents 编排模式。项目规模是一个带用户认证、内容管理、数据报表三个模块的中型系统，约 4200 行代码。

三种模式的关键数据对比如下：

单 Agent 全流程的问题清楚可见：上下文消耗高、需求覆盖率低、首次通过评审率只有三成。多 Agent 无编排模式因为有了分工，数据明显比单 Agent 好一些，但暴露了新问题：Agent 之间没有清晰的交接协议，信息传递靠对话流硬塞，模块边界一复杂就开始混乱。

Agency Agents 编排模式在需求覆盖率上的提升最明显，88% 对 61%，这个差距来源于产品 Agent 单独承担了需求解析和约束提炼的职责。没有这一步，需求信息在漫长的开发链路里会被逐层稀释。

4.2 上下文消耗优化：为什么能省一半还多

我一开始对上下文消耗总量下降这么多是有些意外的，后来复盘原因，核心在于上下文复用的机制。在单 Agent 模式里，每完成一个模块，整个对话历史都会继续保留，这些历史信息包括需求讨论、架构变动、其他模块的无关细节。token 总量是随时间线性甚至超线性累积的。

Agency Agents 模式里，每个 Agent 只在自己的工作域内读取相关文档。开发 Agent 写模块 A 时，它不需要加载模块 B 的历史代码，也不需要加载产品 Agent 讨论业务场景的全部对话。这种“按需加载”让上下文总量从“全量历史”降到“当前任务相关”，优化幅度自然大。

对成本敏感的实际项目来说，这个效果直接等于省钱。同样一轮迭代，95 万 tokens 和 220 万 tokens 的差别，按现在的模型价格计算，可能差出几倍到十几倍的成本。

5. 核心避坑指南：跑通与跑好之间的关键细节

5.1 任务定义粒度不能太粗也不能太细

任务粒度是多 Agent 系统里最微妙的设计。粒度太粗，单个 Agent 要处理的上下文会膨胀，退回单 Agent 模式的老路；粒度太细，Agent 间通信成本上升，协调器反而成为瓶颈，而且每个 Agent 的产出会因为上下文太零碎而失去全局一致性。

我实践下来，一个比较稳的粒度参考是：开发 Agent 的单次任务应该对应“一个模块内的一个功能点”。比如“实现用户认证模块的验证码发送接口”是一个好任务；“实现用户认证模块”太粗；“实现验证码发送接口里的字符生成工具函数”又太细，会让开发 Agent 无法理解验证码接口的整体逻辑，容易写出脱离上下文的零碎函数。

5.2 评审 Agent 的 prompt 要比开发 Agent 更长

这是一个反直觉的经验。很多人设计 Agent 角色时，会把主要精力放在开发 Agent 的 prompt 上，评审 Agent 随便写两句“检查代码质量”就完事。实际上评审 Agent 的 prompt 应该更长、更具体，因为它要承担判断职责。判断的标准需要显式描述：什么算阻断项、什么算建议项、检查哪些维度的契约一致性、如何处理模棱两可的情况。

我给审查 Agent 的 prompt 里加了一段硬性要求：“只依据接口契约和架构文档判断，不要根据你自己的偏好改代码风格。如果契约里没有定义某个行为，默认按最小实现处理。”这段约束加完之后，审查 Agent 的误报率下降了一半以上。

5.3 协调器的重试必须带上下文增量

这是我在跑项目X时踩得最深的一个坑。最初实现协调器重试逻辑时，如果开发 Agent 的产出被打回，直接原样把任务重新投递一次。结果发现，打回重跑后的代码几乎没有任何变化——因为开发 Agent 接收到的上下文和之前完全一样，没有新增评审意见，模型的输出自然趋同。

正确做法是，重试时把审查 Agent 的评审意见作为增量上下文追加进任务卡片。开发 Agent 重新生成时，除了原始任务描述，还能看到“上次为什么被驳回、需要修复哪些问题、具体到哪个文件哪个函数”。加了这一步之后，修正后的代码质量有肉眼可见的提升，而且迭代轮数明显减少。

5.4 消息总线不要用同步阻塞式

多 Agent 协作系统中，各个 Agent 的执行耗时差异很大。产品 Agent 处理需求解析可能要几十秒，开发 Agent 生成代码可能要几分钟，评审 Agent 通常几秒到几十秒就能返回结论。如果消息总线用同步阻塞式，先完成的 Agent 会阻塞等待后完成的 Agent，整个团队的吞吐量被最慢成员拖垮。

我建议用异步消息队列，Agent 之间通过事件订阅解耦。每个 Agent 完成工作后发布事件，关心该事件的上下游 Agent 异步响应。这样协调器可以把不同阶段的任务并行推进，整体吞吐量能提升 30% 到 50%。当然，异步化会带来状态一致性的复杂度，所以在设计上要注意把状态存储集中到协调器，避免分布式状态散落。

6. 常见问题与排查技巧实录

多 Agent 系统的调试比单 Agent 困难得多，因为问题可能出在任意环节：某个 Agent 的 prompt 有问题、上下文组织不对、协调器的状态机逻辑出错、或者消息总线丢消息。我整理了一份常见问题速查表。

6.1 常见问题速查表

问题一：Agent 输出开始“漂移”

症状是开发 Agent 前几轮产出质量正常，后面越来越差，代码里开始出现与需求无关的细节，甚至开始“自己设计”模块。这个问题的根源通常是 Agent 的本地上下文里混入了过多历史信息，包括之前轮次的错误代码和无关讨论。

我的排查习惯是：检查任务卡片里有没有携带过期需求。比如需求已经变更过，但上下文里还保留旧版本的需求描述，Agent 会同时在旧需求和新契约之间“找平衡”，输出自然变形。解决办法是任务卡片里只保留当前版本的需求摘要，不给 Agent 看到历史版本的变更过程。

问题二：评审 Agent “睁眼瞎”

技术上叫漏检比较准确，评审 Agent 对某些明显错误视而不见。我遇到过的案例是，开发 Agent 在代码里直接硬编码了数据库连接串，评审 Agent 的报告里却是“通过”。

后来发现原因很有意思：数据库连接配置放在架构 Agent 输出的部署文档里，评审 Agent 在审查代码时，上下文里只有代码 diff 和接口契约，没拿到部署文档。但评审规范里要求检查“是否有敏感信息硬编码”。评审 Agent 没有检查这个行为的上下文依据，所以干脆放行了。

这就是上下文隔离的代价。评审 Agent 的上下文不是越少越好，而是需要覆盖它职责范围内的所有检查项。我给评审 Agent 增加了一个动态规则：当审查对象与某个配置项关联时，自动加载相关配置文档作为评审依据。

问题三：流程跑到一半态被卡死

状态卡死一般有两种情况。一种是协调器的状态机没定义某种异常分支，比如测试 Agent 执行测试时环境崩溃，该走哪个分支没有定义，流程就悬在那里。另一种是消息丢失，异步模式下如果消费者处理失败且没有重试机制，消息会静默消失，上游 Agent 还以为是下游在处理。

我的处理方式是给每个阶段任务设置超时时间，超时未完成就标记任务失败并通知人工介入。同时给每个状态转换加事件日志，发生卡死时先查日志，看最后一步是什么，基本能定位是哪个 Agent 没产出或哪个分支没定义。

问题四：多个 Agent 的代际不一致

编码 Agent 之间偶尔出现函数签名对不上。模块 A 的开发 Agent 实现了一个函数叫fetchUserData，模块 B 的开发 Agent 在调用时却用了getUserProfile。两边代码单独看都没问题，一集成就亮红灯。

原因在于两个 Agent 各自独立的上下文里引用了一个不存在的共享约定。虽然架构 Agent 在接口契约文档里定义过数据模型和函数命名规范，但两个开发 Agent 都没有把它当硬约束来读。

修复思路是：协调器在分派任务时，需要把“数据模型定义”和“命名规范”作为硬约束放进每个编码任务的卡片里，并从“参考文档”一栏移到“约束条件”一栏。AI 模型对“约束”和“参考”的概念权重差异很明显，同一段话放进不同分类下，对生成的约束力完全不同。

7. 一个完整的执行实例：从需求到交付

我完整走一遍模拟项目X中“用户登录模块”从需求到交付的执行流程，把整个过程的细节都展开。需求描述很简单：用户可以通过手机号和验证码登录系统，验证码有效期 5 分钟，连续失败 5 次后锁定账号 30 分钟。

第一步，产品 Agent 解析需求，输出结构化需求文档。关键产出是它提炼了不少显式约束和隐含约束。显式约束包括验证码有效期 5 分钟、失败次数上限 5 次、锁定时长 30 分钟。隐含约束包括手机号格式需要校验、验证码需要防暴力破解、锁定状态需要持久化防止重启失效。它所生成的验收标准也被拆成了原子描述，比如“提交正确手机号和有效验证码，返回登录成功”。

第二步，架构 Agent 设计模块边界。它把登录模块拆成两个子模块：验证码服务和认证服务。验证码服务负责生成、校验、过期验证码的清理；认证服务负责手机号输入校验、失败计数、账号锁定状态的管理。两个子模块通过内部接口通信，数据放在同一个用户表中，并通过 Redis 存储验证码和锁定状态。这些内容都落到接口契约文档中。

第三步，开发 Agent 实现这两个子模块。任务卡片里包含了接口契约、数据模型定义和开发规范。开发 Agent 生成的代码实现了验证码生成、发送、校验和认证逻辑，并处理了边界情况。这里值得一提的是，开发 Agent 生成的代码默认遵守了数据模型里用户表和时间字段的命名约定，整体风格一致。

第四步，审查 Agent 给出阻断项。它发现实现中只有“失败次数达到 5 次后返回锁定错误”，但没有在锁定状态下直接拒绝验证码校验，这意味着锁定期间用户依然可以触发验证码发送和校验流程，只是最终认证失败。对比架构文档中“锁定期间停止一切验证码校验”的设计，审查 Agent 把这条记录为阻断项，打回开发 Agent 修复。

第五步，开发 Agent 修复后重新提交。在验证码发送前增加了锁定状态检查，只有非锁定状态下才允许发送验证码和校验。这次审查通过，没有阻断项。

第六步，测试 Agent 生成测试用例。它覆盖了正常登录成功、验证码错误、验证码过期、连续失败 5 次触发锁定、锁定期间拒绝验证码发送与校验、锁定 30 分钟后自动解除，共 6 个场景。测试全部通过。

第七步，运维 Agent 生成部署配置。它生成了 Dockerfile、MySQL 初始化脚本、Redis 资源配置说明、以及一份包含环境变量清单的部署说明。

整个流程跑下来，用时约 20 分钟，期间人工介入次数为零。这个结果在单 Agent 模式下基本不可能稳定复现。

8. 扩展方向与我的实践心得

Agency Agents 这套系统我在几个内部项目上用过之后，对它的一些边界和扩展方向也有了更清晰的认识。这里分享几个我实际尝试过的扩展，以及最后的个人感受。

跨项目知识复用。目前的架构是按单个项目隔离上下文，项目之间的知识完全隔离。但如果能建一个项目无关的知识库，把架构 Agent 沉淀的通用方案、审查 Agent 沉淀的常见问题模式放进去，新项目就能站在之前项目的基础上起步，而不是每次都从零开始。我在模拟项目X上跑完一个模块后，把它的评审报告喂给下一个模块的审查 Agent，漏检率进一步下降了约 20%。

人工介入的接口设计。多 Agent 系统不是全自动无人系统。在设计协调器时，我专门保留了一个人工介入接口，两个场景触发人工介入：一是超过重试轮数上限，二是某个 Agent 连续多次产出被打回。人工介入不是去改代码，而是审查架构方案和任务拆分是否合理。这个设计在实操里帮过我好几次，有一次就是产品 Agent 对需求里的一个业务规则反复理解错误，人工介入后发现是规则本身有歧义，修正需求描述后就顺畅了。

评估体系的建设。多 Agent 系统的质量评估，不能只看最终测试有没有通过，还要看每个阶段的 Agent 产出质量。我现在会在每个阶段结束时存储一份阶段产物快照，用于后续对比分析。比如架构 Agent 输出的接口契约，在开发过程中有没有被频繁改动？改动的原因是什么？这些数据对优化整个系统的 agent 配置非常有价值，但项目初期往往不会想到去采集。

个人实操体会。跑了这么久，我最深的体会是：多 Agent 系统调度的核心，不是让模型“更聪明”，而是让流程“更有秩序”。代码生成能力由模型决定，但很多实际问题都出在信息传递的混乱上——该给的信息没给，不该给的信息给了，约束放错了位置，上下文没有及时清理。

单 Agent 里要靠模型消化的信息，在多 Agent 里是靠流程消化的。把信息该放到哪个环节、该以什么形式传递、什么时候该被遗忘，这些才是多 Agent 系统里最值得花时间的部分。Agent 的 prompt 当然重要，但流程结构的重要性高一个量级。

最后分享一个小技巧：每个 Agent 的 prompt 第一段，我建议都固定写一句“你是这个工作流的哪一环，你的上游是谁，你的下游是谁，你手里有哪些输入，你要产出什么格式的东西”。这句话加进去之后，Agent 的行为稳定性提升非常明显。它会让模型在生成之前，先建立起自己的坐标感。这一点，在我跑过的所有项目里都稳定奏效。