麻省理工团队开源项目 Reef:让推理服务器不只负责“回答”,还负责让 Agent 能持续学习和自我改进
线上请求留下可归因经验,Recipe 生成模型或 Harness 候选,评测与版本链决定哪些变化能进入下一轮服务。
- 多数 Agent 在部署后停止学习,原因不是线上没有经验,而是推理记录、反馈、训练与版本发布彼此断开。
- Reef 用 Serve、Observe、Grow、Commit 把请求变成可归因经验,再生成模型或 Harness 候选;只有通过评测的版本才能回到服务。
- Recipe 把 SAO、OpenClaw-RL、TTT-Discover、SkillClaw 和 GEPA 等方法接到同一底座;scenario 隔离记录与版本,但学习方法由部署配置决定。
- Reef 可以先作为不训练的记录代理接入外部模型,再逐步启用学习;闭环能控制更新,却不能替团队保证反馈和评测目标正确。
一个 Agent 每完成一次真实任务,都会留下极有价值的经验:用户纠正了什么,工具为什么失败,哪条执行路径得到了高分,哪种结果真正解决了问题。可多数推理服务器在返回答案后就把这些信号丢掉了。模型上线的那一刻,也成了它停止学习的那一刻。
麻省理工学院(MIT)的 Ao Qu 与 Human-Agent-Society 团队,开发了一个专门解决这道断点的项目——Reef。Reef 要改变的就是这件事:把线上推理、经验记录、候选更新、评测和版本发布接成一条长期运行的闭环,让推理服务器不只负责“回答”,还负责让 Agent 持续学习和自我改进。
这套系统要解决的并不是某一种训练算法,而是持续学习缺失的工程底座:从真实流量中取得可信经验,决定该更新模型还是外层运行框架,再阻止未经验证的变化直接污染线上服务。Reef 把这个更宽泛的目标称为 continual self-improvement。它允许系统反复从经验中改善,但并不等同于已经实现了能够自行制造下一代系统的递归自我改进(RSI)。
部署后的 Agent 为什么停止学习
传统大模型的生命周期是一条单向流水线:收集数据 → 训练模型 → 离线评测 → 部署上线 → 响应请求。训练系统关心参数如何变化,推理系统只关心如何稳定返回结果,两边在部署时被切开了。
Agent 让这个切口变得越来越昂贵。一次长任务包含多轮对话、工具调用、中间状态、执行结果和用户反馈,它们共同回答了三个关键问题:系统当时看到了什么、做了什么、结果到底好不好。这类经验比通用离线语料更贴近真实需求,却常常没有稳定路径回到学习系统。
另一个问题是,Agent 的行为并不只由模型权重决定。提示词、记忆、Skill、工具权限和编排逻辑都会改变最终结果。工具选错、上下文组织失控或规则写坏时,继续训练模型可能既昂贵又无效;真正该改的对象可能在模型外面。
所以,持续学习需要同时打通两条断点:
- 推理不再是终点。 线上轨迹、执行结果、用户反馈和环境奖励要成为下一轮学习的输入。
- 模型不再是唯一的更新对象。 权重与 Harness——也就是负责上下文、记忆、Skill、工具和编排的外层系统——都要进入同一套演化与版本控制流程。
问题因此从“再接一条训练管道”变成了“怎样管理一个不断产生经验、候选和新版本的在线系统”。
到这里,Reef 与站内两篇解读正好接上:Harness 工程继续展开“模型外面还有什么可以优化”,OpenAI 的 ARC-AGI-3 复盘则把 Harness 对结果的影响放进一个具体实验。Reef 补上的下一步,是让这些改动能够从线上经验中持续产生,经过评测,再安全进入下一版服务。
一次请求怎样变成下一次更新
Reef 把一次学习循环拆成四步:Serve、Observe、Grow、Commit。Serve 处理请求并留下记录,Observe 把后续反馈对回具体交互,Grow 用符合条件的经验生成候选,Commit 只把通过评测的候选发布为新版本。
这四步能够连续运转,依赖三项端到端能力:
| 必须掌控的对象 | 要解决的问题 | 缺失后的结果 |
|---|---|---|
| 经验 | 把反馈精确关联到一次请求、上下文和实际版本 | 样本无法归因,训练数据很快失真 |
| 整个 Agent | 同时识别模型与 Harness 中可变化的部分 | 行为变化无法定位,更新对象选错 |
| 版本发布 | 评测候选并控制它何时替换线上版本 | 坏更新直接污染服务,旧任务还可能覆盖新版本 |
先把经验和反馈对上号
Reef 首先是一台推理服务器。它接受 OpenAI 的 /v1/chat/completions 和 Anthropic 的 /v1/messages 请求体;应用无需另造一套调用协议。区别在于,每次响应会多返回一个 x-reef-agent-record-id,相当于这次推理的收据。
用户评价、测试结果或环境奖励出现后,应用再调用 /reef/report,用这张收据指出反馈对应哪次交互:
response = reef.post(
"/v1/chat/completions",
headers={"x-reef-scenario": "support-agent"},
json={"model": model, "messages": messages},
)
receipt = response.headers["x-reef-agent-record-id"]
reef.post(
"/reef/report",
json={
"score": 0.0,
"feedback": "没有处理空 token 的情况",
"references": [receipt],
},
)
这一步解决了持续学习最基础的归因问题:一条反馈究竟在评价哪次推理、哪组上下文和哪个 Agent 版本。Reef 所说的 stateful inference 不只是保存聊天历史,还包括保存结构化推理记录、反馈引用、scenario、artifact 版本和样本新鲜度。
统一的记录层还能处理多轮 session 拼接、重复样本和 off-policy staleness。后者衡量一条经验来自多旧的策略,以及它是否还适合训练当前版本。不同 scenario 隔离各自的记录和版本;Recipe 则由部署配置选定,请求只能指定 scenario,不能临时切换学习方法。
再决定该改模型,还是改 Harness
模型负责语言、推理和生成,Harness 负责把能力组织成可靠行动。模型再强,也补不上错误的工具权限和混乱的上下文;Harness 再精巧,也无法凭空创造模型没有的能力。Reef 因此把两者都做成可以产生候选、接受评测和发布版本的 learning surface。
- 模型侧: Recipe 异步消费符合条件的记录,训练出 checkpoint 或 LoRA 候选。模型训练后端基于 Slime 适配;候选获准后,可通过 NCCL 同步权重并热更新推理引擎,不必停止服务。
- Harness 侧: Recipe 根据执行轨迹、反馈与评测任务修改规则、提示词、记忆、Skill、工具或编排树。Cordis 承担 Harness 演化后端,新版本以可安装 artifact 交付;交互式客户端可选择更新或跳过。
模型权重
Records 进入训练后端,产生 checkpoint 或 LoRA 候选;通过评测后热更新 serving runtime。
交付:新的模型 artifactHarness
Trajectory 与反馈推动 prompt、memory、skill、tool 和 orchestration tree 的修改。
交付:可安装的 harness artifact
官方代码分层:上层入口和 recipe 进入 application kernel,底层能力通过 adapter 接到 runtime、训练后端与 Git LFS/SQLite。
Harness 新版本以明确更新提示交付,交互用户可以安装,也可以跳过。
“Agent 版本”由此不再只是一个模型名称。一次请求用了哪套权重、哪版规则、哪组 Skill 和工具,都可以进入可追踪的版本链。模型和 Harness 也不必一起变化:Recipe 可以只更新某一侧,甚至只训练一个引导模型,把负责执行的外部模型保持冻结。
最后只让通过评测的候选进入服务
持续更新最大的风险,是系统把噪声、个人偏差或奖励漏洞学进去,最后越学越差。Reef 严格区分“新候选”和“正在服务的版本”:Recipe 先生成候选,评测插件再比较候选与现有版本。候选被拒绝,线上服务保持不变;评测异常,流程关闭,准备中的更新不会被发布。
拒绝:正在服务的版本保持不变。
接受:提交 artifact → 加载 serving state → 推进 release head。
只有评测明确通过,Reef 才会提交 artifact、加载新的 serving state,并推进 release。模型 checkpoint、LoRA、Harness tree 和 routing policy 都可以被版本化;Git 与 Git LFS 负责保存这些对象。
每个 scenario 维护自己的追加式 release chain。发布者推进 release head 时,必须声明自己看到的旧 head;如果另一项任务已经发布了更新,compare-and-swap 会拒绝这次过期提交,避免较老的训练任务覆盖较新的版本。
这套门控能保证更新按规则进入服务,却不能替团队定义“什么叫更好”。评测集太窄、反馈带有偏差或指标容易被钻空子时,严密的版本链只会更可靠地执行错误目标。
不同学习方法怎样共用一套底座
Learning Recipe 决定“怎么学”,公共底座负责记录、批处理、评测和发布。在线强化学习、测试时训练、提示词优化和 Skill 演化虽然算法不同,都可以归结为三个配置问题:
- 信号从哪里来? 环境 reward、用户反馈、测试结果、下一状态,还是评审模型的判断?
- 经验怎样取得? 被动等待真实任务,还是主动探索、搜索和自博弈?
- 最终改什么? 模型权重、引导模型、规则、Skill pool,还是整个 Harness tree?
Reef 已经把多种路径装进同一套接口:
| Recipe | 经验与信号 | 主要更新对象 |
|---|---|---|
| SAO | 连续任务由测试或 verifier 给出分数 | 模型权重 |
| OpenClaw-RL | 从用户交互的下一状态中提取可利用信号,不要求显式报告 | 模型权重 |
| TTT-Discover | 围绕同一问题反复尝试,用环境 reward 保留更优解 | 模型权重 |
| Guidance-TTT | 对代码搜索结果打分,执行模型保持冻结 | 引导模型权重 |
| SkillClaw / Harness Evolve | 从失败流量、执行轨迹和评测任务中产生 Skill 或规则候选 | Skill pool 或 Harness tree |
| GEPA | 从失败样本中反思并改写规则,在小批次与完整验证集上筛选 | 规则、Skill 等 Harness 组件 |
OpenClaw-RL 的示例把一名模拟学生的 72 道 GSM8K 作业连续送给个人 Agent,用“经过多少轮交互才能符合学生偏好”衡量适应速度。TTT-Discover 走的是另一条路:它围绕 Packing 32 等可评分问题不断尝试,用环境奖励保留更有效的解法。两者一个从连续交互中被动学习,一个在单个问题上主动搜索,却共享相同的记录与版本底座。
GEPA 进一步说明,持续学习不必等同于更新权重。它从失败流量中选择一个 Harness 组件,让更强的反思模型提出改写,再用小批次和完整验证集逐层筛选。Reef 的 AIME 2025 验证在两个随机种子上分别从 26.67% 提升到 46.67%、从 24.00% 提升到 36.00%。这只有两个种子,说明实现能够跑通并产生候选改进,不能证明它在不同任务上都稳定优于其他方法。
接入也不必从训练开始。Basic Recipe 只记录请求、不学习:可以用一个 Reef 进程代理外部 HTTP 模型,无需本地 GPU;也可以连接本地 SGLang,但不启动训练。团队可以先验证请求、收据、反馈和版本链是否可靠,再决定是否开启权重或 Harness 更新。
需要注意,reef-infra 的 PyPI 包提供核心基础设施,Cookbook Recipe 保存在源码仓库中,并不随 wheel 一起分发。运行这些方法需要源码 checkout 和各自的依赖;模型训练通常还需要满足文档要求的 GPU 环境,Skill 或 Harness 演化则存在不依赖 GPU 的路径。
Reef 真正改变了什么
Reef 把 Agent 开发中的三个分离系统接到了一起:推理服务开始积累可归因经验,模型与 Harness 共享版本边界,训练结果必须经过评测和发布控制才能回到线上。
这意味着,训练不再只是周期性产出一个 checkpoint。Observe 决定哪些反馈可信且仍然新鲜,Grow 负责提出变化,Commit 决定变化能否成为下一版服务。持续学习因此成为一项长期的 release engineering,而不是一次离线实验。
最适合这套架构的,是任务会重复出现、结果能够被测试或相对可靠地评分、团队也愿意维护回归评测和 artifact 生命周期的场景。只有零散主观反馈、没有稳定评测面时,接上闭环只会更快地积累不确定性。
Reef 采用 Apache-2.0 许可证,要求 Python 3.10 以上;artifact 与 checkpoint 功能依赖 Git LFS。它提供了让 Agent 在真实服务中“边做边学”的控制平面,但最终学到好习惯还是坏习惯,仍由反馈信号、学习方法和评测质量决定。
Your Inference Server is Secretly a Learner: Open-Sourcing Reef for Continual Self-Improving Agents

