解剖 Claude Science

2026 年 6 月 30 日，Anthropic 发布 Claude Science[1]。它看上去只是个简单的本地应用。⁺启动它，弹出来的不是常规桌面窗口，而是浏览器里一个 localhost 页面。真正的新意藏在界面底下：Anthropic 把科研工作台本身做成了一套智能体框架（agent harness）。一个守护进程居中，从正在运行的分析，一路管到最终产物（artifact）背后的证据。

从界面上看，它用起来并不陌生。你打开一个项目，跟一个智能体对话，看它写代码、跑代码，然后收到一张图、一个表、一个结构，或一份报告。系统生成的产出，还能亮出背后的代码。我就是顺着这段代码摸进架构的。在一次生成的分析里，我看到这样一个调用：

try:
    EMAIL = host.get_user_email()
except Exception:
    EMAIL = None

没有 import host。Python 环境里也没有 host 这个包。可正在运行的内核里，偏偏有这个名字。一个起步项目的代码记录里还藏着另一条线索：host.exec_peek(...)。这些细小的反常，出现在一段再普通不过的 Python 会话里，带出了我拆解这套系统时一路追问的问题：是谁把 host 放进来的，调用的另一头又是什么？

答案先落在一个具体机制上。kernel_worker.py 说明，内核启动后，第一次 execute() 会装入 host SDK。SDK 由守护进程注入；host.llm()、host.mcp() 这类调用，实际都是跨过进程边界、同步回到守护进程的 RPC。全文的主线就从这里展开：内核留住工作状态，守护进程掌管权柄和历史。

这条分工又带出 Claude Science 的三个关键选择。代码压缩了编排，却没有抹掉能力边界；产物带着版本和证据，留在对话之后；审查脱离主智能体的自省循环运行，还能拦住任务收尾。

对做智能体框架的人来说，Claude Science 的价值就在这里：它让人看清，模型能力、框架策略、应用掌管的执行环境，怎样合成一条科研流水线。下文始终沿着同一条边界往前走：先看应用外壳和它写进磁盘的内容，再追进 host 背后的注入与 RPC，最后看守护进程怎样控制代码、产物、验证三条流。这里剖的实现版本是 0.1.15-dev。⁺文中关于机制的判断，都来自本地应用包、~/.claude-science/runtime 下的文件、SQLite 迁移，还有部署好的 claude-science 守护进程的行为。

装到你机器上的是什么

在追 host 之前，先从任何用户都能查的东西说起。这个 macOS 应用包，大半只是一层签名外壳，负责启动和更新。它先跑一个种子可执行文件，在应用主目录下部署一个更新的 claude-science 守护进程，再让这个守护进程在本机回环地址上提供本地 web 应用。守护进程接着在 ~/.claude-science/runtime 下选择一个带版本号的运行时包（runtime payload）。

这个运行时包在 BUILD.json 里写明构建号和平台。围着这个小文件的，才是真正的产品发行内容：web 客户端、agent 配置、内核 worker、SQLite 迁移、科研技能、MCP 服务器、算力提供方代码、种子项目、micromamba、图像处理依赖、字体，还有写入追踪支持。整个运行时包都可以替换。大得多的 Python 和 R 环境则单独装在 ~/.claude-science/conda 下。

签名外壳可以一直很小，守护进程和运行时包则能快速迭代。在我查的这套安装里，基础的 Python 分析、R 分析和自带的 MCP 服务，各住在单独的 conda 环境里。具体的工作区，再往上叠本地 Python 虚拟环境和 R 库。

运行时包里还带着几个起步项目：CRISPR 筛选、酶工程、嗜极生物分析、免疫治疗分析。它们的清单和归档里，装着计划、报告、表格、图、结构、数组、中间结果，还有生成这些东西的消息流。因为这些材料就在用户自己的机器上，起步项目便不只是演示，也让人看得见系统怎样管理产物。用户能看见 Claude Science 做了什么、怎样做到，交付物又是什么成色。

跟着 host 进入守护进程

产物的代码面板给了我第一条线索，但运行时才解释这套戏法是怎么变的。内核启动前后，kernel_worker.py 初始化一个普通的持久命名空间，留下这么一句注释：

