Agent 时代的 开源 协作

蚂蚁开源与 InclusionAI 联合出品 · 2026 年 9 月

就像工业化进程里我们无法拒绝机器一样，在当今这个时代，我们很难拒绝 Agent 生产代码，然而，我们也在反复重复“没理由机器生产的代码让人一行一行来审查”，因为正如这份报告中所呈现的，代码生产的速度已经超出碳基维护者的消化速度了，而 Agent 和相应的基础设施的演进正在和这个趋势相互作用。我虽然还没有充分的理由，但我相信，Agent 生产力的大繁荣，最终将让代码的协作，上升到观点的共识，让开发者们更专注于创造更好的体验。

——蚂蚁开源技术委员会副主席 王旭

这份报告发现了什么

Runtime 正在追赶已经形成的应用需求。

Application 占 Agent Infra 7 月 OpenRank 的 55%；相较 5 月 tracking pool 新纳入的 23 个 Agent Infra 项目中，13 个属于 Runtime。新增项目正在补齐上下文、互操作、工具控制和执行环境。

PR 流入翻倍，完成速度没有跟上。

同一组 55 个仓库中，PR 流入从 2025 年的 129,563 条增加到 2026 年的 265,447 条。90 天后仍保持 open 的比例翻倍至 11.3%，仓库中位合入率则降至 68.4%。

Agent 扩大了评审与修改能力，却没有接过最终决定。

5,000 条抽样 Issue / PR 中，只有 87 条由具名 Agent 或 App 发起；1,342 条 PR 收到了 Agent review。最终可见状态变化中，88.5% 仍由 GitHub User 账号完成。

基础设施必须处理什么

Agent 把代码带进运行时

Agent 可能在任务开始后编写代码、打开浏览器、调用内部服务，并把状态留在多个短生命周期环境之间。基础设施必须隔离此前从未见过的工作，限制每项任务的权限，并在进程消失后保留足以解释变化的证据。

软件开发中的协作发生了什么变化

Agent 正在进入仓库内部

Agent 会读取贡献规则、修改文件、运行测试并回应评审，因此已经进入普通的 Issue / PR 循环。真正的问题不是它能否写出补丁，而是它能否缩短一项有用改动进入项目的路径，还是主要增加了维护者必须判断的工作量。

全景图范围

这四个数字定义了下一部分的项目范围：保留的 5 月基线、当前项目池、两张全景图的入选项目，以及基线之后新纳入的项目。

2272026 年 5 月基线中的仓库
279当前 canonical project pool 中的仓库
145Agent Infra 与 Model Infra 的入选项目
335 月基线之外的新入选项目
01全景图与开放基础设施

应用承载了最多活跃度，Runtime 正在快速补齐。

当前全景图包括 84 个 Agent Infra 项目和 59 个 Model Infra 项目。Application 占 Agent Infra 7 月 OpenRank 的 55%，而 Runtime 占 5 月 tracking pool 之外 23 个 Agent Infra 项目中的 13 个。Model Infra 更成熟、以 Python 为主，其中 Serving 占 7 月 OpenRank 的 44%。

01A当前全景图

切换视图 · 项目按 2026 年 7 月 OpenRank 排序

56%创建于 2025 年或之后
35%下列五个项目占 7 月 OpenRank 的比例
OpenClaw303.2Hermes Agent277.9Deer Flow211.2OpenViking187.9Lark CLI186.9
01B全景图中的信号

Application 仍然最活跃，新增项目更多出现在 Runtime。

从 5 月以来，持续的生态复核把 tracking pool 从 227 个仓库扩展到 279 个。Application 仍然吸引最多可见活跃度；Runtime 的入选项目数已经接近 Application，并占 5 月池之外 25 个 Agent Infra 项目中的 13 个。项目先通过活跃度发现和编辑复核进入项目池，再经过第二轮判断决定是否进入发布版全景图。

活跃度仍然集中在应用层

项目占比OpenRank 占比
应用33 个项目 · 9 个不在 5 月项目池
38% / 47%
开发框架21 个项目 · 3 个不在 5 月项目池
24% / 26%
运行时32 个项目 · 13 个不在 5 月项目池
37% / 27%