Reef is fully open source: https://github.com/Human-Agent-Society/reef
1. Before all the “RSI” hype becomes real
Before today's excitement around RSI is fully realized, we want to open-source Reef, an infrastructure we've been building for the same broader problem: enabling agents (harness + model) to continuously evolve from their experience.
The goal is to make it easier for the open-source community to experiment with continual self-improvement and readily access production-grade infrastructure for it. We use continual self-improvement as the broader and more practical framing here, with RSI representing a more fully recursive form of the same idea.¹
2. Why does continual self-improvement need new infrastructure?
Most LLM infrastructure assumes a relatively simple lifecycle. We train a model, evaluate it, deploy it, and then use it for inference. For continually self-improving agents, we think two assumptions behind this setup start to break.
First, inference is no longer the end of the pipeline. Agents generate useful experience while they work, including trajectories, execution results, user feedback, and other signals that can drive future improvement. What happens at inference time is no longer something we simply serve and discard. It becomes part of the learning process itself.
Second, the model is no longer the only thing that evolves. An agent is more than a model, and continual self-improvement should not be restricted to model weights. Prompts, memory, skills, tools, and orchestration logic can all potentially improve from experience. A stronger model expands the agent's capabilities, while a better harness helps elicit those capabilities more effectively and exercise them more reliably in complex tasks.
Together, these changes turn what was once a mostly sequential pipeline into a continuous evolution loop. Agents interact, generate experience, improve different parts of themselves, evaluate whether those changes are worth keeping, and return to serving as new versions of the system.
That is also why we do not think of Reef as merely training infrastructure. Training is only one part of the loop. We think infrastructure for continual self-improvement has to start from live inference and support the evolution of the whole agent.
3. What does such infrastructure need, and how does Reef implement it?

