# AI For Science：垂直 Agent 的「垂直」，并不主要来自 Prompt

> 作者：晨旭｜发布：2026-07-13｜系列：入门系列文章
> 来源：https://chenxu.xin/writing/ai-for-science-vertical-harness

从 Claude Science 和开源项目 OpenScience 出发，拆解科研 Harness 的五层设计：专业数据源、持续 Kernel、结构化 Artifact、研究型 Session、可见的执行过程。

---

6 月 30 日，Anthropic 发布了 Claude Science，并把它定义为 An AI workbench for scientists，一张属于科学家的 AI 工作台。

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

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

这让我想起之前[拆解 Agent Harness](/writing/agent-model-plus-harness) 时看到的公式：

```text
Agent = Model + Harness
```

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

但 Claude Science 又把这个问题向前推进了一步：当大家使用的底层模型越来越相似，一个垂直 Agent 的「垂直」，究竟来自哪里？

为了进一步理解这套产品设计，我阅读了另一个独立开源项目 OpenScience 的代码。沿着这条思路，我逐渐发现：垂直 Agent 的「垂直」，并不主要来自 Prompt，而来自围绕专业工作流设计的 Harness。

对于科研 Agent 来说，这层 Harness 包含五个关键部分：专业数据源、持续 Kernel、结构化 Artifact、研究型 Session，以及让执行过程可见的前端反馈。

它们不是五个孤立的功能，而是在共同回答一个产品问题：如何让一个擅长对话和调用工具的通用 Agent，进入真实的科研工作流，逐渐变成一张可以持续探索、计算和查看专业结果的工作台？

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

首先回顾一下 OpenScience 与普通 Work Agent 共有的部分。用户在前端输入问题后，系统会进入一个新的会话，随后组织 Agent、模型、上下文和可用工具，接收模型输出的结果。模型可能直接输出文字，也可能返回一张工具调用单：

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

这套循环很重要，但它并不是 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：

```text
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 视图展示，化学分子用分子结构图展示，基因组数据用轨道图展示。

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

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

例如，一个蛋白质搜索工具拿到了结构坐标。对于模型来说，这些坐标已经是结果；但对于用户来说，一串数字几乎无法使用。OpenScience 会把它标记为「蛋白质结构」，前端收到后，再把这些坐标交给 3D 蛋白质查看器。于是用户最终看到的不是一堆原始数据，而是一个可以旋转、缩放和观察的蛋白质模型。



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

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

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

普通 Chatbot 的最小单位是一条消息：用户提问，模型回答。但科研工作的最小单位更像一个持续演化的项目。

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

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

- 与 sessionID 绑定的 Python / R Kernel
- Todo、权限请求、问题确认和其他任务状态
- User Message 与 Assistant Message
- 文本、工具、文件和 Artifact 等不同 Part
- Agent、模型以及本轮可用的工具
- 工具执行中的 running、completed 与 error

它不只是一段对话历史，更像是一个研究任务的容器。用户在这里提出假设、查找资料、运行计算、查看图表，再根据结果继续追问。Message 记录交流，Part 记录每一步产生的内容和状态，Kernel 保留计算现场，Artifact 承载专业结果。

这些对象被同一个 Session 组织起来后，产品的基本单位也发生了变化：Chatbot 的基本单位是一问一答，科研工作台的基本单位是一个持续演化的研究任务。

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

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

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

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

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



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

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

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

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

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

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

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

这比简单地告诉模型「你是一名生物学家」更接近真正的垂直产品：Prompt 负责引导判断，Harness 则负责确保它能接触正确的数据、使用合适的仪器，并以用户熟悉的方式交付结果。

### 一次科研任务如何穿过这套 Harness

假设用户提出一个蛋白质相关的研究问题：某个蛋白质有什么功能？它的结构和相关研究证据是什么？

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

首先，Agent 会根据问题查找专业蛋白质数据库，并对结果进行整理和分析：汇总不同论文中的关键结论、整理蛋白质的功能与结构和相关实验信息、使用 Python 清洗或比较数据、根据分析结果生成表格与统计图或结构视图。

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

如果用户接着问「能不能只比较最近五年的研究？」或者「把这个蛋白质的三维结构展示出来」，Agent 可以直接基于前面的资料和计算继续分析，并且根据结果类型，工作台分别展示带来源的文献总结、整理后的数据表格、Python 生成的统计图、可以旋转查看的蛋白质三维结构。

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

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

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

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

## 最后

垂直 Agent 的「垂直」，并不主要来自 Prompt，而来自 Harness。可以把 OpenScience 的产品思路压缩成一个公式：

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

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

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

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

## 核心结论

- 垂直 Agent 的「垂直」并不主要来自 Prompt，而来自围绕专业工作流设计的 Harness。只换一段系统提示词，只能让通用 Agent 说话像科研人员。（判断 · 把握较大）
  永久链接：https://chenxu.xin/writing/ai-for-science-vertical-harness#vertical-comes-from-harness
- 把每个数据库单独包成一个 tool，模型的选择错误率会随数据源数量一起上升。加一层 Connector 收敛成 search 和 fetch，数据库可以继续增长而动作空间保持稳定。（判断）
  永久链接：https://chenxu.xin/writing/ai-for-science-vertical-harness#connector-keeps-action-space-stable
- 对话记忆不等于计算状态。Agent 能在对话记录里「记得」刚做过什么，却无法继续操作刚才的计算现场——除非 Kernel 按 session 复用。（判断 · 把握较大）
  永久链接：https://chenxu.xin/writing/ai-for-science-vertical-harness#conversation-memory-is-not-compute-state
- Artifact 不只是让界面更漂亮。它是一种约定好的结果包装格式，告诉前端「这份数据是什么、应该怎样展示」，把原始坐标变成可旋转的蛋白质模型。（判断）
  永久链接：https://chenxu.xin/writing/ai-for-science-vertical-harness#artifact-is-a-packaging-protocol
- 对于普通问答用户可能只关心最后一句话，但对于科研工作，过程本身就是信任的一部分。（判断）
  永久链接：https://chenxu.xin/writing/ai-for-science-vertical-harness#process-visibility-builds-trust

---

本文出自晨光里的AI（https://chenxu.xin），作者晨旭。
引用时请保留来源链接。文中标注「判断」「假设」的部分是作者的个人看法，不是事实。
