开篇

6 月 30 日，Anthropic 发布了 Claude Science，并把它定义为：

An AI workbench for scientists，一张属于科学家的 AI 工作台。

第一次看到这个定位时，最让我感到困惑的是 Workbench 这个词：为什么science 不能在现有的 cowork 里实现，而需要单独做一个产品出来呢？🤔

仔细琢磨后发现，Claude Science 并不是在强化聊天，而是把大模型放进一个真正接近真实科研工作的环境里。

这让我想起之前拆解 Agent Harness 时看到的公式：

Agent = Model + Harness

模型负责推理；Harness 决定模型能看到什么数据、使用什么工具、保留什么状态、如何执行动作，以及最终交付什么。

但 Claude Science 又把这个问题向前推进了一步：当大家使用的底层模型越来越相似，一个垂直 Agent 的“垂直”，究竟来自哪里？为了进一步理解这套产品设计，我阅读了另一个独立开源项目 OpenScience 的代码。沿着这条思路，我逐渐发现：👉 垂直 Agent 的“垂直”，并不主要来自 Prompt，而来自围绕专业工作流设计的 Harness。对于科研 Agent 来说，这层 Harness 包含五个关键部分：专业数据源、持续 Kernel、结构化 Artifact、研究型 Session，以及让执行过程可见的前端反馈。

它们不是五个孤立的功能，而是在共同回答一个产品问题：

如何让一个擅长对话和调用工具的通用 Agent，进入真实的科研工作流，逐渐变成一张可以持续探索、计算和查看专业结果的工作台？

这篇文章，是从产品与技术两个角度，重点拆解这五层「科研 Harness」。👇

参考资料：https://www.anthropic.com/news/claude-science-ai-workbench、https://github.com/synthetic-sciences/openscience

通用 Agent Loop，只是科研工作台的地基

首先回顾一下 OpenScience 与普通 Work Agent 共有的部分。

用户在前端输入问题后，系统会进入一个新的会话，随后组织 Agent、模型、上下文和可用工具，接收模型输出的结果，模型可能直接输出文字，也可能返回一张工具调用单

模型决策 → 返回 Tool Call → 外部程序执行 → 工具结果写回 Message → 模型继续决策

（具体过程在之前的这篇文章中有详细写到～给 Claude Code 一个任务，它的内部发生了什么？）

这套循环很重要，但它并不是 OpenScience 独有的。Claude Code 可以用同样的循环读写代码，通用研究 Agent 也可以用它进行网页搜索。

换句话说，Agent Loop 决定系统「能不能自主行动」，而领域 Harness 才决定它「在为什么专业工作」。

只换一段 System Prompt，只能让普通 Agent 说话像科研人员🥸；只有改造它能访问的数据、能延续的状态、能操作的环境和能交付的结果，它才可能真正像科研人员一样工作。👇

科研 Harness 的五层设计

1、专业数据源，让 Agent 接触科研世界

科研任务与普通问答的第一个差异，就是数据。

普通 Agent 可以搜索网页，但科研信息分散在文献、蛋白质、基因组、化学、通路和组学等不同数据库中。它们的 API、查询字段、返回结构甚至身份认证方式都可能不同。

那如果直接把上述数据库每个都单独包装成一个 tool 暴露给模型，会发生什么呢？

随着数据源增加，模型看到的工具说明会越来越多。它不仅要理解用户的问题，还要先判断应该使用 PubMed、UniProt 还是其他数据库，并记住每个 API 完全不同的参数。能力看起来丰富了，选择工具和填写参数的错误率也会一起上升。🤯

OpenScience 的做法是在中间增加了 Connector 层。

不同领域的数据连接器统一注册到 ConnectorRegistry，并被收敛成 search 与 fetch 两类基本动作。上层再通过‘science_search’等少量工具把统一能力交给 Agent。👇

Agent → science_search → Connector Registry → 文献 / 蛋白质 / 基因组 / 化学 / 通路 / 组学数据库

Connector 隔离了外部 API 的变化，新增数据库时不需要修改 Agent 主循环，更重要的是，数据库数量可以继续增长，但模型面对的动作空间仍然是相对稳定的。

👉 专业数据源并不是给 Agent 多装几个搜索插件，而是在模型与科研世界之间建立一层稳定的数据平面。

2、持续 Kernel，把一次调用变成连续实验

普通工具调用往往是无状态的。

Agent 执行一条命令，得到结果，这次调用就结束了。但科研分析很少能在一步内完成：先加载数据，再清洗缺失值；接着计算统计指标、画图；看到异常后，又要修改参数重新运行。

