GitHub对AI Agent的计划（90分钟阅读）

# GitHub 的智能体计划 —— Kyle Daigle，GitHub 来源：https://www.latent.space/p/github *我很激动能再次与微软合作，作为AI工程师世界博览会（https://www.ai.engineer/worldsfair/2026）的主要赞助商！\!**我们将在MS Build（https://build.microsoft.com/）今天进行直播，与我们的朋友在No Priors（https://x.com/saranormous/status/2061681787169017949?s=20）以及独一无二的**Satya Nadella**进行一期特别的跨界节目。但我们并没有在这次采访中有所保留——我们问出了所有你们心中关于正常运行时间和Copilot的燃眉之急。开始吧！\!* 近二十年来，**GitHub**一直是软件的栖息地，无论是开源还是闭源，都通过代码提交、拉取请求、审查、Action等流程流动。 X头像 @kdaigle Kyle Daigle@kdaigle 生日快乐🎂，GitHub\! 我正在用一个故事庆祝我们的生日：关于GitHub联合创始人defunkt如何在18年前他们上线后拒绝了我的求职……但最后一切都很顺利。🤣 18年前的今天，GitHub由defunkt、@mojombo正式发布， 下午12:33 · 2026年4月10日·21.9万次查看 16条回复·18次转发·243个赞 (https://x.com/kdaigle/status/2042581612400120093)这个生态系统蓬勃发展，开源维护者和贡献者持续为社区利益发布代码。然而，当编码智能体开始发布海量代码时——**2026年增长了1400%**，这标志着一个对GitHub来说既极其激动人心又充满挑战的新时代。 X头像 @kdaigle Kyle Daigle@kdaigle 没错，平台活动正在激增。2025年有10亿次提交。现在，每周有2.75亿次，如果增长保持线性（剧透：不会的），今年将达到140亿次。GitHub Actions已经从2023年的每周5亿分钟增长到2025年的每周10亿分钟，现在 X头像 @ThePrimeagen ThePrimeagen@ThePrimeagen 我想为捍卫微软道歉，但我不得不偶尔这样做。我必须向GitHub致敬，感谢他们处理了过去3个月里添加的大量垃圾代码。真的是数十亿行永远不会见到CPU光亮的代码 下午8:29 · 2026年4月3日·262万次查看 156条回复·569次转发·7140个赞 (https://x.com/kdaigle/status/2040164759836778878)虽然这些智能体帮助更多人发布更多项目，但它们也显著提高了代码发布量的下限、发布频率、提交代码的人数，并基本上在GitHub基础设施的每个维度上都带来了数量级的增长： 现在GitHub不可避免地在其原本围绕人类开发者以人类速度运行的基础设施上面临更大压力。这导致了一个非常公开且引人注目的正常运行时间事件： X头像 @SapphoSys chloe 🐇@SapphoSys 世界上第一个实现零个九可用性的企业解决方案 GitHub平台：89.91% 可用性 上午11:31 · 2026年4月2日·62万次查看 120条回复·474次转发·1.26万个赞 (https://x.com/SapphoSys/status/2039667138198372591)这就引出了一个问题：围绕代码的现有系统能否吸收AI产生的内容？当每个想法都变成一个构建时，CI/CD能跟上吗？开源维护者能承受住AI生成的劣质贡献洪流吗？GitHub能否在成为智能体操作层的同时，保留软件的人类社会契约？ 这让我们找到了回答这些问题的最佳人选：**GitHub COO Kyle Daigle。**在本期节目中，他与swyx一起深入探讨了当AI不仅仅是自动补全代码，而是开始改变公司运营方式、开源工作方式、拉取请求审查方式以及GitHub自身扩展方式时会发生什么。 我们深入探讨了**GitHub的内部AI工作流程**：微技能、WorkIQ、MCP、Slack、Teams、电子邮件、Copilot工作流、新的Copilot桌面应用、CLI、云智能体，以及Kyle**如何使用智能体回顾公司上下文来决定下一步行动。**Kyle还反思了GitHub构建webhooks、API、Actions、npm、Dependabot和Semmle的历史，为什么AI时代以新的方式冲击GitHub，Actions如何成为通用计算层，以及Copilot在代码补全之后会变成什么。 **我们讨论的内容包括：** - Kyle在GitHub的**扩大的职责范围** - AI如何让Kyle在领导层多年后**重新开始编码** - 为什么GitHub通过**现有工作流程**而非强制新工具来推广AI - WorkIQ、MCP、Slack、Teams、电子邮件以及GitHub作为**公司上下文** - 为什么庞大的“宏技能”正在让位于小型、**原子的微技能** - AI如何改变**摘要、沟通、市场营销**和分析师工作 - 为什么前开发者出身的领导者在AI时代可能具有**独特优势** - Kyle的**“周六15个智能体”**工作流程 - Kyle如何为CRO/CFO团队构建**AI生成的执行演示** - 为什么AI改变了**幕僚长角色**但并未消除人工工作 - GitHub Actions、webhooks、任意代码执行和**安全的智能体计算** - npm收购、**供应链安全**、2FA和令牌失效 - 劣质复刻、vendoring以及AI智能体是否改变**依赖管理** - 当大多数PR来自**智能体**时，拉取请求会变成什么 - 提示请求、担保、AI审查和**开源信任** - 当AI降低了构建的**门槛**时，什么才算“开发者” - GitHub Spark、低代码以及为什么GitHub拒绝**隐藏代码** - **14倍提交增长**、Actions负载、数据库、单体仓库和可用性 - Copilot从代码补全都**CLI、桌面应用、云智能体和SDK**的演进 - 上下文、记忆、规则以及让GitHub**“表现得像Kyle希望的那样”** - Ambient AI、OpenClaw、企业安全以及**面向智能体的新操作系统** - swyx应该问**Satya Nadella**关于微软AI未来的问题 **Kyle Daigle** - **LinkedIn:** https://www.linkedin.com/in/kyledaigle - **X:** https://x.com/kdaigle **00:00:00** 引言 **00:03:36** 为什么AI让Kyle重新开始编码 **00:07:04** 使用AI运营GitHub：WorkIQ、MCP、Slack、Teams和技能 **00:15:39** 前开发者出身领导者的黄金时代 **00:17:31** 周六15个智能体与AI生成的执行层工作 **00:20:20** AI如何改变幕僚长角色 **00:21:45** GitHub的历史：Actions、npm、webhooks和开源 **00:28:45** 劣质复刻、vendoring和AI依赖管理 **00:33:57** 拉取请求、提示请求以及对智能体生成代码的信任 **00:41:21** GitHub Stars、2亿+开发者以及新的AI构建者浪潮 **00:45:15** GitHub Spark、低代码以及为什么GitHub仍然显示代码 **00:47:38** GitHub最艰难的时代：14倍增长、可靠性和规模 **00:59:21** Actions作为CI/CD和自动化的计算层 **01:02:04** GitHub Copilot的现状与未来 **01:08:24** Ambient AI、后台智能体以及SDLC的未来 **01:13:09** OpenClaw、企业安全以及面向智能体的新操作系统 **01:18:03** Build公告、WorkIQ、FoundryIQ和微软上下文 **01:21:41** swyx应该问Satya什么？ **Swyx [00:00:00]：** 我们邀请到了GitHub COO Kyle Daigle。欢迎你。 **Kyle [00:00:07]：** 嘿，感谢邀请。 **Swyx [00:00:08]：** 你不仅仅是GitHub的COO。大家也这么认识你。你有了一个新角色。 **Kyle [00:00:11]：** 是的，我现在职责范围扩大了。我在GitHub工作了13年，一直从事与开发者相关的一切工作。我自己也是以开发者身份加入的。现在，我还担任微软开发者部门的CMO。所以，关于如何与开发者合作、如何沟通以及如何将产品推向市场，这些我们多年来积累的经验和热情，现在也被带到了更广泛的微软生态系统中，帮助每一个使用微软产品或希望获得类似GitHub体验的开发者。从某些方面来说，这是一个不同的角色，但它也是建立在我在GitHub的经验之上的：实话实说、保持真实、向人们展示如何使用，然后让产品自己说话。现在，我只是在整个微软范围这样做。 **Swyx [00:01:09]：** 我们将在Build大会期间发布这期节目。你有很多计划，我们可以在合适的时候聊到。我觉得有趣的一点是，我很少见到一个COO同时还是CMO。你非常面向外部，并且在公开场合非常自信。这很少见。你把自己看作COO吗？你的定位是什么？ **Kyle [00:01:33]：** 对我来说，这些头衔一直挺有意思的。加入GitHub时我是一名开发者？我编写了那么多 **Swyx [00:01:46]：** 我们聊聊这个。你写了后端？ **Kyle [00:01:48]：** 我在翻看一些老照片的时候，当时大家在讨论某些东西是如何构建的，或者GitHub是如何构建的。我构建了webhooks，与团队一起构建了API，构建了平台层。直到2018年左右，任何与GitHub集成的项目，都是我构建或领导工程团队完成的。我最初的热情始终是帮助人们构建东西，并交付给他们的客户。作为一名开发者、为开发者构建东西，这总是非常独特的。随着我职责的扩大，我具备了与开发者、企业客户或业务领导者沟通并充当翻译层的能力。这么多年来，GitHub一直运营得相当独特。疫情之后，远程办公并不像GitHub在2008年创立时那样新奇。但所有这些运营远程团队并做好的经验，逐渐演变成了一个更大的角色，最终成为了COO：在微软收购后，如何以GitHub一贯的方式运营GitHub。大约就是这样。所以对我来说，我仍然在编码。我热爱编码，但问题始终在于人。支持我们自己的员工是一个更难的问题；向开发者和企业买家沟通我们在构建什么以及为什么重要，也是一个更难的问题，因为这两者是完全不同的信息。能够在COO、CMO和开发者身份之间切换，我认为这就是我能在GitHub待这么久的原因。 **Swyx [00:03:40]：** 显然，你的提交量增加了。这是怎么回事？ **Kyle [00:03:45]：** Rui非常直接地指出了这一点。正如你可以想象的，大家可以看到我作为开发者的正常阶段是在2013、2014年左右，然后进入管理岗位，最终成为COO。我认为你在这里看到的是，我借助AI真正重新开始编码了。与解决如何营销、如何运营业务以及如何编码这些问题类似，我发现构建能够连接各种截然不同问题的智能体和工作流程正是驱动这次变化的动力。所以，这其中一部分是编写软件，很大一部分是连接大量不同的数据源来帮助我。但这完全是我深入AI领域、尝试我们的工具、尝试每个人的工具，然后为自己、为非技术领导者（尽管我是技术出身）进行构建，我们使用这些工具的方式超越了简单的“呼叫-响应”，我认为许多非技术人员必须使用AI，所以每个人都用ChatGPT、Copilot、Claude或其他工具。要真正深入理解这如何帮助我，我发现这不是“我需要写一篇博客文章”或“我需要那些简单例子”所能解决的。帮助人们找到那些工作流程，比如：“好的，我需要你浏览今天所有的PR。我需要你浏览我们在线发布的所有内容。我需要你浏览过去三个月我们所做的一切。浏览我所有Obsidian笔记中提及此内容的地方，然后浏览我在工作时的转录记录。”我们使用Teams，所以利用WorkIQ，调用那个MCP服务器，获取所有的转录记录，浏览所有的Slack信息，然后为我制定出本周实际要传达的信息计划。这在以前是不可能的，因为对我来说，我发现AI在这次发布中的大部分内容，实际上并不是面向未来的构建。它实际上是一个向后的递归循环。我总是先看发生了什么。回顾这一周，告诉我我们做了什么，什么有效，什么无效？然后告诉我接下来三四天——基于这种回顾和稍微向前看一点，你会调整什么？我发现这非常有价值，尤其是对于非技术人员，因为LLM非常擅长这种回顾总结。比如找出所有模式，提取出来，然后将这种回顾应用到仅仅几天或很短的时间内。所有这些都源于我构建并发布的一系列应用和内部工具。我使用新的GitHub Copilot应用，也就是带有工作流的桌面应用。每次我打开笔记本电脑，它都在为我运行工作流。这涉及非常多不同的东西，当然，所有最终都会落在GitHub上。 **Swyx [00:06:47]：** 当然。那是所有东西托管的地方。天哪，有太多问题要问你了。我本来打算把“你如何用AI运营公司”这个问题留到最后。但我必须追问一件事。你说，你回顾这一周，了解发生了什么。当你说“我们”时，那可是三千人。怎么做到的？ **Kyle [00:07:09]：** 我认为当我们开始在工程部门之外推广内部AI时，我充满热情的一件事是：我们必须以这样一种方式进行，即没有人需要改变他们工作的方式。我不想必须教你一个工具。我不想必须教你一些新东西。所以对我们来说，我们尝试了一些工具。大部分都不奏效，因为我必须让你接纳并教你如何使用它。我们最终实际做的是，我们在内部构建了一套技能。我们每个人都有自己的技能，我们甚至将CLI分发给非技术人员。然后，我们有效地赋予它读取我们所有书写内容的权限。对我们来说，这通常是GitHub、Teams、电子邮件和Slack。Teams用于视频聊天，一般来说是这样。 **Swyx [00:08:03]：** Teams和Slack同时用？ **Kyle [00:08:04]：** 我们使用Teams进行视频通信，但我们不把它用于聊天。GitHub有着悠久的历史，对吧？我们总是 **Swyx [00:08:13]：** 还有Slack **Kyle [00:08:14]：** 谈论ChatOps，一切都在Slack中构建。每个命令，每个流程。 **Swyx [00:08:18]：** 所以尽管你们被收购了大约八年 **Kyle [00:08:22]：** 我们仍然 **Swyx [00:08:23]：** 你们还在用Slack？ **Kyle [00:08:23]：** 它对我们来说是一个专用工具，我认为现实是，迁移离开它的成本会非常高？仅仅因为所有工具都已经与那个范式深度集成。两者各有优缺点，但它们的工作方式完全不同。我们仍然使用许多不同的工具，因为我们需要这些专用工具。然后 **Swyx [00:08:47]：** 好吧，微软其他部门可能不是这样。 **Kyle [00:08:50]：** 各个团队的运作方式不同 **Swyx [00:08:53]：** 他们自己做决定 **Kyle [00:08:54]：** 多种多样。我认为这取决于你想要做什么。但我们确实在我们使用的每一种工具中协同工作，然后通过赋予每个人对我们所写一切的访问权限——