Dynamic Workflows 深度解析：4.8 如何重新定义多 Agent 编排
本文是「Claude 企业级工程实战手册」专栏第 02 篇。深度对比 Claude 4.6 和 4.8 在多 Agent 编排上的架构差异，讲清楚 Dynamic Workflows 的本质与适用边界。
背景：为什么多 Agent 是企业 AI 的核心命题
单个 Claude 实例有两个根本限制：
- 上下文窗口有限：即使 Opus 有 1M token，超大任务仍然放不下
- 串行执行慢：复杂任务需要多个步骤，无法并行
多 Agent 架构解决这两个问题——把大任务拆分给多个 Agent 并行处理。但问题在于：如何编排这些 Agent？4.6 和 4.8 的答案截然不同。
一、Claude 4.6 的多 Agent：星型结构
架构图
┌─────────────────┐
│ 主 Orchestrator │
└────────┬────────┘
│ 分配任务 / 收集结果
┌────────┼────────┐
▼ ▼ ▼
Agent A Agent B Agent C
（设计） （编码） （测试）
│ │ │
└────────┴────────┘
全部汇报回
主 Orchestrator
核心特征：子 Agent 之间永远不直接通信，所有信息必须经过主 Orchestrator 中转。
4.6 的优势
- 长上下文保持能力强：即使相关指令在 200k+ token 之前，输出仍能对齐原始指令
- 异步工具理解好：能系统性执行和追踪并行工作，清晰感知工具间依赖关系
- 实现简单：用标准
Task工具就能创建子 Agent，门槛低
4.6 的已知问题
过度生成子 Agent：Anthropic 官方文档明确标注，Opus 4.6 有强烈偏向生成子 Agent 的倾向，即使直接方法更快更便宜，它也可能去委托给子 Agent。
真实事故：
- 一个开发者运行 TypeScript 检查命令，Opus 4.6 自动编排了 49 个专属子 Agent 并行运行 2.5 小时，估计费用 8000–15000 美元
- 一个金融服务团队三天累计 47000 美元的 token 费用，因为 23 个子 Agent 在无人监督下持续分析代码
二、Claude 4.8 的多 Agent：Dynamic Workflows
最核心的架构革新：计划从上下文移入代码
4.6 的计划存在于 Context Window 里：
[Context Window]
├── 原始目标
├── 计划（文字形式）
├── Agent A 的结果
├── Agent B 的结果
└── ... 越来越大，直到溢出
上下文越来越胖 → 模型为了"处理"任务，条件反射地派发子 Agent → 过度生成。
4.8 Dynamic Workflows 的解法：
[Context Window] [后台 JavaScript 脚本]
├── 原始目标 → let plan = {
└── 最终答案 subtasks: [...],
agents: [...],
verifyPasses: 2
}
// 编排逻辑在这里，不占 Context
编排逻辑（循环、分支、Agent 数量决策、验证轮次）全部存在于脚本变量里。模型的上下文窗口只接收最终的、已验证的答案。这个分离使得涉及数百个并行子 Agent 的运行成为可能。
Dynamic Workflows 的四层内置防护
防护层 1：硬性并发与总量上限
并发上限：16 个 Agent 同时运行
总量上限：1000 个 Agent/次
脚本权限：无文件系统 / Shell 直接访问
对比 4.6：需要你在代码里手写 MAX_SUBAGENTS = 5，4.8 系统原生强制执行。
防护层 2：对抗性验证（最关键）
普通 Agent 系统：
派发 → 执行 → 汇总 → 输出
Dynamic Workflows：
派发 → 执行 → [对抗层：独立 Agent 尝试推翻结论]
↓ 不收敛？继续迭代
↓ 收敛？
汇总 → 输出给用户
输出自带质量保证，不需要手动设计 Critic Agent。
防护层 3：中途重写计划
4.6：
计划 → 执行步骤1 → 执行步骤2（即使假设已经错了）→ 错误传播
4.8：
计划 → 执行步骤1 → 发现步骤2的假设不成立
→ [重写剩余计划]
→ 执行修正后的步骤2
防护层 4：Ultracode 模式自决策
开启 Ultracode 后，Claude 对每个请求做预评估：
- 简单任务 → 直接内联执行，不启动 Workflow
- 复杂任务 → 启动 Workflow，自动决定 Agent 数量
开发者不再需要判断"这个任务要不要用多 Agent"。
三、4.6 vs 4.8 对比全景
| 维度 | 4.6 星型结构 | 4.8 Dynamic Workflows |
|---|---|---|
| 并行规模 | 数个到数十个 | 数百个 |
| 并发上限 | 你写代码硬截断 | 系统强制 16 并发 |
| 总量上限 | 你设 MAX_SUBAGENTS | 1000/次 硬上限 |
| 质量验证 | 手动设计 Critic | 对抗性验证内置 |
| 计划纠错 | 错误会传播 | 中途重写计划 |
| 是否触发 | 模型可能过度生成 | Ultracode 预评估后决定 |
| 上下文膨胀 | 结果积累在 Context | 计划在脚本，Context 只收最终答案 |
| 文件系统安全 | 子 Agent 有完整权限 | 脚本层无直接 FS/Shell 权限 |
四、Dynamic Workflows 的使用方式
使用条件
- 仅限 Claude Code 的 Enterprise、Team、Max 套餐用户
- 配合 Opus 4.8 效果最佳
触发方式
方式一：手动触发（在 Prompt 里写 "workflow"）
# 在 Claude Code 里直接描述大任务
将整个 src/ 目录从 Python 3.9 迁移到 Python 3.11，
保持所有测试通过，workflow
方式二：Ultracode 模式（让 Claude 自决策）
# 在 Claude Code 设置中开启 Ultracode
# Claude 会自动判断是否需要启动 Workflow
方式三：API 调用（企业集成）
import anthropic
client = anthropic.Anthropic()
# Dynamic Workflows 通过标准 API 触发
# Opus 4.8 会自动判断是否启动 Workflow
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=64000,
thinking={"type": "adaptive"},
messages=[{
"role": "user",
"content": """
审计整个代码库的安全漏洞，生成完整的漏洞报告。
代码库路径：src/
要求：覆盖 OWASP Top 10，输出 Markdown 格式报告。
"""
}]
)
适合场景
✅ 大规模代码库迁移（数十万行）
✅ 完整测试套件生成
✅ 整库安全审计
✅ 大规模文档生成
❌ 简单的单文件编辑
❌ 单次查询回答
❌ 需要紧密共享上下文的任务
五、仍然需要控制的成本风险
Dynamic Workflows 的内置防护解决了过度生成问题，但成本风险依然存在：
500 个 Agent vs 50 个 Agent = 10 倍成本差距
你仍然需要做的事：
# 1. 子 Agent 用 Sonnet 而不是 Opus
# Orchestrator → Opus 4.8（智能决策）
# Sub-agents → Sonnet 4.6（执行，省 60% 成本）
# 2. 大任务先跑 10% 样本
# 在大型代码库上，先在有代表性的 10% 上运行 Workflow
# 确认结果后再提交完整任务
# 3. 设置预算上限（Claude Code CLI）
npx @anthropic-ai/claude-code --max-budget 50.0 # 单次最多 $50
六、一句话总结
4.6 = 一个主管 + 几个专员，主管做中间人传话，防护靠你手动设计
4.8 = 一个主管 + 数百个并行工人，完工自动质检再交货，防护系统原生内置
选 4.6 的时候：任务规模中等，你需要精确控制每个子 Agent 的行为，且有能力设计防护层。
选 4.8 + Dynamic Workflows 的时候：任务超大规模，你需要系统帮你保证质量，且在 Enterprise/Team/Max 计划内。
上一篇：01. Claude 模型家族全景：4.5 / 4.6 / 4.8 如何选型？
下一篇：03. 企业级 System Prompt 四层架构
专栏首页：Claude 企业级工程实战手册
专栏导航 · Claude 企业级工程实战手册
➡️ 下一篇：03. 企业级 System Prompt 四层架构：角色 / 上下文 / 约束 / 输出标准
本专栏共 14 篇，系统覆盖 Claude 模型选型 / Prompt 工程 / Claude Code 工作流 / API 高级用法 / MCP / RAG / AI 安全合规全链路。欢迎收藏：Claude 企业级工程实战手册