# The host SDK (host.lineage/query/llm) is installed via the first
# execute() after kernel start -- see base.ts postStartCode mechanism.

这个文件里有 SDK 调用的协议管道，却没有 SDK 的实现本体。那份实现是 claude-science 守护进程的一部分，由它按内核组装、注入。

守护进程总会先发一个基础片段，随后按 agent 配置，把一批受门控的片段接在后面。后面这些片段，往一个已经建好的单例上挂方法。基础片段把这个单例同时绑到 host 和旧名字 operon 上，再把这个对象注册进 sys.modules。这就是为什么明明没装任何模块，import host 看着也能用。

同一个片段还回答了：一次方法调用的另一头发生了什么。在内核里，host.llm()、host.artifacts()、host.mcp()、host.compute.create() 看着都像普通 Python。可每一个到头来，都会把一个同步请求序列化，走内核私有协议发出去，然后等守护进程给一个对得上的响应：

这些注入方法只为调用方便，不掌握最终权柄。守护进程给每种内核挑一套允许调用的方法，派发前先查许可，再让各个处理器分别校验。就算硬造一个原始的 _host_call("mcp", ...)，也拿不回当初没有授予分析内核的能力。

守护进程是整个架构的中心。身份、权限、agent frame、执行记录、产物存储、连接器访问、算力提供方、验证状态、本地 web 服务，全归它管。Python、R、shell 进程、只用标准库的控制 REPL、远程计算，始终是从属的 worker。Python、R 能保留状态，这些 worker 都能计算或产出文件。但用哪些外部能力、哪些产出能留存下来，不由它们说了算。

运行时包和 host 边界接上以后，下面便可以顺着这项设计的后果往前走。第一项后果，是智能体怎样干活：它写代码。

第一刀：代码即编排语言

很多智能体产品都在用某种 ReAct 循环：推理，调用一次或几次工具，读回结果，再进入下一轮模型调用。Claude Science 也能这么做，但它更独特的界面是代码。Python 可以直接表达工具之间的控制流；规模一大，差别就出来了。

拿它自带的 literature-review 技能来说。这个技能把 search_openalex、expand_citations 这类辅助函数直接加载进 Python 内核。智能体只需写一个 Python 代码单元格（cell），就能拉来几百篇候选论文，在引文图上双向游走，再把整批结果作为一张表留在内核里。模型调用也在同一个内核里跑，所以一个循环就能逐篇调用 host.llm()，评估相关性，抽取论文报告的效应。整场筛查仍只占一个代码单元格。模型写一次代码，读一个汇总结果，不必在对话记录里亲自调度几百次工具往返。最后，matplotlib 直接用内存里的表画图。

这种压缩靠两点。第一，整批论文不必塞进主智能体的对话上下文。它们作为数据留在持久内核里；每次 host.llm() 只送出当次请求，最后回到主对话的则是汇总结果。第二，迭代写在代码里，不铺在模型一轮一轮的对话记录里。一个 for 循环在单个单元格中发出 N 次调用；模型只写一次循环，也只读一个结果。代码把迭代挪出了语言模型。

所以，代码不只用来分析返回的数据，也是编排的压缩格式。这一刀余下的部分，讲的是怎样约束这种压缩：代码跑在按能力裁剪的进程里，进程之间的边界也经过明确划分。

import json
papers = search_openalex(query, n=25)
for seed in papers[:3]:
    g = expand_citations(seed["doi"])
    papers += g["references"] + g["cited_by"]
for p in papers:                    # ~240 candidates
    prompt = rubric + "

" + json.dumps(p)
    p.update(json.loads(host.llm(prompt)["text"]))

keep = [p for p in papers if p["score"] >= 0.7]
plt.scatter([p["year"] for p in keep],
            [p["effect"] for p in keep])
plt.savefig("effects.png")          # -> artifact

主 OPERON 提示词把工作流讲得很直白。MCP 调用走 repl，不走 Python 或 R。对样本或记录的循环，应该在一个 REPL 代码单元格里跑完。结果要序列化进 ./handoff/<name>.json，再由分析内核加载。一次 Python 调用应该装下一个完整的逻辑分析步骤，因为哪怕内核本身持久，每次调用也要花一整个模型往返。

控制内核与数据内核