假如每次执行一次 Python 都启动一个全新的进程，上一轮创建的数据框、变量和依赖状态会全部消失。Agent 虽然能在对话记录里「记得」刚刚做过什么，却无法继续操作刚才的计算现场。

这也是一个很容易被忽略的概念区分：

👉 对话记忆不等于计算状态。

如下面这张截图，真正重要的信息不是代码本身，而是「共享的 Live Kernel」和正在远程运行的八组实验。

把本地 Notebook、远程集群任务和运行状态放在同一个界面里；

在技术实现上，OpenScience的做法是，NotebookTool 和 RKernelTool 会按照 sessionID 复用长时间运行的 Python 或 R 进程。工具不只捕获最终文本，还会收集 stdout、stderr、计算结果和生成的图片。

这样，同一个 Session 中的多次工具调用就不再是彼此孤立的函数执行，而更像在同一个 Notebook 里不断增加 Cell：

这让用户获得了实验连续性：Session 不再只关联聊天消息，还成为 Kernel 的运行作用域。

不过这里要注意～运行中的 Kernel 不等于永久保存的实验环境。要实现几个月后仍能一键复现，还需要保存代码版本、依赖、随机种子、输入数据和计算环境。

这就自然地把我们带到了下一层。👇

3、结构化 Artifact，让回答变成专业对象

我们平时使用 Codex/Cowork，最熟悉的交付方式是Markdown文件。

但科研结果天然不只有文字。一个蛋白质结构、一条基因组轨道、一组多序列比对、一张实验图、一份 PDF 和一段 LaTeX，如果把这些原始数据直接扔进聊天框，用户看到的只会是一大段难以理解的数字或 JSON。

为了解决这个问题，OpenScience 会先给工具结果贴上一个「类型标签」：

这是蛋白质结构 这是化学分子 这是一条基因组轨道 这是一份 PDF 这是一张实验图

前端看到标签后，就会自动选择合适的专业查看器：

• 蛋白质结构，用可旋转的 3D 视图展示；

• 化学分子，用分子结构图展示；

• 基因组数据，用轨道图展示；

• ...

整个过程可以理解成一个智能分拣系统：​​​​​​

工具获得科研数据 → 标记“这是什么类型” → 前端选择对应的查看器 → 展示成图表、结构、轨道或文档

例如，一个蛋白质搜索工具拿到了结构坐标。对于模型来说，这些坐标已经是结果；但对于用户来说，一串数字几乎无法使用。

OpenScience 会把它标记为「蛋白质结构」，前端收到后，再把这些坐标交给 3D 蛋白质查看器。于是用户最终看到的不是一堆原始数据，而是一个可以旋转、缩放和观察的蛋白质模型。

左侧是研究项目，中间是可直接批注的科学图表，右侧同时展示 Code、Execution Log、Messages、Environment 和 Review；

这就是 Artifact 的作用：

它像一种约定好的科研结果包装格式，告诉前端：“这份数据是什么，以及应该怎样展示”。

👉 因此，Artifact 并不只是让界面更漂亮。它真正解决的是：如何把 Agent 得到的原始数据，转化为科研人员能够理解和继续使用的专业成果。

4、Session，把聊天记录升级为研究空间

普通 Chatbot 的最小单位是一条消息：用户提问，模型回答。

但科研工作的最小单位更像一个持续演化的项目。

因此，Claude Science 也强调：“在一个环境中完成研究的所有阶段”，而支撑这件事的核心对象不是某一次 Prompt，而是 Session。

普通聊天产品里的 Session，主要用于保存「用户说过什么、模型回答了什么」。但在 OpenScience 中，一个 Session 同时连接了更多状态：

• User Message 与 Assistant Message

• 文本、工具、文件和 Artifact 等不同 Part

• Agent、模型以及本轮可用的工具

• 工具执行中的 running、completed 与 error

• 与 sessionID 绑定的 Python/R Kernel

• Todo、权限请求、问题确认和其他任务状态

👉 它不只是一段对话历史，更像是一个研究任务的容器。

用户在这里提出假设、查找资料、运行计算、查看图表，再根据结果继续追问。Message 记录交流，Part 记录每一步产生的内容和状态，Kernel 保留计算现场，Artifact 承载专业结果。

这些对象被同一个 Session 组织起来后，产品的基本单位也发生了变化：

Chatbot 的基本单位：一问一答 科研工作台的基本单位：一个持续演化的研究任务

这是非常重要的产品转变。

