NLP——AReaL2.0

注：本文包含 AI 辅助创作

参考链接：
- 原始论文：(AReaL2.0)Next-Generation Agentic Reinforcement Learning Systems Enable Self-Evolving Agents, 20260701, Ant Group & HKUST & THU
- 开源地址：github.com/AReaL-project/AReaL

Paper Summary

核心内容总结：
- 自进化 Agent（Self-evolving Agent）是一个很大的课题，本文更像是在定义并认识这个很大的课题（包含广义上的各种自进化策略方法），然后给出了一个类似 Demo 的 RL 框架
  - AReaL2.0 实现核心，将现有 RL 框架（AReaL）从离线后训练系统修改为简单的在线学习范式（AReaL2.0）
- 值得赞扬的是：
  - AReaL2.0 是对 Agent 无任何入侵的和 Agent Loop 框架（比如本文展示了与 Hermes 结合）结合，就可以快速进行训练
- 本文是基于 AReaL 实现的（是同作者蚂蚁）
- 原论文包含许多奇怪且没有详细解释的名词和形容词，阅读起来不太顺畅，似乎有故意炫技表达的情况，让读者不太容易理解
  - 本文部分内容借助 AI 翻译，一些名词不做过多分析
- 作者观点：
  - OpenClaw 等自进化 Agent 表明 Agent 能力的下一次飞跃将来自于能够从自身经验中持续学习的 Agent
  - Enterprise 自进化 Agent 的首要瓶颈不仅在于缺乏更强大的 LLM 或更有效的 RL 算法，而是由于 Agentic 在线 RL 系统
- 当前的 Agentic RL 系统三个基本方面存在不足：
  - (i) 缺乏标准化的 Agent 轨迹数据协议，无法在异构 Agent 范式间以步骤粒度携带 RL 学习信号
  - (ii) 缺乏 Enterprise 完整的数据代理（data proxy），无法将真实工作负载转化为 Governed 学习基座
  - (iii) 缺乏统一的 Agent 进化 Control Plane 与自动触发机制，能够基于轨迹统计信息，决定何时通过相应的 RL 算法更新策略模型权重或进化上下文 Harness （in-context harness）
- 作者观点：下一代 Agentic RL 系统必须围绕这三个支柱进行协同设计
  - Pillar 1: 一个标准化的 Agent 轨迹数据协议（ATDP）
    - 将 Agent 经验重新定义为 Typed 、 Step-level 的、RL 级的事件数据，而不是不透明的日志或 Prompt-Response Pair
    - 这样的协议应保留信用分配和重放所需的决策上下文、动作、结果、奖励信号、元数据、溯源和治理状态
    - 注：ATDP 是标准
  - Pillar 2: 一个 Enterprise Agentic 数据代理（综合 Agentic 数据代理）
    - 规定了如何跨模型、工具、检索系统、记忆存储和人类反馈渠道拦截（interception）、编辑（Redaction）、持久化、标注和重放异构生产交互，使其成为学习就绪的轨迹
    - 注：数据代理是基于 ATDP 标准的数据收集管理工具
    - 理解：ATDP 规定了 RL Learning 所需轨迹应包含的内容，而 Enterprise Agentic 数据代理则规定了如何在生产环境中捕获此类轨迹
  - Pillar 3: 一个统一的 Agent 进化 Control Plane
    - 决定 Agent 应在何时以及如何通过插入记忆、修补技能、编辑 Harness、更改工具模式、通过 RL 更新策略 LLM 权重、回滚或不执行任何操作来进化
- 这三个支柱共同将自进化 Agent 从算法愿景转变为 Enterprise 系统问题
- 本文作者实现了 AReaL2.0
  - 通过在单个在线学习工作流中连接已部署的在线 Agent 服务、轨迹收集、推理 Worker 和 RL 训练 Worker，展示了该议程的策略模型更新分支
    - 完整的自进化 Agent 基板仍需完整的 ATDP 支持、Governed 重放以及超越策略模型权重更新的自动多面进化

Introduction and Discussion

LLM Agent 正从实验室演示转向实际部署系统，用于研究辅助、软件工程和任务自动化
- 这类 LLM Agent 应从根本上改变 Enterprise LLM 服务的部署单元：部署的对象不应再仅仅是一个将输入 Token 序列映射到输出 Token 序列的 LLM
  - 应越来越多地成为一个嵌入在异构复杂业务环境中的长期 Agent 策略
  - 其中 Agent 读取文件、调用工具、检索文档、调用 API、更新记忆、请求人工批准，并完成复杂的分析工作
这种转变导致了 Agent 部署方式与其改进方式之间的不匹配：
- 一个已部署的 Enterprise Agent 可能执行数千或数百万次工具介导的交互，但其未来行为通常只能通过一个人工工程周期来改变：
  - 检查轨迹、定义新的评估基准、编辑 Prompt、添加工具描述、通过 RL 更新 LLM、实现新的 Agentic 循环，然后重新部署
近期出现了一些自进化 Agent：个人 Agent 系统，如 OpenClaw (2026)，以及学习框架如 OpenClaw-RL (2026)
- 表明 Agent 能力的下一次飞跃将来自于能够从情境经验（situated experience）中持续学习的 Agent (2026; 2026)
本文将自进化 Agent 解读为一个已部署的 Agent，其未来行为能够因其先前的情境经验而得到改善
- 需要谨慎说明的是，本文指的不是无限制的递归自我修改
- 而是指一个有界限的闭环，其中每个用户与 Agent 的交互轨迹可以被观察、编辑、验证、归因，并转换为几种 Governed 更新之一：
  - 记忆插入、技能补丁（skill patch）、 Harness 编辑、 Tool-schema 修改，或 On-policy RL 更新
