阿里开源 Open Code Review：用「确定性工程 × Agent」重写 AI 代码评审的工程管线

一、导读

阿里把内部用了两年的官方 AI 代码评审助手开源为 alibaba/open-code-review（命令名 ocr），上线四个月已到 3.6 万星、当日再涨 2,724 星。它最值得读的不是"又一个 AI 审代码工具"，而是一个架构判断：代码评审的可靠性来自工程管线，而不是提示词。在自家 AACR-Bench 上，同一底层模型下它的 F1 与精确率显著高于通用 Agent，token 消耗约为后者 1/9；代价是召回率更低，这是刻意为之的取舍。本文基于仓库源码、官方文档与第三方实践反馈，拆解这条 Go 语言写成的流水线。

二、项目速览

项目	详情
仓库	alibaba/open-code-review（CLI 命令 ocr）
团队	阿里巴巴（源自集团内部 AI 代码评审助手，官方称服务数万开发者）
主语言	Go（仓库体积约 52 MB，另含 VS Code / JetBrains 插件源码）
Star 总数	36,575（GitHub API，2026-09-18 抓取）
当日涨星	+2,724（GitHub Trending daily，2026-09-19 抓取），周涨 +11,489
License	Apache-2.0
首次发布	仓库创建于 2026-05-18，v1.0.0 于 2026-05-21 发布
最新版本	v1.12.6（2026-09-18 发布；近一周几乎每天发版）
社区规模	2,606 fork、231 开放 issue、贡献者 100+、npm 30 天下载 150K+
官网	open-codereview.ai

三、为什么是它

它踩中了一个真实且正在扩大的缺口。 阿里在开源两周月的复盘博客里引用 Faros AI《The Acceleration Whiplash》的遥测（4,000 个团队、22,000 名开发者）：AI 编码工具让单人任务完成量提升 34%、代码活动量上涨 210%，但返工率飙升 861%、每 PR 生产事故上升 242.7%、PR 平均评审时长拉长 441.5%、未经评审即合并的 PR 占比增加 31.3%。也就是说，AI 把瓶颈从"写代码"搬到了"看代码"。这条数据与该仓库的定位完全吻合：它不帮你写代码，只在合入前拦截缺陷。

它的差异点不是模型，而是对流程的强约束。 官方 README 直接否定了"通用 Agent + Skill 做评审"的路线，列出三类典型失效：变更集大时 Agent"偷懒"只审部分文件；报出的问题与真实代码位置漂移；纯自然语言驱动的质量随提示词微调而波动。根因被归纳为一句：纯语言驱动的架构对评审流程缺乏硬约束。于是它把"不能出错"的环节——文件选择、文件打包、规则路由、行号定位——交给确定性代码，把"需要判断"的环节——动态决策与上下文召回——留给 LLM Agent。

可核验的生产背书与零改造成本进一步放大了传播。 官方披露的内部数据是：月活 2 万+、采纳率 30%+、误报率低于 5%、合入主干的 AI 有效建议占比接近 80%；面向社区的数字是 3M+ 次真实评审任务、150K+ 次 npm 下载（近 30 天）。加上"自带模型密钥、数据不出内网、一条 npm install 即可用"的低门槛，以及需要私有化评审能力的合规团队（第三方实践中提到"合规要求不能接商用 SaaS 评审"），共同解释了它为什么能在四个月里从 0 冲到 3.6 万星：2026-05-28 首登 Trending（400 星）、06-06 登上 Hacker News 首页（1.5k→4k）、07-23 至 07-28 连续五天停留在 Trending 首页（10.5k→15.5k），随后靠每周多次发版维持热度。

四、架构原理

4.1 整体架构与数据流

ocr review 的主链路是一条"先收敛、再并发、后校验"的流水线，全程围绕 Git diff 展开：

命令入口  ocr review [--from A --to B | --commit SHA | 无参=工作区]
   │
   ▼
① bootstrap      解析 LLM 端点(config → env → rc 文件) + 载入模板/工具注册表/系统规则
   │
   ▼
② diff provider  git diff / ls-tree / show → []model.Diff（三种模式，统一 3 行上下文）
   │
   ▼
③ 六道闸门过滤   二进制 → 密钥路径 → 用户 exclude → 用户 include → 扩展名白名单 → 测试文件默认排除
   │             （vendor/、node_modules/ 等在②就已按目录丢弃）
   ▼
