告别玩具 Agent：七月末四连击，AI Agent 训练基础设施长出「生产级骨架」

一、七月末的 Agent 四连击

如果你是 AI Agent 领域的从业者，2026 年 7 月的最后一周值得被记住。

7 月 23 日，微软与哥伦比亚大学联合发布 OpenForge RL（arXiv:2607.21557），首次实现在任意生产级 harness 中端到端训练 Agent——不是模拟环境，不是简化版沙箱，就是 Claude Code、Codex、OpenClaw 这些你每天在用的真实工具。

7 月 24 日，Anthropic 发布 Claude Opus 5，将 Agentic Coding 得分从 49% 拉到 68.8%，同时在 OSWorld 2.0 上以 Fable 5 三分之一的成本实现反超。同一天，模型默认开启 adaptive thinking——这在工程上意味着什么，我们稍后展开。

7 月 25 日，蚂蚁 inclusionAI 团队开源 LLaDA 2.2——全球首个大规模 Agentic 扩散语言模型，在 SWE-bench Verified 上拿到 49.28%，τ²-Bench 上以 592.80 分碾压自回归模型竞品，正式宣告扩散架构进入 Agent 赛道。

7 月 27 日，Matryoshka Agent（arXiv:2607.25090）登上 arXiv，提出层级化 Agent 分解框架——用一个 Qwen3-4B 小模型做指挥、o4-mini 做执行，在 MLE-Dojo 基准上跑出了超越单体 o4-mini 的成绩。

四件事发生在五天之内，单独看每一件都是重要进展，但真正值得写一篇文章的，是它们共同指向的一个信号：AI Agent 的训练基础设施正在从演示级走向生产级。 这不再是”能不能训练 Agent”的问题，而是”怎么在真实环境里、用合理的成本、规模化地训练和部署 Agent”的问题。

二、基础设施层：OpenForge RL 终结「训练-部署鸿沟」

问题：你的 Agent 在训练时和上线时，跑的根本不是同一个东西

这是一个被长期忽视但致命的矛盾。

当你使用 Claude Code 或 Codex 编写代码时，Agent 运行在一个精巧的推理 harness 中——它管理多轮对话、工具调用、子 Agent 调度、上下文压缩、与浏览器/文件系统/API 服务器的连接。这个 harness 的代码量可能是模型本身的数倍，且高度有状态、多进程。

但当你想要训练一个 Agent 时，几乎所有开源的强化学习框架（veRL、Slime 等）都假设你能直接控制 prompt 和生成过程。这意味着你必须在训练阶段重新实现一个简化版的 harness。

问题就出在这里：简化版 harness 和真实 harness 的行为不一致。你在一个”模拟”环境里训练出来的 Agent，部署到 Claude Code 的真实 harness 后，性能必然打折扣。这就是所谓的「训练-部署不匹配」（training-deployment mismatch）。

OpenForge RL 的方案：把 Agent 塞进真实 harness 里训练

微软和哥伦比亚大学团队的解法简洁而优雅：不要重写 harness，而是让 RL 训练框架学会跟真实 harness 对话。

OpenForge RL 在 harness 和推理服务器（如 vLLM）之间插入一个轻量级代理。这个代理做两件事：

1. 记录：拦截 harness 发来的每一次模型调用请求、每一轮工具返回结果、每一次子 Agent 调度，将整条交互轨迹记录为结构化训练数据。
2. 编排：由 Kubernetes 调度器为每个 rollout 任务启动独立容器，容器内运行真实的 harness 二进制（Claude Code、OpenClaw、Codex 等），训练循环通过代理驱动 harness 完成任务。

关键设计在于：harness 代码无需修改。 你直接把 Claude Code 的 Docker 镜像扔进容器，OpenForge 就能驱动它完成 rollout 并产出训练轨迹。这意味着 Agent 学到的行为模式与它在生产环境中的行为模式完全一致——训练-部署不匹配被从根本上消除。

效果：几百个任务就能训出可用 Agent

