Claude Code动态Harness工作流：六种编排模式深度解析
内容提要
Claude Code新增动态工作流功能，通过JavaScript脚本并行调度上百个智能体，解决大型任务中智能体偷懒、自我偏好和目标漂移问题。文章介绍六种编排模式，并展示Bun项目十一天完成重写的案例，同时提醒该功能消耗token较多，适合复杂任务，常规编码无需使用。
延伸解读
动态工作流的适用边界
文章明确指出，动态工作流并非万能，它消耗的token明显更多，官方建议先从范围可控的任务开始。对于常规编码任务，如修改函数、修复bug或添加功能，默认harness已经足够。只有当任务复杂到单个对话窗口无法处理时，才值得使用动态工作流。这提醒读者，在决定是否采用该功能前，应评估任务的复杂度和token成本，避免过度使用。
六种编排模式的组合使用
文章介绍的六种编排模式并非孤立存在，Claude在构建工作流时会组合使用它们。例如，Bun重写案例中，工作流结合了扇出合成（每个文件配两个评审智能体）和循环直到完成（修复循环驱动构建和测试套件）。理解这些模式如何协同工作，有助于读者设计更高效的工作流，而不是机械地套用单一模式。
中断恢复机制的不确定性
文章提出了一个关键问题：动态工作流的中断恢复机制细节尚不明确。官方仅提及“可恢复”，但未说明恢复的是脚本变量、子智能体上下文还是其他状态。对于像Bun重写这样长达十一天的任务，中断恢复的可靠性至关重要。读者在依赖该功能处理长任务时，应意识到这一不确定性，并考虑备份或检查点策略。
Q&A
Claude Code的动态工作流是什么？
Claude Code的动态工作流（Dynamic Workflows）是Anthropic在2026年5月底为Claude Code添加的新功能，它允许Claude当场编写JavaScript调度脚本，在后台并行调度几十到上百个智能体同时处理任务，主对话窗口不被占用，脚本运行后直接给出最终报告。
默认harness在处理大型任务时有哪些缺陷？
默认harness在处理长期运行、大规模并行、高度结构化或对抗性任务时会出现三种问题：智能体偷懒（Agentic laziness），即任务做到一半就宣布完成；自我偏好（Self-preferential bias），即智能体检查自己的输出时容易开绿灯；目标漂移（Goal drift），即上下文压缩导致原始目标逐渐丢失。
动态工作流与子智能体/智能体团队的主要区别是什么？
动态工作流与子智能体/智能体团队的关键区别在于谁持有计划。子智能体或智能体团队由Claude作为编排者，每一步的结果都塞进上下文窗口；而动态工作流将计划从上下文窗口搬进JavaScript脚本，脚本控制循环、分支和中间结果，Claude的上下文窗口只负责最终答案，因此代码执行不消耗主上下文窗口，能支撑更大规模的并行编排。
动态工作流有哪六种核心编排模式？
六种核心编排模式包括：分类路由（先分类再路由到不同智能体）、扇出合成（将任务拆分为多个小步骤并行执行后合成结果）、对抗验证（派一个智能体干活，另一个专门挑错）、生成过滤（生成多个想法后过滤去重）、锦标赛（多个智能体竞争，评审两两对比决出冠军）、循环直到完成（循环执行直到满足停止条件）。
Bun重写案例中动态工作流是如何应用的？
在Bun从Zig重写为Rust的案例中，动态工作流被用于并行处理：一个工作流负责将Zig结构体字段映射到Rust生命周期，另一个工作流将每个.zig文件转换为行为一致的.rs文件，每个文件配两个评审智能体，然后通过修复循环驱动构建和测试套件，最后通宵运行工作流处理不必要的数据拷贝。整个项目75万行Rust代码在11天内完成，测试套件通过率99.8%。
动态工作流适合哪些任务？使用时需要注意什么？
动态工作流适合代码库范围的漏洞扫描、大规模文件迁移、需要多来源交叉验证的研究、困难计划的多角度起草、概率性bug复现、上千条记录的分拣等复杂任务。但需要注意：它会消耗明显更多的token，建议先从范围可控的任务开始；大多数常规编码任务（如改函数、修bug）用默认harness即可；开启ultracode模式会显著增加token消耗，复杂任务完成后记得将effort降回high。
动态工作流的中断恢复机制存在哪些未解问题？
官方提到工作流被中断后可以恢复，但未详细说明技术细节。具体问题包括：脚本变量中的中间结果能否完整保存？子智能体的上下文窗口能否重建？如果子智能体中途被杀，恢复后是重新运行还是继续？这些细节对于长任务（如Bun重写）至关重要，但目前没有公开的技术细节。
