Claude 接管约束优化：LLM 正在替人做实验设计

上周 Elliot Smith 发了一篇博客，讲他怎么把 Claude 接进一个约束优化的工作流里。乍看是又一篇 AI 编程心得，但读到中间你会发现事情不太一样——他不是让 Claude 帮他写代码，是让 Claude 自己去想应该跑什么实验、调什么参数、看哪些指标。人只在最后看结论。

这事儿放两年前会被当成营销话术。但 2026 年年中的现在，从 Karpathy 亲自下场的 autoresearch，到 Claude Code、Codex、甚至 AutoResearchClaw 的多路复现，一个明确的信号已经浮出水面：LLM 参与数学搜索和实验设计，不再是 demo，是正在被工程化的方法论。

从「写代码」到「做研究」的临界点

先说 Elliot 的那个案例，它是理解这波变化最干净的样本。

他要解决的问题很典型：一个带约束的组合优化问题，参数空间大到没法穷举，传统的求解器要么慢要么不收敛。以前的做法是——搞个启发式算法，人肉调半天参数，跑一晚上看结果，第二天再来。

Elliot 干的事情是：把问题的形式化描述、约束条件、评价指标写成一份 markdown 规格，扔给 Claude Code，让它自己迭代。Claude 会读规格、写求解器代码、跑测试、看输出、修改策略、再跑一轮。整个过程 Elliot 只是在旁边看着，偶尔在方向明显走偏时干预一下。

有意思的不是「Claude 能写求解器」——这个能力早就有了。真正的变化是决策权的转移：以前是「人想清楚要做什么，让 AI 去执行」，现在变成「人给出目标和约束，AI 自己决定路径」。

这个差别听起来微妙，但工程含义很重。它意味着 LLM 不再只是一个更聪明的补全器，而是可以承担研究流程里最耗时的那部分——试错。

Karpathy 的 autoresearch：把研究组织写进 markdown

把这个思路推到极致的是 Karpathy。他今年年初开源的 autoresearch 项目，本质上就是一套用 markdown 编程的研究流水线。

项目地址在 GitHub 上，结构简单得让人怀疑是不是遗漏了什么：

• program.md：人写的行为指令，定义 Agent 怎么实验、怎么评估、怎么决定保留还是回滚
• train.py：模型代码，Agent 自己改
• 剩下的就是让 Claude Code 或 Codex 自己跑

Karpathy 在项目里那段话已经在推特被反复引用：「前沿 AI 研究曾经由肉体大脑完成，他们在吃饭、睡觉之间挤出时间做研究……那个时代早已过去。」这话有 Karpathy 一贯的戏剧感，但底下的判断是认真的——当 Agent 能够在有明确指标的环境里自我改进，很多研究工作就可以被外包给算力。

关键在「有明确指标」这五个字。ML 训练天然满足：loss 曲线、验证集准确率、推理延迟，全都是可测量的数字。Agent 修改一版 train.py，跑起来，看指标，好就保留，差就回滚。这个循环闭合，就不需要人一直盯着。

复现潮：Claude、Codex、龙虾各自展开

autoresearch 火了之后，社区的复现和扩展来得非常快。目前值得关注的有几个方向：

Codex Autoresearch（leo-lilinxiao/codex-autoresearch）走的是泛化路线。Karpathy 只做 ML 训练，Codex 版本把「有指标就能自主研究」的逻辑推广到所有软件工程场景——性能优化、测试覆盖率提升、bug 修复率，任何能量化的目标都可以塞进这个框架。

Claude Autoresearch（uditgoenka/autoresearch）是 Claude Code 平台上最完整的一个，做成了 9 个命令的 skill 插件。安装方式很直接：

git clone https://github.com/uditgoenka/autoresearch.git
cp -r autoresearch/claude-plugin/skills/autoresearch .claude/skills/autoresearch
cp -r autoresearch/claude-plugin/commands/autoresearch .claude/commands/autoresearch

用起来是这种感觉——你给一个目标和验证方式：

Goal: Increase test coverage from 72% to 90%.
Verify: npm test -- --coverage | grep "All files"

剩下的 Claude 自己搞。它会读代码库、找覆盖率低的地方、写测试、跑测试、看结果、迭代。你早上起来看它跑了多远就行。

AutoResearchClaw（aiming-lab/AutoResearchClaw）野心最大，做成了一个 23 阶段、8 个 Phase 的全自动流水线，覆盖从「研究范围界定」到「实验执行」再到「论文草稿生成」的完整链路。产出物是一份 paper_draft.md，包含引言、相关工作、方法、实验、结论。听起来很科幻，但项目在 GitHub 上是开源的，可以自己去看流水线定义。

几个项目的核心差异其实很清楚：

| 项目 | Agent 平台 | 适用范围 | 自动化程度 | |------|-----------|---------|-----------| | Karpathy autoresearch | 任意 | ML 训练 | 中 | | Codex Autoresearch | OpenAI Codex | 所有软件工程 | 中高 | | Claude Autoresearch | Claude Code | 通用开发场景 | 高 | | AutoResearchClaw | 多平台 ACP | 学术研究 | 极高 |

约束优化为什么是个好切口

回到 Elliot 那篇博客。他挑约束优化作为例子，我觉得不是随手选的。这个场景对 LLM 特别友好，原因有三个：

