GitHub COO 亲述：AI 代理正在“撑爆”GitHub，信任机制要重写

GitHub 正在被 AI 代理“撑爆”。

2025 年全年 10 亿次 commit，现在每周 2.75 亿次，年化增速 14 倍，平台可用性一度跌到 89.91%。不是因为突然多了几亿人类开发者，而是 AI 代理在疯狂提交代码。GitHub COO Kyle Daigle 在这期访谈里正面回应了这场冲击。他在 GitHub 干了十三年，从写 webhooks 的开发者一路做到 COO，还兼任了微软开发者 CMO。整场对话他讲了四条主线：第一，GitHub 的数据库权限层、单体大仓和 Actions 正在被 agent 的高频使用“撑破”，传统的垂直和水平扩展都不管用了，必须重写底层服务；第二，他自己怎么用 AI 管三千人的公司，周末跑 15 个 agent 做复盘、用 AI 生成向 CFO 汇报的完整幻灯片、以及为什么内部不用“巨型技能”而用“微技能”；第三，Copilot 正在从代码补全进化成统一的 agent 平台，但真正让他兴奋的是让 GitHub 能像他自己一样行动，记住他的规则和偏好；第四，当绝大多数 PR 都来自 agent 时，信任机制需要根本性重建，这说到底不是一个技术问题，而是一个社会问题。

以下为编译。

1

从写 webhooks 的开发者到 GitHub COO，现在又多了个微软 CMO

主持人： 你现在不仅是 GitHub 的 COO，还多了一个新角色？

Kyle： 对，我现在也兼任微软的开发者 CMO。我在 GitHub 工作了十三年，刚加入时就是一名开发者，后来一路从写代码到带工程团队，再到 COO。现在微软把我在 GitHub 积累的那套跟开发者沟通、做产品的方式，扩展到整个微软生态里去。本质上还是同一件事：说实话、保持真实、让产品自己说话，只是现在范围变成了整个微软。

主持人： 很少见到一个 COO 同时做 CMO，你还挺愿意公开露面的，这在 COO 里很少见。

Kyle： 头衔对我来说一直都有点奇怪。我加入 GitHub 时就是写代码的，webhooks 是我写的，API 是我和团队一起搭建的，平台层也是我做的。一直到 2018 年，几乎所有跟 GitHub 集成有关的东西，不是我自己写的，就是我带的工程团队做的。后来角色慢慢变大，我发现我的价值变成了能在开发者和企业客户之间做“翻译”。再后来，GitHub 一直很擅长远程协作，这套运营经验最终让我变成了 COO。我到现在还在写代码，但真正的难题从来都是人。支持员工、跟开发者沟通、向企业客户解释我们在做什么，这些是更复杂的工作。同时做 COO、CMO 和开发者，这种混合角色也是我在 GitHub 待这么久的原因。

主持人： 你的 commit 数量最近涨了很多，怎么回事？

Kyle： 确实被同事点名了。你看我的 commit 记录，2013、2014 年是一个正常的开发者时期，后来进入管理层，再到 COO，commit 就降下来了。最近又涨了，完全是因为 AI 让我重新开始写代码。我做的事情不完全是传统意义上的写软件，更多是把各种数据源连接起来、搭 agent 和工作流。

对我来说，AI 最有价值的用法不是“帮我写篇博客”那种简单问答，而是帮我在做决策之前先回头看。比如我会让 agent 去翻过去一周的 PR、我们对外发的所有内容、过去三个月的内部记录、我的 Obsidian 笔记、Teams 和 Slack 的聊天记录，然后帮我生成一份“这周到底发生了什么”的计划。LLM 非常擅长做这种复盘和模式识别，把过去几天的事情整理出来，再给我一个“接下来三到四天该调整什么”的建议。这比单纯往前建东西有用得多。

我每次打开笔记本，Copilot 桌面应用就在跑各种 workflow。当然，所有这些最终都托管在 GitHub 上。

怎么让三千人的公司用上 AI：不教新工具，只给技能和 CLI

主持人： 你说“我们回顾这一周”，那可是三千人的公司，怎么做到的？