因为科研用户真正需要保存的，通常不是一句最终答案，而是问题如何被拆解、数据从哪里来、运行过什么计算、产生了哪些中间结果，以及下一步还能从哪里继续。

5、让用户看见过程，而不只是等待结果

科研任务通常比普通问答更慢，也更容易失败。一次任务可能持续几分钟、几小时，甚至几天；数据库可能没有返回，代码可能报错，远程任务也可能失败。

如果界面只显示「正在思考」，用户根本不知道系统是正在查文献、运行代码，还是已经卡死了。🫥

OpenScience 把一轮任务拆成文字、工具、文件、Artifact 等不同状态，并通过事件流实时推到前端。这样用户就能看到工具开始运行、任务完成、错误出现以及结果逐步生成。

如下图，Claude Science 也在强化这种过程可见：运行了多少次搜索、调用了哪些子 Agent、远程实验还剩多久、Reviewer 发现了什么、图表对应哪段代码，都不再藏在聊天框背后。

多个子 Agent 搜索资料、Reviewer 指出引用错误，右侧直接生成完成的 PDF。

👉 对于普通问答，用户可能只关心最后一句话；但对于科研工作，过程本身就是信任的一部分。

专业 Agent：把五层科研 Harness 组合起来

有了数据源、Kernel、Artifact、Session 和过程可见，还需要有人根据任务选择这些能力。🤔

OpenScience 定义了 research、biology、physics、ml 等不同 Agent。它们的差异不只是一段角色提示词，还体现在默认行为、权限以及可见工具上。ToolRegistry 会根据 Agent 过滤工具，减少无关能力进入上下文。

因此，专业 Agent 更像一份能力组合方案：

专业 Agent = 领域提示词 + 专业数据源 + 可用工具集合 + 权限边界 + 结果表达方式

这比简单地告诉模型“你是一名生物学家”更接近真正的垂直产品：

prompt 负责引导判断，harness 则负责确保它能接触正确的数据、使用合适的仪器，并以用户熟悉的方式交付结果。

那具体来说，一次科研任务是如何穿过这套 Harness 的呢？

假设用户提出一个蛋白质相关的研究问题：

某个蛋白质有什么功能？它的结构和相关研究证据是什么？

普通 Chatbot 可能根据已有知识生成一段文字回答。但在 OpenScience 中，这个问题会逐步变成一项可以继续推进的研究任务。👇

首先，Agent 会根据问题查找专业蛋白质数据库，并对结果进行整理和分析。例如：

• 汇总不同论文中的关键结论

• 整理蛋白质的功能、结构和相关实验信息

• 使用 Python 清洗或比较数据

• 根据分析结果生成表格、统计图或结构视图

这些分析并不是每次都从零开始。同一个研究任务中的数据、变量和计算结果可以被后续步骤继续使用。

如果用户接着问：“能不能只比较最近五年的研究？” 或者 “把这个蛋白质的三维结构展示出来。”

Agent 可以直接基于前面的资料和计算继续分析，并且根据结果类型，工作台分别展示：

• 带来源的文献总结

• 整理后的数据表格

• Python 生成的统计图

• 可以旋转查看的蛋白质三维结构

• ...

在整个过程中，界面还会告诉用户系统当前正在搜索资料、运行分析、生成图表，还是遇到了错误。用户不需要面对一个长时间没有反应的聊天框，而是可以看见研究任务一步步展开。

这时，产品的价值就不再是“替用户回答一个蛋白质问题”，而是为用户保留资料、分析、结果和修改过程，让研究能够持续向前推进。

👉 普通 Work Agent 更像是在完成一条指令；而科研工作台则是在陪用户推进一个不断演化的研究项目。

到这里，OpenScience 才真正从一个会调用科研工具的 Agent，走向一张可以持续工作的科研工作台。

最后

垂直 Agent 的“垂直”，并不主要来自 Prompt，而来自 Harness。

可以把 OpenScience 的产品思路压缩成一个公式：

👉 科研工作台 = 通用 Agent Loop + 专业数据平面 + 持续计算环境 + Artifact 协议 + 研究型 Session + 可观察反馈

这里模型未必因此变得更聪明，但它开始能够以更接近科研工作的方式使用自己的聪明。

这也是对 Claude Science 的产品定义：科学家缺少的不是另一个更会聊天的模型，而是一套能够接住完整研究过程的工作环境。

前面的 Loop 让 Agent 能够行动；而后面的 Harness，才让它真正进入了科学家的日常。🧑‍🔬