今天早上刷到 Claude Code 的更新，我第一反应不是“又多了个配置项”，而是：终于有人把很多人现在最容易用乱的一件事，单独拿出来摆到台面上了。

Claude Code v2.1.202 新增了一个设置，叫 Dynamic workflow size。表面上看，它只是让你在 /config 里选一个工作流规模，大概分成小、中、大三档；但真正有意思的地方在于，Claude 官方已经很明确地在告诉你一件事：

不是所有任务都适合一上来就开一堆 Agent。

很多人现在用 Agent，已经开始出现一种很典型的误区：任务还没想清楚，先把阵仗拉满；问题还没拆明白，先让它多线程开跑。结果不是更快，而是更贵、更乱、更难收尾。

所以这篇我不准备讲“这个按钮怎么点”，而是讲更关键的事：什么时候该开多 Agent，什么时候反而应该收着用。

这次更新，核心不是“大中小”三个字

先把最容易误解的地方说清楚。

这次的 Dynamic workflow size，本质上不是一个硬限制，更像是一个工作流规模建议。也就是说，它不是在告诉 Claude：“你最多只能开几个 Agent。”它更像是在给系统一个倾向：你平时更希望它保守一点，还是更愿意让它把任务拆得更开一点。

这意味着它解决的不是“能不能多开”，而是“默认该不该多开”。

这个区别很重要。

因为真正难的从来不是并行本身，而是：

• 这个任务到底值不值得拆
• 拆完之后，每个子任务是不是足够独立
• 最后谁来收口，谁来判断“现在已经完成了”

如果这三件事没想清楚，Agent 数量越多，噪音往往越大。

先记一个最简单的判断标准：看任务是不是“能并行且能收口”

我现在判断要不要开多 Agent，基本先看两件事。

第一件事，这个任务能不能并行。

第二件事，并行完以后，能不能比较干净地收口。

只要这两件事里有一件不成立，我一般就不会把工作流开大。

比如下面这几种情况，通常就不适合一上来开大：

• 需求本身还在变
• 你连最终要什么都还没说清楚
• 每一步都高度依赖上一步结果
• 你真正缺的不是执行力，而是判断力

这种时候，多 Agent 不会让你更快，只会让你更早进入“看起来很忙，其实在乱跑”的状态。

我会怎么区分：单任务、小工作流、大工作流

如果要把这件事讲得更落地一点，我大概会这么分。

1. 单任务：问题很清楚，路径也很短

最适合单任务的，通常是那种你自己都能一句话说清楚的活。

比如：

• 改一个函数
• 修一个明确报错
• 把一段文案润一下
• 给现有页面补一个小交互
• 从一份报告里提炼重点

这类任务的共同点是：目标明确，链路短，判断标准也比较直接。

这种时候你最怕的不是“Agent 不够多”，而是“系统开始过度表演”。

明明三分钟能做完的事，硬拆成三个子 Agent，再互相传球、总结、汇报，最后只会让上下文更臃肿。

我的经验是：能一条线跑完的任务，就别强行把它做成组织架构图。

2. 小工作流：任务可以拆，但拆得别太碎

这是我最常用的一档。

所谓小工作流，不是说 Agent 数量一定是多少，而是说：任务已经值得拆了，但拆分维度还比较克制。

最典型的场景是这种：

• 一边查资料，一边整理输出
• 一边改代码，一边做验证
• 一边写文章，一边补配图
• 一边拆需求，一边列实施方案

这类任务的特点是，已经出现了两个到三个相对独立的小环节，但它们之间仍然需要一个统一的主线来收口。

比如我自己写内容时，经常会用这种规模：

• 一个线程看最新动态和用户讨论
• 一个线程整理结构和角度
• 主线程负责最后的判断、改写和收口

如果中间要补图，像 iMini 这种一站式生图生视频能力，我也更愿意把它挂在这种小工作流里：正文主线继续往前走，视觉物料作为一个独立环节补上就行。它是工作流的一部分，但没必要因为“顺手做张图”就把整套流程放大成一个很重的多 Agent 系统。

对大多数人来说，小工作流其实就是甜 spot。既有拆分带来的效率，又不会把管理成本拉得过高。

3. 大工作流：不是“大任务”就一定配得上“大编制”

很多人最容易误判的，就是这里。

不是任务看起来大，就一定适合开大工作流。

真正适合大工作流的任务，通常要同时满足这几个条件：

• 任务周期比较长
• 子任务之间边界清楚
• 每个子任务都能独立推进一段时间
• 最终验收标准相对明确
• 你愿意为“管理复杂度”付出额外成本

比如：

• 大版本重构
• 多模块代码审查
• 长周期调研报告
• 要同时产出多种中间物的复杂项目

这种场景下，大工作流的价值不只是“跑得更快”，而是它能让不同子任务同时推进，不必都挤在一个上下文里争抢注意力。

但它的问题也很明显：只要你前面的任务拆分不够稳，后面返工就会成倍增加。

所以我自己的原则是：

只有当任务天然就长成一个“项目”时，我才会认真考虑大工作流。

如果它只是一个“大号任务”，而不是一个“多角色项目”，我通常还是会往小工作流收。

一个很实用的判断问题：你要的是“执行并行”，还是“思考并行”？

这个问题特别好用。

很多任务看起来像是可以拆，其实拆的是“执行动作”；但真正卡住你的，是前面的判断还没完成。

举个例子。

你说：“帮我做一个新功能，并顺便把交互也优化一下。”

这句话听起来像是可以拆成：

• 一个 Agent 写功能
• 一个 Agent 看交互
• 一个 Agent 做 review

但现实里，最大的风险往往不是执行速度，而是你根本没有回答这些问题：

• 这个功能的优先级到底是什么
• 用户路径改到什么程度算合适
• 这次是局部优化，还是顺带重构

这些问题没定，多 Agent 只会并行地产生更多分歧。

所以我的经验是：

• 执行已经明确，才适合并行
• 判断还没完成，就先别急着并行

很多人不是不会用 Agent，而是太早把“组织能力”用在了还没定型的任务上。

Dynamic workflow size 真正适合谁？

如果你本来就只把 Claude Code 当成一个单回合工具，这次更新你未必会立刻有强感知。

但如果你已经在做下面这些事，这个设置就很值得认真看：

• 经常让 Agent 帮你拆任务
• 已经在用多步骤工作流
• 有代码、文档、调研、配图这种混合任务
• 已经感受到“有时很好用，有时特别乱”

它最大的价值，不是让你追求“更多 Agent”，而是让你开始意识到：

工作流规模，本身就是一个该被设计的变量。

以前很多人默认把它交给模型自己发挥。现在这个选项等于把一个原本隐性的决策，显性地摆到了你面前。

这反而是好事。

因为一旦你开始有意识地区分“小任务、小工作流、大工作流”，你对 Agent 的使用就会稳定很多。

说到底，这次更新最有价值的地方，不是多了个能调大小的选项，而是它逼着你重新想一遍：我手上的任务，到底适不适合拆。

有些活本来就很直，顺着做完就行了，硬拆只会把事情搞复杂。也有些活确实值得并行，但通常拆到两三股线，就已经很顺了。再往上加，不一定是提效，也可能是在给自己增加管理成本。

所以我现在看多 Agent 这件事，心态反而比以前保守一点。不是不用，而是不会再默认“开得越多越高级”。先把边界想清楚，再决定要不要放大工作流，这样最后出来的结果通常更稳，也更省心。