【AI Native开发-16】十个 Agent 同时开工，团队怎样不失控？

30 秒看懂这篇

一个高手用 AI，可以把功能做得又快又好；十个 Agent 同时开工，也可能把冲突、越权和密钥泄露一起规模化。

所以团队 AI-Native 化的关键，不是再买十个账号，而是建立一套让正确路径最省事、危险路径走不通、每次失败都能加固系统的研发操作系统。

flowchart TB
    H["人：意图、风险与发布裁决"] --> A["共享契约：Spec / Plan / ADR"]
    A --> G["Agent：隔离沙箱中生成与执行"]
    G --> C["CI：追踪、权限、质量与供应链检查"]
    C --> V["Verify：需求级证据"]
    V --> R["灰度发布与可回滚交付"]
    R --> O["线上反馈与事故"]
    O --> K["回写 Spec / 测试 / pitfalls / CI"]
    K --> A

这套系统有四根支柱：

契约与追踪。 REQ → TEST → 代码 → Verify 可审计，缺口不靠开会发现。
隔离与最小权限。 Agent 的文件、工具、网络和密钥访问都要受控，不只是分支隔离。
分级审批与安全交付。 高风险变更由人裁决，版本可追踪，发布可灰度、可回滚。
失败回写。 事故要转化为 Spec、回归测试、知识库或 CI 的新防线。

本篇把前 16 篇的方法落成团队资产、CI 机制、Agent 治理和四步引入路线。

从个人习惯到团队系统：差在哪

一个人用 SDD，你可以记得：写 Spec 要带非目标、Plan 要写不碰清单、测试要断言副作用、失败要归因回写。因为上下文都在你脑子里。

团队里这一切会失效：

新人不知道项目的 Spec 长什么样、放哪里；
有人赶进度跳过 Plan 直接让 AI 改代码；
不同人写的 Spec 详略不一，AI 执行质量天差地别；
失败的教训留在个人脑子里，别人（和 AI）还在踩同一个坑；
多个 AI / 多个人并行改代码，互相覆盖、冲突不断。

差别就一句话：个人靠自觉，团队靠机制。 团队系统要做的，是把前 15 篇里的关键纪律变成与风险匹配的默认路径：能自动检查的高风险红线交给机器强制，需要判断的事项保留人工评审，低风险变更则避免过度流程。

第一块：统一资产，让正确做法成为最省事的做法

把所有产物标准化、模板化、纳入版本管理。AI 和人都从模板出发，而不是每次从零写。

团队共享资产库（Git 管理）：

/specs/
  _templates/                     # spec / plan / tests / verify 模板
  article-delete/
    spec.md                       # 业务契约（第 04 篇）
    plan.md                       # 技术方案（第 06 篇）
    tests.md                      # 文本用例与 REQ→TEST 矩阵（第 10 篇）
    verify.md                     # 需求级证据报告（第 14 篇）
/spikes/
  keystatic-delete-path.spike.md  # Spike 记录（第 05 篇）
/tests/
  automation/                     # 自动化代码（第 11 篇）
/docs/
  ARCHITECTURE.md                 # 架构说明
  pitfalls.md                     # 踩坑笔记（AI 每次必读）
  decisions/                      # 架构决策记录（ADR）
  glossary.md                     # 业务术语表
/AGENTS.md 或 /CLAUDE.md           # 根目录 AI 工作守则：命令、规范、禁区

同一功能的四类产物放在 specs/<feature>/ 下，减少跨目录寻找和命名漂移；自动化测试仍跟随项目测试框架的目录约定。

关键原则：

模板即规范。Spec 模板里固定有”非目标""需求编号""验收标准”等节，不填就不完整——人不需要记得”要写非目标”，模板会替他记得；
AI 守则显式化。AGENTS.md 写清：测试命令、代码规范、禁止修改的路径、“失败先分类不许改测试压绿”等纪律，让每个 AI 会话开工前就加载；
所有资产进 Git。Spec、Plan、用例、Verify 报告都版本化，可追溯、可评审、可 diff。

第二块：CI 强制追踪完整性，让缺口藏不住

