# 解剖 Claude Science *Claude Science 是一套守护进程居中的智能体框架，管执行，管留得住的产物，也管验证。* - 作者: Feitong Yang (https://www.feitong.phd/about/) - 发布日期: 2026-07-06 - 原文链接: https://www.feitong.phd/zh/essays/dissecting-claude-science-zh/ - 主题: technical, ai, science --- 2026 年 6 月 30 日，Anthropic 发布 Claude Science。它看上去只是个简单的本地应用。启动它，弹出来的不是常规桌面窗口，而是浏览器里一个 localhost 页面。真正的新意藏在界面底下：Anthropic 把科研工作台本身做成了一套智能体框架（agent harness）。一个守护进程居中，从正在运行的分析，一路管到最终产物（artifact）背后的证据。 从界面上看，它用起来并不陌生。你打开一个项目，跟一个智能体对话，看它写代码、跑代码，然后收到一张图、一个表、一个结构，或一份报告。系统生成的产出，还能亮出背后的代码。我就是顺着这段代码摸进架构的。在一次生成的分析里，我看到这样一个调用： ```python 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` 初始化一个普通的持久命名空间，留下这么一句注释： ```python # 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 次调用；模型只写一次循环，也只读一个结果。代码把迭代挪出了语言模型。 所以，代码不只用来分析返回的数据，也是编排的压缩格式。这一刀余下的部分，讲的是怎样约束这种压缩：代码跑在按能力裁剪的进程里，进程之间的边界也经过明确划分。 主 `OPERON` 提示词把工作流讲得很直白。MCP 调用走 `repl`，不走 Python 或 R。对样本或记录的循环，应该在一个 REPL 代码单元格里跑完。结果要序列化进 `./handoff/.json`，再由分析内核加载。一次 Python 调用应该装下一个完整的逻辑分析步骤，因为哪怕内核本身持久，每次调用也要花一整个模型往返。 ### 控制内核与数据内核 控制 REPL 运行隔离的 Python，只带标准库。它拿到的是编排类片段：MCP、agent、技能、frame 查询、委派、结构化输出，以及按算力提供方门控的远程计算。包更齐全的 Python 和 R 内核则没有这些界面，只能使用产物查找、溯源、模型调用、凭据等分析方法。 分析代码尝试调用 `host.mcp` 时，SDK 不会假装这个方法存在。`AttributeError` 会直接说明：这个内核没有连接器界面；请到 `repl` 取数，把 JSON 写进 `./handoff`，再由 Python 读取。同类的教学式报错也覆盖 agent、技能、计算、查询、frame、执行控制、结构化输出。报错还点明进程边界：这些内核共享工作区的当前目录，却不共享内存。 | host 界面 | 分析用 Python/R | Operon 控制 REPL | 审查者 | | ----------------------------- | --------------- | ------------------ | ----------- | | 产物、溯源 | 有 | 有 | 只读 | | 模型调用 | 有 | 有 | 无 | | MCP、agent、技能 | 无 | 有 | 无 | | 计算、委派、提交产出 | 无 | 按配置/提供方门控 | 无 | | frame 与数据库自省 | 无 | 有 | 有限只读 | 不注入某些 SDK 方法，只是第一道关卡，不是安全边界。这种做法会用一条明确的报错教会智能体怎样调用 API。真正的权柄在守护进程的许可集里。就算内核代码硬造一个 `_host_call("mcp", ...)`，分析内核的许可集也会拒绝。MCP 处理器还会继续检查 Operon 内核、身份认证、连接器解析、schema 校验、策略审批。 代码也是一条能力边界。第三方科研包在有状态的分析内核里跑；连接器访问、agent 修改则留在更窄的控制内核。一个 pandas 对象不能把引用直接从 Python 递进 `repl`，必须先变成文件。这多了一步，却让跨越有了名字，可以检查，可以哈希，也可以纳入产物溯源。 ### 有持久状态，内核却不掌权 Python worker 是一个长命的子进程，带一个持久命名空间。它接收 JSON 请求，把每个单元格编译进一个合成文件名（比如 ``），在 `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 把这条链当成头等的状态，而不是事后临时凑的一段话。 ### 产物背后的代码是怎么重建的 没有哪一个神奇的"重建代码"函数。这套系统把好几条证据线拼起来。 如果一项产物直接从有记录的单元格存下来，`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。这说明审查在本地跑过，但没测准确率，也没走遍每条分支。 ### 它按独立窗口运行，不是定时任务 审查不按钟点触发。运行器每次派发一批工具调用前，都会问两件事：离上次检查点够不够久？这期间有没有积累真正的工作？按默认值，至少要过去 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 会话，用来改进模型。沿着这条路，我有三个判断： 1. Anthropic 会以 Opus 或 Fable 为底座，训练或微调一个专攻生命科学的模型。 2. Claude Science 会随一次重要的新模型发布走到 v1.0。无论这个模型是否明确标成生命科学模型，Claude Science 积累的真实工作流和反馈都会参与塑造它，正如我判断 Claude Code 已经影响了 Anthropic 近期的编程模型。 3. Anthropic 已经开展并支持生物实验研究。我判断，这些计划会把模型、框架、实验室接成更紧的反馈回路，加快三者共同演进。 这三点是预测。前面拆出的架构，是我认为它们可能成真的理由。我也因此更想看这个产品接下来会长成什么样。