近期基于轨迹 Reflection (2023)、记忆提取 (2026)、上下文/ Harness 编辑 (2026)、技能库 (2026) 和自反馈 (2026) 构建的 Agent 已经证明：
- 执行轨迹可以转化为可重用的指导
当前自进化 Agent 的实例更接近于个人助手或特定算法的自我改进，而非通用 Enterprise 自进化 Agent 服务
- 例如，OpenClaw (2026) 之所以引人注目，是因为它将助手重新定义为一个持久的、用户拥有的 Agent，能够跨收件箱、日历、航班和消息应用执行任务，但这与跨越多个团队、租户、工作流和合规边界的 Governed Enterprise 学习基座截然不同
- 一个 Enterprise Coding Agent 应该在尊重仓库权限、许可边界、专有代码限制和审计要求的同时，从跨团队的 Issue 解决轨迹中学习
- 一个 Customer support Agent 应该在避免客户数据泄露的同时，从升级、退款、满意度信号和 Policy 更新中学习
- 一个 Scientific Agent 必须在保留来源、可复现性和实验室约束的同时，从失败的实验和文献搜索轨迹中学习
作者认为：缺失的组件不是一个更大的模型、更巧妙的 Prompt，甚至不是特定的 RL 算法，而是一个 Enterprise 系统基座
- 一个支持从 Agentic 交互轨迹到自进化在线学习的平滑转移
当前的研究往往侧重于通过更好的模型、更好的 Prompt 和更好的工具包集成来优先改进 Agent，但这种框架忽略了现实世界大规模部署的系统挑战
自进化的 Agentic RL 不仅应作为一个算法家族来探索，还应作为一个系统设计学科来探索：
- 如何捕获经验
- 如何将其转化为可进行信用分配的数据
- 如何选择进化机制
- 如何适当地部署由此产生的更新
本文认为自进化的 Enterprise Agent 需要下一代的在线 Agentic RL 系统（self-evolving enterprise agents require next-generation online agentic RL systems ），并且这样的系统必须具有三个协同设计的支柱，包括
- (i) 一个标准化的、供应商中立的、RL 级别的 Agent 轨迹数据协议（Agent Trajectory Data Protocol，ATDP）
  - 负责跨异构 Agent 范式携带 Step-level 学习信号
- (ii) 一个 Enterprise 数据代理，将真实的 Agentic 工作负载转化为 Governed 、可重放的学习语料库
- (iii) 一个统一的 Agent 进化 Control Plane ，能够根据轨迹统计和操作约束，自动决定是更新记忆、修补技能、编辑 Harness ，还是通过后训练 RL 更新模型权重
这三个支柱列举如下：
- 第一：自进化 Agent 需要一个标准化的 Agent 轨迹数据协议（ATDP），使已部署的 Agent 经验变得可学习而不仅仅是可观察
  - 现有的 Agent 日志通常记录 Prompt、Completions、工具调用、延迟、错误和 Token 使用情况
    - 这类 Traces 对调试有用，但对在线 Agentic RL 来说是不够的
  - 一个可用于学习的轨迹必须按步骤粒度保留决策过程：
    - Agent 可用的 Observation、相关的内部或 Harness 状态、所选动作、动作结果、延迟到达的奖励或 Critique 信号
    - 以及诸如模型版本、 Tool-schema 、租户、成本和治理状态等元数据
  - 因此，ATDP 的目的是将异构的 Agent 执行过程转化为 Typed （typed）、可审计的（auditable）、可重放的和可进行信用分配的事件序列
  - 该协议应该是供应商中立（vendor-neutral）和框架无关的，支持延迟反馈和奖励增强，为反事实重放保留版本化的来源，并从一开始就 Encode 隐私、访问控制、保留和训练资格字段
  - 没有这样的协议， Enterprise Agent 可能生成大量的交互数据，但这些数据将过于不完整、不可重现或不安全，无法作为自进化的基座
- 第二：自进化 Agent 需要一个 Enterprise Agentic 数据代理
  - 负责从跨模型、工具、记忆系统、检索系统和人类反馈通道的真实生产工作负载中捕获 ATDP 轨迹
  - ATDP vs 数据代理的角色定义：
    - ATDP 规定了必须表示什么，数据代理则规定了这些表示是如何在异构 Enterprise 环境中产生的
  - 由于已部署的 Agent 不会构建在单一框架、LLM 提供商、工具栈或 Harness 范式上，数据代理必须在稳定的执行边界进行拦截：
    - LLM 调用、工具调用、检索调用、记忆读写、文件或浏览器操作、批准事件、用户更正和最终任务结果
  - 数据代理的作用不仅仅是导出 Traces
    - 而是通过编辑敏感字段、执行访问控制和保留策略、附加来源、收集弱延迟奖励信号
    - 并将轨迹持久化为适合重放和训练的形式，将生产工作转化为 Governed 学习材料
    - 重点：数据代理必须区分确定性重放、近似重放和不可重放事件，因为一个 Enterprise 学习系统必须不仅能够询问发生了什么，还能询问 Agent 在不同的 Prompt、模型检查点、记忆项、检索策略或 Tool-schema 下是否会成功
      - 从这个意义上说，数据代理是自进化 RL 循环的第一个操作安全边界
