1. 从“能跑”到“可靠”科研 Agent 的真实困境做过科研自动化的人都有一个共同体会让 Agent 跑起来不难难的是让它稳定地跑对。你写一个脚本调用大模型去读论文、提假设、跑实验、写报告Demo 阶段看起来很美一旦进入真实科研场景——文献量上千、实验周期跨天、中间步骤依赖外部工具返回——各种问题就冒出来了。幻觉引用、步骤跳漏、上下文爆炸、工具调用参数漂移每一个都能让整条链路崩掉。ScienceBuddy 这个项目核心要解决的就是这个问题。它不是又一个“套壳对话机器人”而是一套面向科研场景的 Agent Harness——注意是 Harness不是 Agent 本身。这个区分非常关键也是最近圈子里讨论“harness 和 agent 区别”的根源。Agent 是“干活的智能体”Harness 是“让智能体可靠干活的约束框架”。ScienceBuddy 的野心在于它试图用一套“双层递归自进化”机制让 Harness 本身也能随着任务执行不断变强。这篇文章我会从架构设计、核心机制、实操落地、踩坑排查四个维度把 ScienceBuddy 这套东西拆开讲透。适合正在做科研自动化、Agent 工程化、或者对 Agent Harness 设计模式感兴趣的读者。不管你是刚接触 Agent 的新手还是已经踩过一堆坑的老手应该都能从中拿到一些可以直接复用的思路。2. 先搞清楚Harness 和 Agent 到底差在哪2.1 一个类比赛车手和赛车调校团队很多人第一次听到 Agent Harness 会懵。我用一个类比来解释Agent 是赛车手Harness 是整个赛车调校团队加赛道规则。赛车手决定怎么开但能不能稳定跑完 500 圈取决于调校团队有没有把悬挂、轮胎、油路都调到位取决于赛道有没有清晰的边界和信号。具体到技术层面Agent 负责的是“决策与生成”——给定当前状态决定下一步做什么。Harness 负责的是“约束与编排”——定义 Agent 能做什么、不能做什么、做完之后怎么验证、验证不过怎么回退、多轮之间怎么保持状态一致。ScienceBuddy 把这两者做了严格分离。它的 Agent 层只关心科研任务本身的推理比如“这个假设是否成立”“下一步该做哪个实验”。而 Harness 层负责所有工程性的东西工具注册、权限控制、上下文裁剪、结果校验、失败重试、技能沉淀。2.2 为什么科研场景特别需要 Harness普通对话场景Agent 说错一句话用户重新问一遍就行。科研场景不行。一个实验流程可能涉及几十个步骤中间任何一步出错后面的结论全部作废。更麻烦的是科研任务往往有“不可逆”特性——你调用了一个外部计算资源、提交了一个任务、写入了一个数据库这些操作没法简单撤销。所以 ScienceBuddy 的设计哲学是Agent 可以犯错但 Harness 必须能兜住。这就引出了它的核心机制——双层递归自进化。2.3 Scoped Skill 和 Harbor Task 的定位在展开讲双层递归之前先把两个关键概念说清楚。Scoped Skill是 ScienceBuddy 里最小的可复用能力单元。一个 Scoped Skill 包含三部分触发条件、执行逻辑、验证规则。比如“从 PDF 中提取参考文献”就是一个 Scoped Skill它规定了什么情况下触发输入是 PDF 且需要文献列表、怎么执行调用解析工具加 LLM 抽取、怎么验证抽取结果必须符合引用格式且数量与原文匹配。Harbor Task则是更高一层的任务容器。一个 Harbor Task 可以包含多个 Scoped Skill它定义了完成一个完整科研子目标所需的全套流程。比如“复现某篇论文的核心实验”就是一个 Harbor Task它内部会调用文献解析、假设生成、实验设计、结果比对等多个 Scoped Skill。这两个概念的关系是Harbor Task 是“港口”Scoped Skill 是“停靠的船只”。港口负责调度和验收船只负责具体运输。3. 双层递归自进化核心机制拆解3.1 第一层递归Skill 级别的自我修正第一层递归发生在 Scoped Skill 内部。每次 Skill 执行完毕Harness 会拿执行结果和预设的验证规则做比对。如果验证不通过不是简单重试而是触发一次“技能修正”——分析失败原因调整执行逻辑然后重新执行。这里的关键设计是修正不是盲目的。ScienceBuddy 会记录每次失败的上下文包括输入特征、中间状态、错误类型。当同类失败累积到一定次数Harness 会生成一个新的 Skill 变体而不是反复用同一个逻辑撞墙。我举个例子。假设有一个 Skill 是“从实验数据中拟合曲线”。第一次执行用的是线性拟合验证发现 R² 只有 0.6不达标。Harness 不会直接重试线性拟合而是分析数据分布判断可能需要多项式拟合于是生成一个“多项式拟合”的 Skill 变体。如果多项式拟合也不行再尝试其他模型。这个过程是递归的——每次修正都基于前一次的结果逐步逼近可用方案。3.2 第二层递归Task 级别的流程重构第二层递归发生在 Harbor Task 层面。当 Task 内部的多个 Skill 组合执行时Harness 会监控整体流程的效率和质量。如果发现某个环节反复成为瓶颈或者某些 Skill 的组合方式导致冗余调用Harness 会触发流程重构。流程重构的具体表现包括调整 Skill 执行顺序、合并冗余步骤、替换低效 Skill、增加并行分支。比如原本是“先解析全部文献再逐个提取假设”重构后可能变成“解析一篇就提取一篇边解析边提取”减少内存占用和等待时间。这两层递归的关系是Skill 层递归保证单点可靠Task 层递归保证整体高效。两者叠加形成“双层递归自进化”。3.3 自进化的边界什么能变什么不能变这里必须强调一个工程上的关键约束自进化不是无限制的。ScienceBuddy 明确划定了可变和不可变的边界。可变的部分包括Skill 的执行逻辑、参数配置、组合方式、执行顺序。不可变的部分包括验证规则、安全约束、数据权限、输出格式标准。为什么这么设计因为如果验证规则也能被 Agent 自己改那就等于让考生自己出题自己判卷可靠性直接归零。ScienceBuddy 的做法是进化只发生在“怎么做”层面不发生在“什么算对”层面。这条边界是整套机制能成立的前提。4. 实操落地从零搭建一个可用的 Harness4.1 环境准备与依赖清单要复现 ScienceBuddy 的核心思路你不需要照搬它的全部代码但需要准备以下基础组件。组件作用推荐方案LLM 接口Agent 推理核心任意支持函数调用的模型接口工具注册中心管理 Scoped Skill自建注册表或轻量级插件框架状态存储保存执行上下文SQLite 或 Redis验证引擎执行结果校验规则引擎加自定义校验函数日志系统追踪递归过程结构化日志建议 JSON 格式环境准备阶段最容易踩的坑是过早引入复杂框架。我见过不少人一上来就搭分布式任务队列、上向量数据库、搞多机部署结果核心逻辑还没跑通光调试基础设施就耗掉一周。ScienceBuddy 的思路是先用最简组件跑通单机闭环再逐步扩展。4.2 定义第一个 Scoped Skill我们从一个最简单的 Skill 开始从文本中提取关键实体。这个 Skill 的触发条件是“输入为一段科研文本且需要结构化信息”执行逻辑是调用 LLM 做抽取验证规则是“抽取结果必须包含至少一个实体且格式符合预定义 schema”。class EntityExtractionSkill: def __init__(self, llm_client, schema): self.llm llm_client self.schema schema self.failure_history [] def execute(self, text): prompt f从以下文本中提取实体输出格式{self.schema}\n\n文本{text} result self.llm.call(prompt) return result def validate(self, result): if not result or entities not in result: return False, 缺少 entities 字段 if len(result[entities]) 0: return False, 未提取到任何实体 return True, 验证通过 def self_correct(self, text, failure_reason): self.failure_history.append(failure_reason) # 根据失败历史调整 prompt 策略 if 未提取到任何实体 in failure_reason: prompt f仔细阅读以下文本逐句分析提取所有可能的实体\n\n{text} return self.llm.call(prompt) return None这段代码的关键点在于self_correct方法。它不是简单重试而是根据失败原因调整策略。这就是第一层递归的雏形。4.3 组装 Harbor Task有了 Skill 之后下一步是把它组装成 Harbor Task。一个 Task 需要定义包含哪些 Skill、执行顺序、每个 Skill 的输入输出如何衔接、整体验证规则是什么。class HarborTask: def __init__(self, name, skills, validator): self.name name self.skills skills # 有序列表 self.validator validator self.execution_log [] def run(self, initial_input): state {input: initial_input, intermediate: []} for skill in self.skills: result skill.execute(state[input]) valid, reason skill.validate(result) if not valid: result skill.self_correct(state[input], reason) valid, reason skill.validate(result) if not valid: self.execution_log.append(f{skill.__class__.__name__} 修正后仍失败{reason}) return {status: failed, log: self.execution_log} state[intermediate].append(result) state[input] result # 链式传递 overall_valid, overall_reason self.validator(state) return {status: success if overall_valid else failed, state: state}这个 Task 的执行逻辑是线性的但已经包含了递归修正的入口。当 Skill 失败时会触发self_correct这就是第一层递归在 Task 内部的体现。4.4 加入第二层递归流程重构第二层递归需要 Harness 在 Task 执行完毕后分析执行日志判断是否需要调整 Skill 组合。下面是一个简化的重构逻辑。class TaskEvolver: def __init__(self, task, performance_threshold0.8): self.task task self.threshold performance_threshold self.history [] def evaluate(self, execution_result): # 计算成功率、耗时、资源消耗等指标 success_rate 1.0 if execution_result[status] success else 0.0 self.history.append(success_rate) return success_rate def evolve(self): if len(self.history) 3: return self.task # 样本不足不重构 recent_performance sum(self.history[-3:]) / 3 if recent_performance self.threshold: # 触发重构调整 Skill 顺序或替换 Skill new_skills self.reorder_skills(self.task.skills) return HarborTask(self.task.name, new_skills, self.task.validator) return self.task def reorder_skills(self, skills): # 简化示例把验证最严格的 Skill 提前 return sorted(skills, keylambda s: len(s.failure_history), reverseTrue)这段代码展示了第二层递归的基本逻辑基于历史表现决定是否重构流程。实际项目中重构策略会更复杂可能涉及 Skill 替换、并行化、缓存复用等。5. 常见问题与排查技巧实录5.1 递归不收敛怎么办这是最常见的问题。Skill 反复修正但始终无法通过验证Task 反复重构但性能不升反降。排查思路如下。现象可能原因排查方法解决方向Skill 修正 3 次以上仍失败验证规则过严或任务本身不可行检查验证规则是否合理人工跑一遍任务放宽验证规则或标记任务为不可行Task 重构后性能下降重构策略过于激进对比重构前后的执行日志增加重构冷却期限制重构频率递归深度无限增长缺少递归终止条件检查是否有最大递归深度限制设置硬性上限如 Skill 层 5 次、Task 层 3 次修正后结果与之前相同修正逻辑没有真正改变策略打印每次修正的 prompt 或参数确保修正逻辑根据失败原因做差异化调整我的经验是递归一定要有刹车。ScienceBuddy 在实现中设置了双重上限——单 Skill 最多修正 5 次单 Task 最多重构 3 次。超过上限就标记为“需要人工介入”而不是无限循环。5.2 上下文爆炸怎么控制科研任务往往涉及大量文本和中间结果上下文很容易撑爆。ScienceBuddy 的做法是分层裁剪Skill 层只保留当前步骤必需的输入Task 层只保留关键中间状态全局层只保留摘要和索引。具体操作上我建议在 Skill 的execute方法入口加一个上下文预算检查。如果输入超过预算先做摘要或分块再传给 LLM。不要指望模型自己处理超长上下文成本和稳定性都不可控。5.3 工具调用参数漂移怎么防Agent 调用外部工具时参数格式经常漂移。比如要求传 JSON它传了字符串要求传整数它传了浮点数。ScienceBuddy 的解法是在 Harness 层加一道“参数规范化”关卡所有工具调用前先过一遍 schema 校验和类型转换。def normalize_params(params, schema): normalized {} for key, expected_type in schema.items(): if key not in params: raise ValueError(f缺少必需参数{key}) value params[key] if expected_type int and isinstance(value, float): value int(value) elif expected_type str and not isinstance(value, str): value str(value) normalized[key] value return normalized这道关卡看起来简单但能挡掉大量低级错误。实测下来加了参数规范化之后工具调用失败率能降一半以上。5.4 验证规则怎么写才靠谱验证规则是 Harness 可靠性的基石。写得太松错误结果蒙混过关写得太严正常结果被误杀。我的建议是分三层写验证。第一层是格式验证检查输出结构是否符合预期比如 JSON 是否有必需字段。第二层是逻辑验证检查输出内容是否自洽比如引用的文献是否在输入中存在。第三层是抽样人工验证定期抽一部分结果人工检查校准前两层验证的准确性。ScienceBuddy 在实现中把这三层验证做成了可配置的管道每层可以独立开关和调整阈值。这个设计很实用因为不同科研任务对可靠性的要求不一样有的任务格式对了就行有的任务必须逻辑严密。6. 我踩过的坑和几条实用建议第一个坑是过早追求自进化。我一开始就想着让 Harness 自己学会所有东西结果发现基础 Skill 都没写稳进化出来的全是垃圾。后来调整策略先把每个 Skill 的手动版本写扎实验证规则调准再开启自进化。自进化是放大器基础不行放大出来的还是不行。第二个坑是忽略执行日志的结构化。早期我用 print 打日志出了问题根本没法追溯。后来改成 JSON 结构化日志每个步骤记录输入哈希、输出哈希、耗时、验证结果排查效率提升了一个数量级。如果你要做递归自进化日志就是你的眼睛千万别省这个功夫。第三个坑是验证规则和 Skill 逻辑耦合太紧。一开始我把验证逻辑写在 Skill 内部后来发现想换验证规则就得改 Skill 代码非常麻烦。后来把验证抽成独立模块Skill 只负责执行验证交给外部引擎灵活多了。最后一个建议从小场景开始。不要一上来就搞“全自动科研”先选一个具体的小任务比如“从一组 PDF 中提取所有实验方法”把这个场景的 Harness 跑通跑稳再逐步扩展。ScienceBuddy 本身也是从文献处理这个单点切入的后来才扩展到假设生成和实验设计。这套东西后续还可以往几个方向扩展一是把 Scoped Skill 做成可共享的技能市场不同项目之间复用二是把验证引擎做成可插拔的针对不同学科用不同的验证策略三是把递归过程可视化让研究者能直观看到 Harness 是怎么一步步进化的。我现在正在试的是第二个方向把生物信息学和材料科学的验证规则做成独立插件效果还不错。