引言
这个系列已经讲过 Claude Code 的底层运行机制和四层扩展能力的分工。但到这里还有一个问题没解决：当任务复杂到单个 Agent 扛不动，你怎么编排？编排完了，你怎么保证它不跑偏、不偷懒、不越界？
这两个问题，对应 Claude Code 最近两个最重要的能力：动态工作流（Dynamic Workflows）和 Loop Engineering。
一、动态工作流：Claude 自己写 harness，你只负责目标和边界
harness 是什么？就是控制 Claude 读什么、什么时候动手、产出怎么验证的那层编排。Claude Code 自带的默认 harness 打磨得很好，但它是冲着"写代码"这件事调出来的。
而你实际让 Claude Code 干的活远不止写代码：深度调研、安全审计、代码迁移、多人评审。这些任务的"最佳跑法"和写代码不一样。过去要把它们做到极致，你得自己手搓一套 harness。
动态工作流的意思就一句话：这套针对任务的 harness，不用你手搓了，Claude 自己现场写。
工作流是真代码，不是提示词
关键区别：动态工作流是 Claude 现场生成、然后真的拿去执行的 JavaScript 文件，不是"一段精心调过的提示词"。它有三个基本积木：
agent(prompt, opts)：开一个子 Agent，给它独立上下文窗口，还能用 JSON Schema 约束输出结构parallel(...)：栅栏——几个任务全跑完才放行pipeline(items, ...)：流水线——让一批东西过几道工序，A 项先走，B 项慢一点也不挡道
Claude 拿这几块积木，针对你的任务搭出一套编排：要不要开子 Agent、开几个、哪步用强模型哪步用便宜模型、要不要用 git worktree 把不同方案隔开、哪些并行哪些串行——这些不是你预先规定死的，是 Claude 分析完任务自己定的。
为什么非得这么折腾？单个上下文扛不动
长任务里，一个 Claude 单挑全部时，老三样毛病会准时冒出来：
- 偷懒：审 50 个文件审到 35 个就说"干完了"——不是模型坏了，是上下文塞满了，它把"差不多"当成了"做完"
- 自夸：让 Claude 验自己的活，它会偏向维护自己之前的结论
- 跑偏：对话拉长，反复压缩摘要，把边界要求、约束条件一点点丢掉
动态工作流的解法是结构性的——与其让一个 Claude 扛全部，不如开一堆互相隔离、各自上下文干净、只盯一件事的子 Agent。隔离让偷懒无处藏，独立的验证 Agent 让自夸自然消失，每个窗口都短让跑偏被摁住。
六种最常复用的编排模式
| 模式 | 怎么跑 | 适合 |
|---|---|---|
| 分类即处理 | 先分流，再路由给专门 Agent | 工单 triage、产出归档 |
| 扇出+汇总 | 拆多份并行各跑一个 Agent，栅栏处汇总 | 审计、跨模块独立评审 |
| 对抗验证 | 一个提出，另一个专挑刺，互不共享上下文 | 根因排查、结论复核 |
| 生成+筛选 | 先广撒网生成候选，再按标准筛掉弱的 | 方案探索、测试用例 |
| 锦标赛 | 多个 Agent 同题竞赛，裁判两两比较选优 | 模型路由、方案择优 |
| 跑到收工为止 | 反复动手—检查—修复，直到满足停止条件 | 开放式排查、清扫式发现 |
对抗验证最该记住：验活的和干活的彻底分家、互不通气，一个结论只有在"反驳失败"之后才算数。
怎么用、怎么存、怎么分享
触发方法：直接说"给这个任务做一套工作流"，或者把 effort 调到 ultracode，让 Claude 自己判断。
盯进度：/workflows 打开运行面板，每个阶段、每个子 Agent、每次工具调用和 token 消耗都看得到，还能暂停、跳过卡住的、重试单个 Agent。
存下来复用：面板里按 s 存到 ~/.claude/workflows。一次漂亮的根因排查，就能沉淀成一套"根因排查工作流"；一次漂亮的迁移，就能沉淀成"迁移工作流"。分享也简单——把 JS 文件丢进 Skill 文件夹发给队友。但记住它是模板不是死脚本，会根据具体任务自适应。
别滥用：它很烧 token
动态工作流比普通单 Agent 会话烧多得多的 token。判断标准：这个任务是不是真的需要比"一个上下文窗口"更多的算力？
- 值得上：50 个文件的安全审计、上千行的排序打分、高不确定要反复探索的调研、高风险要独立验证的改动
- 别上：两行的 bug、改一个文件——杀鸡用牛刀，钱白烧
二、Loop Engineering：14 步让自动化不失控
动态工作流解决了"怎么编排"，但还有一个更重要的问题：怎么保证编排不跑偏？ 这就是 Loop Engineering 要解决的事——不是怎么搭 loop，而是怎么搭一个能长期守住、不失控、不越界的 loop。
Loop 不是免费的，先问四个问题
- 任务是重复的吗？ Loop 的搭建成本要靠多次运行摊回来。一次性的活儿，写个好 Prompt 更快。
- 有自动检查机制吗？ 测试、类型检查、linter，随便哪个都行。没有自动检查，你就得自己逐行读 diff，loop 没帮你省时间。
- Token 预算够吗？ Loop 会反复读上下文、重试、试探，不管有没有产出都在烧 token。
- Agent 能跑自己写的代码吗？ 需要有日志、能复现、看得到哪里崩。
还有个附加题比上面四个都重要：你打算 review 它产出的代码吗？ 不打算，就别建 loop。
五个核心构件
- Automations：loop 的心跳，按节奏触发，关键是停止条件要写死
- Worktrees：多个 Agent 同时干活，给每个 Agent 一份独立工作区，互不干扰
- Skills：把项目背景写下来，Agent 每轮直接读
- Connectors：通过 MCP 接上 GitHub、工单系统、Slack、监控，loop 才算真正接入工作流
- Sub-agents：写代码和验收的分开，验收的那个要专挑刺
14 步路线图
第一段：先想清楚要不要做（5 步）
跟上面四个问题基本一致，再加一个：确认你真打算 review。
第二段：搭一个最小能跑的 loop（8 步）
- 先让一次手动运行稳定下来——顺序别跳，先手动跑一遍确认每一步都通
- 把项目背景沉淀成一个 Skill——省得每轮从零解释
- 加一个状态文件——记下做完了什么、下一步干啥，这是 loop 的记忆
- 设一道硬闸门——测试/构建过不了就自动拒，这是你能放心走开的唯一保障
- 配一个 Automation——按节奏触发，用停止条件控制什么时候停
- 多 Agent 并行就上 Worktree——别让它们改同一个文件打架
- 接上 Connectors——让 loop 能开 PR、更新 ticket、发通知
- 拆出 Sub-agents——写代码的和验收的分开
第三段：上线之后守住（这步最难）
- 盯一个指标：每个被接受的改动的成本。接受率低于 50%，这 loop 就在亏本。定期复审权限——今天加一个写权限，明天再加一个，每 30 天复审一次、砍掉不需要的。读 diff——别因为"loop 产出的"就不读了。别让 loop 碰架构——loop 能干的是重复劳动、机械校验、低风险的小改动；架构决策、重构、核心逻辑，必须人来做。
上线后的三种翻车方式
- 假装干完了：Agent 提前发"完成"信号，活干一半就退。原因：没有硬闸门。解法：回到第 9 步。
- 理解债务：loop 越快交付你没写过的代码，“仓库里有什么"和"你理解什么"的差距就越大。有一天你得 debug 一个团队里没人读过的系统。解法：读 diff，抽查。
- 认知投降：你慢慢不再自己判断，loop 返回啥就收啥。这是最隐蔽也最致命的一种翻车。解法：守住第 14 步。
安全红线
- 生成代码未审就上线——闸门里得加 SAST、依赖审计、密钥扫描
- Skill 是注入入口——社区 17000+ 个 skill 里有 520 个会泄露凭证，自动安装前先读源码
- 凭证泄露进日志——生产 loop 关掉 verbose 日志
- 权限蔓延——每 30 天复审一次
无人值守不等于无人负责。 loop 出了安全问题，背锅的还是你。
总结
这两件事放在一起看，是一个完整的 Agent 编排体系：
- 动态工作流解决"怎么搭”——Claude 现场分析任务，自己写 harness，把一个大任务拆给一队互相隔离的 Agent
- Loop Engineering解决"怎么守住"——从要不要做、到怎么搭、到上线后怎么盯，让自动化在失控之前停下来
两年来与编码 Agent 协作的杠杆一直在提示词上。而现在，工作流成了真正的护城河。 编排这件事，正在从"人来设计架构"挪到"模型自己决定"。你只负责说清楚什么算成功、信任边界在哪，剩下的那套外壳，Claude 自己搭。
参考链接
- Anthropic Blog: Dynamic workflows in Claude Code
- Addy Osmani: Loop Engineering
- Anthropic 工程文档