编辑｜杜伟
当 Agent 从演示视频中的炫技片段开始走进真实工作流与生产环境，下一阶段的「何去何从」成为业界关注的焦点。
最近，Claude Code 创造者 Boris Cherny 在一次访谈节目中透露，「在 Anthropic 内部，几乎 100% 的工程师都在同时运行 100 多个带有自我改进循环的 Agent【1】。这样的能力让它们在每次运行中不断变得更好」。此外 Anthropic 也发布了名为《When AI builds itself》的深度报告，其中提到当前 AI 正在接管自身的研发流程，未来将迈向递归自我改进【2】。
种种迹象表明，Agent 正面临着又一次关键的节点：从「会使用工具并完成任务」转向「在使用中学习并改进完成任务的方法」
但现实是，Agent 可以在软件工程、客服、科研助理等真实场景任务中运行，却很难在运行中变强。它们每天都会产生大量交互轨迹，包括成功路径、失败步骤、用户修正、工具调用结果等。可问题在于这些数据与经验大多只被当作日志或监控信息，用于排查问题，很少被系统化地转化为下一轮能力提升。
这背后暴露出的，是 Agent 进入生产阶段后的一大缺口。破局点在什么地方？由蚂蚁联合香港科技大学、清华大学组成的 AReaL 团队认为，自演进的障碍不只停留在单一 RL 算法层面，而在于缺少一套面向真实智能体服务的在线强化学习系统基础设施。
作为一个开箱即用的 Agentic RL 训练底座，3 月初发布的 AReaL v1.0 解决的重点是如何高效进行大规模异步 RL 训练以及让 Agent 一键接入 RL 训练。而今天上线的 AReaL 2.0，将问题边界进一步推到了 Agent 服务侧：真实部署中的 Agent 如何通过「会话式交互、轨迹采集、奖励绑定和异步训练」进入一个在线学习闭环
AReaL 2.0 给出了自己的答案，「既不要求开发者重写 Agent，也不需要现有业务系统推倒重来」。
它的核心思路是：将原本服务于 Rollout 和训练的计算单元重组为可部署、可接入、可替换的 Agent-compute 微服务组件。这样一来，只要将 Agent 原本的 LLM 推理后端切换到 AReaL 2.0 管理的入口，就可以在尽量少改动原有规划、工具调用、沙箱和记忆模块的前提下，把真实交互流引入在线 RL 闭环。
目前，AReaL 2.0 的技术报告已经放出。
- 论文标题：Next-Generation Agentic Reinforcement Learning Systems Enable Self-Evolving Agents
- 论文地址：https://arxiv.org/pdf/2607.01120
- 项目主页：https://github.com/areal-project/AReaL
Agent 自演进，首先要有学习闭环
要让 Agent 真正从使用中学习，首先要解决一个基础的问题：真实工作流里发生的一切如何被转化为可学习、可治理、可回放的经验。
在 AReaL 2.0 的系统构想中，自演进 Agent 需要三根支柱：Agent Trajectory Data Protocol、Agentic Data Proxy 以及 Agent Evolution Control Plane。
首先来看第一根支柱 ——Agent Trajectory Data Protocol（ATDP），也就是面向学习的智能体轨迹协议。
普通日志通常会记录用户问了什么、模型答了什么、调用了哪个工具、有没有报错、延迟多少、花了多少 token。对调试来说，这些信息有用；但对训练一个要从经验中变强的 Agent 来说，还远远不够。
在 AReaL 团队看来，一个真正可学习的轨迹需要以步骤为单位记录完整决策过程：当时 Agent 观察到了什么，内部状态或 harness 是什么，选择了什么动作以及动作产生了什么结果，奖励或反馈在什么时候到达以及模型版本、工具版本、租户、成本、权限、治理状态等元数据。
总之，一次复杂任务被拆分为可追责、可回放、可归因的学习样本。只有这样，系统才能回答更关键的问题：到底是哪一次检索、哪一个工具调用、哪条 prompt 片段、哪段记忆影响到了任务成败？
接下来是第二根支柱 —— 企业级 Agentic Data Proxy。ATDP 定义了「应该记录什么」，而 Data Proxy 解决的是「在真实生产系统里如何记录」。
Agent 往往同时连接模型、工具、检索系统、记忆系统、人类反馈渠道、文件系统和浏览器动作。并且不同团队可能使用不同 Agent 框架，不同租户有不同数据权限，不同业务线也有不同合规边界。如果只是把所有轨迹先堆成日志，再事后补充治理，风险会非常高。
Data Proxy 正是部署在这些关键边界上的学习数据层，它同时负责拦截、采集、脱敏、权限控制、轨迹持久化、奖励收集和回放管理。更关键的是，数据进入训练队列之前，治理就要先完成：哪些字段可见或需要脱敏，哪些轨迹具备训练资格，哪些数据只能用于调试或审计，都要在这一层处理清楚。
这也是 Agent 自演进进入企业场景后必须面对的现实问题。
最后到了第三根支柱 ——Agent Evolution Control Plane，即智能体演进控制平面。自演进不能简单理解成「一出错就立刻拿失败轨迹训练模型」。一个真实 Agent 由模型、prompt harness、记忆、工具、路由策略和安全规则共同组成，不同类型的失败对应不同的修复入口。
如果问题来自缺少某个事实，写入记忆可能更合适；如果问题出在工具路由，调整 tool schema 或 harness 可能更有效；如果某类失败跨租户、跨任务、跨工具配置持续出现，才可能需要通过 RL、偏好优化、过程奖励学习或蒸馏来更新策略模型。
控制平面的价值就在于把「是否更新、更新哪里」变成可治理的系统性决策，其根据轨迹统计、用户修正率、工具失败簇、评估器得分、成本信号、安全约束和分布漂移，判断本次演进应落在哪个层面。在企业级系统里，每一次更新还要经过回放评估、离线回归测试、租户级安全检查、灰度发布和版本化追踪。
一个无法解释「改了什么、为什么改、影响哪些用户、出问题后如何退回」的 Agent， 很难被称为真正可用的自演进系统。
三根支柱的共同作用，构成了 Agent 自演进的基本闭环。真实工作流中的经验，才有可能稳定、安全地转化为下一次变强的能力。
Online RL，被做成 Agent 微服务运行时
理解了自演进 Agent 的三根支柱，我们再来看 AReaL 2.0 的工程设计，会更容易看清它的定位。
正如 AReaL 团队所说，AReaL 2.0 并没有实现完整的自演进智能体基座。这一基座的实现涉及方方面面，AReaL 2.0 选择先从其中一条关键且具有代表性的路径切入，即基于真实部署轨迹的在线策略模型更新
因此，遵循 AReaL 2.0 的核心思路，其工程重心放在了将原有 RL 基础设施改造成可以承接 Agent 服务流量的在线系统上。它要解决的问题也更具体：一个已经上线的 Agent，如何在更少改动业务代码的前提下，将 LLM 推理请求接入 AReaL 2.0？
为了实现这一目标，AReaL 2.0 将训练、推理、权重更新等能力拆分为可独立使用、可组合、可扩展的服务组件，并通过「解耦再组合」的方式打通 Agent 应用与后训练系统之间的连接。每个组件又由统一的系统模块构建而成：
Gateway作为链路的入口，在不同服务组件中承担着不同的角色：对于智能体服务来说，它面向外部承接请求，支持 HTTP/WebSocket 等访问方式，也可以通过 OpenResponses bridge 提供兼容 /v1/responses 风格的接口；对于推理服务来说，它承接来自智能体服务转接来的会话，交由大模型服务进行推理，产生轨迹信息；对于训练服务来说，它是训练数据的入口，把准备好的轨迹导入到训练服务中去。在 AReaL 2.0 内部，Gateway 是在线 RL 运行时数据流转的第一道关口。
请求进入各组件后，接着由Router负责分配和维持会话关系。Agent 执行任务通常不会只发生在单轮对话里，伴随多轮交互、工具调用和中间状态变化。 如果同一个任务的不同轮次被随机分散到不同后端，就很容易破坏上下文连续性。因此，Router 会维护 session 与 Data Proxy 之间的绑定关系，让同一会话在后续交互中持续落到对应的数据代理上，同时也为多个 Data Proxy 与 Worker 组合的横向扩展提供基础。
Data Proxy承担的是会话状态和轨迹管理。在智能体服务中，它会保存每个 session 的历史信息，把新的用户输入、已有上下文、队列模式和相关元数据整理成 AgentRequest，再发送给后端 Worker；在推理服务中，它负责记录来自同一会话的轨迹存储信息；训练服务通过它可以拿到对应的训练数据信息并加载。它位于线上服务和训练数据之间，负责把一次次普通 Agent 调用整理成后续能够被训练系统消费的经验轨迹。
真正执行计算的是Agent-Compute Worker，它同样在不同的微服务组件中承担着不同的角色：它接收来自 AgentRunnable 协议的请求，每次调用都对应一次单轮执行，包括调用 Agent 的运行逻辑，并通过 emitter 收集生成增量、工具调用、工具返回等过程事件；在推理服务中，它通过实例化 SGLang、vLLM 等推理后端，执行推理、采样等任务；在训练服务中，它通过 Megatron、FSDP 等后端进行训练计算。
在训练任务中，每个组件由各自的Controller负责调度：包括启动 guard worker，创建 Router、Worker 与 Data Proxy 组合，完成注册和服务启动，并处理扩容、缩容、流量排空和健康检查等运行时管理任务。
在 Controller 指挥下，微服务的每个独立模块作为一个整体运行起来，进而支撑 AReaL 2.0 从线上请求接入、会话保持、轨迹采集到训练更新的完整链路。
AReaL 2.0 的 Online RL 工作流
过去做 Agentic RL，常见的路径是重构训练环境或者把线上 Agent 行为抽象为一个离线仿真任务。这样做虽然便于训练，但离线训练环境与线上真实行为之间往往存在差距。AReaL 2.0 就是要尽可能弥合这种差距，通过微服务化降低 Agent 接入 Online RL 的工程门槛。在尽量保持原有 Agent loop 不变的情况下，真实服务轨迹本身成为可采集、训练与持续优化的可靠数据来源。
通过这样的改造，AReaL 2.0 的角色也发生了变化：从面向离线后训练的 RL 框架，进一步延伸为连接 Agent 在线服务、轨迹采集、训练更新和运行时管理的可扩展系统。
从 Hermes 到 Claude Code：Agentic RL 有了可复用路径
AReaL 2.0 的价值已经开始在具体实践中得到验证。团队为我们展示了多类 Online RL 范例，覆盖已有热门 Agent 接入、软件工程智能体训练等应用场景。
其中，在面向 Hermes Agent 的范例中，AReaL 2.0 展示了一种低侵入式接入方式。当开发者手里有一个可以正常运行的 Agent，希望让它进入强化学习闭环时，不必从头重写规划逻辑、工具调用、沙箱环境或记忆模块。
有了 AReaL 2.0，解决方案变得简单直接，把标准推理后端替换为 AReaL 2.0 管理的 Agent-Compute Worker，就可以将真实交互纳入强化学习闭环。从此，开发者不用再为了训练 Agent 重搭一个离线环境或者把线上业务流程复制成一套仿真系统。
这套范例的价值还在于可替换与复制。Hermes Agent 只是演示载体，真正可复用的是背后的接入范式：把演示中的 Agent 换成自己的任务环境和智能体，复用 AReaL 2.0 的解耦接入、会话化交互与异步训练架构，则可以搭建起面向自身业务的 Agent Online RL 流程。
代码实例地址：https://github.com/areal-project/AReaL/tree/main/examples/hermes
Hermes Agent 范例展示的是接入方式，而接下来的 Claude Code Agent RL 方向的范例，更接近一套面向软件工程智能体的端到端实践参考。用一句话总结，AReaL 2.0 在该方向上提供了一套可复现的算法与基础设施范例，覆盖数据处理、Agent Infra 建设和算法训练等环节
数据侧，团队会先筛选训练样本，只保留至少有一个外部模型能够解出的问题；同时改写种子 issue 描述，让问题表述更清晰，也更贴近对应的 golden patch。Agent Infra 侧基于底层大规模并发 sandbox，并结合分布式调度、毫秒级 fork 启动和镜像预热能力，支撑起几万个环境实例并发运行，在 RL 过程中尽量减少脏数据生成，并保证长时间训练的稳定性。算法侧引入 KPop 等稳定化策略，针对训练引擎和推理引擎之间可能出现的 logp diff 问题，进行 token 级自适应过滤，降低 RL 训练后期突然崩溃的风险。
此外，针对模型可能通过 git 查答案的 reward hacking 情况，AReaL 2.0 在 harness 侧禁用了部分 git 操作。同时考虑到 Claude Code 这类黑盒 Agent 训练，系统采用了 token-in-token-out 的对齐方式。
最终效果显著，模型在经过 800 步训练后实现了稳定涨分，为开发者复现 Claude Code Agent RL、替换自定义任务环境、构建自己的软件工程 Agent 训练流程提供了完整参考。
代码实例地址：https://github.com/areal-project/AReaL/tree/main/examples/swe
这些范例说明，当一套 Online RL 工程路径跑得越来越顺，Agent 自演进不再是少数团队的定制化工程，开始具备被更多开发者复用、迁移和扩展的基础。
Agent 下一步：从执行闭环走向学习闭环
从发展来看，Agent 行业的热点看起来很分散：coding agent 从 IDE 延伸到云端沙盒，处理 issue、修复代码、生成 PR；MCP、A2A 等协议让模型、工具、数据源和其他智能体更容易连接；skills、subagents 和 workflow 让复杂任务被拆解、复用和编排。
与此同时，企业开始认真面对一系列现实问题，包括 token 成本控制、工具权限收口以及 Agent 出错后的审计、追责和回滚。
这些变化共同指向了一个趋势：Agent 正从单个智能体应用变成生产系统的一部分。核心矛盾也随之发生变化，早期关心 Agent 能否调用工具、完成任务、跑通工作流，而现在更迫切的问题是它执行过的任务以及产生的轨迹、反馈和错误能不能成为后续能力提升的「养料」。
AReaL 瞄准的正是这一薄弱环节，补上了 Agent 当前缺失的一段链路：从执行闭环走向学习闭环。在这场面向生产的 Agent 基础设施竞争中，越能把真实使用过程转化为持续改进机制，就能「越用越强」。
当然，这条路仍在早期，更完整的自演进路径有待 AReaL 后续版本的探索。并且，为了适配不同团队、不同算力平台，AReaL 坚持开源以融入主流强化学习基础设施生态，在今年 5 月从蚂蚁 inclusionAI 孵化成为独立社区并加入 PyTorch 基金会 Ecosystem 项目。
依托 AReaL，社区伙伴持续补齐不同生产环境中的关键能力，比如华为云团队为社区提供了 AReaL 在国产昇腾 NPU 上的端到端适配工作【3】，MindLab 提供了基于 LoRA 面向低算力规模场景下的端到端智能体强化学习服务化解决方案【4】。所有这些都将进一步丰富 AReaL 作为 Agentic RL 基础设施的生态边界。
未来，AReaL 的探索会与开源社区的两条生态路线紧密结合。一方面，降低社区用户使用 RL infra 的门槛。团队计划研究 AReaL-AutoPilot，让智能体参与 RL 方案的自动部署，包括自动生成训练与推理一体化 kernel、搜索训练过程中的最优并行策略，以及监控 RL 训练曲线的健康状态。另一方面，为不同芯片厂商提供更统一的 RL infra 适配标准与接口，包括算子精度对齐、权重传输统一格式，以及标准化测试样例。
1.https://x.com/0xMovez/status/2067642452991717790
2.https://www.anthropic.com/institute/recursive-self-improvement
3.https://areal-project.github.io/AReaL/en/tutorial/installation_npu.html
4.https://github.com/areal-project/AReaL-MinT
热门跟贴