第 14 篇的需求追踪矩阵，在团队里不该靠人手工核对，而应由 CI 自动校验。这是把”靠开会对齐”变成”机器强制”的核心。

CI 校验项（不通过则阻断合入）：

1. 追踪链完整性
   - 每个 Spec 的 REQ 编号，都有至少一个 TEST 文本用例
   - 每个 TEST，都有自动化用例或显式的"仅人工验证"标注
   - Verify 报告里，每条 REQ 都有证据链接
   → 断链即失败：REQ 无 TEST、TEST 无代码、Verify 无证据

2. 变更范围控制（第 09 篇）
   - 实际 diff 文件 ⊆ Plan 声明的授权文件
   - 受保护路径（auth、核心加载器、package.json）改动需人工审批标记
   - 扫描：console.log / debugger / 幻觉 import / 调试残留

3. 质量门槛
   - 类型检查、lint、构建必须通过（静态站构建是独立必过项）
   - 测试全绿，且无"未解释的 skip"
   - flaky 用例不允许带 retry 混在主集（第 12 篇）

4. 模板完整性
   - Spec 包含非目标、验收标准等必填节
   - Plan 包含"不碰清单""回滚方案"
   - Verify 报告包含"未验证项""已知限制"

追踪链校验尤其重要。它让”这条需求有没有被测""这个测试对应哪个需求”不再是口头问题，而是 PR 上一个明确的红叉或绿勾。缺口在合入前就被机器拦住，而不是上线后被用户发现。

第三块：测试集治理与质量分层

团队的测试会不断增长，需要分类治理（第 13 篇的团队化）：

冒烟集（smoke）    个位数核心路径，每次部署自动跑
黄金集（golden）   关键业务 + P0 权限/资金/不可逆，每次合入跑
回归集（regression）全量，发布前跑；每个线上 bug 修复后补入新用例
flaky 隔离区       疑似 flaky 登记治理，显式 skip 留痕，禁止 retry 掩盖

治理规则：

线上缺陷必须留下防复发资产：可稳定自动化的转 CI 回归；其余转人工验收、监控告警或运行手册，并记录选择依据；
flaky 有负责人和期限：保留首次失败，重试通过单列 flaky；修复或显式隔离，不允许无限期挂着；
定期审计测试有效性：对关键用例做有针对性的变异检查，清掉对目标错误不敏感的陪跑测试；
度量用于团队自检，不用于个人考核：Gate 拒绝率、缺口发现阶段分布、逃逸缺陷数等，一旦和个人绩效挂钩，就可能被优化成漂亮数字。

第四块：风险分级、灰度与回滚

不是所有变更都走同样重的流程。按第 09 篇的风险分级，团队设定差异化审批：

P0（权限/认证、不可逆操作、资金、数据迁移、核心共享模块）
  → 强制人工逐行评审 + 人工确认合入 + 完整 Verify 报告
  → AI 不得自动合入

P1（新业务功能、业务逻辑修改、状态流转）
  → 人审范围一致性 + 高风险逻辑 + 异常路径测试覆盖
  → Verify 矩阵闭合可合入

P2（文案、样式、文档、类型补充）
  → CI 全绿 + Diff 范围核对，可快速放行

风险由“改动中最危险的部分”决定，不由改动大小决定。动了 P0 路径却没有人工审批标记，CI 自动阻断。

合入不等于发布。交付物还应绑定代码提交、模型 / 工具版本、Verify 报告和依赖锁版本；高风险变更先灰度或小流量发布，观察错误率与关键业务指标。回滚方案要区分代码回滚、数据恢复和外部副作用补偿，不能假设“回退版本”能撤销一切。

第五块：多 Agent / 多人并行的隔离与安全

分支只解决代码冲突，不能解决 Agent 读取密钥、调用任意外部服务或执行危险命令的风险。隔离至少要覆盖五层：

1. 工作区与所有权
   - 每个任务独立分支 / worktree，不共享未提交改动
   - Plan 声明授权文件；两个任务争同一文件则串行或显式协调
   - auth、loader、类型定义等共享核心文件走高风险审批

