meiki 上一篇写 Opus 4.8 体验的时候，我对
dynamic workflows 的结论比较保守：拿它改博客 tools/
目录下几个小工具，确实能并行，但对我这种小项目用处不大。事后想想，问题可能出在我喂的任务上——我拿一个改样式的零碎活去试一个为大规模任务设计的功能，本来就不对路。
所以这几天我换了个场景重新试：不是改存量代码，而是从零搭一个新的 MVP。下面记录一下这次的过程。先说清楚：凡是「我看到的」都来自这一次的运行，不是基准测试；「官方说的」我会标出来，分开看。
一、这次让它做的事
我一直想做个小工具：一个管 Google 收录的运营面板。需求大致是 Google OAuth 登录、同步 Google Search Console 数据、读 sitemap、做一个 URL 收录状态的检查队列、一个四张卡片的看板，再加一封每周邮件。技术栈定死：Next.js 16 / Drizzle / SQLite。
我没有自己一步步带它做，而是在 prompt 里写清目标、带上 workflow
这个词，让它自己写一个工作流脚本来编排。它给的计划是 5 个阶段：
Foundation → Core Libraries → Sync Engine → UI & Routes → Verify & Repair
这个拆分我看了认可：先打地基，再并行造各个独立模块，然后是同步引擎、UI 和路由，最后留一个阶段验证和修复。值得留意的是最后那个 Verify & Repair——搭完之后还有一道自检，而不是直接交差。这也是工作流和我手动一句句指挥子代理的区别：质检被写进了流程里。
二、运行过程
Foundation：单个代理打地基
第一阶段只有一个代理，把项目骨架、依赖、数据库 schema 这些地基铺好。这一步是串行的，没法并行，因为后面所有模块都依赖它。
这一个 foundation 代理用了 61.5k token、44 次工具调用、近 8 分钟。不算少，但它做的是最不能出错的部分，慢一点可以接受。
Core Libraries：5 个代理并行
地基好了，第二阶段铺开 5
个并行代理：auth、gsc、sitemap、email、demo，一人负责一个模块。
这一屏是这次并行价值最直观的地方。这几个模块基本不耦合——OAuth 怎么写不影响
sitemap 怎么解析，邮件模板和 GSC
同步也没关系。模块越独立，并行的收益越实在。每个代理的开销也不一样：auth 用了
71.1k token、28 次工具调用，sitemap 只用了 42.1k、12 次工具，2 分 20
秒就完成了。它们确实在同时跑，不是排队。
这也回答了我上次的疑问：上次那个统一小工具样式的活，各处改动是互相黏在一起的，强行并行只会增加我 review 的负担；而这次是一堆天然独立的模块，并行才合适。
期间主会话照常可用
工作流在后台跑，主会话一直可用。下方的任务面板会持续显示进度，瞄一眼就知道到哪一步了。
这张是跑到一半截的：6/7 agents done · 16m 7s · ↓ 425.3k tokens。token
数后面单独说。期间我的主上下文只占了
13%，因为工作流的中间结果都留在它自己的脚本变量里，不会一股脑灌进对话上下文，最后只把结论交给我。这点设计我比较喜欢。
Verify & Repair：第一遍通过
最后是验证阶段，也是我比较在意的一步。结果是第一遍 verify 就
green: true，没有需要修复的东西。
整个运行收尾的数字是 12 个代理、约 31 分钟。并行拼出来的这个 app 集成得比较干净，verify 阶段没揪出需要返工的地方。
不过代理说自己过了，我一般不会直接信。所以工作流结束后我又独立验了一遍：git status
看改了哪些文件，再 pnpm exec tsc --noEmit 跑一遍全量类型检查，结果是
EXIT: 0。这样我才确认它说的「绿」是真的。
三、它适合什么场景
把这次和上次放一起，判断比较清楚了：
- 从零搭、且能拆成独立模块的任务，是它合适的场景。新项目没有存量代码的牵绊，模块之间界面清晰，并行才跑得出速度。这次 5 个 Core Libraries 代理并行就是例子。
- 改存量代码、各处改动互相纠缠的任务，不建议硬上。这是我上次踩的坑。并行的前提是任务能切成互不冲突的块，切不开就别为了并行而并行。
- 流程里自带质检，比单纯多几个代理更有价值。dynamic workflows真正有用的地方不是「人多」，而是能把「verify 一遍、有问题自己修」这种套路固化进脚本里。即使没有一遍通过，这道自检本身也比我手动盯着省事。
四、保留的几点判断
几点需要说明的：
「绿」只代表能编译、能通过类型检查，不代表产品就好。tsc --noEmit
通过，只说明没有类型错误和明显的集成断裂，不保证业务逻辑对、边界情况全，也不保证代码质量我满意。这是个
MVP 骨架，离能上线还有我自己 review 和打磨的距离。
token 消耗不低。前面那张图里，16 分钟用了 42 万 token，整个运行下来更多。同样这个 MVP，用单线程的 Claude Code 一点点带，慢一些，但花费会低很多。并行省的是时间，代价是 token，值不值要看这半小时对你值多少钱。
它还是 research preview。这次顺利不代表每次都顺。目前在 Pro
及以上的付费档可用（Pro 需要去 /config 里手动打开），需要较新版本的 Claude
Code。功能还在演进，不建议当成稳定能力依赖。
这只是一个样本。一次成功证明不了「它总能行」，只能说明「这类任务它能行」。我给不了成功率，只能给个方向。
小结
上一篇我对dynamic workflows的结论是「知道有就行，不必为它改工作流」。这篇要修正一半：当任务是「从零搭、可拆分、需要自检」这种形状时，它确实能把我半天的活压进半小时，而且第一遍就通过了类型检查。上次觉得它用处不大，主要是我喂错了任务。
但从「能编译」到「能上线」那段路还是得我自己走——代理把脚手架搭得再快，最后为代码兜底的还是我。对一个所有代码都要自己负责的人来说，这点清醒比那个「31 分钟」更重要。
想看官方对这个功能的完整说明、以及脚本写法和管理方式，可以读 Claude Code 文档里的dynamic workflows章节。等我用它趟过更多真实场景，再回来更新这篇。