Kyle： 我们在向非工程团队推广 AI 时，定了一条原则：不能强迫任何人改变工作方式。 我不想教你怎么用一个新工具。我们试过好几个产品，大多数都不行，因为你得先让人上手。后来我们干脆自己内部建了一套“技能”（skills），分发给所有人，包括非技术岗位的同事。入口就是 CLI，然后给这些技能开通读取权限，能访问 GitHub、Teams、邮件和 Slack。

我们用 Teams 做视频会议，但聊天一直用 Slack。因为 GitHub 历史上就把 ChatOps 和所有命令、流程都嵌进 Slack 里了。就算被微软收购了八年，我们还是在用 Slack，因为所有工具链都围绕这个范式搭建的，迁移成本太高了。

有了这套上下文访问能力，再加上新的 WorkIQ MCP server，远程办公的同事可以随时往回看。我们会自动把发现的内容推送到 GitHub issues 或 discussions 里，然后在上面继续讨论。非技术岗位的人以前要花一周才能搞明白的事情，现在变成“我建了一个技能，放到仓库里，大家一起用 CLI 或者 app 跑就行了”。

主持人： 技能会不会膨胀到失控？每个人都想推自己的技能，内部肯定有“技能网红”吧？

Kyle： 确实有这种苗头，但我们现在正在告别那种“巨型技能”的时代。以前 Twitter 上天天有人分享一个完美的技能包，号称能完成整个工作流。我们内部发现根本不是那么回事。那种把所有工具串在一起、产出超长报告的“巨型技能”，几周几个月之后环境一变，你就得去修它，一修就崩。

现在我们更推崇“微技能”，一个技能就做好一件事。比如“从任意 MCP server 里提取最重要的营销信息”，而不是“把一堆工具串起来出一份完整的报告”。我们更像个乐高积木的组合方式，每块都很小，大家自己拼说明书。我自己的“总结”技能也分很多版本：做分析师沟通的总结、做客户会议的总结、做营销的总结，每一种都不一样。原子化的工具或技能是基础，但我关心什么、什么才是好的总结，这部分得按角色定制。这就是从开发者视角切换到不同职业视角时最麻烦的地方：同一个词，对你、对我、对分析师、对销售，含义完全不同。排列组合不一样，但每一种排列都很重要，它直接决定了读者读了之后是觉得“这是 AI 写的吧”，还是“这份简报给我的感觉完全对”。

主持人： 其实这也意味着你不用那么小心翼翼地把每样东西都塞进技能里，大概能兜住就行。以前插件时代，GitHub 被这些东西塞爆了，现在直接用技能，反而不需要了。

Kyle： 最神奇的是，我能直接打开技能改。以前你可能要去改插件的代码，现在 AI 可以帮你做，但更爽的是，你收到一个回复觉得“不对”，然后打开技能，敲几句英文，它就不一样了。这种积木块的感觉非常独特。我现在就希望让更多人搞明白怎么通过调整这些技能来发挥最大威力。

主持人： 你有没有觉得，现在是前开发者转型做管理的人的一个黄金时代？因为你会用这些工具，你知道该说什么词，你比没有技术背景的人高效得多。

Kyle： 我觉得秘诀从来都是识别模式和解决问题的能力。像我这样不再每天写代码的人，这个能力让我曾经是一个好开发者，后来是一个还不错的 COO，现在又做 CMO。现在我能重新写代码了，就等于是把模式识别和解决问题的能力，再加上十年积累的商业知识，一起用到开发上。

比如我们每年做收入规划时，到处是幻灯片，讨论明年要做什么。我想“我能不能自己搭个东西搞定它，不用把整个表格传给团队”。于是我用上面提到的那些技能，把所有信息汇总起来，还写了个小应用让我在 SQLite 数据库里看数据更方便。最后我做了一整套演示文稿，完全没有手动碰过。我特意做了一个技能让它的风格看起来“不那么 AI”——不漂亮，但很清晰，不是 AI 味的东西。我就这样拿去给 CRO、CFO 和他们的团队演示，全程没人提过一句“这是 AI 生成的”。事后我跟团队说，我不想让你们去画幻灯片，我们只是需要互相分享信息。如果 AI 能做这件事，你稍微打磨一下，我们一起看看，就很好。做幻灯片这件事没有额外价值。

主持人： 你以前是 Thomas 的 chief of staff，在 AI 之前，这类工作本来就是 chief of staff 做的——帮你准备幻灯片什么的。现在你自己就干了。