④ 语义分组       仅用文件元数据（路径/状态/增删行数）发一次 GROUPING_TASK，把关联文件打成一包
   │             每组最多 10 个文件，上下文互相隔离
   ▼
⑤ 子任务并发      每组一个 sub-agent（默认并发 8）：
   │             [可选] PLAN_TASK 出检查清单 → MAIN_TASK 工具循环 × N 轮（effort 决定轮数）
   ▼
⑥ 后处理与渲染    行号解析 → 可选 RE_LOCATION 重定位 → REVIEW_FILTER 剔除可证伪评论
                 → 文本或 JSON 输出，同时落 JSONL 会话日志

三条设计线索贯穿其中。确定性优先：①②③④都是纯工程逻辑，不消耗 token、结果可复现；ocr review --preview 甚至能在零成本下打印"哪些文件会被审、哪些被丢弃及原因"。分组即分治：每个分组拥有独立会话与独立上下文预算，大变更集因此不会挤爆单一上下文窗口，也天然支持并发。后置纠错：模型产出的评论不直接透出，必须先经过行号定位与一轮"反思过滤"，把可证明错误的评论删掉。

4.2 分层模块拆解

协议与配置层（internal/llm、internal/config）：端点解析按"配置文件 → 环境变量 → rc 文件"顺序取第一个完整三元组 (URL, token, model)，找不到就直接非零退出，官方文档明确"端点发现没有兜底"；兼容 OpenAI 与 Anthropic 两种协议形状（use_anthropic 开关），可用 ocr config set 在 CI 中非交互写入。

