你的推理服务器其实是个学习者：开源Reef以实现持续自我改进

Reef 完全开源：https://github.com/Human-Agent-Society/reef

1. 在“RSI”热潮真正到来之前

在当今围绕 RSI 的热潮完全实现之前，我们希望开源 Reef——这是我们为同一个更广泛的问题构建的基础设施：让代理（harness + 模型）能够从自身经验中持续进化。

目标是让开源社区更容易尝试持续自我改进，并方便地获得用于此目的的生产级基础设施。我们在这里使用持续自我改进作为更广泛、更实用的框架，而 RSI 则代表了同一思想的更完全递归形式。⁠¹

2. 为什么持续自我改进需要新的基础设施？

大多数 LLM 基础设施假设了一个相对简单的生命周期。我们训练模型、评估它、部署它，然后用于推理。对于持续自我改进的代理，我们认为这个设置背后的两个假设开始失效。

首先，推理不再是流程的终点。代理在工作过程中会产生有用的经验，包括轨迹、执行结果、用户反馈以及其他可以推动未来改进的信号。推理时发生的事情不再是我们简单提供后便丢弃的内容。它成为学习过程本身的一部分。

其次，模型不再是唯一进化的东西。代理不仅仅是模型，持续自我改进不应局限于模型权重。提示词、记忆、技能、工具和编排逻辑都可能从经验中得到改进。更强的模型扩展了代理的能力，而更好的 harness 则有助于更有效地激发这些能力，并在复杂任务中更可靠地运用它们。

这些变化共同将原本近乎线性的流水线转变为持续进化的循环。智能体相互交互、生成经验、改进自身不同部分、评估这些改动是否值得保留，然后以系统新版本的身份重新投入服务。

正因如此，我们不将 Reef 仅仅视为训练基础设施。训练只是循环中的一环。我们认为，面向持续自我改进的基础设施必须从实时推理出发，并支撑整个智能体的进化。

3. 此类基础设施需要什么，Reef 又是如何实现的？

持续自我改进的基础设施需要端到端地掌控三件事：经验、智能体与更新。这意味着（1）从实时流量中学习，（2）同时更新模型与框架（harness），以及（3）妥善评估、版本管理并控制更新的发布方式。

掌控经验——学习必须建立在实时服务之上

推理与训练历来彼此分离。部分强化学习基础设施（如 Slime、veRL）集成了用于生成数据的推理引擎，但这些系统是为模型训练而非模型服务而设计的。

我们认为，持续自我改进的基础设施首先应当是推理基础设施，并围绕实时推理构建其训练能力：系统服务真实应用、收集测试时经验，并让学习算法持续消费这些经验。这一理念促使我们重新思考诸多设计选择，包括训练信号生成与训练样本筛选。

推理是 Reef 的原生能力。Reef 提供标准推理端点，使其易于集成到现有应用中，并将它们转变为自我进化系统。

# 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"]

应用还可以通过以下方式报告奖励、评估者反馈，或与特定推理调用相关的其他信号：

# Attach feedback to the corresponding inference record
client.post(
		"/reef/report",
    json={"feedback": "wrong answer", "references": [receipt]},
)

与现有推理引擎在整个生命周期中保持静态不同，Reef 提供有状态推理：Reef 将推理轨迹和反馈存储为结构化的经验流，处理诸如策略过时、会话合并和去重等问题。学习配方定义了该经验流的处理方式、使用哪种学习算法，以及何时评估和部署更新。这使得不同应用能够在相同基础设施之上，以各自的学习策略进行演进。

拥有完整的智能体——模型与框架均通过有状态推理进行演进

一个能够交付端到端结果的AI智能体，不仅包含模型，还包含一个操控框架（harness）。模型提供完成任务所需的基础能力，而操控框架则通过管理工具、上下文、记忆、反馈和编排，确保在复杂、长周期的轨迹中可靠执行。两者紧密耦合：操控框架决定了模型能力如何被激发、落地和运用，而模型则决定了操控框架能可靠支持何种执行形式。因此，任何一方的进步都可能改变另一方的最优设计。一个持续自我改进的基础设施应支持整个智能体栈的联合演进，不仅包括模型权重，还包括提示词、记忆、技能、工具和编排逻辑。

Reef支持对模型和操控框架的双重更新。

在操控框架方面，Reef使用Cordis作为训练后端。操控框架的演进配方通常分析智能体的轨迹和反馈，然后提出对操控框架的编辑建议。这一过程完全在Reef内部进行，每个演进的操控框架版本都会作为可安装更新发布给用户（假设Reef在localhost:8900上提供服务）：