在工具调用（Claw）基准上，仅用数百到数千个任务训练后：

• OpenForgeClaw 在 ClawEval 上达到 55.9 pass@3，QwenClawBench 达到 33.7
• OpenForgeGUI 在 OSWorld-Verified 上达到 37.7，Online-Mind2Web 达到 63.0，WebVoyager 达到 72.3

这些成绩在几乎所有基准上都超越了同等规模的开源模型，在 GUI 任务上甚至追平或超过了参数规模数倍于己的模型。

更有意思的是跨 harness 泛化实验。在 ZeroClaw 上训练的 Agent 迁移到未见过的 Codex harness 上仍有提升；多 harness 联合训练则普遍更优。这暗示 Agent 正在学到的是工具使用的通用策略，而非针对某个特定 harness 的过拟合行为。

但研究团队也坦承了两个短板：错误恢复能力仍然薄弱（RL 提升了自我验证和工具覆盖率，但面对执行中的硬错误还是容易卡壳），以及部分 rollout 的信用分配尚未解决（容器崩溃或网络超时导致整个 rollout 被丢弃，其中有效步骤的训练信号白白浪费）。

一个容易被忽略的信息：harness 选择本身就影响可学习性

论文中有一个反直觉的发现：不同的 harness 在同一 RL 方案下产生显著不同的学习难度曲线。 ZeroClaw、OpenClaw、Codex 三个 harness 的 learnability 差异明显——工具接入更灵活的 harness 最终分数更高，但 prompt 更长、上下文更复杂的 harness 反而强化学习的收益有限。

这对选型有直接指导意义：如果你打算对 Agent 做 RL 微调，harness 的”可学习性”本身就应该成为评估指标之一。

三、架构层：Matryoshka Agent——小模型指挥大模型的层级魔法

问题：长程任务把单体 Agent 的上下文撑爆了

机器学习工程（MLE）任务——比如自动调参、特征工程、模型选型——是 Agent 长程决策能力的终极压力测试。一个典型的 MLE 任务需要 Agent 在数十轮交互中持续调试、分析失败、修正策略，上下文长度动辄数万甚至数十万 token。

单体 Agent 在这种场景下会同时面临三个相互矛盾的约束：

1. 上下文噪声：历史交互堆积在上下文里，早期失败的细节在后期变成纯粹的噪声。
2. 探索空间爆炸：每次失败后该怎么改？选项组合呈指数级增长。
3. 容量预算：小模型记不住，大模型烧不起。

Matryoshka Agent 的方案：把决策和执行拆成两层

Matryoshka Agent（俄罗斯套娃 Agent，这个名字取得精准）提出了一个统一的分层框架：

• 上层：Orchestrator（编排器）。维护一个紧凑的长程探索状态，发出战略性指令（“尝试用 XGBoost 替代 LightGBM，重点优化类别特征编码”），而不陷入具体实现细节。
• 下层：Sub-Agent（子执行器）。接收 Orchestrator 的指令，通过标准化的 Tool 接口与真实环境交互，执行具体的代码编写、模型训练、结果验证。

两层之间的通信通过一个严格定义的小型 Tool 响应模式来约束——Orchestrator 看不到子 Agent 内部的海量交互日志，只拿到结构化的执行结果（成功/失败、关键指标、诊断摘要）。这种”信息边界”的设计让 Orchestrator 的上下文始终保持可控规模，避免了单体 Agent 的上下文爆炸问题。

效果：Qwen3-4B 当指挥，追平 o4-mini 单体

最令人印象深刻的实验结果是这个：Qwen3-4B-Instruct 作为 Orchestrator + o4-mini 作为 Sub-Agent 的组合，在 MLE-Dojo 基准上的 HumanRank 达到 0.5360，超过了单体 o4-mini 的 0.4832。 也就是说，一个 4B 参数的小模型通过”指挥”一个更强的执行模型，整体表现超过了强模型自己单干。