Kyle： 我现在还是有 chief of staff。只是她的工作内容变了。每次技术演进，不是岗位消失，而是角色改变。我不再需要有人花所有时间帮我做幻灯片了，但我需要有人帮我在这些讨论中找到人与人之间的连接点：我应该跟哪个团队开会、他们在旧金山有个机会、我明天去西雅图该见谁。这类人际连接的洞察依然极其宝贵。以前 chief of staff 不拆信了，改处理邮件；现在他们不用做那么多幻灯片了，因为 AI 可以分担，我们就可以更快地做出更好的决策。

GitHub 是怎么一步步走到今天的？

主持人： 聊聊 GitHub 的历史吧。你参与了很多关键节点。

Kyle： 2018 年收购完成前，我在 GitHub Universe 上发布了 Actions 的第一个版本。我是那个项目的工程负责人。后来我们收购了 npm、Semmle、Dependabot、Pull Panda 等等。那是收购之后的一个重大转变期。

主持人： Actions 是不是 GitHub 上最大的安全风险来源？

Kyle： 最大的安全风险可能还是每个人仓库里的代码本身。但再往前追溯，最早其实是 webhooks。当年我们有一个叫 GitHub Services 的东西，是一个 Ruby 代码仓库，你可以往里面写任意 Ruby 代码，我们替你执行。那时候没有容器，隔离主要靠服务器层面的分离。Pages 也是跑在自己的容器化基础设施上，不在 Actions 上。后来我们意识到“不能让每个人随便跑 Ruby 代码”，就把它全部容器化，变成了 Actions。现在容器化做得很好，但大多数人不会把自己的 workflow 锁定到特定的镜像 SHA 上，只是用 V1 或者 latest，这跟依赖管理的问题是一样的。从那个“跑任意代码”的时代走到现在，容器化越来越好，我们还在底层用 Azure 的 Dev Compute 来做非常快速的 VM 启动。

主持人： 再聊聊 npm。那次收购当时看来是 npm 需要一个“家”。

Kyle： 当时跟 npm 团队聊，核心目标是让这个基本上在支撑整个互联网的注册表能继续运行、继续扩展。它当时有扩容问题，在做一些重写。我们投入了大量时间和精力去修后端、改 manifest 层，现在也在努力把 npm 的安全水平提上来。但每一次加强安全的动作都会影响很多人。安全是头等大事，但每次我们发现问题或者让平台更安全，对开发者来说都是一个需要紧急处理的“雪天”或者“火灾”。我们改了 2FA 政策，改了 token 的工作方式，发现可能泄露的 token 会直接让它们失效。这会制造问题，但我们是在尽量推动社区往前走，同时不打破已经存在十五年左右的默契。

AI 代理让 PR 暴增，但真正的难题是人类该怎么信任机器写的代码

主持人： 现在大家在讨论 slop forks、vendoring、甚至有人提出干脆取消 npm，只发布源码，让 AI 代理去“vendor 化”。你怎么看？

Kyle： Mitchell Hashimoto 今天还在聊这个。某种程度上，vendoring 是老东西卷土重来。我记得 2013、2014 年我们就在做一样的事，讨论“这个包太大了，我只需要这一个文件”。只取所需、让依赖越来越小，这个方向有帮助，但解决不了根本问题，因为 agent 检查代码时有一百万种方式被说服“这个东西是安全的”。静态分析、运行时测试才是需要持续投入的方向，问题是范围要多大。

作为 GitHub，我们很少主动推一个流程或实践给社区。我们更倾向于等社区通过 RFC 或者事实上的共识形成惯例，再把它固化下来。我们不想塑造整个生态，我们想让生态自己演化。

主持人： 很多人不知道 pull request 这个流程本身就是 GitHub 标准化的。现在的问题是：当 80% 的 PR 都来自 agent 而不是人类开发者时，PR 流程该长什么样？Peter 提的 prompt request 这个想法你觉得怎么样？