Infrastructure for continual self-improvement needs to own three things end to end: the experience, the agent, and the updates. That means (1) learning from live traffic, (2) updating both the model and the harness, and (3) properly evaluating, versioning, and controlling how updates are released.
Own the experience — learning has to be built on top of live serving
Inference and training have historically been decoupled. Some RL infrastructure (e.g., Slime, veRL) incorporates an inference engine for generating data, but these systems are designed for model training rather than model serving. We posit that a continual self-improving infra should first be an inference infra and build its training capacity around live inference: the system serves real applications, collects test-time experience, and lets learning recipes continuously consume it. This belief leads to a rethinking of many design choices, including training signal generation and training sample selection.
Inference is native to Reef. Reef exposes standard inference endpoints, making it easy to integrate into existing applications and turn them into self-evolving systems.
# client = xxx # initialize httpx client to Reef's serving endpoint
# Standard inference call through Reef, Open-AI format
response = client.post(
"/v1/chat/completions",
json={"model": xxx, "messages": xxx},
)
# Reference to the inference record stored by Reef
receipt = response.headers["x-reef-agent-record-id"]Applications can also report rewards, evaluator feedback, or other signals associated with specific inference calls through:
# Attach feedback to the corresponding inference record
client.post(
"/reef/report",
json={"feedback": "wrong answer", "references": [receipt]},
)Different from existing inference engines that stay static throughout their lifecycles, Reef offers stateful inference: Reef stores inference traces and feedback as a structured experience stream, handling issues such as off-policy staleness, session merging, and deduplication. Learning recipes define how this stream is processed, which learning algorithm is used, and when updates are evaluated and deployed. This lets different applications evolve with their own learning strategies on top of the same infrastructure.
Own the whole agent - both the model and the harness are evolved via stateful inference
An AI agent capable of delivering end-to-end results consists not only of a model, but also of a harness. The model provides the underlying capabilities needed to solve tasks, while the harness enables reliable execution across complex, long-horizon trajectories by managing tools, context, memory, feedback, and orchestration. The two are tightly coupled: the harness determines how the model’s capabilities are elicited, grounded, and exercised, while the model determines what forms of execution the harness can reliably support. Advances in either can therefore change the optimal design of the other. A continual self-improving infrastructure should support the joint evolution of the entire agent stack, including not only model weights, but also prompts, memory, skills, tools, and orchestration logic.
Reef supports updates to both the model and the harness.
On the harness side, Reef uses Cordis as a "training backend." A harness evolution recipe typically analyzes agent trajectories and feedback, then proposes edits to the harness. This process happens entirely within Reef, and each evolved harness version is released to the user as an installable update (assuming Reef is served on localhost:8900):
curl -fsS -H "Authorization: Bearer $REEF_TOKEN" \
'http://localhost:8900/reef/harness/install?adapter=pi' | bashThe command above installs a Reef-wrapped Pi harness in much the same way as a typical coding agent. The harness is configured to use Reef's stateful inference endpoint, so its inference traffic flows through Reef. As the user works, Cordis evolves the harness following the configured harness evolution recipe, and new versions are made available through Reef. The next time the user opens the harness, they may see:

On the model side, learning recipes consume Reef records to update model weights. Training runs asynchronously with live serving using a distributed training backend, currently adapted from Slime, and produces candidate weight updates such as checkpoints or LoRA adapters.
Once a candidate passes evaluation and is approved for deployment, Reef publishes it as a new version of the scenario's model artifact and hot-updates the serving engine using NCCL-based weight synchronization, without restarting the service.
Own the updates - evolved releases are evaluated and versioned
A continuously evolving agent is subject to service quality degradation especially as the evolution is not guaranteed to bring performance improvement. As such, each evolved candidate should be evaluated before release. Reef controls whether an evolved candidate is allowed to replace the artifact currently serving a scenario. If the candidate is rejected, serving remains unchanged. Otherwise Reef publishes it as a new, auditable release.
Anything Reef can evolve—such as a model checkpoint, LoRA adapter, harness tree, or routing policy—is represented as an artifact managed by a version controller. Reef adopts Git LFS for managing the artifacts, especially ones taking up large disk space such as model weights. The release path is:

Each scenario has an append-only release chain. Reef advances the scenario’s release head using compare-and-swap, so a stale publisher cannot overwrite a newer release. The release pipeline allows Reef to efficiently track continuous version changes and release processes.
4. Continual self-improving methods in Reef
The infrastructure above provides the common abstractions for continual self-improvement. The actual logic of how an agent improves is implemented through modular learning recipes.
We have seen a growing zoo of methods for turning signals generated at test time into better agents: online reinforcement learning, test-time training, skill evolution, harness evolution, self-play, and more. Despite their different names and mechanisms, they share the same basic pattern: signals generated at test time are turned into updates to the system that generates the next interaction.
These recipes differ mainly along three dimensions:
Learning signal: What form of signal drives improvement, and where does it come from?
Experience acquisition: How is learning experience generated? Is it proactively sought by the agent, or reactively generated from an external task or interaction?
Evolving target: What actually changes: the model, the harness, or both?