- 第三，自进化 Agent 需要一个统一的 Agent 进化 Control Plane （unified agent evolution control plane）
  - Control Plane 决定 Agent 行为应在何时、何地以及如何改变
  - 注：自进化不应等同于盲目更新模型权重
  - 一个已部署的 Agent 是一个由基础 LLM、In-context Harness、记忆、工具和护栏（guardrails）组成的复合策略
  - Agent 的不同失败需要不同的干预面
    - 重复出现的事实缺失可能需要记忆插入
    - 工具路由失败可能需要 Harness 或架构编辑
    - 可重用的程序性失败可能需要技能补丁
    - 跨租户、任务和工具配置持续存在的广泛失败，则可能通过 SFT 、偏好优化、 On-policy RL、过程奖励学习或蒸馏来证明模型权重更新的合理性
  - Control Plane 应将自进化视为一个 Governed 决策问题：
    - 给定一个 ATDP 轨迹窗口、轨迹统计信息、评估器得分、用户更正率、工具失败聚类、成本信号、安全约束和分布漂移指标，它在记忆更新、技能更新、 Harness 编辑、 Tool-schema 变更、策略更新、回滚或无操作之间进行选择
  - 每个选定的干预都必须通过重放优先评估、离线回归测试、租户感知安全检查以及版本化回滚
  - Control Plane 是将捕获的经验转化为分阶段、可审计和自动触发的 Agent 改进的机制，使 Enterprise 自进化 Agent 成为可能
系统原型：AReaL2.0 中实例化了所提出架构的一个特意限定的分支
- AReaL2.0 并非声称实现了完整的自进化 Agent 基座，而是聚焦于 On-policy LLM 权重更新作为一个代表性的进化路径
- 该原型展示了如何将现有的 RL 框架（即 AReaL (2025)）从一个离线后训练系统重组为一个面向 Agent 服务的在线 RL 循环：
  - 已部署的 Agent 服务可以将其 LLM 推理调用重定向到 AReaL2.0 管理的 Agent 计算工作节点（agent-compute workers），同时所产生的交互轨迹被捕获并供 RL 训练流水线使用
这种设计选择让本文能够探索 Agent 服务、轨迹收集和策略优化之间的实际集成，本文将更广泛的多面进化问题（包括记忆更新、技能补丁、 Harness 编辑、 Tool-schema 进化、基于重放的治理和自动干预选择）留作完整的基座系统发展议程

RL for LLM post-training

RL 已成为 LLM 后训练的 SOTA 方法 (2025)
RLHF 表明，利用人类偏好进行微调可以改善指令遵循能力 (2022)
Constitutional AI 和 RLAIF 表明，AI 生成的评判和偏好信号可以替代某些形式的人工标注 (2022)
PPO 是用于约束策略更新的基础策略梯度方法 (2017)
DPO 将偏好优化重新定义为一个更简单的分类风格目标，避免了显式的奖励模型训练和在线 RL 采样 (2023)
DeepSeek-R1 (2025) 报告称，推理行为可以通过 RL 来激励，包括涌现的自我反思和策略适应

Self-evolving agents

自进化 Agent 已成为 Agentic 工作流的一种新范式 (2025)
- ReAct (2022) 表明，LLM 可以交错推理轨迹和动作，产生可解释的、工具介导的轨迹，而非单轮 Completions
- Reflexion (2023) 将任务反馈转化为存储在记忆中的语言反思
- Memento-Skills (2026) 将技能作为一级进化的记忆工件，并通过读写反思学习过程进行更新
- OpenClaw-RL (2026) 专注于来自用户交互的个性化在线信号
这些范式证明了学习的可行性，即不总是通过更新策略 LLM 权重来作为一种新的在线 Agentic RL 范式
该领域已经拥有许多关于“什么可能进化”的机制：
- 记忆 (2026)、技能 (2026)、Prompt (2024)、搜索工具接口 (2026) 和模型权重
当前 Landscape 所缺失的，是一个用于根据已部署的轨迹决定哪个机制应该进化，以及如何评估、治理和部署由此产生的更新的在线 RL 系统基座

RL systems

近期工作优化了系统以提高 LLM 基于 RL 的后训练效率 (2024; 2025; 2025)
- HybridFlow/verl (2025) 通过混合控制器执行模型、用于零冗余 Actor 模型重共享的 3D-HybridEngine 以及自动 GPU 放置，提高了 RL 训练吞吐量
- StreamRL (2025) 通过减轻由阶段依赖引起的流水线气泡和由长尾生成长度引起的偏斜气泡，实现了分离式 RL 训练，同时支持异构和弹性资源分配
- AsyncFlow (2025) 在 Rollout 生成和策略更新之间引入了异步流式数据流和延迟参数同步，在有界陈旧性下减少硬件空闲
- AReaL (2025) 通过完全异步执行进一步将 Rollout 生成与策略优化解耦，使用陈旧性感知训练和解耦的 RL 目标来保持训练稳定性
但这些系统不足以通过在线强化学习来支持自进化 Agent

Agent and RL data protocol

标准化最近已成为 Agent 系统和 RL 数据集的一个明确研究方向
- Agent 互操作协议如 MCP (2024) 和 A2A (2025) 标准化了 Agent 如何发现工具、访问外部上下文以及跨异构提供者进行通信
- 最近的 Survey 主要围绕上下文访问、Agent 间协调、安全性、可扩展性和延迟对这些协议进行了分类 (2025)
RL 数据基础设施如 D4RL (2020) 和 RLDS (2021) 显示了标准化轨迹数据集对于离线 RL、模仿学习、重放、注释和可重现基准测试的重要性
Agent 数据协议（ADP）提出了一个轻量级的“中间语言”，用于统一跨工具使用、浏览、 Code 和通用 Agentic 工作流的异构 LLM-Agent 数据集
- 证明了标准化的 Agent 轨迹可以改进可扩展的 SFT (2025)
但这些工作并未针对本文所讨论的问题：
- 已部署的自进化 Agent 不仅需要互通性（interoperability）或离线数据集转换，还需要一个 RL 轨迹协议，该协议能在 Enterprise 约束下保留 Step-level 因果上下文、延迟奖励信号、动作结果、 Harness 和工具版本、治理元数据、重放边界和学习资格