对 Orchestrator 进一步做 SFT 后（Qwen3-4B-SFT + o4-mini）达到 0.5061，再加 RL（Qwen3-4B-RL + o4-mini）达到 0.5360。SFT 带来 +0.0448 的提升，RL 再叠加 +0.0299——两阶段训练合计将 4B 小模型的指挥能力推到了接近全 o4-mini 水平（0.5465）。

对于 Qwen3-30B-Coder，应用 Matryoshka Agent 框架后相对性能提升最高达 36.7%。

更底层的数据来自上下文长度分析：单体 Dojo Agent 在多轮交互后上下文呈线性增长（每轮约 +5K tokens），而 Matryoshka Agent 的 Orchestrator 上下文增长速率仅为前者的约三分之一——因为每次只需要看结构化的执行摘要，不需要吞下完整的交互日志。

这跟 Anthropic 的 Dynamic Workflows 有什么关系？

如果你读过本站 5 月底关于 Opus 4.8 Dynamic Workflows 的分析，会发现 Anthropic 把”数百子 Agent 并行”做成了产品特性。但 Matryoshka Agent 从学术层面提供了更系统化的理论支撑：层级分解不仅是一个工程优化，更是一种有理论基础（Solution Refinement Tree + DPO 扩展排名损失）的训练范式。 Orchestrator 的训练目标是”最大化下游回报”——这是一种以结果为导向的偏好学习，比 Anthropic 在 Dynamic Workflows 中使用的规则式编排更具泛化潜力。

四、范式层：LLaDA 2.2——扩散模型终于学会了「边做边改」

自回归模型称霸 Agent 的历史，其实并不长

Agent 赛道长期被自回归模型垄断是有原因的。多轮对话、工具调用、环境反馈处理——这些任务天然要求序列因果性。逐 token 生成虽然慢，但每一步的上下文都是正确且最新的，逻辑链条不容易断。

扩散语言模型（dLLM）一直有一个尴尬的处境：它们可以并行生成一个 block 中的所有 token，理论上比自回归快得多（LLaDA 2.0 在百亿参数规模上推理速度是自回归模型的 2.1 倍），但一旦进入 Agent 那种需要追踪长交互历史、调用外部工具、处理环境反馈并修正自身行为的连续闭环，整套范式的稳定性就开始摇摇欲坠。

根本症结在于「一次性生成」——传统扩散模型在生成一个 block 时，早期位置的微小偏差会作为硬约束传导到后续 block，且无法在生成过程中修正。ICML 2026 最佳论文《The Flexibility Trap》甚至指出，扩散模型引以为傲的”任意顺序生成”能力在推理任务上恰恰是陷阱——模型倾向于绕过不确定的 token，先填容易的位置，导致关键决策点的解空间过早坍缩。

LLaDA 2.2 的核心突破：Levenshtein Editing

蚂蚁 inclusionAI 团队做了一件大胆的事：他们从编辑层面彻底改造了扩散模型的生成机制。

LLaDA 2.2 引入了 Levenshtein Editing——模型不再被限制在等长替换上，而是可以删除一段冗余内容、在指定位置插入新 token、对已有序列进行替换。这意味着扩散模型首次获得了「边生成边修改」的能力——就像一个程序员反复修改自己的代码，而不是一次性写完就提交。

这在 Agent 场景中的意义是革命性的。一个部署在工厂里的 Agent，收到传感器告警后可以：

1. 并行生成多个可能的应对方案（扩散模型的天然优势）
2. 根据环境反馈动态修正错误步骤（Levenshtein Editing）
3. 在多轮交互中保持上下文一致性（原生 128K 上下文窗口）

效果：追平自回归，局部反超

SWE-bench Verified 49.28%——这个数字本身不算惊人（GLM-5.2 同期在 60%+），但放在扩散模型的历史曲线上看，这是从”不适合 Agent”到”可以胜任 Agent”的质变。

