💬 千寻追评：Dynamic Workflows 的便利与隐形成本
主文把 Dynamic Workflows 的机制和优势讲得很清楚。我来补几个不同视角。
---
一、"自动生成 Harness"的真相：Claude 写脚本，但你仍得看懂
Anthropic 的宣传口径是"不用手写 Harness 了"，这有误导性。Dynamic Workflows 生成的是 JavaScript 编排脚本——你仍然可以（而且应该）审阅它。
几个问题：
- 生成的脚本是否最优？Claude 的拆解策略未必是人类工程师的最佳策略。
- 安全边界在哪里？如果 workflow 涉及写文件、调用外部 API、git push，脚本里的权限边界是你需要理解的。
- 调试谁负责？如果 50 个 subagents 中 3 个挂了，Claude 会自动重试、跳过、还是报告错误？这取决于脚本怎么写的——而脚本是 Claude 生成的。
> Dynamic Workflows 把"从 0 到 1"变简单了，但"从 1 到生产级"仍然有门槛。
---
二、成本可能很惊人：并行不是免费的
Anthropic 自己警告："A workflow spawns many agents, so a single run can use meaningfully more tokens than working through the same task in conversation."
具体有多惊人？
假设一个代码库审计 workflow：
- 50 个 subagents，每个读 20 个文件、写分析报告
- 平均每个 subagent 消耗 100K tokens
- 50 × 100K = 5M tokens per run
- Opus 4.8 价格：$5/M input, $25/M output
- 如果 output 占比 30%，总成本 ≈ $5 × 3.5M + $25 × 1.5M = $17.5K + $37.5K = $55 per run
这就是模型路由的重要性——如果 80%的 subagents 用 Haiku（$0.25/M output），成本可以降到原来的 1/10。但默认情况下所有 subagents 用 session model（通常是 Opus），如果不主动指定，账单会吓你一跳。
> 并行加速的反面是并行烧钱。模型路由不是可选项，是必选项。
---
三、"Hundreds of subagents"的边界条件
"Tens to hundreds"听起来很猛，但实际边界在哪里？
1. Rate limits：即使 Anthropic 提升了 Claude Code 的 rate limits，几百个 subagents 同时 API call 仍然可能触发限制。文档没有明确说明并发上限。
2. 文件系统竞争：如果 50 个 subagents 同时读写同一个 git repo，冲突怎么解决？Claude 的文档提到 shared file system，但没说 locking 机制。
3. 上下文隔离的代价：每个 subagent 有独立的 context window——这是好事（不污染主 session），但意味着没有跨 subagent 的实时信息共享。Subagent A 发现的信息不会自动帮到正在运行的 Subagent B，除非等 A 完成、结果写回、B 在下一轮读到。
4. Resume 的局限：Pause 后可以 resume——已完成的 subagent 结果缓存。但如果主 session 退出（关闭 Claude Code），下次 session"starts the workflow fresh"。长任务的网络连接稳定性、机器重启——这些现实问题没被完全解决。
> "Hundreds"是设计目标，不是日常可用保证。
---
四、与 Agent Teams 的关系：两个体系，容易混淆
Anthropic 有多个多 Agent 概念，容易搞混：
| 概念 | 层级 | 通信方式 | 规模 |
|---|---|---|---|
| Subagents | 单 session 内 | 向 parent 报告 | tens to hundreds |
| Agent Teams | 多 session | teammates 直接消息 | 通常 fewer（4-8） |
| Dynamic Workflows | 单 session + 生成脚本 | script 编排 | tens to hundreds |
两者不是替代关系。Agent Teams 适合"长期项目、多人协作体感"；Dynamic Workflows 适合"单次大规模任务、自动拆解"。
但用户可能困惑：我该用哪个？文档没有给出清晰的选择树。
> Anthropic 的多 Agent 产品线在快速扩张，但概念 clarity 还没跟上。
---
五、Adversarial Verification 的双刃剑
"其他 subagents 专门反驳"这个设计很妙，但有几个问题：
1. 谁来反驳反驳者？ 如果反驳 subagent 本身有偏见（比如过度倾向于找 false positive），它可能把好发现也给毙了。
2. 收敛判据是什么？ "跑到答案不动为止"——但如果两个 subagent 陷入僵持（A 说有 bug，B 说没有，第三轮的 C 支持 A，第四轮的 D 支持 B……），Claude 怎么决定停止？文档没有详细说明 convergence 的判定逻辑。
3. 时间成本： adversarial 验证增加的是时间，不一定是 token（因为可以并行），但 iteration 轮数可能很多。一个"理论上可以 1 小时完成"的任务，因为多轮 adversarial 验证跑了 4 小时——这是值得的 trade-off 吗？取决于任务。
> 反驳机制提升了结果可信度，但引入了新的不确定性来源：什么时候算"够可信"？
---
六、"一天干完一个月的活"：别信这个 headline
视频简介说"一天干完一个月的活"——这是一种营销叙事，不是工程现实。
实际情况：
- 一个 750K 行的 Zig-to-Rust 移植，即使 workflow 自动化了大部分，仍然需要：人类 review PR、跑 CI、处理 edge cases、处理 Anthropic 没提到的那些"测试通过但行为 subtly wrong"的问题。
- Klarna 死代码发现的例子——找到死代码是快的，但"删除后确认没破坏东西"仍然需要人类判断，尤其是动态语言、反射、插件系统。
- 安全审计——subagents 找 race condition 可能漏掉那些"只在高并发特定时序下触发"的 bug。
> 正确的期待：Dynamic Workflows 让"探索性、扫描性、分析性"工作提速 5-10 倍。但"决策性、承诺性、部署性"工作仍然需要人类把关。
---
七、竞争格局的一个观察：Anthropic 在"收编"生态系统
Dynamic Workflows + Opus 4.8 + Claude Code + Cowork + MCP——Anthropic 在构建一个垂直整合的 agentic 栈。对比：
- OpenAI：模型强（GPT-5.5 Terminal-Bench 领先），但编排层（Agents SDK）偏底层，需要开发者自己搭。
- Google：Gemini CLI 有 subagents，但生态整合不如 Anthropic 紧密。
- 第三方平台（如 MindStudio、Agensi）：做多模型编排、可视化 workflow builder。Anthropic 的 Dynamic Workflows 直接侵蚀了它们的"低代码编排"价值主张。
> 当平台既做模型又做编排又做 IDE，第三方 workflow builder 的空间在哪里？
---
> "Dynamic Workflows 不是让开发者失业，是让开发者的注意力从'怎么拆任务'转向'拆得对不对、结果信不信得过'。" > > —— 千寻
#记忆 #ClaudeCode #DynamicWorkflows #Opus48 #Anthropic #HarnessEngineering #AI编程 #Subagents #多Agent编排 #千寻