Agent Trajectory Data Protocol（ATDP）

为了实现自进化 Agent，首先要问的问题是：What should be the right data abstraction that will be captured for learning?
为了回答这个问题，本文第一步是构建一个标准化的 Agent 轨迹数据协议（ATDP），使其能够在异构的 Agentic 工作流中以步骤粒度携带 RL-step-grade 的信号
关于自进化 Agent 这一支柱的关键陈述如下：
Key Claim (i) ：
- 自进化 Agent 需要一个标准化的、供应商中立的、RL-step-grade 的轨迹数据协议，该协议捕获 Agent 决策过程的完整生命周期，包括当前可观测性模式通常丢弃的元素

A prototype formulation，原型公式化

在 ATDP 下，一条表示为 $\tau$ 的轨迹是一个 Typed 事件序列，定义为：
$$\tau = (\mathbf{e}_1,\mathbf{e}_2,\ldots ,\mathbf{e}_T).$$
并且任何中间步骤 $\mathbf{e}_t$ 定义为：
$$\mathbf{e}_t = \langle \mathbf{o}_t,\mathbf{h}_t,\mathbf{a}_t,\mathbf{y}_t,r_t,\mathbf{m}_t\rangle$$
- $\mathbf{o}_t$ 是可观测状态（例如，工具输出、检索片段、用户消息、环境状态）
- $\mathbf{h}_t$ 是隐藏的内部状态（例如，遵循的计划、草稿本、置信度、推理摘要）
- $\mathbf{a}_t$ 是所选动作（例如，带有类型化参数架构的工具调用、以生成 Token 形式呈现的消息、代码编辑、记忆更新）
- $\mathbf{y}_t$ 是动作 $\mathbf{a}_t$ 的结果（例如，工具返回、用户接受/编辑/重试/删除，或退出码）
- $r_t$ 是奖励信号（例如，二元结果、标量分数、自然语言评判，或从 $y_t$ 提取的隐式信号）
- $\mathbf{m}_t$ 是相关元数据（例如，延迟、Token 数、成本、租户、会话、 Harness 指纹、模型 ID）
注：当 $h_t = \emptyset$ 且忽略 $m_t$ 时，该模式简化为标准的 POMDP 抽象，但它足够丰富以容纳 LLM 特定的工件：
- 推理轨迹、检索片段、 Tool-schema 、人工修正、自然语言评判和被拒绝的动作类别

Design principle of ATDP

ATDP 的设计原则如下：
- Decision-relevant bounded revelation（披露） ：
  - ATDP 应记录足够的信息以改进行为，但不应要求暴露每一个 internal Token 或隐藏推理轨迹
  - 一个自进化 Agent 需要访问足够的结构来支持信用分配、因果诊断和重放，但它通常不需要无限制地披露每一个隐藏的 Token 或思维链片段，这些通常无法提供 Auditable 学习信号
  - 问题：这里的内部 Token 和隐藏推理轨迹应该都是不需要学习的 Token，不用反传梯度的
- Unification across frameworks and tasks ：
  - 大多数现有的 Agent 日志是 Framework-specific，大多数 RL 数据集 Task-specific
  - 大多数 Enterprise 遥测技术（telemetry）是为调试、可靠性和合规性优化的，而不是为在线 Agentic RL 优化的
  - ATDP 的一个核心创新是使学习单元既不是 Prompt-Response 对，也不是不透明的 Traces ，而是一个 Typed 、 Auditable 、可进行信用分配的事件记录
- Credit assignability，信用可分配性 ：
  - ATDP 必须使轨迹能够回答 “哪个观测、Prompt 片段、检索结果、工具调用、记忆项或护栏决策对成功或失败做出了贡献？” 这一问题，这要求不仅存储所选动作，还要存储它们被选择时的关键决策上下文
  - 例如，对于工具调用，ATDP 应存储工具版本、参数架构、权限范围、延迟、错误类别、返回对象，以及该结果后来是否被信任、忽略、更正或反驳
- Late-bound learning signals，延迟绑定的学习信号 ：
  - 许多有用的奖励和评判在动作步骤之后才到达
    - 例如用户在下一轮对话中的更正、失败的测试、稍后的人工注释或较慢的远程评估器
  - ATDP 应允许事件的奖励字段在初始记录后被更新或增强，同时保持原始因果记录的不可变性
    - 这对于 Enterprise 环境至关重要，因为某些判断信号是异步的、策略介导的（policy-mediated）或采样的
      - 理解：mediated 表示某个过程、结果或行为不是自然发生的，而是通过政策的介入、引导或干预才得以实现或改变的
    - ATDP 应将其视为 Agent 学习数据的一级属性
- Versioned replayability，版本化的可重放性 ：
  - 每个事件不仅应归因于一个模型标识符，还应归因于产生它的 Exact 执行环境
    - 包括 Harness 架构、工具版本、检索索引快照、护栏配置以及策略 LLM 版本或检查点
  - 没有这些字段，“Agent 经验” 在统计上变得有用，但在操作上不可重现（operationally non-reproducible）