Kyle： 每个想法都有它的道理，我不想回避问题，但我觉得之所以没有一个标准答案，是因为我们本质上是在试图把“信任”这件事编码化。以前我们信任一个 PR，是因为 Sean 审过了、或者你是高级开发者。现在 agent 写代码、另一个 agent 审代码、我再去看，信任就被稀释了。我们讨论的很多工具其实是在做“验证流”，用更多资产来判断一个 PR 好不好。但依然没有解决那个人类问题：我看着一个 PR，我想知道我能不能信任它。我们仍然在用人类的信号来判断——Mitchell 通过了，或者 Kyle 通过了。这就是为什么大多数方案没有真正解决问题，因为说到底，这是一个社会问题，一个人类问题。

主持人： 就像我们终有一天会不允许人类开车，因为机器比人类更安全。我在等那个临界点。

Kyle： 我坐 Waymo 过来，全程看手机，完全没看路。但有些自动驾驶车，我死盯着路也不敢信。我认为信任是一半可验证的数据（事故率、里程等）加上一半人类的感受（我坐这辆车的感觉、它给我什么反馈）。有些 AI 工具就算数据说是 100% 准确，我用起来就是需要更长时间才能说服自己“我能信任它吗”。在创业公司、开源项目里这已经是难题了，到企业和受监管行业就更难了，因为不仅要团队内部信任，还要跨国、跨监管机构信任。直到我们在人类情感层面感觉到“好了，够了，我信了”，事情才会加速滚动。

主持人： 如果信任是关键，GitHub 作为开发者社交网络能不能做得更多？我们现在只有 star、contributor 权限，我感觉应该还有更多东西。

Kyle： Sponsors 是个好例子。它让你付出一些成本，来证明你相信这个项目、信任这个人。我不太喜欢 star 或 commit 计数这些东西，因为我们做了大量反滥用、去重工作，但它们终究是被动的信号，是可以被刷的。攻击者会提前批量注册账号，养着等它“变老”，互刷 star、互建 repo 提 PR，然后突然搞破坏。

所以我们更想给你工具，让你自己选择信任什么信号。比如，一个 agentic workflow 可以设规则：Kyle 在多少项目里提交过被接受的 PR、他的 GitHub 账号关联的社交账号有多久历史。这些都是很复杂但对你很重要的指标，大多数开源项目的维护者脑子里本来就有这些判断规则，只是没写在贡献指南里。

主持人： 说到这个，项目涨星的速度也让人不敢相信。现在十万星只要几个月，但谁知道有多少是 bot 刷的？star 这个机制是不是坏了？

Kyle： 我们一直在打击 spam，包括 star 刷量，但这确实像打地鼠。不过我看到的更大因素是，我们正在把更多人拉进软件开发这个领域。现在 GitHub 已经有超过两亿“开发者”了，但它不是传统意义上的开发者，不是你我这种写了很久代码的人。有些人可能只是在 AI 时代开始写代码，有些人是周末给朋友做了一个小应用，听到一个很酷的新 agent 技能包，就点了 star。他们想参与这个时代，就像当年 Ruby 社区爆发时我想参与一样。我不觉得我们应该在这个早期阶段去细分“谁是真正的开发者”。我自己刚开始写代码的时候也算不上开发者，如果那时有人 gatekeeping，我也进不来。任何人只要有想法、能用某种方式把它跑起来，就应该被当作开发者。 这跟你会不会换电灯开关一样，你不需要去碰配电箱，但换个开关你应该能做到。GitHub 一直在坚持一件事：我们永远不把代码藏起来。 就算做 Spark 这种低代码产品，底层代码你依然可以看到。

GitHub 正经历最难的扩容时刻：数据库权限层、单体大仓和“对角线式”扩展

主持人： 现在对 GitHub 来说是轻松的时刻还是艰难的时刻？

Kyle： 艰难的时刻。同时也是我在 GitHub 经历过的最好、最兴奋的时刻。以前我们一年做一次 Octoverse 报告，看数字就觉得“天哪”。去年十月我在 Universe 上说“这是我们增长最快的一年”，现在一个月干掉了去年一年的量。不管是 commit、PR 还是其他指标，都在打破系统，而且是以全新的方式。

以前 webhooks 是出了名的不稳定，后来在规模层面重写了，现在没问题。但现在的问题不是那种简单问题了，而是在这种体量下才出现的独特权限问题、跨所有对象的边界情况，逼我们重写底层系统。增长是天文数字，但我们在底层基础设施上的进展也非常实质性。我期待当我们重新构想完底层之后，不只是现在所有的人类开发者和他们的 agent 在协作，而是整个社区能一起做什么。

