Claude Code Workflow 高级用法实战
公众号名称：Agent101
作者名称：Hunter
发布时间：2026-06-07 00:03
【上手实战】上次讲了 Claude Code 的 dynamic workflows 是什么、五级阶梯怎么选。这次往深里走一层：我用一个真实开源项目实测了三个高级技巧——怎么先审计 plan 再执行、怎么逐阶段指定模型把 token 砍下来、怎么在 workflow 里调用 MCP 和 Codex，让 Claude 和 Codex 双引擎一起找 bug。
上一篇我把 dynamic workflows 是什么、它和 skill、sub-agent、agent team、goal 怎么分讲清楚了。这篇接着往下走。光知道概念不够，真正值钱的是怎么把它用好、用省、用强。
我找了个有大量真实 bug 的开源项目当靶子，把三个高级技巧挨个跑了一遍。下面是实测过程。
先说个版本细节。最新版 Claude Code 里，触发动态工作流的关键词从 workflow 改成了 ultracode。你在输入框敲 ultracode，看到它高亮成那种彩色效果，就说明动态工作流功能已经激活，后面跟上你的任务就行。我用的版本是 v2.1.162。
cover
技巧一：先看 plan，别让它直接跑
这是最重要的一条习惯。
动态工作流一启动，可能瞬间派生出几十个 agent 并行干活。如果你上来就让它执行，token 哗哗地烧，跑完才发现方向不对，钱已经花了。
所以我的第一条任务，是让它只读分析这个项目最近 50 个 open issues，找出 top 10 高优先级的，但是——先展示 workflow plan，不要立即执行。
它输出的 plan 很完整。先是一张流程图：第一步抓取仓库里 50 个 issues，确认抓取成功后才调用 workflow。整个 pipeline 分三段，issues 分析、验证、合成。分析阶段每个 issue 派一个 agent（数量不超过 50），验证阶段每个 issue 也分一个 agent，最后合成只用一个 agent。
它还给出了完整的 workflow JavaScript 脚本代码，让我先审查。甚至主动提示「运行前需要锁定两个会改变结果的决策」——高优先级怎么排序、分析深度选哪档。我按它的提示选了默认项，确认没问题，才按下执行。
这就是关键：你审的是 plan，不是结果。把决策点提前，把脚本看一遍，再决定要不要花这个钱。
plan-审计
如果想看得更细，可以在任务里直接要求它在运行前展示每个阶段预计用多少 agent、检查哪些文件、用什么模型、停止条件是什么、最终验收标准是什么。它会把这张表完整列出来：第一阶段拉元数据不需要 agent，第二阶段每个 issue 分析、第三阶段对抗验证、第四阶段合成报告。每一阶段的 agent 数量、用的模型、检查项，一目了然。
技巧二：逐阶段换模型，把 token 砍下来
看那张表的时候我注意到一个问题：它每一阶段默认都用 Opus 模型。
Opus 很强，但也很贵。一个分析 50 个 issue 的任务，每阶段几十个 agent 全用 Opus，账单会很难看。
而 workflow 一个很爽的点是——你可以逐阶段指定模型。
我直接用提示词让它把第二阶段和第三阶段的模型换成更便宜的。它很聪明地给了我三个组合建议：一是两阶段都用 Sonnet；二是分析用 Haiku、验证用 Sonnet；三是两阶段都用 Haiku。
我选了第二个——Haiku 分析、Sonnet 验证。运行起来，切到第二阶段看，用的确实是 Haiku；切到第三阶段，用的是 Sonnet。
模型分配
这个设计很合理。分析阶段是大批量的初筛，用便宜快的 Haiku 扛量；验证阶段要做对抗判断、需要更强的推理，用 Sonnet。合成报告这种关键收口，留给 Opus。把贵的算力用在刀刃上，便宜的活交给便宜的模型，token 一下省下来。
技巧三：在 workflow 里调 MCP 和 Codex
前面两个是控成本，这个是放大能力。
先是 MCP。我让 workflow 调用 CodeGraph 这个项目来分析一个开源仓库的潜在 bug。任务里我给了总预算 200 万 token，要求用 CodeGraph MCP 做代码导航，重点关注某几个模块，输出简洁的 markdown 报告，照例先展示 plan。
它生成 plan 后我确认运行。点进任意一个 agent 看，能清楚看到它在调用 CodeGraph MCP，连每个 agent 调了几个工具都看得到。
这一步的意义在于：workflow 里的每个 agent 不再是光秃秃的模型，而是能接上你的数据源、你的工具链。MCP 能连什么，workflow 里的 agent 就能用什么。
调用MCP
更狠的是第三个——在 workflow 里调 Codex。
我让它对一个开源项目做只读交叉验证 review，目标是找潜在 bug、不改代码。要求启动三路独立 review：第一路调用 Codex CLI、第二路用 Opus 独立审查、第三路用 Sonnet 独立审查。还特意叮嘱：Codex 只启动一次，单一 review，不可用就标记不可用，不许假装执行，只做基于代码证据的判断。
运行起来，第一阶段三个 agent 各就各位。点进第一个，能看到它正在用 Sonnet 驱动 Codex CLI 命令对项目做审查。有意思的是 token 消耗对比：Opus 和 Sonnet 那两路各烧了 100 多 k token，而调用 Codex CLI 那路只花了 20k。
最后它输出了交叉验证报告，确认了 5 个 bug，附详细描述和修复建议。
为什么要拉 Codex 进来？因为Codex 对代码的 review 能力很强，很多 Claude 系模型发现不了的潜在 bug，Codex 反而能挖出来。让两套不同的引擎从不同角度审同一份代码，比单靠一家更靠谱。
Codex交叉验证
这个脚本生成后还能复用。在编辑器里打开能看到，它创建了一个 agent，用 Sonnet 模型驱动这个 agent 去调 Codex CLI。下次要 review 别的项目，直接把这个脚本复用过去就行。
三个技巧串起来看
这三招其实是一条完整的工作方法。
先用「展示 plan 不执行」把决策点提前，审完脚本再花钱。再用「逐阶段指定模型」把成本压到合理区间——Haiku 扛量、Sonnet 验证、Opus 收口。最后用「调 MCP 和 Codex」把单纯的模型并行，升级成接得上数据、扯得动外部工具、多引擎交叉验证的真正生产力。
上一篇我说，搞清楚自己的活在梯子的哪一级，比追最新功能重要。这一篇可以补一句：当你真的要用 workflow 这种重武器时，先审计、再控本、后增强，这三步能让它从一个烧钱的玩具，变成一个能交付的工具。
我自己跑 11 个产品，真正需要动用 workflow 的场景不多。但一旦要审整个代码库、做大规模交叉验证，这套打法就是我会用的。
内容效果不满意？点此反馈