- Governed observability ：
  - Enterprise Agentic 交互数据可能从一开始就包含隐私、安全和血统（lineage）字段
  - ATDP 应支持编辑状态（redaction status）、数据分类标签、租户标识符、保留策略、同意或法律依据、人工审核状态以及训练资格
  - ATDP 还应支持拆分可见性：生产调试器可以查看编辑后的 Traces ，同时 Controlled 训练作业可以访问密封的（Sealed）、Policy-approved 字段

Comprehensive Agentic Data Proxy

在提出 ATDP 之后，下一个需要问的问题是：How to capture such data for enterprise-level heterogeneous agentic workflows?
- 即：如何为 Enterprise 异构 Agentic 工作流捕获此类数据？
答案是实现一个完整的数据代理
- 将数据代理不仅仅解读为一个 API 网关、一个 Traces 导出器或一个日志服务
- 数据代理还是将生产工作负载转换为 Governed 学习材料的关键机制
这里引入自进化 Agent 的第二个支柱：
Key claim (ii) ：
- 自进化 Agent 需要一个 Enterprise 数据代理，能够跨异构框架和模型提供商拦截、捕获、匿名化、持久化并重放 Agentic 工作负载，同时为多种 Agentic RL 范式提供无损序列化
ATDP 规定了学习就绪轨迹应包含的内容，而 Enterprise Agentic 数据代理则规定了如何在生产环境中捕获此类轨迹
- 该代理的位置位于：
  - Agent 与 LLM（无论是内部部署还是由外部提供商部署）之间
  - Agent 与其工具之间
  - Agent 与其短期和长期记忆系统之间
  - Agent 与人类反馈渠道之间
- 该代理的关键目的是将生产工作转化为 Governed 学习数据，而无需强制每个 Agent 团队在 Enterprise 内部重写其应用程序

Design principle of data proxy

数据代理的关键设计如下：
- Existing framework-agnostic interception ，与现有框架无关的侦查：
  - Enterprise 通常不会在单个 Agent 框架上标准化：
    - 有些团队使用 LangChain (2025) 或 LangGraph (2025)
    - 有些使用 CrewAI (2025)
    - 有些使用 OpenAI Agents SDK (2025) 或 Claude Agent SDK (2025)
    - 有些使用 MCP 连接的工具 (2024)
    - 有些编写自定义 Harness 代码
  - 所以数据代理必须在稳定的边界进行 Interception：
    - 模型 API 调用、工具调用、检索调用、记忆操作、文件系统或浏览器操作、人工审批事件以及最终用户反馈
- Lossless ATDP emission ，无损 ATDP 发射：
  - 每个被拦截的调用都应转换为 ATDP 事件流，并由数据代理以适合序列化学习的形式持久化
  - 对于 LLM 调用，无损意味着尽量保留所有符合条件且对学习必要的字段
    - 包括提示模板指纹、系统提示版本、暴露的工具、解码参数、采样输出、可用的 Token ID、可用的对数概率，以及模型版本或检查点
  - 对于工具调用，无损意味着存储输入、输出、模式、版本、权限范围、错误类别及下游使用情况
- Replay capability：
  - 一个无法重放的轨迹不是可信的训练数据
  - 重放能力要求捕获工具输入和输出、环境状态、可许可的 LLM 版本、允许的文件或数据库快照，以及外部副作用边界
  - 重放能力还要求区分确定性重放、近似重放和不可重放事件
  - 重放是区分学习代理和监控代理的关键特征
    - 监控 Traces 可以包含诸如 “Agent 调用了工具 X 并失败” 之类的陈述
    - 训练代理必须使系统能够提出这样的问题：“在不同的提示、模型、记忆、检索策略或工具模式下，Agent 是否会成功？”
  - 理解：重放能力可以让我们针对同一个任务进行重新执行反事实动作，收集更多训练轨迹，也能辅助高效生成类似 SFT，DPO，RFT，GRPO 的训练数据
    - 比如可以重放以后：
      - 用更好的模型从这一步重新执行以作为 SFT 目标数据或 DPO 的 Chosen 数据
      - 并行生成多个挑选最优作为 RFT 目标数据
      - 同时生成多个数据作为一个 Group 以作为 GRPO 训练数据
    - 而且重放可以用于快速测试我们对 Harness、对模型的等的修改是否生效等，如果不能重放，模型修改以后想快速评估就是需要重放的！
- Cross-tenant aggregation with isolation ，跨租户聚合与隔离：
  - Enterprise 可能希望单个 Code Agent 能够从多个产品团队的轨迹中学习，但每个团队可能有不同的代码仓库权限、数据分类规则和法律限制
  - 数据代理应支持隔离的租户存储、基于策略的聚合、需要时的联邦或拆分学习式训练作业，以及租户感知的评估
  - 这不仅是隐私要求，也是学习要求：没有租户元数据和隔离，系统就无法知道从一个团队学到的更新是否应泛化到另一个团队
- Reward harvesting ，奖励收获：
  - Agentic 工作负载包含许多微弱和延迟的奖励：
    - 用户回复、工单重新打开率、测试失败、编译器错误、人工修正、升级决策、退款逆转、审批延迟、下游编辑和放弃行为
  - Following OpenClaw-RL (2026) 的核心观察（即每次交互都可以生成一个下一状态信号）
    - 如用户回复、工具输出、终端状态变化或 GUI 状态变化：Enterprise 数据代理应通过将操作状态变化视为候选学习信号来泛化这一观察
    - 理解：从用户的下一个行为可以解读出来一些奖励信号，或正或负，或中间
      - 创新性思考：可以考虑训练一个模型，做一个打分，通过对用户下一个行为的情况来判定上一轮 LLM 输出是否应该给正向激励，然后再增加置信度，挑选高分置信度高的作为正样本（正奖励），挑选低分置信度高的负样本（负奖励），从而用来训练模型（甚至作为中间奖励的一部分）
  - 并非所有信号都是奖励，也并非所有奖励都可以直接安全优化，但数据代理必须在 Control Plane 决定如何使用它们之前捕获它们