Serving 仍然承载着系统侧的主要活跃度

项目占比OpenRank 占比
模型服务15 个项目 · 3 个不在 5 月项目池
25% / 40%
预训练18 个项目 · 1 个不在 5 月项目池
31% / 31%
数据13 个项目 · 1 个不在 5 月项目池
22% / 16%
计算4 个项目 · 0 个不在 5 月项目池
7% / 6%
后训练9 个项目 · 3 个不在 5 月项目池
15% / 7%
4 月→7 月

从 4 月到 7 月，OpenRank 增长最大的六个项目都在处理工具使用、上下文或推理效率。OpenRank 反映仓库活跃度，这个变化指出了当前吸引更多贡献者和讨论的开源技术位置。

01Lark CLITools, web & computer use+48.7
02OpenVikingMemory, knowledge & context+45.5
03Deer FlowMulti-agent orchestration+20.4
04Kimi CodeAgentic coding+15.1
05OrcaMulti-agent orchestration+11.9
06DeepSpeedPre-Train · Framework & parallel+4.9
创建于 2025 年或之后56%

Agent Infra · 48 / 86 个项目

创建于 2025 年或之后17%

Model Infra · 10 / 59 个项目

Agent 接口和 Runtime 正在这一轮浪潮中形成；模型服务、训练框架、调度器和数据系统则带着多年工程经验进入 Agent stack。新工作负载要求这些成熟系统处理短生命周期代码、委托式工具访问，以及可能比单个进程存活更久的状态。

Agent 产品更偏 TypeScript，模型基础设施仍以 Python 为主。

GitHub 将 84 个 Agent Infra 仓库中的 33 个标记为 TypeScript，将 59 个 Model Infra 仓库中的 33 个标记为 Python。这与两张全景图的形态一致：Agent 一侧有更多面向用户的 Web 产品，底层则有更多模型服务和系统工程。Other 包含 Rust、Java、Shell 等占比较小的语言。

Agent Infra86 个仓库
Model Infra59 个仓库
TypeScriptPythonGoC++Other

Runtime 项目正在沿着一项 Agent 任务经过的路径聚集。

一项任务会检索上下文、跨过接口、调用工具、在隔离环境中执行，并留下可供检查的证据。沿着这条路径，应用问题逐步变成基础设施责任：上下文需要生命周期，接口需要策略，工具调用需要有限权限，生成代码需要隔离，外部影响需要留下可追溯记录。

01C开放基础设施

Agent 执行具有波动性、状态性和外部影响。

一项任务可以在开始后生成代码，扇出为多次模型和工具调用，暂停、重试并留下外部变化。平台 token 总量会把许多运行合并在一起，隐藏其中的峰值、等待和重试。因此，在单个进程不断出现和消失时，基础设施仍要把隔离、权限、预算、状态和证据绑定在同一项任务上。

常见的基础设施假设

部署服务从已知制品启动

Agent 改变了什么

Agent 可以在任务中生成并运行代码

环境可能只存活几分钟，却仍然需要隔离、网络策略、稳定的任务身份、可控的预热延迟和可靠清理。

当前全景图中的信号

全景图包含 4 个开发沙箱项目。Kubernetes Agent Sandbox 增加了声明式 claim、模板与 warm pool。

成熟开放基础设施能够提供什么

Kubernetes 管理沙箱生命周期，Kata Containers 为不受信任的代码提供 VM 级边界。

查看一手来源
仍未解决的问题

强隔离仍然与启动速度存在取舍；warm pool 还需要安全重置、租户隔离、容量限制和可移植模板。

02开源协作

PR 流入翻倍，评审与合入没有同步跟上。

同一组 55 个仓库收到的 PR 比 2025 年增加了 105%。具名 Agent 出现在更多线程中，也有更多 PR 进入公开 review；但第一周维护者响应和 30 天内完成 PR 的比例都下降了。本章沿着这条不断扩大的差距，观察工作量怎样进入仓库、Agent 在哪里参与，以及谁仍然承担最后的公开动作。

