Workflow(工作流)用一段写好的脚本,把一个大任务拆开,同时派出几十个子代理并行开工,再把结果汇总、互相核验。这一页的全部文字,就是它刚刚派 5 个子代理并行起草、29 秒完成的。
Workflow（工作流）说白了，就是一段写死的小程序，它像剧本一样安排一群 AI 助手（叫"子代理 / subagent"，就是被派出去单独干一摊活的小助手）分工合作，去完成一个大到一次对话装不下的任务。它跟普通"找 AI 聊一句"最大的不同是：流程是脚本确定好的，而且能让很多助手同时开工。正因为它可能一口气派出几十个助手、花掉不少算力，所以得你点头明确开启，简单小事用不着它。
就像你只雇了一位助理，所有事都得他一件接一件地办：先读完这份资料，再去查那个，最后写报告。活儿能干完，但全靠他一个人排队推进，又慢又容易顾此失彼。任务一大，他脑子（也就是一次对话能装下的内容）就塞不下了，越往后越力不从心。
这就像你请了一位总指挥，他手里有事先定好的作战计划，把大任务拆成很多小块，同时撒出一队人各管一摊、并行开工，再把结果汇总。该等齐所有人时他会设个"集合点"，需要把关时还会专门派几个人去挑刺、互相验证后才下结论。所以它既铺得开（覆盖全面、规模大），又靠得住（多视角加对抗式核查）。
工作流会把一个大任务拆成许多小块，同时派出多个子代理（subagent，就是一个个听你指挥的 AI 小助手）分头去做。就像你不再一个人埋头读完整本资料，而是雇了一队人各看一章、最后拼成一张完整地图。该覆盖的角落不容易被漏掉。
它不会让单个 AI 拍脑袋给答案，而是让多个独立视角各自判断，再专门派一批"挑刺者"去反驳同一个结论，多数人反对就推翻。这好比一篇论文要先过几位审稿人和反方质询，才算站得住，结论自然更经得起推敲。
有些任务大到一次对话根本塞不下，比如把整个代码库改一遍、做一次全库审计或大范围扫描。工作流能调度几十个代理同时开工（并发上限约十几个、总数最多上千），背后还有保险防止失控。简单小事用一个助手就够，真正的大工程才请它出马。
你不用自己写脚本——这些是 Claude 在编排时用的"指挥手势"。了解它们，你就能看懂 /workflows 进度树里在发生什么。
面对一个谁都说不清全貌的项目，工作流会同时派出一群"阅读者"（subagent，就是替你干活的小助手），每人各读一摊。读完后把各自的笔记汇成一张完整的地图。好比一栋陌生大楼，与其让一个人挨层走，不如每层放一个人，最后大家拼出整栋楼的结构图，又快又全。
工作流先派代理找出所有可疑的问题，但不急着下结论。关键在于"对抗式核验"：每发现一个问题，再派几个"杠精"代理专门去反驳它，多数反驳成立就把它否掉。这样留下来的都是经得起挑刺的真问题，避免虚惊一场。
想搞清一个题目，工作流让每个代理从不同角度去搜，而且彼此看不到对方的发现（叫"多模态扫描"），免得大家都往一个方向钻。搜完各自深读，最后综合成一份带出处的报告。相当于派一队侦探分头取证，再合并成完整结论。
比如要把整个项目里某个老写法换成新写法，单个助手很容易漏。工作流分三步：先扫出所有需要动的地方，再逐个修改，最后逐个验证改对没有。靠脚本写死流程，几十个改动点不会落下，特别适合你换网站、迁框架这类大动作。
需要拿主意时，工作流让多个代理各自独立给出一套方案，再相互打分，最后综合出最好的那个（这套叫"评审团"）。比你只听一个助手的一面之词靠谱，相当于请好几位专家背对背出主意，再择优而取。
同样交给 Claude 一件事，"派一个助手"和"开一个工作流"是两种量级。
| 维度 | 单个代理 | 工作流 |
|---|---|---|
| 本质是什么 | 一个助手，按顺序一摊活一摊活地干完 | 一段写死的脚本，像总指挥调度一群助手协同干 |
| 怎么干活 | 单线程，一步接一步，一次只做一件事 | 能把大任务拆开、几十个助手同时并行覆盖 |
| 靠不靠谱 | 一个视角下结论，对就对、错就错 | 多个独立视角加对抗式核查（专门派人挑刺反驳）后才下结论 |
| 能扛多大活 | 受单次对话容量限制，装不下太大的活 | 能处理塞不进一个对话的大活，如全库审计、大型代码迁移 |
| 启动 / 看进度 | 你问它答，当场出结果 | 后台跑，立刻给个任务号，完成时通知你，/workflows 看进度树 |
成本高，必须明确启用：一次可能派出几十个助手、烧不少算力，所以系统要你主动选它才会启动，不会偷偷动用。
适合有明确产物的大任务：像全库审计、大型迁移、带引用的研究报告这类一眼能说清交付物的活，它才划得来。
简单任务别动用它：一次性的小问题、查一下改一处，单个助手顺手就办了，套工作流反而又慢又贵。