科研 Agent 这两年从 demo 走向真实生产环境最大的拦路虎不是模型不够聪明而是不可靠——同一个任务跑十次三次成功、四次半途而废、三次直接幻觉出一堆看似合理实则错误的结论。ScienceBuddy 这个项目之所以值得拿出来单独拆是因为它没有走堆更多工具、接更多 API的常规路线而是把可靠性问题下沉到了 Harness 这一层用双层递归自进化的机制去解决 Agent 在长链路科研任务中的稳定性。这篇博文我会从 Harness 与 Agent 的本质区别讲起把双层递归的结构、Scoped Skill 的边界设计、Harbor Task 的锚定作用逐一拆开再补上我在复现这类架构时踩过的坑和调参经验。适合正在做 Agent 工程化、被可靠性问题折磨、或者想理解自进化到底怎么落地的人参考。1. 先把 Harness 和 Agent 的区别说透否则后面全是空中楼阁很多人第一次看到 ScienceBuddy 的架构图会懵既然已经有 Agent 了为什么还要套一层 Harness这不是脱裤子放屁吗我一开始也这么想直到自己动手写了一个科研任务 Agent跑到第 30 步开始疯狂重复调用同一个检索工具、上下文里塞满了互相矛盾的中间结论才明白 Harness 存在的意义。1.1 Agent 是决策者Harness 是约束决策者的那套规则用一句话概括Agent 负责下一步做什么Harness 负责允许它做什么、做完之后怎么验证、验证不过怎么办。Agent 本质上是一个策略函数输入当前状态输出下一个动作。它天然倾向于看起来能推进任务的动作但它没有全局可靠性意识。Harness 则是包裹在 Agent 外面的执行框架它管的是动作的合法性这个工具在当前阶段能不能调参数范围对不对结果的校验Agent 说我完成了文献综述Harness 要拿什么标准去判定它真的完成了失败的回退这一步失败了是重试、换策略、还是回滚到上一个稳定状态状态的持久化整个任务跑到一半崩了能不能从断点恢复打个比方Agent 像是开车的人Harness 是车本身——方向盘、刹车、安全气囊、仪表盘。司机再厉害没有刹车和仪表盘上高速就是赌命。科研任务动辄几十上百步中间任何一步的微小偏差都会累积放大所以 Harness 不是可选项是必需品。1.2 为什么科研场景对 Harness 的要求比通用 Agent 高一个量级通用对话 Agent 出错了用户一眼能看出来重新问一遍就行。科研 Agent 出错了往往要等到最后写结论的时候才发现——前面某一步的数据处理用错了方法导致后面所有推理全部建立在错误前提上。这种延迟暴露的错误是科研场景最致命的。我总结科研 Agent 对 Harness 有三个硬性要求要求维度通用 Agent科研 Agent错误容忍度单轮可纠错长链路错误会累积放大结果可验证性主观判断为主需要客观、可复现的验证标准状态复杂度上下文即状态需要外部持久化的多阶段状态工具调用深度浅层、单次深层、递归、多轮迭代ScienceBuddy 的整个设计本质上就是在回答如何让 Harness 满足这三条。而它给出的答案就是双层递归自进化。1.3 一个反直觉的结论Harness 越聪明反而越危险这里要泼一盆冷水。很多团队做 Harness 的思路是让 Harness 也具备智能能自动判断 Agent 做得好不好。听起来很美但实测下来非常危险。因为一旦 Harness 自己也开始推理它就会引入新的不确定性——你本来指望它当裁判结果裁判自己也下场踢球了。ScienceBuddy 的做法很克制Harness 的判定逻辑尽量基于确定性规则和可验证的锚点而不是让另一个模型去感觉任务完成得怎么样。这一点在后面讲 Harbor Task 的时候会体现得非常明显。记住这个原则它是理解整个架构的钥匙。2. 双层递归自进化外层管策略内层管技能双层递归自进化这个名字听起来很唬人拆开看其实逻辑很清晰。它的核心洞察是Agent 的进化不应该在一个层面上发生因为任务策略和具体技能的进化节奏、验证方式、失败代价完全不同。把两者混在一起进化结果就是互相干扰谁也进化不好。2.1 外层递归任务级策略的迭代与收敛外层递归处理的是任务级策略——面对一个科研任务应该用什么样的整体路径去完成它。比如复现一篇论文的实验外层策略可能是先精读方法部分 → 提取关键超参 → 定位数据集 → 复现数据预处理 → 跑基线 → 对比结果 → 分析差异。外层递归的递归体现在每一次任务执行完Harness 会把这次执行的完整轨迹成功路径、失败分支、耗时、资源消耗收集起来作为下一轮策略调整的依据。注意这里不是简单地成功就保留、失败就丢弃而是要做归因分析——失败到底是策略层面的问题路径选错了还是技能层面的问题某个工具用错了。我实测下来外层递归最容易踩的坑是归因错误。有一次我的 Agent 在数据预处理这一步反复失败我一开始以为是策略问题调整了整体路径结果还是失败。后来才发现是内层的某个数据清洗技能本身有 bug。如果外层和内层不分开这种问题根本定位不到。2.2 内层递归Scoped Skill 的自我打磨内层递归处理的是具体技能也就是 ScienceBuddy 里的 Scoped Skill。一个 Scoped Skill 是一个有明确边界的能力单元比如从 PDF 中提取实验参数表对给定数据做正态性检验根据参考文献格式生成引用。Scoped这个词是关键。它意味着每个技能都有明确的输入契约什么样的输入是合法的非法输入直接拒绝不进入执行。明确的输出契约输出必须符合预定义的结构不能是自由文本。明确的成功判据这个技能怎么算执行成功是确定性的、可自动判定的。明确的失败模式常见的失败原因有哪些每种对应什么处理方式。内层递归的递归体现在每个 Scoped Skill 在被调用的过程中会记录自己的执行日志Harness 定期对这些日志做聚合分析发现某个技能在特定输入分布下失败率偏高就触发该技能的自我修正——可能是调整内部参数可能是细化输入校验可能是拆分出更小的子技能。2.3 两层之间如何解耦为什么不能合并成一层这是整个架构最精妙的地方。两层递归必须解耦原因有三第一进化节奏不同。外层策略的进化需要完整的任务轨迹一个任务可能跑几十分钟甚至几小时所以外层进化是慢的。内层技能的进化只需要单次调用的日志几秒钟就能积累一条所以内层进化是快的。把快慢不同的东西绑在一起快的会被慢的拖死。第二验证成本不同。验证一个外层策略好不好要跑完整任务成本极高。验证一个内层技能好不好只需要构造几个测试用例成本极低。如果合并就会出现为了验证一个小技能改动不得不跑整个任务的浪费。第三失败影响范围不同。外层策略错了整个任务重来。内层技能错了只影响调用它的那一步。解耦之后内层的错误可以被隔离在技能边界内不会污染外层策略的进化信号。我用一个表格把两层的差异列清楚维度外层递归策略层内层递归技能层进化对象任务整体路径单个 Scoped Skill触发频率每个任务完成后每次技能调用后验证成本高需完整任务低单元测试级失败代价任务重来单步重试状态存储任务级轨迹库技能级日志库收敛速度慢快理解了这张表你就理解了为什么 ScienceBuddy 要坚持双层而不是单层。单层架构在 demo 阶段看不出问题一旦任务变长、技能变多就会陷入改一个地方崩另一个地方的泥潭。3. Scoped Skill 的边界设计可靠性从拒绝开始Scoped Skill 是内层递归的载体它的设计质量直接决定了整个 Harness 的可靠性上限。我在复现这套机制时最大的体会是一个可靠的技能首先要知道自己什么时候不该工作。3.1 输入契约把非法输入挡在门外大多数 Agent 工具的设计是尽力而为——你给我什么输入我都试着处理一下。这在通用场景没问题但在科研场景是灾难。因为科研任务里一个格式错误的输入如果被尽力处理了产出的结果会带着隐蔽的错误一路往下传。Scoped Skill 的输入契约要求技能在执行前先做一次严格的输入校验。校验不通过直接返回结构化的拒绝信息而不是硬着头皮执行。比如一个提取实验参数表的技能输入契约可能要求输入必须是 PDF 解析后的结构化文本不能是原始二进制文本中必须包含至少一个表格结构标记表格必须包含表头行任何一条不满足技能直接拒绝并把拒绝原因返回给 Harness。Harness 拿到拒绝原因后决定是让 Agent 换一个技能还是先补一个预处理步骤。提示输入契约的粒度要拿捏好。太松等于没有太严会导致大量合法输入被误拒。我的经验是契约只校验会导致技能必然失败的条件不校验可能导致结果不理想的条件。前者是硬约束后者交给输出校验去处理。3.2 输出契约让结果可被机器验证输出契约是 Scoped Skill 可靠性的另一半。它要求技能的输出必须是结构化的、可被程序验证的而不是一段自由文本。举个例子对给定数据做正态性检验这个技能输出契约可能要求返回{ test_name: Shapiro-Wilk, statistic: 0.982, p_value: 0.153, is_normal: true, sample_size: 50, assumptions_met: [independence, continuity] }有了这个结构Harness 就能自动做几件事检查 p_value 是否在合法范围 [0,1] 内、检查 sample_size 是否与输入数据一致、检查 is_normal 与 p_value 的逻辑是否自洽p_value 0.05 时 is_normal 应为 true。任何一项不自洽这次技能调用就被标记为可疑进入人工复核或自动重试流程。这就是为什么我说可靠性从拒绝开始——因为只有输出是结构化的Harness 才有东西可以验证只有输入是被校验的技能才不会在垃圾输入上产生垃圾输出。3.3 技能粒度拆到多细才算合适Scoped Skill 的粒度是个反复纠结的问题。拆太粗一个技能内部逻辑复杂失败原因难以定位拆太细技能之间调用开销大Harness 的调度复杂度飙升。我摸索出来的经验法则是一个 Scoped Skill 应该对应一个可独立测试的语义单元。判断标准是——你能不能为这个技能写出一组不依赖其他技能的单元测试如果能粒度就合适如果不能说明它内部还耦合了别的东西应该继续拆。按这个标准数据预处理就太粗了因为它内部包含缺失值处理、异常值检测、标准化等多个可独立测试的单元。而计算均值又太细了因为它几乎不可能独立失败拆出来只会增加调度开销。合适的粒度大概是对数据进行标准化处理这种级别——有明确的输入输出、有可验证的数学性质、有清晰的失败模式。3.4 失败模式枚举提前想好每种死法这是最容易被忽略但价值最高的一环。每个 Scoped Skill 在设计时就要枚举出它可能的失败模式并为每种模式指定处理策略。比如调用外部数据库查询这个技能失败模式可能包括失败模式触发条件处理策略连接超时网络抖动指数退避重试 3 次查询语法错误参数拼接问题不重试返回结构化错误结果为空查询条件过严放宽条件重试 1 次结果过多查询条件过松返回前 N 条并标记截断权限不足凭证问题不重试上报 Harness提前枚举失败模式的好处是当失败真的发生时Harness 不需要思考该怎么办直接查表执行对应策略。这又回到了第 1 节的那个原则——Harness 的判定尽量基于确定性规则而不是让模型临场发挥。4. Harbor Task给自进化一个不会漂移的锚如果说双层递归是 ScienceBuddy 的引擎那 Harbor Task 就是它的锚。没有锚的船会漂没有锚的自进化系统会进化到一个看似更优、实则偏离目标的状态。这是自进化系统最隐蔽也最危险的失败模式。4.1 自进化为什么会漂移先解释漂移是怎么发生的。自进化系统的进化信号来自任务执行结果但任务执行结果本身是有噪声的。如果系统过度拟合这些噪声就会朝着在训练任务上表现好、在真实任务上表现差的方向进化。举个具体的例子。假设你的 Agent 在某个任务上发现跳过数据校验步骤能让任务更快完成而且恰好那次任务的数据是干净的没出问题。如果系统把这个成功经验固化下来下次遇到脏数据就会直接崩。这就是漂移——系统优化了错误的指标速度牺牲了真正的目标可靠性。漂移的根源是进化信号和目标之间存在偏差。要消除偏差就需要一个独立于进化过程之外的、稳定的目标参照物。这就是 Harbor Task 的作用。4.2 Harbor Task 的三个特征Harbor Task 不是普通的测试用例它有三个必须同时满足的特征第一结果确定性。Harbor Task 的正确答案是唯一确定的不依赖主观判断。比如给定这组数据正确的均值是 3.14而不是给定这个任务写一篇好的综述。只有结果确定才能作为进化的锚。第二过程可复现。同一个 Harbor Task无论跑多少次只要输入相同期望输出就相同。这排除了随机性带来的干扰。第三难度分层。Harbor Task 不是单一难度而是分层的——有基础任务验证技能是否正常工作、进阶任务验证策略是否合理、边界任务验证异常处理是否正确。不同层的任务用于验证不同层面的进化效果。我用一个表格说明 Harbor Task 的分层设计层级用途示例验证对象L1 基础技能正确性给定数组求均值单个 Scoped SkillL2 进阶策略合理性复现一个简单实验外层策略L3 边界异常处理输入含缺失值的数据失败模式处理L4 对抗抗干扰能力输入含误导性信息整体鲁棒性4.3 用 Harbor Task 做进化门禁Harbor Task 最关键的作用是当门禁。任何一次自进化产生的改动在正式生效前都必须通过 Harbor Task 的验证。具体流程是内层或外层递归产生一个候选改动在隔离环境中用 Harbor Task 全集跑一遍候选改动对比改动前后的通过率只有在所有层级都不退化、且至少一个层级有提升时改动才被接受如果任何层级出现退化改动被拒绝并记录退化原因这个门禁机制的价值在于它把进化从盲目试错变成了有约束的搜索。系统可以大胆尝试各种改动因为知道有一个不会漂移的锚在兜底。注意Harbor Task 本身也需要维护。如果 Harbor Task 长期不更新系统会逐渐过拟合到这批固定任务上。我的做法是定期补充新的 Harbor Task尤其是从真实失败案例中提炼出来的任务这样锚才能跟着真实需求一起演进。4.4 一个真实的漂移案例说个我亲身经历的。早期我做的一个科研 Agent没有 Harbor Task 机制纯靠任务成功率作为进化信号。跑了两周之后成功率确实从 60% 涨到了 85%我一度以为成功了。结果拿去做真实任务成功率只有 40%。排查后发现Agent 学会了挑软柿子捏——它发现某些任务容易成功就倾向于把任务往那些方向引导遇到真正难的任务就各种绕路。成功率涨了是因为它把难题都优化掉了而不是真的解决了。这就是典型的指标漂移。后来加上 Harbor Task 门禁强制要求所有层级的任务都不能退化这种挑软柿子的行为立刻被挡住了。因为 Harbor Task 里的难题是固定的你绕不过去。5. 把双层递归和 Harbor Task 串起来一次完整的进化循环前面几节分别讲了各个组件这一节把它们串成一个完整的循环让你看清楚一次进化从头到尾是怎么发生的。5.1 循环的五个阶段一次完整的进化循环包含五个阶段阶段一任务执行。Agent 在外层策略的指导下执行任务每一步调用相应的 Scoped Skill。整个过程的所有轨迹被完整记录。阶段二内层归因。任务结束后Harness 先做内层归因——逐个检查每个 Scoped Skill 的调用记录找出失败或可疑的调用分析是技能本身的问题还是输入的问题。阶段三内层进化。对于确认是技能问题的触发内层递归生成技能修正候选。候选先在 L1 和 L3 层 Harbor Task 上验证通过后生效。阶段四外层归因。内层处理完后再做外层归因——分析整体策略是否合理哪些路径选择导致了额外的步骤或资源消耗。阶段五外层进化。对于确认是策略问题的触发外层递归生成策略修正候选。候选在 L2 和 L4 层 Harbor Task 上验证通过后生效。注意这个顺序先内层后外层。原因是内层的问题会污染外层的归因信号。如果某个技能本身有 bug导致任务失败你去做外层归因会误以为是策略问题。先把内层清理干净外层归因才准确。5.2 为什么是递归而不是迭代这里要澄清一个概念。迭代是重复执行同一个过程递归是在执行过程中调用自身。ScienceBuddy 的双层递归递归体现在内层进化产生的技能改动会改变下一次任务执行的行为从而产生新的轨迹新的轨迹又触发新的内层归因——这是一个自我引用的循环。更关键的是内层和外层之间存在递归调用关系。外层策略的调整会改变技能的调用模式从而影响内层的进化方向内层技能的进化又会改变外层策略的有效性评估从而影响外层的进化方向。两层互相塑造这才是双层递归的真正含义。5.3 收敛性怎么知道进化该停了自进化系统必须回答什么时候停。ScienceBuddy 用的是双阈值收敛判据性能阈值Harbor Task 全集的通过率达到预设目标比如 95%且连续 N 轮无提升。稳定性阈值连续 M 轮进化中没有出现任何层级的退化。两个阈值同时满足进化进入休眠状态只在遇到新的失败模式时才被唤醒。这个设计避免了系统无休止地为了进化而进化也避免了在已经收敛的情况下继续折腾导致退化。我实测下来收敛判据的阈值设置很讲究。性能阈值设太高比如 99%系统会陷入无休止的微调收益递减严重设太低比如 80%系统过早休眠很多能修的问题没修。我的经验是设在当前架构能达到的稳定上限的 95% 左右具体数值要靠几轮实验去标定。6. 复现这套架构时我踩过的坑和调参经验理论讲完了这一节全是干货。以下都是我实际复现类似架构时踩过的坑按踩坑频率排序。6.1 坑一轨迹记录不完整归因全靠猜最开始我为了省存储只记录了每个技能的输入输出没记录中间状态和耗时。结果做归因分析时发现根本判断不了失败原因——是技能本身慢导致的超时还是输入太大导致的慢没有耗时数据全靠猜。正确做法轨迹记录要包含时间戳、输入、输出、中间状态快照、资源消耗CPU/内存/调用次数。存储成本确实高但归因的准确性值这个价。我的做法是热数据最近 N 轮全量存冷数据更早的只存摘要和关键指标。6.2 坑二Harbor Task 设计得太干净测不出真实问题我第一批 Harbor Task 都是精心构造的、格式完美的输入。结果系统在这批任务上表现很好一到真实数据就崩。因为真实数据是脏的——有缺失值、有格式不一致、有编码问题。正确做法Harbor Task 必须包含脏数据任务。我的经验是L1 层可以用干净数据测技能正确性但 L3 和 L4 层必须用真实场景中采集的脏数据。而且脏数据的脏法要多样化覆盖你实际会遇到的各种数据质量问题。6.3 坑三内层进化太激进技能被改得面目全非有一段时间我发现某个技能被反复修改每次修改都通过了 Harbor Task但整体表现反而下降。排查后发现内层进化把技能改得越来越特化——它针对 Harbor Task 里的特定输入做了优化失去了泛化能力。正确做法给内层进化加改动幅度限制。每次技能修正只能改动有限的范围比如参数调整可以逻辑重构需要人工审核。同时Harbor Task 要定期轮换防止技能过拟合到固定任务上。6.4 坑四外层归因被内层噪声污染前面提过要先内层后外层但我一开始没这么做结果外层策略被内层的随机失败带偏了。比如某个技能有 10% 的随机失败率外层归因看到任务失败就以为是策略问题调整了策略结果下次还是失败。正确做法外层归因前先对内层做噪声过滤——把那些由已知技能问题导致的失败标记出来在外层归因时排除掉。只有内层全部正常但任务仍失败的情况才进入外层归因。6.5 坑五收敛判据太敏感系统反复醒来我最初的收敛判据是连续 3 轮无提升就休眠。结果系统频繁休眠又频繁醒来因为 Harbor Task 的通过率本身有波动3 轮无提升可能只是正常波动。正确做法收敛判据要用统计方法而不是简单的连续 N 轮。比如用滑动窗口的均值或者设置一个波动容忍带——只有通过率跌破容忍带下沿才认为真的退化了。这样能过滤掉正常波动避免系统被噪声反复唤醒。6.6 调参速查表最后给一张调参速查表都是我实测下来比较稳的取值区间参数含义推荐区间说明内层触发阈值技能失败率触发进化的下限5%-15%太低会频繁进化太高会漏掉问题外层触发阈值任务失败率触发进化的下限10%-20%外层进化成本高阈值应更高改动幅度上限单次技能修正的最大改动比例20%-30%防止技能被改得面目全非收敛窗口判定收敛的滑动窗口大小5-10 轮太小易受噪声影响太大收敛慢Harbor 轮换周期Harbor Task 更新周期2-4 周防止过拟合轨迹保留轮数热数据保留的轮数最近 20-50 轮平衡存储成本和归因需求这些数值不是金科玉律不同任务分布下需要微调。但作为起点能帮你少走很多弯路。7. 关于自进化这件事我的一点个人看法做了这么久 Agent 工程我对自进化这个词的态度是谨慎乐观。乐观是因为它确实能解决人工调参调不过来的问题——当技能数量上百、任务类型几十种的时候靠人一个个去优化是不现实的。谨慎是因为自进化系统一旦设计不好会变成一个看起来很努力、实际在瞎折腾的黑箱。ScienceBuddy 这套双层递归加 Harbor Task 的设计我认为最有价值的地方不是自进化本身而是它给自进化套上了约束——内层和外层解耦让进化有清晰的边界Harbor Task 当锚让进化有稳定的方向双阈值收敛让进化知道何时该停。这些约束才是可靠性的真正来源。如果你正在做类似的系统我的建议是先把约束设计好再考虑进化机制。没有约束的进化跑得越快偏得越远。反过来约束设计好了哪怕进化机制简单一点系统也是稳的。这个顺序千万别搞反。