这几年我带过的研发团队有个共同的怪现象：人数越加，沟通成本涨得越快。一个支付模块的改造需求，产品先讲一遍业务背景，技术负责人再讲一遍约束条件，后端开发进场前还要拉三个同事确认字段口径——每个人都在做"上下文人肉搬运"。直到我们尝试用 Agency Agents 搭了一套多智能体协作系统，把需求拆解、方案设计、代码编写、代码审查、测试用例生成这些环节交给不同的智能体代理协作完成，情况才真正变了。
这套系统的核心思路，不是用AI替换程序员，而是用"一组各司其职的智能体 + 一个共享工作区 + 一套任务状态协议"，把开发团队的协作过程变成可编排、可追溯、可重放的流水线。人在里面的角色从"执行者"变成"评审者"：定目标、定边界、做最终裁决。Agency Agents 这个名字里的Agency，我后来才理解，它强调的是每个智能体都有明确的"代理权责"，不是随便闲聊的聊天机器人。
这篇文章适合正在为研发交付效率发愁的技术负责人、对多智能体系统感兴趣的开发者来读。我会把我们从架构设计到落地的完整经验摊开来讲：为什么要这样分层、智能体之间怎么通信、迁移路径怎么设计，以及我们踩过的一堆坑。篇幅不短，但每段基本都能直接抄作业。
1. 传统开发协作的崩溃点与多智能体的解围逻辑
1.1 上下文在交接中持续损耗，才是效率失血的根源
对多智能体系统感兴趣的人，第一句问的大多是"它能取代哪些岗位"。我恰恰觉得这是错误的问题。我们先看一个软件开发里的最小协作单元：一个需求从产品经理到前端、后端、测试，往往要经过四到五次"人肉交接"。每一次交接，信息都会损耗：产品说"我要让用户看到订单状态"，后端理解的可能是"订单状态字段要新增枚举值"，测试拿到的则可能是另一版口径。这种损耗积累到联调阶段，就是长时间的返工和扯皮。
在有五个以上角色的中型项目里，一个工程师真正写代码的时间通常只占三到四成，剩下的时间都在开会、对齐、翻文档、等人回复。关键问题是，这些传递的"上下文"本身是高度结构化的——需求、约束、接口契约、验收标准，都可以用文档、代码、配置的形式固化下来。既然可以结构化，就可以被自动化地处理和传递。多智能体协作系统的本质，就是把原来靠"找个人问一下"来完成的上下文交接，改成靠"写进工作区、触发一条消息、更新一次状态"来完成。
1.2 智能体不是来替代人的，它是来替代"中间商"的
把思路理清楚之后，我们对 Agency Agents 的定位就不再是"AI开发工程师"，而是"能按合同办事的临时工"。它没有职位焦虑，不会争功诿过，只关心任务描述里写了什么、允许调用哪些工具、产出物要符合什么格式。人的精力则被释放出来，放在三件机器做不了的事情上：定义目标和验收标准、判断方案取舍、处理异常和灰度决策。
我经常用一个比喻：以前一个需求上线，像是在老式工厂里由不同工人手工传递零部件，每个人都要停下来问"上一个人到底想做什么"。现在相当于给每个环节装了一台专用机床，产出的工件尺寸是标准化的，传送带上的状态是实时可见的。工人从"搬零件"变成了"看仪表盘、调机床参数、处理报警"。人还是那个团队的人，但不再扮演信息的搬运工。
1.3 先判断自己适不适合：四个硬性条件
并不是所有团队都适合立刻上多智能体协作。我们内部总结过四个前置条件，缺一两个可以边做边补，缺太多就先别折腾：
- 需求文档规范化程度足够高。如果需求本身只有一句"把体验优化一下"，智能体再聪明也不该背这个锅。
- 有清晰的CI/静态检查流程。自动化反馈是智能体自我修正的前提，没有跑单测的环境，智能体编码就是盲写。
- 团队愿意接受"AI产出初稿，人类负责审查"的工作方式。这事最大的阻力往往不是技术，而是老工程师觉得"让AI写代码破坏了我的职业尊严"。
- 问题域边界清晰。比如订单状态流转、接口字段调整这类有明确约束的任务，非常适合先试点；而"重新设计一套推荐策略"这种高度发散的任务，人自己都还没想清楚，就别指望智能体能想清楚。
如果你所在的项目对这四个条件大部分都不满足，我的建议是先把手上的基础设施补齐，再回来考虑。工具是放大器，前提条件都不具备，放大器只会放大混乱。
2. Agency Agents 的分层架构：从编排大脑到执行手脚怎么分工
2.1 一张架构全景图：四层结构加一个共享工作区
我们在落地时把整个系统拆成了四个逻辑层，外加一个贯穿始终的共享工作区。这个划分不是一次到位的，而是踩了"职责不分"的坑之后反思出来的。你可以把四层理解成一个公司的四个职能部门：
- 编排层（Planner/Dispatcher）：接收一个总目标，做任务分解，生成带依赖关系的任务图，然后决定哪个智能体在什么时间点接手哪个任务。
- 角色层（Role Agents）：每个智能体对应一个开发角色，比如需求分析、架构设计、编码实现、代码审查、测试生成。它们只关心自己职责范围内的产出物。
- 能力层（Tools/Skills）：给智能体提供真实世界的"手脚"，包括读写工作区、执行静态检查、跑单元测试、搜索代码库、调用构建系统等。
- 记忆层（Memory）：存放短期会话记录、长期事实库（比如团队技术规范）、经验库（历史踩坑记录）。记忆层决定了智能体能不能越用越"懂事"。
共享工作区是所有这些层之间交换信息的物理载体。它不是一个聊天记录文件，而是一个带结构的仓库，里面存的是需求文档、技术方案、代码补丁、测试报告这些可引用的产物。我后来发现，很多团队做多智能体失败，就是因为把"对话历史"当成了共享记忆，而没有建立这样一个"物化的工作区"。
2.2 角色卡是Agent的灵魂：一个Agent只干一件事
在 Agency Agents 里，每个智能体的行为由一张"角色卡"定义。角色卡本质上是一组人设、约束、输入输出规范，而不是一个长期运行的服务进程。我们会在系统初始化时加载它，任务来临时按需创建Agent实例。下面是我们 developer 角色卡的简化版本：
role: developer system_prompt: | 你是一名资深后端开发工程师。 你的任务是基于技术方案和接口契约，生成符合团队编码规范的代码补丁。 禁止修改任务描述中声明文件范围之外的代码。 不确定字段含义时，记录 BLOCKED 状态并请求人工确认，不要猜测。 tools: - read.workspace - git.diff - linter.run - unit_test.run input_schema: task_description: string related_artifacts: [string] # 工作区中的文件坐标 constraints: [string] output_schema: patch: string # 代码补丁内容 changed_files: [string] impact_note: string self_test_result: string max_iterations: 3字段不多，每一个都有讲究。system_prompt 负责"人格和边界"，约束它不要越权；tools 列表限定了它能调用哪些工具，从物理上防止它乱搞；input_schema 和 output_schema 则决定了上下游 Agent 能不能自动消费它的产出。我见过很多团队在 system_prompt 里写几百字的角色小作文，但完全没有定义输出结构，结果下游 Agent 根本不知道拿到的文本该怎么解析。记住一句话：Agent 的产出物格式，比它的"人设"重要十倍。
2.3 编排策略不是越复杂越好：顺序流、扇出并行与评审闭环
编排层是大脑，但它不需要发明特别复杂的调度算法。我们在第一阶段只用了三种编排模式，已经能覆盖绝大多数开发场景。第一种是顺序流水线：需求分析 → 技术方案 → 编码 → 审查 → 测试，适合逻辑链路较长的任务。第二种是扇出并行：一个需求拆成多个模块后，多个 developer Agent 并行写不同模块，适合多个文件互不依赖的改动。第三种是评审闭环：编码 Agent 提交补丁后，审查 Agent 打回修改意见，形成迭代循环。
这三类模式底层都是同一张任务依赖图。我们用一个非常朴素的 JSON 描述它：
{ "tasks": [ {"id": "t1", "type": "analysis", "depends_on": []}, {"id": "t2", "type": "architecture", "depends_on": ["t1"]}, {"id": "t3", "type": "coding", "depends_on": ["t2"]}, {"id": "t4", "type": "review", "depends_on": ["t3"]} ] }Planner 只需要做一件事：解析 depends_on，找出没有依赖的任务并行下发，有依赖的任务在前置任务满足后触发。听起来简单，但实际运行中，因为任务粒度拆得不够细，经常出现"一个任务卡住整条链路"的情况。我们的经验是先跑顺序流，看到数据再考虑并行，不要一上来就追求调度器的复杂度。
2.4 共享工作区：Agent之间的"共同记忆盘"
共享工作区的设计是整个系统能否落地的分水岭。我们把它实现成一个类似"带 schema 的临时仓库"：每个任务都会在工作区里生成一个目录，里面放着任务描述、约束条件、分析结论、代码补丁、测试报告。Agent 之间不直接传文件，而是通过消息引用工作区里的坐标，比如 workspace/t3/patch.diff。
这样做有四个显而易见的好处。第一是可追溯，每一个产出物都知道是谁、在什么任务下、基于什么输入生成的。第二是可回滚，某次修改出问题，直接把工作区里对应的补丁文件回退即可。第三是可并行，不同 Agent 读写不同目录，天然隔离，不会互相踩踏。第四是可审计，人的评审任务从"看聊天记录"变成"看坐标上的产物"，效率高得多。
工作区里的产物还会有统一的元信息格式。我们每次写入都会带一条记录，标明 artifact 类型、内容坐标、产出 Agent、任务ID、状态和时间戳。你甚至可以把它理解成一个微型数据库加文件系统的混合体。这个设计直接决定了后面消息协议能不能精简，所以值得多花点心思。
3. 智能体之间不是"群聊"，而是靠任务状态机与消息协议协作
3.1 自然语言群聊会立刻失控
如果你让多个 Agent 像人类开会一样你一言我一语地协作，系统会在三十分钟内变成一场灾难。上下文窗口会被无关对话填满；讨论主题会从"接口契约"漂移到"代码风格"；出了问题没人说得清是哪一轮对话、哪句话导致的状态；想重放某个步骤，翻遍聊天记录也找不到清晰的时间线。
我们的做法是：智能体之间的一次协作，本质上是"一次任务状态转移"，而不是"一段对话"。自然语言只出现在评审意见、影响说明这类需要理由的字段里，真正推动流程前进的是状态的变化。你可以把它想成物流系统里的包裹流转：包裹不会在两个快递员之间来回唠嗑，它只会在系统里显示"已揽收""运输中""派送中""已签收"。状态一变，下一道工序的机器就知道该动了。
3.2 状态机设计：八种状态与流转条件
任务状态机是我们定义的第一份权威文档。每个任务从创建到完成，一共八种状态：
| 状态 | 含义 | 进入条件 | 离开条件 |
|---|---|---|---|
| CREATED | 任务已创建未分配 | 编排层任务拆分完成 | 分配至具体Agent |
| ASSIGNED | 已分配 | Agent被选中 | Agent标记开始执行 |
| IN_PROGRESS | 执行中 | Agent开始动作 | 产出物写入工作区 |
| REVIEWING | 待审查 | 产出物提交 | 审查通过/退回 |
| CHANGES_REQUIRED | 需修改 | 审查未通过 | Agent重新提交 |
| APPROVED | 已通过 | 审查通过 | 合入主干 |
| DONE | 已完成 | 合入主干 | 无 |
| BLOCKED | 阻塞 | 任意状态 | 人工介入 |
这张表看着简单，但它解决了大量实际问题。尤其是 BLOCKED 这个状态，它给了 Agent 一条正式的"求助通道"。我们会明确告诉每个 Agent：拿不准就进 BLOCKED，不要猜。猜错一次的成本，比阻塞十分钟的成本高一个数量级。这个状态在代码审查阶段尤其重要，审查 Agent 一旦怀疑需求有歧义，可以直接把任务挂起而不用硬着头皮往下走。
3.3 消息协议：每个消息都携带线索，而不是携带全部内容
状态机定义了任务"是什么状态"，消息协议则解决"状态变化时通知谁、带什么信息"。我们的消息设计原则是：消息本体只是一个轻量级的通知和索引，具体细节放在工作区引用里。下面是一条 developer Agent 完成编码后发出的典型消息：
{ "event": "artifact.updated", "task_id": "t3", "agent_id": "dev-billing", "ts": "2025-06-11T14:32:00Z", "artifact_ref": "workspace/t3/patch.diff", "summary": "完成订单状态字段扩展，新增枚举值 PROCESSING", "impact_note": "涉及 OrderStore、OrderSerializer、单测 3 个文件", "status": "REVIEWING" }注意 summary 里是"人话摘要"，真正的大段内容都在 artifact_ref 指向的文件里。下游 Review Agent 收到这条消息后，如果只需要知道"有一个补丁进入审查状态"，那读消息本体就够了；需要深入检查，再去工作区里拉 diff。这种设计能把上下文窗口的占用维持在一个稳定水平，不至于随着消息累积而线性爆炸。我们曾做过统计，如果没有引用机制，光是一个中型需求的 Agent 间消息就能把一个窗口塞爆。
3.4 并发冲突：谁有权利改同一份文件
当多个 developer Agent 并行执行时，必然会遇到"两个 Agent 改同一个文件"的问题。人类团队里这叫"改冲突了"，多智能体系统里处理不好，代码就会互相覆盖，产出一堆幽灵代码。
我们的处理分三层。第一层是预防：Planner 在任务拆分时，就要求每个任务声明影响到的文件集，依赖检测器发现两个并行任务文件集有交集，就自动改为串行。第二层是隔离：工作区里引入"文件锁"的概念，Agent 读写某个文件前必须先申请锁，锁被占用就只能等待或切换任务。第三层是兜底：如果锁也防不住，那就遵守"后提交者先同步"原则——后提交的 Agent 必须合并最新变更并重跑测试才能交卷，实在合并不了就转人工仲裁。
这一套规则加进去之后，我们的并行任务冲突率从最初的百分之十几降到了百分之一以下。核心经验是：不要指望 Agent 自己"自觉避让"，要靠系统层面的硬约束。
4. 落地路径：别想一步到位，先让一个环节跑通再谈重构
4.1 第一步：把代码审查智能体化，作为破冰实验
很多团队上多智能体系统，一上来就希望"全流程自动化"，结果因为反馈链路太长、问题定位太困难，一两周之后就偃旗息鼓。我们的建议非常反直觉：第一步先做代码审查，而不是先做代码生成。
原因是代码审查天然适合作为破冰实验。它有清晰的边界，输入是PR diff，输出是问题清单，不涉及改动生产代码，出了问题不会炸线上；它可以旁路运行，即使审查意见不准，也不阻塞主流程，最坏情况就是人忽略它。我们当时的做法是：开发者提交 PR 后，Review Agent 自动跑一遍，输出严重程度分级的问题清单，并给出修改建议。人只需要在评审页面上决定"采纳或忽略"。
这一步跑通之后，团队对 AI 的信任感会发生质变。因为 AI 确实能抓到一些低级错误，比如未处理的空指针、遗漏的分支条件、不规范的异常抛出。而这些错误以前是人肉眼检查时最容易漏掉的。信任感建立起来，后面推更深的内容才有人愿意配合。
4.2 第二步：让"需求分析+技术方案"两个Agent组成小分队
第二步，我们开始让 Agent 参与"上游创作"，而不是只做"下游检查"。具体做法是在流程前端放两个 Agent：一个负责把粗糙的需求描述扩充成结构化的需求文档，另一个负责基于需求文档和约束库产出技术方案初稿。
这个环节最关键的基建是"约束库"。没有约束库，方案 Agent 就会按照大模型的通用套路自由发挥——比如数据库变更不知道要走迁移脚本、接口不知道要遵循统一错误码规范、日志系统不知道要接哪个中间件。我们的做法是把团队的技术规范一条条结构化，存进记忆层，方案 Agent 每次开工前必须检索约束库，并在方案里逐条说明如何满足相关约束。
人的角色在这里变成了审批者：方案 Agent 给出技术选型、接口设计、改动范围和风险点，人只需要做可行性判断和决策。这一步跑通，意味着"写文档"这件事从人肉工时里剥离出来了。我们实测下来，一个中型需求的技术方案设计，从过去的两个工作日压缩到两个小时，里面至少有七成内容可以直接用，剩下三成人来修正。
4.3 第三步：打通"编码-审查-测试"闭环，再切进主线
前两步都稳定之后，才建议把编码 Agent 接入主线。我们从非常小的颗粒度开始，专门挑那些"自包含"的需求：单个字段调整、某个 bug 的缺陷修复、补一条测试用例。这一类任务影响范围小、验收标准明确，适合让 Agent 独立完成。
我们为编码 Agent 设立了一张严格的准入准出清单：
| 维度 | 允许 | 禁止 |
|---|---|---|
| 文件范围 | 任务声明的文件集 | 涉及核心支付/鉴权模块 |
| 代码规范 | 必须通过 linter | 绕过公共抽象层 |
| 测试 | 修改后单测必须全绿 | 删除或跳过失败测试 |
| 合入方式 | 生成 patch 文件供人工预览 | 无人工确认自动合入 |
| 迭代次数 | 最多 3 轮，超限转人工 | 无限循环自我修正 |
这套清单的要点是"每一条都能被系统自动校验"。编码 Agent 生成的 patch 不会直接合入主干，而是落到工作区，由人在本地预览确认。确认通过后，再交给测试 Agent 跑一轮完整回归。如果某轮测试失败，编码 Agent 可以自动迭代修改，但超过三轮就必须停下转人工。这个熔断机制是我们从惨痛教训里学来的，后面避坑部分会展开讲。
4.4 用数据判断：它是效率提升，还是数字幻觉
多智能体系统上线后，最容易被"AI生成代码量"这种指标迷惑。我们内部有一套自己的评估口径，每个指标都能从工作区和 CI 日志里直接算出来：
- 交付周期：从需求创建到合入主干的时长。这是北极星指标。
- 交接次数：同一个需求在 Agent 和 Agent、Agent 和人之间转手的次数。次数越少越好。
- 缺陷逃逸率：合入后两星期内被线上或回归测试发现的问题数。
- 人工审查耗时：每 PR 的评审环节人实际花费的分钟数。
- Agent 任务成功率：不经过人工介入就一次通过的编码/审查任务占比。
举一个我们真实的对比：试点前，某业务线一个中小型需求平均交付周期 4.2 天；试点三个月后，同类型需求平均 2.8 天。交接次数从平均 7 次降到 3 次。更关键的是缺陷逃逸率没有抬头的趋势，这说明效率提升不是靠牺牲质量换来的。我建议你也按这个思路建立基线数据，上线前跑两周的旧流程数据，才有参照系。否则到复盘时，你根本分不清多智能体系统到底有没有用。
5. 踩坑记录：上下文溢出、死循环，还有"看起来很忙"的Agent
5.1 上下文爆炸：当Agent把整个仓库都塞进prompt
第一次把编码 Agent 接进真实代码库时，我们遇到的最诡异现象是：Agent 在任务前段回答得很正常，到后段开始胡编文件名，引用的接口明明已经不存在，它却信誓旦旦地写着"根据最新代码约定"。一开始我们怀疑模型不行，后来查 token 消耗曲线才发现，上下文窗口已经被塞进了大量历史内容，有效输入比例极低，模型在"注意力稀释"的状态下开始产生幻觉。
根因很简单：我们早期没有做记忆分级，而是把 Agent 的所有对话历史、中间产物一股脑地连续追加到上下文里。解决方法是把记忆分成短期工作记忆和长期事实库。短期工作记忆只保留当前任务窗口内最近两三轮的关键结论，长期事实库则通过向量检索按需加载，Agent 每次只取与任务直接相关的三五条规范。这一步下来，Token 消耗大概降了六成，幻觉出现的频率也明显降低。
5.2 Review死循环：两个Agent互相踢皮球
我们曾经踩过一个非常经典的死循环：编码 Agent 提交补丁后，Review Agent 打回说"代码格式不符合规范"，编码 Agent 修改后再次提交，Review Agent 又说"行尾缺少空格"，循环往复，同一个 PR 改了几十版都没有定稿。到第8轮我们终于看明白了——不是编码 Agent 不会写格式，而是 Review Agent 的审查标准太宽泛，把一些本应交由 linter 自动处理的问题，当成逻辑错误提了出来。
解决方法是给审查规则做减法。凡是静态检查工具能覆盖的问题，一律从 Review Agent 的评审规则里删除；Review Agent 只关注逻辑正确性、边界条件、接口契约、安全风险这些真正需要推理的内容。同时，我们在状态机层面加了一条熔断规则：同一任务的审查循环最多迭代 3 轮，超过 3 轮强制转人工。人工介入后人类可以直接拍板，不让 Agent 继续空转。这条兜底规则看似简单，但它是系统稳定运行的最后保险。
5.3 "看起来很忙"的Agent：输出了大量内容但没有进展
还有一个更隐蔽的问题：某些 Agent 在遇到稍微复杂的任务时，会产生大量"看起来很努力"的输出——写长总结、列分析步骤、分析利弊，但产出物坐标永远是空的，任务状态一直停在 IN_PROGRESS，没有产生任何可以被下一个环节消费的补丁或文档。我们内部管这叫"空转 Agent"。
排查思路是看工具调用日志。一个真正在干活的 Agent 必然会调用 read.workspace、git.diff、linter.run 这些工具，留下可查的操作记录；空转的 Agent 则只有文本生成记录，没有工具调用记录。修复方法是在角色卡的 output_schema 里强制要求"任务必须产生 artifact_ref，且引用必须真实存在"，否则视为任务失败。这一条规则加下去，空转现象几乎绝迹。它背后的原理是：Agent 是概率生成模型，天然倾向于顺着上下文"继续说话"，如果系统不要求它产生物理世界的产物，它就会把"说话"当成工作完成。
5.4 信任分层：AI产出物不是权威，只是未验证输入
最后一个坑，其实是理念层面的。我们早期犯过一个错误：为了让流程跑得更顺，默认"Agent 生成的代码本身就是正确的"，结果审查环节变成了走过场，直到一次测试环境事故才让我们警醒。Agent 的产出物本质上是一个概率模型的采样结果，它可能看起来极度专业，但仍然可能包含致命的逻辑错误。
从此我们把整个系统设计成一条"信任提升管道"，任何 AI 产出物都按信任等级分级处理：
| 信任等级 | 判定方式 | 允许动作 |
|---|---|---|
| 低信任 | AI 初稿 | 进入自动检查流程 |
| 中信任 | 通过 linter 和单测 | 允许进入人工评审队列 |
| 高信任 | 人工评审通过 | 允许合入主干 |
这套分级的最大价值是让"人在环路里"这件事变得不可跳过。每次合入都会留下审计日志：哪个 Agent 产出的、经过了哪些自动检查、由谁批准。我后来跟团队说，多智能体协作系统就像一个自动化程度很高的无菌车间，但最终出厂的产品必须有人签字。AI 是高速的加工设备，人永远是这个流程里最终的签章人。
6. 如果只让我分享一个经验：把"不确定"留给人，把"确定"留给Agent
这套系统跑了大半年之后，我最大的体会是：它没有让团队砍掉一半人，但确实让每个工程师每周多出半天到一天的时间，去做那些真正需要判断力的工作。所谓"重构开发团队"，重构的不是人数，而是信息在人与人、人与机器之间流动的方式。以前的信息流是一根串在每个人嗓子眼上的电话线，现在的信息流是一张带状态、带坐标、带审计记录的工作台。
如果你也想在自己的团队里尝试，我只有一个建议：不要讨论"能不能替代程序员"这种哲学问题，先找一个像代码审查一样边界清晰、反馈直接的小环节，把多智能体协作跑起来。等它稳定了，你自然会知道下一个环节该切到哪。最后送你们一个我自己用得很顺手的小技巧：在每张角色卡的 system_prompt 里都写上一句"不确定时，记录 BLOCKED 状态并请求人工确认，不要猜测"。光这一个设置，就能省掉至少一半的返工。
