autoresearch

autoresearch skill 概览

autoresearch 是用来做什么的

autoresearch skill 适合用于那些“成败可量化”的编码实验闭环。它不是让 agent 一次性给出一个大修复，而是先明确目标、指标和边界，再由 agent 按迭代方式进行改动、测试、测量，以及保留或回退的决策。

谁适合安装 autoresearch

autoresearch skill 最适合希望获得“可重复优化结果”、而不是一次性答案的开发者。它尤其适用于：

• 性能调优
• 可通过 prompt 驱动的 benchmark 提升
• 提高可靠性或测试通过率
• 缩短构建时间或降低运行成本
• 安全地尝试多种实现方案

如果你的任务只是一个简单 bug 修复、一次代码审查，或者根本没有可衡量的结果，那么 autoresearch 通常不是合适工具。

它真正解决的工作问题是什么

用户会采用 autoresearch，通常是因为他们希望 agent 更像“实验操作员”，而不是“代码生成器”。这里要完成的不是“写代码”，而是“围绕明确定义的指标进行有纪律的迭代，并在收益趋于平缓或触达约束时停止”。

autoresearch 与普通 prompt 的本质差异

普通 prompt 往往只产出一个候选方案。用于 Workflow Automation 的 autoresearch 不一样，它会把工作组织成以下结构：

• 明确的目标
• 基线测量
• 可重复的实验循环
• 基于 git 的检查点
• 用于保留或丢弃结果的决策流程

当有多种看起来都可能有效的改动，但最终只能靠测量来判断时，这种差异尤其关键。

安装前先了解的主要限制

在尝试 autoresearch install 之前，先确认这些硬性条件：

• 你的项目必须已经是一个 git 仓库
• agent 需要具备终端访问能力
• 任务必须有可衡量的指标
• 这个指标必须能足够频繁地运行，支持迭代

这个 skill 几乎不依赖额外支持文件，核心基本都集中在 SKILL.md 中，所以是否值得安装，主要取决于这套 workflow 是否适合你的环境。

如何使用 autoresearch skill

在你的 skill 环境中安装 autoresearch

可通过 GitHub skill 仓库安装：

npx skills add github/awesome-copilot --skill autoresearch

安装完成后，先打开 skills/autoresearch/SKILL.md。这个 skill 没有额外脚本或 helper 引用，因此大部分实际操作细节都写在这里。

开始前先读这个文件

先看：

• SKILL.md

由于仓库里没有单独的自动化资源文件，你的 autoresearch 使用效果 很大程度上取决于是否真正理解了这个文件里的 workflow，而不是去找一些隐藏工具。

先确认你的项目是否适合 autoresearch

只有当你能同时回答下面三个问题时，autoresearch 才真正适合：

1. 你到底想改善什么结果？
2. 你准备用什么方式衡量？
3. 哪些约束绝对不能被破坏？

好的例子：

• “在保持所有测试通过的前提下，将 endpoint 延迟降低 20%。”
• “提升 bench/search.js 的 benchmark throughput，同时内存增长不超过 10%。”
• “把 flaky test 的通过率从 82% 提高到 95%。”

较弱的例子：

• “把代码写得更干净。”
• “重构这一块。”
• “把看起来不对的地方修一下。”
• “优化架构。”

在循环开始前先定义好指标

这份 autoresearch 指南 里最关键的准备动作，就是选定一个 agent 真的能执行的指标。强指标通常具备这些特点：

• 客观
• 足够快，可反复运行
• 足够稳定，可用于比较
• 与真实目标直接相关

例如：

• npm test -- --runInBand
• 带有中位运行时间的 benchmark 脚本
• build duration
• 本地 harness 测出的 request latency
• binary size
• 重复运行后的 failure count

如果指标噪声较大，就应要求多次运行，或者设定“达到什么阈值才算有意义的改进”。

把模糊目标写成强 prompt

模糊请求会让整个循环处于猜测状态。一个强 prompt 会明确给出目标、指标、范围和停止规则。

较弱：

Use autoresearch to improve this service.

更强：

Use autoresearch on this repository to reduce npm run bench:api median latency by at least 15%. Keep npm test passing, do not change external API behavior, and limit work to src/cache and src/http. Establish a baseline first, commit each experiment, and stop after 8 iterations or when improvements plateau.

这个 prompt 更有效，因为它消除了循环流程无法安全自行推断的歧义。

明确给出范围约束

这个 skill 的设计本来就会通过交互询问安装和运行细节。你可以提前把这些条件说清楚：

• 允许修改的目录
• 禁止修改的文件
• 是否允许变更依赖
• 运行时或内存上限
• 可接受的权衡
• 最大迭代次数

否则，agent 可能会把迭代预算浪费在那些你一开始就会否决的区域。

按 autoresearch 预期的循环方式使用

在实际工作中，autoresearch skill 最适合按这样的方式运行：

1. 定义目标
2. 定义指标
3. 记录基线
4. 提出一个实验方案
5. 修改代码
6. 运行测量
7. 与基线比较
8. 保留或丢弃
9. 提交这次尝试
10. 重复，直到满足停止条件

这里最核心的操作理念是“受控迭代”，而不是大范围自治式重构。

按这个 skill 预期的方式使用 git

这里的 git 不是可选项。整个 workflow 明确依赖于为每次实验尝试创建检查点。这样做的好处包括：

• 试验可回退
• 不同思路之间更容易比较
• 审计轨迹更清晰
• 更安全地进行自治探索