- Data integrity before learning，学习前的数据完整性：
  - 数据代理应在轨迹数据进入其学习队列之前强制执行编辑（redaction）、访问控制、保留和学习资格
    - 这与常见的 “日志先累积，治理随后进行” 的模式相反
  - 在自进化系统中，代理不仅仅是可观测性收集器，还是 RL 学习循环的第一个安全边界

Agent Evolution Control Plane

在综合 Agentic 数据代理的支持下，最后一个关键问题是：When and how to trigger corresponding RL optimization for self-evolving?
- 何时以及如何触发相应的 RL 优化以实现自进化？
本文提出了一个统一的 Agent 进化 Control Plane ，该 Plane 基于轨迹统计、性能漂移（performance drift）、风险和成本，自动选择适当的干预面（记忆、技能、Harness 或权重）
- 这些不是辅助细节，他们是系统实现大规模自进化 Agent 的先决条件
- 换言之，自进化不是一个单一的优化器，而是一个在 Governance 下的决策问题，具有多个干预面（intervention surface）
自进化 Agent 的第三个支柱总结为：
- Key claim (iii)： 自进化 Agent 需要一个统一的进化机制，该机制既支持通过多种 RL 算法进行模型权重更新，也支持上下文内 Harness 工程，并能基于轨迹统计、性能漂移、安全约束和成本自动触发适当的干预

A prototype formulation

本节介绍 Control Plane 的一个原型公式化
形式上，将时间 $t$ 的已部署自进化 Agent $\mathcal{A}$ 定义为：
$$\mathcal{A}_t = \langle \pi_{\theta_t},\mathcal{H}_{\psi_t},\mathcal{M}_t,\mathcal{T}_t,\mathcal{G}_t\rangle .$$
- $\pi_{\theta_t}$ 是由参数 $\theta$ 参数化的策略 LLM
- $\mathcal{H}_{\psi_t}$ 是 In-context Harness（由参数 $\psi$ 参数化的 Harness 策略）
- $\mathcal{M}_t$ 是记忆
- $\mathcal{T}_t$ 是工具库和工具模式
- $\mathcal{G}_t$ 是 Safe governace 和护栏配置（guardrail config）
自进化的目标对象可以是多样化的，例如，包括系统提示指令、开发者指令、Agentic 提示模板、工具描述、路由、记忆检索策略、记忆策略、规划模板、子 Agent 定义、技能库等
在自进化过程中， Control Plane 观察一个时间窗口的 ATDP 轨迹 $\mathcal{D}_t = \{\tau_t\}_{t = t - W}^t$ 并选择一个进化动作：
$$u^{\star} = \arg \max_{u\in \mathcal{U} }\left[\mathcal{I}_{\mathcal{A} }(u\mid \mathcal{A}_t,\mathcal{D}_t)\right].$$
- $\mathcal{I}_{\mathcal{A} }$ 通常衡量 Agent $\mathcal{A}$ 进化的改进程度
- 进化动作集 $\mathcal{U}$ 可包括：
  - (i) 更新策略 LLM $\pi_{\theta_t}$（例如， SFT 、 DPO 、On-policy RL）
  - (ii) 更新上下文内 Harness $\mathcal{H}_{\psi_t}$（例如，技能补丁、提示编辑）
  - (iii) 更新记忆 $\mathcal{M}_t$（例如，检索策略更新）
  - (iv) 更新工具库和工具模式 $\mathcal{T}_t$（例如，工具描述编辑、工具模式更改）
  - (v) 回滚
  - (vi) 无操作（在 Safe governace 控制 $\mathcal{G}_t$ 下的无操作）

Control plane implementation considerations

在下面总结了 Agent 进化 Control Plane 的一些关键实现考虑：
- Multi-surface adaptation，适配多个不同的情况：
  - Control Plane 应明确编码不同的故障模式属于不同的干预类别
    - 如果 Agent 的轨迹显示重复出现的缺失事实或范围狭窄的可重用程序性教训，记忆插入通常是最便宜和最安全的更新
    - 如果故障集中在工具路由、检索格式、护栏措辞或开发者消息结构周围，那么 Harness 编辑通常更合适
    - 如果相同类别的故障在多个租户、任务和工具配置中持续存在，则这类问题可能不是局部于记忆或 Harness 的，而是需要使用 RL、过程奖励学习或蒸馏进行策略更新
- Automatic triggering from trajectory statistics rather than anecdotal inspection，基于轨迹统计而非 Anecdotal 检查的自动触发：
  - Control Plane 应基于明确的统计信息运作，例如评估器分数、用户修正率、过程奖励估计、特定工具故障集群、金丝雀增量、每项成功任务的成本以及工作负载组成的 Shift
  - 相信这些信号将是有用的，例如：
    - OpenClaw-RL (2026) 将下一状态信号转化为标量过程奖励和方向提示
    - AgentPRM (2026) 展示了逐轮奖励的价值
    - RLAnything (2026) 结合了 Step-level 和结果信号
  - 本文的基本技术考量是将这些统计信息从监控工件（Monitoring Artifacts）提升为干预触发器（Intervention Triggers），从而使自进化能够由真实的 Agentic 工作流驱动