控制 REPL 运行隔离的 Python，只带标准库。它拿到的是编排类片段：MCP、agent、技能、frame 查询、委派、结构化输出，以及按算力提供方门控的远程计算。包更齐全的 Python 和 R 内核则没有这些界面，只能使用产物查找、溯源、模型调用、凭据等分析方法。

分析代码尝试调用 host.mcp 时，SDK 不会假装这个方法存在。AttributeError 会直接说明：这个内核没有连接器界面；请到 repl 取数，把 JSON 写进 ./handoff，再由 Python 读取。同类的教学式报错也覆盖 agent、技能、计算、查询、frame、执行控制、结构化输出。报错还点明进程边界：这些内核共享工作区的当前目录，却不共享内存。

不注入某些 SDK 方法，只是第一道关卡，不是安全边界。这种做法会用一条明确的报错教会智能体怎样调用 API。真正的权柄在守护进程的许可集里。就算内核代码硬造一个 _host_call("mcp", ...)，分析内核的许可集也会拒绝。MCP 处理器还会继续检查 Operon 内核、身份认证、连接器解析、schema 校验、策略审批。

代码也是一条能力边界。第三方科研包在有状态的分析内核里跑；连接器访问、agent 修改则留在更窄的控制内核。一个 pandas 对象不能把引用直接从 Python 递进 repl，必须先变成文件。这多了一步，却让跨越有了名字，可以检查，可以哈希，也可以纳入产物溯源。

有持久状态，内核却不掌权

Python worker 是一个长命的子进程，带一个持久命名空间。它接收 JSON 请求，把每个单元格编译进一个合成文件名（比如 <kernel:17>），在 linecache 里登记源码，再在前面单元格用过的同一个命名空间里求值。加载好的矩阵、拟合好的模型、写好的辅助函数，都能跨轮次活下来。每个响应都带着 stdout、stderr、轨迹信息、墙钟时间、CPU 时间和峰值内存。

持久得配上协议加固。流式输出、最终响应、单元格执行到一半的 host 调用，共用锁，好让 JSON 行不会交叠。协议用的文件描述符，和用户看得见的 stdout 分开。用户代码运行前，先把密钥变量清掉。从可写根目录加载动态库，一概拒绝，除非落在一条明确的环境豁免里。exit、quit 和中断都专门处理，不会随手把内核毁掉。

R 大体上是同一个形状。它是一个长命的 Rscript worker，保住 .GlobalEnv，通过标准流交换 JSON，剥掉机密，看住 dyn.load，并在求值期间支持 host 回调。Bash 不一样：证据指向的是受管的子进程执行，而不是持久的 shell 内存。它照样参与，靠的是执行记录、后台输出、进程组中断和 host 审批。⁺Python 和 R 的持久，在 worker 源码里写得明明白白。shell 的持久没有。在 macOS 上，写追踪配置也说，Darwin 这条路不像 Linux 那样追踪 Bash。

持久内核不是新东西。这里真正要紧的设计选择，是持久却不给内核权柄。一个 Python 进程可以攥着巨大的矩阵一个钟头。可要做一次特权的 host 操作，它还是得向守护进程开口。

用代码编排智能体集群

控制平面不止管计算。它那些受门控的 SDK 片段，暴露出这些活儿：增删改查 agent 配置，挂载技能和连接器，编辑、发布技能，委派、收集、中断子智能体，提交结构化结果。这些都是 host 调用，不是去改一个随手写的提示词文件。守护进程能在搭新智能体时加上校验和策略，也能管住它们怎么用工具。

新手引导用的是同一个运行器，只是故意收窄了。自带的 ONBOARDING 配置不能跑 Python、R、Bash、repl，不能搜索、管包，也不能用远程计算。它用选项卡片做一次有边界的访谈，等选定第一个任务后再收集权限，然后把任务交给一个干活的智能体。一个本可以做成固定向导的产品流程，在这套框架里，成了一个受约束的 agent 配置。

对做框架的人，第一刀给出一条具体的教训。给模型"代码执行"，不是给它一项能力。Claude Science 把这件事拆开：持久的数据状态、标准库控制代码、外部工具 RPC、受管子进程、远程作业，还有守护进程掌握的策略。代码把它们拼到一起，却没抹掉彼此的边界。

