Claude Code-Dynamic Workflows：1.为什么用工作流？
为什么用工作流
如果你经常让 Claude 做长任务，应该见过这种情况：它一开始很认真，越往后越像在“凭感觉收尾”。不是模型突然变差了，而是我们把太多事情塞进了同一个对话窗口：规划、执行、验证、记忆约束、汇总结论，全都挤在一起。
工作流要解决的不是“让 AI 更努力”，而是把长任务拆成可调度、可验证、可恢复的过程。
先说结论
普通对话适合短任务。工作流适合这类任务：
- 量大：一次要读很多文件、查很多资料、跑很多检查。
- 可拆分：任务天然能拆成多个相对独立的小块。
- 需要交叉检查：不能只让同一个 agent 自己说自己做得好。
一句话判断：
当任务“量大、可拆分、需要交叉检查”时，就用工作流。
反过来，常规的、短的、一个上下文装得下的任务，别用。工作流更费 token，也更需要设计编排方式。
1. 普通对话的瓶颈
普通对话里的 Claude 像一个人逐件处理：它既要记住目标，又要规划步骤，还要执行和自检。短平快的活没问题，但任务一长、材料一多，问题就会集中爆发。
2. 长任务的三个通病
| 通病 | 英文 | 典型表现 |
|---|---|---|
| 偷懒 | Agentic laziness | 干到一半就宣布完工。安全审查列了 50 项，检查完 20 项就说搞定了 |
| 自我偏好 | Self-preferential bias | 让 AI 自己验证自己的结果，它倾向于说“挺好的” |
| 目标漂移 | Goal drift | 上下文压缩时，原始目标慢慢走形。“不要做 X”这类约束，压缩几次就丢了 |
这三点是理解动态工作流一切设计的钥匙。后面每一种编排手法，本质上都在对治其中某个病。
3. 工作流的解法
工作流不是让一个 Claude 从头干到尾，而是让Claude 自己写一段 JavaScript 调度脚本。这段脚本按需派出一群子 agent，每个子 agent 都有自己独立的上下文窗口和目标。
更关键的是：计划不再完全放在 Claude 的对话上下文里，而是搬进了脚本。
这个结构带来三个直接结果：
| 普通对话的病 | 工作流怎么治 |
|---|---|
| 偷懒 / 装不下 | 拆分成几十上百个子任务，每个子 agent 只盯一小块 |
| 自我偏好 | 换一个 agent来验证，而不是让它检查自己 |
| 目标漂移 | 每个子 agent目标独立、上下文干净，不会被压缩稀释 |
中间结果留在脚本变量里，不必全部塞回你的主对话上下文。主对话只需要看到调度后的关键结论。
4. 它和 subagents / skills / agent teams 有什么不同？
官方文档把这四者放在一起对比，核心区别是：谁持有 plan，谁决定下一步跑什么。
| Subagents | Skills | Agent teams | Workflows | |
|---|---|---|---|---|
| 是什么 | Claude 派的一个工人 | Claude 遵循的指令 | 一个 lead 监督多个对等会话 | 运行时执行的一段脚本 |
| 谁决定下一步 | Claude，逐回合 | Claude，按提示 | lead，逐回合 | 脚本 |
| 中间结果存哪 | Claude 上下文 | Claude 上下文 | 共享任务列表 | 脚本变量 |
| 可复用的是 | 工人定义 | 指令 | 团队定义 | 编排本身 |
| 规模 | 每回合几个 | 同 subagents | 少量长跑对等体 | 每次几十到上百个代理 |
| 被中断时 | 重启当前回合 | 重启当前回合 | 队友继续跑 | 同会话内可恢复 |
一句话：工作流把“计划”搬进了代码。其它三者里，Claude 仍然是主要编排者，结果也主要落在上下文窗口；工作流让脚本持有循环、分支和中间结果，Claude 的上下文里只剩最终答案。
这也是它能施加“可复用质量套路”的原因，比如让独立代理互相对抗审查、让生成和筛选分离、让长任务按阶段推进。
5. 动态 vs 静态工作流
| 静态工作流 | 动态工作流 | |
|---|---|---|
| 特点 | 预先写死流程，需覆盖所有边界情况，通常更通用 | Claude为你的具体任务现写一个定制调度器 |
| 例子：供应商迁移 | 五个网络搜索 → 取顶级结果 → 验证 → 总结，出一份通用报告 | 读取你的计费代码 → 逐功能匹配新供应商文档 → 按你的交易量定价 → 给出具体推荐 |
动态工作流的价值，就是 Claude 能临场为你这个任务写出最贴合的编排，而不是套一个万能模板。
)