2. 沙箱与工具权限
   - 默认最小权限：限制文件系统、shell、进程和可调用工具
   - 删除、迁移、部署、外部消息等动作需要独立授权
   - 不用“AI 自己确认”代替人的高风险审批

3. 网络、密钥与数据
   - 网络采用域名白名单或显式放行，防止任意数据外发
   - 密钥用短期、最小范围凭据；不向提示词和日志注入生产密钥
   - 敏感仓库 / 数据按任务分级，记录访问与工具调用审计

4. 模型、工具与供应链
   - 记录模型、Agent、MCP / 插件及关键依赖版本，重要任务可复现
   - 新工具先做安全审查；锁定依赖并扫描恶意包、漏洞和异常脚本
   - 模型或工具升级先跑基准任务与回归，再逐步放开权限

5. 契约与上下文一致性
   - 所有 Agent 读同一份 AGENTS.md / pitfalls.md / glossary
   - Spec 冲突由人裁决并回到契约层统一，不能各自实现

没有这些边界，多 Agent 并行放大的是冲突、越权和供应链风险，而不只是吞吐量。

第六块：线上反馈闭环，让系统自我进化

团队系统和个人流程最大的不同：它要能随时间变强。闭环机制：

用户问题 / 线上缺陷
   ↓
归因（第 15 篇决策树：Spec / Plan / 实现 / 测试 / 环境）
   ↓
止血修复（Implement）
   ↓
回写四处：
  ① Spec 补/改规则（根因在需求）
  ② 回归集补用例（根因在漏测）→ 进 CI 永久守护
  ③ pitfalls.md / 评审检查表（根因在认知盲区）→ 所有 AI 下次必读
  ④ CI 规则（根因在机制漏洞）→ 机器自动拦截同类
   ↓
系统比事故发生前更严密

这是整个体系的飞轮：每一次失败都不只是被修复，而是转化成系统里一条新的防线。 线上出一次越权，CI 就增加相应的权限路径检查，回归集补充用例，pitfalls 记录教训，Spec 权限规则也更具体——这会显著降低同类错误复发的概率，但不能承诺系统此后绝无漏洞。

团队角色的变化

AI Native 研发系统里，角色不是消失，而是重心转移：

产品 / 需求：
  从"写需求文档"转向"定义意图、规则、边界、验收"
  核心产出：可测的 Spec、明确的非目标、风险优先级

开发：
  从"逐行写代码"转向"审查方案、控制架构、裁决高风险变更"
  核心动作：Plan 评审、Diff 范围控制、P0 审批、失败归因裁决
  三件不可委托：判断测试是否充分、失败归因、发布决策（第 00 篇）

测试：
  从"执行用例"转向"设计测试体系、维护质量门槛、治理测试资产"
  核心产出：REQ→TEST 矩阵、分层测试集、flaky 治理、Verify 把关

AI：
  分析代码库、生成 Spec/Plan 初稿、实现代码、生成用例、
  执行测试、基于证据调试、汇总报告
  —— 承担"生成与执行"；不作高风险裁决，低风险自动合入也只能在人预先批准的策略内运行

人不再是主要的代码产出者，而是意图的定义者、边界的设定者、风险的裁决者、结果的负责者。AI 放大的是执行力，人保值的是判断力。

落地路线：四步引入，不要一步到位

团队不要试图一次性铺开全部。按第 02 篇”从 Verify 起步”的思路，分四步，每步都能独立见效：

第一步：先建证据能力（Verify 切入，改造成本最低、见效最快）
  - 统一测试命令和报告格式
  - 建立需求追踪矩阵（哪怕先手工）
  - 引入冒烟集
  → 让团队先有"什么算验证过"的共识。没有证据能力，闸门会退化成签字。

第二步：固化 Spec 和 Plan 模板
  - 提供 Spec / Plan 模板，必填节齐全
  - 建立 AGENTS.md / pitfalls.md
  - 推行 Plan 评审（Gate 2）
  → 让"做什么/怎么做"先书面化、可评审。

第三步：CI 强制化
  - 追踪链完整性校验
  - 变更范围控制、受保护路径审批
  - 质量门槛、flaky 治理
  → 把靠自觉的纪律变成机器强制。