同一组 Top 100，两层证据。

所有结果都从同一组 100 个仓库出发。仓库全量记录回答多少工作进入、最后发生了什么；每仓库 50 条公开线程用于还原响应与评审的顺序。历史图表固定使用同一组 55 个仓库，2026 年线程直接复用主样本。

仓库全量记录Top 100

包括固定窗口内全部公开 Issue / PR，以及仓库画像、贡献政策、Agent 文件和 Release。工作量、积压和结果数据都来自这一层。

历史对比固定同一组 55 个仓库

从 Top 100 中选出在 2024、2025 和 2026 年都有可比活动的仓库，三年始终使用同一份名单。

公开线程时间线5,000 条（2026 年）

每个仓库抽取 50 条 Issue / PR，并串联 138,150 条公开事件，用于按顺序分析响应、评审和修改。

历史对比5,500 条同口径线程

从同一组 55 个仓库中，每仓库、每年抽取 50 条线程，对比响应、评审和完成情况。

Top 100 是怎样的一组仓库？

我们冻结了 277 个 tracking pool 中 7 月 OpenRank 最高的 100 个仓库，再逐一人工复核它们的技术角色以及与 LLM 的关系。这是一组由活跃度筛选出的头部项目，不是对全部开源项目的普查；规模更小、活跃度更低的仓库并不在其中。

pytorch/pytorch模型基础设施 · 传统软件7 月 OpenRank 333.3 · 102,035 Stars ↗
模型基础设施
36
Agent 应用
28
Agent 框架
21
Agent 运行时基础设施
15
项目属性 · 人工复核
LLM 原生
68
项目的核心用途依赖语言模型或 Agent；移除 LLM 后，核心产品无法按原本方式工作。LangChain 与 vLLM 属于这一类。
传统软件
18
项目在不依赖语言模型时也有完整核心用途。它可能服务 AI workload，但 AI 并不定义项目本身。PyTorch 与 ONNX Runtime 属于这一类。
混合型
14
项目原本有更广泛的软件用途，AI 或 Agent 如今已成为重要产品表面，但非 AI 产品仍然成立。n8n、Warp 与 MLflow 属于这一类。
仓库创建时间
创建于 2022 年 12 月或之后
72
创建时间更早
28
GitHub 主要语言
Python
44
TypeScript
26
Go
11
其他
19
02A仓库需要吸收更多代码

PR 正在比 Issue 增长得更快。

2026 年 1 月 1 日至 8 月 31 日，Top 100 共开启约 606.7K 条 PR 和 349.8K 条 Issue，平均每条 Issue 对应 1.73 条 PR。总量同时包含真人工作与自动化，不能据此推断 AI 生成代码的比例。

PR / Issue 比例从 1.35 升至 2.11。

1 月至 8 月均为完整自然月。柱高使用同一比例尺；悬停或聚焦月份可查看准确数量。

1 月26,320 Issues · 35,540 PRs · 1.35×
2 月35,543 Issues · 50,329 PRs · 1.42×
3 月49,896 Issues · 74,831 PRs · 1.50×
4 月50,167 Issues · 71,173 PRs · 1.42×
5 月44,040 Issues · 78,753 PRs · 1.79×
6 月41,604 Issues · 83,082 PRs · 2.00×
7 月49,274 Issues · 101,482 PRs · 2.06×
8 月52,982 Issues · 111,551 PRs · 2.11×
IssuesPR

PR 流入翻倍，评审队列没有跟上。

这组对比每年都使用同一组 55 个仓库，统计 1–8 月所有公开 Issue / PR 的新开与关闭数量，不是线程抽样。

新开 PR · 同一组 55 个仓库
进入仓库的代码在一年内翻倍。
+105%
202497.8K
2025129.6K
2026265.4K
55 个仓库中有 54 个的 PR 队列继续增长。

2026 年 1–8 月，每一类技术项目的新开 PR 都多于关闭数量。

Agent 应用+54.6K

Agent 框架+17.1K

Agent 运行时基础设施+5.7K

模型基础设施+35.7K

Agent 触达了更多 PR，但 30 天内完成的比例下降了。

