1. 从 Karpathy 的 AutoResearch 说起为什么软件开发也需要 program.mdKarpathy 的 AutoResearch 之所以让人眼前一亮不是因为它用了多复杂的模型而是它把「改进」这件事量化成了一个明确的数字——val loss。Agent 改 train.py、跑 5 分钟实验、看 val loss 有没有降降了就 commit没降就 git revert然后继续下一轮。人只需要维护一份 program.md相当于给 Agent 的「研究章程」剩下的交给它自己跑。这套思路放到软件开发领域其实同样成立。我们每天面对的是 GitHub 上一堆 Issue有的要修 bug有的要加功能有的要重构。传统做法是人写代码、跑测试、发现问题、再改一轮一轮 chat 交互。即使用上 Claude Code 或 Codex人还是被绑在循环里离开就不转了。我试过把 AutoResearch 的循环搬到软件开发场景核心替换逻辑很简单把「修改 train.py → 跑实验 → val loss 改善才保留」换成「实现 Issue → 跑测试 → 多维评分达标才合并」。program.md 从「研究章程」变成「开发章程」定义权限边界、代码规范、测试要求、评分标准。Agent 在循环里自主实现、自主测试、自主审核评分达标才提交 PR。这套东西适合谁适合手里有几十上百个待处理 Issue、又不想被 chat 交互绑死的开发者适合想用 AI Agent 做自动化开发、但担心单 Agent 自审有盲区的团队也适合想理解 AutoResearch 思想、把它迁移到自己领域的工程师。下面我会给出可复制的 program.md 模板、统一 Key 配置片段以及一轮自动迭代的完整验证动作。2. TaoToken 前置统一 Key 串联多 Agent 调用链路多 Agent 交叉审核的架构里最容易被忽略但最影响稳定性的是 API 通道的统一管理。Codex 和 Claude 轮流担任实现者和审核者意味着一次迭代里会有多次模型调用如果每个 Agent 各自配一套 Key、各自走一条通道排查问题时会非常痛苦——你分不清是模型本身的问题还是某条通道的限流或超时。TaoToken 在这里的作用是提供一个统一的 Key 和 API 通道把 AI Agent 的调用链路收敛到一处。你可以在一个地方管理模型访问Agent 侧只需要配置 Base URL、Key 和 Model ID 三件套。对于 program.md 驱动的自动迭代来说这意味着脚本里的模型调用可以统一走同一个入口重试、退避、日志记录都更容易做。先拿到 Key。访问 TaoToken 的 API Keys 页面创建一个https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite创建后你会得到一串 Key形如sk-xxxxxxxx。这个 Key 就是后面所有 Agent 配置里要填的东西。注意不要把它提交到 Git 仓库建议放在环境变量或本地配置文件里。接下来是接入文档不同工具的配置方式略有差异建议对照文档操作https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite如果你用的是 Claude Code 这类工具可以参考 ClaudeCodeAnthropic 的接入说明https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite统一 Key 的好处在于当自动迭代跑到第 5 轮、第 10 轮时如果出现调用失败你只需要检查一个通道的状态而不是在多个 Key 之间来回切换排查。program.md 里的退火重试逻辑指数退避 随机抖动也只需要针对这一条通道配置脚本会简单很多。3. 可复制配置program.md 模板与统一 Key 片段这一节给两份可以直接复制的东西一份 program.md 模板一份统一 Key 的配置片段。program.md 是整个自动迭代的规则核心Agent 每轮开始前都会读它所以写清楚权限边界和评分标准比写得多更重要。先看 program.md 模板。放在项目根目录的.autoresearch/program.md# AutoResearch 开发章程 ## 目标 自主完成指定 GitHub Issue 的实现评分达标后提交 PR。 ## 权限边界 允许 - 读取 Issue 内容、仓库代码、测试文件 - 创建分支、修改源码、新增测试 - 运行测试命令、查看测试输出 - 提交 commit、创建 PR 禁止 - 修改 CI 配置、发布流程 - 删除已有测试用例 - 改动与当前 Issue 无关的模块 - 直接推送到 main 分支 ## 代码规范 - 遵循项目现有风格不引入新依赖除非 Issue 明确要求 - 函数职责单一命名清晰 - 新增功能必须有对应单元测试 ## 评分标准总分 10 - 正确性 35%功能是否符合 Issue 描述 - 测试 25%测试覆盖是否充分、是否通过 - 代码质量 20%可读性、结构、命名 - 安全 10%是否有明显漏洞 - 性能 10%是否有明显性能坑 各维度得分无问题 10 / 建议改进 9 / 一般问题 7 / 严重问题 4 / 致命问题 1 达标线9.0 ## 迭代规则 - 每轮由实现 Agent 写代码审核 Agent 评分 - 评分 9.0 时审核反馈传入下一轮实现 Agent - 连续失败 3 次则停止记录日志 - API 调用失败使用指数退避重试最大等待 60 秒最多 10 次再看统一 Key 的配置片段。以 JSON 形式放在.autoresearch/config.json{ base_url: https://taotoken.net/api, api_key: sk-你的Key, models: { implementer: claude-sonnet-4-5, reviewer: gpt-5-codex }, max_iterations: 42, score_threshold: 9.0, retry: { max_attempts: 10, base_delay: 2, max_delay: 60 } }如果你用的是 TOML 风格的工具配置等价写法[api] base_url https://taotoken.net/api api_key sk-你的Key [models] implementer claude-sonnet-4-5 reviewer gpt-5-codex [loop] max_iterations 42 score_threshold 9.0这里 Base URL、Key、Model ID 三件套必须齐全缺一个 Agent 就调不起来。implementer 和 reviewer 用不同模型是为了让交叉审核真正有外部视角——同一个模型自己审自己盲区还是那个盲区。4. 验证请求跑通一轮自动迭代配置写好后先别急着跑完整循环用一轮最小验证确认调用链路是通的。这一步的目的是把「配置对不对」和「逻辑对不对」分开排查。先确认环境。需要 GitHub CLI、Go 环境以及能操控 Agent 的命令行工具。检查一下gh --version go version然后进入你要处理的 GitHub 项目目录创建一个测试用的 Issue或者直接拿一个简单的 bug fix Issue 来试。运行脚本时传入 Issue 号./docs/autoresearch/run.sh 21脚本会按顺序做这些事检查环境 → 获取 Issue 内容 → 创建分支 → 实现 Agent 写代码 → 跑测试 → 审核 Agent 评分 → 如果评分低于 9.0把反馈传给下一轮实现 Agent。一轮跑完后看results.tsv里的记录timestamp issue_number issue_title status iterations tests_passed score branch_name 2026-03-15 10:23:01 21 enhance job execution success 3 true 9.2 autoresearch/issue-21如果 status 是 success、score 达到 9.0 以上说明链路通了。如果卡在某一轮先看log.md里审核 Agent 的反馈通常能定位到是实现方向问题还是测试没通过。验证模型本身是否可用可以单独发一个请求curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: 回复 ok}] }返回里有choices字段且内容正常说明 Key 和通道没问题。这一步能快速区分是模型调用失败还是脚本逻辑问题。想直接在对话界面里验证模型可以用模型对话入口https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite5. 常见错排查401、local proxy failed、reading choices、OAuth自动迭代跑起来后报错基本集中在几类。下面按真实遇到的顺序说。401 Unauthorized。最常见的原因是 Key 没填对或者环境变量没生效。检查.autoresearch/config.json里的api_key是否和 TaoToken 后台创建的一致注意前后不要有空格。如果用的是环境变量确认脚本里读取的变量名和导出的一致echo $TAOTOKEN_API_KEY如果输出为空说明没导出成功重新export一次再跑。local proxy failed。这类报错通常出现在 Agent 工具尝试走本地代理但代理没起来的时候。检查你的工具配置里有没有多余的 proxy 设置把 Base URL 直接指向https://taotoken.net/api不要经过本地转发。如果工具本身有代理开关关掉再试。reading choices 相关报错。一般是响应结构不符合预期常见于 Model ID 写错或模型名不被识别。确认config.json里的implementer和reviewer用的是有效模型名不要自己拼一个不存在的名字。改完后单独用 curl 验证一次确认返回里有choices。OAuth 相关报错。如果你用的是 Claude Code 这类带 OAuth 流程的工具报错通常和登录态有关。检查工具是否已经完成授权或者改用 API Key 方式接入。Claude Code 的接入方式可以参考前面给的 ClaudeCodeAnthropic 文档按里面的步骤配置 Base URL 和 Key。评分一直上不去。这不是报错但很常见。先看log.md里审核 Agent 的反馈如果连续几轮都是同一个问题说明 program.md 里的约束不够明确或者 Issue 本身描述太模糊。这时候回去改 program.md把评分标准写细一点或者把 Issue 拆小。连续失败 3 次停止。这是脚本的保护机制。看日志确认是 API 调用失败还是 Agent 执行失败。如果是 API 失败检查通道状态和重试配置如果是执行失败通常是权限边界没写清楚Agent 做了不该做的事被拦下来了。6. 把统一 Key 用起来从单次验证到长期自动迭代一轮验证跑通后就可以把循环放开了。默认最多 42 轮迭代但实际中等复杂度的 Issue 通常几轮就能到 9.0。我实测下来一个涉及结构体扩展和超时控制的 Issue大约 10 分钟、3 轮迭代完成最终评分 9.2。长期跑的话有几个点值得注意。program.md 要持续更新一旦发现评分机制不符合预期就改这个文件它是整个系统的规则来源。评分趋势看log.md如果某类 Issue 总是卡在 8.5 左右说明评分标准可能偏严或者测试要求需要调整。多 Agent 交叉审核的价值在长期跑里更明显。单 Agent 自审时同一个盲区会反复出现两个不同模型轮流实现和审核A 写完 B 审、B 写完 A 审能发现单 Agent 发现不了的问题。这也是为什么统一 Key 很重要——两个模型的调用都走同一条通道重试和日志才能统一处理。如果你打算把自动迭代长期跑在项目上Coding Plan 会比按次调用更合适https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite控制台里可以看调用记录和用量https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite最后说一个实际踩过的坑program.md 里的权限边界一定要写死。我一开始没写「禁止修改 CI 配置」结果 Agent 为了实现功能顺手改了 workflow 文件虽然测试通过了但合并后 CI 行为变了。后来把禁止项列清楚这类问题就没再出现。规则写得越具体Agent 越不容易越权自动迭代也越省心。 我把 Karpathy 的 AutoResearch 搬到了软件开发领域：用 TaoToken 统一 Key 跑通 program.md 自动迭代
1. 从 Karpathy 的 AutoResearch 说起为什么软件开发也需要 program.mdKarpathy 的 AutoResearch 之所以让人眼前一亮不是因为它用了多复杂的模型而是它把「改进」这件事量化成了一个明确的数字——val loss。Agent 改 train.py、跑 5 分钟实验、看 val loss 有没有降降了就 commit没降就 git revert然后继续下一轮。人只需要维护一份 program.md相当于给 Agent 的「研究章程」剩下的交给它自己跑。这套思路放到软件开发领域其实同样成立。我们每天面对的是 GitHub 上一堆 Issue有的要修 bug有的要加功能有的要重构。传统做法是人写代码、跑测试、发现问题、再改一轮一轮 chat 交互。即使用上 Claude Code 或 Codex人还是被绑在循环里离开就不转了。我试过把 AutoResearch 的循环搬到软件开发场景核心替换逻辑很简单把「修改 train.py → 跑实验 → val loss 改善才保留」换成「实现 Issue → 跑测试 → 多维评分达标才合并」。program.md 从「研究章程」变成「开发章程」定义权限边界、代码规范、测试要求、评分标准。Agent 在循环里自主实现、自主测试、自主审核评分达标才提交 PR。这套东西适合谁适合手里有几十上百个待处理 Issue、又不想被 chat 交互绑死的开发者适合想用 AI Agent 做自动化开发、但担心单 Agent 自审有盲区的团队也适合想理解 AutoResearch 思想、把它迁移到自己领域的工程师。下面我会给出可复制的 program.md 模板、统一 Key 配置片段以及一轮自动迭代的完整验证动作。2. TaoToken 前置统一 Key 串联多 Agent 调用链路多 Agent 交叉审核的架构里最容易被忽略但最影响稳定性的是 API 通道的统一管理。Codex 和 Claude 轮流担任实现者和审核者意味着一次迭代里会有多次模型调用如果每个 Agent 各自配一套 Key、各自走一条通道排查问题时会非常痛苦——你分不清是模型本身的问题还是某条通道的限流或超时。TaoToken 在这里的作用是提供一个统一的 Key 和 API 通道把 AI Agent 的调用链路收敛到一处。你可以在一个地方管理模型访问Agent 侧只需要配置 Base URL、Key 和 Model ID 三件套。对于 program.md 驱动的自动迭代来说这意味着脚本里的模型调用可以统一走同一个入口重试、退避、日志记录都更容易做。先拿到 Key。访问 TaoToken 的 API Keys 页面创建一个https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite创建后你会得到一串 Key形如sk-xxxxxxxx。这个 Key 就是后面所有 Agent 配置里要填的东西。注意不要把它提交到 Git 仓库建议放在环境变量或本地配置文件里。接下来是接入文档不同工具的配置方式略有差异建议对照文档操作https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite如果你用的是 Claude Code 这类工具可以参考 ClaudeCodeAnthropic 的接入说明https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite统一 Key 的好处在于当自动迭代跑到第 5 轮、第 10 轮时如果出现调用失败你只需要检查一个通道的状态而不是在多个 Key 之间来回切换排查。program.md 里的退火重试逻辑指数退避 随机抖动也只需要针对这一条通道配置脚本会简单很多。3. 可复制配置program.md 模板与统一 Key 片段这一节给两份可以直接复制的东西一份 program.md 模板一份统一 Key 的配置片段。program.md 是整个自动迭代的规则核心Agent 每轮开始前都会读它所以写清楚权限边界和评分标准比写得多更重要。先看 program.md 模板。放在项目根目录的.autoresearch/program.md# AutoResearch 开发章程 ## 目标 自主完成指定 GitHub Issue 的实现评分达标后提交 PR。 ## 权限边界 允许 - 读取 Issue 内容、仓库代码、测试文件 - 创建分支、修改源码、新增测试 - 运行测试命令、查看测试输出 - 提交 commit、创建 PR 禁止 - 修改 CI 配置、发布流程 - 删除已有测试用例 - 改动与当前 Issue 无关的模块 - 直接推送到 main 分支 ## 代码规范 - 遵循项目现有风格不引入新依赖除非 Issue 明确要求 - 函数职责单一命名清晰 - 新增功能必须有对应单元测试 ## 评分标准总分 10 - 正确性 35%功能是否符合 Issue 描述 - 测试 25%测试覆盖是否充分、是否通过 - 代码质量 20%可读性、结构、命名 - 安全 10%是否有明显漏洞 - 性能 10%是否有明显性能坑 各维度得分无问题 10 / 建议改进 9 / 一般问题 7 / 严重问题 4 / 致命问题 1 达标线9.0 ## 迭代规则 - 每轮由实现 Agent 写代码审核 Agent 评分 - 评分 9.0 时审核反馈传入下一轮实现 Agent - 连续失败 3 次则停止记录日志 - API 调用失败使用指数退避重试最大等待 60 秒最多 10 次再看统一 Key 的配置片段。以 JSON 形式放在.autoresearch/config.json{ base_url: https://taotoken.net/api, api_key: sk-你的Key, models: { implementer: claude-sonnet-4-5, reviewer: gpt-5-codex }, max_iterations: 42, score_threshold: 9.0, retry: { max_attempts: 10, base_delay: 2, max_delay: 60 } }如果你用的是 TOML 风格的工具配置等价写法[api] base_url https://taotoken.net/api api_key sk-你的Key [models] implementer claude-sonnet-4-5 reviewer gpt-5-codex [loop] max_iterations 42 score_threshold 9.0这里 Base URL、Key、Model ID 三件套必须齐全缺一个 Agent 就调不起来。implementer 和 reviewer 用不同模型是为了让交叉审核真正有外部视角——同一个模型自己审自己盲区还是那个盲区。4. 验证请求跑通一轮自动迭代配置写好后先别急着跑完整循环用一轮最小验证确认调用链路是通的。这一步的目的是把「配置对不对」和「逻辑对不对」分开排查。先确认环境。需要 GitHub CLI、Go 环境以及能操控 Agent 的命令行工具。检查一下gh --version go version然后进入你要处理的 GitHub 项目目录创建一个测试用的 Issue或者直接拿一个简单的 bug fix Issue 来试。运行脚本时传入 Issue 号./docs/autoresearch/run.sh 21脚本会按顺序做这些事检查环境 → 获取 Issue 内容 → 创建分支 → 实现 Agent 写代码 → 跑测试 → 审核 Agent 评分 → 如果评分低于 9.0把反馈传给下一轮实现 Agent。一轮跑完后看results.tsv里的记录timestamp issue_number issue_title status iterations tests_passed score branch_name 2026-03-15 10:23:01 21 enhance job execution success 3 true 9.2 autoresearch/issue-21如果 status 是 success、score 达到 9.0 以上说明链路通了。如果卡在某一轮先看log.md里审核 Agent 的反馈通常能定位到是实现方向问题还是测试没通过。验证模型本身是否可用可以单独发一个请求curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: 回复 ok}] }返回里有choices字段且内容正常说明 Key 和通道没问题。这一步能快速区分是模型调用失败还是脚本逻辑问题。想直接在对话界面里验证模型可以用模型对话入口https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite5. 常见错排查401、local proxy failed、reading choices、OAuth自动迭代跑起来后报错基本集中在几类。下面按真实遇到的顺序说。401 Unauthorized。最常见的原因是 Key 没填对或者环境变量没生效。检查.autoresearch/config.json里的api_key是否和 TaoToken 后台创建的一致注意前后不要有空格。如果用的是环境变量确认脚本里读取的变量名和导出的一致echo $TAOTOKEN_API_KEY如果输出为空说明没导出成功重新export一次再跑。local proxy failed。这类报错通常出现在 Agent 工具尝试走本地代理但代理没起来的时候。检查你的工具配置里有没有多余的 proxy 设置把 Base URL 直接指向https://taotoken.net/api不要经过本地转发。如果工具本身有代理开关关掉再试。reading choices 相关报错。一般是响应结构不符合预期常见于 Model ID 写错或模型名不被识别。确认config.json里的implementer和reviewer用的是有效模型名不要自己拼一个不存在的名字。改完后单独用 curl 验证一次确认返回里有choices。OAuth 相关报错。如果你用的是 Claude Code 这类带 OAuth 流程的工具报错通常和登录态有关。检查工具是否已经完成授权或者改用 API Key 方式接入。Claude Code 的接入方式可以参考前面给的 ClaudeCodeAnthropic 文档按里面的步骤配置 Base URL 和 Key。评分一直上不去。这不是报错但很常见。先看log.md里审核 Agent 的反馈如果连续几轮都是同一个问题说明 program.md 里的约束不够明确或者 Issue 本身描述太模糊。这时候回去改 program.md把评分标准写细一点或者把 Issue 拆小。连续失败 3 次停止。这是脚本的保护机制。看日志确认是 API 调用失败还是 Agent 执行失败。如果是 API 失败检查通道状态和重试配置如果是执行失败通常是权限边界没写清楚Agent 做了不该做的事被拦下来了。6. 把统一 Key 用起来从单次验证到长期自动迭代一轮验证跑通后就可以把循环放开了。默认最多 42 轮迭代但实际中等复杂度的 Issue 通常几轮就能到 9.0。我实测下来一个涉及结构体扩展和超时控制的 Issue大约 10 分钟、3 轮迭代完成最终评分 9.2。长期跑的话有几个点值得注意。program.md 要持续更新一旦发现评分机制不符合预期就改这个文件它是整个系统的规则来源。评分趋势看log.md如果某类 Issue 总是卡在 8.5 左右说明评分标准可能偏严或者测试要求需要调整。多 Agent 交叉审核的价值在长期跑里更明显。单 Agent 自审时同一个盲区会反复出现两个不同模型轮流实现和审核A 写完 B 审、B 写完 A 审能发现单 Agent 发现不了的问题。这也是为什么统一 Key 很重要——两个模型的调用都走同一条通道重试和日志才能统一处理。如果你打算把自动迭代长期跑在项目上Coding Plan 会比按次调用更合适https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite控制台里可以看调用记录和用量https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite最后说一个实际踩过的坑program.md 里的权限边界一定要写死。我一开始没写「禁止修改 CI 配置」结果 Agent 为了实现功能顺手改了 workflow 文件虽然测试通过了但合并后 CI 行为变了。后来把禁止项列清楚这类问题就没再出现。规则写得越具体Agent 越不容易越权自动迭代也越省心。