如果你开始前工作区就很乱，先清理干净。只有当每次试验都被隔离开时，Autoresearch 才更容易建立信任。

在真实仓库中的推荐 autoresearch 工作流

一种实用的 autoresearch 使用方式 是：

1. 清理 working tree
2. 确认指标命令能在本地运行
3. 手动验证一次基线
4. 带着目标、指标和范围调用 skill
5. 让它以小批次方式迭代
6. 重点审查被保留的 commits，而不是每一个被丢弃的思路
7. 合并前独立复验最终胜出的结果

这样既能保留实验循环的价值，又不会放弃应有的审查纪律。

能快速提升输出质量的实用建议

高影响力习惯包括：

• 只选一个主指标，而不是五个互相竞争的目标
• 一开始先把实验面收窄
• 明确定义什么叫“无回归”
• 设定最大迭代次数
• 要求输出简短的尝试与结果日志
• 优先使用可测量的本地命令，而不是主观评价

这些选择的重要性，往往比 prompt 写得多花哨更高。

autoresearch skill 常见问题

autoresearch 比普通编码 prompt 更好吗？

如果是可衡量的优化任务，通常是的；如果只是一次性的实现需求，通常不是。autoresearch 的价值来自反复、可测的试验，而不只是第一次生成代码的质量。

autoresearch 对新手友好吗？

可以用，但前提是新手至少能够定义一个可运行的指标，并且对仓库足够了解，能设定范围。这个 skill 能减少实验过程中的盲猜，但不能替你定义清晰的成功标准。

什么情况下不该使用 autoresearch？

以下情况建议跳过 autoresearch skill：

• 没有可信的指标
• 任务主要依赖设计判断
• 代码库过于敏感，不适合自治修改
• 实验运行太慢或成本太高
• 你只需要一个简单修复

autoresearch 需要特殊的项目结构吗？

不要求特定 framework，但它确实要求：

• 一个 git 仓库
• 终端访问能力
• agent 能运行的度量命令

因此，只要你的测量闭环是真实可执行的，它基本适用于各种语言和项目。

它与 CI 驱动的优化有什么区别？

CI 可以负责验证结果，而 autoresearch 的重点是“在循环中生成并评估候选改动”。可以把 CI 看作安全网，把 autoresearch 看作实验操作员。

autoresearch 除了性能调优还有用吗？

有，只要结果可测量。它也适用于可靠性、通过率、成本、构建速度等具备明确指标的编程任务。对于那种模糊的“帮我优化一下”，它的价值就会明显下降。

如何改进 autoresearch skill 的使用效果

先把问题定义得更锋利

想让 autoresearch 更快产出好结果，最有效的办法通常不是给它更多自由，而是把模糊目标换成可操作目标。应尽量包含：

• 目标指标
• 基线命令
• 可接受的回归范围
• 作用域边界
• 停止条件

大多数情况下，精确定义的 setup 比“让 agent 自由发挥”效果更好。

先降低指标噪声，再怀疑这个 skill

一个常见失败模式，是把随机波动当成真实优化去追。若结果波动明显，应先改进 benchmark 设置：

• 多跑几轮
• 使用中位数
• 隔离后台进程
• 一致地预热缓存
• 固定输入数据集

很多时候，提升测量质量对这个 skill 的帮助，比改 prompt 更大。

尽早缩小搜索空间

如果 autoresearch 跑得太散，就收紧约束。可以要求它先聚焦在一个子系统、一个热点，或一类特定改动上。大范围搜索听起来很强，但更窄的搜索通常更容易产出真正可审查、可落地的收益。

明确告诉 skill 哪些东西绝不能变

很多糟糕结果，本质上都是因为缺少护栏。把这些不可触碰的条件说清楚，例如：

• API compatibility
• test suite 的通过要求
• 依赖冻结
• 内存上限
• 风格或安全限制

这能帮助 agent 主动拒绝那些“局部看起来更好、整体却更差”的改动。

不只要最终代码，也要实验日志

如果你想从 autoresearch 指南 的 workflow 中获得更高价值，就让 agent 一并总结：

• 每次尝试了什么改动
• 测量结果如何
• 保留 / 丢弃的决定
• 被拒绝的原因

这样迭代过程才可审计，也更容易看出失败尝试中的模式。

第一次运行后，要继续迭代 prompt

如果第一次结果不理想，不要原样重跑。优先改进以下某一项：

• 指标
• 允许范围
• 停止规则
• benchmark 命令
• 明确要验证的假设

例如：

On the next autoresearch run, focus only on allocation reduction in src/parser, ignore stylistic refactors, and compare median time across 7 runs.

这种级别的调整，往往会实质性改变行为表现。

识别最常见的误触发模式

重点留意这些情况：

• 优化了错误的指标
• 测试太弱，掩盖了回归
• 单次迭代改动过大
• benchmark 命令过慢或不稳定
• 只看到一次表面上的提升就过早停止

这些通常是 setup 问题，并不等于 autoresearch 本身无效。

合并前独立验证最终胜出方案

即使 用于 Workflow Automation 的 autoresearch 找到了改进方案，仍然要在循环外独立验证：

• 自己重新跑 benchmark
• 跑更完整的测试集
• 检查可维护性上的权衡
• 确认收益在生产场景中确实有意义

这个 skill 最擅长的是发现候选方案；是否最终接受，仍应由你审慎决定。