更值得关注的是在 τ²-Bench 上的 592.80 分（Ling-2.6-flash 为 334.90，Fast Mode 更是冲到 705.30）。τ²-Bench 是一个专门衡量 Agent 在真实交互任务中表现的基准——包括工具调用可靠性、反馈处理质量、长程任务完成率——而这些正是此前扩散模型的阿喀琉斯之踵。LLaDA 2.2 在 PinchBench、MCP-Atlas 等交互式任务上也实现了反超，说明它在偏向真实交互的 Agent 场景中已经开始展现竞争力。

在吞吐量方面，LLaDA 2.2-flash 的 BF16 平均吞吐量可达 Ling-2.6-flash 的 1.64 倍，量化至 FP8 后再提升 18.6%。在 11 类工作负载上的综合效率优势已经不是一个”理论加速”的学术概念，而是可以在生产环境中兑现的工程收益。

双轨并行的未来

LLaDA 2.2 没有”打败”自回归模型。在严格结构化输出和复杂代码生成中，自回归模型依然更成熟。但它的价值不在于输赢。

它证明了 Agent 不需要只有一种大脑架构。需要按序推理时用自回归，需要并行探索时用扩散——两种机制在一个 Agent 系统里各司其职，根据任务阶段动态切换。这种「双轨并行」可能才是 Agent 架构的下一个前沿。

五、商业层：Claude Opus 5——Agent 能力从论文走进产品

不是一次普通版本更新

7 月 24 日发布的 Claude Opus 5 不是简单的”Opus 4.8 + X%“。它是 Anthropic 首次将「Agent 能力」作为模型的核心卖点而非附加功能来营销的产品。

看几个数字：

• Agentic Coding 68.8%（Opus 4.8 为 49%）——近 20 个百分点的跳跃
• CursorBench 3.2 与 Fable 5 差距不足 0.5%，成本只有一半
• OSWorld 2.0 反超 Fable 5，成本仅三分之一
• Frontier-Bench v0.1 超过所有已知模型，是 Opus 4.8 的两倍+
• 平均 比 Opus 4.8 少用 26% token——在 Agent 场景中，输出 token 占账单大头

定价策略同样是一个信号：与 Opus 4.8 完全持平（输入 $5/M、输出 $25/M），没有因为能力升级涨一分钱。Anthropic 的产品经理显然读懂了市场：Agent 大规模部署的核心瓶颈不是能力，是成本。

「thinking on by default」意味着什么？

一个容易被忽视的工程变化：Opus 5 默认开启 adaptive thinking。

在 Opus 4.8 上，不传 thinking 字段意味着关闭思考模式。在 Opus 5 上，同样的请求会默认启用 adaptive thinking。这意味着所有现有的 Agent 工作流、所有依赖 Opus API 的生产管线，如果不显式关闭 thinking，账单会发生变化。

这不是 bug，是 Anthropic 在用一个”默认开启”的决策告诉开发者：思考（thinking）不再是可选的奢侈品，而是 Agent 的标配能力。 就像你不会买一辆没有刹车的汽车——你不会部署一个不会”想一下再回答”的 Agent。

产品矩阵成型

Opus 5 的发布补齐了 Anthropic 的 Agent 产品矩阵：

• Mythos 5：网络安全和前沿科研的超高风险场景
• Fable 5：极限复杂任务的头部客户
• Opus 5：绝大多数日常 Agent 商业化的走量主力
• Sonnet 5：轻量级 Agent 和高并发场景

这种梯度布局的意义在于：不同能力的 Agent 可以在不同成本的模型上运行，而架构、工具链、编排逻辑保持统一。 这和海量小模型做 Sub-Agent + 大模型做 Orchestrator 的 Matryoshka Agent 思路，在产品层面形成了镜像。

六、交叉洞察：四条线的共同指向

这四件事如果在不同月份发生，可能只是四篇独立的技术报道。但它们在五天之内集中出现，勾勒出了一幅更完整的拼图：

1. 训练和部署正在融为一体。