这是守护进程边界带来的第一项后果：工作可以跨进程流动，权柄却仍集中在一处。这些跨越随即带来下一个问题。结果既要经过文件交接，又要活得比内核更久，系统就必须留下持久记录，说明每个结果是什么，又从哪里来。

第二刀：产物才是产品，消息不是

OPERON 提示词要求智能体留下可保存的产物，不只是给出答案。工作区里的文件在保存前，用户看不见。图应该按版本 id 嵌入。报告链接产物，要按身份，而不是按含混的文件名。最终回复指向主交付物，其余内容留在产物栏里。

这不是排版上的润色。它点出了这套系统真正要长期保存的对象。

一份产物记录要有用，就得回答一个问题：每个版本是用什么造出来的？Claude Science 用一张依赖图作答。图连接的是精确版本，不是文件名。图底下的映射记录还能区分两类输入：一类在运行时直接观测到，一类来自事后重建；整个抽取过程也可能暂时没有完成。这张图先把三者分开；这一刀余下的部分，再逐层解释底下的证据怎样留下记录。

溯源先观测，后重建

光凭代码文本，判不准溯源。路径可能是动态拼出来的。一个 dataframe 可能是某个库调用切出来的。一张图可能是某个对象写的，而这个对象的来历，在最后那句 savefig 里根本看不见。Claude Science 先试着在代码运行时观测数据流。

在用户代码之前，分析 SDK 会包装选定的读取器和写入器。pandas.read_*、numpy.load*、anndata.read_h5ad 这类读取器，给返回的对象贴上来源版本 id。DataFrame.to_*、Figure.savefig、numpy.save*、json.dump 这类写入器，收集这些标记，记下哪些来源版本流到了一个输出路径。等那个路径登记为产物，host 就向内核要它的运行时输入。

这套机制靠 pandas 属性、打了标记的 NumPy 子类、标量包装器，还有尽量用上的一张辅助表，把标记往下传。它故意不是全面的污点追踪。它明确不做的，包括通用的数据流追踪，也包括对 R 或 Bash 的完整覆盖。普通字典、不受支持的库、执行的字符串，都可能把标记弄丢。包装过的写入器一旦触发，它记下的输入集合就是准数；集合可以为空，空也表示确认没有输入。只有写入器根本没有看见这个路径，host 才退回代码和依赖重建。

这个先后次序，才是要紧的选择：

也可以让一个 LLM 从代码里推断每一条边，但 Claude Science 只把这种办法当作兜底。⁺溯源的可信度并不均匀。Python 的对象包装器最全。R 和 Bash 更多靠写追踪和事后重建，而 Darwin 配置说，Bash 不走 Linux 那条 preload 路径来追踪。别把“可溯源”讲成一个非黑即白的保证。

文件底下的那条记录

产物不只是一个路径，而是项目里一条带版本的记录。产物记录标明项目、根对话、生成它的 frame、文件名、最新版本、所在文件夹、优先级，以及这一项是临时生成还是由用户提供。每个版本可以保留内容类型、大小、校验和、存储路径、抽取出的代码、代码说明、溯源消息、agent、语言、依赖映射、环境快照、注释，还有父版本。另有单独的记录，保存精确到"版本对版本"的依赖。

在这条记录底下，Claude Science 至少记了三层证据。

第一层是执行日志。一个单元格可以记下它的 frame、序号、内核 id、环境、语言、源码、stdout、stderr、状态、写了哪些文件、读了哪些文件，还有出错的位置。一个产物版本，可以指回生成它的那个单元格，也指回单元格源码的快照。

第二层是 host 调用日志。单元格里做的一次特权调用，可以连同方法、参数、序号、可否推导、内联或引用的响应数据、错误、字节数、执行日志 id 一起存下来。这把"代码跑了"和"代码向 host 要了一个外部或特权的结果"分了开来。

第三层是产物图。依赖连的是精确版本，不是文件名。host.lineage.graph(version_id) 取回拓扑，开销很小。host.lineage[version_id] 能为选中的节点返回代码、消息、环境、输入、校验和、frame 和生成它的单元格。结果里还带一个 extraction_pending，所以当前零条边，不一定就说明这项产物没有输入。

