麻省理工团队开源项目 Reef:让推理服务器不只负责“回答”,还负责让 Agent 能持续学习和自我改进

线上请求留下可归因经验,Recipe 生成模型或 Harness 候选,评测与版本链决定哪些变化能进入下一轮服务。

作者:Human-Agent-Society / Qu Ao09-03 · 12 分钟
🎧 听播客版0:00 / --:--
0:00 / --:--
产品发布 · 小互解读
一分钟速览
  • 多数 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 只把通过评测的候选发布为新版本。

新版本成为下一次请求的 serving 起点
推理产生经验,经验产生候选;只有通过评测的候选才能回到线上。

这四步能够连续运转,依赖三项端到端能力:

必须掌控的对象 要解决的问题 缺失后的结果
经验 把反馈精确关联到一次请求、上下文和实际版本 样本无法归因,训练数据很快失真
整个 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 交付;交互式客户端可选择更新或跳过。
SURFACE A

模型权重

Records 进入训练后端,产生 checkpoint 或 LoRA 候选;通过评测后热更新 serving runtime。

交付:新的模型 artifact
SURFACE B

Harness

Trajectory 与反馈推动 prompt、memory、skill、tool 和 orchestration tree 的修改。

交付:可安装的 harness artifact
Reef 官方架构图,展示 service、recipe、application kernel 与 serving、evolution、state 三个能力域

官方代码分层:上层入口和 recipe 进入 application kernel,底层能力通过 adapter 接到 runtime、训练后端与 Git LFS/SQLite。

Reef harness 更新提示,显示当前 v1、最新 v2,以及更新或跳过选项

Harness 新版本以明确更新提示交付,交互用户可以安装,也可以跳过。

模型负责能力上限,harness 负责把能力稳定地组织成行动;Reef 给两者同一套候选、评测与版本语言。

“Agent 版本”由此不再只是一个模型名称。一次请求用了哪套权重、哪版规则、哪组 Skill 和工具,都可以进入可追踪的版本链。模型和 Harness 也不必一起变化:Recipe 可以只更新某一侧,甚至只训练一个引导模型,把负责执行的外部模型保持冻结。

最后只让通过评测的候选进入服务

持续更新最大的风险,是系统把噪声、个人偏差或奖励漏洞学进去,最后越学越差。Reef 严格区分“新候选”和“正在服务的版本”:Recipe 先生成候选,评测插件再比较候选与现有版本。候选被拒绝,线上服务保持不变;评测异常,流程关闭,准备中的更新不会被发布。

Reef 官方发布链:records 生成候选,经 evaluation 后被拒绝则保留 incumbent,被接受则提交 artifact、加载 serving state 并发布 release
经验记录生成候选候选评测

拒绝:正在服务的版本保持不变。

接受:提交 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 演化虽然算法不同,都可以归结为三个配置问题:

  1. 信号从哪里来? 环境 reward、用户反馈、测试结果、下一状态,还是评审模型的判断?
  2. 经验怎样取得? 被动等待真实任务,还是主动探索、搜索和自博弈?
  3. 最终改什么? 模型权重、引导模型、规则、Skill pool,还是整个 Harness tree?
Reef 官方 learning recipe 二维图,横轴为被动到主动获取经验,纵轴为模型到 harness 演化对象
SAO外部 score 或 verifier · 被动经验 · 更新模型
OpenClaw-RL用户与下一状态信号 · 被动经验 · 更新模型
TTT-Discover环境 reward · 主动探索 · 更新模型或 guidance model
SkillClaw失败与 trajectory · 演化 Skill/harness
Recipe 决定信号、经验获取和演化对象;records、评测与 release 仍由公共底座处理。

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 AgentsQu Ao / Human-Agent-Society·2026-09-01·查看主材料
本站说明
Reef 提供持续学习的控制平面;具体 Agent 能否持续变好,仍取决于反馈质量、学习方法与评测覆盖。
↑ 正文结束
✓ 本篇全文免费开放

会员可复制、下载全文 Markdown,还能让你的 AI 订阅和提问。

阅读原文 ↗
📮 新解读第一时间进邮箱

读完觉得有用?留个邮箱,每篇新解读发布就送达,随时退订。