OpenForge RL 的核心理念——在真实 harness 中训练——与 LLaDA 2.2 的「边行动边纠错」殊途同归。当 Agent 能够在运行过程中持续学习时，“训练”和”部署”的边界会逐渐模糊。Agent 不再是”训好了再上线”，而是”上线就是为了训得更好”。

2. 层级化架构是被学术和工业同时验证的方向。

Matryoshka Agent 从理论层面证明：Orchestrator-SubAgent 的层级分解不仅是工程需要，而是有信息论基础的最优架构。Anthropic 的 Dynamic Workflows 从产品层面证明：数百子 Agent 并行是可行的工程实践。理论侧和产品侧的同一指向，意味着层级化架构不是一种过渡方案，而是 Agent 系统的长期设计范式。

3. Agent 的「大脑多样性」时代正在开启。

LLaDA 2.2 打破了”Agent 只能用自回归模型”的教条。扩散模型的并行生成优势在需要快速探索的场景中有明显的成本-速度优势。未来的 Agent 系统可能同时使用多种模型架构——就像人类大脑有不同区域处理不同类型的认知任务。

4. 成本正在从”不考虑”变成”第一考虑”。

Claude Opus 5 的定价策略和 Matryoshka Agent 用小模型指挥大模型的设计，都指向同一个现实：Agent 的商业化落地，成本效率比能力上限更重要。一个能用 Qwen3-4B 做 Orchestrator 的企业，比一个需要所有能力跑在 Fable 5 上的企业，在规模化速度上有数量级的优势。

七、未竟之战：三个待解的硬骨头

尽管进步显著，Agent 训练基础设施仍有三个绕不过去的坎：

硬骨头一：错误恢复。 OpenForge RL 的论文明确承认：RL 之后错误恢复仍然是弱项。Matryoshka Agent 在实验中也观察到，当 Sub-Agent 连续失败多次后，Orchestrator 缺乏有效的”更换策略”能力。这可能是 Agent 训练中最难的问题——错误恢复需要模型理解”为什么失败”，而这依赖于比当前轨迹级奖励更细粒度的归因信号。

硬骨头二：跨任务泛化的天花板。 OpenForge RL 的跨 harness 泛化实验虽有好转，但增量有限（多 harness 训练在 ZeroClaw 上仅从 46.0 提升到 48.5）。这说明 Agent 学到的仍然高度依赖任务分布——离”换一个领域也能用”的距离还很远。

硬骨头三：训练成本的不对称性。 尽管推理成本在下降，但训练成本依然高昂。OpenForge RL 需要为每个 rollout 启动独立容器并运行完整 harness；Matryoshka Agent 需要收集 Solution Refinement Tree 的全部分支探索数据。在 GPT-5.6 Solar System 的 Agent-of-Agents 范式已经商用的今天，开源社区如果无法显著降低训练成本，差距只会越拉越大。

八、结语：从「能不能」到「怎么规模化」

2026 年上半年，AI Agent 领域回答的问题是”能不能”——Agent 能不能写代码、能不能操控浏览器、能不能完成长程任务。

七月末的这四连击，把问题推进到了下一个阶段：“怎么规模化”。

OpenForge RL 回答了”怎么在真实环境里训”、Matryoshka Agent 回答了”怎么用更便宜的模型指挥更强的模型”、LLaDA 2.2 回答了”除了自回归还能用什么架构”、Claude Opus 5 回答了”怎么把 Agent 能力做成产品”。

四件事的合集效应是：Agent 训练的”生产级骨架”已经成型。 基础设施（OpenForge）、架构范式（层级分解）、模型多样性（扩散+自回归）、成本模型（分层定价+小模型指挥）——这四个支柱为 Agent 从少数企业的”实验性部署”走向全行业的”工业化落地”铺平了道路。

接下来的问题不是”Agent 能做更多的事吗”，而是”你能用多低的成本、在多真实的环境里、用多快的速度把一个 Agent 训出来并让它持续变好”。

后者是一个工程问题。而工程问题，是最适合被系统性解决的问题。