合到一起，这几层能表达出：这张图来自那张表，由这个单元格生成，经过这些 host 调用，在这个环境下，在这个 agent frame 里。覆盖也许不全，但这套 schema 把这条链当成头等的状态，而不是事后临时凑的一段话。

Artifact governance

One artifact and the layers it carries

This generated figure from a live session opens with tabs for its reconstructed code, raw execution record, agent messages, and pinned environment. Its provenance is available from the artifact menu.

This is one real artifact from a live pet-genetics session. Switch tabs to read each layer it carries, straight from the product UI.

CodeExecution LogMessagesEnvironmentProvenance

The producing script, reconstructed

Click to enlarge

产物背后的代码是怎么重建的

没有哪一个神奇的"重建代码"函数。这套系统把好几条证据线拼起来。

如果一项产物直接从有记录的单元格存下来，producing_cell_id 和单元格源码给出最强的一条路。碰上更复杂的序列，一个版本可以存 extracted_code、code_description、lineage_messages 和 dependency_mappings。环境和溯源快照可以按哈希寻址。parent_version_id 保住祖先关系。运行时标记可能给出精确的上游 id。守护进程随后把映射收敛成依赖边，同时核对：存下来的映射文本，没在并发更新里改动过。

重建沿用溯源阶梯图里的可信度次序。守护进程先认观测到的标记和生成单元格，拿不到就退到记录下的调用、抽取的代码和快照，再退到事后映射。尚未收敛的，一律标成未决。因此，有些边来自观测，有些来自重建，还有一些仍然悬着。

重放，但不假装 host 从未存在

导出带来一个难题。笔记本代码里可能有 host.llm()、host.artifacts()、host.lineage、host.mcp()、委派，或者对 app 的调用。出了 Claude Science，host 不是一个装好的包，守护进程的状态也不在。只导出 Python，得到的笔记本，重要调用全都会失败。

自带的重放垫片选了个直接的办法。host 的响应写进 operon_tape.json。一个独立的笔记本加载这条磁带，把 host 和旧名字 operon 都绑到一个重放对象上，按顺序一条条消费。抽取出的代码要是省掉了某些已知的发现类调用，这些调用可以跳过。方法一旦对不上，就在游标前进之前抛错，免得一次错位悄悄把后面每一条响应都挪偏。

这个垫片镜像了模型调用、产物、溯源、凭据、frame、子智能体、委派、MCP 和 app 工具。它的能力报告也承认：agent、技能、计算和后台执行控制都用不了。重排调用，或者加入新的 host 效应，都会让这条磁带失效。

这是可移植，不是完整的重算。重放出来的 LLM 答案，是当初实跑时录下的那个答案。重放出来的 MCP 结果，不是一次新的查询。这条磁带证明的是：导出的代码，能对着保存下来的 host 响应、按录下的顺序跑一遍。它证明不了：一个干净的环境，能从外部世界把那些响应重新生成出来。

这个局限不会一笔勾销重放，只会划清重放能证明什么。另一种做法，是把 host 依赖藏在笔记本里，直到运行失败才暴露。Claude Science 则把这些依赖当作数据一并导出。⁺一次合成的冒烟测试证实了：按顺序消费、受控地跳过一条发现类条目，还有对一次录下的凭据失败做软处理。我查的应用数据里，没有一个真实导出的笔记本包，所以端到端的导出完整性，仍未经证实。

产物系统把执行过程变成了持久证据。有了这份证据，审查也能换一种做法：审查者不必重跑分析，也不必加入主智能体的推理循环，只需沿着记录，把留下来的说法追溯到源头。

第三刀：主循环之外的审查者

许多智能体系统把验证留在被验证的主循环里。同一个模型产出结果、反思结果，再判断自己的反思够不够。就算叫来第二个模型，什么时候叫、拿到答案怎么办，也往往由主循环决定。

Claude Science 做的是另一样东西：一个脱离主循环、由运行器掌管的验证器。

我剖的版本带着两个隐藏的验证配置：REVIEWER 和 BOOKMARKER。它们不是两个一直运行的智能体。在我观察的本地运行时里，审查者路径已经启用。bookmarker 的实现也随同一版本发布，但 bookmarks_enabled 默认是 false。本地同样没有 bookmarker 的 frame 或对话记录标注。因此，对 0.1.15 准确的说法是：一个活跃的后台审查者，加一条休眠的书签路径，而不是"两个智能体一直在后台跑"。