主持人： 给听众一个数据概念。2025 年 10 亿次 commit，现在每周 2.75 亿次，年化 140 亿次。这就是 14 倍增长。很多人经历过 14 倍增长，但没经历过你们这种宕机。到底哪里出了问题？

Kyle： 有几个地方。一是 Actions 需要更多 CPU。更多 agent、更多 PR 意味着更多构建，更多构建意味着更多 CPU。我们不仅在用自己的数据中心，也在扩展到 Azure 的云上，因为单纯需要更多 CPU。GPUs 当然也要，但 CPU 现在也成了瓶颈。

底层服务方面，我们多年来一直在拆分数据库基础设施，让不同服务之间有更好的隔离。但问题最集中的地方是权限层，很多权限相关的逻辑还放在一个我们内部叫“MySQL One”的数据库里。我们从几年前就在往外拆，用 Vitess 和其他技术做分片。更复杂的是，GitHub Enterprise Server 还要把所有东西打包成一个黑盒给本地部署客户跑，还要做数据驻留部署。每一个场景对 MySQL 存储和权限设置的处理都不一样，这就是为什么有些宕机看上去是全面性的，而不是单点故障。

另外还有一个趋势是单体大仓（monorepo）越来越多了。以前行业走了很多年“小 repo、多 repo”的路，现在反过来了，repo 越来越大。大仓一直有独特的性能问题，尤其是底层 blob 特别大的时候。我们在 Git 基础设施层做了大量工作，让大仓变好，所有 repo 也跟着受益。还有一个是 job queuing 系统，也在改底层技术。

总的来说，过去 GitHub 扩规模就两条路：垂直扩展（数据库加机器）和水平扩展（加更多服务器）。现在进入了“对角线”阶段：垂直也不够了，水平也受限了，因为 CPU 和 GPU 供应都紧张。我们不得不拆开已经跑了十到十五年的服务，发现“这个服务的规则已经彻底变了，必须重写”。这不是借口，这是我们必须干的活。

主持人： 我作为一个基础设施爱好者，这大概是我见过最迷人的扩规模挑战。

Kyle： 这就是为什么我们之前没怎么公开聊，因为 GitHub 的老传统是：这是我们的可用性问题，它是宕了，我们修好就行，你不需要知道具体哪个服务没达到预期。但现在我们在改变做法：我们会写博客、写文章，让工程师做完之后告诉你“我们做了什么”。我们想跟社区重新建立起这种信任契约：我们依然是认真的，我们只是没来得及告诉你每一步在做什么。未来不管是 14 倍、30 倍还是 50 倍的增长，我们都会为那个量级而建。

Copilot 的“成长”

主持人： Copilot 现在到底处于什么状态？

Kyle： Copilot 刚出来时靠代码补全一炮打响，后来我们花了一年半左右的时间做 fine-tuning，因为当时整个行业都在问“怎么提高准确性和性能”。我们在做更大范围的代码补全、下一版编辑建议的 fine-tuning，既有整体模型的 fine-tuning，也有按客户定制的。但就在那个阶段，新一代模型出来了，性能大幅跃升，各种 AI 编程工具也冒出来了。很多人问“Copilot 去哪了”，其实那段时间我们是走在“让模型更好”这条路上，结果模型自己变好了。

从那以后，我们在继续做好代码补全的同时，也构建了一套统一的 SDK 和 harness，这就是现在 Copilot 的底层。新的 CLI、桌面应用、云端 agent，全都用同一套 SDK。它不只是帮你生成代码，而是让你能用这套 agent 运行时去做各种事情：安全修复、对每一个 GitHub issue 自动派一个 agent 去试试能不能解决、扫描仓库里的文档看看哪些跟实际代码对不上。这种“AI agent 自动化”的感觉，是 Copilot 正在走的方向。

主持人： 那还差什么？

Kyle： 我最终想让 GitHub 能像我自己一样行动。记住我的规则、我的偏好、我的记忆，不用我把所有东西都显式编码出来。我们的方法会随着目标变化，我需要 GitHub 理解我在开源和依赖中的上下文。这离 AGI 还远，但如果每次我需要告诉你一件我关心的事、一件我已经说过无数遍的事，你能自动记住并调用，那就很接近我想要的。