过滤与规则层（internal/agent/selection.go、internal/config/rules）：文件先过六道闸门，其中第 2 道"密钥路径保护"来自内置 default_secret_patterns.json，先于用户规则且不可被 include 覆盖；**/*_test.go、**/__tests__/** 等测试文件在最后一道闸门默认排除，但用户 include 可以放行。规则解析是四层优先级链：--rule 参数 > 仓库内 .opencodereview/rule.json > 用户全局 ~/.opencodereview/rule.json > 二进制内置的 system_rules.json；每条规则支持 include/exclude/rules[{path, rule}] 三段结构，glob 用 doublestar 实现、匹配前统一小写。内置规则文档覆盖 50+ 语言与文件类型（java、go、python、ts_js_tsx、mapper_dao_xml、terraform、rego、github_workflows 等）。这也是社区 PR 最活跃的方向之一——issue #470 直接以"征募语言专家"的形式邀请外部贡献规则。

编排层（internal/agent/agent.go、grouping.go）：Agent.Run 负责全局收敛，dispatchSubtasks 按分组扇出。分组阶段刻意只看元数据、不看 diff 内容，一次调用拿到 {label, files} 数组；三道护栏保证它不会成为正确性瓶颈——单组上限 10 文件、超出提示预算的组拆回单文件、模型漏分配的文件各自成组；分组失败时静默退化为"一文件一组"。

Agent 循环层（internal/llmloop）：这是唯一由模型主导的部分。主循环最多 MAX_TOOL_REQUEST_TIMES=100 次工具调用，连续 3 轮拿不到有效工具结果即退出，同时支持 task_done 主动收尾；每个分组还会按 --effort 档位跑 1/2/3 轮（low/medium/high），后续轮次会把上一轮已确认的问题以 {{confirmed_comments}} 注入、并故意去掉计划——官方注释说计划一旦存在就会变成覆盖天花板。

工具层与评论后处理（internal/tool）：只有六个工具，且分阶段暴露——code_search、file_read_diff、file_find 在计划期与主循环都可用，file_read、code_comment、task_done 仅主循环可用，保证计划阶段严格只读。官方称工具集是"从大规模线上调用轨迹里蒸馏出来的"，分析过调用频率分布、单工具重复调用率、新增工具对整条调用链的影响。评论产出后进入固定大小的工作池，依次做滑动窗口行号解析、失败时的 RE_LOCATION_TASK 重锚定、以及主循环结束后的 REVIEW_FILTER_TASK 证伪过滤。

持久化与可观测层（internal/session、internal/viewer、internal/telemetry）：每次评审以 JSONL 追加写落到 ~/.opencodereview/sessions/，一行一个事件（prompt、响应、工具调用、评论）；ocr viewer 直接读文件渲染 Web UI，没有数据库。遥测走 OpenTelemetry，只发三个流水线 span 与决策点事件，prompt 与响应内容从不写入遥测。

4.3 核心机制与算法原理

计划阶段的触发阈值是纯粹的工程判断，不看模型心情：

// PLAN_MODE_LINE_THRESHOLD = 50, PLAN_MODE_GROUP_LINE_THRESHOLD = 100
if maxFileChanged >= 50                        { plan }   // 单个文件大改写
if fileCount >= 2 && totalChanged >= 100       { plan }   // 多个中等文件

小改动直接跳过计划，省掉一次往返延迟；触发时只发一次 PLAN_TASK，且不传 Tools 字段，模型在计划期物理上无法调用工具，只被允许参考以纯文本嵌入的 {{plan_tools}} 说明。

三层记忆压缩解决长循环的上下文溢出。输入上限 MAX_TOKENS=200000，输出上限单独由 MAX_COMPLETION_TOKENS=16384 控制（两者解耦，调大输入上限不会悄悄抬高输出预算）。消息被切成三区：frozen（system + 首条 user，永不压缩）、compress（中间的旧轮次）、active（最近 K 个完整轮次）。占用到 60% 时异步启动 MEMORY_COMPRESSION_TASK，主循环继续跑；到 80% 时改为同步压缩，保证下一条请求一定塞得下；压缩结果以 <previous_review_summary> 标签追回原始 user 消息。

评论定位决定输出能不能直接贴到 PR 上，算法是三级降级：先在 hunks 新侧找"连续 上下文+新增行"，失败则试旧侧，再失败就在整份变更后文件里逐行滑窗匹配；仍失败就跑一次 RE_LOCATION_TASK 让模型重新给锚点；最终仍失败则把 start_line 置 0——下游据此判定"未锚定评论，需人工定位"。

Token 预算的三道闸门体现"宁可跳过也不烧穿"：分组前，若单文件 diff 已超过 MAX_TOKENS 的 80%，标记 too_large 直接不审；每组调度前，若消息 token 超过上限 80%，记录 token_threshold_exceeded 并跳过该组（作为非致命警告输出）；分组内部还有一道 enforceGroupTokenBudget。

4.4 基准数据：同一底层模型下的对照

官方基准集 AACR-Bench 由 50 个流行开源仓库、200 个真实 PR、10 种编程语言构成，80 余位高级工程师标注出 1,505 条真实问题（数据集已开源于 Hugging Face Alibaba-Aone/aacr-bench，配套论文 arXiv:2601.19494，其"AI 辅助 + 专家复核"标注管线相对原始 PR 评论把缺陷覆盖提升了 285%）。官网公布的对照表（数据抓取于 2026-09-19）如下：

底层模型	方案	F1	精确率	召回率	平均耗时	平均 token
Claude-4.6-Opus	OCR v1.3.1	25.10%	33.90%（301/889）	20.00%	1m23s	385K
Claude-4.6-Opus	Claude Code v2.1.169	11.57%	7.23%（435/5980）	28.90%	13m6s	5,664K
Claude-4.8-Opus	OCR v1.3.1	17.90%	37.80%（176/465）	11.70%	1m6s	352K
Claude-4.8-Opus	Claude Code	14.13%	15.93%（191/1200）	12.70%	5m38s	2,062K
Qwen3.7-Max	OCR v1.3.1	21.20%	25.20%（276/1096）	18.30%	4m41s	625K
Qwen3.7-Max	Claude Code	12.17%	8.23%（351/4260）	23.37%	8m6s	5,153K
GLM-5.1	OCR v1.3.1	20.40%	28.90%（237/820）	15.70%	4m11s	743K
GLM-5.1	Claude Code	11.93%	8.37%（313/3742）	20.80%	14m10s	4,038K
GPT-5.5	OCR v1.3.1	21.00%	32.10%（234/728）	15.50%	2m51s	422K
GPT-5.5	Codex v0.140.0	8.36%	27.82%（74/266）	4.92%	2m58s	525K
Qwen3.8-Max	OCR v1.8.7	23.00%	33.90%（262/774）	17.40%	5m14s	334K

三个要点：同模型下 OCR 的 F1 普遍是通用 Agent 的 1.5–2 倍，精确率差距更大（Claude-4.6-Opus 配置下 OCR 报 889 条命中 301 条，Claude Code 报 5,980 条才命中 435 条）；召回率排序相反，Claude Code 多数更高（最高 28.90% vs OCR 20.00%），官方称之为"精确率优先于噪声"的刻意取舍；token 比约为 1/5.9 至 1/14.7，官网据此给出"约 1/9 token（对照 1,000 个 PR）"口径。首页另标注最高分组合的 SEM.F1 为 25.10%（该口径的精确定义未在公开文档给出，待确认）。

4.5 设计取舍与其他架构路线

官方把"不做什么"写得很清楚：端点发现不兜底；子任务失败只隔离不重试（一组失败产出一条警告，其余继续，重试交给外层 CI）；跨文件推理受分组边界限制——其他文件只能通过 file_read_diff/code_search 只读访问，且不允许对组外文件发表评论。这三条共同换来"每组可确定、成本可预测"。

与另两条路线相比：纯 Skill / 通用 Agent 路线胜在零集成成本，但覆盖、位置与稳定性都不受约束；纯静态分析路线胜在确定性与零 token，但只认模式不认语义，无法判断"这个校验缺失在业务上是否真的可被触发"；OCR 的选择是串起两者——用工程做收敛与定位，用模型做语义判断，代价是必须自备模型并接受较低召回。

五、应用场景

场景一：把评审挂进 GitHub Actions，做 PR 门禁

痛点：PR 数量随 AI 编码上升，评审人力跟不上；商用 SaaS 评审在部分企业受合规限制。 做法：仓库自带 examples/github_actions/ocr-review.yml，触发条件是 pull_request_target（opened）与 issue_comment（正文以 /open-code-review 或 @open-code-review 开头），后者让评审者可在 PR 下留言按需重跑。

- uses: alibaba/open-code-review@main
  with:
    provider: openai     # 也支持 anthropic / gemini / bedrock / azure / 自定义
    model: gpt-4o
    api-key: ${{ secrets.OPENAI_API_KEY }}

核心命令三条（可直接本地复现 CI 行为；--audience agent 会压掉进度输出，只留结构化 JSON）：

npm install -g @alibaba-group/open-code-review      # 需要 Git >= 2.41
ocr config set provider anthropic && ocr config set model claude-opus-4-6
ocr config set providers.anthropic.api_key sk-ant-xxx
ocr review --from origin/main --to origin/feature --format json --audience agent > review.json

收益与量化：同模型对照下，一次评审从 13m6s / 5,664K token 降到 1m23s / 385K，精确率从 7.23% 升到 33.90%（官方基准，2026-09-19 抓取）。落到门禁可用性上还有个关键数字：官方称内部误报率低于 5%——门禁最怕的不是漏报，而是每天几十条无关评论把人赶跑。 边界：它不做构建、不跑测试、不执行 PR 里的代码，只读 diff，不能替代 CI 单测；超出 80% 预算的文件会被主动跳过，因此门禁应声明"部分覆盖"而不是"全量已审"。

场景二：存量仓库"全量体检"（ocr scan）

痛点：接手老项目时没有有意义的 diff，常规"只审改动"的工具无用武之地；关键目录（支付、权限）值得定期扫。 做法：ocr scan 不依赖 git 历史，直接审整份文件。

ocr scan                              # 全仓库
ocr scan --path internal/agent        # 指定目录
ocr scan --resume                     # 中断后恢复
ocr review --preview                  # 先零成本看范围（不调用 LLM）

调度前 ocr scan 会打印粗略 token 成本估算，并支持 --max-tokens-budget 封顶（0 表示不限），超预算即停止派发。 收益与量化：把"人读代码找历史问题"变成可预算任务，配合 --format json 可把扫描结果导入内部缺陷平台做趋势统计；对"接手陌生代码库"与"关键模块定期巡检"这两类任务，它是纯 diff 工具覆盖不到的独有入口。 边界：全量扫描成本随仓库线性上升，不适合每次提交都跑，应定位为季度或专项审计；扫描出的是候选缺陷，仍需人工确认优先级。

场景三：内网私有模型 + 合规场景

痛点：代码不能出内网，且不允许接入商用 SaaS 评审服务。 做法：OCR 只提供框架、不接管数据，可指向任意 OpenAI/Anthropic 兼容端点或本地模型，也能复用已有的 Anthropic 环境变量（ANTHROPIC_BASE_URL/ANTHROPIC_AUTH_TOKEN/ANTHROPIC_MODEL），无需新增凭证。

ocr config set llm.url http://localhost:11434/v1
ocr config set llm.model qwen3-coder
ocr config set llm.use_anthropic false
ocr llm test        # 先验证连通性，避免整轮跑空

收益与量化：数据面上，只有 diff 会发往你自己指定的端点，遥测不含 prompt 与响应内容；合规面上，仓库已附 ASSURANCE_CASE.md（威胁模型与信任边界）与 OpenSSF Best Practices Gold 徽章，可作为内部安全评审材料的输入。内部 2 万月活、误报率低于 5% 也说明该形态在超大规模内网里跑得通。 边界：官方 FAQ 明确警告——模型必须支持原生 tool calling，只能"用文字描述工具调用"的模型（含部分本地模型、把调用写在 <think> 里的模型）会导致每轮都报 No tool calls parsed、最终零评论。

场景四：在编码智能体里走"委托模式"，不额外配置模型

痛点：团队已经为 Claude Code / Codex / Cursor 付了订阅，不想再为评审单独配一套模型密钥。 做法：委托模式下 OCR 只做确定性部分——解析评审范围、应用 exclude、加载规则、注入背景、收集 diff——再把结构化任务交给宿主智能体，由后者用自己的模型完成评审。

ocr delegate preview                                   # 看会交付什么
ocr delegate rule src/main.go src/handler.go           # 取该文件应使用的规则

仓库同时提供 Claude Code / Codex / Cursor / Kimi Code / OpenCode / QCA 的插件与可移植 Skill（plugins/、skills/）。 收益与量化：零新增 API key，规则与范围仍由工程侧保证；对已按量或按席位订阅宿主的团队，等于把评审的边际成本压到接近于零。 边界：委托模式下评审质量回归宿主模型与提示词，官方基准表的精度优势（依赖 MAIN_TASK 提示与专属工具集）未必等价成立；宿主模型若不支持工具调用，委托模式同样出不了评论，需先抽样验证。

场景五：历史 PR 批量回归审计

痛点：想把过去半年的 PR 全量重审一遍，评估引入 AI 评审前后的差异。 做法：逐 commit 跑 commit 模式并收集 JSON：

for c in $(git log --since=6.months --format=%H); do
  ocr review --commit "$c" --format json --audience agent --output "out/$c.json"
done

收益与量化：产出可聚合的历史缺陷分布，并可把这份分布当作基线来校准后续门禁的严格度；按官方单 PR 平均 1–6 分钟（随模型与 --effort 变化）估算，1,400 个 PR 的墙钟时间正好落在十小时量级，与社区实测吻合。建议先跑 10 个 PR 做成本标定再放大。 边界：这是社区实测过的"昂贵路径"——V2EX 上有用户把 1,400 个历史 PR 丢进 CI 连续跑了十多个小时，并指出"只改一两个文件几行代码的 PR 有时也要几分钟"（个人实践口径，非官方数据，待确认）；若目标只是防回归，更划算的做法是在 CI 里只审增量。

六、快速上手

# 1. 安装（需 Git >= 2.41、Node >= 18）
npm install -g @alibaba-group/open-code-review && ocr version
# 2. 配置模型（交互式；CI 中用 ocr config set 非交互写入）
ocr config provider && ocr config model && ocr llm test
# 3. 三种评审入口
ocr review                       # 工作区：已暂存 + 未暂存 + 未跟踪
ocr review --from main --to feature-branch
ocr review --commit abc123
# 4. 结果落盘并回看
ocr review --format json --output result.json
ocr viewer                       # 浏览器里浏览/回放会话，可标记已修复或忽略

只想看范围不花钱时用 --preview；--effort low|medium|high 控制每个分组的评审轮数（1/2/3 轮）。

七、横向对比

维度	open-code-review	通用 Agent + Skill	Claude Code /code-review	商用 SaaS 评审（CodeRabbit / Greptile 类）	SAST 规则引擎
核心判据	确定性管线 + Agent	纯自然语言驱动	多智能体 + 全库上下文	托管模型 + 托管规则	规则/模式匹配
模型选择	任意（自带 key，可本地）	宿主模型	Anthropic 模型	供应商决定	无
数据边界	只把 diff 发往你指定的端点	随宿主	随供应商	代码经第三方	本地
基准表现	F1 17.9–25.1%（同模型）	同模型 F1 约 8–14%	F1 10.9–14.1%	未公开同口径数据，待确认	不适用（规则召回）
成本	约 1/9 token（官网口径）	高（基准表最高 5,664K/PR）	报道称约 15–25 美元/PR（行业估算）	按席位订阅，以官网为准	近乎零
集成	CLI / CI / IDE / MCP / Agent 插件	依赖宿主	Claude Code 内	托管 PR 机器人	CI 插件
许可/合规	Apache-2.0，可自托管	随宿主条款	商业条款	商业条款，需合规评估	视产品

需说明：第三方媒体援引 Anthropic 官方数据称其 Code Review 让"获得实质性评审意见的 PR 占比从 16% 升到 54%"、千行以上大 PR 有 84% 能发现问题、平均每 PR 7.5 个问题、被工程师判定为错误的发现不足 1%；但该套数据与 AACR-Bench 口径不同，不能与上表直接比较（来源为二手报道，细节待确认）。

八、局限、风险与社区观察

刻意的低召回。官方把"召回率低于通用 Agent"写在 README 显著位置，并在评审轮次设计上进一步偏向精度（多轮只做补充、不重写）。它对"地毯式排查"型需求并不合适，需与 SAST 或通用 Agent 组合。

版本节奏快，锚点要自己打。四个月发布到 v1.12.6，近一周几乎每日一个 patch（v1.12.1→v1.12.6），变更集中在 viewer 界面、allowlist、LLM 兼容层与 CI action。生产集成应锁定具体 tag，并预期 CLI 行为与配置格式仍会演进。

工程化的"不自动化"清单。端点发现无兜底；子任务失败隔离不重试；跨文件推理受分组边界约束；组外文件不允许发表评论。这些既是确定性的来源，也是能力上限：跨模块的深层架构问题仍要靠人。

安全模型已文档化，但边界要读。ASSURANCE_CASE.md 把 git diff 视为"可能含对抗内容"的半可信输入、把 LLM 响应视为使用前需校验的半可信来源、把本地 viewer 视为可被 DNS 重绑定攻击的不可信面；密钥路径保护先于用户规则且不可覆盖，是少见的"防误配"设计。不过对"用 LLM 审 LLM 写的代码"这一范式本身的有效性，仍缺乏独立第三方大样本验证——现有基准与内部数据均由项目方提供（可参考社区评测与 V2EX 讨论，结论仍有分歧）。

社区与治理。仓库有 GOVERNANCE.md（组件归属、兼容性意识、安全优先）、ROADMAP.md（H2 2026 计划含 JetBrains 插件与订阅友好的委托模式）、多语种文档与 i18n 工作流；231 个开放 issue 中，规则语言扩展与 CI action 增强是最热的两类，说明"规则库广度"仍是当前最需要外部贡献的短板。

九、小结与行动建议

它真正的贡献是把"AI 评审"从提示词工程推进到管线工程：文件选择、分组、规则路由、行号定位、预算控制全部由代码保证，模型只在需要判断处发力。这也是它用同模型把 F1 拉到通用 Agent 1.5–2 倍、同时把 token 压到约 1/9 的原因；低召回是同一取舍的另一面。给落地者的建议：

1. 先做零成本标定：用 ocr review --preview 与 ocr scan 的成本估算确认范围与预算，再决定档位（--effort）与模型。
2. 按"精度优先"选型：若瓶颈是"没人愿意在几十条误报里找真问题"，它与该取向吻合；若要求零漏报，请与 SAST 或通用 Agent 组合，而不是指望它单打。
3. 先验证工具调用能力：任何候选模型先跑 ocr llm test，再用一个小 PR 验证能否产出评论——不支持原生 tool calling 的模型直接排除。
4. 规则本地化：在仓库内放 .opencodereview/rule.json 写团队规范（如"所有导出函数必须校验入参"），比改提示词稳定得多。
5. 锁 tag、控范围：把评审限定在关键目录与关键分支，CI 里用 --max-tokens-budget 兜底，并预期未来一到两个季度 API 与配置仍有变动。

资料来源（抓取日期 2026-09-18 至 2026-09-19）：GitHub Trending daily/weekly 页与 GitHub REST API；仓库 README（英/中）、pages/src/content/docs/en/ 下 architecture / quickstart / review-rules / tools / integrations/ci / faq 等文档、ASSURANCE_CASE.md、GOVERNANCE.md、ROADMAP.md、internal/ 源码，以及官网 pages/src/components/BenchmarkSection.tsx 公布的基准表与 i18n 文案（20K+ 内部活跃用户、150K+ 30 天下载、3M+ 任务、1/9 token）；官方博客《Reflections on Five Straight Days on the GitHub Trending Front Page》（2026-07-29）；arXiv:2601.19494（AACR-Bench）；社区讨论（V2EX t/1220633、阿里云开发者社区与第三方评测文章）；竞品数据来自二手媒体报道，Faros AI 报告数字经官方博客转引。凡属估算、二手转引或口径不明的数字，文中均已标注。