用多智能体协作放大 Coding Agent：从单兵作战到可验证的工程流水线
当 Coding Agent 进入 Claude Code / Codex 阶段，真正的问题不再是”Agent 能不能干活”，而是”如何让它在复杂任务里不迷路、不污染上下文、不反复犯错，并交付可验证结果”。本文给出一套可复用的多智能体编排规范。
基本信息
- 来源：人人都是产品经理
- 作者：爱研究的乐声
- 原文链接：https://www.woshipm.com/ai/6423349.html
- 素材类型：方法论 + 工程规范
- 阅读时长：约 24 分钟
核心观点
-
单 Agent 做复杂任务会在五个维度失控：①上下文越来越脏（中间过程污染主会话）；②角色混在一起（既写代码又测自己写的东西，“自己证明自己正确”）；③长任务后期质量下降（忘记初始约束）；④失败后缺少责任边界（分不清是需求错、实现错还是验证错）；⑤最终结果缺少证据（说”已完成”但无构建日志/测试结果/截图）。多智能体的目标不是制造复杂感，而是把编程任务改造成”有人规划、有人实现、有人测试、有人审查、有人汇总证据”的工程团队流程。
-
不要提前写死角色，而要建立”动态子智能体生成规范”：主会话天然是 coordinator（主智能体），负责判断是否需要多智能体、拆解边界、生成子智能体 brief、分发任务、收集结果文件、判定通过/失败/重试/阻塞、最后汇总证据。子智能体只负责边界清晰的小任务（调查型只读、实现型只改指定文件、测试型只跑测试、审查型不改代码、UI 验证型只截图、文档型只更新文档）。
-
子智能体不要自己决定下一步召唤谁：子智能体完成后只返回状态和结果地址，下一步由主智能体判断。否则会失控成”Agent 继续召唤 Agent”，上下文、成本、任务边界全部失控。这是整个受控流水线设计的关键约束——详见 子智能体 Brief。
-
完整结果写文件，主会话只接收简短状态和文件地址：这是避免主上下文污染的核心机制。子智能体把调查过程、代码片段、测试日志全写进
.agent-runs/目录的报告文件，只回传STATUS / REPORT路径 / ARTIFACTS / SUMMARY。好处是主智能体上下文保持干净，且整个过程可追踪、复盘、验收——详见 文件交接协议。 -
验证策略是防止 Agent”只靠语言交付”的关键：一个任务不算完成，除非至少存在一个验证产物（测试命令+结果、构建命令+结果、运行输出、截图、日志摘录、人工检查清单，或”为什么无法验证”的说明）。Agent 最大的问题之一就是”说完成”却没有证据，验证策略强制它交付证据链。
-
失败修复遵循”谁实现谁优先修，谁发现谁复验”：实现 Agent 拥有开发上下文、修复效率更高；测试 Agent 知道自己发现的问题、复验更准确。重试上限 2-3 轮，超过后不再烧 token，而是生成 blocked 报告（暴露失败原因、尝试路径、涉及文件、需人工决策点）。
实操内容保留
子智能体 Brief 标准模板
role_name: 本次子智能体的角色名，必须贴合当前任务
mission: 本次唯一任务目标（只能有一个主要目标）
when_to_use: 为什么当前任务需要这个角色
input_files: 开始前必须读取哪些文件
allowed_edit_scope: 允许修改哪些文件或目录
forbidden_actions: 禁止做什么（不能删文件/改配置/提交代码/改测试）
tools_policy: 允许使用哪些工具（只读/可编辑/可跑测试/可启服务）
output_path: 结果必须写到哪里
success_criteria: 什么叫完成（必须可验证）
stop_condition: 什么时候必须停止（需求不清/测试失败/权限不足/超范围）
handoff_format: 如何把结果交还给主智能体
受控流水线（整体工作流）
用户需求
→ 主智能体判断是否启用多智能体
→ 读取 multi-agent skill 规范 → 制定执行策略
→ 召唤调查/规划类子智能体 → 输出计划或调查报告文件
→ 主智能体选择一个可验证任务 → 召唤实现类子智能体
→ 实现类子智能体完成修改并输出变更报告
→ 主智能体召唤测试/审查类子智能体
├─ 测试通过 → 进入下一个任务
└─ 测试失败 → 交回原实现 Agent 修复 → 原测试 Agent 复验
└─ 超过重试次数 → 标记 blocked
→ 全部完成 → 主智能体汇总最终报告
子智能体输出协议示例
成功返回：
STATUS: PASS
REPORT: .agent-runs/2026-07-01/task-003/test-report.md
ARTIFACTS: .agent-runs/2026-07-01/task-003/screenshots/
SUMMARY: Auth API validation tests passed. No regression found.
失败返回：
STATUS: FAIL
REPORT: .agent-runs/2026-07-01/task-003/test-report.md
FAILED_CASES: tests/auth.test.ts::should_return_400_when_password_missing
REASON: Password missing case returns 500 instead of 400.
SUGGESTED_NEXT_STEP: Send back to auth-api-implementer for repair.
阻塞返回：
STATUS: BLOCKED
REASON: Login validation behavior conflicts with existing middleware.
ATTEMPTS:
- Attempt 1: Added route-level validation, but middleware still throws 500.
- Attempt 2: Adjusted service error mapping, but test still fails.
NEED_HUMAN_DECISION: route layer or global middleware for validation?
RELATED_FILES: src/routes/auth.ts, src/middleware/error-handler.ts, tests/auth.test.ts
Skill 目录设计（薄入口、厚规范）
multi-agent-programming/
├── SKILL.md # 只做入口，不写太长
├── agent-factory/ # when-to-use / role-generation-rules
│ # role-attribute-schema / role-naming-rules
├── workflow/ # orchestration-flow / develop-test-repair-loop
│ # retry-and-block-policy
├── contracts/ # file-handoff-contract / report-format
│ # task-result-format
├── quality/ # verification-policy / acceptance-checklist
│ # done-definition
└── examples/ # feature-development / bug-fix
# frontend-ui / refactor
落地七步
- 建立 skill 目录（
SKILL.md+ agent-factory/workflow/contracts/quality/examples） - 写
when-to-use.md（只回答：什么时候启用多智能体） - 写
role-attribute-schema.md（强制生成完整 brief，不许”你去测试一下”） - 写
file-handoff-contract.md（详细结果写文件，只返回状态和路径） - 写
verification-policy.md（规定什么叫完成——必须有验证产物） - 写
retry-and-block-policy.md（默认重试 2 次，超限生成 blocked 报告） - 准备几个 examples（feature-development / bug-fix / frontend-ui / refactor）
原文精彩摘录
“真正的问题不再是 Agent 能不能干活，而是如何让 Agent 在复杂任务里不迷路、不污染上下文、不反复犯错，并且最终能交付一份可验证的结果。”
“子智能体完成任务后，只返回状态和结果地址。下一步由主智能体判断。否则多智能体容易失控，变成’Agent 继续召唤 Agent’，最后上下文、成本、任务边界都会失控。”
“Agent 最大的问题之一是’说完成’，但没有证据。验证策略就是防止它只靠语言交付。”
“这套方案的最佳定位不是重新发明 Agent 平台，而是给现有顶尖 Coding Agent 加上一套可复用的工程协作规范……当这些规范稳定下来之后，Coding Agent 就不再只是一个会写代码的助手，而更像一个有流程、有边界、有验收标准的小型工程团队。“
关键概念
与其他素材的关联
- 与 2026-06-17-ai-agent-工程完全指南 互补：那篇讲”多 Agent 拆分要以上下文为中心、不要模仿人类组织”，本文则在承认这一约束后，给出一套受控流水线的具体落地规范（coordinator + brief + 文件交接 + 验证 + 重试）
- 与 2026-06-03-claude-code-multi-agent-accounting 对照：会计管道是”预先写死的顺序流水线”，本文强调”动态生成子智能体 + 主智能体调度”的编排范式
- 与 2026-06-22-loop-engineering-woshipm 呼应：都强调”执行者和验证者必须分开""好目标的唯一标准是可验证”