Reef把Agent跑成会复盘的学习系统：Serve到Commit四环，权重和Harness都能热更

【摘要】
第一，Human-Agent-Society/reef于9月3日开源、9月10日进入部分GitHub AI热点速览自我改进类前列，定位持续学习基础设施，不只在会话外挂记忆，而是把推理、反馈、训练、评估、发布串成不停机闭环。
第二，闭环分Serve、Observe、Grow、Commit四步：每次请求发回执，反馈按回执绑定成经验，配方产出候选权重或Harness更新，只有评估胜出才热加载，支持版本化和回滚。
第三，它和agent-memory、human-review构成三层治理：memory存“发生过什么”，human-review卡“关键产出改不改”，reef决定“下次怎么自动变得更好”；但自学习不是无监督进化，低质量反馈、无评估发布、无人工验收会把错误放大。

一、为什么单有记忆还不够

Agent跑项目常出现三类重复成本。其一是失忆，新会话重讲架构、偏好、禁做项，agent-memory类方案用Markdown或向量把事实留下来可解。其二是失控，模型改了页面、代码、文档但人不知道改了哪，human-review类可视化批注可解。其三是停滞，记忆再全、人审再细，模型权重和提示规则仍靠人手动调；今天踩的坑明天还踩，因为系统没有把“结果好坏”反灌回策略。

reef补的是第三类。它把每次请求、轨迹、输出、用户评分、文字反馈做成结构化经验，再按配方更新两类对象：模型权重走SAO、OpenClawRL、TTT-Discover等，需要GPU；Harness走SkillClaw、GEPA等，迭代提示、规则、技能、工具配置，可无GPU。这样Agent不等于“自己变聪明”，而是有工程通道把真实任务结果转成下一版能力。

二、四环闭环：从回执到热更新

Serve阶段reef提供兼容OpenAI、Anthropic的HTTP接口，应用调/v1/chat/completions或/v1/messages，响应带回x-reef-agent-record-id之类回执，完整记录输入、轨迹、输出。Observe阶段客户端用/reef/report提交score和文字反馈，系统按record_id把反馈绑定到那次交互，过滤无明确信号、低质量、重复噪声的样本。Grow阶段配方读合格经验，产出候选权重、候选提示、候选技能集。Commit阶段候选和当前版跑同一评估集，胜出才进版本历史并热加载到推理服务，失败丢弃，全程不重启。

表：reef持续学习四环与产物。权重更新依配方和训练后端而定；Harness更新可本地CLI上报，如reef-pi报任务结果驱动技能演进。

1. 持续学习吞吐定性（示意）
2. 原始流量→Serve记录100%→Observe筛合格样本→Grow出候选→Commit评估
3. 若反馈覆盖率低：Observe通过样本可能明显少于100%，Grow频次受限
4. 若只做Harness：可省GPU，但模型能力上限仍由底座决定
5. 若做权重：SAO/TTT等需训练资源，闭环更慢但改底层行为
6. 说明：自改进速度不取决于“自动”二字，而取决于回执完整度、反馈质量、评估集代表性。

三、权重与Harness分开进化，避免一刀切

很多自改进方案只讲微调模型，实际落地有两个问题。其一，小团队没GPU，跑不动RL和SFT；其二，大量Agent错误不在模型能力，而在提示词含糊、技能选择错、工具权限松。reef把Agent等价于“Model+Harness”，两侧都可版本化。权重侧适合代码修复测试用例、对话偏好、验证器可自动打分任务；Harness侧适合改系统提示、增加错误处理技能、收缩工具调用规则、按项目沉淀最佳实践。

无GPU团队先跑SkillClaw和GEPA更划算：用现有模型API上报成功失败，配方改技能池和提示，评估通过后热更。这样不碰权重也能显著降低重复错误。有SGLang、vLLM和多卡资源的团队再上SAO类权重配方，做更根本的行为迁移。选型不是“越重越好”，而是反馈信号能标注到哪一层，就先改哪一层。

表：reef双路径配方对照。具体配方名称和适用任务随版本变化，以仓库recipe目录为准。

四、和agent-memory、human-review怎么拼

9月10日热点里agent-memory、human-review、reef同被归入“记忆与监督”方向，但职责不同。agent-memory存长期事实，纯Markdown真源、可Git审计、会话启动注入，解决“记得住”。human-review把HTML、Markdown、localhost产出可视化，人直接改文字、锚定评论、回传Agent，解决“关键改动有人看”。reef把任务结果和评分转成下一版权重或Harness，解决“跑完能自己复盘”。

三者串起来是：memory提供静态经验库，human-review提供人工验收入口，reef提供自动改进通道。若只上reef不上memory，经验回放成本更高；只上reef不上human-review，关键产出可能自动学错；只上memory和review不上reef，系统不停滞但不会有算法层自迭代。生产级Agent治理通常是memory打底、review卡关、reef按评估慢迭代，而不是把reef当成“装了就自动变强”。

1. 三层治理负载定性
2. memory常驻注入 ████████████ 低延迟、人人可审
3. human-review批注 ██████████ 人在关键产出前/后介入
4. reef闭环更新 ███████ 周期最长，需回执、反馈、评估、回滚
5. 说明：reef频率应低于memory注入和review批注；高频自动改权重而无人审，会把局部错误固化为全局策略。

五、边界：自改进不是递归自我起飞

reef再完整也要防四类误用。其一，反馈信号假：用户随便打分、测试未覆盖边界，Grow会把噪声学成策略；必须在Observe设资格过滤。其二，评估集偏：只拿历史成功案例评估，候选会过拟合“看起来像以前对”；要保留对抗样本、失败回归集。其三，权重自动上线：无Commit人工抽检，模型可能语法更顺但业务约束变差；关键域要求人批候选。其四，把RSI理解成无人工全程自跑，reef官方也更强调continual self-improvement而非无监督递归进化。

9月10日榜单reef约895星、列自我改进类热点；9月3日早期材料记录516星、179 commit，星数和API会随迭代变化。它不替代vLLM、SGLang只做推理，也不替代slime、veRL只做离线训练，而是把“线上经验→候选更新→评估发布”做成基础设施。小项目若没有稳定回执和评分，先用手动prompt迭代比强上reef更省；多Agent、长周期、重复任务多、有明确通过/失败信号时，再接reef才划算。