第四步：闭环与规模化
  - 线上失败回写机制
  - 多 Agent 并行隔离
  - 测试集分层治理、度量自检
  → 系统开始自我进化，支撑更大规模。

刻意从 Verify 而非 Spec 起步的原因（第 02 篇已论证）：团队最先缺的往往不是”写 Spec 的意愿”，而是”判断对错的证据能力”。没有能自动证明行为的测试和追踪，Spec 写得再好，闸门也只能靠人签字，签着签着就成了橡皮图章。先让团队能”看见真相”，再逐步把上游管起来。

团队化反模式

反模式一：一步到位的流程革命。 第一天就要求所有人写完整 Spec + Plan + Verify + 全套 CI，团队不堪重负、集体绕过。对策：四步渐进，每步见效。

反模式二：度量挂钩个人绩效。 Gate 拒绝率、缺陷数一旦考核个人，就会被优化成假数字，质量判断崩塌。对策：度量只用于团队自检和流程改进。

反模式三：只建模板不建机制。 发一堆模板文档，但没有 CI 校验、没有强制评审，模板形同虚设。对策：关键纪律必须机器强制，不能只靠文档号召。

反模式四：系统僵化不进化。 模板、检查表、CI 规则定完就不改，踩了新坑也不更新。对策：失败回写是固定动作，系统随事故进化。

反模式五：把人完全排除在判断外。 追求”全自动合入""AI 自己发布”，在高风险场景失控。对策：P0 变更和发布决策永远有人，自动化的是执行和检查，不是裁决。

系列总结：回到最开始的那个问题

第 00 篇我们问：AI 能写代码了，新的核心问题是什么？答案是——不再是”怎么写”，而是”怎么描述意图、怎么约束边界、怎么证明它写对了”。

17 篇走完，这套方法可以收成一句话：

写清楚（Spec） → 规划好（Plan/Spike） → 小步做（Implement）
            → 有证据地验收（测试/Verify） → 把经验沉淀下来（回写/系统化）

认知篇（00–02）：AI Native 不是让 AI 写代码更快，而是重组”人定义意图、AI 执行、人用证据验收”的分工；生成提速会让审查队列堆积，所以核心命题是让审查成本不随生成量线性增长；SDD 的四道闸门就是答案。
方法篇（03–07）：上下文工程让 AI 理解现状，Spec 让 AI 理解要做什么，Spike 清掉技术未知，Plan 声明影响面，评审在最便宜的阶段拦住错误。
实现篇（08–09）：小步、红线、每步 Diff、冲突暂停；代码评审的主角从”代码优不优雅”变成”变更是否忠于契约”。
测试篇（10–13）：从 REQ 推导文本用例，把用例代码化成有效断言（测行为不测实现、空实现自检），失败先证据后分类、禁猜测修复，分层执行并诚实报告。
验证篇（14–15）：Verify 把视角从”测试绿”抬升到”每条需求有证据”，失败要归因到真正的源头层并回写，而不是就地修绿。
系统篇（16）：把个人习惯变成团队机制——模板、CI 追踪、分级审批、并行隔离、反馈飞轮。

贯穿始终的几条信念：

AI 越强，流程越重要——因为错误实现的速度也变快了；
契约在人，执行在 AI，证据在测试；高风险裁决由人作出，低风险自动策略由人预先批准并负责；
最贵的不是写代码，是判断”哪些改动该存在""失败该在哪一层修”；
每一次失败都应让系统更严密，而不是简单清零。

AI Native 研发的终点，不是”完全不需要人”，而是——让人的判断力被沉淀进 Spec、模板、CI 和知识库，被每一个 AI 会话复用，被整个团队放大。 人从重复的执行里解放出来，专注在只有人能做的事上：定义什么是对的，并为结果负责。

系列到此完整。但这套方法不是读完就会的，它是在一次次”写 Spec → 被 AI 误解 → 补规则 → 测试拦住 → 归因回写”的循环里长出来的。挑一个你手上真实的小功能，从第一步”把它写成一份带非目标的 Spec”开始，让它跑完整套四道闸门——你会比读完这 17 篇理解得更深。

.Sam