Reef is designed so that these methods can largely be expressed through different learning recipes on top of the same infrastructure. Using a recipe is simple: choose one and configure it when starting the Reef service.
# serve.yaml
reef:
recipe: recipes.sao.recipe:SAORecipe # Plug in an evolution recipe
batch_size: 1 # Recipe-specific configuration
max_staleness: 18Then start Reef with the configuration:
reef serve -c recipes/sao/examples/sao/serve.yamlBelow, we show two examples, OpenClaw-RL and TTT-Discover, which follow very different evolution strategies but can both be implemented in Reef.
5. Conclusion
Reef is our attempt to turn the broad idea of continual self-improvement into a concrete systems problem. By open-sourcing Reef, we hope to make this problem easier to study and give the community a practical foundation for building agents that do not merely serve, but continually learn and evolve from experience.
We invite you to try Reef, build your own learning recipes, and integrate it with your agents. Explore the code, documentation, and example recipes at https://github.com/Human-Agent-Society/reef. If you find Reef useful, we'd appreciate a star on the repository. If you want to build with us or discuss continual self-improvement more broadly, you're more than welcome to join our Discord: https://discord.gg/5y8e5f937k.
- We use continual self-improvement as a broader and more practical framing than RSI. It covers systems that repeatedly improve from experience without requiring the fully closed loop often associated with RSI, where AI itself participates in building and improving the system that produces its next version. Reef is designed for this broader problem, while leaving room for more recursive forms of self-improvement to emerge on top of it.
Growing List of Contributors (alphabetical order): Chai Wenhao (@wenhaocha1), Ding Shuangrui (@ShuangruiDing), He Hao, He Haoze, Jiang Chonhe (@JiangChonghe), Jiang Nan (@nanjiangwill), Jiang Xuan, Li Xiaochen (@jacobli99), Liang Paul (@pliang279), Liu Bo (@Benjamin_eecs), Long Boyuan, Mang Qiuyang (@MangQiuyang), Qi Zhenting (@ZhentingQi), Qu Ao (@ao_qu18465), Qu Mingruo, Wang Zhaokai, Yan Xuezhi, Yu Hanfei (@yhfchitanda), Yu Haofei (@haofeiyu44), Yu Simon (@simon_ycl), Zheng Han (@hanzheng_7), Zhou Kaichen (@alex_kai2020), Zhou Zijian (@BobbyZhouZijian), Zhu Jiacheng (@JiachengZhu_ML), Zhuang Dingyi