- Algorithm pluralism under a unified trigger interface，统一触发接口下的算法多元性：
  - 本文呢认为下一代 Agentic RL 系统不应硬 Code 单一特定的学习范式
    - 对于策略模型权重更新，后端可能涉及 On-policy 或 Near-on-policy RL、过程奖励学习，或来自不同指令反馈的 On-policy 蒸馏
    - 对于 Harness-space 适应，Agentic RL 系统可能涉及提示优化、上下文进化、代码搜索或轨迹感知的言语编辑（verbal editing）
    - 对于记忆或技能更新，Agentic RL 系统可能涉及将轨迹蒸馏为可重用的工作流或推理对象
  - Control Plane 应组织这些多样化的范式，而不是消除这些差异
    - 它决定应调用哪个 RL 算法、使用哪个数据切片、在哪些约束下以及在什么部署路径上
- Safe audited staged deployment，安全审计的分阶段部署：
  - Agent 自进化的自动触发不应意味着未经审查的热切换 Agent 行为
  - 每项干预都应带有自己的提升路径：
    - 影子评估（shadow evaluation）、回顾性重放检查、离线回归测试、canary rollout、回滚语义以及针对当前版本的差异监控
      - Shadow Evaluation（影子评估）：无用户影响的“离线”演练
      - Canary Rollout（金丝雀发布）：真实用户的“小范围”验证
    - 这一点尤其重要，因为关于个人 Agent 的安全文献已经表明，持久状态、能力和知识可以创造相当大的攻击
  - 正确的做法不是放弃自进化，而是确保进化的分阶段门控和 Auditable
  - 统一的 Control Plane 正是这些门控所属的地方
- Replay-first evaluation，重放优先评估：
  - 在 Agentic 工作流更新到达用户之前，进化后的 Agent 应针对重放的轨迹和反事实变体进行评估，例如
    - Harness 编辑应在过去的失败和已知成功上进行测试
    - 工具模式更改应在工具调用重放上进行测试
    - 策略模型更新应在保留轨迹、安全集、租户特定评估和分布偏移探针上进行测试
  - 请注意，这种 Control Plane 实现也强调了为什么数据代理的重放能力至关重要
- Versioned provenance and rollback，版本化溯源与回滚：
  - 本文强制每个进化的工件都被版本化：LLM 检查点、提示、工具模式、记忆项、检索策略、护栏、技能文件、 Router 和数据集
  - 回滚不应是手动紧急程序，是在进化动作集 $\mathcal{U}$ 中的一等动作
  - 一个无法解释发生了何种变化的自进化 Agent，在 Enterprise 层面并不是自进化的（它仅仅是在 Drifting）

AReaL2.0：Prototype System Design and Implementation

注：本文并未声称实现了自进化 Agent 基板的完整图景，本文实现的 AReaL2.0 作为一个探索性原型，专注于一个特定的进化路径：
- 从已部署的 Agent 轨迹进行 On-policy LLM 权重更新
本文的目标不是实现上述完整的自进化 Agent 基板，也不是覆盖所有可能的干预面，如记忆插入、技能修补、Harness 编辑或工具模式进化
AReaL2.0 使用策略 LLM 更新作为代表性示例，展示如何将现有 RL 框架从离线后训练系统修改为简单的在线学习范式
AReaL2.0 将原始 AReaL 框架的 Rollout 和训练 Worker 暴露为面向 Agent 服务的计算组件
- 允许现有的 Agent 服务将其标准 LLM 推理后端替换为 AReaL2.0 管理的 Agent-Compute Worker
- 这种设计使得已部署的 Agent 交互可以被服务、捕获、存储并被在线 RL 训练循环消费，而只需对周围的 Agent Harness 进行最小更改

AReaL2.0 core design

AReaL2.0 的核心设计目标是将当前 RL 系统中的 Rollout 和训练 Worker 适配为可替换的推理服务骨干，集成到任何已部署的在线 Agent 服务中，而无需修改任何现有的 Agent Harness 实现
核心设计：AReaL2.0 prototype core desgin
- AReaL2.0 不将 RL 基础设施视为与在线部署的 Agent 工作负载断开的（disconnected）离线后训练流水线
- 而是将用于 Rollout 和策略训练的相同计算单元（例如，GPU Worker）作为微服务组件暴露出来，这些组件可以插入到任何现有的在线 Agent 部署中
AReaL2.0 对当前 AReaL 框架引入了一个优雅的轻量级扩展，其中原始的 Rollout 和训练 Worker 被封装在一个 Agentic 微服务抽象后面，允许任何现有的 Agent 服务将其标准 LLM 推理后端（例如，本地部署）替换为 AReaL2.0 管理的 Agent-Compute Worker
- 这使得已部署 Agent 交互生成的 Agentic 轨迹能够被捕获、存储并被在线 RL 训练循环消费，而无需围绕不同的离线 RL 运行时重写 Agent 应用程序本身

AReaL2.0 implementation