curl -fsS -H "Authorization: Bearer $REEF_TOKEN" \
  'http://localhost:8900/reef/harness/install?adapter=pi' | bash

上述命令以与典型编码智能体类似的方式，安装了一个由Reef包装的Pi操控框架。该操控框架配置为使用Reef的有状态推理端点，因此其推理流量流经Reef。随着用户的使用，Cordis按照配置的操控框架演进配方对操控框架进行演进，新版本通过Reef提供。下次用户打开操控框架时，可能会看到：

在模型侧，学习配方消耗Reef记录以更新模型权重。训练与实时服务异步进行，采用分布式训练后端，目前改编自Slime，并生成候选权重更新，如检查点或LoRA适配器。

一旦候选通过评估并获准部署，Reef将其发布为场景模型工件的新版本，并通过基于NCCL的权重同步热更新服务引擎，无需重启服务。

掌控更新——演进版本经过评估与版本管理

持续演进的智能体可能面临服务质量下降的风险，尤其是当演进不保证带来性能提升时。因此，每个演进候选在发布前都应经过评估。Reef控制演进候选是否被允许替换当前服务场景的工件。若候选被拒绝，服务保持不变；否则，Reef将其发布为新的可审计版本。

Reef可演进的任何内容——如模型检查点、LoRA适配器、工具树或路由策略——均表示为由版本控制器管理的工件。Reef采用Git LFS管理工件，尤其是占用大量磁盘空间的模型权重等。发布路径如下：

每个场景拥有一个仅追加的发布链。Reef通过比较并交换推进场景的发布头，确保过时的发布者无法覆盖新发布。发布管道使Reef能够高效追踪持续版本变更及发布流程。

4. Reef中的持续自我改进方法

上述基础设施为持续自我改进提供了通用抽象。智能体如何改进的实际逻辑通过模块化的学习配方实现。

我们已经看到，将测试时生成的信号转化为更优智能体的方法日益增多：在线强化学习、测试时训练、技能进化、框架进化、自我对弈等等。尽管它们名称各异、机制不同，但都遵循相同的基本模式：测试时生成的信号被转化为对系统下一次交互生成方式的更新。

这些方法主要沿三个维度有所区别：

学习信号： 何种形式的信号驱动改进，它又源自何处？

经验获取： 学习经验如何生成？是由智能体主动寻求，还是从外部任务或交互中被动产生？

进化目标： 实际改变的是什么：模型、框架，还是两者兼有？

Reef 的设计使得这些方法大多能通过同一基础设施之上的不同学习方案来表达。使用方案很简单：选择一个，并在启动 Reef 服务时进行配置。

# serve.yaml
reef:
  recipe: recipes.sao.recipe:SAORecipe   # Plug in an evolution recipe
  batch_size: 1                          # Recipe-specific configuration
  max_staleness: 18

然后使用该配置启动 Reef：

reef serve -c recipes/sao/examples/sao/serve.yaml

下面，我们展示两个示例——OpenClaw-RL 和 TTT-Discover，它们遵循截然不同的进化策略，但都能在 Reef 中实现。

5. 结论

Reef是我们将持续自我改进这一宏大理念转化为具体系统问题的一次尝试。通过开源Reef，我们希望使这一问题更易于研究，并为社区提供一个实用基础，以构建不仅服务于用户、还能从经验中不断学习与进化的智能体。

我们诚邀您试用Reef，构建自己的学习配方，并将其与您的智能体集成。欢迎探索代码、文档及示例配方，详见 https://github.com/Human-Agent-Society/reef。如果您觉得Reef有用，我们感激您为仓库点亮一颗星。若您希望与我们共同开发或更广泛地探讨持续自我改进，也欢迎加入我们的Discord：https://discord.gg/5y8e5f937k。

不断壮大的贡献者名单（按字母顺序排列）： 柴文浩（@wenhaocha1），丁双瑞（@ShuangruiDing），何浩，何浩泽，蒋崇赫（@JiangChonghe），江南（@nanjiangwill），蒋璇，李晓晨（@jacobli99），梁保罗（@pliang279），刘波（@Benjamin_eecs），龙博远，莽秋阳（@MangQiuyang），齐振廷（@ZhentingQi），曲傲（@ao_qu18465），曲明若，王兆凯，闫学智，于涵菲（@yhfchitanda），于浩飞（@haofeiyu44），余西蒙（@simon_ycl），郑涵（@hanzheng_7），周凯辰（@alex_kai2020），周子健（@BobbyZhouZijian），朱嘉诚（@JiachengZhu_ML），庄定一