工作流篇 · Plan 模式与结构化编排

2026-07-07 16:20 Claude Code; Plan 模式; Workflows; 多智能体; Agent 2740 字 14 min read

前面几篇讲的都是”Claude 自己决定怎么做”——它读代码、选工具、委派子智能体,链路全在模型的判断里。这一篇讲两个把控制权部分收回到人手里的机制:

Plan 模式
,先让 Claude 把方案摊开给你看,对齐意图再执行。
Workflows
JavaScript 代码,把”先做什么、再做什么、哪些能并行”钉死,不再靠提示词去”请求”模型调度。

一个管”执行前的对齐”,一个管”执行中的骨架”。它们回答的是同一个焦虑:当任务复杂到一定程度,你还敢不敢把方向盘完全交给模型?

一、Plan 模式
Agent 一个”合法的思考空间”

为什么需要”先想后做”

没有 Plan 模式的 Agent 面对复杂任务时,会陷入一个两难:

要么在第一轮就盲目动手——高风险,方向错了要回滚;
要么每一轮都反复读代码但不做决定——低效,你看着它绕圈子。

Plan 模式解决的核心问题,书里叫**“过早行动”(Premature Action)**。它把 Agent 的行为切成两个阶段:

只读探索阶段(规划)  →  可写执行阶段(实施)
   不改文件               对齐后才动手
   不跑命令
   纠错成本≈0

这个设计有个很贴切的类比

。他会先画图纸、跟甲方确认设计意图、评估结构可行性,然后才动工。改一张图纸比拆一面墙便宜得多。 Plan 模式就是给 Agent 一个”画图纸”的阶段——在这里它可以自由探索而不被期望产出实际结果,直到确信自己理解了问题全貌。

看几个典型场景的对比就明白它的价值:

场景	无 Plan 模式	有 Plan 模式
误解需求	实现了错误功能,需要回滚	只读阶段发现误解,零成本修正
忽略已有模式	写出与项目风格不一致的代码	先探索发现既有模式,再实施
方案选择失误	实现了性能差的方案,需要重写	对比多个方案的 trade-off 后再动手
遗漏边界情况	代码写完才发现遗漏,返工	规划中枚举边界情况并纳入方案

六步认知模型

进入 Plan 模式后,Claude 收到的不是一句”开始规划”,而是一段明确的行为指令:

1. 深入探索代码库,理解现有模式
2. 识别相似特性和架构方法
3. 考虑多种方案及其权衡
4. 需要时用 AskUserQuestion 澄清
5. 设计具体的实施策略
6. 准备好后,用 ExitPlanMode 呈现计划

记住:现在还不要写或改任何文件。这是只读的探索和规划阶段。

这六步不是随意列举,而是一个从发散到收敛的思维过程:

Step 1-2(发散)
,理解代码结构、发现相似实现;
Step 3-4(过渡)
,但仍然开放,必要时向你提问;
Step 5-6(收敛)
,呈现给你审批。

理解这个模型对使用者有直接价值:如果你发现 Claude 的计划质量差,往往是发散阶段信息不足。 给它更具体的探索目标(比如指明相关模块、贴一个类似功能的文件路径),比反复否决它的计划更有效。

两个值得注意的设计约束

子 Agent 不能进入 Plan 模式。 这是架构层面的硬约束。想象一下

Agent 进入 Plan 模式,它会等待用户审批计划,而你可能根本不知道这个子 Agent 的存在——整个父 Agent 的执行会被阻塞在一个你无法理解的审批请求上。所以 Plan 模式只属于主会话。

退出时有个”断路器”防御。 进入 Plan 模式时权限模式可能是 auto(自动批准),但 Plan 模式可能持续几十分钟。在这期间,auto 可能因为系统负载或安全策略变更被关闭。退出 Plan 模式时,系统会重新检查

auto 但现在 auto 的门已经关了,就回退到 default(需要确认),而不是盲目恢复。这个细节揭示了一个安全系统的通用原则——恢复状态时要重新校验,而不是无条件信任保存的旧值。

实战心法
Plan 模式

一位重度用户(sshh.io)的经验值得参考:

对于任何”大型”功能变更,规划都是必不可少的。经常使用 Plan 模式可以培养一种强大的直觉——需要提供多少最少的上下文,才能得到一个好的计划,而不会让 Claude 在实现阶段搞砸。

操作上,交互模式下按 Shift+Tab 进入 Plan 模式(再按返回),Claude 会给出方案,你确认无误后再让它执行。方向不对时随时干预,成本几乎为零。

二、Workflows

Plan 模式解决的是”单次任务执行前的对齐”。但当你要的是一套可复用、可并行、结果可信的多智能体流程时,Plan 模式就不够了——它还是靠模型在运行时临场判断。

Claude Code 的 Workflows 特性(实验性,需较新版本通过 workflows 命令触发)给出了另一条路:用一段纯 JavaScript 脚本,确定性地编排多个子智能体。

