把“计划“搬出上下文窗口:拆解 Claude Opus 4.8 的 Dynamic Workflows

TL;DR

Anthropic 在 2026 年 5 月 28 日随 Claude Opus 4.8 发布了 Dynamic Workflows:让 Claude 自己写一段 JavaScript 编排脚本,由 runtime 在后台调度多达上千个子代理(subagent)并行干活。关键的工程取舍是------把任务计划和中间结果放进脚本变量而非模型上下文窗口,从而让 Claude 的上下文只承载最终答案。本文拆解它的机制、约束与对代理系统设计的启示。

1. 背景:长任务的真正瓶颈是上下文,而不是智力

过去一年里,"让一个 agent 跑更久"几乎成了行业军备竞赛。但真正卡住长程任务(long-horizon task)的,往往不是模型不够聪明,而是上下文窗口被中间过程撑爆

设想用单个 Claude 会话做一次跨数十万行代码的迁移:它要读每个文件、记下改动计划、保存每一步的测试输出、再回看之前的判断。这些中间状态全都堆在上下文里,token 越积越多,模型既要"想"又要"背",最终在注意力稀释和窗口上限之间双重受限。

Dynamic Workflows 的核心洞察,就是把"状态管理"这件事从模型脑子里搬出去。

2. 机制:Claude 写脚本,runtime 跑子代理

按官方与多家报道的描述,一个 dynamic workflow 本质是一段由 Claude 编写的 JavaScript 编排脚本,再由运行时(runtime)在后台执行。流程大致分三段:

第一段是写编排计划。Claude 先把你描述的任务拆成一张"任务地图"------哪些部分需要被检查、重写、测试、复审、甚至被刻意挑战。这张地图不是自然语言的详细描述,而是落进脚本结构里的可执行计划。

第二段是分发(fan-out)子代理 。脚本启动多个独立 subagent 并行处理仓库的不同部分:一个去审认证代码,一个去移植文件,一个去搜不安全的写法,还有一个专门尝试"破坏刚提出的修复方案"。报道给出的硬约束是------同时并发上限 16 个,单次运行总量上限 1000 个子代理。

第三段,也是 Anthropic 强调的"关键创新",是验证收敛。Claude 不是把子代理的答案简单收集起来交差,而是相互比对、反驳弱结论、跑检查,反复迭代直到结果收敛。换句话说,编排器自己充当了裁判与对抗者。

3. 工程取舍:上下文里只留最终答案

这套设计里最值得算法工程师玩味的一句话是:计划存在脚本变量里,而不是 Claude 的上下文窗口里;中间结果同样存在脚本变量里,于是 Claude 的上下文只持有最终答案。

这其实是把传统编程的"状态外置"思想,搬到了 agent 编排上。可以从几个角度理解它的价值:

其一,token 经济学。 中间状态不进上下文,意味着主会话的 token 占用近乎恒定,而不随任务规模线性膨胀。配合 Opus 4.8 更便宜、据称快约 2.5 倍的 fast mode,长任务的单位成本被显著压下来。

其二,注意力质量。 模型上下文越干净,越不容易被无关的历史细节带偏。让 runtime 而非 LLM 来保管"账本",等于把确定性的状态管理交给确定性的系统,把模糊判断留给模型------各司其职。

其三,可验证性。 当编排逻辑落在脚本里,它就是可读、可重放、可审计的。相比"一个巨型 prompt 里隐含的计划",脚本化的工作流更接近工程制品,而非一次性魔法。

代价也很清楚:Claude 必须真的会写正确的编排脚本。计划一旦外置成代码,模型在"生成可靠代码"上的弱点就会直接传导成工作流的脆弱性------这也解释了为何 Opus 4.8 把 agentic coding 分数从 64.3% 提到 69.2% 作为同批卖点,编排能力与编码能力是一体两面。

4. 对代理系统设计的启示

Dynamic Workflows 给自研多代理框架的人提供了几条可借鉴的原则。

把状态外置为一等公民。 与其让 LLM 在上下文里"记住"计划,不如用确定性的数据结构(变量、数据库、文件)保管状态,LLM 只在需要决策时读取必要切片。这能同时改善成本和稳定性。

让验证成为结构的一部分,而非事后补丁。 专门派一个"挑刺"子代理去攻击主方案,并强制结果收敛,比单纯多数投票更能逼出隐藏缺陷。对抗式验证应该被写进编排图,而不是靠 prompt 里一句"请仔细检查"。

给并发设硬上限。 官方的 16 并发 / 1000 总量并非随意------它在吞吐与可控性之间划线。自研系统同样需要明确的扇出预算,否则子代理风暴会吞掉成本与可观测性。

需要提醒的是,目前 Dynamic Workflows 处于研究预览(research preview)阶段,面向 Max、Team、Enterprise 计划,且在 Max 与 Team 上默认开启。能力边界和约束未来可能调整,落地前请以官方文档为准。

参考资料

相关推荐
IT_陈寒1 小时前
Redis内存爆了,原来我漏掉了这个致命配置
前端·人工智能·后端
用户3521802454752 小时前
🎆从 Prompt 到 Skill:让 Spring AI Agent 学会"装新技能"
人工智能·spring boot·ai编程
米小虾3 小时前
手把手教你搭建第一个生产级AI Agent:从选型到实战的完整指南
人工智能·agent
任沫3 小时前
Agent之Function Call
javascript·人工智能·go
米小虾3 小时前
2026年AI Agent全面爆发:从开源生态到企业级应用的进化之路
人工智能·agent
用户6919026813393 小时前
Vibe Coding 开发项目的基本范式
人工智能·设计模式·代码规范
To_OC4 小时前
别再跟 AI 死磕 prompt 了,我写了个 Loop 让它自己改到满意为止
人工智能·aigc·agent
血小溅4 小时前
三大 AI 编码框架深度对比:GSD vs OpenSpec vs Superpowers
人工智能·后端
武子康7 小时前
调查研究-186 LangChain 和 LangGraph 的区别:从快速构建 Agent 到生产级工作流编排
人工智能·langchain·llm
武子康8 小时前
调查研究-185 CodeGraph 调研:给 AI 编程 Agent 一张代码库地图,少一点反复 grep(2026)
人工智能·openai·claude