CLI 成为主流后，多 agent 对抗正在变成 AI 编程的最佳实践

CLI 正在成为 AI 编程的主流入口。

Claude Code、Codex CLI、Gemini CLI——最近半年，几乎所有头部 AI 编程工具都在往终端走。不是因为命令行本身变酷了，而是当 AI 能听懂人话，你不再需要按钮和菜单来翻译意图。一句话进去，代码出来。

但一旦你真正在终端里干活，一个更深层的变化会自然发生：

你会开始同时跑多个 agent。

一个 terminal 写代码。另一个 terminal 做 code review。再开一个 terminal 专门问需求、补约束。不是因为你想折腾，而是你发现，一个 agent 写完不 review 就上线，心里总不踏实。

这就是多 agent 对抗——一个写，一个审，一个验。写的那个尽量快，审的那个尽量挑毛病，验的那个只看"能不能跑起来、行为是不是对的"。

它不是什么高阶玩法。

它正在变成 CLI 时代 AI 编程的基本工作方式。

因为 AI 会走捷径、会漏边界、也会像人一样对自己的第一版过度自信，所以"一个写、一个审、一个验"不是炫技，而是最朴素的质量控制。

为什么对抗比协作更重要

很多人第一反应是：多 agent 不就是让 AI 互相合作吗？

不完全是。关键在对抗。

工程实践里有一条老规矩：写代码的人不能自己 review。不是因为不信任，而是因为人在生成模式下，天然会忽略边界问题——你太清楚自己"想"让代码做什么，反而看不到它"实际"会在哪里崩。

AI 也一样，甚至更甚。

它从人类代码里训练出来，也继承了人类代码里那些很常见的捷径倾向。能跑通 happy path 就不管 edge case，能用简单实现就不考虑扩展性，能少写几行就少写几行。不是恶意，是训练数据里大量代码本身就是这么写的，走捷径本来就是它学到的"正常行为"。

单个 agent 写完觉得自己没问题，和人类程序员写完觉得自己没 bug，是同一种过度自信。

所以对抗不是锦上添花，是必要约束。

多 agent 对抗的逻辑就是：

• Coder agent 的目标是"写出来"
• Reviewer agent 的目标是"挑出问题"
• Verifier agent 的目标是"跑得通"

01-workflow

三个 agent 的激励方向不同。这种张力不是 bug，是 feature。它模拟的是好团队里自然存在的角色分工：开发、审查、测试。只不过现在每个角色都是一个 CLI 里的 AI 进程。

如果你还在用单个 agent 写完就提交，不是说不行，而是你在放弃 AI 编程里目前最有效的质量保障手段。

每个 AI 使用者都会遇到这个问题

你可能会觉得：我用 Cursor 就好了，多 terminal 是 CLI 极客的事。

但方向已经很明确了。

Cursor 已经在做 background agents——后台跑一个 agent 处理你不想盯的任务。Codex 有 async tasks。Windsurf 在推多 agent 协作。不管你用什么工具，行业的方向就是：让多个 AI 视角互相检查彼此的输出。

产品形态可能不同，但底层都在走向同一件事：把"写、审、验、补约束"拆给不同 AI 角色。

这意味着一个现实：你迟早会面对"同时管理多个 AI 的工作节奏"这件事。

而真到了那一步，最累的不是让 agent 跑起来。

是你自己变成了调度员。

对抗模式的真正瓶颈：人变成了项目经理

假设你在重构一个 auth 模块。

左边 terminal 里让 Claude Code 上手改代码。右边 terminal 开另一个模型做 CR，重点看权限边界和异常链路。改完之后，再跑一个验证，确认登录流程没被改坏。

三个 agent 各有分工，看起来很漂亮。

但真实的体验是：

1. 你先给 coder 下任务
2. 等它跑出第一版
3. 切到 reviewer 那边触发 CR
4. reviewer 抛回问题，你来判断哪些该返工、哪些可接受
5. 回 coder 补约束继续改
6. 改完还得决定是复检还是收口

每一步都要你亲自点火。

你不是在用 AI 协作。你是在给三个 AI 当项目经理——派单、催进度、做仲裁、定验收。

而且最贵的不是来回切窗口。是切脑子。上一秒你在像工程师一样看实现，下一秒你要像 reviewer 一样挑边界，再下一秒你得像 PM 一样判断"这个风险值不值得修到这一步"。

AI 在替你写代码，你反而被抬成了整条链路里最忙的节点。

把对抗流程产品化，是下一步的关键

这也是我看 oh-my-claudecode 觉得有意思的地方。

它不是"又一个多 agent 工具"。它真正在做的，是把多 agent 对抗的编排逻辑产品化。

README 里的核心流程是一条 staged pipeline：

team-plan → team-prd → team-exec → team-verify → team-fix (loop)

翻译成人话：先把需求问清楚，再出 PRD，然后执行，执行完自动验证，验不过就修，修完再验。

它的价值不只是把流程串起来，而是把"写的人"和"挑错的人"拆成不同角色，让质量控制从人为切换变成系统默认。

这套流程回答的是多 agent 对抗里最现实的几个问题：

• 需求模糊时，先写还是先问？（team-plan 先澄清）
• 写完之后谁负责验？（team-verify 自动触发）
• 验不过怎么办？（team-fix loop 自动回退重做）
• 什么时候才算 done？（有明确的通过条件，而不是"差不多能跑了"）

v4.4.0 之后，它还能用 omc team N:codex|gemini|claude 在 tmux 里拉起真实 CLI worker——不同模型跑不同角色，按需启动，任务完成就销毁。

这才是重点：不是 agent 数量变多了，而是对抗流程不再需要人来手动推进了。

但要注意：自动化对抗也有盲区

当然，我的保留意见也很明确。

当 reviewer 也是 AI 的时候，它和 coder 可能共享同类盲区——同一个模型家族对某类漏洞的敏感度就是比另一类低。自动化的对抗流程会让你产生"已经被审过了"的安全感，但这个安全感可能是假的。

复杂度没有消失，只是换了个位置。

以前你的工作是"亲自推流程"，现在变成"设计对抗结构"——该让哪些模型互审？verify 的通过条件怎么定？哪些场景不能只靠 AI 对抗，必须拉人进来？

人的角色从"调度员"升级到了"对抗架构师"。这比盯流程高级，但并不轻松。

最后

CLI 成为主流开发入口，这件事本身只是界面层的变化。

真正值得关注的后果是：多 agent 对抗正在从个别极客的高阶玩法，变成每个 AI 编程用户都会遇到的基本模式。

谁先把这个模式跑顺，谁就能在 AI 辅助开发里拿到更高的代码质量和更低的心智负担。

但跑顺的前提，不是模型够强，也不是 terminal 够多。是你理解对抗的逻辑、设计好对抗的结构，然后把编排交给工具。

未来 AI 编程真正会沉淀下来的，不是"谁的 agent 更多"，而是"谁先把多 agent 对抗做成默认工作流"。