用 autoresearch 优化万物

Karpathy的推文在一个周五晚上发布。一个链接，一条损失曲线向下复合的截图，一句话：代理在你睡觉时做实验。

我在十分钟内读完了README。然后我又读了一遍。不是因为代码复杂——它特意只有630行。我再读一遍是因为代码不是重点。

要点在于约束： 一个文件，一个指标，一个循环。修改。评估。保留或丢弃。重复。

这个模式与机器学习无关。它是一个优化原语。我看到它的那一刻，就知道我要在它之上构建东西。

1、Karpathy实际构建了什么

Autoresearch有三个重要文件。prepare.py处理数据和评估基础设施——代理从不接触它。train.py是代理编辑的唯一文件。program.md是人类为代理编写策略的地方。

设计约束使其有效：

固定时间预算。 每个实验正好运行五分钟。这使得实验可以直接比较，无论代理改变什么——模型大小、批量大小、架构。代理每小时运行约12个实验，一晚100个。

单文件范围。 代理只修改train.py。这保持差异可审查且范围有界。每个实验一个更改。你知道什么有效，因为你只改了一件事。

Git作为记忆。 成功的实验被提交。失败的被还原。实验历史就是git日志。新会话可以从上一个停止的地方继续。

一个指标。 val_bpb——验证每字节比特数。越低越好。没有歧义，没有多目标权衡，没有"视情况而定"。

一周内仓库达到31,000颗星。我找到的每篇Medium文章都做了两件事之一： 复述README，或推测这是否意味着AGI即将到来。没有人用这个模式构建新东西。

所以我做了。

2、泛化：从train.py到任何有数字的东西

我问的问题很简单： 还有什么有一个文件、一个指标和一个循环？

API响应时间。包大小。测试通过率。构建速度。内存使用。标题点击率评分。提示质量评分。系统提示有效性。

所有这些都遵循相同的结构。有一个可以修改的文件。有一个产生数字的命令。越低或越高越好。代理可以尝试、测量结果并保留有效的东西。

我构建了一个autoresearch-agent技能，将Karpathy的模式泛化为AgentSkills规范——一个适用于Claude Code、OpenAI Codex、Gemini CLI、Cursor、Windsurf、OpenClaw和其他五个工具的开放标准。不是autoresearch的分支。是其核心思想的泛化。

第一个设计决策是将循环机制与领域分离。Karpathy的autoresearch是特定于ML的。但优化循环不是。

所以我引入了领域：

设置创建与Karpathy相同的刻意结构——但参数化为任何领域：

# 工程：优化API响应时间
python scripts/setup_experiment.py \
  --domain engineering --name api-speed \
  --target src/api/search.py \
  --eval "pytest bench.py --tb=no -q" \
  --metric p50_ms --direction lower
# 营销：优化标题点击率
python scripts/setup_experiment.py \
  --domain marketing --name medium-ctr \
  --target content/titles.md \
  --eval "python evaluate.py" \
  --metric ctr_score --direction higher \
  --evaluator llm_judge_content

两者都产生相同的.autoresearch/目录结构：一个config.cfg包含目标文件、评估命令、指标名称和方向。一个program.md用于代理策略。一个results.tsv记录每个实验。一个git分支跟踪复合更改。

代理协议与Karpathy的循环相同。阅读历史。决定一个更改。编辑目标文件。提交。运行评估脚本。脚本处理与先前最佳的比较、失败时的还原和日志记录。代理处理决定尝试什么的创造性工作。

每个实验一个更改。永远如此。如果你一次改变五件事，你就不知道什么有效。Karpathy做对了这一点——我保留了它。

3、最难的问题：评估不是数字的东西

Karpathy相对容易。val_bpb是一个清晰的数值指标，来自训练运行。越低越好。没有歧义。

但标题质量？提示有效性？ 系统提示的"语气"？这些没有输出浮点数的基准命令。

这是技能与原始版本差异最大的地方。

我构建了两类评估器：

免费评估器像Karpathy的设置一样工作——它们运行命令并解析数字。benchmark_speed测量p50毫秒。benchmark_size测量文件或包大小（字节）。test_pass_rate运行测试套件并报告百分比。无API成本，无歧义。

LLM评判评估器是使autoresearch适用于非工程领域的扩展。llm_judge_content对标题和描述进行0-10分评分。llm_judge_prompt对系统提示质量进行0-100分评分。llm_judge_copy评估社交媒体帖子和广告文案的参与潜力。

评判使用用户已在运行的CLI工具。Claude Code Max提供无限Claude调用。带有ChatGPT Pro的Codex CLI提供无限Codex调用。Gemini CLI有免费层。除用户已支付的订阅外无额外API成本。

关键的设计约束是：评估提示位于evaluate.py内部，代理不能修改它。 这是一条硬规则——如果我抓到代理编辑评估器，技能会指示它立即停止。

为什么？ 因为一个代理在优化指标的同时也控制指标的定义会自我博弈。它会重写评分标准使其输出得分更高。