上面的仓库全量数据说明队列怎样增长。为了观察队列内部发生了什么，我们比较同一组 55 个仓库在 2025 和 2026 年 1–8 月的线程：每个仓库、每年各 50 条，共 5,500 条。

观察项20252026变化
出现具名 Agent 或 App 的线程19.9%46.1%+26.3 pp
7 天内收到仓库维护者响应37.1%31.1%-6.0 pp
PR 在 30 天内处理完成87.8%80.3%-7.5 pp
PR 出现公开 review68.8%73.9%+5.1 pp

具名 Agent 出现在线程中的比例翻了一倍以上，进入公开 review 的 PR 也更多；与此同时，第一周维护者响应从 37.1% 降到 31.1%，30 天 PR 完成率从 87.8% 降到 80.3%。Agent 帮助更多变更走到 review，仓库仍需要投入真人注意力并承担最终决定，才能把这些变更处理完。

更多账号进入 Push 路径，集成仍由小范围核心承担。

同一组 55 个仓库中，出现 PushEvent 的账号中位数从 17 个增加到 25 个；但完成一半 push 所需的账号中位数仍只有 3 个。更多人进入了公开写入路径，大部分集成活动仍集中在一个很小的核心圈。

2026 年对照仓库中位数
Agentic AI Top 10055 个活跃仓库

25个账号执行过 push

3个账号完成一半 push

Cloud Native98 个活跃仓库

12个账号执行过 push

2个账号完成一半 push

Big Data56 个活跃仓库

7个账号执行过 push

1个账号完成一半 push

一部分仓库几乎每天都在发布 GitHub Release。

2026 年 1 月 1 日至 8 月 31 日共 243 天，Top 100 中有 98 个仓库至少发布过一次非草稿 GitHub Release。Release day 按 UTC 日期去重；高频记录常常反映自动化发布。这里包含 prerelease，不包含只有 tag 或只发布到包仓库的记录。

无2
1 天2
2–913
10–2926
30–8927
90–17924
180+6
  1. ggml-org/llama.cpp241 / 243 天2,041 条记录
  2. QwenLM/qwen-code222 / 243 天492 条记录
  3. openai/codex208 / 243 天681 条记录
  4. router-for-me/CLIProxyAPI203 / 243 天440 条记录
  5. vercel/ai194 / 243 天15,232 条记录
  6. flashinfer-ai/flashinfer185 / 243 天221 条记录
02B贡献入口与 Agent 设置

大多数仓库接受外部 PR，少数仓库要求贡献者先对齐。

Top 100 中有 98 个仓库允许任何人创建 PR；Codex 和 Claude Code 只允许 collaborators 创建。另有 12 个仓库保持 PR 入口开放，但要求贡献者先开 Issue、取得同意或遵守限定范围。Top 100 之外的 DeepSeek Harness 则划出更鲜明的边界：核心代码公开，核心贡献关闭，插件路径开放。

48
明确邀请外部贡献
12
要求先开 Issue 或事先限定范围
38
未发现限制性政策信号
2
仅允许 collaborators 创建 PR
两个限制 PR 创建的仓库

Codex 与 Claude Code 保留了 Pull Requests 页面，但 GitHub 只允许 collaborators 创建 PR。

编码前先对齐

Mastra 要求代码贡献者先开 Issue；Open WebUI 对首次贡献者设置相同门槛，但本地化修改除外。

TOP 100 之外

DeepSeek Harness 以 MIT 协议公开核心代码，但关闭核心 Issues 与 PR，把外部开发引向插件。

贡献政策是怎样分类的

我们先读取 GitHub 的 has_pull_requests 与 pull_request_creation_policy，再检查冻结的 README、CONTRIBUTING、GOVERNANCE 和 PR template。只有既未发现明确邀请、也未发现事先门槛时，仓库才归入“未发现限制性政策信号”。

核心仓库之外也可以成为贡献界面

“你可以把这个仓库视为一个想法、一个官方展示和灵感来源，但不要把它当作我们的强制规范。”

