AI Skills
autoresearch

autoresearch

热门

适用于任何编程任务的自主迭代实验循环。引导用户定义目标、可衡量的指标和范围约束，然后运行一个自主循环：代码修改、测试、测量，并保留或丢弃结果。灵感来自 Karpathy 的 autoresearch。用途：自主改进、迭代优化、实验循环、自动研究、性能调优、自动化实验、爬山法、自动尝试、优化代码、运行实验、自主编码循环。不适用于：一次性任务、简单 bug 修复、代码审查，或没有可衡量指标的任务。

3.7万Star
4637Fork
更新于 2026/7/24
获取 Skill源代码

相关 Skills

frontend-testing15万vitest11万subagent-driven-development23万
SKILL.md
readonly只读
name
autoresearch
description

适用于任何编程任务的自主迭代实验循环。引导用户定义目标、可衡量的指标和范围约束，然后运行一个自主循环：代码修改、测试、测量，并保留或丢弃结果。灵感来自 Karpathy 的 autoresearch。用途：自主改进、迭代优化、实验循环、自动研究、性能调优、自动化实验、爬山法、自动尝试、优化代码、运行实验、自主编码循环。不适用于：一次性任务、简单 bug 修复、代码审查，或没有可衡量指标的任务。

Autoresearch：自主迭代实验

一个适用于任何编程任务的自主实验循环。你定义目标和衡量方式；智能体自主迭代——修改代码、运行实验、测量结果，并保留或丢弃更改——直到被中断。

本技能灵感来自 Karpathy 的 autoresearch，从 ML 训练推广到任何具有可衡量结果的编程任务。

智能体行为规则

  1. 必须在启动循环前与用户交互完成设置阶段。
  2. 必须在进行任何更改前建立基线测量。
  3. 必须在每次实验尝试前提交（以便干净地回滚）。
  4. 必须维护结果日志（TSV），记录每次实验。
  5. 必须回滚未改进指标的更改（git reset 到上一个已知良好状态）。
  6. 必须在循环启动后自主运行——绝不暂停询问“我是否应该继续？”。
  7. 不得修改用户标记为范围外的文件。
  8. 不得跳过测量步骤——每次实验都必须测量。
  9. 不得保留使指标退化的更改，除非用户明确允许权衡。
  10. 不得安装新依赖或更改环境，除非用户批准。

阶段 1：设置（交互式）

在任何实验开始之前，与用户合作确定以下参数。直接向用户询问每一项。不要假设或跳过任何一项。

1.1 定义目标

询问用户：

你想改进或优化什么？

示例：执行时间、内存使用、二进制大小、测试通过率、代码覆盖率、
API 响应延迟、吞吐量、错误率、基准分数、构建时间、打包大小、
代码行数、圈复杂度等。

将用户的回答记录为目标。

1.2 定义指标

询问用户：

我们如何衡量成功？哪个确切的命令能产生指标？

我需要：

  1. 要运行的命令（例如：dotnet test、npm run benchmark、time ./build.sh、pytest --tb=short）
  2. 如何从输出中提取指标（例如：正则表达式、特定行、JSON 字段）
  3. 方向：越低越好还是越高越好？

示例：“运行 dotnet test --logger trx，统计通过的测试数。越高越好。”
示例：“运行 hyperfine './my-program'，提取平均时间。越低越好。”

记录：

  • METRIC_COMMAND：要运行的命令
  • METRIC_EXTRACTION：如何从输出中提取数值指标
  • METRIC_DIRECTION：lower_is_better 或 higher_is_better

1.3 定义范围

询问用户：

我可以修改哪些文件或目录？

哪些文件是禁止修改的（只读）？

记录：

  • IN_SCOPE_FILES：智能体可以编辑的文件/目录
  • OUT_OF_SCOPE_FILES：不得修改的文件/目录

1.4 定义约束

询问用户：

有哪些约束我需要遵守？

示例：

  • 每次实验的时间预算（例如：“每次运行应少于 2 分钟”）
  • 无新依赖
  • 必须保持所有现有测试通过
  • 不得更改公共 API
  • 必须保持向后兼容
  • VRAM/内存限制
  • 代码复杂度限制（优先选择更简单的解决方案）

记录为 CONSTRAINTS。

1.5 定义实验预算（可选）

询问用户：

我应该运行多少次实验，还是继续直到你停止我？

你可以指定一个数字（例如：“尝试 20 次实验”）或“无限制”（我会一直运行直到你中断）。

记录为 MAX_EXPERIMENTS（数字或 unlimited）。

1.6 简洁性标准

告知用户默认的简洁性策略：

简洁性策略（默认）： 在其他条件相同的情况下，更简单的更好。一个带来丑陋复杂性的小改进不值得。在保持或改进指标的同时删除代码是一个很好的结果。我会权衡复杂性成本与改进幅度。这个策略对你有用吗，还是你想调整？

记录任何调整作为 SIMPLICITY_POLICY。

1.7 确认设置

以清晰的表格向用户总结所有参数：

参数 值
目标 ...
指标命令 ...
指标提取 ...
方向 越低越好 / 越高越好
范围内文件 ...
范围外文件 ...
约束 ...
最大实验次数 ...
简洁性策略 ...

