开篇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 等不同 PartAgent、模型以及本轮可用的工具工具执行中的 running、completed 与 error与 sessionID 绑定的 Python/R KernelTodo、权限请求、问题确认和其他任务状态 它不只是一段对话历史更像是一个研究任务的容器。用户在这里提出假设、查找资料、运行计算、查看图表再根据结果继续追问。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才让它真正进入了科学家的日常。‍