这个项目把官方代码作为参考点，把第三方插件作为生态扩展的位置。这种安排把真正的治理工作留在了接口稳定性、插件发现，以及插件变得不安全或无人维护时如何处理等问题上。

核心代码公开MIT 协议
核心贡献关闭Issues / PR
扩展生态开放Discussions 与插件

Coding-agent 设置已经遍布整个技术栈。

Top 100 中有 92 个仓库在默认分支上发布了 instruction file 或工具目录。各类技术项目的覆盖率都很高，因此更值得追问的已经不是仓库是否在为 Agent 做准备，而是 Agent 辅助的工作进入公开贡献流程后发生了什么。

92/100

个仓库在默认分支上发布了 coding-agent instruction file 或工具目录。这种设置已经遍布各类技术项目。

具有 coding-agent 设置的仓库

Agent frameworks20/21

Agent runtime infra15/15

Agent applications25/28

Model infra32/36

我们找到了哪些 instruction file 与工具目录

Works across Agents80

Claude Code71

Codex23

GitHub Copilot20

Cursor17

Gemini12

02CAgent 在公开流程的哪里进入
线程样本5,000 条 Issue / PR

2026 年 1 月 1 日至 8 月 31 日，我们从 Top 100 的每个仓库抽取 50 条 Issue / PR：1,433 条 Issue 和 3,567 条 PR。图表串联这 5,000 条线程及其 138,150 条公开事件；每条线程只计算一次。

Agent 大多在贡献进入仓库之后才加入。

5,000 条抽样线程中，只有 87 条由具名 Agent 或 App 发起；Agent review 则出现在 3,567 条 PR 中的 1,342 条。到流程另一端，在 88.5% 的已解决线程中，执行最后一次 merge、close 或 reopen 的仍是 GitHub User 账号。

由具名 Agent 或 App 发起1.7%

87 / 5,000 条抽样 Issue / PR

收到 Agent review37.6%

1,342 / 3,567 条抽样 PR

最后由 GitHub User 账号执行公开动作88.5%

3,618 / 4,089 条已解决线程

具名 Agent 在公开记录中做了什么

Review 占据主要部分，其次是分流与讨论。

评审5,363
分流与路由1,448
讨论1,915
什么会被计为具名 Agent 行为

GitHub 明确显示 Agent 或 App 身份

例如 CodeRabbit review、Gemini Code Assist 评论或 OpenHands App 行为。常规 CI、依赖更新和发布机器人单独统计。

本地 Agent 使用通常不可见

使用 Cursor、Claude Code 或 Codex 在本地完成的工作，通常只显示为开发者的普通 GitHub User 账号，除非公开记录提供了额外归因。

最终动作指公开状态变化

它是最后一个可见的 merge、close 或 reopen 事件，说明哪个账号完成了公开流程，不代表此前所有决定都由该账号作出。

Agent 首先评审的 PR，更常出现后续提交。

在收到 review 的 PR 中，Agent-first review 之后有 66.8% 出现了新 commit，User-first review 之后为 41.1%。如果 review 明确要求修改，两组几乎没有差别：Agent 为 76.5%，User 为 77.4%。Agent review 已经进入修改循环，但最能推动下一轮工作的仍是一项明确的修改要求。

Agent-first review 后有 66.8% 出现新提交，User-first review 后为 41.1%。

每条收到 review 的 PR 都按第一次正式 review 背后的账号分类，再继续观察下一次 commit；两组相差 25.7 个百分点。

第一次正式 review 来自具名 Agent 或 App66.8%834 / 1249 条 PR 随后出现新 commit
第一次正式 review 来自 GitHub User 账号41.1%457 / 1111 条 PR 随后出现新 commit

明确要求修改后，约四分之三的 PR 会出现新提交。

当 review 状态明确为 CHANGES_REQUESTED 时，Agent 与 User 两组几乎没有差别。