主持人： 我们是不是已经到“整个 SDLC 都铺满 agent”的尽头了？

Kyle： 还没有。我们现在还处于一个非常短视的 AI 时代。因为安全和治理的原因，大多数人的编程 agent 就算能后台跑，也会丢掉编码之外的所有上下文。对我来说最有趣的是环境式 AI（ambient AI）：不是那种“帮你记住一切的插件”，而是当我要实现一个新功能时，agent 能知道每一个 spec 文档、每一封邮件、每一次在线讨论，然后用这些来做决策。软件开发从来不是单行道，不只是写好代码就完事。它需要其他团队成员的上下文、业务在做什么、现在什么流行。这就是为什么 OpenClaw 这么有意思：它连接了我关心的所有数据源。但我的问题是：我怎么把这些数据用起来，不只是换一种方式启动 coding agent，而是让它真正帮我做开发决策。

主持人： 极端情况就是 AI 接管你的生活。有一种“控制反转”——不是你来告诉 AI 做什么，而是 AI 来告诉你。

Kyle： Nat Friedman 在一个活动上分享过，他把 OpenClaw 接上了自己的摄像头，它在看着他。他把 Uber 重定向了。我其实挺想让 OpenClaw 提醒我喝水的，但我不太想让它改变我的行车路线。我想说的是，它需要掌握更多关于我的信息才能帮到我，而我每次告诉你我关心什么、我说过十二次的东西，它应该能记住并获取到。

微软为什么要派一个 CVP 专门盯着 OpenClaw？

主持人： 微软有一个 CVP 专门负责 OpenClaw，为什么？微软又不拥有 OpenClaw。

Kyle： 这次 Build 我们也会聊更多。OpenClaw 做到的事情是，它让每个人都能接入自己有权访问的资源，并让 AI 替你做事。以前大家得自己搭 agent 来实现这个。放到工作场景里，如果你能在工作设备上跑一个类似 OpenClaw 的东西，能访问你的工作资产，还能在 Windows 上跑得好，那不是很好吗？

OpenClaw 已经变成了“一个真正理解我、能使用我的电脑的 agent”的化身。它比任务型流程或者聊天工具强得多。所以微软要解决的下一个问题是：如果 agent 不是装在 Mac Mini 或托管设备上，而是装在个人设备或工作设备上，操作系统层面必须有更好的沙箱机制，否则你会被公司开除。 这就是为什么微软在 Windows 沙箱、云端沙箱上投入。微软也在给 OpenClaw 开源项目贡献大量代码，很多核心贡献者就是全职投入的微软员工，只是他们不想抢功劳。

我们不需要每个人都去造同样的顶层产品。如果我们是为构建者而建，就应该给你所有组件，告诉你它们是什么、怎么用、为什么值得关注，而不是一次又一次地只交付同一个垂直产品。

主持人： 微软是原生的操作系统公司，而 OpenClaw 正在变成新的“AI 操作系统”。

Kyle： 操作系统必须跟五年前不一样了，因为现在不只有你在用它们。我的 OpenClaw 不能随便创建一个用户账号。我们得一路看到 Azure 的芯片层，因为工作负载不一样了。不只是“需要更多推理”，而是“需要什么类型的推理、什么类型的计算来跑 agent 和 agentic 流”。这是一个非常有意思的多层物理问题。过去五六年软件行业有点无聊，SaaS 产品推新功能，最好的 SaaS 产品推最新的 SaaS 功能。现在不一样了，我们撞上了物理极限，这很刺激。

主持人： 最后一个问题。我要去 Build 大会采访 Satya，我该问他什么？

Kyle： 问他“你觉得两三年后，什么会是真的？” 听起来像随口一问，但你看他怎么看 AI 问题、推理问题、token 问题，以及我们实际会怎么工作。你能看到微软内部最近正在发生一些转变，把四五六七八件不同的事收敛到一起，把分散的上下文整合起来。为什么这条路在两年后会有效？这个问题很大胆，但我觉得很多人其实心里有疑问，一个坦诚的回答会让人安心，也给我很多写作的素材。

点击关注我哦