AutoResearch软件开发实践：效率与效果深度测评
导读
这套方案的核心思路，是把Karpathy在AI研究领域“让AI自主训练AI”的闭环，迁移到软件工程中。我们在此基础上做了几项关键增强——多Agent交叉校验、五维度加权评分、基于审核反馈的迭代驱动——最终构建出一个全自动的软件开发流水线。系统依赖一份`program.md`作为行动纲领，能够自动完成从GitHub Issue识别、代码生成、测试验证到审核合并的完整闭环，仅在极少数场景下需要人工参与。实际数据表明：一个中等复杂度的开发任务，系统可在约10分钟内自主完成，代码质量评分稳定达到9.0/10。
像 Karpathy 优化模型那样打磨软件。
1 项目介绍
该项目已独立成库，并经过多轮优化：代码全面重构，控制逻辑更严谨；通用性大幅提升，可直接接入任意GitHub仓库；最关键的是新增了`opencode`功能，支持配置1~3个Coding Agent进行交叉审核与代码实现。
2 什么是 Karpathy AutoResearch？
2026年3月，AI领域领军人物AndrejKarpathy发布了名为`autoresearch`的开源项目，代码量仅600行，发布数日内GitHub星标突破5万，相关介绍视频播放量飙升至860万次。
其核心思想简洁而优雅：让AI独立开展AI研究。
具体是如何实现的？向AI Agent提供一个真实的小型LLM训练环境——单GPU、5分钟训练预算。Agent自主修改train.py、运行实验、检查结果。关键规则是：仅当验证集损失（val loss）降低时，修改才被视为有效并提交；否则执行git revert回滚，继续下一轮。人类只需维护一份`program.md`——即Agent的“研究章程”——剩下的工作全部由Agent在夜间自动运行。
该项目的精要可提炼为三点：① 量化目标（val loss是唯一评判标准）、② 自主循环（每轮无需人类介入）、③ 只保留改进（一旦退化果断回滚，绝不妥协）。按此节奏，预计每小时可完成约12次实验。一觉醒来，即可收获上百轮自动优化后的成果。
Karpathy的这套思路在ML研究领域得到验证后，我们自然联想到：软件开发环节能否复制同样的魔法？将“修改train.py→跑5分钟实验→val loss改善才保留”的模式，对应替换为“实现GitHub Issue→运行测试→多维评分达标才合并”——这便是整个项目的起点。实测结果令人惊艳：一个中等复杂度的Issue，10分钟内完成，全程无需人工干预，最终评分9.0/10。
Issue#21自动化实现的回放地址：
3 为什么做这个?
传统的“人类编写代码→运行测试→修复缺陷”流程，当GitHub Issues中积压几十上百个待处理项时，几乎寸步难行。
即便使用Claude Code、Codex等AI编程工具（即当下流行的vibe coding），仍然绕不开以下痛点：需要反复与AI对话告知需求；必须人工审查输出、发现错误再指令修改；最终生成的代码往往堆积成“屎山”；人类始终被锁定在循环中，一旦离开，流程随即中断。
2025年底流行的Ralph Wiggum方法（while true; do cat PROMPT.md | claude; done）有所改进：编写好SPEC，让单个Agent自行循环工作。这解决了人机对话的频繁交互问题，但本质仍是单Agent的自我闭环——自己写、自己测、自己改。缺乏外部审核视角，质量只能依赖测试压力（backpressure）和精心设计的prompt来保障。
2026年3月，Karpathy的`autoresearch`将同样的循环逻辑应用至ML研究：编写`program.md`定义目标与约束，AI自主修改训练代码、运行5分钟快速实验，仅当val loss改善时才提交，否则git revert。其核心创新在于：将“什么是改进”这一模糊判断，转化为明确的量化指标（metric）。
总结来看，本AutoResearch在Karpathy基础上做了三项关键改进：
1. 多Agent交叉审核，取代单Agent自审。Ralph Wiggum和Karpathy的AutoResearch均采用单Agent自改自评，缺少外部视角。本项目中Codex与Claude轮流扮演实现者和审核者：A完成代码后B审核，B完成后A审核。不同模型各有盲区和强项，交叉审核能发现单一Agent难以察觉的问题。实践证明，双Agent交叉审核的效果远优于单Agent。该设计创造性地让两个Agent互相审核、交替开发，显著提升了代码质量。
2. 五维度加权评分，替代单一metric。Karpathy用val loss一个数字判断好坏，对ML场景足够。但软件工程的质量是多维度的——功能需正确、测试需充分、代码需规范、安全无漏洞、性能无隐患。本项目引入五维度加权评分（正确性35% + 测试25% + 代码质量20% + 安全10% + 性能10%），总分达到9.0才算通过。这一机制将“代码好坏”从主观判断转化为可量化的指标。
3. 审核反馈驱动下一轮实现，取代盲循环。Ralph Wiggum的每轮循环彼此独立——新上下文中一切归零，不记忆上一轮的错误。本项目中审核反馈会直接注入下一轮Agent的提示词中，Agent能够针对具体问题定向改进，避免无意义的重复尝试。
最终效果极其干脆：人只需提供Issue编号，其余全自动完成——自动实现、自动测试、自动审核、自动迭代，评分达标后自动创建PR并合并。
与同类项目对比
不妨将三个将“自主迭代循环”思想应用于不同领域的项目并列审视：Karpathy的AutoResearch面向ML研究，本项目面向通用软件开发，“达尔文.skill”面向Skill优化。它们的核心机制完全一致——量化目标+自动迭代+只保留改进——但在优化资产、质量保证机制、人类介入程度等方面做出了不同的选择。
从对比中可提炼出几个要点：
- 量化目标是共通的核心。三个项目均将“什么是改进”定义为可量化的指标——val loss、审核评分、八维总分——而非依赖主观感受。
- 质量保证机制各有侧重。Karpathy和“达尔文.skill”使用git revert作为硬性保护（退化即回滚），本项目则采用多Agent交叉审核作为软性保护（审核反馈驱动改进，未设计回退机制，因为Claude Code/Codex自身已足够智能，能够决定是回退还是改进上一轮的变更）。
- 人类介入程度反映领域特征。ML研究的metric足够客观，可全自动运行；Skill的好坏需人工判断，因此每轮会暂停确认；软件开发介于两者之间，大部分流程自动进行，但保留了关键节点人工介入的能力。
4 系统架构
下面是整个项目的架构图：
4.1 六条核心原则
这六条原则构成了系统的设计基石。原则01定义了规则的来源与边界；原则02至05构建了多Agent对抗的质量保证链路——谁来做、怎么评、如何改进；原则06确保整个过程可追溯。它们相互配合：没有`program.md`的约束，Agent会越权；没有多Agent对抗，单Agent自审存在盲区；没有量化门槛，质量判断重回主观经验；没有反馈驱动，迭代沦为盲循环；没有全量记录，问题出现后无法回溯。
4.2 审核评分体系
审核评分是整个AutoResearch的量化核心。它将“这段代码好不好”这一模糊主观判断，转化为五维度加权计算出的精确分数。该分数决定迭代是继续还是终止：≥ 9.0自动提交PR，< 9.0则审核反馈驱动下一轮改进。维度与权重的分配体现了软件工程的质量优先级：功能正确最重要（35%），测试其次（25%），代码质量（20%），安全与性能各占10%。
总分10分，五维度加权计算：
各维度得分的判定标准：无问题10分，建议改进9分，一般问题7分，严重问题4分，致命问题1分。
达标线：9.0/10
4.3 优化循环：4个阶段
整个流程分为四个阶段。
- Phase 1 负责环境准备，一次性工作，几秒钟即可完成。
- Phase 2 是核心迭代循环，多Agent轮流审核与实现、测试验证、评分判定——此阶段完全自主运行，无需人类介入。
- Phase 3 在评分达标后自动触发，完成commit、PR创建与合并。
- Phase 4 进行结果归档，将迭代过程写入日志，便于后续回溯。
其中Phase 2占据了几乎全部时间，也是整个系统价值的核心所在。
Phase 1: 环境准备迭代示例：
迭代 1: Codex 审核 → Codex 实现 → 测试 → Claude 审核(5.0) → Claude 实现终止条件**：在以下情况下，任务会终止
4.4 核心文件
4.5 Issue 选择策略
排除规则：以下类型的Issue不会被处理：带有`wontfix`、`duplicate`、`invalid`、`blocked`、`needs discussion`、`on hold`、`external`标签的；标题包含`[WIP]`或`[DRAFT]`的；正文中含有`DO NOT IMPLEMENT`的；以及已有关联PR的。
优先级计算：
分数 = 基础权重(15) + 标签权重 + 类型权重 + 时间因子- 标签权重：critical(100) > high(50) > medium(20) > low(10)
- 类型权重：bug(30) > feature(20) > refactor(10) > test(5) > docs(3)
- 时间因子：新Issue加10分，陈年Issue加15分，近期有更新的Issue加5分
复杂度评估**：
4.6 program.md 要点
权限边界**：
代码规范（Go）**：
测试规范**：
4.7 错误处理
退火重试：API调用失败时，采用指数退避加随机抖动策略。延迟时间按公式delay = 2^retry * base_delay + random_jitter计算，最大等待60秒，最多重试10次。
连续失败保护：Agent执行失败时，连续失败计数加1。连续失败达到3次，则停止运行并记录日志。
测试失败：测试失败后，会将“测试失败”的反馈传递给下一轮Agent，使其有针对性地进行修复。
4.8 运行结果
results.tsv 格式**：
timestamp issue_number issue_title status iterations tests_passed score branch_name状态定义**：
5 快速开始
5.1 前置条件
要自动化处理GitHub的Issue，自然需要安装GitHub CLI。通过acpx工具操控Claude Code和Codex，因此acpx也必须安装。此外，本项目基于Go语言开发，Go环境同样必备。
5.2 运行
调用run.sh脚本，直接输入Issue编号即可启动。
# 进入你要处理的 GitHub 项目目录脚本会自动完成以下流程：检查环境 → 获取 Issue → 创建分支 → 轮流让Codex和Claude实现和审核 → 达标后自动发起PR并合并。
5.3 自定义配置
在项目根目录下创建.autoresearch/目录，即可覆盖默认配置：
6 实战案例
以下是两个典型的实战案例，全程无需人工干预。
案例一：Issue #21 —— feat: enhance job execution with agent selection and timeout
只需提供一个Issue编号，剩下的由autoresearch脚本自动完成。默认最多执行42轮迭代，但实际上通常几轮后代码质量即可达标。该Issue大约10分钟完成开发，总共只迭代了3轮。完整过程可查看回放。
关键日志：
案例二：Issue #15 —— feat: define source-of-truth event protocol
实现该Issue时仅迭代了两轮，代码质量即达到标准。
关键日志：
案例三：Issue #6 —— feat: add web UI for sessions
该实现涉及多个模块，需要做出设计决策，复杂度较高。即便如此，也只迭代了5轮，代码质量即达标。
关键日志：
7 最佳实践
- 从小Issue开始：先用简单的bug fix类Issue测试整个流程是否顺畅。
- 保持program.md更新：根据实际运行情况，随时调整规则和约束。若效果不尽人意（如评分机制与预期不符），直接修改该文件即可。
- 关注评分趋势：每次迭代的评分都会记录在log.md中，注意观察评分是否稳步上升。
- 利用多Agent对抗：让Codex和Claude轮流实现和审核，交叉验证能有效减少盲区。
- 退火重试：API不稳定时，脚本会自动进行退避重试，完全无需人工介入。
8 设计灵感
- karpathy/autoresearch — 核心循环思想：只保留可测量的改进，其余的统统回滚。
- acpx — Agent控制工具，使Codex和Claude能够在命令行中协同工作。
- imclaw — 本项目的基石和相关文件仓库。