1. 科研 Agent 的可靠性困局与破局思路做科研辅助类 Agent 的人大概都有过这种体验Demo 阶段惊艳四座一旦丢进真实的科研工作流里跑上两三天输出质量就开始肉眼可见地滑坡。文献综述越写越水实验设计开始重复自己代码调试环节甚至会把之前已经修好的 bug 重新引入。这不是模型能力不够而是整个 Agent 的运行框架出了问题。ScienceBuddy 这个项目之所以值得拿出来单独拆解核心就在于它没有去卷模型本身而是把力气花在了Agent Harness这一层。所谓 Harness直译是马具在 Agent 语境里指的是包裹在模型外面、负责调度、约束、评估、反馈的那一整套运行框架。很多人把 Harness 和 Agent 混为一谈其实两者的关系更像是赛车手和赛车调校系统——模型是车手Harness 决定了车手在什么赛道上跑、什么时候进站、跑偏了怎么拉回来。一个设计糟糕的 Harness会让再强的模型也发挥不出三成功力。ScienceBuddy 提出的双层递归自进化机制本质上是在解决一个非常具体的问题科研任务的周期长、反馈稀疏、评价标准模糊传统的单轮 prompt 优化或者简单的反思循环根本撑不住。它把进化拆成了两层——外层进化的是技能库内层进化的是执行策略两层之间通过递归调用形成闭环。再配合Scoped Skill做技能的边界约束用GRPO做策略优化整个系统在长周期任务上的稳定性有了质的提升。这篇文章适合三类人看一是正在做 Agent 应用、被长周期任务稳定性折磨的工程师二是对科研自动化感兴趣、想了解 Harness 层设计思路的研究者三是听说过 GRPO 但不太清楚它在实际系统里怎么落地的人。我会尽量把每个设计决策背后的为什么讲透而不是只罗列架构图。2. 双层递归自进化到底在进化什么2.1 为什么单层进化撑不住科研任务先说清楚一个前提科研任务和普通的问答任务在结构上有本质区别。普通任务是一问一答反馈即时错了重来成本很低。科研任务是提出假设—设计实验—执行—分析—修正假设的长链条中间任何一环出问题可能要跑几个小时甚至几天才能发现。这种稀疏反馈特性决定了如果 Agent 只在单层做进化会面临两个死结。第一个死结是信用分配问题。假设一个文献调研任务跑了 50 步最后结论有偏差你很难判断到底是第 12 步的检索策略错了还是第 30 步的筛选标准太宽还是第 45 步的归纳逻辑有漏洞。单层进化只能把整个链条当成一个整体去优化梯度信号被稀释得几乎为零。第二个死结是技能复用问题。科研工作流里有大量可复用的原子能力比如从 PDF 里抽取实验参数判断两篇论文的方法是否可比生成可执行的统计分析代码。如果每次任务都从零开始这些能力就浪费了。但如果直接把技能硬编码进 prompt又会遇到技能之间互相干扰、边界模糊的问题。ScienceBuddy 的双层设计正是冲着这两个死结去的。外层负责沉淀和迭代可复用的技能单元内层负责在具体任务中组合和调度这些技能。两层各自有独立的进化信号互不干扰又能互相喂养。2.2 外层进化技能库的沉淀与淘汰外层进化的对象是技能库。每个技能在 ScienceBuddy 里被封装成一个Scoped Skill这个Scoped是关键词意思是每个技能都有明确的适用边界——什么输入格式、什么任务类型、什么前置条件、什么输出规范全部写死在技能定义里。我实测下来这个边界约束是整套系统里最容易被低估的设计。早期我也试过让技能定义写得宽松一点想着通用性更强结果就是技能之间疯狂打架。一个文献摘要技能和一个方法对比技能如果边界不清晰Agent 在调度时就会反复横跳一会儿摘要一会儿对比最后输出四不像。加上 Scope 约束之后调度器能明确知道当前这一步该用哪个技能冲突率直接降了一个数量级。外层进化的触发条件通常是跨任务的模式识别。系统会定期扫描历史任务日志找出那些反复出现的、当前技能库覆盖不好的场景。比如发现最近 20 个任务里有 8 个都卡在从图表中提取数值这一步就会触发一个新技能的孵化流程。孵化出来的候选技能要经过一轮验证——在历史任务上回放看它能不能真的提升成功率——通过了才正式入库。淘汰机制同样重要。技能库不是只进不出的那些调用频率低、成功率低、或者被新技能完全覆盖的旧技能会被标记为 deprecated。我个人的经验是技能库的规模控制在 30 到 50 个之间比较健康太少覆盖不足太多调度器会犯选择困难症。2.3 内层进化执行策略的实时调整内层进化的对象是执行策略具体来说就是在给定任务下如何选择技能、如何排列顺序、如何分配计算预算。这一层用的是GRPOGroup Relative Policy Optimization来做优化。GRPO 和传统的 PPO 相比最大的区别在于它不需要一个独立的 value network 来估计基线。它的做法是对同一个 prompt 采样一组group输出用这组输出的平均奖励作为基线然后计算每个输出的相对优势。这个设计在 Agent 场景下特别香因为 Agent 的奖励信号本来就稀疏且噪声大单独训一个 value network 又贵又不稳GRPO 直接用组内相对比较省掉了这一大块开销。在 ScienceBuddy 里内层进化的具体流程是这样的给定一个科研任务策略网络会生成多条执行轨迹比如 8 条每条轨迹是一串技能调用序列。这些轨迹跑完之后用任务级的奖励函数打分——奖励可能来自最终输出的质量评估、中间步骤的合规性检查、以及资源消耗的惩罚项。然后 GRPO 用这 8 条轨迹的相对表现来更新策略让好的序列模式被强化差的被抑制。这里有个实操细节值得说组的大小不能太小也不能太大。太小比如 2 到 3 条相对优势的估计噪声太大策略会抖太大比如 32 条以上计算成本爆炸而且边际收益递减。我试过 4、8、16 三档8 是比较稳的甜点区具体还要看任务的单次执行成本。2.4 两层之间怎么递归双层之所以叫递归是因为两层之间不是简单的上下级关系而是会互相触发。内层在执行任务时如果发现某个技能反复失败会把这个信号上报给外层触发技能修订或新技能孵化。外层孵化出新技能后又会更新内层的可选动作空间内层需要重新学习如何在新空间里调度。这个递归关系如果处理不好会陷入震荡——外层刚改完技能内层还没学会用外层又根据内层的糟糕表现去改技能越改越乱。ScienceBuddy 的做法是给两层设置不同的进化频率内层每个任务批次更新一次外层每 N 个批次比如 50 个才更新一次。这样内层有足够的时间去适应外层的变更避免了两层同时抖动。3. Scoped Skill 的设计细节与实操要点3.1 一个合格 Scoped Skill 应该包含什么Scoped Skill 不是简单的 prompt 模板它是一份完整的技能契约。我拆解了 ScienceBuddy 里几个典型技能总结出一份合格技能定义应该包含的字段字段作用是否必填skill_id唯一标识用于日志追踪和版本管理必填scope适用边界包含输入类型、任务类型、前置条件必填preconditions执行前必须满足的状态检查必填procedure具体的执行步骤可以是 prompt 也可以是代码必填output_schema输出的结构化规范必填failure_modes已知的失败模式及对应的降级策略推荐cost_estimate预估的 token 消耗和执行时间推荐version版本号配合外层进化做灰度必填其中scope和failure_modes是最容易被写烂的两个字段。scope 写得太宽技能会越界写得太窄技能复用率上不去。我的经验是scope 应该描述这个技能在什么情况下一定能work而不是可能能work。宁可窄一点让调度器多组合几个技能也不要宽到让技能自己去做判断。failure_modes 则是很多人的盲区。科研任务里失败是常态一个技能如果没有预设的降级路径一旦失败整个任务链就断了。比如从 PDF 抽取表格这个技能如果 PDF 是扫描件没有文字层就应该降级到 OCR 路径而不是直接报错。3.2 技能边界怎么划才不打架技能边界划分是门手艺。我踩过的坑是一开始按功能划分结果数据清洗和特征工程两个技能在边界上大量重叠调度器经常选错。后来改成按输入输出契约划分问题就解决了。具体来说划分原则有三条第一条输入类型唯一。一个技能只接受一种主输入类型。文本归文本表格归表格代码归代码。如果确实需要处理混合输入就拆成两个技能中间加一个转换技能。第二条输出可验证。每个技能的输出必须能被自动验证要么是结构化 schema 校验要么是单元测试。不能验证的输出等于没有输出因为调度器无法判断这一步是否成功。第三条单一职责。一个技能只做一件事。我见过有人把检索筛选摘要塞进一个技能结果这个技能的成功率永远上不去因为三个环节任何一个出问题都会拉低整体成功率而且失败原因无法定位。3.3 技能库的版本管理与灰度技能库一旦上了规模版本管理就是刚需。ScienceBuddy 的做法是每个技能独立版本化外层进化产生的新版本先进入影子模式——在真实任务里并行执行但不影响主流程收集足够的对比数据后再决定是否转正。这个影子模式的设计非常实用。我自己的项目里也借鉴了这套新技能上线前先跑 100 个历史任务做回放成功率比旧版本高 5 个百分点以上才允许转正。低于这个阈值就打回重做避免技能库被劣质技能污染。灰度发布的时候要注意一点新旧技能不能同时被调度器选中。否则同一个任务里可能一半用旧技能一半用新技能结果无法归因。正确的做法是给调度器加一个开关在灰度期间强制走新技能或旧技能对比完再切换。4. GRPO 在 Harness 里的落地细节4.1 奖励函数怎么设计才不跑偏GRPO 的效果高度依赖奖励函数的设计。科研任务的奖励函数比游戏、代码生成这些场景难设计得多因为好的标准很模糊。ScienceBuddy 用的是多信号加权的方案把奖励拆成几个可量化的维度任务完成度最终输出是否满足任务要求用规则或小模型判定权重 0.4中间步骤合规性每一步是否符合技能契约权重 0.2资源效率token 消耗和执行时间做归一化后作为惩罚项权重 0.2输出质量用另一个模型做质量打分权重 0.2这个权重不是拍脑袋定的是做了几轮消融实验调出来的。我一开始把输出质量权重设到 0.5结果策略学会了讨好评分模型——输出写得很漂亮但实际没用。后来把完成度权重提上来策略才回到正轨。奖励函数还有一个坑是奖励黑客。Agent 会找到各种钻空子的方式比如把输出写得特别长来刷质量分或者跳过中间步骤直接给结论来省 token。防御方法是给每个维度设置上下限超出范围的部分不计分同时定期人工抽检发现异常模式就调整奖励函数。4.2 组采样与优势估计的实操参数GRPO 的核心是组内相对优势。具体计算是这样的对同一个任务采样 G 条轨迹每条轨迹得到奖励 r_i然后优势 A_i (r_i - mean(r)) / std(r)。这个归一化很关键它让不同任务的奖励尺度统一避免高奖励任务主导梯度。实操参数方面我整理了一份参考配置参数推荐值说明group_size8太小噪声大太大成本高kl_coef0.01~0.05控制策略偏离参考模型的程度clip_ratio0.2和 PPO 一致防止单步更新过大learning_rate1e-6~5e-6Agent 场景下学习率要小batch_tasks16~32每个 batch 包含的任务数kl_coef 这个参数特别值得说。设得太小策略会快速偏离参考模型输出变得不可控设得太大策略几乎不更新进化停滞。我的经验是从 0.02 起步观察训练曲线如果 KL 散度持续上升就调大如果策略更新幅度太小就调小。4.3 训练稳定性问题的排查GRPO 训练过程中最常见的问题是奖励不升反降或者剧烈震荡。我遇到过几次排查下来原因基本集中在三类第一类是奖励函数本身有 bug。比如某个维度的计算依赖了未初始化的变量导致奖励值随机波动。排查方法是把每条轨迹的奖励拆解打印出来看哪个维度异常。第二类是组内轨迹差异太小。如果 8 条轨迹几乎一模一样优势估计就退化成噪声。这通常是因为策略的探索性不足解决方法是提高采样温度或者在策略里加熵正则项。第三类是任务难度分布不均。如果 batch 里既有超简单的任务又有超难的任务简单任务的奖励会主导梯度难任务学不到东西。解决方法是做难度分层采样保证每个 batch 里任务难度分布均匀。5. 完整实操流程与关键环节复现5.1 环境搭建与依赖准备复现 ScienceBuddy 这套 Harness环境准备阶段有几件事必须先做。首先是日志系统这是整套系统的地基。Agent 的每一步调用、每一次技能选择、每一个奖励信号都必须结构化落盘。我推荐用 JSONL 格式每行一条记录字段包含 task_id、step_id、skill_id、input、output、reward、timestamp。没有这套日志后面的进化分析全是空谈。其次是技能注册中心。可以用简单的文件系统实现每个技能一个目录目录里放 skill.yaml技能定义和 procedure.py执行逻辑。注册中心负责加载、校验、版本管理。我实测下来文件系统方案在技能数量 100 以内完全够用超过 100 再考虑上数据库。第三是奖励评估模块。这个模块要独立于 Agent 主流程因为评估本身可能很重比如调用另一个模型打分。独立出来之后可以异步执行不阻塞主流程。5.2 技能孵化与验证的完整流程技能孵化的触发到上线完整流程分五步第一步模式挖掘。扫描最近 N 个任务的日志统计失败步骤的分布。如果某个失败模式出现频率超过阈值比如 15%就标记为候选孵化目标。第二步技能草拟。用一个大模型根据失败模式生成技能定义草稿包括 scope、procedure、output_schema。这一步的质量参差不齐需要人工审核。第三步历史回放。把草稿技能放到历史任务上跑对比使用前后的成功率。这一步要注意控制变量只替换目标步骤其他步骤保持不变。第四步影子运行。通过回放验证的技能进入影子模式在真实任务里并行运行收集至少 100 个样本。第五步转正或淘汰。影子运行的成功率显著高于现有方案就转正否则淘汰并记录失败原因供下一轮孵化参考。这个流程走下来一个技能从发现到上线大概需要 3 到 5 天。听起来慢但比拍脑袋加技能靠谱得多。5.3 内层策略训练的实操记录内层策略训练我用一个文献调研任务做了完整记录。任务要求是给定一个研究主题检索近三年相关论文归纳主要方法流派指出研究空白。第一轮训练group_size8采样温度 0.8。8 条轨迹的成功率只有 2/8失败原因集中在检索关键词太宽导致噪声太多和归纳时把不同流派混在一起。奖励分布很分散优势估计噪声大。第二轮调整把检索技能拆成宽检索和精筛两个技能让策略有更细的粒度可选。同时把采样温度降到 0.6减少无效探索。这一轮成功率提升到 5/8奖励分布开始收敛。第三轮加入资源效率惩罚。之前策略倾向于用大量 token 去堆质量加了惩罚之后策略学会了用更少的步骤完成任务。成功率维持在 5/8 到 6/8但平均 token 消耗降了 40%。整个训练过程跑了大概 200 个任务批次策略才稳定下来。这里要提醒一句不要指望几十个批次就能看到效果Agent 策略的搜索空间比普通 RL 任务大得多耐心是必须的。5.4 双层递归的联调要点两层联调是最容易出问题的环节。我的经验是联调前先把两层单独跑通并稳定再合到一起。单独跑的时候外层用固定的内层策略内层用固定的技能库各自调好参数。联调时第一个要解决的问题是信号传递。内层发现技能失败怎么把信号传给外层ScienceBuddy 用的是失败事件队列内层把失败事件写入队列外层定期消费。队列要做去重和聚合避免同一个技能的同类失败被重复上报。第二个问题是更新时序。前面说过外层更新频率要低于内层但具体低多少要看任务周期。如果单个任务要跑几小时外层可能每 20 到 30 个任务更新一次就够了。如果任务很快可以适当提高频率。第三个问题是回滚机制。外层更新后如果内层表现变差要能快速回滚到上一个技能库版本。这要求技能库做完整的版本快照回滚时原子切换。6. 常见问题与排查技巧实录6.1 技能调度冲突的排查调度冲突的表现是Agent 在同一个步骤反复切换技能或者选了明显不合适的技能。排查思路分三步先看技能 scope 是否有重叠。把冲突涉及的两个技能的 scope 拿出来对比如果输入类型、任务类型都一致那就是边界没划清需要重新划分。再看调度器的选择逻辑。如果 scope 没问题那就是调度器的打分函数有问题。打印出每个候选技能的得分看是不是某个特征权重过大导致误选。最后看上下文是否缺失。有时候调度器选错是因为它看不到足够的信息。比如它不知道前一步已经做过检索就会重复选检索技能。解决方法是把任务状态显式传给调度器。6.2 奖励震荡的定位方法奖励震荡是 GRPO 训练里的高频问题。定位方法我总结成一个速查表现象可能原因排查方法解决方向奖励周期性大幅波动学习率过大打印每步梯度范数降低学习率奖励缓慢下降KL 惩罚过强监控 KL 散度调小 kl_coef奖励突然崩塌奖励函数 bug拆解各维度奖励修复计算逻辑奖励长期不涨探索不足检查组内轨迹多样性提高采样温度奖励方差极大任务难度不均统计 batch 内任务难度难度分层采样这张表是我踩了无数次坑之后总结的基本覆盖了 80% 的震荡场景。剩下的 20% 通常是多个原因叠加需要逐个排除。6.3 长周期任务的断点续跑科研任务动辄跑几小时中途失败是常态。断点续跑能力是刚需但实现起来有几个坑。第一个坑是状态序列化。Agent 的中间状态不只是对话历史还包括技能库版本、策略网络参数、任务上下文。这些都要能序列化和反序列化。我建议用统一的 state 对象封装避免散落各处。第二个坑是幂等性。续跑时重新执行的步骤必须保证幂等否则会产生重复副作用。比如写入文件这种操作续跑时要先检查文件是否已存在。第三个坑是版本一致性。续跑时如果技能库或策略已经更新可能导致前后行为不一致。解决方法是把版本号写进 checkpoint续跑时强制使用相同版本。6.4 几个我踩过的坑和对应技巧第一个坑技能库膨胀。早期我贪多什么技能都往里加结果调度器选择困难成功率反而下降。后来定了规矩新技能必须证明比现有组合方案好 10% 以上才允许入库技能库规模稳定在 40 个左右。第二个坑奖励函数过拟合。有一段时间奖励涨得很好但人工评估发现输出质量没提升。排查发现是奖励函数被策略破解了。解决方法是定期用留出任务集做验证奖励函数只在训练集上优化验证集上的表现才是真实水平。第三个坑外层进化过于激进。有次外层一次性替换了 5 个技能结果内层策略完全懵了成功率断崖式下跌。后来改成每次最多替换 1 个技能给内层足够的适应时间。第四个坑日志爆炸。全量日志一天能写几十 GB磁盘很快满了。解决方法是分级记录正常步骤只记摘要异常步骤记全量同时设置日志轮转和压缩。7. 一些个人体会这套双层递归自进化的架构我前后复现加改造花了大概两个月。最大的感受是Agent Harness 的复杂度被严重低估了。大家讨论 Agent 的时候总在聊模型能力但真正决定一个 Agent 能不能在生产环境跑起来的是 Harness 层的工程细节。技能边界怎么划、奖励函数怎么设计、两层怎么联调这些问题的难度一点不比调模型低。GRPO 在这个场景下确实好用尤其是它省掉了 value network 这一大块让整个训练流程轻量了很多。但它也不是银弹奖励函数设计不好GRPO 照样学不出东西。我的建议是先把奖励函数打磨到人工评估和自动评估高度一致再上 GRPO否则就是在噪声上做优化。Scoped Skill 的边界约束是我觉得最值得借鉴的设计。很多人做 Agent 喜欢追求通用性但通用性在长周期任务里往往是毒药。明确的边界反而能让系统更稳、更容易调试、更容易进化。这个思路其实不限于科研 Agent任何需要长期运行的 Agent 系统都可以参考。最后分享一个小技巧给技能库和策略网络都加上健康度监控。技能的健康度看调用成功率和使用频率策略的健康度看奖励趋势和 KL 散度。这两个指标一旦异常就说明系统在退化需要人工介入。我现在的项目里这套监控帮我提前发现了至少三次潜在的系统性故障省下了大量排查时间。