和以往多 Agent 方案的本质区别

在 Workflows 之前,社区做多 Agent 编排无非两种路子:

靠提示词”请求”模型调度——模型会跳步、会忘、会跑偏;
社区自己造轮子模拟控制流——各写各的,不通用。

Workflows 直接把编排逻辑从提示词中拽出来,用确定性代码实现。有人用《左传》的”经纬”来比喻这套设计,很传神:

meta 与 phase 是经——确定性的结构骨架,预先张紧、不可动摇;agent()、parallel()、pipeline() 是纬——在骨架中穿梭执行的智能单元。经线决定流水线的形状,纬线填入真正的工作。

一句话概括 Workflow 的边界:能画成”先做什么 → 再做什么 → 哪些能并行”流程图的东西,就能写成 Workflow。

几个核心原语

原语	作用
`meta`	工作流的元信息(名称、描述、阶段声明),必须是纯字面量
`agent(prompt, opts)`	生成一个子智能体,可带 `schema` 强制结构化输出
`phase(title)`	划分阶段,后续 agent 归到这个阶段的进度分组
`parallel(thunks)`	并行执行,屏障
`pipeline(items, ...stages)`	流水线,无屏障 item 独立流过各 stage
`budget`	token 预算,支持动态循环和静态扩缩

其中最容易踩坑的是 parallel() 和 pipeline() 的区别:

parallel() 是屏障——所有任务必须全部完成才返回结果。适合”我需要所有结果凑齐才能下一步”。
pipeline() 是流水线——item A 可以在 stage 3,而 item B 还在 stage 1,各自独立流过。墙钟时间等于”最慢的单条链路”,而不是”每阶段最慢之和”。

这个区别直接影响性能。当你的多个任务之间没有”必须凑齐”的依赖时,pipeline() 几乎总是更快。

让结果”经得起质疑”的进阶模式

编排跑通只是第一步。真正让 Workflow 有价值的,是一组保证结果可信的模式(社区实战手册里总结的):

对抗验证
agent 去质疑另一个 agent 的产出,而不是自说自话;
循环到干(loop-until-dry)
;
完整性批判
agent 检查”有没有遗漏”;
worktree 隔离写入
agent 并行改文件时,各自在独立 git worktree 里操作,避免冲突;
断点续传
,跑一半挂了能接着来。

这些模式的共同点是:不满足于”跑出来就完事”,而是让过程和结果都经得起推敲。 这恰好呼应了整个 Claude Code 设计里反复出现的主题——自动化的效率必须配上可验证的护栏。

三、两个机制的关系

Plan 模式和 Workflows 看似是两个独立特性,但放在一起看,它们其实是同一个控制光谱上的两个点:

完全自主  ──────────────────────────────►  完全确定
   │              │                │
 普通对话      Plan 模式        Workflows
 模型全权     执行前人工对齐    代码钉死流程骨架

普通对话
,模型全权决定怎么做——灵活,但复杂任务下不可控;
Plan 模式
,但执行前必须先让你过目——在灵活和可控之间取平衡;
Workflows
你写的代码决定,模型只在骨架的每个格子里填内容——最可控,但需要你先想清楚流程。

选择哪个,取决于任务的确定性程度:

一次性的、探索性的任务 → 普通对话或 Plan 模式;
反复要做的、有明确流程的、需要并行提速的任务 → Workflow。

有个观点值得记住:原生 Workflow 给了确定性骨架,优秀的社区实践(磁盘状态续命、Hook 注入、工具层护栏)才能铸成它的血肉。 骨架保证流程不跑偏,血肉保证结果可信——两者缺一不可。

小结

Plan 模式把”执行前对齐意图”变成一等公民,用”只读探索 → 审批 → 执行”三段式,把纠错成本降到接近零。它的六步认知模型是一个从发散到收敛的思维过程。
Workflows把编排逻辑从提示词里拿出来,用确定性代码(agent/parallel/pipeline/phase)钉死流程骨架,不再靠模型临场调度。parallel 是屏障、pipeline 是流水线,是最关键的区别。
两者是”控制权光谱”上的不同点
、越需要复用和并行,就越往 Workflows 这端走。

下一篇进入对比篇,把 Claude Code 和 Codex 放在一起,看看两个顶级 Agent 工具在设计取向上的真实差异。

本文主要参考:

《御舆
Agent Harness》(lintsinghua/claude-code-book,CC BY-NC-SA 4.0)第 14 章”Plan 模式与结构化工作流”
《织经
Code 官方 Workflows 深度剖析》(Linux.do 社区,linux.do/t/topic/2260152)
“How I Use Every Claude Code Feature”(blog.sshh.io)Plan 模式部分

本文为学习整合的二次创作,Claude Code 为 Anthropic PBC 产品,相关架构分析基于公开资料。

一、Plan 模式 Agent 一个”合法的思考空间”