第一，问题描述可以完全形式化。 约束条件、目标函数、可行域——都是可以用数学语言精确表达的东西。LLM 不用猜你想干什么，读一遍规格就懂。

第二，反馈信号干净。 每跑一次求解器，输出的是一个可行解和一个目标值。好坏一目了然，不需要人来判断。这跟让 LLM 写一段前端代码然后问「这个 UI 好看吗」完全不是一个难度级别。

第三，搜索空间大到人类也玩不转。 传统上组合优化靠的是数学家精心设计的启发式，但设计启发式本身也是一种搜索——搜索算法空间。LLM 的通用知识让它可以在算法空间里做启发式搜索，这比人类的直觉快得多。

翁荔今年那篇 Harness 工程的博客里也提到过类似的思路。AFlow 那套东西把智能体工作流表示成一张图，节点是 LLM 调用，边是代码逻辑，然后用蒙特卡洛树搜索来优化这张图。同样是让 LLM 参与结构搜索，本质是一回事。

真实效果：一个数字

Instagram 上流传的一个案例值得记一下。某位开发者 3 月份把一个训练优化任务交给 autoresearch 工具，两天内把训练时间从原来的时长压到了 1 小时 48 分钟。具体的 baseline 没写清楚，但压缩比例是真实的。

这就是我说的临界点意义。你可以争论 LLM 「真的懂不懂」优化，但当它能在两天内做完一个熟练工程师一周的工作，「懂不懂」就变成一个纯哲学问题了。工程上，有用就是有用。

别急着上头：这套东西的边界

讲了这么多好话，得说点冷的。

第一，指标依赖症。 autoresearch 这套逻辑的前提是「有明确、可自动测量的指标」。ML 训练有 loss，软件工程有测试，但很多真实场景没有这么干净。产品好不好用、代码可维护性、架构决策的长期影响——这些东西 Agent 自己是判断不了的。你硬塞进去，它会给你一个技术上满足指标但业务上完全错的答案。

第二，成本还是问题。 一个 Agent 跑一晚上，Token 消耗不是小数。如果你用 Claude Opus 或者 GPT-5 Pro 级别的模型全程 driving，一个中等规模的实验跑下来账单可能相当可观。这也是为什么现在的 autoresearch 实践里，很多人会做分层——便宜的模型负责执行和数据整理，只有决策节点才调用旗舰模型。ARIS 那个项目（Auto-claude-code-research-in-sleep）的核心机制就是跨模型协作，Claude Code 干活，外部 LLM 出主意。

第三，方向盘还得握着。 Karpathy 自己在项目 README 里也说了，autoresearch 不是让人退休，是让人从执行者变成方向的把关人。你不看着，Agent 会朝一个局部最优里越走越深，最后给你一个技术上完美但完全跑偏的方案。

对开发者意味着什么

如果你在写代码——尤其是那种需要反复试参数、跑实验的活儿——现在真的应该花个周末试试这套东西。门槛比想象中低。Claude Code 或者 Codex 的 CLI 装好，把上面几个仓库 clone 下来，读一遍 program.md 的模板，套着自己的问题写一份 spec，就可以开始跑。

实际工程里，我建议从两类任务切入：

• 超参搜索和消融实验：这是 autoresearch 最舒服的场景，指标干净、循环封闭，Agent 跑几十轮不用你操心。
• 代码性能优化：给一个 benchmark，让 Agent 自己想优化方向。比人肉调优省事，而且它会尝试你可能想不到的路径。

对于新模型的接入，如果要在同一个工作流里对比 Claude、GPT、Gemini 的表现——这个场景越来越常见，因为不同模型对不同问题的直觉差别很大——用 OpenAI Hub 这种聚合平台会省掉很多 Key 管理和路由的麻烦，国内直连也不用折腾网络。同一个 spec 分别喂给三个模型，看谁跑出来的解更好，这在两年前是纯理论探讨，现在是真能落地的对比实验。

结尾一句

2026 年最有意思的事情不是又出了什么新模型，是我们对「AI 能干什么」的想象终于开始追上模型的实际能力。autoresearch 这波东西的价值不在具体某个仓库，而在它把一个思路做透了：LLM 不只是补全你的下一行代码，它可以承担整个「试错-学习-迭代」的循环。

剩下的问题就是——哪些循环适合外包，哪些还得亲自跑。这是接下来一年每个工程师都要给自己回答的问题。

参考来源

• karpathy/autoresearch (GitHub) — Karpathy 的原始项目，用 markdown 编程的研究组织雏形
• uditgoenka/autoresearch (GitHub) — Claude Code 平台上最完整的 autoresearch 插件实现
• leo-lilinxiao/codex-autoresearch (GitHub) — 把 autoresearch 泛化到所有软件工程场景的 Codex 版本
• aiming-lab/AutoResearchClaw (GitHub) — 覆盖 23 阶段的全自动学术研究流水线
• wanshuiyin/Auto-claude-code-research-in-sleep (GitHub) — 跨模型协作的自主 ML 科研工作流实现
• Karpathy 的 AutoResearch 指南：用 AI 智能体自动化机器学习 (知乎) — 关于 autoresearch 核心思路的中文详解
• 翁荔博客又上新：通过 Harness 工程实现 AI 自我提升 (知乎) — AFlow 与智能体工作流搜索的相关讨论