这是小型的对齐问题，解决方案相同：将优化器与目标函数分离。Karpathy通过使prepare.py不可触碰来实现。我通过锁定evaluate.py来实现。

诚实的局限性：LLM评判不是绝对真理。ctr_score为8.4并不意味着8.4%的点击率。它意味着另一个语言模型根据你在评估提示中定义的标准给标题打了8.4分（满分10分）。

这些优化后的标题是否真正在真实读者中表现更好，是技能无法回答的问题。验证仍然属于人类。

4、策略升级：我最不确定的部分

技能包含一个关于代理应如何随时间思考实验的进展模式：

第1到第5次运行： 低挂果实。明显的改进，简单的优化。

第6到第15次运行： 系统性探索。每次改变一个参数。

第16到第30次运行： 结构性更改。算法替换，架构转变。

第30次及以后： 激进实验。完全不同的方法。

加上一个自我改进机制：每10个实验，代理审查results.tsv的模式并更新program.md的策略部分。"缓存更改持续改进5%到10%。" "重构尝试从未改进指标。" 未来迭代从积累的知识中受益。

这是我信心下降的设计部分。升级模式在纸面上听起来干净。在实践中，我还不知道代理是否会真正遵循有意义的进展，还是只是在带有策略标签的随机变体之间振荡。

我认为会发生什么： 升级在前30次运行中有效。之后，人类编写的program.md质量成为瓶颈——正如Karpathy预测的那样。他说人类的工作是*"编程研究组织，而不是运行单个实验。"* 这意味着编写更好的策略，而不是更好的代码。

自我改进部分更具推测性。一个代理在观察到三次成功的缓存实验后写下*"缓存有用"是有用的。一个代理在同样的三次实验后写下"尝试更多缓存"*是循环的。我还不知道这在大规模下会产生哪种结果。这是一个诚实的答案，我宁愿发布它，也不愿假装我有我没有的数据。

5、这目前不能做什么

无多文件优化。 每个实验一个目标文件。真实性能通常取决于跨文件的更改。约束是刻意的——保持差异可审查——但有限制。

无多指标权衡。 一个指标，一个方向。真实工程涉及速度与内存、CTR与相关性的权衡。帕累托优化是未来版本的问题。

LLM评判一致但未校准。 相同提示、相同标准、可重现分数——但未针对真实世界结果验证。用它们来发现相对改进，而不是绝对质量。

我还没有过夜运行过。 技能本周刚发布。架构是稳固的。100次实验的过夜验证还在前面。我有这些数字时会更新。

策略自我改进可能停滞。 代理更新自己的program.md是最具推测性的设计选择。我不知道这是否会显著复合，还是在20次运行后陷入循环。

6、为什么是技能，而不是分支

其他扩展autoresearch的人都分支了仓库。这将工具锁定在一个平台和一个领域。

我将此构建为AgentSkills规范中的技能，因为技能可以组合。该技能与Claude Code原生配合，并可转换为其他10种工具——Codex CLI、Gemini CLI、Cursor、Windsurf、OpenClaw、Aider、Kilo Code、OpenCode、Augment和Antigravity。一个架构，十一个平台。

这也意味着autoresearch-agent技能可以与生态系统中的其他技能组合。一个TDD指南技能可以提供评估函数——你的测试套件成为指标。一个高级ML工程师技能可以用领域特定策略为program.md提供信息。autoresearch-agent处理循环。每个技能做它擅长的事情。

安装只需一个命令：

git clone https://github.com/alirezarezvani/claude-skills.git
cp -r claude-skills/engineering/autoresearch-agent ~/.claude/skills/

对于其他工具：

./scripts/convert.sh --skill autoresearch-agent --tool codex

7、我实际怎么看这个模式

我是否会赌自主、有测量、复合迭代在两年内成为标准工程实践？是的。这个模式太明显、太强大，不会不传播。Karpathy用ML训练展示了它。营销界已经在将它应用于着陆页和广告创意。跃升到代码优化、提示工程和内容质量根本不是跃升——它是带有不同评估器的相同循环。

我是否会赌我的特定实现是正确的？还不确定。架构反映了我现在最好的想法。领域系统、评估器分离、策略升级——这些是设计决策，不是已验证的模式。社区会发现我还没发现的bug。我还没做的过夜运行会揭示我没想到的边缘情况。

如果我重新开始，我会做不同的事情：先发布更简单的v1。没有LLM评判，没有策略升级，没有领域系统。只是核心循环——一个文件，一个指标，一个命令。只有在基础循环在100个实验中证明自己后才添加复杂性。我添加了复杂性是因为我能看到模式的走向，但复杂性在验证之前是CTO习惯，我应该知道不该沉迷于此。

仓库在这里：autoresearch-agent。在你关心的东西上试试它。在太慢的函数、转化率不高的标题、不落地的系统提示上运行它。告诉我什么坏了——因为一定会有什么坏，而这正是循环改进的方式。

原文链接: I Turned Karpathy's Autoresearch Into a Agent Skill For Claude Code That Optimizes Anything — Here…

汇智网翻译整理，转载请标明出处