全部 CHANGES_REQUESTED review76.4%123 / 161 条 PR 随后出现新 commit
具名 Agent 或 App 发出的修改要求76.5%13 / 17 条 PR 随后出现新 commit
GitHub User 账号发出的修改要求77.4%106 / 137 条 PR 随后出现新 commit
70.7%记录到正式 review · 2,521 / 3,567 条 PR
37.6%出现 Agent review 或行内评论 · 1,342 / 3,567 条 PR
54.9%第一次正式 review 后出现新 commit · 1,385 / 2,521 条 PR

第一版 Agent 补丁经常被保留，也可能被重写。

我们跟踪了 10 条由已验证 Coding Agent 修改代码、最终合入的 PR，并从第一份有效 Agent patch 开始追踪每一行文字。9 条 PR 有清晰的行级历史：1,225 行中有 765 行原样保留，123 行首先由 User 账号改动，193 行由后续 Agent commit 改动。这些案例同时包含 Agent 独立迭代、Agent 向人交接，以及原样进入项目的补丁。

62.4%的第一版 Agent patch 行以完全相同的文本保留下来1,225 行中的 765 行 · 9 条可追踪 PR
62.4%
文本原样保留
10%
由真人账号修改
15.8%
由后续 Agent commit 修改
11.8%
无法确认后续作者
Agent 持续迭代至合入

vercel/ai #18818

打开 PR

172第一版 Agent patch 行数

0文本原样保留

0由真人账号修改

172由后续 Agent 修改

0无法确认作者

第一版 172 行补丁被后续 Agent 修改全部替换。

七条公开线程

每个仓库里的交接方式都不一样。

这些案例展示谁发起工作、Agent 在哪里进入、谁继续修改，以及最后由谁结束公开流程。

相同结果背后，可能是完全不同的交接方式。

其中四条案例来自 5,000 条线程样本，三条来自十仓库面板。公开时间线显示，在一条线程被合入、关闭或修复之前，贡献者、Agent、自动化和维护者分别从哪里进入工作。

MixedPR已合入

将 provider_disabled 503 判定为不可重试

“/coder-agents-review”

维护者多次调用 review swarm。Bot 报告共使用 17 个 reviewer、花费 62.66 美元；随后由真人确认结果并完成合入。

打开公开线程
  1. 01
    贡献者提交修复
  2. 02
    维护者调用 review
  3. 03
    Agent swarm检查补丁
  4. 04
    维护者接受并合入

Agent 扩大代码供给，开源协作决定一个项目能够吸收并长期维护多少。

证据显示 Agent 确实增加了评审和修改能力，却没有带来相匹配的合入能力。在 Agent 时代，贡献不只是生产更多代码；它还意味着把改动连接到共同问题、带过评审流程，并留下社区愿意继续承担的部分。
方法与数据边界

当前两张全景图包含 data/agentic-ai-projects.csv 中标记为 keep 或 add 的 145 个仓库。5 月基线是 data/history_snapshot/2605_agentic_projects.csv 中保留的 227 个仓库；OpenRank 与参与者数量使用完整的 2026 年 7 月数据。

OpenRank、Stars、Forks 与参与者数量描述的是不同信号；主要语言来自 GitHub 的仓库级标签。OpenRouter 应用榜公开且为自愿归因。Agent Sandbox、Kata Containers 与 OpenTelemetry 的项目材料用于证明 Agent 执行周围正在发生的具体工程工作；营收、部署规模与技术性能需要其他来源。

协作章节按 7 月 OpenRank 冻结 tracking pool 的 Top 100，此后只把 OpenRank 作为抽样规则。所有 2026 年协作统计均截止到 8 月 31 日，9 月的采集与发布时间不延长观察窗口。贡献入口使用 GitHub REST 与 GraphQL；年度 marker 快照检查默认分支上的 coding-agent instruction file 与工具目录。ClickHouse 事件面板仅用于历史规模与质量检查，因为 2025–2026 年 PR 作者与合入时间数据不完整，不用于生产力结论。

公开线程分析从 Top 100 的每个仓库抽取 2026 年 1 月 1 日至 8 月 31 日的 50 条 Issue / PR，每条线程只计算一次。Actor 标签遵循 GitHub 公开的身份或 App 归因；未披露的本地 Agent 使用仍会显示在开发者普通 User 账号下。

参考来源

61 项来源