科研 Agent 这两年从 demo 走向能真正干活卡点早就不在模型本身而在外面那层壳——也就是大家最近常说的 Agent Harness。ScienceBuddy 这个项目有意思的地方在于它没有去卷基座模型而是把力气全花在 Harness 上用一套双层递归自进化的机制让 Agent 在科研任务里越跑越稳。我拿到这个标题的时候第一反应是双层递归到底递归在哪两层自进化的信号从哪来Scoped Skill 和 GRPO 又是怎么串起来的这篇就把这套架构从头到尾拆一遍顺带把 harness 和 agent 的区别、GRPO 在其中的角色讲清楚适合正在做 Agent 工程化、尤其是科研/长链路任务方向的同学参考。1. 先把 harness 和 agent 的区别说透不然全是空中楼阁很多人一上来就聊自进化结果连 harness 是什么都没搞明白最后做出来的东西既不像 agent 也不像 harness四不像。我先把这两个概念掰开。1.1 agent 是决策者harness 是决策者赖以生存的操作系统你可以把 agent 理解成一个坐在驾驶位上的人他负责看路、判断、打方向盘。而 harness 是整辆车——底盘、油门响应、刹车助力、仪表盘、安全带甚至包括副驾那个不断提醒你前面有坑的领航员。agent 决定往哪走harness 决定这个决定能不能被安全、可复现、可观测地执行出来。在 ScienceBuddy 里agent 是那个调用工具、读论文、写代码、跑实验的推理核心harness 则是包裹在它外面的一整套运行时工具注册与调度、上下文管理、状态持久化、失败重试、结果校验、以及最关键的——技能Skill的加载与进化。没有 harnessagent 就是一个裸奔的 LLM跑两步就上下文爆炸或者工具调用错乱。1.2 为什么科研场景对 harness 的要求远高于普通对话场景普通聊天 Agent 出错用户笑一笑重问一遍就完了。科研 Agent 出错代价是跑了一晚上的实验白跑、引用了不存在的文献、把错误结论写进报告。科研任务有三个特点直接拉高了 harness 的门槛链路极长一个复现某篇论文的实验任务可能包含检索、精读、环境搭建、代码改写、调参、结果对比十几个子步骤任何一步的状态丢失都会导致前功尽弃。工具异构要调 Python 解释器、要读 PDF、要访问数据库、要跑 shell工具之间的数据格式和错误语义完全不同。正确性难验证不像订机票这种有明确成功信号的任务科研中间结果对不对很多时候 agent 自己都判断不了需要 harness 提供额外的校验层。所以 ScienceBuddy 把重心放在 harness 上这个方向我认为是对的。模型能力是公共资源harness 才是拉开差距的地方。1.3 一个常见的认知误区把 harness 当成prompt 模板集合我见过不少团队所谓的 harness 就是一堆 system prompt 加几个 function calling 的 schema然后美其名曰框架。这不是 harness这是配置。真正的 harness 必须能回答这几个问题agent 中途崩了状态怎么恢复同一个技能在不同任务里怎么复用又不互相污染跑完一批任务后系统怎么知道哪个技能该改、怎么改ScienceBuddy 的双层递归自进化恰恰就是在回答最后这个问题。2. 双层递归自进化到底哪两层在递归进化信号从哪来这是整个项目最核心也最容易被讲玄乎的部分。我尽量用工程语言把它落地。2.1 第一层递归任务内的执行-反思-重试闭环第一层递归发生在单个任务内部。ScienceBuddy 的 agent 在执行一个科研任务时不是一条直线走到底而是每完成一个关键子步骤就触发一次轻量的自我反思当前结果是否满足该步骤的预期如果不满足是回退重做还是换一个技能这里的递归体现在反思本身也可能调用工具比如跑一个验证脚本而验证脚本的执行又走一遍完整的 harness 流程。也就是说执行流程会嵌套调用自身。这就是第一层递归的由来。关键设计点在于反思的粒度。粒度太粗整个任务跑完才反思错误会累积到无法定位粒度太细每一步都反思开销爆炸且容易陷入过度自我怀疑。ScienceBuddy 的做法是绑定在技能边界上——每完成一个 Scoped Skill 就反思一次这个粒度我认为是合理的后面会展开讲 Scoped Skill。2.2 第二层递归跨任务的技能进化循环第二层递归发生在任务与任务之间。当一批任务跑完后harness 会收集所有任务的执行轨迹trace分析哪些技能在哪些场景下失败了、失败模式是什么然后修改技能本身。修改后的技能进入下一批任务再次被检验、再次被修改。这就是自进化系统在改自己的组件。而它之所以也叫递归是因为技能的进化过程本身也是一个 agent 任务——系统用一个进化 agent去分析轨迹、生成新技能版本这个进化 agent 同样跑在 harness 上。于是 harness 在改进 harness 的组件形成第二层递归。两层递归的关系可以用一句话概括第一层负责把当前任务做对第二层负责让未来的任务更容易做对。第一层产生的高质量轨迹是第二层的燃料第二层进化出的好技能又反过来提升第一层的成功率。2.3 进化信号GRPO 在这里扮演什么角色自进化最怕的是越进化越差因为没有可靠的信号告诉系统这个新技能到底比旧的好在哪。ScienceBuddy 引入 GRPOGroup Relative Policy Optimization来解决信号问题。GRPO 的核心思想是不依赖一个绝对的价值评估器而是对同一个问题采样一组group输出用组内的相对表现作为奖励信号。放到技能进化场景里可以这样理解对同一个科研子任务用旧技能和新技能各跑若干次形成一组轨迹然后比较组内的成功率、步数、工具调用正确率等指标相对更好的那个版本获得正向信号。这样做的好处是绕开了绝对打分的难题。科研任务很难给一个绝对分数但新技能比旧技能在这批任务上成功率高 15%这种相对判断是可靠的。GRPO 天然适合这种相对比较的场景这也是它被选中的原因而不是随便挑了个 RL 算法。提示GRPO 的组采样会显著增加算力开销实践中要控制 group size 和采样任务数否则进化一轮的成本可能比训练一个模型还高。3. Scoped Skill让技能有边界才能被安全地进化如果技能是一个巨大的、什么都管的黑盒那自进化根本无从下手——你改一个地方不知道会影响到哪里。ScienceBuddy 用 Scoped Skill 解决这个问题。3.1 什么是 Scoped Skill为什么必须scopedScoped Skill 直译是有作用域的技能。一个 Scoped Skill 只负责一件边界清晰的事比如从 PDF 中抽取实验参数表、把一段伪代码转成可运行的 Python、对比两组实验结果的显著性。它有自己的输入契约、输出契约、依赖的工具集合、以及成功判定标准。为什么必须 scoped三个理由可测试边界清晰才能写单元测试才能判断它到底行不行。可组合小技能像乐高积木能拼出复杂流程而大黑盒只能整体替换。可进化进化时只动一个技能影响面可控出问题能快速回滚。我踩过的一个坑是早期把读论文并复现做成一个技能结果这个技能内部逻辑极其复杂失败时根本不知道是检索错了、理解错了还是代码写错了进化更是无从谈起。拆成 scoped 之后定位问题的时间从半天缩短到几分钟。3.2 Scoped Skill 的结构契约、实现、元数据三件套一个完整的 Scoped Skill 在 ScienceBuddy 里包含三部分组成部分内容作用契约Contract输入 schema、输出 schema、前置条件、后置条件定义这个技能承诺做什么实现Implementation具体的 prompt、工具调用序列、控制流定义怎么做到元数据Metadata版本号、历史成功率、适用场景标签、依赖关系支撑进化决策契约和实现分离是关键。进化时契约通常保持不变改的是实现。这样上层调用者不受影响进化的风险被限制在技能内部。元数据则是第二层递归的决策依据——系统根据历史成功率决定哪个技能优先被进化。3.3 技能之间的依赖与冲突进化时最容易翻车的地方技能不是孤立的。技能 A 的输出可能是技能 B 的输入如果进化 A 时改了输出格式B 就崩了。ScienceBuddy 用元数据里的依赖关系图来管理这个进化一个技能前先检查它的下游技能必要时做兼容性验证。另一个坑是技能冲突两个技能在相似场景下都能用但行为不一致。比如抽取表格和抽取文本在遇到半结构化 PDF 时可能都触发结果互相打架。解决办法是在元数据里标注适用场景标签让调度器根据场景精确匹配而不是靠模糊的语义相似度。4. 把两层递归和 Scoped Skill 串起来一次完整的进化是怎么发生的前面分开讲了机制这里给一个端到端的例子把整个链路走一遍这样你能看到各部件是怎么咬合的。4.1 场景设定一批复现论文实验的任务假设我们有一批 50 个任务都是给定一篇论文复现其核心实验。每个任务会被拆解成若干 Scoped Skill 的调用序列文献检索 → 参数抽取 → 环境搭建 → 代码生成 → 实验执行 → 结果对比。4.2 第一层递归在单个任务里的运转以第 7 号任务为例。agent 调用参数抽取技能抽出了学习率和 batch size。紧接着触发反思跑一个轻量校验检查抽出的参数是否在合理范围内。发现 batch size 抽成了 0.001明显是把学习率的值错填了。反思判定失败回退换用参数抽取的另一个版本重试这次成功。这个过程里反思调用的校验脚本本身也走了一遍 harness 的执行流程这就是第一层递归的体现。整个任务的轨迹被完整记录下来包括这次失败和重试。4.3 第二层递归如何消费这些轨迹50 个任务跑完后harness 汇总轨迹发现参数抽取技能在 12 个任务里都出现了类似的数值错填。于是触发第二层递归进化 agent 分析这 12 条失败轨迹发现共性是当论文里学习率和 batch size 相邻出现时容易混淆。进化 agent 生成新版本的参数抽取技能在实现里增加了先识别参数名再绑定数值的步骤。新技能进入下一批任务用 GRPO 做组内对比新版本在同类任务上的成功率从 68% 提升到 89%步数还减少了。这个相对优势被确认为正向信号新版本正式替换旧版本元数据里的版本号和成功率同步更新。4.4 这个链路里最容易被忽略的三个细节轨迹的完整性如果第一层没有把失败轨迹完整记下来第二层就没有燃料。很多团队只记成功轨迹结果进化无从谈起。进化的原子性一次只进化一个技能且必须能回滚。批量进化看起来高效实际上出问题时你根本不知道是哪个改动导致的。验证的独立性验证新技能的 GRPO 组采样必须用没参与进化的任务否则就是自己考自己数据泄漏会让进化结果虚高。5. 实操中真正会卡住你的几个问题理论讲完说点实际的。这套架构落地时坑基本都集中在工程细节上。5.1 上下文管理长链路任务的隐形杀手科研任务动辄几十步每步的工具返回都可能很长一篇 PDF 的解析结果轻松上万 token。如果无脑往上下文里塞很快就会超限。ScienceBuddy 的做法是按技能边界做上下文分段每个 Scoped Skill 执行完只把它的输出契约里定义的字段写回主上下文中间过程丢弃或存到外部存储。我自己的经验是这个只回写契约字段的规则极其重要。早期我图省事把工具原始返回全塞回去结果第 15 步就爆上下文而且模型被无关信息干扰决策质量明显下降。5.2 工具调用的幂等性重试机制的前提第一层递归里有重试重试的前提是工具调用幂等。如果实验执行技能不幂等重试就会重复跑实验浪费算力甚至污染结果。所以 harness 里每个工具都要标注是否幂等非幂等的工具在重试时要走先清理再重跑的流程。5.3 进化频率与稳定性的权衡第二层递归不能太频繁。每跑一批任务就进化一次会导致技能版本剧烈震荡系统永远处于不稳定状态。实践中建议设置一个最小样本量阈值比如某类失败累计超过 N 次才触发进化和冷却期让技能有足够时间被验证。5.4 GRPO 组采样的成本控制前面提过GRPO 的组采样很贵。控制手段有几个缩小 group size组内样本数、只在关键技能上做组对比、复用已有轨迹而不是全部重跑。我的建议是先用小规模验证 GRPO 信号是否可靠再逐步放大别一上来就全量跑。6. 我对这套架构的几点判断拆完 ScienceBuddy有几个判断想分享给正在做类似方向的同行。第一harness 的工程价值被严重低估。大家都在追模型但真正决定 Agent 能不能在科研这种硬场景落地的是 harness 的健壮性。双层递归自进化本质上是在给 harness 装一个自我修复的引擎这个思路值得借鉴。第二Scoped Skill 的边界划分是门手艺。划得太细调度开销大、组合爆炸划得太粗进化和测试都无从下手。我的经验是一个技能最好对应一个可独立验证的中间产物比如一张参数表、一段可运行代码而不是一个动作或一个阶段。第三GRPO 不是银弹。它解决了相对信号的问题但引入了采样成本。在技能数量不多、失败模式清晰的早期阶段用简单的规则统计比如成功率阈值可能比 GRPO 更划算。GRPO 更适合技能多、场景复杂、需要精细比较的中后期。第四自进化的安全阀必须有。系统改自己的组件一旦改错可能连锁反应。回滚机制、版本隔离、灰度发布这些在传统软件工程里是老生常谈在自进化 Agent 里同样是保命的东西。别因为自进化听起来高级就跳过这些基本功。最后分享一个我在做技能进化时的小技巧给每个技能版本打上进化来源标签记录它是从哪个失败模式、哪批任务里进化出来的。这样当某个版本出问题时你能快速定位到它的出身判断是进化方向错了还是场景变了。这个标签在调试阶段能省下大量时间。