在这篇文章中，Discovery 团队的研究员 Siddharth Mishra-Sharma 解释了如何将多日智能体编码工作流——测试预言机、持久记忆和编排模式——应用于科学计算任务，即使这些任务超出了自己的专业领域。
基本前提
目前大多数使用 AI 智能体的科学家都处于对话式循环中，每一步流程都受到严密管控。随着过去一年左右模型在长周期任务上的能力显著提升，一种新的工作方式应运而生：我们不再介入每个细节，而是指定高层目标，然后让一组智能体自主工作。这使得原本需要数天、数周甚至数月才能完成的项目，在短短几小时内就能完成。某些类型的科学任务非常适合这种模式，例如：重新实现数值求解器、将用旧版 Fortran 方言编写的传统科学软件转换为现代语言，以及根据参考实现调试大型代码库。这些任务的范围界定清晰，成功标准明确，人工监督只需偶尔进行，无需持续介入。
Anthropic 的 C 编译器项目展示了这种模式的一个版本：Claude 在大约 2000 个会话中工作，构建了一个能够编译 Linux 内核的 C 编译器。本文描述了如何以典型学术实验室为背景，使用 Claude Code 为科学计算任务设置类似的模式。作为具体示例，我将演示如何使用 Claude Opus 4.6 实现宇宙学玻尔兹曼求解器的可微版本。这是一种数值代码，用于预测大爆炸余辉——即宇宙微波背景辐射（CMB）——的统计特性。它通过演化早期宇宙中光子、重子、中微子和暗物质的耦合方程来实现这一目标。
像 CLASS 和 CAMB 这样的玻尔兹曼求解器是宇宙学中核心的科学基础设施，使我们能够利用普朗克卫星和西蒙斯天文台等巡天项目的数据来约束宇宙学模型。一个可微分的版本——即能够通过整个求解器传播梯度的版本——使得基于梯度的推理方法得以应用，从而大幅加速参数估计。用 JAX 编写这一求解器是自然而然的选择，因为它能几乎零成本地为我们提供自动微分能力以及与加速器（例如 GPU）的兼容性。值得注意的是，这项任务并不属于我的核心科学领域——我对相关工具和科学原理有较高层面的了解，但缺乏在合理时间内独立完成它的专业知识。拥有这方面专业知识的团队已经用 JAX 构建了具备 CLASS 部分功能的可微分求解器。这些工作通常需要耗费研究人员数月到数年的时间。这里的重点在于，想看看一个智能体能否在非领域专家的最小引导下取得更大进展。
这类任务在结构上不同于 C 编译器项目，后者可以分派给大量并行工作的智能体。而玻尔兹曼求解器则是一个深度耦合的流水线——在对早期宇宙如何复合进行建模时，一个微小的数值误差或欠佳的近似，都会微妙地影响下游所有环节。因此，它需要一套不同的智能体技能。调试需要从因果链条上追溯整个过程，并借助领域知识，这可能更适合由单个智能体按顺序工作，在需要时生成子智能体，并利用参考实现来二分查找差异所在。
我们将使用运行 SLURM 作业调度器的高性能计算集群作为计算环境，但核心思路——进度文件、测试预言机、包含清晰规则的智能体提示词——无论你在何处运行 Claude Code 都适用。
起草计划并在本地进行迭代。
在向管理自主智能体研究团队这一模式转变的过程中，你应将大部分时间（与 Claude 协商）用于编写一套指令，这套指令需清晰阐明项目的交付成果及相关背景。这些指令应存放在根目录下的 `CLAUDE.md` 文件中。Claude 会特殊对待此文件，将其保留在上下文中，并据此参考整体计划。关键在于，Claude 可以在工作过程中编辑这些指令，在解决问题的同时，为后续工作更新指令内容。
以下是一个宇宙学玻尔兹曼求解器项目的早期 `CLAUDE.md` 文件，展示了在初步尝试编写求解器后，所确立的整体计划和设计决策。为了得到这份文件，我明确了项目的高层目标——在实现与参考实现 CLASS 完全功能一致的同时，具备完全可微性，并设定主要科学交付成果相对于 CLASS 的精度目标为 0.1%——然后与 Claude 反复迭代，直到计划令人满意。考虑到 0.1% 是两大经典玻尔兹曼代码 CLASS 和 CAMB 之间通常的吻合程度，这看起来是一个合理的科学目标。
跨会话记忆
进度文件（我们按惯例在此称之为 `CHANGELOG.md`）是智能体的便携式长期记忆，起到类似实验记录的作用。在 `CLAUDE.md` 中，Claude 被指示在此文件中记录进度。
一份好的进度文件可能会记录当前状态、已完成的任务、失败的方法及其失败原因、关键检查点的精度表格，以及已知的限制。记录失败的方法很重要——否则，后续的会话会重复尝试同样的死胡同。一条记录可能看起来像这样：“尝试使用 Tsit5 求解扰动 ODE，系统过于刚硬。已切换至 Kvaerno5。” 以下是示例项目的变更日志，展示了这些要素。
测试预言
虽然通过智能体进行更开放式的科学发现确实已近在眼前，但长期自主的科学工作目前关键取决于智能体是否有办法知道自己是否在取得进展。对于科学代码而言，这可以是一个参考实现、一个可清晰量化的目标，或是一套现有的测试套件。同时，指导智能体在推进过程中扩展测试套件并运行测试，以防止回归问题，也会很有帮助。在我的示例任务中，Claude 被指示以 CLASS C 源码作为参考实现，构建并持续运行单元测试。
Git 作为协调工具
Git 可以成为以非介入方式监控和协调智能体进度的好方法。智能体应在每个有意义的阶段性工作完成后执行提交和推送操作。这样，如果出现意外情况，你就拥有可恢复的历史记录；能让进度在本地可见；还能防止工作丢失——例如，当你的计算配额在会话中途耗尽时。
实际操作中，这可以是在 CLAUDE.md 中设置的一组指令，例如：“在每个有意义的阶段性工作完成后执行提交和推送。每次提交前运行 `pytest tests/ -x -q`。绝不提交会破坏现有通过测试的代码。”
若要引导智能体，你可以随时通过 SSH 登录集群，手动重新输入提示词和/或更新其指令。更符合人体工程学的做法通常是让本地运行的 Claude Code 实例通过 SSH 登录并为你执行命令；这也适用于下文描述的所有操作。
执行循环
如上所述，通常最好先在本地对计划进行迭代，直到得到一个看起来合理且已编码到 CLAUDE.md 中的计划。然后，在计算节点上的 tmux 等终端复用器中启动一个 Claude Code 会话，告诉智能体你的代码库在哪里，然后让它自行运行。由于会话在 tmux 内部运行，你可以分离会话、合上笔记本电脑，并偶尔检查进度（以玻尔兹曼求解器为例，我会在手机上查看 GitHub，比如在排队买咖啡的时候）。
在 HPC 集群上，你可以通过 SLURM 调度器请求一个节点，一个在 tmux 会话中启动 Claude Code 的示例作业脚本可能如下所示：
#!/bin/bash
#SBATCH --job-name=claude-agent
#SBATCH --partition=GPU-shared
#SBATCH --gres=gpu:h100-32:1
#SBATCH --time=48:00:00
#SBATCH --output=agent_%j.log
cd $PROJECT/my-solver
source .venv/bin/activate
export TERM=xterm-256color
tmux new-session -d -s claude "claude; exec bash"
tmux wait-for claude任务开始后，你接入 tmux 会话，向 Claude Code 下达指令（例如“读取 CHANGELOG.md 并接手下一个任务”），确认它走上正轨后即可断开连接。你可以随时重新接入来检查进度、调整方向，或使用类似以下命令启动新任务：
srun --jobid=JOBID --overlap --pty tmux attach -t claudeRalph 循环：随着模型能力不断增强，它们对提示词工程、RAG 或上下文填充这类定制化编排的需求会越来越少。然而，在特定时间点，提供一定程度的脚手架支持作为能力提升手段仍然是有用的。例如，当前模型可能存在智能体惰性问题——当被要求完成一项复杂的多步骤任务时，它们有时会找借口在完成全部任务前停下来（“天色已晚，我们明天再继续吧？”）。
为解决这一问题，一种有用的编排模式是 Ralph 循环。它本质上是一个 for 循环，当智能体声称任务完成时，会将其重新拉回上下文，并询问它是否真的完成了。这对于长时间运行的任务很有用，因为智能体会承认任务未达到标准，并继续工作直到达标。其他类似的模式包括 GSD（及其领域特定变体）以及 Claude Code 原生的 `/loop` 命令。
可通过 `/plugin` 安装 Ralph。在 Claude Code 中，典型的调用提示词可能如下所示：
/ralph-loop:ralph-loop “Please keep working on the task until the success criterion of 0.1% accuracy across the entire parameter range is achieved.” --max-iterations 20 --completion-promise “DONE”在这里，Claude 会最多迭代 20 次，直到它通过“DONE”指令保证任务完成。
结果
Claude 在几天内从头开始处理该项目，在其各项输出中达到了与参考 CLASS 实现低于百分之一的误差。我要求 Claude 在项目过程中重建代码部分主要输出（即各种 CMB 角功率谱）的精度，同时标注开发过程中的里程碑。它生成了下图，展示了达到亚百分比精度的路径。
该智能体的发展轨迹略显笨拙。例如，其测试覆盖存在明显缺口——有段时间它只在单个（基准）参数点上测试代码，大幅缩小了其捕捉错误的覆盖面。它还会犯一些低级错误，比如在规范约定上出错，或者花数小时追踪一个宇宙学家一眼就能看出的错误，但它始终朝着既定目标（亚百分比精度）持续取得进展。
该项目的一个附带效应是，通过观察 git 提交历史，我意外地学到了大量关于玻尔兹曼求解器及其所模拟物理的知识。这个项目并非源自我的核心科学领域，但跟随 Claude 的渐进式进展并查阅我不认识的内容，结果证明是一种有效吸收科学知识的方式。提交日志读起来就像一位快速、极度字面理解的博士后的实验笔记。
虽然最终得到的求解器尚未达到生产级水平（例如，它并非在所有情况下都能与参考的 CLASS 实现达到可接受的精度），但它证明了智能体驱动的开发可以将研究人员数月甚至数年的工作压缩到几天内完成。
这种压缩改变了什么才算作空闲时间。AI 研究中一个普遍的经历是，晚上启动一个实验（例如，一次训练运行），然后在早上看到结果时获得满足感。不运行实验会带来机会成本。如今，不运行智能体似乎也伴随着成本。如果你拥有算力以及定义明确成功标准的项目，那么每一个没有智能体为你工作的夜晚，都是被搁置的潜在进展。
致谢
我们感谢 Eric Kauderer-Abrams 的同行评审，以及 Xander Balwit、Ethan Dyer 和 Rebecca Hiscott 提供的有益反馈。
加拿大如何使用 Claude：来自 Anthropic 经济指数的发现
Claude 在不同模型和语言中的价值观
In this post, Siddharth Mishra-Sharma, a researcher on the Discovery team, explains how to apply multi-day agentic coding workflows—test oracles, persistent memory, and orchestration patterns—to scientific computing tasks even outside of one’s domain.
The premise
Most scientists currently using AI agents work in a conversational loop, managing each step of the process on a tight leash. As models have become significantly better at long-horizon tasks over the last year or so, a new way of working emerged: rather than getting involved with every detail, we can specify the high-level objective and set a team of agents loose to work autonomously. This makes it possible to complete projects in mere hours that might otherwise take us days, weeks, or even months. Certain types of scientific tasks fit well within this model, e.g., reimplementing a numerical solver, converting legacy scientific software written in an old Fortran dialect to a modern language, and debugging a large codebase against a reference implementation. These are tasks where the work is well-scoped, the success criteria are clear, and human oversight can be occasional rather than continuous.
Anthropic’s C compiler project demonstrated a version of this, where Claude worked across roughly 2,000 sessions to build a C compiler capable of compiling the Linux kernel. This post describes how to set up a similar pattern for scientific computing tasks using Claude Code, with a typical academic lab in mind. As a concrete example, I will walk through using Claude Opus 4.6 to implement a differentiable version of a cosmological Boltzmann solver. This is numerical code that predicts the statistical properties of the afterglow of the Big Bang—the Cosmic Microwave Background, or CMB. It does this by evolving coupled equations for photons, baryons, neutrinos, and dark matter through the early universe.
Boltzmann solvers like CLASS and CAMB are core pieces of scientific infrastructure in cosmology, allowing us to constrain cosmological models using data from surveys like Planck and the Simons Observatory. A differentiable version—one that can propagate gradients through the full solver—enables the use of gradient-based inference methods, dramatically speeding up parameter estimation. Writing it in JAX is a natural fit here, since it gives us automatic differentiation and compatibility with accelerators (e.g., GPUs) essentially for free.
Notably, the task isn’t in my core scientific domain—I have a high-level familiarity with the tools and the science, but don’t have the expertise to complete it myself in any reasonable time frame. Groups who do have that expertise have built differentiable solvers in JAX with a subset of the features present in CLASS. These efforts typically represent months to years of researcher-time. The point here was to see if an agent could go further with minimal steering from a non-domain expert.
This kind of task is structurally different from the C compiler project, which can be farmed out to a large number of parallel agents. A Boltzmann solver, on the other hand, is a deeply coupled pipeline—a small numerical error or poor approximation in modeling how the early universe recombines can subtly shift everything downstream. It thus requires a different set of agent skills. Debugging requires tracing causally through the entire chain and drawing from domain knowledge, which may be better suited to a single agent working sequentially, spawning subagents as needed, and using the reference implementation to bisect discrepancies.
We'll use an HPC cluster running the SLURM job scheduler as our compute environment, but the core ideas—a progress file, a test oracle, an agent prompt with clear rules—apply regardless of where you run Claude Code.
Draft a plan and iterate locally
In this shift toward managing an autonomous research team of agents, you should spend most of your time (in consultation with Claude), crafting a set of instructions that clearly articulates the project’s deliverables and relevant context. These instructions should live in a CLAUDE.md file located in the root directory. Claude treats this file specially, keeping it in context and referencing it for the overall plan. Crucially, Claude can edit these instructions as it works, updating them for future work as it works through issues.
Here is an early CLAUDE.md for the cosmological Boltzmann solver project, showing the overall plan and design decisions codified after an initial attempt at writing the solver. To arrive at this, I specified the high-level goals of the project—achieving full feature-parity with the reference CLASS implementation while being fully differentiable, and having an accuracy target of 0.1% against CLASS in the main science deliverables—and iterated with Claude until the plan seemed satisfactory. Given that 0.1% is the typical level of agreement between the two canonical Boltzmann codes CLASS and CAMB, this seemed like a good science target.
Memory across sessions
The progress file, which by convention we call here CHANGELOG.md, is the agent’s portable long-term memory, acting as a sort of lab notes. In CLAUDE.md, Claude was instructed to keep track of progress in this file.
A good progress file might track current status, completed tasks, failed approaches and why they didn't work, accuracy tables at key checkpoints, and known limitations. The failed approaches are important—without them, successive sessions will re-attempt the same dead ends. An entry might look like: “Tried using Tsit5 for the perturbation ODE, system is too stiff. Switched to Kvaerno5.” Here is the changelog for the running example, showing these elements.
The test oracle
While more open-ended scientific discovery via agents is certainly on the horizon, long-running autonomous scientific work today crucially depends on the agent having a way to know whether it’s making progress. For scientific code, this could be a reference implementation, a clearly quantifiable objective, or an existing test suite. It can also be helpful to instruct the agent to expand the test suite and run tests as it works, to prevent regressions. In my example task, Claude was instructed to construct and continuously run unit tests using CLASS C source as a reference implementation.
Git as coordination
Git can be a good way to monitor and coordinate the agent’s progress in a hands-off manner. The agent should commit and push after every meaningful unit of work. This gives you a recoverable history if something goes awry, makes progress visible locally, and prevents work from being lost if, for instance, your compute allocation runs out mid-session.
Practically, this could be a set of instructions in CLAUDE.md, e.g. “Commit and push after every meaningful unit of work. Run `pytest tests/ -x -q` before every commit. Never commit code that breaks existing passing tests.”
For steering the agent, you can always SSH into the cluster and manually re-prompt and/or update its instructions. It is typically more ergonomic to simply ask a local instance of Claude Code to SSH in and run commands for you; this will also apply to everything described below.
The execution loop
As mentioned above, it’s often useful to first iterate on the plan locally until you have one that looks reasonable and is encoded in CLAUDE.md. From there, start a Claude Code session inside a terminal multiplexer like tmux on a compute node, tell the agent where to find your codebase, and let it cook. Because the session runs inside tmux, you can detach, close your laptop, and occasionally check on progress (in the case of the Boltzmann solver, I would check in on GitHub on my phone, e.g. while waiting in line for a coffee).
On an HPC cluster you might request a node through the SLURM scheduler, and an example job script that launches Claude Code in a tmux session might look like the following:
#!/bin/bash
#SBATCH --job-name=claude-agent
#SBATCH --partition=GPU-shared
#SBATCH --gres=gpu:h100-32:1
#SBATCH --time=48:00:00
#SBATCH --output=agent_%j.log
cd $PROJECT/my-solver
source .venv/bin/activate
export TERM=xterm-256color
tmux new-session -d -s claude "claude; exec bash"
tmux wait-for claude
Once the job starts, you attach to the tmux session, give Claude Code direction (e.g., “Read CHANGELOG.md and pick up the next task”), and detach when you're satisfied it's on the right track. You can re-attach whenever you want to check in, steer, or start a new task using something like:
srun --jobid=JOBID --overlap --pty tmux attach -t claude
The Ralph loop: As models get more capable, they require less bespoke orchestration such as prompt engineering, RAG, or context stuffing. At a given point in time, however, it can be useful to provide some level of scaffolding as a capability uplift. For example, current models can suffer from agentic laziness—when asked to complete a complex, multi-part task, they can sometimes find an excuse to stop before finishing the entire task (“It’s getting late, let’s pick back up again tomorrow?”).
To circumvent this, a useful orchestration pattern is the Ralph loop, which is essentially a for loop which kicks the agent back into context when it claims completion, and asks if it’s really done. This can be useful for long-running tasks since the agent will admit the task is not up to spec, and continue working until it is. Other similar patterns include GSD (and domain-specific variants) as well as the native-to-Claude Code /loop command.
Ralph can be installed via /plugin. A typical invocation prompt in Claude Code could look like
/ralph-loop:ralph-loop “Please keep working on the task until the success criterion of 0.1% accuracy across the entire parameter range is achieved.” --max-iterations 20 --completion-promise “DONE”Here, Claude will iterate up to 20 times until it guarantees that the task is done with a “DONE” incantation.
The result
Claude worked on the project from scratch over a few days, reaching sub-percent agreement with the reference CLASS implementation across its various outputs. I asked Claude to reconstruct the accuracy of some of the main outputs of the code—the various CMB angular power spectra—over the course of the project, also labeling milestones during development. It produced the plot below, illustrating the path to sub-percent accuracy.
The agent’s development trajectory was somewhat clunky. For example, there were clear gaps in its test coverage—for a while it was only testing the code at a single (fiducial) parameter point, drastically reducing its bug-catching surface area. It can also make elementary mistakes, such as tripping over gauge conventions or spending hours chasing bugs that a cosmologist would spot instantly, but it kept making sustained progress towards the stated goal of sub-percent accuracy.
A side effect of the project was that I learned a surprising amount about Boltzmann solvers and the physics they model by watching the git commit history. The project isn’t drawn from my core scientific domain, but following Claude’s incremental progress and looking up what I didn't recognize turned out to be an effective way to osmose the science. The commit log reads like lab notes from a fast, hyper-literal postdoc.
While the resulting solver is not production-grade (e.g., it doesn’t match the reference CLASS implementation to an acceptable accuracy in every regime), it demonstrates that agent-driven development can compress months or even years of researcher work into days.
This kind of compression changes what counts as idle time. A universal experience in AI research is to launch an experiment (e.g., a training run) overnight and then have the satisfaction of seeing the results in the morning. Not running the experiment comes with an opportunity cost. These days, not running agents feels like it has a cost as well. If you have the compute and projects with well-defined success criteria, every night you don't have agents working for you is potential progress left on the table.
Acknowledgments
We thank Eric Kauderer-Abrams for peer-review, as well as Xander Balwit, Ethan Dyer, and Rebecca Hiscott for providing helpful feedback.