awesome-copilot autoresearch Skill 实战：构建可度量的自主迭代实验循环-迪斯科星球

awesome-copilot autoresearch Skill 实战：构建可度量的自主迭代实验循环

【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot

导读

autoresearch是 awesome-copilot 仓库中一个面向任意编程任务的自主迭代实验 Skill：你只需定义优化目标与衡量指标，Agent 便会进入"改代码 → 跑实验 → 测量 → 保留或回退"的自动化循环，直到达到实验预算或被你手动中断。本文以 skills/autoresearch/SKILL.md 为骨架，完整讲解其交互式 Setup、分支与基线、实验循环、结果汇报四个阶段的运作细节，并结合仓库内的 Skill 校验脚本，说明如何正确安装、触发与落地这套"自动化爬山"式优化流程。

一、Skill 定位：从机器学习训练到任意可度量任务

1.1 核心思想

autoresearch的灵感来自 Karpathy 的 autoresearch 项目（见该 Skill frontmatter 的metadata.inspired-by字段），但其适用范围从模型训练被泛化到了任何具有可度量产出的编程任务。

它的工作方式可以用一句话概括：你定义目标和度量方式，Agent 自主迭代——修改代码、运行实验、测量结果、保留或丢弃变更——直到被中断为止。

1.2 适用场景（USE FOR）

根据 SKILL.md frontmatter 的description声明，本 Skill 面向以下场景：

自主改进（autonomous improvement）
迭代优化（iterative optimization）
实验循环（experiment loop）
自动研究（auto research）
性能调优（performance tuning）
自动化实验（automated experimentation）
爬山式搜索（hill climbing）
自动尝试（try things automatically）
优化代码（optimize code）
自主编码循环（autonomous coding loop）

1.3 明确不适用的场景（DO NOT USE FOR）

同样在description中，Skill 明确声明不要用于：

一次性任务（one-shot tasks）
简单 bug 修复（simple bug fixes）
代码评审（code review）
没有可度量指标的任务（tasks without a measurable metric）

这条边界非常重要：如果任务无法用数字指标衡量成败，实验循环就失去了决策依据，autoresearch便不适用。

1.4 运行前提

frontmatter 的compatibility字段写明了硬性依赖：

要求使用 git：项目必须是 git 仓库（git repository）
要求终端访问：需要能够执行命令（terminal access）

git 之所以是前提，是因为整个循环的"可回退性"完全建立在 commit 与 reset 之上——每次实验先提交、失败则git reset --hard回退，这是后面 Phase 2/3 的基石。

二、安装与加载：Skill 在仓库中的组织方式

2.1 Skill 是什么

在 awesome-copilot 中，Skill 是"包含指令与捆绑资源的自包含文件夹"，遵循 Agent Skills 规范，每个 Skill 内有一个SKILL.md指令文件，Agent 按需加载（渐进式披露，progressive disclosure），详见 docs/README.skills.md。autoresearch文件夹当前只包含一个SKILL.md，没有捆绑脚本或参考数据——整个流程完全由指令驱动。

2.2 两种安装方式

方式一：通过 GitHub CLI 安装

gh skills install github/awesome-copilot autoresearch

该命令需要 GitHub CLI v2.90.0+，在交互式 Copilot 会话中引用 Skill 名称即可触发。

方式二：手动复制

将 skills/autoresearch 文件夹整体复制到本地 skills 目录，然后在提示词中引用该 Skill，或让 Agent 自动发现。

2.3 从仓库校验脚本看 SKILL.md 的结构约束

autoresearch能被仓库正常收录，其 frontmatter 必须通过 eng/validate-skills.mjs 的严格校验。从校验逻辑可以反推出该 Skill 文件的设计约束：

必须存在SKILL.md文件（validateSkillFolder的第一步检查，缺失直接报错）；
name必须合法：只能包含小写字母、数字与连字符，长度在 1–64 字符之间（SKILL_NAME_MIN_LENGTH/SKILL_NAME_MAX_LENGTH，定义于 eng/constants.mjs），且文件夹名必须与name一致——这正是autoresearch文件夹与name: autoresearch匹配的原因；
description必须有足够信息量：长度需在 10–1024 字符之间，这也是该 Skill 用大段文字同时描述"适用场景"与"不适用场景"的原因；
frontmatter 由 eng/yaml-parser.mjs 中的parseSkillMetadata解析，name、description缺失会被判定为无效 Skill。

