先明确起点：第三课那条 KMP 重构流水线，你已经亲手设计并跑通了一条 30-40 个 Agent 的全自动 Workflow——10 个单元全部 MERGED、零 BLOCKED。所以这一课不教"怎么开"，教的是两件你还缺的东西：
Dynamic Workflows 很贵——Anthropic 官方工程博客给的量化：multi-agent 系统消耗约为普通 chat 的 ~15 倍 token。所以判断先于技巧。对任何任务问三个问题：
成本判断一句话：舰队只配高价值任务——答案的价值得盖过 ~15× 的 token 账单。官方的护栏也印证了这一点：最多 16 个并发 agent、单次 run 上限 1000 个。日常小修小补开舰队，等于打车去隔壁便利店。
| 姿势 | 怎么触发 | 作用范围 |
|---|---|---|
| ultracode 关键词 | prompt 里任意位置写 ultracode（UI 会高亮；Option+W 可取消） | 只对这一条任务强制走 workflow |
| 自然语言 | 直接说 "use a workflow" / "用 workflow 跑" | 同上，等价写法 |
| session 级开关 | /effort ultracode = xhigh 推理 + 自动编排，Claude 自己判断每个任务是否开舰队，一个请求可能连开几个（理解→修改→验证） | 整个 session；结束即重置。官方建议日常用 /effort high |
冷知识：触发词原本叫 workflow，v2.1.160（2026-06）改名 ultracode——旧词太容易在正常对话里误触。注意和 ultrathink 区分：ultrathink 是单条消息推理加深，不开 agent；ultracode 是开舰队。
workflow 的本质是把编排计划从模型的逐轮判断移进代码——循环、分支、中间结果都存在脚本变量里，不占主上下文，官方的说法是 "routing the fleet is free"。官方文档的最小示例：
export const meta = {
name: 'audit-routes',
description: 'Audit every route handler for missing auth checks',
}
// 侦察：先拿到工作清单（schema 强制结构化输出，不匹配自动重试）
const found = await agent('List every .ts file under src/routes/.', {
schema: { type:'object', required:['files'],
properties:{ files:{ type:'array', items:{ type:'string' } } } },
})
// 逐文件流水线处理
const audits = await pipeline(found.files, file =>
agent(`Audit ${file} for missing authentication checks.`, { label:file }),
)
return audits.filter(Boolean)
| 原语 | 语义 | 关键点 |
|---|---|---|
agent(prompt, opts) | 派一个子 agent | opts：schema（结构化输出）/ label / phase / model（按阶段换模型）/ isolation:'worktree'（并行写同一批文件时才用） |
pipeline(items, ...stages) | 每个条目独立流过所有阶段，无屏障 | 条目 A 在第 3 段时条目 B 可以还在第 1 段——不空等，默认首选 |
parallel(thunks) | 并发执行 + 屏障（全部完成才返回） | 失败的解析为 null 不抛异常，记得 .filter(Boolean) |
phase(title) / log(msg) | 进度分组 / 叙述行 | 对应 /workflows 面板里的分组和进度 |
最重要的设计决策就一个：pipeline 还是 parallel。默认 pipeline；只有当下一步真的需要全部上游结果（全量去重、总数为零就早退、互相比较排序）时才用 parallel 加屏障。屏障的代价是真实的：5 个 finder 里最慢的跑 3 倍时长，其余 4 个就白等 2/3 的时间。
脚本里调 Date.now()、Math.random()、无参 new Date() 会直接抛异常。这不是缺陷，是"确定性编排"的具体落点：runtime 对每次 agent() 调用记 journal，暂停/中断后 resume 时，已完成的 agent 直接返回缓存结果，只有剩余部分真跑——脚本必须可重放才能做到。时间戳要用就从 args 传入。限制：resume 仅限同一 session；退出 Claude Code 后只能从头跑。
这是官方明确的立场：workflow 的价值不是"更多 agent"，而是可复现的质量结构。Anthropic 工程博客《How we built our multi-agent research system》给了三个应该背下来的数字：
四个可直接抄的质量模式（内置的 /deep-research 就是它们的产品化版本——每条结论派 3 个 skeptic 投票，没通过交叉验证的标 unverified）：
| 模式 | 结构 | 治什么病 |
|---|---|---|
| 对抗验证 adversarial verify | 每条发现派 N 个独立"反驳者"专门证伪，多数存活才保留 | 貌似合理但错的产出（自产自评必然放过它） |
| 多视角验证 diverse lenses | N 个 verifier 各持一个视角（正确性/安全/性能/可复现），而非 N 个同质副本 | 单一视角的盲区——冗余抓不到的失效模式 |
| 评审团 judge panel | N 个不同角度的方案 + 并行评审打分，从赢家合成、嫁接亚军优点；进阶用两两对比而非绝对打分 | 解空间宽的设计题，单方案迭代容易局部最优 |
| 挖到干涸 loop-until-dry | 发现类任务持续派 finder，连续 K 轮无新发现才停；去重要对"见过的一切" | "找 10 个就收工"式的假完整——尾部问题漏网 |
省钱技巧（官方明说）：agent() 可按阶段传 model——不需要旗舰的阶段用轻量模型。典型分层：强模型规划与评审、轻模型批量执行机械步骤。再配预算硬顶：prompt 尾部加 +200k 这类 token 目标，打到即停（该语法官方文档着墨少，以实测为准）。
| 按键 | 作用 |
|---|---|
↑↓ / Enter | 选择 run / 下钻到单个 agent（看 prompt、最近工具调用、结果） |
p / x / r | 暂停或恢复 / 停掉单个 agent 或整个 run / 重启 agent |
f | 按状态过滤（只看失败的） |
s | 存成斜杠命令：项目级存 .claude/workflows/（团队共享），个人级存 ~/.claude/workflows/，之后 /<name> 直接复用，支持传参 |
两个容易踩的运维点：① workflow 派生的子 agent 一律以 acceptEdits 跑（文件编辑自动放行），但 shell/网络仍走 allowlist——长任务开跑前先补 allowlist 是官方明说的最佳实践，否则半夜卡在权限提示上；② 每次 run 的脚本会落盘到 session 目录，可读、可 diff、可手改后让 Claude 重新发起——你上次审 refactor-workflow.mjs 的技能直接迁移过来。
agents.max_threads 默认 6 并发、嵌套深度默认 1 层，没有用户可读的编排脚本（experimental 的 spawn_agents_on_csv 算半个：CSV 每行起一个 worker，支持列名占位符）；要确定性编排得把 Codex CLI 暴露成 MCP server、用 Agents SDK 在外面写。大规模并行走 Codex Cloud：并行任务队列（各自 sandbox + 独立 git 状态）+ best-of-N——本机实测 flag 是 codex cloud exec --attempts N，再 cloud diff --attempt 挑候选（CLI 侧仍标 EXPERIMENTAL）。一句话记分工：Claude Code 是"脚本在产品里"，Codex 是"编排在 SDK 里/云上"。本地开舰队 → Claude Code Dynamic Workflows；想要"下班后云端替你并行试几个方案再挑" → Codex Cloud / best-of-N（第七课云端异步细讲）。
refactor-workflow.mjs，逐段对照官方原语——你手写的"关卡"= phase() + parallel 屏障；"并行改造互不干扰"= isolation:'worktree'；"对抗 review 关"= adversarial verify 模式。找出至少一处官方原语能替你省掉的手写复杂度（提示：看你当时怎么处理失败单元和中间结果传递）。/workflows 面板观察 phase / agent / token，跑完按 s 存成斜杠命令。话术模板：ultracode: 审计 <你的模块> 下所有 <目标>（如：日志 tag 不符合分层规范的文件）， 每个文件一个 agent 并行找；对每条发现派一个独立 agent 专门反驳， 只报告存活的发现，按严重度排序。
+200k 设硬顶。把 ① 的对照发现和 ② 的 token 单价发回给我——这两个数据决定第七课（云端异步）从哪里接。
1. 一个大任务摆在面前，最能说明"该开 workflow"的信号是？
2. 编排脚本里，pipeline 和 parallel 的正确取舍是？
3. Anthropic 官方研究中，解释 multi-agent 性能方差最大的单一因素是？
4. 流程中间必须由你拍板（如方案冻结）的大改造，正确的编排是？
Anthropic — How we built our multi-agent research system（约 20 分钟）。90.2%、80%、15× 三个数字的出处，也是理解"为什么舰队的本质是 token 结构而不是 agent 数量"的一手材料——今天的 /deep-research 和 Dynamic Workflows 都是这篇文章思路的产品化。
点卡片翻面。记的是能用的判断核心，不是定义。
能讲清楚，才是真懂——比能回忆高一层。
讲不顺的地方就是还没真懂的地方 —— 发给我，我帮你补上。