微信扫码
添加专属顾问
我要投稿
Claude 4.8的动态工作流赋予AI“自主调度权”,能现场创建专用工具解决复杂任务,从代码审查到多角度商业分析,潜力与风险并存。核心内容:1. 动态工作流的核心机制与能力突破2. 七大实际应用场景与脑洞案例3. 使用成本考量与当前最佳实践
上周,Claude Code 上线了一个新功能,叫 动态工作流(dynamic workflows)。简单说就是——Claude 现在能现场给自己"写"一套"工具",专门为手头这件活儿量身打造。
你可能知道,Claude Code 默认的工具流是为写代码设计的。但我们后来发现,很多看似跟代码无关的事,本质上跟写代码也差不多。所以这套默认工具其实能解决很多种问题。不过也确实有那么几类任务,光靠默认这套还不够得劲——比如 深度研究、安全审计、多 Agent 协作,还有 代码审查 这些。我们之前都得在 Claude Code 之上另搭一套专门的"工具"才能把它们跑好。
现在有了工作流,你就可以让 Claude 在 Claude Code 里现场搭出这种专用工具,直接把这一类问题给解决掉。而且搭完之后,你还能把它分享出去、或者留着自己下次复用。
这篇文章里,我想跟你分享一下我这段时间用工作流的真实感受和踩过的坑,让你也能尽快把它用起来。
不过我得先把丑话说前头:最佳实践还在不断演化中。动态工作流往往会更费 token,所以什么时候用、怎么用,都得掂量掂量。
在讲技术细节之前,先放几个真实能用的提示词给你感受一下。看完你就知道,工作流能干的事儿远不止写代码:
是不是有点感觉了?这些场景里,传统的"一次性提示词"基本都搞不定。
动态工作流本质上就是一个 JavaScript 文件,里面会用到几个特殊的函数来启动和协调 子 agent。
除了这些专用函数,文件里也能正常用 JavaScript 自带的那些——JSON、Math、Array 都行,方便你做数据处理。
特别值得一提的是:工作流里可以指定每个 agent 跑什么模型,也可以让子 agent 单独开 worktree 跑。这意味着 Claude 可以根据任务的复杂程度,自主决定"用多聪明的脑子"和"要不要跟主任务隔离"。
还有一点很贴心:如果工作流跑到一半被中断了——比如你不小心关了终端,或者按了 Ctrl+C——下次接着开会话,它能从断掉的地方继续跑,不会前功尽弃。
默认的 Claude Code 工具流,在处理任务时需要把"规划"和"执行"塞在同一个上下文窗口里。
对于很多写代码的场景,这套打法其实很有效。但一旦碰到那种特别长、特别并行、或者特别需要严格流程的任务,就容易出问题。
因为 Claude 在同一个上下文窗口里持续干一件复杂的事干得越久,越容易踩到下面这三种坑:
1. Agent 偷懒(Agentic laziness)
就是 Claude 干到一半觉得累了,明明还有一半活儿没干完,就直接宣布"搞定收工"。比如一个安全审查里有 50 项需要查的,它只查了 20 项就交差。
2. 自利偏差(Self-preferential bias)
Claude 容易偏爱自己产出的结果。尤其是让它按评分标准给自己打分或者做校验的时候,它会下意识地"放自己一马"。
3. 目标漂移(Goal drift)
干着干着就忘了最初的目标。尤其是在上下文被压缩过几轮之后——每压缩一次都会丢点细节,像"这个边界情况要怎么处理"、"千万别做 X"这种约束条件,很容易就被磨没了。
工作流的存在,就是为了对付这三种毛病。它的核心思路是:用多个 Claude,每个管自己独立的一小块上下文,各自盯着一个明确的小目标,然后由一个"调度员"把它们串起来。
你之前可能用过 Claude Agent SDK 或者 claude -p 这种方式来"静态地"编排多个 Claude Code 实例。这种方式能干活,但有个天然的缺陷:
静态工作流要照顾所有可能的边界情况,所以通常写得很通用、很笨重。
而现在有了 Claude Opus 4.8 这种级别的模型,再加上动态工作流,Claude 已经聪明到能根据你的具体场景,"现编"一套完全贴身的工具了。
想用工作流其实很简单——直接让 Claude 给你做一个就行。或者在提示词里加个"ultracode"关键词,这样能更稳地触发它真的去搭工作流。
不过我建议你先在脑子里建个模型,搞清楚工作流是怎么搭起来的,这样你才知道什么时候该用,也知道怎么在提示词里引导 Claude 往你想要的方向走。
下面这几种"套路"是 Claude 在搭工作流时经常会用到、也经常会组合起来用的:
① 分类-执行(Classify-and-act)
先用一个分类 agent 决定这是个什么类型的任务,然后根据类型分派给不同的 agent 去处理。也可以反过来用——最后用一个分类 agent 决定输出长什么样。
② 发散-收敛(Fan-out-and-synthesize)
把一个大任务拆成很多小任务,每个小任务交给一个 agent 单独跑,最后再用一个 agent 把所有结果汇总成一份。这种套路特别适合那种"步骤特别多、或者每一步都最好在干净的上下文里跑"的任务。汇总这一步是个"屏障"——它会等所有发散出去的 agent 都跑完,然后把它们的结构化输出合并成一份。
③ 对抗式校验(Adversarial verification)
每个 agent 跑完之后,再单独派一个 agent 出来,用评分标准或者规则"挑刺儿"地校验一遍它的产出。
④ 生成-筛选(Generate-and-filter)
先围绕一个主题生成一堆想法,然后用评分标准或者验证流程筛一遍,去掉重复的,最后只留那些质量最高、经过验证的。
⑤ 锦标赛(Tournament)
不是分工,而是让一群 agent 互相 PK。同样一个任务,派 N 个 agent 用不同思路去解,然后让裁判 agent 两两对比,直到决出一个赢家。
⑥ 循环到干完(Loop until done)
对于那种"不知道要干多少活"的任务,就一直派 agent 出去跑,直到满足某个停止条件为止(比如没有新发现了、或者日志里没有新错误了)。不要硬卡一个固定的轮数。
动动脑筋想想,有哪些地方可以让 Claude Code 给你搭个工作流。我自己的体会是:工作流在很多非技术活儿上反而比写代码更香。
Bun 从 Zig 改写成 Rust,就是用工作流干的。具体怎么干的可以看看 Jarred 在 X 上的这条 thread。
核心打法是:把任务拆成一连串"可以单独操作的小目标"——比如调用点、跑挂的测试、模块等等。给每个修复点单独开一个 worktree,派一个子 agent 进去改;改完了再派另一个 agent 进去对抗式审查;审查通过再合回去。
一个实用的小提醒:记得告诉 agent 千万别用那些特别吃资源的命令(比如说全量构建),这样你就能最大化并行,跑很多个也不会把机器压垮。
我们在 Claude Code 里内置了一个 /deep-research 技能,它本身就是用动态工作流搭的。具体来说:发散出去跑一堆网页搜索 → 把原始资料抓回来 → 对抗式地校验每一条论断 → 最后合成一份带引用的报告。
但这种"深度研究"的思路,其实不只限于网页搜索。比如你可以让 Claude 把 Slack 里的上下文攒成一份状态报告,或者让它把一个代码库深挖一遍,搞清楚某个功能到底是怎么跑的。
反过来,如果你手上有一份报告,想把里面每一条事实性论断都核对一遍、每个引用都追溯到源头——这种场景特别适合搭个工作流:让一个 agent 先把报告里所有事实性论断都列出来,然后给每条论断单独派一个子 agent 去深挖核对。还可以再上一层,让一个验证 agent 去检查核对 agent 找的源头靠不靠谱。
你可能手上有一堆条目,想按某种偏主观的标准排个序——比如"按 bug 的严重程度给支持工单排个序"。
这种活儿 Claude Code 其实挺擅长。但如果你想让它一次性给 1000 多行排个序,那质量会肉眼可见地下降,而且也塞不进上下文。
正确做法是:跑个锦标赛、或者用一组"两两对比"的 agent 串成一条流水线。两两对比比直接打绝对分要靠谱得多。每个对比都是独立的 agent,外面那个调度循环负责维护对阵表,主体上下文里只保留当前的赛程进度。
如果你发现 Claude 老是不按你写在 CLAUDE.md 里的某些规矩来,那就可以搭个工作流:把你关心的所有规则列成清单,每条规则单独派一个验证 agent 去盯。你还可以再派一个"怀疑论者" persona 的子 agent,去审视这些规则本身写得对不对——这一步能有效避免"假阳性"满天飞。
反过来也行:把你最近的会话和代码评审意见里反复出现的纠错挖出来,让并行的 agent 归类,然后对抗式地验证每条候选("这条规则真的能避免一个真实犯过的错吗?"),最后把活下来的那些写回 CLAUDE.md。
Debug 这件事,最好的做法是先想出几个互相独立的假设,再挨个验证。但如果你只用一个上下文窗口,Claude 很容易被自利偏差带偏——它会下意识地偏向自己提出的假设。
工作流能从根本上避免这个问题:派几个 agent 从互不重叠的证据出发,各自提出假设。比如一个看日志,一个看文件,一个看数据。每个假设提出来之后,再由一组"拥护者"和"反驳者" agent 去 PK。
这种思路不只适用于代码。比如做销售分析("三月销量怎么跌了?")、数据工程("这条流水线为啥挂了?")、或者任何事后复盘的场景,都可以用同样的套路。
每个团队都有一堆支持工单、bug 报告、或者其它 backlog,全靠人根本处理不过来。
一个分流工作流能这样干:给每条工单打分类 → 跟已经在跟踪的去重 → 然后采取行动。行动可以是尝试修一下,也可以是升级到人工。
一个特别有用的模式叫"隔离(quarantine)":让那些读"不可信公开内容"(比如别人发来的工单、第三方数据)的 agent,不允许执行高权限操作。高权限操作只能由负责"行动"那一层的 agent 来做。
把分流工作流跟 /loop 组合起来用,Claude 就能不间断地帮你处理这些事儿。
当你要探索多种解法的时候,工作流特别管用——尤其是那种"偏品味"的活儿,比如设计、命名,这种最好有个明确的评分标准(rubric)。
让 Claude 探索一拨方案,再让一个评审 agent 拿着评分标准去挑。任务完成的标志是评审 agent 觉得已经达标了。方案之间也可以跑个锦标赛,按评分标准决出胜负。
对于某些特定任务,你可以用工作流跑一些轻量级的评估:在 worktree 里派子 agent 跑各种实现,然后派对比 agent 按评分标准去 PK、打分。比如评估一个你刚写的技能,然后按标准去打磨它。
你可以搭一个分类 agent,让它来判断"这件活儿该用哪个模型"。这招在"任务会涉及大量工具调用"的场景下特别有用——因为执行前先做点研究,就能判断出最合适的模型。
比如"给我讲讲 auth 模块是怎么跑的"这个任务,最适合的模型取决于 auth 模块有多少文件、代码库的结构长什么样。一个分类 agent 完全可以做完这层调研,然后根据任务的预期复杂度,分派给 Sonnet 或者 Opus。
工作流是个新东西。虽然很多场景下它能带来意想不到的效果,但它不是万能药,而且通常会明显消耗更多 token。
我的建议是:把工作流当作一种"创意工具",用来把 Claude Code 推到以前没想过的边界。 而对于日常的写代码任务,先问自己一句:"这事儿真需要这么多算力吗?"
比如传统的写代码任务,绝大多数根本不需要搞个 5 人评审小组。
提示词要写得细
对工作流来说,提示词写得越具体、越细致,结果越好。前面介绍的那些套路,能用上的都用上。
工作流不一定是"大活儿专用"。你也可以让模型用个"轻量工作流"——比如搞一次快速对抗式审查,专门挑某个假设的刺儿。
和 /goal、/loop 组合用
对于那些可以反复跑的工作流(比如分流、研究、校验),把它们和 /loop 配起来,就能定时跑;再和 /goal 配起来,就能卡死完成标准。
Token 用量预算
你可以给动态工作流显式设个 token 上限,控制一下别烧太狠。比如在提示词里直接写:"用 10k token 解决这事",模型就会把上限设在那里。
保存和分享工作流
在工作流菜单里按 s 键就能保存。你可以把这些工作流存进 ~/.claude/workflows,或者打包成技能分享出去。
要通过技能分享的话,把 JavaScript 工作流文件放到技能文件夹里,然后在 SKILL.MD 里引用一下。为了让分享出去的工作流更灵活,建议你在提示词里引导 Claude:把这些工作流当作模板来理解,而不是要一字不差照搬的脚本。
工作流给 Claude Code 打开了一扇新门。我更愿意把它当作一个起点——到底怎么用最好,我们还远没摸到边。
欢迎你上手试试,也欢迎告诉我你发现了什么。
Thariq Shihipar 和 Sid Bidasaria(@sidbid)是 Anthropic 的技术团队成员,目前负责 Claude Code。
相关文档:
如果你觉得这篇内容对你有启发,欢迎在留言区聊聊你的看法。
关注我,我会持续分享高质量的技术与思考干货。👇
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-06-03
Codex三大重磅更新上线:合并ChatGPT倒计时
2026-06-02
让 Coding Agent 从黑盒到透明:阿里云 Agent 观测审计数据采集实践
2026-06-02
哪些活,该交给Claude Code的 /workflows?
2026-06-02
Step 3.7 Flash:为 Agent 而生的高频引擎
2026-06-01
面向 LLM 的架构设计:什么是真正的 AI Friendly 架构?
2026-06-01
写代码快 10 倍,不等于研发快 10 倍!Google 揭秘 AI 系统级瓶颈
2026-06-01
Anthropic 发布《创始人指南》!教你如何创建一家独角兽企业
2026-06-01
现场即壁垒:OpenAI收购Tomoro背后的FDE战争
2026-04-15
2026-04-07
2026-03-31
2026-03-13
2026-04-07
2026-03-17
2026-03-17
2026-03-21
2026-04-24
2026-04-17
2026-06-03
2026-06-02
2026-06-01
2026-05-26
2026-05-23
2026-05-21
2026-05-19
2026-05-09