企业官网建设流程全解析

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. 实操落地：从零搭建一个可用的 Harness

4.1 环境准备与依赖清单

要复现 ScienceBuddy 的核心思路，你不需要照搬它的全部代码，但需要准备以下基础组件。

环境准备阶段最容易踩的坑是：过早引入复杂框架。我见过不少人一上来就搭分布式任务队列、上向量数据库、搞多机部署，结果核心逻辑还没跑通，光调试基础设施就耗掉一周。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_threshold=0.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, key=lambda s: len(s.failure_history), reverse=True)

这段代码展示了第二层递归的基本逻辑：基于历史表现决定是否重构流程。实际项目中，重构策略会更复杂，可能涉及 Skill 替换、并行化、缓存复用等。

5. 常见问题与排查技巧实录

5.1 递归不收敛怎么办

这是最常见的问题。Skill 反复修正但始终无法通过验证，Task 反复重构但性能不升反降。排查思路如下。

我的经验是：递归一定要有刹车。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 是怎么一步步进化的。我现在正在试的是第二个方向，把生物信息学和材料科学的验证规则做成独立插件，效果还不错。