对照实际文件，autoresearch的 frontmatter 字段包括：name、description、license: MIT、compatibility（git 与终端前提）、metadata.author: luiscantero、metadata.inspired-by（灵感来源标注）。

三、Agent 行为规则：循环的"宪法"

在进入具体阶段之前，SKILL.md 用 10 条行为规则约束 Agent 在整个流程中的边界。这些规则可以分为"必须做"与"禁止做"两类：

DO（必须）

在开始循环前，交互式引导用户完成 Setup 阶段；
在做出任何修改前，先建立基线测量（baseline）；
每次实验运行前先提交（以便干净地回退）；
维护一个结果日志（TSV），记录每一次实验；
回退未改善指标的变化（git reset到最近一次已知良好状态）；
循环一旦开始就自主运行——绝不中途停下问"我该继续吗"。

DO NOT（禁止）

不修改用户标记为**超范围（out-of-scope）**的文件；
不跳过测量步骤——每个实验都必须被测量；
不保留使指标回退的变更（除非用户明确允许权衡取舍）；
未经用户批准，不安装新依赖或改动环境。

这十条规则构成了整个循环的纪律基础：可回退、可测量、自主、克制。

四、Phase 1：交互式 Setup（实验参数定义）

在任何实验开始之前，Agent 必须与用户逐项确认以下参数，不得假设或跳过任何一项。这是整个流程中唯一强交互的阶段。

4.1 定义目标（Goal）

Agent 会直接询问用户：

你想改进或优化什么？

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

4.2 定义指标（Metric）

这是循环能否成立的关键。用户必须提供三样东西：

度量命令（METRIC_COMMAND）：例如dotnet test、npm run benchmark、time ./build.sh、pytest --tb=short；
指标提取方式（METRIC_EXTRACTION）：从输出中如何提取数值——一个正则、特定一行、或某个 JSON 字段；
方向（METRIC_DIRECTION）：lower_is_better（越低越好）或higher_is_better（越高越好）。

文档给出的两个完整示例：

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

三个参数METRIC_COMMAND、METRIC_EXTRACTION、METRIC_DIRECTION会被记录并在后续循环中反复使用。

4.3 定义范围（Scope）

Agent 会询问：

哪些文件或目录允许我修改？哪些文件是禁区（只读）？

分别记录为：

IN_SCOPE_FILES：Agent 可编辑的文件/目录；
OUT_OF_SCOPE_FILES：绝不允许修改的文件/目录。

4.4 定义约束（Constraints）

Agent 会询问用户希望遵守哪些约束，典型示例包括：

每次实验的时间预算（如"每次运行应 < 2 分钟"）
不允许新增依赖
必须保持所有现有测试通过
不得更改公共 API
必须保持向后兼容
VRAM/内存限制
代码复杂度限制（倾向更简单的方案）

统一记录为CONSTRAINTS。

4.5 定义实验预算（可选）

我应该运行多少个实验，还是持续进行直到你叫停？

用户可以给出一个数字（如"尝试 20 个实验"），或选择unlimited（无限，直到用户中断）。记录为MAX_EXPERIMENTS。

4.6 简洁性标准（Simplicity Criterion）

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

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

任何调整记录为SIMPLICITY_POLICY。这一条把"代码质量"纳入了实验的评价体系，防止为了一点指标增益而堆砌复杂度。

4.7 确认设置（Confirm Setup）

Agent 会把所有参数汇总成一张清晰表格，要求用户确认后方可进入下一阶段：

参数	值
目标（Goal）	...
度量命令（Metric command）	...
指标提取（Metric extraction）	...
方向（Direction）	越低越好 / 越高越好
范围内文件（In-scope files）	...
范围外文件（Out-of-scope files）	...
约束（Constraints）	...
最大实验数（Max experiments）	...
简洁性策略（Simplicity policy）	...

未经用户确认，不得开始实验。

五、Phase 2：分支与基线（Branch & Baseline）

用户确认参数后，进入实验准备阶段，共 5 步：

5.1 创建分支

基于当天日期提议标签（如autoresearch/mar17），并创建分支：

git checkout -b autoresearch/<tag>