要求用户确认。在确认之前不要继续。

阶段 2：分支与基线

一旦用户确认：

  1. 创建分支：基于今天的日期提议一个标签（例如 autoresearch/mar17）。
    创建分支：git checkout -b autoresearch/<tag>。

  2. 读取范围内文件：读取所有范围内的文件，以构建当前状态的完整上下文。

  3. 初始化 results.tsv：在仓库根目录创建 results.tsv，包含标题行：

    experiment	commit	metric	status	description

    将 results.tsv 和 run.log 添加到 .git/info/exclude（如果尚未存在则追加），使它们保持未跟踪状态，而不修改任何已跟踪文件。

  4. 运行基线：在当前未修改的代码上执行指标命令。
    将结果记录为实验 0，状态为 baseline，写入 results.tsv。

  5. 向用户报告基线：

    基线已建立：[指标名称] = [值]
    开始自主实验循环。

阶段 3：实验循环

持续运行此循环。不要停下来询问用户。运行直到：

  • 达到 MAX_EXPERIMENTS，或者
  • 用户手动中断

每次实验：

循环：
  1. 思考   - 分析之前的结果和当前代码。
               生成一个实验假设。
               考虑：什么有效，什么无效，什么还没尝试过。

  2. 编辑    - 修改范围内的文件以实现想法。
               每次实验保持更改集中且最小化。

  3. 提交    - git add + git commit，附带简短的描述性消息。
               格式：“experiment: <更改的简短描述>”

  4. 运行     - 执行指标命令。
               将输出重定向到 run.log，以免淹没上下文窗口。
               使用适合 shell 的重定向：
               - Bash/Zsh：`<command> > run.log 2>&1`
               - PowerShell：`<command> *> run.log`

  5. 测量 - 从 run.log 中提取指标。
               如果提取失败（崩溃/错误），读取 run.log 的最后 50 行以获取错误信息。

  6. 决定  - 将指标与当前最佳值比较：
               - 改进：保留提交。更新“最佳”基线。
                 记录状态为“keep”。
               - 相同或更差：回滚。`git reset --hard HEAD~1`。
                 记录状态为“discard”。
               - 崩溃：尝试快速修复（拼写错误、导入、简单错误）。
                 修改实验提交（`git commit --amend`）并重新运行。实验保持原始编号。
                 如果两次尝试后仍无法修复，回滚整个实验
                 （`git reset --hard HEAD~1`）并记录状态为“crash”。

  7. 记录     - 向 results.tsv 追加一行：
               experiment_number  commit_hash  metric_value  status  description

  8. 继续 - 转到步骤 1。

实验策略

生成实验想法时，遵循以下优先级顺序：

  1. 先易后难：简单的参数调整、明显的低效。
  2. 根据结果调整：如果某个方向显示出希望，进一步探索该方向。
  3. 平台期后多样化：如果最近 3-5 次实验都失败，尝试完全不同的方法。
  4. 组合优胜者：如果实验 A 和 B 各自独立改进，尝试组合它们。
  5. 简化轮次：定期尝试删除代码/复杂性，看指标是否保持。
  6. 激进更改：在穷尽增量想法后，尝试更大的架构更改。

处理约束

  • 时间预算：如果运行时间超过预期持续时间的 2 倍，终止并将其视为崩溃。
  • 现有测试：如果约束要求测试通过，在前后运行测试，如果测试失败则回滚。
  • 内存/资源：监控并在资源使用超过规定限制时回滚。

阶段 4：报告

当循环结束时（达到预算或用户中断）：

  1. 以格式化表格打印完整的 results.tsv。
  2. 总结：
    • 运行的总实验次数
    • 保留 / 丢弃 / 崩溃的实验次数
    • 起始指标（基线）与最终指标
    • 改进百分比
    • 影响最大的 3 个更改
  3. 显示保留实验的累积 git 日志：
    git log --oneline <start_commit>..HEAD
  4. 推荐下一步：根据结果，建议人类研究人员接下来可以尝试什么（对于自动化实验来说风险太大或太复杂的想法）。

快速参考

结果 TSV 格式

制表符分隔，5 列：

experiment	commit	metric	status	description
0	a1b2c3d	0.997900	baseline	未修改代码
1	b2c3d4e	0.993200	keep	将学习率提高到 0.04
2	c3d4e5f	1.005000	discard	切换到 GeLU 激活函数
3	d4e5f6g	0.000000	crash	加倍模型宽度（OOM）

Git 工作流

  • 所有实验都在 autoresearch/<tag> 分支上进行
  • 每次实验在运行前提交
  • 失败的实验通过 git reset --hard HEAD~1 回滚
  • 成功的实验推进分支
  • results.tsv 和 run.log 保持未跟踪（已添加到 .git/info/exclude）

关键原则

  1. 测量一切：没有测量就没有实验。
  2. 回滚失败：分支仅在改进时推进。
  3. 保持自主：绝不停止询问。卡住时更努力思考。
  4. 保持简单：复杂性是成本。权衡其与收益。
  5. 记录一切：TSV 是研究日志。