审查者要做什么

REVIEWER 不是第二个科学家。它读取另一个智能体的运行记录，找出这份工作在哪儿编造了结果、捏造了来源，或偏离了计划。它的提示词对方法要求得异常严。第一条规矩是追溯，不要重算：智能体报出一个数，审查者就去找打印这个数的单元格，再检查有无矛盾。某个值在审查窗口里追不到，单凭这一点不能算作问题。

这条规则针对验证器一种特定的失效。两次独立分析只要用了不同的过滤条件、库或随机种子，结果就可能对不上。但这种分歧本身，不能说明哪一次真正沿用了用户的工作。追溯型审查者只问一个更窄、也更能回答的问题：准备留存的结论，是否符合会话自己留下的证据路径？

为让它只回答这个问题，配置剥掉了那些会让它跑偏、另起炉灶做分析的工具。它关掉计划、委派、联网搜索和思考，也排除 Python、R、Bash、包和环境管理、产物写入、文件修改、全文检索、计算。守护进程只留给它一个只读的 host 界面：frame、限定范围的查询、产物路径和列表，还有溯源。

第二条规矩，露出了这套设计的优先级：问题有多严重，要看那项说法留在哪里。图或报告里的错数，用户下周可能脱离对话记录直接引用，所以保存下来的产物按严标准审查。聊天里一句松散的话很快就会滚出视野，只有照着它行动确实会误导用户，才需要标出。审查者守的是留得住的记录，不是闲话。

这些选择是测出来的，不是凭直觉定下的。关掉思考的代码注明：在"追溯数值"这类任务上，思考吃掉审查者大约 72% 的输出 token，召回率却几乎没有提升。不给 Python 的代码注明：三十轮生产环境审查中，Python 占 41% 的工具调用，而这些调用全是评分标准明令禁止的重算。审查者最终长成什么样，是基准测试一点点定出来的。⁺给验证器开发者的教训是：用真实评测调校评判者，不能只靠文字推演。代码还特意警告：除非重跑评测，否则不要随手改提示词。

BOOKMARKER 复用同一套检查点机制，用途更窄：留下可点击的路标，让回访用户直接跳回原文。每个窗口最多引用两句原文，往往一句也不引。它的提示词经过 62 个金标准检查点窗口的评测，一轮轮调校而成。代码注释同样警告：改措辞前先重跑评测，因为好几处看似合理的修改，实测反而降低了分数。在 0.1.15 里，bookmarker 已经做好、也经过测试，却默认关闭。因此，它是暂未启用的能力，不是正在运行的审查者。⁺本地检查找到两个隐藏的审查者 frame，四行 verification_checks 记录全是 pass，没有 bookmarker frame。这说明审查在本地跑过，但没测准确率，也没走遍每条分支。

You are the REVIEWER — a transcript reviewer.

You receive pointers into another agent's conversation … read that transcript and report where it fabricated, hallucinated, or deviated.

Trace, don't recompute. If the agent claims a number, find the cell that printed it and compare — a CONTRADICTION is the finding. A value you simply cannot trace inside this window is NOT a finding …

Weight by WHERE the claim lives. Artifact contents (saved files, figures, tables, reports) are the session's durable output … Hold these to the strict bar. Assistant prose is chat narration the user skims in the moment — flag only if a reader ACTING on it would be materially misled.

Call submit_output ONCE with your findings and stop — do not write any assistant prose before or after it.

You are the BOOKMARKER — you leave breadcrumbs in another agent's transcript so a returning user can jump straight to what matters.

You receive a window of an agent's work … Decide what — if anything — a user reopening this session tomorrow would want to click straight back to, and return 0-2 VERBATIM quotes via submit_output.

THE ONE QUESTION
Imagine the user scanning this session later: "where's the result? what did it produce? what was decided?" Bookmark the exact sentence(s) they'd want to land on. Nothing else.

HOW MANY
Most windows deserve 0 or 1. … If nothing landed in this window — it's routine churn, setup, or work still in flight — return an empty list; that is the normal outcome.

