Newshot GitHub 上星标最多的 AI 工具中，有多少是由编码智能体编写的？
对 GitHub AI 工具主题中 52 个星标最多的仓库的完整 git 历史（324,088 次提交）进行了检查，查看 AI 签名、churn 以及每个项目发布了哪些关于自身结果的信息。
数据说明了什么
带 AI 签名的提交很常见
在中位仓库中，其最近 180 天活动里有 16.9% 的提交带有 AI 签名（全历史为 13.6%）。52 个仓库中有 21 个达到 25% 或以上，10 个达到 50% 或以上。38 个仓库至少 5% 的提交带有签名，另有 9 个仓库提交了面向编码智能体的指令，但签名比例更低，还有 5 个仓库两种信号都没有（未知，而非“没有 AI”）。
AI 占比与流行度并不相关
星标数与 AI 签名占比之间没有可检测到的联系（Spearman ρ = -0.05，p = 0.72）。星标最多的十个仓库，其 AI 签名占比从 0% 到 73.6% 不等。
在相同项目年龄下，修复提交更多，被丢弃的代码没有更多
在第 180 天，这些仓库标记为修复的提交数量是 12 个知名的 Copilot 之前项目的 2.0 倍（34.1% 对 17.3%），churn 更低（1.92x 对 3.77x），并且编写的代码留存更多（67.1% 对 41.7%）。
此处无法区分 AI 使用与项目新近程度
修复占比、churn 和留存差距集中在 2025 年或之后启动的 31 个项目中：在它们之中，至少 5% 的提交带有签名的仓库与签名比例更低的仓库之间没有可检测到的差异，而更早启动的 10 个仓库与基线之间也没有可检测到的差异。大量使用 AI 的情况集中在最新的项目中（AI 占比与启动日期：ρ = 0.72），因此这个样本无法将 AI 使用与项目新近程度区分开。在一年时（20 个仓库达到该时长），修复占比差距仍然存在，但 churn 和留存差距已不再可检测到。
许多项目发布自己的结果，包括不利结果
24 个仓库发布了带有已提交结果的基准测试 harness；其中 15 个衡量工具是否完成其工作（节省的 token、准确率、成本、任务成功率），11 个带有 AI 签名。有几个项目发布了不利于自己的数字。3 个没有发布任何量化内容。
提交中有多少 AI
52 个仓库如何划分
带签名是指在全历史或最近 180 天活动中，至少 5% 的提交带有 AI 共同作者 trailer、以 AI 智能体作为作者或提交者，或带有“Generated with”页脚。52 个仓库中有 44 个还提交了智能体指令（CLAUDE.md、AGENTS.md 及类似文件），7 个在 CI 中运行编码智能体。
各仓库近期提交的 AI 签名占比
按最近 180 天活动中 AI 签名提交占比划分的仓库数量。
最近 180 天活动中 AI 签名占比最高
哪些工具会为提交签名
36,892 次带签名的提交中，85.3% 是 Claude 的。Claude Code 默认添加 trailer，因此签名频率更低的工具会被少计。
最近 180 天活动的 AI 签名占比比全历史至少高 15 个百分点。
| 仓库 | 创建日期 | AI 签名，全历史 | AI 签名，最近 180 天 |
|---|---|---|---|
| go-zero | 2020-08-07 | 1.3% | 23.1% |
| yao | 2021-09-06
其余 5 个（anything-llm、PageIndex、QwenPaw、conductor、open-webui）的署名比例低于 5%，且没有提交任何 agent 配置。它们的 AI 使用情况未知。
热度
star 数与 AI 署名占比之间的 Spearman ρ：全历史为 -0.15（p = 0.30），最近 180 天的活动为 -0.05（p = 0.72）。star 数与修复占比：ρ = -0.0（p = 0.99）。star 数越多的仓库改动越频繁（ρ = 0.33，p = 0.017）。
star 数最多的十个
| 仓库 | Star 数 | AI 署名，全历史 | 最近 180 天 | AI 证据 |
|---|---|---|---|---|
| superpowers | 314,290 | 13.3% | 6.1% | 已署名 |
| ECC | 299,342 | 8.1% | 7.9% | 已署名 |
| deepseek-harness | 276,014 | 0% | 0% | agent 配置，署名 <5% |
| hermes-agent | 261,582 | 2.9% | 2.8% | agent 配置，署名 <5% |
| firecrawl | 199,609 | 13.1% | 42.1% | 已署名 |
| AutoGPT | 187,937 | 20.4% | 73.6% | 已署名 |
| ponytail | 186,540 | 24.1% | 24.1% | 已署名 |
| ollama | 186,319 | 0.1% | 0.2% | agent 配置，署名 <5% |
| transformers | 168,646 | 1% | 10% | 已署名 |
| dify | 160,649 | 5.3% | 6.7% | 已署名 |
相同年龄下的修复与改动
改动频率取决于项目的年龄，因此每个仓库都在首次提交后第 180 天和第 365 天的最后一个主线提交处检出，并用相同方式测量。基线是 12 个著名项目（star 数超过 4 万），其第一年在 GitHub Copilot 正式可用（2022-06-21）之前就已结束。在 HEAD 处，这里的仓库中位数修复占比为 36.3%，改动比率为 2.08 倍，存活率为 65%。
第 180 天的中位数：这 41 个仓库对比 12 个基线项目。
这些仓库对比基线，在第 180 天和第 365 天
| 中位数 | 这些仓库，第 180 天 | 基线，第 180 天 | 这些仓库，第 365 天 | 基线，第 365 天 | ||
|---|---|---|---|---|---|---|
| 提交数 | 1318 | 678.5 | p = 0.082 | 2013.5 | 1119.5 | p = 0.045 |
| 修复占比 | 34.1 | 17.3 | p < 0.001 | 27.3 | 17.1 | p < 0.001 |
| 改动比率 | 1.92 | 3.77 | p = 0.008 | 2.47 | 3.56 | p = 0.41 |
| 存活率 | 67.1 | 41.7 | p = 0.011 | 57.55 | 43.65 | p = 0.46 |
| 仓库数 | 41 | 12 | 20 | 12 |
p 值：双侧 Mann-Whitney U 检验，10,000 次置换，未针对检验数量做校正。基线在两个年龄点都显示 0% 的 AI 署名提交，这检验了检测器的假阳性率。第 180 天时，52 个仓库中有 41 个被比较：8 个的历史不足 180 天（deepseek-harness、elephant-goldfish-model、get-shit-done、gsd-2、holaOS、munder-difflin、ponytail、thinkrail），另有 3 个快照早于 Copilot。第 180 天是主要对比：第 365 天时只有 20 个仓库符合条件，而它们在该年龄时的 AI 参与度远低于此（中位数 0.8% AI 署名）。
是 AI 的作用，还是项目启动时间的作用？
在这些仓库内部，AI 占比与修复占比相关，与其他两项的关系不明显：修复占比 ρ = 0.46（p = 0.003）；改动 ρ = -0.22（p = 0.17）；存活率 ρ = 0.21（p = 0.18）。但 AI 占比也随项目启动时间的临近而上升（ρ = 0.72，p < 0.001）：31 个在 2025 年或之后启动的项目中，有 23 个到第 180 天时至少 5% 的提交被署名，而更早启动的 10 个项目中这一数字为 0。
| 中位数，第 180 天 | 2025+ 启动，署名 ≥5% | 2025+ 启动，署名 <5% | 2022–2024 启动 | 基线 | 2025+：署名 vs 未署名 | 2025+ vs 基线 | 2022–2024 vs 基线 |
|---|---|---|---|---|---|---|---|
| 修复占比 | 36.2 | 34.65 | 22 | 17.3 | p = 0.47 | p < 0.001 | p = 0.18 |
| 改动 | 1.89 | 1.86 | 2.79 | 3.77 | p = 0.57 | p = 0.003 | p = 0.37 |
| 存活率 | 69.2 | 69.25 | 52.95 | 41.7 | p = 0.60 | p = 0.003 | p = 0.38 |
| 仓库数 | 23 | 8 | 10 | 12 |
这篇文章的标题是：GitHub 上星标最多的 AI 工具中，有多少是由编码智能体编写的？
正文： 修复占比、流失率和存活率上的差距集中在 2025 年或之后启动的 31 个项目中：在这些项目里，至少为 5% 的提交签名的仓库与签名比例更低的仓库之间没有可检测到的差异，而更早启动的 10 个仓库与基线之间也没有可检测到的差异。AI 使用密集的情况集中在新近的项目中（AI 占比与启动日期：ρ = 0.72），因此这个样本无法将 AI 使用与新近程度区分开。签名较少的项目不一定就是没有智能体的项目，因此在新近项目内部的比较，是在更可见与更不明显的 AI 使用之间进行的。
各项目就自身结果发布了什么
各仓库就自身性能发布的最有力证据
在有测试框架并提交了结果的 24 个仓库中，15 个衡量工具是否完成其本职工作（节省的 token 数、准确率、成本、任务成功率），9 个只衡量软件本身的速度（AutoGPT、Paradev、agent-orchestrator、cmux、deepseek-harness、happy、orca、transformers、yao）。
有几个项目发布的结果对自己不利，其中包括 ECC、archify、context-mode 和 caveman。有 3 个仓库（agents、conductor、elephant-goldfish-model）完全没有发布任何定量结果。
结果均为项目自己的主张，按被审计提交中的文件和行号定位，并按证据类型分类。没有一项被重新运行。
15 项成果基准测试，AI 签名的仓库排在前面
点击某一行可查看该仓库发布内容的摘要以及确切文件的链接。
Caveman 发布了三项结果，配有可运行的测试框架和已提交的数据：一项是在 claude-opus-5-5 上对 10 个提示词进行的单次运行输出快照，其中在“Answer concisely.”这一对照条件之上，/caveman 使输出中位数进一步减少 3%，/ultracave 减少 35%；caveman-compress 的测试夹具（五个记忆文件从 6,198 个 token 降至 4,138 个 token）；以及一项浏览器快照基准测试（在 200 行表格上为 121 对 15,704 个 token，而在一个小表单上 caveman 的完整结果比 Playwright 的大 2.34 倍）。作为头条的输入 token 结果（885,793 → 591,673 个 token，33.2%，18 个回答中 18 个正确，其中 HTML 用例差了 9.9%）以及 Auto 结果（解决率 43.7% 对 44.3%，成本为 0.46 倍，是针对 169 个任务中 85 个的阶段性运行）是作为书面报告提交的：docs/WRAP-BENCHMARK.md 声明第一项无法从这个检出中独立复现，docs/AUTO-BENCHMARK.md 声明原始轨迹不在仓库中。63.6%（Elastic）、1.4 至 2.4 倍成本削减（Adobe Research）以及 p = 0.82（JetBrains）这些数字是第三方结果，而 docs/HONEST-NUMBERS.md 将相对默认冗长回复的输出减少列为“未发布”，并声明没有发布任何质量主张，因为未提交经过审查的保真度快照。
证据：README.md:116、README.md:247、README.md:246
academic-research-skills 提交了带有预注册、运行记录和原始输出的留出测量套件：在植入缺陷的稿件上，评审小组在两个有缺陷的测试样本上都达到了召回率 1.00，且 0 个干净对照误报，同时严重程度一致性从 0.672 降至 0.607（在 #581 批次之后从 0.663 降至 0.536），一项预注册审计将评审小组的错误主张率定在 12/805（1.5%）到 104/805（12.9%）之间。一个防护提示词将评判出的主张强度漂移从 7/16 降至 1/16，但并未消除它；Wording-Pattern Advisory 的留出漏检率从 0.375/0.344 降至 0.094，且 0/16 误触发（评判协议，无运行脚本）；gpt-5.6-sol 引文验证器的对比测试在 10 条不存在的参考文献上记录到召回率 0.90 对 0.80（p95 延迟 25.0 秒对 49.6 秒），依据是已提交的回执和一个离线评分器。较小的检查以会话次数形式报告，其中包括一项路由修复通过了 6 次会话中的 3 次，未达到其预注册的接受规则；docs/PERFORMANCE.md 中按模式划分的 token 和成本表是在 Opus 4.x 上测得的估算值，若干发布说明将提示词层面的改动标记为未测量。
证据：evals/heldout/reviewer_seeded_defects/README.md:287-291、evals/heldout/reviewer_seeded_defects/README.md:295-296、evals/heldout/panel_claim_factuality/PREREGISTRATION.md:10-14
read-gate 评估（scripts/eval-read-gate.ts，npm run eval:read-gate）有一个可运行的测试框架和已提交的逐用例表格：开启 gate 时，49 KB 文件上每次运行的平均成本在 Sonnet 上为 $0.077 对 $0.124（-38%），在 Opus 上为 $0.171 对 $0.243（-30%），而在 19 KB 文件上分别为 -1% 和 0%，此前版本的 gate 曾让 Opus 成本高出 20%。work-view SQLite 基准测试（scripts/benchmark-work-view.ts）的合成夹具和约 3 GB 真实数据库延迟总结在 docs/development/viewer-sync-recovery.md 中；真实数据库不在仓库中，两个基准测试的原始报告都写入被 git 忽略的 reports/ 目录，且 read-gate 评估需要付费模型调用。Smart Explore 对比（发现阶段 token 少 17.8x，定向读取少 19.4x）是一份书面 A/B 报告，仓库中没有脚本，README 和 CHANGELOG 中的数字（约 10x、90%、200x）没有数据支撑。
证据：tests/evals/read-gate/README.md:87、tests/evals/read-gate/README.md:41、docs/development/viewer-sync-recovery.md:126
graphify 的 BENCHMARKS.md 报告了针对具名基线的结果，并给出成本和评判一致性数字（一致性 90.6%，Cohen's kappa 0.81）：LOCOMO recall@10 为 0.497，对比 BM25 的 0.362 和 mem0 的 0.048；LongMemEval-S 为 76%，与 dense RAG 持平；ERPNext 关键事实覆盖率为 82.0%，对比 grep-and-read 基线的 70.8%（n=6）；在 LOCOMO QA 准确率上，supermemory 得分更高（49.7% 对 45.3%），但摄取成本约为 11x（$15.67 对 $1.40）。这些结果指向的 harness（memory/runner.py、crosstool/run.py）不在仓库中，也没有提交每次运行的输出或支出账本。71.5x 的 token 减少数字由仓库内代码（graphify benchmark）和已提交的 graph.json 支撑，其中语料 token 是根据词数估算而非实测。Graphify Cloud 声称将 agent token 支出削减 80%，但没有数据支撑。
证据：worked/karpathy-repos/review.md:11-28、BENCHMARKS.md:19、BENCHMARKS.md:20
gsd-core 没有发布关于任务成功率、输出质量或端到端 agent 成本的结果。其测得的数字是来自两个离线 token 计数脚本的静态提示大小缩减，并带有已提交的 JSON 基线：启用可选的 workflow.compact_content 模式（默认关闭）后，六个 spine/detail workflow 拆分为 token 少 15.5%（113,676 到 96,055），32 个 compact 变体文件少 21.91%（122,467 到 95,637），使用 gpt-tokenizer 作为 Claude 分词器的替代来计数，且没有检查输出质量是否保持；两者都可以通过 npm run benchmark:compact-content 和 npm run benchmark:compact-content-variants 确定性重跑。来自提示精简的“约 40%”静态开销缩减和“约 75%”更小的命令文件都是没有测量支撑的说法。
证据：tests/fixtures/compact-content-benchmark-baseline.json:3、tests/fixtures/compact-content-variant-benchmark-baseline.json:3、docs/features/context-window-aware-prompt-thinning.md:7
文章标题：GitHub 上星标最多的 AI 工具中，有多少是由编码智能体编写的？
正文： Headroom 主要的 token 节省表（四个预设场景下输入 token 减少 21–57%，总计 178,024 → 104,261 token）可离线复现：benchmarks/index_proof_table.py 及其已提交的输出 benchmarks/results/index_proof_table.txt 给出相同的数字。延迟、准确率（GSM8K 0.870 → 0.870；TruthfulQA 0.530 → 0.560，README 称其无可检测差异）、HTML 提取（F1 0.919）、工具搜索和 Vertex AI（提示 token 减少 76.7%）的结果有 harness 代码，结果记录在 markdown 中；这些结果没有提交原始运行文件，且其中若干项需要付费 API 调用。部分 README 数字与文档不一致：“0.21 ms p50”与文档表格中的 p95 一致（p50 为 0.20 ms），而来自 benchmarks/bench_latency.py 的文档表格显示，重复的 500 字符串 JSON 数组为 4.9K → 228 token，但结构化日志为 53% 和 54%，与 README 的“重复 JSON 数组和日志行上 90%+”不符。40–90% 的图像压缩数字没有给出基准测试。
证据：README.md:38、README.md:38-40、README.md:202-203
context-mode 附带一个离线基准测试套件（bench/run.mjs，66 个场景）以及一份已提交的结果文件，README 的 99.4% 中位字节节省可由此重新计算（36 行原始输出达到或超过 10 KB）；这些是 fixture 上的字节数，token 按字节 / 4 估算，并非模型运行。在 Claude Code 中使用 claude-sonnet-5-5 进行的实时 A/B 运行（脚本和已提交的聚合结果；重新运行需要 claude CLI 和付费模型调用）发现，v2 将大任务上的中位 tool_result 字节数削减了 84%（734.5 对 4,694.5），12 个大型任务会话在每一组中都全部通过，而在小任务上会话 token 比无插件差 5.7%，在大任务上差 19.6%；后来的一次运行显示 v2 的会话 token 在大任务上比无插件低 3.8%，在小任务上高 5.6%。一项配对的成本研究（包含已提交的运行文件和分析脚本）发现，该开源插件在六个短任务上的成本高于单独使用 Claude Code（v1 高 34.6%，v2 高 2.2%），而托管版 Context Mode Gateway 公布的行则低 24.5%；该仓库自身对 README 的 Try It 部分中 13 个数字的核查（commit a92cf6a7，在 v1 上测量）发现 2 个成立、11 个不一致。
证据：README.md:29、README.md:415、bench/RESULTS.md:11
book-to-skill 的核心卖点——回答问题时所使用的 token 比把整本书放入上下文少 24×–51×——来自在三个真实书籍上运行的 tools/discovery_tax.py，这些书籍的文本未提交（上下文转储 token 分别为 119,264 / 175,253 / 256,287，而 book-to-skill 约为 5,000，即约 4K 核心加上约 1K 章节，除非传入生成的 skill，否则该工具将其视为设计上限），而 2.4×–15.6× 的发现循环数字是一个模型，正如该工具的 docstring 所述。提取计数、Docling 与 pdftotext 对比（164s 对 0.1s；48 对 0 个表格）、每本书约 1 美元的生成成本以及一张单章前后对比表以结果形式发布，但没有提交 harness，且 docs/performance.md 列出 Moby-Dick 的 133 个自动检测章节，而 docs/how-it-works.md 一个也没有列出。用于路由和答案准确率的 tools/evals harness 尚无实时结果，docs/research/progressive-disclosure-evals.md 总结了一项关于基于 book-to-skill 的配方（recipe）的外部研究，其中单本书上的强导航器降低了预构建包带来的准确率收益。
证据：README.md:107、docs/performance.md:42-55、docs/performance.md:14-25
Ponytail 提交了一个 agentic harness（benchmarks/agentic/run.py，包含 judge、completeness 和 compare 脚本）以及带有各任务中位数、95% bootstrap 区间和符号检验的结果：在 39 项任务上，每项任务每个实验组运行 5 次（共 585 次会话），Ponytail 5 报告相对于无技能，代码行数 -53%、输出 token 数 -45%、成本 -26%、时间 -41%，并对 98% 的高风险逻辑进行了测试（无技能：68%）。同一批结果也报告了它未能领先的地方：隐藏检查持平（87/90 对无技能的 86/90，且三个实验组均通过了 30/30 次安全运行），在存在测试的情况下，无技能测试捕获了更多注入的 bug（77% 对 69%），盲评 judge 更偏向无技能回复（82 : 106，p=0.09，不显著）。更早的一次单次基准测试发现，在 gpt-5.4-mini 和 gpt-5.5 上，ponytail 比无技能分别贵 26.2% 和 38.7%。原始运行工作区未提交，因此检查结果需要付费实时重跑，而 /ponytail-review 的检测率（100% 对无技能的 87%）出现在没有数据的图片说明中。
证据：README.md:42, benchmarks/README.md:13, benchmarks/results/2026-10-07-agentic.md:66
Archify 发布了来自其 ordinary-model-floor 基准的三份已提交的 15 次运行矩阵（3 个模型 x 5 项任务），并附有每次运行的 receipt 以及可运行的 verifier 和 report harness。第一次运行记录为 10/15 首次通过可用；在当前 verifier 下，原始、修复后和 quality-first 矩阵各自得分 8/15，且 README 指出这些修复并未证明整体提升（lifecycle 从 0/3 提升到 1/3，architecture 从 2/3 提升到 3/3，而 workflow 和 data-flow 出现回退）。候选生成使用外部 runner 和该仓库未附带的模型提供商，因此这些数字可以从已提交的候选中重新验证，但无法从此 checkout 端到端重新生成。第二个 harness，repair-rounds，没有已发布结果。
证据：benchmarks/ordinary-model-floor/README.md:96-100, benchmarks/ordinary-model-floor/README.md:102-110, benchmarks/ordinary-model-floor/README.md:111
ECC 发布了 GateGuard 评估，附有可运行的 harness 和已提交的聚合结果。其预注册的验证性运行（run-intent.js，96 次试验）报告 gate 的收益未得到确认（使用 gate 通过 25/48，不使用 gate 通过 18/48，p = 0.210），每次试验的轮次约多 37%、成本约多 40%；更早的一次探索性运行给出 15/24 对 8/24（p = 0.065）。replay 和 latency 脚本报告，在 184 步语料上，拒绝从 157 降到 132，must-deny 绕过从 8 降到 0，fresh-process hook 的 p50 为 23.68 ms，而 upstream/main 上为 11.58 ms；行级结果和 hidden-intent 运行的转录记录未提交。在 GateGuard 之外，README 中关于默认使用 Sonnet 可“降低成本约 60%”的说法没有数据支撑，而 mgrep 的“token 数约减少 2 倍”数字被归因于 Mixedbread。
证据：docs/gateguard/question-effectiveness.md:451, docs/gateguard/question-effectiveness.md:370, docs/gategu
hermes-agent 在 evals/ 下按 PR 提交 A/B 评测，配有可运行的 harness 和 scorecard，在报告实测准确率的同时给出 token 节省情况：lean+recovery 压缩的召回率为 68.3%，而当前策略为 45.8%，同时 token 用量少 3.3 倍（49K 对 162K；96.7% 未压缩），core-tool deferral 带来 −7% 到 −23% 的 token 变化，总准确率 0.916 对 0.923，browser_exec 则减少 −60% 到 −66% 的 token，两组各 18/18 次运行均成功。scorecard 也记录了不利于该改动本身的结果，例如 gpt-5.6-terra 的准确率从 0.938 掉到 0.879，以及在 core-tool deferral 下 clarify 工具在 18 次运行中只被用了 7 次，而不是 18/18。这些运行需要实时的付费模型，压缩过程的 transcript 没有提交，deferral、read-tool 和 browser 套件的逐次运行行被 gitignore，因此那些结果只是汇总表；session_search 评测提交了全部 108 条逐次运行记录（52/54 对 49/54 通过）。toolperf 的数字（qwen3-coder-30b 上 −21% 轮次、−29% 工具调用）写在 harness 旁边的 README 里，没有提交结果。
Evidence: evals/compaction/results/SCORECARD-2026-08-15.md:18-21, evals/compaction/results/SCORECARD-2026-08-15.md:67, evals/core_tool_deferral/results/SUMMARY.md:1-20
OmniRoute 主打的「15–95% tokens（平均约 89%）」是在第三方 README 数字上做的算术：文档把 RTK 的 60-90% 与 Caveman 约 46% 的输入节省按 1 − (1 − RTK) × (1 − Caveman_input) 合并，得出 78.4–94.6%，平均 89.2%。各模式的数字（Lite 约 15%、Standard 约 30%、Aggressive 约 50%、Ultra 约 75%）以及 69 → 19 token（72%）的例子都是直接给出，没有数据支撑。有 harness 支撑的数字要窄得多：一个已提交的 CI 下限，即 5 个用例语料上每任务的压缩后 token 数（npm run check:compression-budget），它不记录未压缩的计数，并对 lite、aggressive、rtk、session-dedup 和 headroom 列出相同的数值（129 / 127 / 160）；一个单元测试，跑的是所引用 95.93% 背后的那一条输入（300 行完全相同的错误行），并断言节省超过 90%；以及一个路由事件微基准（npm run bench:routing-events，每请求约 0.12 µs 的事件分发开销）。其他 harness（bench:compression、eval:compression、perf:lts-baseline）没有提交输出。
Evidence: docs/compression/COMPRESSION_GUIDE.md:161, scripts/check/compression-budget-baseline.json:2-8, docs/architecture/ADAPTIVE_ROUTING.md:128
该仓库附带一个真实、可重新运行的对比 notebook（63 个由厂商编写的 NVIDIA 10-K 问题、LLM 裁判、已保存的输出），显示 PageIndex 的准确率为 100.0%，而各向量 RAG 配置为 42.9-92.1%，不过向量答案和裁判评分没有提交，且该运行依赖付费 API。README 主打的数字（FinanceBench 98.7%、97% 的 token 削减、financial-QA 基准）指向外部厂商仓库/博客，而索引成本/时间和原生 PDF 成本比则只是图表，没有提交 harness。
Evidence: cookbook/pageindex-vs-vector-10k/pageindex-vs-vector-10k.ipynb:603, cookbook/pageindex-vs-vector-10k/pageindex-vs-embeddings-10k.ipynb:574, cookbook/pageindex-vs-vector-10k/pageindex-vs-vector-10k.ipynb:640
gentle-ai 提供了一个确定性的、离线的 Go harness（bench/，自带 go.mod，在 CI 的 .github/workflows/ci.yml:100-163 中运行），用于衡量其评审生命周期中的摩擦，例如人工提示、命令到完成以及阻塞，且不调用模型、不计时，并提交一次完整运行（bench/results.json：统计 64 个 journey，0 个失败）；仓库根目录下的第二个 results.json 记录 0 个已计数、1 个失败的 journey。README 的 14 个 journey 总计及其与 v2.1.2 的对比（在 5 个可比较的 journey 上，blocks 从 10 到 3）来自 results-after.json 和 results-before.json，这两个文件被 gitignore，且不在仓库中。README 的 agent 性能表报告的是单次（n=1）Gentle Shell 运行，而本仓库中没有数据或 harness；其中 data-migration 运行花费 $0.555，而此前为 $0.403，并在第一轮被接受。spec 行以及与 Codex CLI 的对比链接到 gentle-shell 的 PR 和一个 issue（#1718、#1723、#1794、#1713）；该对比报告称大型任务耗时约三倍（17.5–17.9 min vs 6.1 min）。
Evidence: bench/results.json:12558, bench/README.md:409-431, bench/README.md:439-446
全部 52 个仓库
| 仓库 | 星标数 | 创建时间 | AI 证据 | AI 签名 % | AI 签名 %（最近 180 天） | 修复 % | Churn | 存活 % | 已发布结果 |
|---|---|---|---|---|---|---|---|---|---|
| superpowers | 314,290 | 2025-10-09 | AI 签名 | 13.3 | 6.1 | 24.5 | 3.86 | 41.2 | 有结果，无 harness |
| ECC | 299,342 | 2026-01-18 | AI 签名 | 8.1 | 7.9 | 43.7 | 1.57 | 77.8 | Harness + 已提交结果 |
| deepseek-harness | 276,014 | 2026-08-13 | Agent 配置，<5% 签名 | 0.0 | 0.0 | 38.4 | 2.43 | 57.9 | Harness + 已提交结果 |
| hermes-agent | 261,582 | 2025-07-22 | Agent 配置，<5% 签名 | 2.9 | 2.8 | 53.5 | 2.73 | 53.8 | Harness + 已提交结果 |
| firecrawl | 199,609 | 2024-04-15 | AI 签名 | 13.1 | 42.1 | 32.3 | 2.16 | 63.2 | 有结果，无 harness |
| AutoGPT | 187,937 | 2023-03-16 | AI 签名 | 20.4 | 73.6 | 36.7 | 2.55 | 56.2 | Harness + 已提交结果 |
| ponytail | 186,540 | 2026-06-12 | AI 签名 | 24.1 | 24.1 | 41.8 | 1.66 | 75.2 | Harness + 已提交结果 |
| ollama | 186,319 | 2023-06-26 | Agent 配置，<5% 签名 | 0.1 | 0.2 | 15.1 | 4.45 | 36.7 | 有 harness，无已提交结果 |
| transformers | 168,646 | 2018-10-29 | AI 签名 | 1.0 | 10.0 | 31.7 | 3.38 | 45.7 | Harness + 已提交结果 |
| dify | 160,649 | 2023-04-12 | AI 签名 | 5.3 | 6.7 | 42.6 | 3.55 | 43.9 | 有 harness，无已提交结果 |
| open-webui | 158,080 | 2023-10-06 | 两种信号均无（未知） | 1.3 | 2.6 | 22.2 | 3.37 | 45.8 | 声明无数据 |
| langchain | 149,190 | 2022-10-17 | Agent 配置，<5% 签名 | 0.3 | 2.1 | 21.7 | 5.63 | 30.1 | 有 harness，无已提交结果 |
| graphify | 144,135 | 2026-04-03 | AI 签名 | 50.4 | 52.7 | 56.6 | 1.4 | 83.2 | Harness + 已提交结果 |
| browser-use | 120,289 | 2024-10-31 | AI 签名 | 4.9 | 5.6 | 22.2 | 5.56 | 30.5 | 有结果，无 harness |
| orca | 118,822 | 2026-03-17 | AI 签名 | 14.7 | 13.2 | 46.6 | 3.63 | 43.2 | Harness + 已提交结果 |
| caveman | 118,218 | 2026-04-04 | AI 签名 | 78.7 | 82.3 | 55.5 | 1.8 | 71.5 | Harness + 已提交结果 |
| claude-mem | 114,633 | 2025-08-31 | AI 签名 | 61.7 | 66.9 | 46.6 | 3.38 | 47.0 | Harness + 已提交结果 |
| archify | 94,563 | 2026-04-15 | AI 签名 | 14.0 | 14.4 | 35.8 | 1.43 | 81.5 | Harness + 已提交结果 |
| ragflow | 93,749 | 2023-12-12 | Agent 配置，<5% 签名 | 2.4 | 4.3 | 49.3 | 3.03 | 49.6 | 有结果，无 harness |
| rtk | 85,862 | 2026-01-22 | AI 签名 | 34.8 | 35.2 | 60.1 | 1.79 | 71.8 | 有 harness，无已提交结果 |
| OmniRoute | 85,531 | 2026-02-13 | Agent 配置，<5% 签名 | 3.0 | 1.7 | 61.2 | 2.3 | 51.9 | Harness + 已提交结果 |
| lobehub | 84,366 | 2023-05-21 | AI 签名 | 22.0 | 40.7 | 34.9 | 1.87 | 69.7 | 有 harness，无已提交结果 |
| headroom | 79,105 | 2026-01-07 | AI 签名 | 31.0 | 32.3 | 63.2 | 1.58 | 77.4 | Harness + 已提交结果 |
| OpenSpec | 74,248 | 2025-08-05 | AI 签名 | 30.6 | 63.9 | 42.9 | 1.66 | 75.1 | 声明无数据 |
| anything-llm | 68,053 | 2023-06-04 | 两种信号均无（未知） | 0.4 | 0.5 | 25.3 | 2.0 | 66.7 | 声明无数据 |
| humanizer | 66,094 | 2026-01-18 | AI 签名 | 32.4 | 35.8 | 25.4 | 6.07 | 28.3 | 仅第三方 |
| get-shit-done | 64,157 | 2025-12-14 | AI 签名 | 50.0 | 50.0 | 43.3 | 1.82 | 70.5 | 有结果，无 harness |
| academic-research-skills | 55,793 | 2026-02-26 | AI 签名 | 75.8 | 70.4 | 27.9 | 1.16 | 92.7 | Harness + 已提交结果 |
| BMAD-METHOD | 55,118 | 2025-04-13 | AI 签名 | 14.7 | 8.5 | 31.7 | 35.84 | 5.4 | 有 harness，无已提交结果 |
| herdr | 49,219 | 2026-03-27 | Agent 配置，<5% 签名 | 0.3 | 0.3 | 55.1 | 1.84 | 70.4 | 有 harness，无已提交结果 |
修复 %、churn 比率和存活率均以 HEAD 为基准测量。点击列可排序。同一张表也提供 CSV 版本；带提交时间线的逐仓库浏览器位于学术版中。
方法与局限
如何测量
文章标题：GitHub 上最受关注的 AI 工具中，有多少是由编码代理编写的？
正文：
- 这 52 个仓库。截至 2026-11-08，7 个 GitHub 主题（agent-harness、ai-agents、coding-agents、context-engineering、llm、prompt-engineering、spec-driven-development）各自按星标数排名前 10 的仓库，减去阅读材料和合集（书籍、课程、指南、提示词合集、awesome-lists），再加上这项研究起始的 4 个仓库（OmniRoute、context-mode、rtk、superpowers）。其中 39 个创建于 2025 年或之后，11 个创建于 2024 年之前（AutoGPT、anything-llm、dify、go-zero、langchain、lobehub、ollama、open-webui、ragflow、transformers、yao）。星标数中位数为 65,126（中间一半：15,632–126,250），数据抓取于 2026-11-08。
- 基线。denoland/deno、excalidraw/excalidraw、fastapi/fastapi、junegunn/fzf、gin-gonic/gin、gradio-app/gradio、hoppscotch/hoppscotch、jesseduffield/lazygit、n8n-io/n8n、microsoft/playwright、BurntSushi/ripgrep、huggingface/transformers。两组都是按如今的名气选出的。在 Copilot 之前拍摄的快照（go-zero、transformers、yao 在第 180 天）被排除在存续时长比较之外，因此没有任何一个仓库同时计入两边。
- 提交。默认分支的完整历史。38,229 个合并提交和 10,346 个维护机器人提交（dependabot、发布机器人）被排除在所有百分比之外。get-shit-done 和 gsd-core 共享 2,554 个提交历史（截至 2026-05-22），两边都计入。
- AI 信号。已签名：AI 共同作者尾注、AI 代理作为作者或提交者，或工具的“Generated with”页脚。已配置：仓库提交了代理指令（CLAUDE.md、AGENTS.md、.cursor/、.github/copilot-instructions.md……）或在 CI 中运行编码代理。
- 修复百分比是提交主题中包含 fix、bug、hotfix 或 regression 的提交占比。变更比率是完整历史中新增行加删除行，除以 HEAD 处的行数。存活百分比是 HEAD 处的行数除以曾经新增的行数（源代码和 Markdown；排除 vendored、生成、翻译、lock 和 changelog 文件）。
- 已发表结果是各仓库对自身性能的声明，按文件和行定位，并按证据类型分类。
这不说明什么
- 无因果关系。知名项目是按如今的星标数选出的，因此它们是幸存者。以同样方式使用 AI 但失败的项目不在样本中。
- 是 AI 工具项目，不是一般意义上的知名项目。为编码代理构建工具的人最有可能使用它们。
- 变化列表的快照。主题排名每天变化；这是 2026-11-08 各主题的前 10。
- AI 占比是下限。签名衡量的是归属，不是作者身份，而且 Claude Code 因为默认签名而过度代表。
- 代理配置可能是产品，而不是过程。在 AI 工具仓库中，根目录的 CLAUDE.md、.claude/ 或 .cursor/ 可能是产品发布的模板，而不是项目自身开发的指令。
- 已签名不等于未审查。签名不能说明一个人审查提交时有多仔细。
- AI 使用与新近度相关。几乎所有重度 AI 使用都出现在 2025 年或之后启动的项目中，因此与更早项目的差异不能归因于 AI，而不是归因于它们启动的时间。
- 修复百分比基于关键词，对提交消息约定敏感；它不是缺陷率。变更比率混合了所有被提交的内容，包括逃过排除规则的 vendored 或生成文件。
- 已发表结果是自我报告的，经过定位和分类，但未复现。
- 小基线。12 个 Copilot 之前的项目，按名气、语言和克隆大小选出。