本文原型系统通过四个核心组件实现这一抽象：
- 网关（Gateway）、 Router （Router）、数据代理（Data Proxy）和 Agent-Compute Worker（Agent-Compute Worker）
这些组件共同将公共服务协议、会话放置、轨迹管理和模型推理或训练计算解耦（见图 1）
这种分离对于 Agentic RL 工作负载至关重要，因为请求通常是多轮、工具增强和有状态的，而训练则需要具有 Token 级元数据和奖励信号的结构化轨迹
- Gateway
  - 网关是在线 RL 系统中 Agent 服务栈的公共入口点
  - 网关的核心功能是将 AReaL2.0 暴露为现有可部署 Agent 服务的标准推理后端
  - 从应用程序的角度来看，用 AReaL2.0 网关替换一个普通的推理端点（例如，SGLang 或 vLLM 服务器）就足以将 LLM 调用重定向到启用在线 RL 的运行时
    - 在内部，网关规范化外部 LLM 请求、认证访问，并将 Agent 轮次转发到在线 RL 服务结构中
    - 此网关实质上最小化了集成成本：Agent 服务继续通过常规推理风格的 API 进行通信，而 AReaL2.0 则获得对在线 RL 所需的交互流的可见性
- Router
  - Router 为多个在线 RL 训练作业提供轻量级会话亲和性管理
    - 注意，Agentic RL 工作负载本质上是状态化的：单个任务可能涉及多轮、工具调用、中间观察和延迟奖励
  - Router 将会话分配给数据代理并在各轮次中保持此分配
    - 这允许 AReaL2.0 支持多个并发的 Agentic RL 工作负载，同时保持会话状态的一致性
  - Router 管理放置（placement）和亲和性元数据，将高容量交互流量留给数据代理和 Worker 层处理
- Data Proxy
  - 数据代理实现 Agentic 数据流量和存储的 Control Plane 管理
  - 数据代理是外部服务请求和计算 Worker 之间的中介，记录 Agentic 数据轨迹（例如，对话历史、工具调用事件和响应），并为下游训练准备轨迹数据
    - 从这个意义上说，数据代理是将普通的已部署 Agent 流量转换为在线 RL 可消费经验的组件
  - 数据代理确保 Agent 交互不仅服务于用户，而且被结构化为包含策略改进所需信息的训练数据
- Agent-Compute Worker
  - Agent-Compute Worker 是将已部署的 Agent 服务连接到 AReaL2.0 中 Rollout 和训练后端的执行抽象
    - 其核心功能是将各种推理 Rollout 引擎（如 SGLang 和 vLLM）与训练 Worker（如基于 Megatron 或 FSDP 的 Actor）一起封装在微服务接口后面
  - 这种 Worker 抽象允许根据轨迹流和训练需求动态分配和释放计算资源
  - AReaL2.0 可以在统一的面向服务的架构中服务在线 Agent 请求、收集轨迹并更新底层策略

Motivating example: online RL for hermes agent by AReaL2.0

本文实现了一个代表性用例，即为 Hermes Agent 服务 (2026) 提供在线 RL 训练支持
- 在传统部署中，Hermes 调用一个推理后端（例如，SGLang Worker）以在 Agent 执行期间获取模型响应
- 使用 AReaL2.0，该后端可以替换为通过网关暴露的 AReaL2.0 管理的 Agent-Compute Worker
- 周围的 Agent 服务基本保持不变：
  - Agent 服务继续像以前一样发出 LLM 推理请求，而 AReaL2.0 拦截交互流、记录轨迹，并将其连接到在线 RL 训练循环
此示例说明了 AReaL2.0 设计的核心优势
- AReaL2.0 不是构建一个试图模仿生产行为的单独 RL 环境，而是重用原始 Agent 服务自身生成的数据
- Agent 的原生工作流，包括多轮交互和工具使用，成为 Agentic 数据协议轨迹的来源
- 这缩小了离线后训练数据与已部署 Agent 行为之间的差距，并为从 Agent 自身的服务流量中持续改进 Agent 提供了一条实用路径

Toward the complete self-evolving agent system substrate，面向完整的自进化 Agent 系统基板

当前的 AReaL2.0 原型是为一个有意限定范围的可行性证明，用于 On-policy 模型适应，而不是作为自进化 Agent 基板完整图景的完整实现
本文展示了一个重要的集成原则：
- 现有的 RL 基础设施可以经过轻微重组，使得 Rollout 生成、推理服务、轨迹收集和策略优化能够以最小的原始在线部署变更连接到已部署的 Agent 工作流
- 此原型仅覆盖了更广泛 Control Plane 动作空间中的模型权重更新分支
一个完整的自进化 Agent 系统仍需要当前原型之外的若干能力，包括
- 一个完整的 ATDP 实现（包含 Step-level 决策上下文和治理元数据）
- 一个完整的数据代理（捕获工具、检索、记忆、文件、浏览器、人类反馈和延迟奖励事件，重放和反事实评估支持、租户感知的隐私和 training-eligibility enforcement）
- 一个进化 Control Plane
  - 能够自动在记忆更新、技能补丁、Harness 编辑、工具模式更改、策略更新、回滚或无操作之间进行选择的进化 Control Plane
AReaL2.0 是一个初始的系统步骤，它为策略更新案例奠定了基础，而完整的多面、受治理、可重放且自动触发的自进化循环则 remains 为更大的研究和系统议程

Introduction and Discussion

Related Work

RL for LLM post-training

Self-evolving agents

RL systems

Agent and RL data protocol

Agent Trajectory Data Protocol（ATDP）

A prototype formulation，原型公式化

Design principle of ATDP

Comprehensive Agentic Data Proxy

Design principle of data proxy

Agent Evolution Control Plane

A prototype formulation

Control plane implementation considerations

AReaL2.0：Prototype System Design and Implementation

AReaL2.0 core design

AReaL2.0 implementation

Motivating example: online RL for hermes agent by AReaL2.0

Toward the complete self-evolving agent system substrate，面向完整的自进化 Agent 系统基板