Call submit_output ONCE with your bookmarks (or an empty list) and stop — no assistant prose before or after it.

它按独立窗口运行，不是定时任务

审查不按钟点触发。运行器每次派发一批工具调用前，都会问两件事：离上次检查点够不够久？这期间有没有积累真正的工作？按默认值，至少要过去 120 秒，还要出现三种信号之一：三个新产物、一个结构化 Markdown 块，或两千个字符的原创输入。单纯等待不会触发审查；有活动却没有合格信号，也不会触发。容易被误读成 cron 周期的两个"120 秒"，一个是检查点之间的最小间隔，一个是合并窗口的暂缓时间，都不是心跳。

检查点触发时，验证器会给一个有边界的窗口拍快照：消息，加上执行、产物、计划、溯源的上下文。随后，它派出一个脱离主循环的审查者。若已有审查者在忙，新单元就并入待处理窗口；否则，暂缓计时器先让相邻工作聚在一起。这样，相邻证据可以合成一次较大的审查，可见对话里却不会出现"请检查我"的自省循环。这张图展示了判定条件和两个计时器。⁺"后台"在这里有精确含义。一次审查可以在主会话推进时继续运行，但是否触发，仍由运行器在边界上判断。它既不是空转的进程，也不是按挂钟运行的 cron。

审查能改变控制流

一个只在完成后加个徽章的审查者，不过是数据统计。Claude Science 的审查者，参与流程控制。

任务正常收尾前，要先过一道审查屏障。它判断尚未审查的尾段是否需要最后一个检查点，派发暂存的单元，再等待正在运行或排队的审查结束。随后，它依次处理审查通知。若有一条需要送达，运行器便把它注入会话，将打回计数加一，保存状态，并否决本次收尾，要求主智能体继续处理。

打回次数默认封顶在三次。这挡住了审查者和主智能体把会话困在一场没完没了的争执里。

最强的一例，是委派出去的结果。子智能体把结构化输出交给父智能体；审查者若抢先判它不合格，运行器会在父智能体看到之前丢弃输出。随后，子智能体会被送回去，改正或反驳问题，再重新调用 submit_output。在修正结果返回或重试额度耗尽之前，父智能体什么也拿不到。

审查者能作废智能体之间的一次交接，不只是标记一下。

三刀之后，留下什么

Claude Science 不只是一个替科学家写 Python 的 AI。它是一套以守护进程为中心、从工作一路管到证据的框架。内核留住长时间分析所需的状态，权柄却留在守护进程手里。代码压缩工作，能力边界仍然有效。产物记录可以把结果、版本、输入、执行记录、环境一并保存。审查从主循环之外核对这些记录，还能拦住尚未过关的结果。

这些都不是科学独有的。一个认真的领域智能体，不靠更长的系统提示词，也不靠更宽的工具菜单。真正要决定的是：哪些对象必须留存，哪些边界必须守住，证据与智能体发生冲突时，系统还能在哪里叫停。Claude Science 最值得借鉴的因此不是某项功能，而是一条架构原则：工作状态留在内核，权柄和历史归守护进程，两者之间始终有一条连续的证据链。

三个预测

上面写的是我从 0.1.15 里实际看到的架构。下面三点是预测，不是反向工程结论。它们还来自我对 Claude Code 演进路径的观察：框架不只把模型能力交到用户手里，其中积累的真实工作流和反馈，也会反过来塑造后续模型。Anthropic 的 Development Partner Program 允许自愿加入者分享 Claude Code 会话，用来改进模型[2]。沿着这条路，我有三个判断：

1. Anthropic 会以 Opus 或 Fable 为底座，训练或微调一个专攻生命科学的模型。
2. Claude Science 会随一次重要的新模型发布走到 v1.0。无论这个模型是否明确标成生命科学模型，Claude Science 积累的真实工作流和反馈都会参与塑造它，正如我判断 Claude Code 已经影响了 Anthropic 近期的编程模型。
3. Anthropic 已经开展并支持生物实验研究[3]。我判断，这些计划会把模型、框架、实验室接成更紧的反馈回路，加快三者共同演进。

这三点是预测。前面拆出的架构，是我认为它们可能成真的理由。我也因此更想看这个产品接下来会长成什么样。