1. 从 Copilot、Codex 的提交记录说起AgentPR 产出到底怎么统计GitHub 上每天都有大量 PR 被合入其中越来越多来自 Copilot、Codex、Claude Code 这类编码 Agent。但如果你真去问一句“这些 Agent 到底贡献了多少产出”会发现很难给出一个能复现的数字。原因不复杂Agent 提交的 PR 和人类提交的 PR 混在同一个事件流里没有统一标记仓库之间的工作流差异又大直接数 PR 数量很容易把“试了一次”和“天天在用”混为一谈。AgentPR 这个场景要解决的就是把 GitHub 上 AI 生成 PR 的产出统计做成一套可复现的口径。它适合三类人想量化团队 AI 编码工具实际收益的工程负责人、需要给 Agent 工作流做数据看板的平台开发者、以及想验证自己项目里 Copilot/Codex 使用强度的独立开发者。核心检索词就是 AgentPR、GitHub、AI、Copilot、Codex——围绕这些工具在 GitHub 上留下的提交记录梳理出从拉取事件数据、去重、到验证产出量的完整动作。我试过直接拿 GitHub 搜索框数author:copilot的结果很快就踩坑了不同 Agent 的账号命名不统一有的用 bot 后缀有的走 App 安装身份还有的通过 commit trailer 标记而不是账号。所以统计口径必须建立在原始事件数据上而不是搜索结果上。下面这套流程从统一 Key 配置开始到拉取 GitHub 事件、去重、验证产出量每一步都能跟做。2. TaoToken 前置统一 Key 管理多模型调用做 AgentPR 统计时一个绕不开的问题是你可能同时要调用多个模型来辅助分类、摘要或校验 PR 内容。比如用一个小模型判断某个 PR 是否由 Agent 生成用另一个模型对 commit message 做归一化。如果每个模型都单独配一套 Key 和 endpoint配置会迅速失控。TaoToken 在这里的角色是统一入口。它提供兼容 OpenAI 风格的 API你可以用同一个 Key 访问不同模型配置集中在一处。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 注意 API 地址不加 UTM 参数。需要先拿到 Key 的话去控制台创建https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 然后在 API Keys 页面生成https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各语言的调用示例。如果你主要做长期编码或 Agent 工作流可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。想先验证模型输出效果直接用模型对话页面https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。Claude Code 相关接入参考https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude-code-anthropicutm_campaignrewrite 。注意Key 只放在环境变量或本地配置文件里不要提交到仓库。统计脚本里用os.environ读取避免硬编码。3. 可复制配置config.toml 与 settings.json 骨架统计流程分两块配置一块是 Python 脚本用的config.toml管 GitHub token、TaoToken Key、模型名和统计参数另一块是编辑器/Agent 工具用的settings.json管模型接入。两块分开避免把 GitHub 凭证和模型凭证混在一起。先看config.toml# config.toml - AgentPR 统计配置骨架 [github] # GitHub Personal Access Token需要 repo 和 read:org 权限 token env:GITHUB_TOKEN # 要统计的仓库支持 owner/repo 格式 repos [owner/repo-a, owner/repo-b] # 统计时间窗口ISO 8601 since 2025-05-01T00:00:00Z until 2025-07-31T23:59:59Z [taotoken] # 统一 Key从环境变量读取 api_key env:TAOTOKEN_API_KEY base_url https://taotoken.net/api # 用于 PR 分类的模型 classify_model gpt-4o-mini # 用于 commit message 归一化的模型 normalize_model gpt-4o-mini [stats] # Agent 账号关键词用于初筛 agent_keywords [copilot, codex, claude, bot, mergify] # 去重时使用的字段 dedup_fields [pr_number, head_sha, merged_at] # 产出量基准线三个月人类 PR 中位数参考 baseline_pr_per_quarter 36再看settings.json这是给编辑器或 Agent 工具用的模型接入骨架{ model_provider: { name: taotoken, base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, models: { default: gpt-4o-mini, classify: gpt-4o-mini, summarize: gpt-4o-mini } }, agent: { name: agentpr-stats, max_tokens: 2048, temperature: 0.2 } }两个配置里的 Key 都走环境变量。设置方式export GITHUB_TOKENghp_你的token export TAOTOKEN_API_KEY你的taotoken_key提示config.toml里的env:前缀是脚本自己解析的约定不是 TOML 标准语法。解析逻辑在下一节的 Python 代码里。4. 拉取 GitHub 事件数据、去重与验证产出量配置就绪后核心动作分三步拉取 PR 事件、去重、验证产出量。下面用 Python 串起来每一步都有可运行的代码。4.1 拉取 PR 与关联事件GitHub REST API 的/repos/{owner}/{repo}/pulls能拿到 PR 列表但判断是否 Agent 生成需要看 commit、review 和 timeline 事件。这里用requests直接调避免引入过重的 SDK。import os import tomllib import requests from datetime import datetime def load_config(pathconfig.toml): with open(path, rb) as f: cfg tomllib.load(f) # 解析 env: 前缀 for section in cfg.values(): if isinstance(section, dict): for k, v in section.items(): if isinstance(v, str) and v.startswith(env:): section[k] os.environ.get(v[4:], ) return cfg def gh_headers(token): return { Authorization: fBearer {token}, Accept: application/vnd.githubjson, X-GitHub-Api-Version: 2022-11-28, } def fetch_pulls(cfg, repo): token cfg[github][token] since cfg[github][since] until cfg[github][until] url fhttps://api.github.com/repos/{repo}/pulls params { state: all, sort: created, direction: asc, per_page: 100, } pulls [] page 1 while True: params[page] page r requests.get(url, headersgh_headers(token), paramsparams, timeout30) r.raise_for_status() batch r.json() if not batch: break for pr in batch: created pr[created_at] if since created until: pulls.append(pr) elif created until: return pulls page 1 return pulls这段代码按创建时间升序拉取遇到超出窗口的 PR 就提前返回避免翻完所有页。4.2 判断 Agent PR 并去重判断逻辑分两层先按账号关键词初筛再用 commit trailer 和 review 记录确认。去重按pr_number head_sha组合防止同一 PR 因多次事件被重复计入。def is_agent_pr(pr, cfg): keywords cfg[stats][agent_keywords] author (pr.get(user) or {}).get(login, ).lower() if any(k in author for k in keywords): return True # 检查 commit trailer body (pr.get(body) or ).lower() if any(fco-authored-by: {k} in body for k in keywords): return True return False def dedup_pulls(pulls, cfg): seen set() result [] fields cfg[stats][dedup_fields] for pr in pulls: key tuple(str(pr.get(f, )) for f in fields) if key in seen: continue seen.add(key) result.append(pr) return result4.3 验证产出量产出量的口径是每个仓库在时间窗口内Agent PR 数量除以参与过 Agent PR 的人类贡献者数。这个比值再和基准线对比。def compute_output(pulls, cfg): baseline cfg[stats][baseline_pr_per_quarter] by_repo {} for pr in pulls: repo pr[base][repo][full_name] by_repo.setdefault(repo, {agent_prs: 0, humans: set()}) if is_agent_pr(pr, cfg): by_repo[repo][agent_prs] 1 author (pr.get(user) or {}).get(login) if author: by_repo[repo][humans].add(author) report [] for repo, data in by_repo.items(): humans max(len(data[humans]), 1) per_human data[agent_prs] / humans report.append({ repo: repo, agent_prs: data[agent_prs], humans: humans, pr_per_human: round(per_human, 2), above_baseline: per_human baseline, }) return report跑完主流程if __name__ __main__: cfg load_config() all_pulls [] for repo in cfg[github][repos]: all_pulls.extend(fetch_pulls(cfg, repo)) all_pulls dedup_pulls(all_pulls, cfg) report compute_output(all_pulls, cfg) for row in report: print(row)4.4 用 TaoToken 做二次校验初筛可能把人类账号误判为 Agent或者漏掉用 trailer 标记的 PR。这时用 TaoToken 调模型对可疑 PR 的 commit message 做分类能提高准确率。import json def classify_with_taotoken(cfg, pr): api_key cfg[taotoken][api_key] base_url cfg[taotoken][base_url] model cfg[taotoken][classify_model] prompt ( 判断下面这个 PR 是否由编码 AgentCopilot/Codex/Claude Code 等生成。 只回答 yes 或 no。\n f标题{pr.get(title, )}\n f正文{(pr.get(body) or )[:500]}\n ) r requests.post( f{base_url}/chat/completions, headers{ Authorization: fBearer {api_key}, Content-Type: application/json, }, json{ model: model, messages: [{role: user, content: prompt}], temperature: 0.1, max_tokens: 8, }, timeout30, ) r.raise_for_status() content r.json()[choices][0][message][content].strip().lower() return content.startswith(yes)把classify_with_taotoken接到is_agent_pr后面对初筛结果做一次复核误判率会明显下降。5. 本篇常见错排查统计跑不通多数问题集中在认证、分页和口径三处。下面按报错现象列排查路径。401 UnauthorizedGitHub token 过期或权限不足。检查 token 是否包含repo和read:org以及是否在环境变量里正确设置。TaoToken 侧如果报 401确认TAOTOKEN_API_KEY没有多余空格。403 rate limit exceededGitHub 未认证请求每小时 60 次认证后 5000 次。如果仓库多、PR 量大建议加time.sleep(0.5)控制频率或者用 GraphQL API 批量拉取。分页漏数据fetch_pulls里按created_at升序遇到超出until的 PR 直接返回。如果仓库 PR 创建时间乱序可能提前截断。稳妥做法是拉完所有页再过滤代价是请求数增加。去重后数量对不上检查dedup_fields是否包含head_sha。有些 PR 在 review 后 force pushhead_sha会变但pr_number不变。如果按pr_number去重会漏掉更新后的版本按head_sha去重会把同一 PR 的多个版本算成多个。建议按pr_number去重取最后一次head_sha。Agent PR 数量虚高agent_keywords里放了bot会把 dependabot、renovate 这类依赖更新机器人也算进去。如果统计目标是编码 Agent把bot从关键词里去掉或者单独维护一个机器人账号黑名单。产出量比值异常humans集合只统计了 PR 作者没有统计 reviewer 和 committer。如果按论文口径需要把 review 和 timeline 事件里的人类账号也加进来。拉取/repos/{owner}/{repo}/pulls/{number}/reviews和/issues/{number}/timeline补充。TaoToken 调用超时批量分类时并发过高会触发限流。用concurrent.futures控制并发数在 5 以内或者加指数退避重试。注意所有统计口径都要在报告里写清楚包括时间窗口、Agent 判定规则、去重字段、人类参与者定义。口径不写清楚数字就没法复现。6. 把统计接进你的 Agent 工作流跑通上面的流程后你会得到一份按仓库分组的 AgentPR 产出报告。接下来可以把它接进日常用 cron 每周跑一次把结果写进 SQLite 或推送到看板或者把classify_with_taotoken换成更强的模型对 PR 做更细的分类比如区分“Agent 独立完成”和“Agent 辅助人类完成”。如果你在做长期编码或 Agent 工作流建议把模型接入统一到 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 这样统计脚本和编码工具共用一套 Key配置不会散。需要先验证模型分类效果去模型对话页面试几条真实 PRhttps://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。接入细节和参数说明在文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。最后留一个实操建议第一次跑先只选一个仓库把since和until缩到一周确认 Agent 判定和去重逻辑符合预期再放大到全量。统计口径的坑基本都是在小样本上先暴露出来的。
