編輯｜杜偉

當 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