所有实验都发生在autoresearch/<tag>分支上，保证主线不受影响。

5.2 读取范围内文件

读取所有 in-scope 文件，建立对当前状态的完整上下文。

5.3 初始化 results.tsv

在仓库根目录创建results.tsv，首行为表头：

experiment commit metric status description

注意各列之间是**制表符（tab）**而非空格。随后把results.tsv和run.log追加到.git/info/exclude（若已存在则追加而非覆盖），使这两个文件保持 untracked 状态，不修改任何已跟踪文件。

5.4 运行基线

在未修改的当前代码上执行度量命令，将结果记录为实验编号0、状态baseline，写入results.tsv。

5.5 汇报基线

向用户报告：

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

至此，Agent 取得了解答"变化是否有收益"的参照系。

六、Phase 3：实验循环（Experiment Loop）

这是 Skill 的核心引擎。循环将持续运行，直到达到MAX_EXPERIMENTS或用户手动中断，期间不停下来询问用户。

6.1 循环伪代码

LOOP: 1. THINK - 分析此前结果与当前代码。 生成一个实验假设。 思考：什么有效、什么无效、还有什么没试过。 2. EDIT - 修改 in-scope 文件以落地该想法。 保持每次实验的变更聚焦、最小化。 3. COMMIT - git add + git commit，附简短描述性消息。 格式："experiment: <变更的简短描述>" 4. RUN - 执行度量命令。 将输出重定向到 run.log，避免淹没上下文窗口。 使用适合当前 shell 的重定向： - Bash/Zsh: <command> > run.log 2>&1 - PowerShell: <command> *> run.log 5. MEASURE - 从 run.log 中提取指标。 若提取失败（崩溃/报错），读取 run.log 最后 50 行定位错误。 6. DECIDE - 与当前最优值比较： - 改进（IMPROVED）：保留该提交，更新"最优"基线。 日志状态记为 "keep"。 - 持平或更差（SAME OR WORSE）：回退。git reset --hard HEAD~1。 日志状态记为 "discard"。 - 崩溃（CRASH）：尝试快速修复（拼写、导入、简单错误）。 用 git commit --amend 修正实验提交后重跑， 实验保持原编号。 若两次尝试仍无法修复，回退整个实验 （git reset --hard HEAD~1），日志状态记为 "crash"。 7. LOG - 向 results.tsv 追加一行： experiment_number commit_hash metric_value status description 8. CONTINUE - 回到步骤 1。

6.2 逐步拆解

THINK：循环的"大脑"。Agent 综合前几轮结果生成假设，方向包括：什么有效（继续深挖）、什么无效（放弃该方向）、什么还没试过（开辟新路）。

EDIT：强调聚焦与最小化——每次实验只做一个改动，否则无法归因指标变化。

COMMIT：实验在运行前必须先提交，commit message 统一以experiment:前缀开头。这是回退机制的前提：git reset --hard HEAD~1能精确撤销"刚提交的这个实验"。

RUN：将命令输出重定向到run.log（> run.log 2>&1，PowerShell 用*> run.log），避免大量输出占用上下文窗口——这对长时间循环至关重要。

MEASURE：从run.log提取数值指标。提取失败通常意味着程序崩溃，此时读最后 50 行日志定位错误。

DECIDE：三种结局的分岔口。keep（改进，分支前进一步）；discard（持平或回退，git reset --hard HEAD~1）；crash（允许一次快速修复并用git commit --amend修正原提交、保持实验编号，但最多两次尝试，否则整体回退并记为 crash）。这个"最多两次快速修复"的限制防止循环在单个坏实验上无限卡死。

LOG：追加一行到results.tsv——实验编号、commit 哈希、指标值、状态、描述。这是研究日志，也是最终汇报的数据源。

6.3 实验策略：想法生成优先级

当 Agent 生成实验想法时，按以下优先级顺序：

先摘低垂果实：简单的参数调整、明显的低效点；
跟随结果：某个方向表现出潜力，就沿该方向继续探索；
平台期后多元化：如果最近 3–5 个实验全部失败，换一种完全不同的思路；
组合胜者：若实验 A 和 B 各自独立带来改进，尝试将二者组合；
定期做减法：周期性尝试删代码/降复杂度，验证指标是否保持；
激进重构：增量想法穷尽后，尝试更大的架构级变更。

