当AI学会改菜谱和练厨艺交替进行：ScienceBuddy的递归中递归自我改进
当 AI 学会"改菜谱"和"练厨艺"交替进行：ScienceBuddy 的递归中递归自我改进
一个场景
想象你是一位实验室的 PI，手下来了个新研究生。你给他一份实验流程，让他分析一批基因数据。他跑完之后结果不太对——漏查了一个数据库，把无关基因当成了靶点。
你给了反馈："下次先查 UniProt，再查 PubMed，最后才下结论。"
第二次，他确实好了一些。但你发现他还是会犯同样的错误——不是因为他不知道流程，而是他的"底层能力"不够：他不会正确解读蛋白质结构域，不会判断哪些变异是致病的。
于是你让他去读文献、上课、做练习。几周后他回来，能力提升了。但此时你发现，之前改的流程又不够用了——因为他现在能做更复杂的分析，需要更精细的操作规范。
你又改流程。他又练能力。又改流程。又练能力。
这个"改流程—练能力—改流程—练能力"的交替循环，就是 ScienceBuddy 论文的核心思想。论文给它起了个精确的名字：Recursive-in-Recursive Self-Improvement（递归中递归自我改进）。
核心问题：为什么 AI Agent 不会从交互中学习？
当前的 AI Agent 面临一个尴尬处境：你和它聊了上千轮，它该犯的错还是犯。原因很简单——大多数 Agent 系统的"工作流程"（harness）和"模型能力"（model）是割裂的。你给的反馈最多进了上下文窗口，下一轮对话就忘了。模型权重没变，工作流程也没变。
已有的改进方案各有侧重：
- Reflexion 把教训写进记忆，但只是文字层面的提醒
- GEPA 搜索更好的 prompt，但只改 prompt 不改模型
- ACE 维护上下文 playbook，但同样不动模型权重
- SEAL / Darwin Godel Machine 尝试自我修改，但把流程和模型混在一起改，容易互相干扰
问题的症结在于：工作流程和模型能力是两个不同层面的东西，同时改会互相干扰。
就像你不能一边改菜谱一边练刀工——改菜谱的时候你需要按现有刀工来设计步骤，练刀工的时候你需要一个稳定的菜谱来练习。两者必须交替进行，而不是同时进行。
方法创新：两层嵌套的递归
ScienceBuddy 的解法是把"改进"拆成两个嵌套的递归：
内层递归：固定模型，改流程
把模型权重冻住（\(\theta_k\) 固定），只改 harness——那个组织 prompt、调用工具、管理上下文的 Python 程序。具体做法是：
- 让当前 harness 跑 16 个训练任务，收集交互记录
- 一个辅助模型（GPT-6 Astra）根据交互证据提出 3 个候选 harness 修改方案
- 每个候选方案在 90 个验证任务上跑一遍，选分数最高的
- 如果新方案严格优于父方案，就替换；否则保留父方案
这一步的产出是：一个更好的工作流程，但模型还是原来那个模型。
外层递归：固定流程，练模型
把选出的 harness 冻住，用 GRPO（Group Relative Policy Optimization）做强化学习。harness 不变，但模型在收集到的轨迹上更新权重。
这一步的产出是：一个更强的模型，在更好的工作流程下训练出来的。
两层交替
外层结束后，更新后的模型回到内层，重新开始改流程——因为模型变强了，之前的工作流程可能不再最优。新的工作流程又为下一轮模型训练提供更好的训练环境。
论文跑了 3 个完整循环（\(k=0,1,2\)），每个循环内层 10 步 harness 搜索 + 外层 20 步 RL 更新。
类比：厨师与菜谱
如果你觉得公式太抽象，换个角度想：
- 模型 = 厨师的厨艺（刀工、火候控制、调味直觉）——这是"内功"
- harness = 菜谱（先切什么、后炒什么、什么时候放盐）——这是"外功"
- 任务 = 一道要做的菜
传统方法要么只练厨艺（RL 微调模型），要么只改菜谱（prompt engineering / harness search）。问题是：
- 只练厨艺，菜谱还是那本老菜谱，厨师的新本事没地方发挥
- 只改菜谱，厨师还是那个水平，再好的菜谱也执行不到位
ScienceBuddy 的做法是：先固定厨师，改菜谱（让菜谱适应当前厨师的能力）。再固定菜谱，练厨师（让厨师在好菜谱下练习）。然后厨师变强了，再改菜谱（因为现在可以设计更复杂的菜谱了）。
这个交替过程的关键洞察是：菜谱和厨艺是耦合的，但不是同时耦合的。 改菜谱时需要一个稳定的厨师来评估菜谱好坏，练厨师时需要一个稳定的菜谱来收集干净的训练信号。
关键实验数据
论文在四个科学任务族上测试：文献阅读（LitQA2）、数据库问答（DbQA）、实验协议排错（ProtocolQA）、GWAS 因果基因定位。共 895 个任务。
三轮共进化结果
| 指标 | 改进前 | 改进后 | 提升 |
|---|---|---|---|
| 整体准确率 | 42.2% | 73.3% | +31.1pp |
| 问题覆盖率（pass@4） | 48.3% | 67.8% | +19.5pp |
| 正确→错误退化率 | — | 2.2% | 极低 |
73.3% 的准确率中，33.3% 的问题是"从错变对"，只有 2.2% 是"从对变错"。这意味着改进几乎不会带来退化——这是一个非常重要的安全性质。
拆解实验：单独看两层递归的效果
只改 harness（模型固定）：验证集准确率从 31.1% → 51.1%，提升 20 个百分点。最终选出的 harness 包含 4 条指令条目和 9 个作用域技能，涵盖 Python 执行、资源检查、记录查找、答案提交等。
只练模型（harness 固定）：问题覆盖率从 48.3% → 67.8%，提升 19.5 个百分点。在相同的 harness 和尝试预算下，模型能解决更多不同的问题。
两层各自贡献约 20pp，组合起来贡献 31pp——说明两者有协同效应但不是简单叠加。
工程洞察
1. 分离关注点比统一优化更有效
这是论文最重要的工程洞察。把 harness 搜索和模型训练分开做，各自有干净的优化目标和评估信号。如果同时改两者，你无法知道是 harness 的改动导致了性能变化，还是模型的改动导致的——优化信号被污染了。
这和 CritICL 的"失败模式跨尺度一致性"是同一个道理：分工比统一更有效。 小模型犯错、大模型分析、大模型受益——每个环节有明确的职责。ScienceBuddy 是 harness 改进、模型训练、交互收集——同样每个环节有明确的职责。
2. harness 是可执行的 Python 程序，不是自然语言 prompt
ScienceBuddy 的 harness 不是一段 prompt 文本，而是一个完整的 Python 程序，包含 run(task, api) 接口。这意味着 harness 可以做任何 Python 能做的事：条件分支、循环、异常处理、状态管理。
候选 harness 由辅助模型（GPT-6 Astra）生成，必须引用至少两个训练任务的证据。结构验证要求同步 run(task, api) 接口，拒绝已知的无效指令模式。字节相同的程序被排除。每个候选在隔离的控制器容器中执行。
这套设计让 harness 搜索变成一个有约束的程序合成问题，而不是模糊的 prompt 工程问题。
3. 反馈信号的分层设计
ScienceBuddy 区分了两种反馈：
- 诊断反馈（diagnostic score \(q_t \in \{-1, 0, +1\}\)）：用于 harness 改进，由反馈解释器生成
- 轨迹奖励（trajectory reward \(R_x(\tau)\)）：用于模型 RL，由验证器独立评估
这两者不混用。诊断反馈帮助 harness 反思器理解"为什么错了"，但不直接作为 RL 奖励。轨迹奖励是干净的标量信号，不受诊断反馈污染。
这种分层设计和"判断-闸门解耦"是同构的：判断（诊断反馈）和行动（RL 奖励）是分离的两个模块，各自有独立的信号通路。
4. 改进机制本身不改进
论文明确指出："its reflector remains fixed, so improved task performance does not imply that the improvement mechanism itself has become stronger."
这是一个重要的安全设计。辅助模型（GPT-6 Astra）和反馈解释器是固定的，不随系统改进而改进。如果改进机制本身也在改进，就会形成失控的正反馈循环——这正是 Aspire 论文发现的"自演化正反馈失败循环"。
ScienceBuddy 通过固定改进机制，避免了"越优化 proxy，离真实能力越远"的陷阱。
开源代码
论文配套开源了实验代码：Gen-Verse/ScienceBuddy
仓库包含：
src/simple_scibuddy/：简化版 Agent 实现，包含实验 harness、执行 broker、验证器和 SkyRL 适配器docs/algorithm.md：双层递归 RSI 算法详细文档docs/experiments.md：实验配置、任务划分、复现指南
实验使用 Qwen3.5-4B 作为任务模型，冻结的 715 训练 / 90 验证 / 90 测试任务集，三个 harness/RL 循环。每个 harness 阶段 3 步，每步 16 个训练交互和 3 个候选提案。每个 RL 阶段 30 个 GRPO 更新。
注意：仓库不包含 ScienceBuddy 产品的前端和 API 服务，只有实验代码。产品可在 science-buddy.io 体验。
个人思考
和 Aspire 的对比：为什么 ScienceBuddy 的自我改进能工作？
Aspire 论文发现，在模糊目标下，weight-level 自演化几乎不工作——越优化 proxy，离真实能力越远。ScienceBuddy 的自我改进能工作，关键区别在于：
- 有验证器：ScienceBuddy 有一个独立的科学验证器，提供干净的轨迹奖励。Aspire 依赖自我评估，而自我评估和真实能力之间的 gap 会随优化放大。
- 分离两层：ScienceBuddy 把 harness 和 model 分开改进，各自有干净的优化信号。Aspire 混在一起改，信号污染。
- 固定改进机制：ScienceBuddy 的 reflector 不改进，避免了正反馈失控。Aspire 的自我评估也在演化，形成正反馈循环。
这三点构成了一个完整的解释：自我改进要工作，需要干净的信号、分离的优化、固定的改进机制。 缺一不可。
"分工比统一更有效"再添一例
ScienceBuddy 是这个概念谱系的又一个实例：
- CritICL：小模型犯错、大模型分析、大模型受益
- 弱模型引导：弱模型给强模型当前缀教练
- ScienceBuddy：harness 改进、模型训练、交互收集
每个案例都是把一个看似统一的任务拆成多个职责明确的子任务，各自有独立的优化目标。统一优化看起来优雅，但分工优化更有效。
对 AI Agent 工程的启示
ScienceBuddy 给 AI Agent 工程师的一个直接启示是：不要只改 prompt，也不要只微调模型，要交替改两者。
具体来说：
- 先固定模型，搜索更好的 harness（prompt + 工具编排 + 上下文管理）
- 用选出的 harness 收集训练数据，做 RL 微调
- 用更新后的模型重新搜索 harness
- 循环
这个流程比单独做 prompt engineering 或单独做 RLHF 更有效，因为两者有协同效应。但前提是你需要一个验证器来提供干净的训练信号——在科学领域这相对容易（有标准答案），在开放领域可能需要更多设计。
一个值得警惕的边界
ScienceBuddy 的改进机制本身不改进（reflector 固定），这是一个关键的安全设计。如果未来有人让改进机制也自我改进，就需要非常小心正反馈失控的风险。Aspire 已经展示了这个风险——自我评估和真实能力的 gap 会随优化放大，形成"越优化越差"的悖论。
ScienceBuddy 的做法是：让系统改进，但不让改进系统改进。 这和人类社会的很多设计是一致的——法律系统可以改进社会，但法律系统本身的改进需要更谨慎的程序，不能和法律执行混在一起。
论文与代码
讨论回复
加载中...正在加载回复...
推荐
智谱 GLM-5 已上线
我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。