Vibecoding进阶教程-从能用到可控（二）：拒绝coding agent既当裁判又当运动员
- 内容介绍
- 文章标签
- 相关推荐
Vibecoding进阶教程-从能用到可控（二）：拒绝coding agent既当裁判又当运动员
本篇是 Vibecoding 系列教程第二部分进阶篇的第二篇。
- 第一部分（环境搭建 + 基础闭环）：Vibecoding基础教程
如果对您有帮助的话可以帮我点一个star，这个repo我会持续更新的- 上一篇：MCP + Skills
- 下一篇：[安全 + 评测 + 工程化]
GitHub - 1EchA/how-to-vibecoding: A comprehensive guide and practical tutorials for...
A comprehensive guide and practical tutorials for VibeCoding, covering environment setups, CLI/IDE integrations, Agents, and MCP on macOS and Windows.VibeCoding 全面指南与实战教程：涵盖 macOS / Windows 环境搭建，Claude/Gemini/Codex CLI 与 VS Code 插件配置，以及 Agents 和 MCP 最佳实践。
写在前面
上一篇我们给 coding agent 装上了 MCP 工具，还用 Skills 卡片制定了一些标准化流程。
但你可能已经碰到了一个新问题：你让 coding agent 按技能卡片修好了一个 Bug，结果它偷偷把"验证通过"的结论也自己编了，等想复现的时候发现test根本跑不通。
这就是单 Agent 的极限：让同一个 AI 既写代码又审代码，它往往对自己写的 Bug 视而不见。本篇要解决的就是这两件事：
-
任务 1：多智能体分权—把写代码和审查代码的职责拆开
-
任务 2：长任务治理—让复杂任务不发散、可回溯
能并行的只读工作就并行。能分权的执行审查任务就分权。每个环节都要交证据，而不是听你的cc告诉你已经到达了“顶会level”
任务 1：多智能体：不让你的coding agent既当运动员又当裁判
目标：把"写代码"和"审查代码"拆给不同的角色
推荐两种做法：
-
比较简单的实现方法：你来当调度员，把 Scout、Builder、Verifier 的输出按固定格式手动传递。具体操作：在 Chat A 中以 Scout 身份让 AI 搜索，复制它的输出 JSON，再在 Chat B 中以 Builder 身份粘贴进去开始实现，最后在 Chat C 中以 Verifier 身份审查。
-
比较进阶高效的方法：用脚本或工作流引擎做自动编排。本文末尾附录 C 给了一个比较小的参考骨架。
从单 Agent 到多 Agent 的拐点：
你可能会问——“我用一个 coding agent 加上 Skills 卡片不就够了吗？” 我的回答是：如果这个任务节点比较少并且简单你的思路是没问题的，但是如果任务比较复杂的话，让同一个 Agent 既写实现又审代码，它往往对自己写的 Bug 视而不见。就像你让同一个人写代码又做 Code Review，这种模式的效果注定是不好的。把"写"和"审"拆给不同角色才能够提高质量，维持每一次决策的可靠性。
ps：最简单的方法就是你开一个codex再开一个claudecode，让claudecode出plan，然后给codex做check，没问题了之后让claude开始工作，然后拿工作结果给codex做double check，这种方法简单高效又好用。
1.1 核心分工（这里拿三个来举例子）
-
Scout：只找线索，不改代码。
-
Builder：只做实现，按约束最小改动。
-
Verifier：只做审查，负责找问题和跑验证。
只要职责不重叠或混合，稳定性就会上一个台阶。
1.2 一套用来参考的提示词约束模版
下面这三段约束，重点在于如何把输入、输出、禁止事项写的清楚。
Scout
你当前的角色是 Scout。你只负责收集证据，不允许改代码。
你必须交付：
1) 直接相关的文件路径清单，按重要性排序。
2) 仓库中相似实现或现有模式，尽量精确到函数、类、模块。
3) 你判断出的约束条件：构建、平台、安全、依赖、权限。
4) 你建议的最小改动范围。
禁止事项：
- 不写代码草案
- 不提出大范围重构
- 不替 Builder 做实现决策
Builder：
你当前的角色是 Builder。你的原则是：改动的时候尽量保持最小改动。
你不可违背的红线：
1) 动手之前，先亮出你需要跑的 3-7 步执行计划和验证预期。
2) 编码结束后交出 diff。
3) 提供实际执行过的测试、构建或验证输出。
4) 如果碰到了必须要加新库或者要一次动超过 5 个文件，停下来，先给我解释清楚非改不可的原因。
5) 你的修改方案应当竭尽所能做到"幂等"。无论跑几次都不该搞出重复追加、文本反复插入导致的破相。
6) 不要过分迷信 unified diff 的通用性：如果工具执行失败，立刻切换降维方案——给出"整个函数/模块的完整替换"或采用"查找且批量替换"式的方案协助落盘。
Verifier：
你当前的角色是 Verifier。你不负责写实现，你只负责审查和验收。
你必须交付：
1) 按严重程度排序的风险清单。
2) 决策没覆盖到的测试点和边界条件。
3) 基于 diff 的逐项审查结论。
4) 最低成本的补救建议。
你的判断必须基于：
- diff
- 实际执行结果
- 测试覆盖情况
- 已知约束条件
禁止事项：
- 凭感觉输出
- 在没有验证结果时宣称"应该没问题"
- 越过风险直接建议合并
最小流转路径：
-
scout.pass -> builder -
builder.pass -> verifier -
verifier.fail -> builder（打回原因直接发还给 Builder） -
needs-human→ 交给你来仲裁。
这么做最大的好处是：不管你以后换什么框架（LangGraph、AutoGen / AG2、原生 SDK），甚至手动复制粘贴排障的链路都是熟悉且清楚的。
1.2.1 大仓库的上下文管理：别让模型把你仓库全读一遍
真实项目里最常翻车的原因不是模型写不出代码，而是无关信息太多，把上下文窗口塞爆了，这不仅对项目上下文不友好，对你的钱包也不太友好。
可以参考的底线策略：
-
用
rg先快速锁定一小批候选文件（按报错名或接口名搜）。 -
再用 AST 级别的工具（IDE 的 Go to Definition 或
ast-grep）精确定位函数调用链。 -
喂给 Builder 时，只给裁剪后的代码片段 + 必要上下文 + 报错信息，避免填入多余噪声。
懒得装额外工具的话，直接用 IDE（VSCode / Cursor）里的 Go to Definition 来圈定范围也够用，有余力的话试试
ast-grep，比正则准得多：
- ast-grep 官网 — https://ast-grep.github.io/
如果你的库很硕大：
-
第一轮： 只做速查，摸清模块和接口，不写代码。
-
第二轮： 做最小化修复。
-
第三轮： 跑全量验证，找漏掉的边界。
或者在代码库中做一个目录索引，避免模型真的一个一个代码去读，由索引先提供给模型一个候选区域而不是让他瞎猜。
什么时候可以确认协作路子是对的？
- Verifier 能准确指出 Builder 的遗漏。
- 最终代码确实比第一版更稳。
核心：
多智能体协作不是"给几个机器人喂同样的 Prompt 让它们抢答"。核心在于：职责分离 + 信息隔离。
延伸阅读：
想深入了解多 Agent 协作的设计思路：
-
Building effective agents — https://www.anthropic.com/research/building-effective-agents
-
How we built our multi-agent research system — https://www.anthropic.com/engineering/multi-agent-research-system
-
Effective context engineering for AI agents — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
-
Measuring AI agent autonomy in practice — https://www.anthropic.com/research/measuring-agent-autonomy
任务 2：长任务治理：ULW 循环式推进
不管是用单 Agent 还是多智能体，只要任务开始跨越多个步骤和文件都可以使用这套方法
做过长周期复杂任务的佬都知道，最要命的不是Coding agent无从下手，Coding agent不会无从下手，怕的是它到处下手，越做越发散，屎山越来越高，最后甚至找不到一个能回滚的位置。
ULW（循环式推进 / Ultrawork）不是让 AI 无限循环。它的核心是：把大任务切成一段段可以验收的小结果，每段都有明确的目标、证据、可回滚的存档点和一键喊停的开关。
ulw我觉得omo做的很好
GitHub - code-yeongyu/oh-my-openagent: omo; the best agent harness - previously...
omo; the best agent harness - previously oh-my-opencode
感兴趣的佬可以试一试
你也可以直接把这份约定喂给你的coding agent：
你现在接手的任务按"循环推进"制度，规则如下：
1) 每轮只盯一个改动点，动手前先说清楚验证标准。
2) 每轮结束必须交证据：改动概要 + diff + 通过验证的日志。
3) 硬性上限：最多试 N 轮或花 T 分钟。超了就停下汇报，不许硬撑。
4) 碰到红线（拉大依赖、改大批文件、完全查不出原因的报错），立刻停手汇报。
5) 高危操作（删库、改根目录配置等）必须等我批准。
6) 交接时自己精简上下文：只把"做了什么、结论是什么"压缩成 3 句话带到下一轮，不许把大段日志原封不动搬过去。
当能够随时抽查它，它能说出"现在第几轮、这轮修什么、成功标准是什么"，而且能退回到上一轮的存档点，就算有效果了
参考：
看看别的佬是怎么管住长任务的：
-
oh-my-opencode README（ultrawork / ulw-loop 机制）— https://raw.githubusercontent.com/code-yeongyu/oh-my-opencode/dev/README.md
-
The Harness Problem（测试脚手架为什么是定海神针）— I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed. | Can.ac
附录 C：现在怎么做多智能体——时代变了，现在已经不用自己写调度代码了
任务 1 里讲的 Scout/Builder/Verifier 分工，现在主流工具已经内置了不同程度的支持。你不需要很麻烦的自己写，很多主流工具你写一段提示词存起来在需要的时候用自然语言调用一下就可以了。
C.1 最简单：AGENTS.md 分角色
把角色约束写进 AGENTS.md，工具启动时自动加载，对所有对话生效。
## 角色约束
当前角色：Builder
- 职责：只做实现，最小改动
- 禁止：自行修改测试基线、重构无关代码
- 交付：diff + 通过验证的输出
当前角色：Verifier
- 职责：只做审查，不写实现
- 必须交付：风险清单、未覆盖边界、逐条 diff 结论
- 禁止：在没有验证结果时宣称"应该没问题"
支持 AGENTS.md 的工具：Codex、Claude Code 等。
C.2 Codex 并行 Agent（worktree 模式）
Codex 原生支持同时跑多个 Agent，每个 Agent 在独立的 git worktree 里工作，互不干扰、不产生合并冲突。
实际用法：
-
打开 Codex，发起一个任务
-
点击"+ 新 Agent"，可以同时跑多个互不影响的子任务
-
Codex 自动管理 worktree 隔离，你只需要审查每个 Agent 的 diff
适合场景：同一个 feature 里，UI 改动和 API 改动可以并行交给两个 Agent 分别做。
参考文档：https://openai.com/codex
C.3 Claude Code 子智能体（subagent）
Claude Code 支持在一个主 Agent 里，通过 Task tool 发起并行子任务。主 Agent 做 Scout 和调度，子 Agent 做 Builder 或局部验证。
小示例：在 Claude Code 的对话里直接跟它说：
你现在作为 Scout，先把相关代码范围摸清楚，
然后启动两个子 Agent 分别实现方案 A 和方案 B，
最后你来对比两个结果选出更好的。
Claude Code 会自动调用 Task tool 并行跑子任务，你只需要最后审查主 Agent 给你的汇总。
参考文档：https://www.anthropic.com/engineering/multi-agent-research-system
C.4 ：LangGraph 图编排（需要写代码）
如果你的团队需要把多 Agent 流程做成自动化 pipeline（比如接进 CI/CD），可以用 LangGraph 做图调度。核心结构是：
START → scout → builder → verifier → [pass: END | fail: summarize → builder]
用 summarize 节点在每次打回时裁剪上下文，避免 Builder 重试时带着一堆没用的历史日志。
官方文档：Redirecting to LangGraph Documentation
总结：大多数人用 AGENTS.md + Codex/Claude Code 的内置多 Agent 支持就够了，不需要自己写调度代码。自己写框架只在需要完全定制化 pipeline 时才值得投入。
网友解答：下一篇预告：[安全 + 评测 + 工程化]
--【壹】--：
学习 收藏
--【贰】--：
actor-critic
--【叁】--：
佬，claude 的子subagent 模式和 使用 oh-my-opencode 的多 agent 协作模式，那个效果更好一点？企业级该如何落地
--【肆】--：
给跪了，我最近也打算弄一套multi agent，先mark，明天仔细阅读
--【伍】--：
好有道理，但是偏高阶，大部分人先把单Agent明白了再说吧～
--【陆】--：
收藏加一
--【柒】--：
大佬,学习了
--【捌】--：
向大佬学习，感谢分享
--【玖】--：
辛苦啦！
--【拾】--：
任务一现在基本spec都是这样用的，比如ccg，孙佬的，都是这样写的。不过任务二我学到了，就跟砌墙一样，一点一点砌墙，一点一点验证
--【拾壹】--：
感谢大佬 。
--【拾贰】--：
收藏学习一波
--【拾叁】--：
必须交叉审阅，不然很多时候有bug一个模型看不出来
--【拾肆】--：
看得出来这是真大佬
--【拾伍】--：
mark，感谢佬的帖子，虽然也在用，但是胜在总结很到位
--【拾陆】--：
佬好形象的总结
--【拾柒】--：
我回家慢慢拜读佬友的文章，现在，下班！
--【拾捌】--：
工作太忙只能周末详细研究了，佬友干货满满
--【拾玖】--：
已学习！
Vibecoding进阶教程-从能用到可控（二）：拒绝coding agent既当裁判又当运动员
本篇是 Vibecoding 系列教程第二部分进阶篇的第二篇。
- 第一部分（环境搭建 + 基础闭环）：Vibecoding基础教程
如果对您有帮助的话可以帮我点一个star，这个repo我会持续更新的- 上一篇：MCP + Skills
- 下一篇：[安全 + 评测 + 工程化]
GitHub - 1EchA/how-to-vibecoding: A comprehensive guide and practical tutorials for...
A comprehensive guide and practical tutorials for VibeCoding, covering environment setups, CLI/IDE integrations, Agents, and MCP on macOS and Windows.VibeCoding 全面指南与实战教程：涵盖 macOS / Windows 环境搭建，Claude/Gemini/Codex CLI 与 VS Code 插件配置，以及 Agents 和 MCP 最佳实践。
写在前面
上一篇我们给 coding agent 装上了 MCP 工具，还用 Skills 卡片制定了一些标准化流程。
但你可能已经碰到了一个新问题：你让 coding agent 按技能卡片修好了一个 Bug，结果它偷偷把"验证通过"的结论也自己编了，等想复现的时候发现test根本跑不通。
这就是单 Agent 的极限：让同一个 AI 既写代码又审代码，它往往对自己写的 Bug 视而不见。本篇要解决的就是这两件事：
-
任务 1：多智能体分权—把写代码和审查代码的职责拆开
-
任务 2：长任务治理—让复杂任务不发散、可回溯
能并行的只读工作就并行。能分权的执行审查任务就分权。每个环节都要交证据，而不是听你的cc告诉你已经到达了“顶会level”
任务 1：多智能体：不让你的coding agent既当运动员又当裁判
目标：把"写代码"和"审查代码"拆给不同的角色
推荐两种做法：
-
比较简单的实现方法：你来当调度员，把 Scout、Builder、Verifier 的输出按固定格式手动传递。具体操作：在 Chat A 中以 Scout 身份让 AI 搜索，复制它的输出 JSON，再在 Chat B 中以 Builder 身份粘贴进去开始实现，最后在 Chat C 中以 Verifier 身份审查。
-
比较进阶高效的方法：用脚本或工作流引擎做自动编排。本文末尾附录 C 给了一个比较小的参考骨架。
从单 Agent 到多 Agent 的拐点：
你可能会问——“我用一个 coding agent 加上 Skills 卡片不就够了吗？” 我的回答是：如果这个任务节点比较少并且简单你的思路是没问题的，但是如果任务比较复杂的话，让同一个 Agent 既写实现又审代码，它往往对自己写的 Bug 视而不见。就像你让同一个人写代码又做 Code Review，这种模式的效果注定是不好的。把"写"和"审"拆给不同角色才能够提高质量，维持每一次决策的可靠性。
ps：最简单的方法就是你开一个codex再开一个claudecode，让claudecode出plan，然后给codex做check，没问题了之后让claude开始工作，然后拿工作结果给codex做double check，这种方法简单高效又好用。
1.1 核心分工（这里拿三个来举例子）
-
Scout：只找线索，不改代码。
-
Builder：只做实现，按约束最小改动。
-
Verifier：只做审查，负责找问题和跑验证。
只要职责不重叠或混合，稳定性就会上一个台阶。
1.2 一套用来参考的提示词约束模版
下面这三段约束，重点在于如何把输入、输出、禁止事项写的清楚。
Scout
你当前的角色是 Scout。你只负责收集证据，不允许改代码。
你必须交付：
1) 直接相关的文件路径清单，按重要性排序。
2) 仓库中相似实现或现有模式，尽量精确到函数、类、模块。
3) 你判断出的约束条件：构建、平台、安全、依赖、权限。
4) 你建议的最小改动范围。
禁止事项：
- 不写代码草案
- 不提出大范围重构
- 不替 Builder 做实现决策
Builder：
你当前的角色是 Builder。你的原则是：改动的时候尽量保持最小改动。
你不可违背的红线：
1) 动手之前，先亮出你需要跑的 3-7 步执行计划和验证预期。
2) 编码结束后交出 diff。
3) 提供实际执行过的测试、构建或验证输出。
4) 如果碰到了必须要加新库或者要一次动超过 5 个文件，停下来，先给我解释清楚非改不可的原因。
5) 你的修改方案应当竭尽所能做到"幂等"。无论跑几次都不该搞出重复追加、文本反复插入导致的破相。
6) 不要过分迷信 unified diff 的通用性：如果工具执行失败，立刻切换降维方案——给出"整个函数/模块的完整替换"或采用"查找且批量替换"式的方案协助落盘。
Verifier：
你当前的角色是 Verifier。你不负责写实现，你只负责审查和验收。
你必须交付：
1) 按严重程度排序的风险清单。
2) 决策没覆盖到的测试点和边界条件。
3) 基于 diff 的逐项审查结论。
4) 最低成本的补救建议。
你的判断必须基于：
- diff
- 实际执行结果
- 测试覆盖情况
- 已知约束条件
禁止事项：
- 凭感觉输出
- 在没有验证结果时宣称"应该没问题"
- 越过风险直接建议合并
最小流转路径：
-
scout.pass -> builder -
builder.pass -> verifier -
verifier.fail -> builder（打回原因直接发还给 Builder） -
needs-human→ 交给你来仲裁。
这么做最大的好处是：不管你以后换什么框架（LangGraph、AutoGen / AG2、原生 SDK），甚至手动复制粘贴排障的链路都是熟悉且清楚的。
1.2.1 大仓库的上下文管理：别让模型把你仓库全读一遍
真实项目里最常翻车的原因不是模型写不出代码，而是无关信息太多，把上下文窗口塞爆了，这不仅对项目上下文不友好，对你的钱包也不太友好。
可以参考的底线策略：
-
用
rg先快速锁定一小批候选文件（按报错名或接口名搜）。 -
再用 AST 级别的工具（IDE 的 Go to Definition 或
ast-grep）精确定位函数调用链。 -
喂给 Builder 时，只给裁剪后的代码片段 + 必要上下文 + 报错信息，避免填入多余噪声。
懒得装额外工具的话，直接用 IDE（VSCode / Cursor）里的 Go to Definition 来圈定范围也够用，有余力的话试试
ast-grep，比正则准得多：
- ast-grep 官网 — https://ast-grep.github.io/
如果你的库很硕大：
-
第一轮： 只做速查，摸清模块和接口，不写代码。
-
第二轮： 做最小化修复。
-
第三轮： 跑全量验证，找漏掉的边界。
或者在代码库中做一个目录索引，避免模型真的一个一个代码去读，由索引先提供给模型一个候选区域而不是让他瞎猜。
什么时候可以确认协作路子是对的？
- Verifier 能准确指出 Builder 的遗漏。
- 最终代码确实比第一版更稳。
核心：
多智能体协作不是"给几个机器人喂同样的 Prompt 让它们抢答"。核心在于：职责分离 + 信息隔离。
延伸阅读：
想深入了解多 Agent 协作的设计思路：
-
Building effective agents — https://www.anthropic.com/research/building-effective-agents
-
How we built our multi-agent research system — https://www.anthropic.com/engineering/multi-agent-research-system
-
Effective context engineering for AI agents — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
-
Measuring AI agent autonomy in practice — https://www.anthropic.com/research/measuring-agent-autonomy
任务 2：长任务治理：ULW 循环式推进
不管是用单 Agent 还是多智能体，只要任务开始跨越多个步骤和文件都可以使用这套方法
做过长周期复杂任务的佬都知道，最要命的不是Coding agent无从下手，Coding agent不会无从下手，怕的是它到处下手，越做越发散，屎山越来越高，最后甚至找不到一个能回滚的位置。
ULW（循环式推进 / Ultrawork）不是让 AI 无限循环。它的核心是：把大任务切成一段段可以验收的小结果，每段都有明确的目标、证据、可回滚的存档点和一键喊停的开关。
ulw我觉得omo做的很好
GitHub - code-yeongyu/oh-my-openagent: omo; the best agent harness - previously...
omo; the best agent harness - previously oh-my-opencode
感兴趣的佬可以试一试
你也可以直接把这份约定喂给你的coding agent：
你现在接手的任务按"循环推进"制度，规则如下：
1) 每轮只盯一个改动点，动手前先说清楚验证标准。
2) 每轮结束必须交证据：改动概要 + diff + 通过验证的日志。
3) 硬性上限：最多试 N 轮或花 T 分钟。超了就停下汇报，不许硬撑。
4) 碰到红线（拉大依赖、改大批文件、完全查不出原因的报错），立刻停手汇报。
5) 高危操作（删库、改根目录配置等）必须等我批准。
6) 交接时自己精简上下文：只把"做了什么、结论是什么"压缩成 3 句话带到下一轮，不许把大段日志原封不动搬过去。
当能够随时抽查它，它能说出"现在第几轮、这轮修什么、成功标准是什么"，而且能退回到上一轮的存档点，就算有效果了
参考：
看看别的佬是怎么管住长任务的：
-
oh-my-opencode README（ultrawork / ulw-loop 机制）— https://raw.githubusercontent.com/code-yeongyu/oh-my-opencode/dev/README.md
-
The Harness Problem（测试脚手架为什么是定海神针）— I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed. | Can.ac
附录 C：现在怎么做多智能体——时代变了，现在已经不用自己写调度代码了
任务 1 里讲的 Scout/Builder/Verifier 分工，现在主流工具已经内置了不同程度的支持。你不需要很麻烦的自己写，很多主流工具你写一段提示词存起来在需要的时候用自然语言调用一下就可以了。
C.1 最简单：AGENTS.md 分角色
把角色约束写进 AGENTS.md，工具启动时自动加载，对所有对话生效。
## 角色约束
当前角色：Builder
- 职责：只做实现，最小改动
- 禁止：自行修改测试基线、重构无关代码
- 交付：diff + 通过验证的输出
当前角色：Verifier
- 职责：只做审查，不写实现
- 必须交付：风险清单、未覆盖边界、逐条 diff 结论
- 禁止：在没有验证结果时宣称"应该没问题"
支持 AGENTS.md 的工具：Codex、Claude Code 等。
C.2 Codex 并行 Agent（worktree 模式）
Codex 原生支持同时跑多个 Agent，每个 Agent 在独立的 git worktree 里工作，互不干扰、不产生合并冲突。
实际用法：
-
打开 Codex，发起一个任务
-
点击"+ 新 Agent"，可以同时跑多个互不影响的子任务
-
Codex 自动管理 worktree 隔离，你只需要审查每个 Agent 的 diff
适合场景：同一个 feature 里，UI 改动和 API 改动可以并行交给两个 Agent 分别做。
参考文档：https://openai.com/codex
C.3 Claude Code 子智能体（subagent）
Claude Code 支持在一个主 Agent 里，通过 Task tool 发起并行子任务。主 Agent 做 Scout 和调度，子 Agent 做 Builder 或局部验证。
小示例：在 Claude Code 的对话里直接跟它说：
你现在作为 Scout，先把相关代码范围摸清楚，
然后启动两个子 Agent 分别实现方案 A 和方案 B，
最后你来对比两个结果选出更好的。
Claude Code 会自动调用 Task tool 并行跑子任务，你只需要最后审查主 Agent 给你的汇总。
参考文档：https://www.anthropic.com/engineering/multi-agent-research-system
C.4 ：LangGraph 图编排（需要写代码）
如果你的团队需要把多 Agent 流程做成自动化 pipeline（比如接进 CI/CD），可以用 LangGraph 做图调度。核心结构是：
START → scout → builder → verifier → [pass: END | fail: summarize → builder]
用 summarize 节点在每次打回时裁剪上下文，避免 Builder 重试时带着一堆没用的历史日志。
官方文档：Redirecting to LangGraph Documentation
总结：大多数人用 AGENTS.md + Codex/Claude Code 的内置多 Agent 支持就够了，不需要自己写调度代码。自己写框架只在需要完全定制化 pipeline 时才值得投入。
网友解答：下一篇预告：[安全 + 评测 + 工程化]
--【壹】--：
学习 收藏
--【贰】--：
actor-critic
--【叁】--：
佬，claude 的子subagent 模式和 使用 oh-my-opencode 的多 agent 协作模式，那个效果更好一点？企业级该如何落地
--【肆】--：
给跪了，我最近也打算弄一套multi agent，先mark，明天仔细阅读
--【伍】--：
好有道理，但是偏高阶，大部分人先把单Agent明白了再说吧～
--【陆】--：
收藏加一
--【柒】--：
大佬,学习了
--【捌】--：
向大佬学习，感谢分享
--【玖】--：
辛苦啦！
--【拾】--：
任务一现在基本spec都是这样用的，比如ccg，孙佬的，都是这样写的。不过任务二我学到了，就跟砌墙一样，一点一点砌墙，一点一点验证
--【拾壹】--：
感谢大佬 。
--【拾贰】--：
收藏学习一波
--【拾叁】--：
必须交叉审阅，不然很多时候有bug一个模型看不出来
--【拾肆】--：
看得出来这是真大佬
--【拾伍】--：
mark，感谢佬的帖子，虽然也在用，但是胜在总结很到位
--【拾陆】--：
佬好形象的总结
--【拾柒】--：
我回家慢慢拜读佬友的文章，现在，下班！
--【拾捌】--：
工作太忙只能周末详细研究了，佬友干货满满
--【拾玖】--：
已学习！