这是一套经典的爬山（hill climbing）搜索策略：先局部贪心，遇到平台期就跳出局部最优，最后才动用大动作。

6.4 约束处理

时间预算：如果某次运行超过预期时长 2 倍，终止它并按 crash 处理；
现有测试：若约束要求测试通过，则在改动前后运行测试，破坏即回退；
内存/资源：持续监控，资源占用超出约定上限即回退。

七、Phase 4：结果汇报（Reporting）

循环结束时（达到预算或被用户中断），Agent 执行四项收尾动作：

7.1 打印完整 results.tsv

将整个实验结果表以格式化表格输出——这是实验的完整履历。

7.2 总结

汇报内容包括：

运行的总实验数
保留 / 丢弃 / 崩溃的实验数
起始指标（基线）vs 最终指标
改进百分比
影响最大的 3 个变更

7.3 展示保留实验的累计提交历史

git log --oneline <start_commit>..HEAD

这条命令清晰地展示分支上"被保留"的实验序列——每个提交都是一个有净收益的改进。

7.4 推荐下一步

基于结果，向人类研究者建议可尝试的方向——那些对自动化实验来说太冒险或太复杂的想法（例如需要人工判断的架构决策、涉及业务语义的权衡）。

八、快速参考（Quick Reference）

8.1 results.tsv 格式

制表符分隔，5 列：

experiment commit metric status description 0 a1b2c3d 0.997900 baseline unmodified code 1 b2c3d4e 0.993200 keep increase learning rate to 0.04 2 c3d4e5f 1.005000 discard switch to GeLU activation 3 d4e5f6g 0.000000 crash double model width (OOM)

解读示例：实验0是基线；实验1指标优于基线（0.9932 < 0.9979，假设 lower is better）被保留；实验2指标回退被丢弃；实验3因内存溢出（OOM）崩溃、指标记为 0。该示例同时说明autoresearch并不限于特定领域——调学习率、换激活函数是 ML 场景，但同样的表结构完全可以承载 API 延迟、构建时间等工程指标。

8.2 Git 工作流要点

所有实验发生在autoresearch/<tag>分支上；
每个实验在运行前先提交；
失败实验用git reset --hard HEAD~1回退；
成功实验推进分支；
results.tsv与run.log保持 untracked（已加入.git/info/exclude）。

8.3 关键原则

一切皆可测量：没有测量的实验不存在；
失败即回退：分支只因改进而前进；
保持自主：绝不中途停下提问，卡住就多想；
保持简单：复杂度是成本，要与收益权衡；
全程记录：TSV 就是研究日志。

九、使用建议：何时启用、如何发挥最大价值

9.1 触发时机

在 Copilot 会话中提及以下意图时即可触发该 Skill：autonomous improvement、iterative optimization、experiment loop、auto research、performance tuning、automated experimentation、hill climbing、try things automatically、optimize code、run experiments、autonomous coding loop。反之，若任务是一次性编码、简单 bug 修复或代码评审，应主动避免触发。

9.2 使用前提自查清单

启用前请确认：

项目是 git 仓库（Skill 的compatibility硬性要求）；
有可执行、可解析、方向明确的度量命令；
已明确 in-scope / out-of-scope 文件边界；
已与 Agent 确认参数汇总表。

9.3 发挥价值的要点

指标要"快"：每次循环都要跑一次度量命令，命令越慢，相同时间内能尝试的实验越少；文档也通过时间预算约束（超时 2 倍按 crash 处理）隐含了这一要求；
约束要"准"：不装新依赖、不动公共 API、保持测试通过等约束，能防止自动化优化在真实约束之外"空转"；
区分 keep/discard/crash：三者分别代表"净收益""无收益""执行失败"，是汇报阶段区分质量信号与执行噪声的关键；
重视简洁性策略：默认"同样收益下更简单更好"的取向，让循环不仅追指标，也抑制复杂度膨胀。

autoresearch的本质，是把"研究者手动尝试、测量、决定去留"的科研闭环压缩进一个 git 驱动的自动化循环：定义好目标与度量之后，剩下的爬山交给 Agent，而results.tsv与提交历史则完整保留了每一次尝试的足迹，可供事后复盘与继续探索。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析