GitHub 的 AI 代理计划 —— Kyle Daigle, GitHub

_I'm excited to work with Microsoft once again as the presenting sponsors of the AI Engineer World’s Fair!_ _We’ll be streaming live from MS Build today for a special crossover pod with our friends at No Priors and the one and only Satya Nadella. However, we did not hold back with this interview — we asked all the burning questions about uptime and Copilot that we know you have in your minds. Let's go!_

近二十年来，GitHub 一直是软件的家园，无论是开源还是闭源代码，都通过提交、拉取请求、审查、动作等流程在此流动。

这个生态系统在开源维护者和贡献者持续发布代码以造福社区的过程中繁荣发展。然而，随着编码代理开始大规模生成代码——2026 年增长了 1400%——这标志着一个既令人兴奋又充满挑战的新时代到来。

尽管这些代理帮助更多人交付更多项目，但也显著提升了代码发布的数量、频率、提交人数，以及 GitHub 基础设施在各个维度上的量级：

如今，GitHub 不可避免地面临更大的基础设施压力，而这些系统最初是为人类开发者以人类速度工作而设计的。这导致了一个广为人知的可用性问题：

因此，这就引发了一个关键问题：当前的代码系统能否吸收 AI 所产生的内容？当每个想法都能变成一次构建时，CI/CD 能否跟上？开源维护者能否应对海量 AI 生成的低质量贡献？GitHub 在成为代理的操作层的同时，是否还能保持软件的人类社会契约？

这正是我们请来最合适人选回答这些问题的原因：GitHub 首席运营官 Kyle Daigle。在本集中，他与 swyx 深入探讨了当 AI 不再仅仅是自动补全代码，而是开始改变公司运作方式、开源协作模式、拉取请求的评审流程，以及 GitHub 自身如何扩展规模时会发生什么。

我们深入讨论了 GitHub 内部的 AI 工作流：微技能（micro-skills）、WorkIQ、MCP、Slack、Teams、邮件、Copilot 工作流、全新的 Copilot 桌面应用、CLI、云代理，以及 Kyle 如何利用代理回顾公司上下文，从而决定下一步行动。Kyle 还回顾了 GitHub 构建 webhook、API、Actions、npm、Dependabot 和 Semmle 的历史，解释了为什么 AI 时代正在以全新方式冲击 GitHub，Actions 如何演变为通用计算平台，以及 Copilot 在代码补全之后将走向何方。

视频 3

我们讨论了：

• 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）与令牌失效机制
• 低质量分叉（slop forks）、依赖项打包（vendoring）以及 AI 代理是否改变了依赖管理
• 当大多数 PR 来自代理时，拉取请求会变成什么样
• 提示请求（prompt requests）、背书（vouching）、AI 审查与开源中的信任问题
• 当 AI 降低了构建门槛时，“开发者”的定义是什么
• GitHub Spark、低代码平台，以及为何 GitHub 拒绝隐藏代码
• 14 倍提交增长、Actions 负载、数据库、单体仓库（monorepos）与可用性
• Copilot 从代码补全到CLI、桌面应用、云代理及 SDK 的演进
• 上下文、记忆、规则，以及如何让 GitHub “按照 Kyle 希望的方式运行”
• 环境 AI（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 低质量分叉、依赖项打包与 AI 依赖管理

00:33:57 拉取请求、提示请求与对代理生成代码的信任

00:41:21 GitHub 星标、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 环境 AI、后台代理与 SDLC 的未来

01:13:09 OpenClaw、企业安全与面向代理的新操作系统

01:18:03 发布公告、WorkIQ、FoundryIQ 与微软上下文

01:21:41 swyx 应该向 Satya 提问什么？

Swyx [00:00:00]: 我们今天邀请到了 GitHub 的首席运营官 Kyle Daigle。欢迎！

Kyle [00:00:07]: 嗨，谢谢邀请我。

Swyx [00:00:08]: 你不仅仅是 GitHub 的 CEO。人们都知道这一点。但你现在有了新的职位。

Kyle [00:00:11]: 所以我现在承担了更广泛的职责。我在 GitHub 工作了十三年，一直专注于开发者相关事务。我自己最初就是一名开发者加入的。现在，我还担任微软的“开发者首席营销官”（CMO of Developer）。我们把在开发者身上积累的经验、热情以及如何与他们合作、沟通、将产品推向市场的做法，也带到了微软更大的生态系统中，帮助每一位使用微软产品或希望获得类似 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，搭建平台层。凡是与 GitHub 集成的部分，直到大约 2018 年之前，都是我亲自构建或带领工程团队完成的。这大概就是我最初的热情所在——帮助人们构建东西，并交付给他们的客户。作为一名开发者，为开发者打造产品一直是非常独特的体验。随着我的角色不断扩展，我逐渐具备了与开发者之外的企业客户或商业领袖沟通的能力，充当了一种“翻译层”。而在这所有这些年里，GitHub 一直以一种非常独特的方式运作。疫情之后，远程工作不像 GitHub 创立于 2008 年时那样新颖了。但我们在管理远程团队方面的专业知识，以及如何高效地做到这一点，最终演变成了一个更大的职责，也就是在微软收购 GitHub 之后，如何继续以 GitHub 一贯的方式运营公司，这最终促成了我担任 COO 的角色。以此类推。对我来说，我认为——我仍然会写代码，我也热爱编程。但问题始终在于“人”：既要支持我们自己的员工，又要向开发者和企业买家传达我们正在构建什么、为什么重要，这两者之间的信息完全不同，难度也更高。因此，能够在 COO、CMO 和开发者身份之间切换并融合工作，我认为正是这一点让我在 GitHub 待了这么长时间。

Swyx [00:03:40]: 据说你的提交记录增加了。这是怎么回事？发生了什么？

Kyle [00:03:45]: Rui 对我提出了相当直接的挑战。所以我想——正如你所想象的那样，你可以看到我从 2013、2014 年那个开发者的时代，逐渐转向管理岗位，最终担任 COO 的历程。我认为你看到的是我通过 AI 真正重新回到编码的状态。我发现自己在思考如何将市场营销、企业运营和编程之间的问题联系起来，而构建智能体（agents）和工作流，把各种看似不相关的难题连接起来，正是推动这一切的核心动力。因此，这其中一部分是编写软件，但更多是整合大量不同的数据源来帮助我解决问题。这完全是我深入探索 AI 领域的过程：尝试我们自己的工具，也尝试其他人开发的工具，为我自己、也为非技术背景的管理者打造解决方案——尽管我本身是技术人员。我们正在探索如何更高效地使用这些工具，而不仅仅是停留在简单的“提问-回答”模式上。我认为很多非技术背景的员工都必须使用 AI，比如 ChatGPT、Copilot、Claude 等等。但真正有价值的是：AI 如何真正帮到我？我发现那些“我需要写一篇博客”之类的简单例子并不够。真正有用的是帮助人们找到这样的工作流：“好，我需要你检查今天所有的 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]: 有很多方式。我认为关键在于你想要做什么。但我们确实会使用各种工具，然后让每个人都能访问所有这些上下文信息，以及新的 WorkIQ MCP 服务器，这在你身处 M365 生态系统时非常酷。我可以向它提出各种回顾性问题，这对我们的远程团队来说至关重要。当你不在办公室时，会错过很多东西，而我们团队遍布全球。因此，大部分工作都是回顾性的。然后我们会将结果自动发布到 GitHub 的 Issues 或讨论中，比如一些发现或行业报告。例如今天早上、今天、昨天发生了什么。一些自动化流程会运行，我们会使用应用，也可能使用 GitHub Actions 配合我们的代理式工作流来执行这些任务，然后推送到 GitHub，继续进行对话。对我们来说，通常就是这种“回顾过去、展望未来”的非技术性工作。当然，对很多人而言，还包括构建应用并将其部署到 GitHub Pages 或其他托管平台等。但核心是赋予每个人能力——原本可能需要我花一周时间去搞清楚的事情，现在我们说：“好吧，我创建了一个技能，把它放进仓库里，我们一起共享这个技能，然后通过 CLI 或现在的应用直接运行它。”

Swyx [00:10:26]: 好的。我觉得我们现在直接进入了团队管理和生产力的话题。我认为很多人正在经历不同程度的 LLM 痴迷症。你怎么管理技能的膨胀？比如每个人都有一套自己的技能，并试图向组织内的其他同事推广，对吧？显然，谁在内部成为技能影响力者，谁就某种程度上成了 AI 领导者。我猜你们也有这种情况。

Kyle [00:10:50]: 我觉得我们有。

Swyx [00:10:52]: 而且我猜这很混乱，是吧？

Kyle [00:10:54]: 是的，我觉得现实中有两个层面。首先，我认为我们正在结束那种庞大、精美、完美的技能的时代——因为那些其实都不是真的完美。之前很长一段时间，每天每条推文都在说：“快下载这个技能，它是完美管理整个工作流的解决方案。” 但我们发现，实际情况并非如此。上周我和我的团队讨论了技能相关的问题，我们真正关注的是那些极其微小的技能，它们只专注做好一件事。而不是那种能完成完整报告的全能型技能。这种技能在我们这边已经不存在了。现在通常是：如何设计一个单一技能，能够从任意 MCP 服务器中识别出最重要的营销信息？这才是最关键的东西。与其把一堆工具拼接起来生成一个超级输出，不如专注于单个功能。因为一旦这样做，几周甚至几个月后，事情就会发生变化，你想调整一下，却发现……

Swyx [00:11:58]: 它太脆弱了。

Kyle [00:11:58]: 你的超级技能，你就完蛋了，根本没法改。所以现在我们真正讨论的是像乐高积木一样的组件，然后让“说明书”由我们所有人共同编写。而我认为，过去很长一段时间里，很多 AI 技能都更像是那种“超级说明书”风格。

Swyx [00:12:15]: 我一直在思考 Postel 的法则。我不知道这个词是否对大家有意义。它的意思是：你应该在输入时宽容，在输出时严格，对吧？我认为这对技能设计是一个很好的指导原则。这是我的技能，显然放在 GitHub 上。我觉得每个人都应该像某些 GitHub 仓库那样，给 /skills 这样的路径赋予某种特殊地位，给予特别展示。不管怎样，是的，这就是那种“下载任何内容、转录任何内容”的模式，然后你可以把那些专注于单一任务的原子级技能串联起来，形成一种编排技能，调用其他技能。我假设，这符合你们的做法吗？

Kyle [00:12:56]: 我觉得是的。我认为……

Swyx [00:13:00]: 总结任何内容。

Kyle [00:13:01]: 比如，对我来说，“总结”这件事因场景而异。我负责沟通、PR、分析师关系、市场营销和客户活动，所以我针对不同场景的“总结”完全不同。比如，如果我要为分析师总结某件事，那和我为一次客户会议或客户互动做总结的方式截然不同。所以我认为，当我们谈论周末我自己可能会用的工具或技能时，那些是相对独立的、底层有实际工具或技能支撑的原子化功能，而 Kyle 关心的是 X。但当我们谈论工作场景，尤其是赋能市场人员、传播人员时，重点是：什么是好的总结？然后再加上我作为市场或传播人员关心的内容是什么。我认为，当我们将开发者的关注点扩展到各种不同职业时，这个问题就变得有趣了——同一个词对我意味着什么，对你意味着什么，对分析师或销售代表又意味着什么，这正是我们开始意识到的“矩阵混乱”。虽然表面上看都是“超级技能”，但实际上只是细微变化，但这些变化非常重要。比如，有人读完后会想：“这是 AI 写的吗？”还是“这完全合理，当我向 Gartner 做简报时，我本就期望看到这样的内容。”等等。

Swyx [00:14:37]: 我觉得它的美妙之处可能在于，你不必太在意里面放了什么。它不需要完全匹配，只要大致包含在其中就行。我过去经常抱怨“插件地狱”，基本上就是当你有一个框架，然后需要集成一百个东西时，每个人都会这么做，GitHub 以前就充斥着这些内容。而现在我们不再需要它们了，因为现在你只需要使用技能（skills）就够了。

Kyle [00:15:00]: 而我认为最神奇的地方是，我可以直接打开它修改。比如，是的，我可以去改插件的代码逻辑，或者现在用 AI 也能做到，但我总觉得，当你收到一个回复说“这不对”，然后你直接打开这个技能，输入一些英文单词，结果就变了——这种构建模块的感觉非常独特。一旦大家都能理解如何最好地进行这些修改，从而发挥出最大的潜力，那会非常棒。

Swyx [00:15:36]: 有没有——你身边有和你一样的同龄人？有没有一种共同的认知框架？我感觉（而且这是真的）：这是否是前开发者如今转做领导者的黄金时代？因为你既能掌握工具，又知道该用哪些正确的词，也许你不再深入细节，但这没关系。但你比那些没有技术背景的人更有效率。

Kyle [00:15:59]: 我认为一直以来的秘密就是你识别模式和解决问题的能力。而像我这样不再每天写代码的人，正是这种能力让我在开发岗位上取得成功，也让我在担任 COO 和现在的 CMO 时获得成功。现在，当我能获取并编写代码时，我就把这种模式识别和问题解决能力应用到新的场景中。我仍然了解足够的知识，可以判断：“哦，我想做一个应用，但我不想搞出越狱之类的东西，也不想做出无法运行或无法扩展部署的东西。” 这种能力——将额外的商业知识与编程能力结合——我觉得正是让我感到有趣的地方。这和一些其他技术出身的高管不同，他们从技术转型为商业领袖后，现在又回去更新自己的应用。当然，这对他们来说很好，但我认为更有趣的是：我现在拥有十多年积累的全新专业知识体系，为什么不把这些经验用在 AI 工具上，继续作为开发者来工作呢？我确实觉得这让我变得更强大，但我认为这对每个开发者都适用。我认识的大多数开发者朋友也都具备某种其他底层技能或热情。当然，确实有很多非常优秀、纯粹走计算机科学路线的软件开发者。但我发现，那些来自不同职业背景、学过别的专业、做过各种随机事情，后来才成为软件开发者的，或者原本是开发者，中途做了别的事，再回来的人，他们学习了额外的知识，掌握了额外的技能。现在再加上 AI 的力量，比如我可以在周六孩子打曲棍球的时候，同时启动十五个代理程序，这简直太强大了。我觉得这让我重新找回了创造的感觉，而这种感觉在大多数其他情境下很难复制。第一次你构建一个应用，点击运行，然后展示给别人看，那种魔力是无与伦比的。所以现在不仅能通过代码实现，还能跨越各种不同的资产类型来完成这种创造，这意义重大。我们每年都会做收入规划，讨论明年会是什么样子。正如你所想，到处都是幻灯片，讨论我们要讲什么、叙事结构等等。就像你说的，我会想：“好吧，我大概可以直接做个工具来生成这些东西，这样我就不用手动搭建整个表格，也不用把任务交给团队。” 所以我们经历了这个过程，我收集了所有信息，并使用了我提到的那些技能，构建了一个小应用，方便我更轻松地查看 SQLite 数据库中的部分数据。最终，我完成了整个演示文稿，全程没有碰任何幻灯片编辑器。我心想：“好吧，我就直接把这个呈现给我们的 CRO、CFO 以及他们的团队。” 而且我完全没有提我是用 AI 做的。我甚至专门设计了一个技能，让它看起来完全不像 AI 生成的。只是不那么漂亮而已。

Swyx [00:19:03]: 就像设计一样。是的。

Kyle [00:19:03]: 不漂亮。但就是明显不是 AI 做的。有点像是“别做什么特别的事”。

Swyx [00:19:08]: 这，是的，这很有价值。

Kyle [00:19:08]: 正是如此。我们整个流程都走完了。它用了我在 Obsidian 中的笔记，用了我之前提到的所有上下文信息，包括计划等。在整个过程中，从未有人察觉这是 AI 生成的。

Swyx [00:19:20]: 没关系。

Kyle [00:19:20]: 一次都没有。根本无关紧要。所以现在我可以

Swyx [00:19:23]: 这是一个工具

Kyle [00:19:23]: 我可以用这个工具说：“看，我不希望你去制作幻灯片。” 它们只是帮助我们彼此分享信息。如果这个工具能通过你的一点点调整就能完成，然后我们一起看看，那就太好了。那些额外的工作根本没有价值。我认为，让结果看起来像是人类做的“糟糕”作品，并构建一个小应用来处理数据，这正是现在处于领导岗位的开发者所拥有的优势之一。因为，正如我之前所说，这一切归根结底都是人的问题，都是人际关系的问题。我知道如果你没用同事来制作幻灯片，除非你花大量时间避免这样做。

Swyx [00:20:07]: 我知道，但我觉得那种直接承认自己是 AI 的方式其实有一种独特的魅力。因为我觉得你很坦诚，可能会有错误，我也无法保证完全准确。那么它的价值到底有多少呢？不过，实际上我想问的真正问题是：你曾是 Thomas 的首席幕僚。在 AI 出现之前，这个职位的工作内容大概就是“帮我准备这些幻灯片”之类的事情。而现在，你自己就能完成这些工作了。

Kyle [00:20:35]: 我仍然有首席幕僚。区别在于，每次我们遇到技术演进时，讨论的重点从来不是这些岗位会消失，而是它们会转变。没错，我不再需要有人花大量时间为我制作幻灯片和演示文稿，因为我已经不再需要这些了。但我现在需要的是能够深入挖掘那些人际互动中的联系，帮助我发现：“我应该和这个团队、这个小组见面，他们有一个机会。” 而且今天我在旧金山，明天要去西雅图。这类人际关系的连接依然极其重要，也一直是首席幕僚角色的重要组成部分。但就像过去首席幕僚不再手动拆信处理邮件，而是处理电子邮件一样，现在他们也不再亲自制作那么多演示文稿，因为他们可以借助 AI 来完成，并分享给我——这很棒。让我们继续前进吧，因为这让我们能更快地行动，更迅速地做出更好的决策。

Swyx [00:21:45]: 太棒了。那我们可以进一步聊聊你在产品效率方面的见解。我还想简单回顾一下 colleague 和 hub 的发展历程。因为我们是从这里起步的。此外你还参与了 NPM 的收购案，这一点我也想提一下。最近，我还想提到我们现在正面临一些服务中断问题——虽然我们已经公开说明并解决了这些问题，但在播客里我们还会详细讨论。我有没有遗漏什么？还有其他重大亮点吗？毕竟这涵盖了很多年。

Kyle [00:22:15]: 没有，我认为其中一个亮点是在 2018 年收购完成前，我成功发布了 Actions 的第一个版本。

Swyx [00:22:27]: 哦？

Kyle [00:22:27]: 在 GitHub Universe 上发布的。所以那是 O

Swyx [00:22:29]: 它们这么年轻吗？

Kyle [00:22:30]: 是 2018 年 10 月，我记得没错。对，没错。

Swyx [00:22:33]: 天啊，真是令人难以置信。

Kyle [00:22:34]: 我当时是那个项目的工程负责人，有幸主导发布。然后，正如你所说，我们完成了对 NPM、Semmle、Dependabot、Pul Panda 等一系列公司的收购。这是一段非常重要的时期。

Swyx [00:22:47]: Pul Panda？

Kyle [00:22:48]: Abi 还不错。

Swyx [00:22:51]: DX。天哪。

Kyle [00:22:52]: DX 方面表现很好。而那次收购之后，最大的转变是我不得不加入业务侧。

Swyx [00:23:00]: 所以我得跟你深入聊一聊这些事，因为你亲身经历过。对吧？而且我还能有多少机会跟一个亲历者对话呢？不过，Actions 是 GitHub 上安全问题的主要来源吗？

Kyle [00:23:11]: 哦，不，我认为安全问题的最大来源其实是每个人仓库中实际存在的代码本身。更早之前，如果你还记得我展示过的那张图，最终的问题根源其实是 webhook。

Swyx [00:23:30]: 对，你说的是。

Kyle [00:23:31]: 大约在那个年代。

Swyx [00:23:32]: 图上写着 Hookshot。

Kyle [00:23:32]: 我忘了具体细节。是的，Hookshot 就在上面。那时候它叫 GitHub Services。你看到没？上面写着 Hookshot FE（前端），然后是 GitHub Services。早期的 GitHub Services，对吧？我们有一个用 Ruby 编写的仓库，你可以写任意 Ruby 代码，然后我们会代你执行这些代码作为一项服务。这样，当你尝试集成某些东西时，我们就帮你运行它。

Swyx [00:23:57]: 当然，那时还没有容器，因为

Kyle [00:23:58]: 没错，因为那是

Swyx [00:23:59]: 当然没有容器

Kyle [00:24:00]: 2014 年。当然有一些隔离机制，但主要是服务器层面的隔离。比如早期版本的 Pages，它运行在自己的容器化基础设施上，而不是基于 Actions。

Swyx [00:24:15]: 那可是永恒的经典产品。

Kyle [00:24:16]: 到现在，Pages 已经支撑了互联网的一部分。这些地方显然没有出现过类似的安全问题，据我所知。但正是这些让我意识到：“好吧，我们不能再为所有人运行任意的 Ruby 代码了。” 因此，我们现在将所有这些功能都封装进了容器中，也就是现在的 Actions。是的，容器化做得非常好。不过大多数用户并没有锁定到特定的

Swyx [00:24:48]: 镜像

Kyle [00:24:48]: Sha 之类的，比如它们的工作流程，这确实是很多人面临的一个大痛点。如果你只是像处理任何依赖管理一样，使用 V1 或最新版本、最新版，我觉得就是这样。但从那个时代“好吧，我们就运行这些任意代码，反正也没啥问题”，到现在，不，我们已经有了非常出色的容器化技术。我们有了一个全新的底层代理容器化服务，它在幕后被我们使用。这是通过 Azure 实现的。他们最近宣布了这项服务——Azure Dev Compute，但它的计算速度非常快，可以让你快速启动自己的云代理或其他东西。我们在新功能的部分中已经在幕后使用了它。

Swyx [00:25:36]: Microsoft Dev Box？

Kyle [00:25:37]: 不是，是 Dev Compute，没错。

Swyx [00:25:41]: 嗯……现在还没找到。

Kyle [00:25:44]: 哦，它就在那里某个地方。

Swyx [00:25:46]: 好吧，那我们先跳过这部分。

Kyle [00:25:47]: 抱歉。但通过 Dev Compute，你可以运行非常快速的计算，能迅速启动非常小的虚拟机，所以当你进行工具调用时，

Swyx [00:25:58]: 概念是一样的。

Kyle [00:25:58]: 就是完全容器化。所以我们正在使用这个技术，明确地朝着这个方向发展，以保护我们最终运行的每一段代码。

Swyx [00:26:07]: 看起来这已经扩展到了完整的软件开发生命周期（SDLC）？代码托管只是起点，然后它已经超越了这一点。我们来谈谈 NPM 吧，也许因为它也是行业中的一个重要议题。我认为它曾经一直在寻找归属，作为一家公司也有些挣扎，对吧？我不知道该怎么描述那次收购以及整个过程。

Kyle [00:26:33]: 当我们和团队交流时，我认为对我们双方来说最重要的事情是找到一种方式，让 NPM 继续运行下去。当时 NPM 基本上支撑着互联网，而现在更是如此。我们要确保它持续运行并不断扩展。我记得当时它确实存在一些扩展性问题，他们正在进行一些重构。

Swyx [00:27:00]: 和现在比起来，那还算轻巧。

Kyle [00:27:01]: 是的，关键在于，我现在跟人聊的时候发现，NPM 的底层用途比当初我们把它整合进 GitHub 时多了太多。但那最终的目标就是：我们过去有页面，我们拥有世界上所有的代码，我们要确保能让全世界继续良好地使用 NPM。为此，我们投入了大量的时间和资源去修复一些底层后端问题，包括我们之前提到的一些清单（manifest）工作等等。现在，我们正努力提升 NPM 的安全态势。但这确实是一个独特的挑战：我们做的每一个增强安全性的改动，都可能破坏大量用户的使用。而安全性至关重要，我们也非常重视这一点。每当 GitHub 出现问题，或者我们做出一个更安全但影响用户体验的变更时，开发者们就会遇到“雪天”——也就是必须紧急处理的重大故障。因此，我们调整了双因素认证（2FA）策略，改变了令牌的工作机制。一旦发现令牌被泄露或可能泄露，我们会立即使其失效。

Swyx [00:28:22]: 我超喜欢 GitHub 的这个功能，是的，太棒了。

Kyle [00:28:23]: 这会带来一些问题，但关键是我们试图推动社区向前发展，同时又不会破坏 NPM 上长达 15 年甚至更久的既定契约。

Swyx [00:28:43]: 我觉得——我们现在讨论的是开源和发布。我认为这里有一个趋势，人们称之为“slop forks”（冗余分叉），比如 Vercel 的 Malta 正在做的。我内心的一部分在想，要解决所有漏洞问题，或许我们应该直接抛弃 NPM 的概念，只发布源代码。每次你想引入某个库时，就由你的代码代理去查看它，然后将你实际要用的那一部分适配并打包到你的项目中。但用 AI 来做这种“vendor”（依赖包管理）是否现实？我不知道。这真的能解决我们所有的安全问题吗？我也说不准。

Kyle [00:29:24]: 我认为这并不能完全解决问题。今天 Mitchell Hashimoto 刚刚谈到了这一点，我觉得某种程度上，这其实又回到了老话题——无论是旧的还是新的，一切都在重演？是的，绝对就是把一切都 vendor 掉。我记得 2013 年、2014 年左右就有类似的情况。

Swyx [00:29:42]: 对，没错。让我们回到……

Kyle [00:29:43]: 这就是我们之前的做法——我们把所有东西都直接引入（vendoring）。我们曾经确实讨论过，或者至少我记得我们当时在问：“我们应该把整个东西都拿过来吗？”“为什么这个包这么大？我们只需要其中一个文件。”所以我认为，确实存在一个事实：要么只取你需要的部分，要么随着时间推移依赖项变得越来越小，这在一定程度上会有帮助。但我认为这并不能解决根本问题，因为从代理的角度来看漏洞，一次又一次地，有成千上万种方式可以让我们说服某个代理，某段代码是安全的或不安全的，然后将其引入。或者我们可以进行静态代码分析或运行时测试来判断代码是否正常工作。我认为，这才是需要持续投入的关键步骤。问题只是在于范围有多大：是应该引入这个庞大的项目，还是只引入其中一小部分？大多数公司都在对引入或引入的包进行某种程度的安全检查，这一点我认为不会改变。这就像高级安全工具所做的那样，Socket 也在做类似的事情。每个人都在做其中的一部分。我们各自如何去做这件事，尤其是在与企业客户沟通时，差异非常大。没有人希望只有一种统一的方式。我认为这一直是 GitHub 在世界上的独特定位。我经常和维护者们交流，也经常和很多人讨论这个问题。我们很少会主动发起某种流程或实践，然后强行推广给社区。我们通常会等待一种类似 RFC 的社会性或实际性的共识过程，等大家都达成一致后，我们才会正式确立某些东西。否则的话，我们

Swyx [00:31:35]: 这符合你在生态系统中的角色，是的。

Kyle [00:31:36]: 我们是 GitHub。是的，我们不想主导整个事情的发展方向，我们希望让社区自己去探索和定义。但问题是，如何平衡我们在行业中所扮演的角色，以尽可能确保一切安全，并确保你作为人类不会被攻破，因为通常都是这样发生的。同时又不能创建出一个流程，把自己锁定在一个无法适应、Mitchell 也无法接受、其他开源项目也不愿遵循的路径上。这一直是我们面临的棘手平衡点。我认为我们还没有充分讨论过的一点是：我们不可能为所有人提供一个所有人都喜欢的解决方案。所以我们需要你们告诉我们：什么在起作用？当 Mitchell 谈到“Upvote”和“up”时，

Swyx [00:32:22]: 我正想提到他的那个想法。是的。

Kyle [00:32:23]: 我忘了他具体说的是什么了。当他跟我们聊的时候，我跟他聊过这个话题，还把它发到了 Twitter 上，我们也通过私信交流过，他说：“我们会继续努力。”但我觉得重要的是，我真的想听到哪些地方对你来说不起作用。请尽可能具体、清晰地描述你项目的实际情况。多年来，无论是在行业内还是我们彼此认识的过程中，他一直这样做，我很感激这一点，因为有些地方确实需要改进，而我们从他那里得到反馈，就会像对待其他所有维护者一样去修复。但这种改进流程与提升安全性之间的关系，以及他所建立的机制——我忘了他怎么称呼它，不是“证明流程”，也不是“声明流程”。我刚才说的到底是什么？他和他的项目有一个机制，让你可以

Swyx [00:33:13]: 背书（vouch）

Kyle [00:33:13]: 背书（vouch），谢谢。是的，他有一个背书系统，用来表达：“嘿，你应该接受我的 PR。”这已经

Swyx [00:33:20]: 我刚把这个功能集成进 GitHub 了，我不知道。

Kyle [00:33:22]: 嗯，但问题就在这里：你说这话的时候，他和他的社区非常喜欢这个功能，然后我去和其他维护者聊天，全球各地的维护者却说：“不，这不适合我。”这就是矛盾所在，但也是 GitHub 的某种魅力所在——取决于你怎么看待它。我们希望帮助维护者，所以我们开发了各种工具，让你能更好地控制 AI 和 PR 引入的内容量。但你也完全可以使用这个项目。你可以去用这个项目，如果它流行起来并成为某种主流标准，那么我们可能不会强制推行，但我们很可能会加入支持，因为这正是我们一贯的做事方式？

Swyx [00:34:02]: 我发现很多人不知道 pull request 的历史。实际上，GitHub 基本上是标准化了这一概念。

Kyle [00:34:08]: 是的，之前这个过程非常混乱，而现在我们受益于它已经成为标准流程。现在我们需要去思考下一个最佳流程是什么，或者需要做哪些调整和变化，比如当 80% 的 PR 都来自你的代理而不是其他开发者时，pull request 应该是什么样子？

Swyx [00:34:31]: 你喜欢 Peter 提出的“prompt request”这个想法吗？

Kyle [00:34:34]: 我觉得每个想法都有其优点。我不是在回避说好或坏，但我感觉我见过一个版本，就是我们拥有完整的 Thomas 的商店，把你们构建的所有资产都放进去。我认为这个想法很棒。虽然 PR 流程有各种各样的变体，但我认为之所以没有单一答案，最终是因为我们试图将信任形式化。我们想说：“好吧，如果 Sean 审查了这个，我就相信它，因为你是 Sean，或者你是高级开发人员，或者你是某某。” 但目前，当我们处于这样的流程中——一个代理编写代码，另一个代理进行审查，然后 Kyle 再去查看时，这种信任是分散的。而我们讨论的大多数工具更多关注的是验证流程：我们有更多的资产可以查看，因此我大概能判断这是否是一个好的 PR。但这仍然没有解决我认为的人类层面的问题：当我看到一个 PR 时，我想知道我是否可以信任它。我们仍然倾向于依赖人类信号来判断，比如 Mitchell 批准了，或者 Kyle 批准了，等等。所以我认为，这就是为什么大多数选项都没有真正解决问题的原因——归根结底，这是一个社会问题，是一个人类需要参与评审并达成共识的问题。或者你完全信任某个工具，并赋予该工具全部的信任。我认为在某些情况下，这种情况确实存在。

Swyx [00:36:08]: 就像社会上终有一天会达到一个临界点，不再允许人类驾驶，因为机器在可衡量的方面比人类更优秀。我也在寻找那个临界点，对吧？比如 Mythos 现在贵得离谱，但总有一天我们会拥有桌面版的 Mythos。我不知道，这会不会改变整个局面？

Kyle [00:36:30]: 我觉得更像是这样：我坐过一次 Waymo，当时我在看手机，根本没有观察周围环境。还有其他自动驾驶车辆，即使我盯着道路，我也不会信任它们。我认为这种信任是一种

Swyx [00:36:48]: 这是 Zoox 吗？是什么？

Kyle [00:36:50]: 我觉得两者都有。我觉得两者都有。就像

Swyx [00:36:53]: 这辆机器人出租车里有 Zoox。就是它。它是

Kyle [00:36:56]: 嗯，这取决于自动驾驶的等级。但我的重点是，我认为这其中一部分是：我强烈相信，信任是可验证证据和人类感受的混合体。比如有多少事故、多少数据等，以及当我坐在车里的时候，我的感受如何，它向我传达了什么信息等等。因此，我认为一些 AI 工具之所以让我更有信任感，是因为即使数据显示它是 100% 准确的，我还是会花更长时间去思考：“我应该信任这个吗？” 这种“软性”的信任体现在初创公司、高自主性的项目、周末项目和开源项目中。而对于企业、受监管行业以及其他领域来说，这个问题更加困难，因为即使完全验证了，你不仅需要团队成员的信任，可能还需要跨国公司、全球多个国家政府以及监管机构的信任。

Swyx [00:37:55]: 天啊

Kyle [00:37:55]: 多国政府和监管机构的信任。因此，我认为直到我们达到你所说的那种“人类情商”层面的临界点——即我感觉“这感觉不错，我已经得到了足够的证明”——事情才会开始加速推进，我们才能真正到达“好吧，我们可以信任这个了”，并在最困难的情况下也感到安心。

Swyx [00:38:18]: 如果人类信任才是关键，我觉得 GitHub 作为开发者社交网络，或许可以在这方面做得更多。比如“凭证”是一个系统，但我们还有星标数量，以及贡献者权限，仅此而已。我觉得这个领域还应该有更多内容。我不知道是否有其他设计上的选择。

Kyle [00:38:37]: 我认为目前我们还没有充分暴露的一个方面是某种程度上的“硬信任”和“支持”。对我来说，赞助就是一个很好的例子。

Swyx [00:38:49]: 啊。

Kyle [00:38:49]: 它对你来说是有成本的。通过支付费用来证明我相信你的项目，某种程度上信任你，或者至少我希望支持你。

Swyx [00:38:56]: 解决开源项目的支付问题，为什么不呢？

Kyle [00:38:58]: 我觉得，随着我们不断前进，越来越多的项目让我愿意个人投入更多资金去支持它们。我之所以这么做，是因为我想支持他们，尽管我可能从未与他们见过面，但我了解他们的工作成果，所以想给予支持。我认为我不喜欢“星标”（stars）、提交次数（commit counts）或其他类似指标的原因在于：即使我们做了各种反滥用、去垃圾信息和去重的工作，这些指标终究都不是活跃的社会信号，而是被动的、可以被游戏化的指标。你或许信任我，但另一位开源维护者可能不会。那么，你依据什么启发式规则来判断是否该信任我呢？我认为这正是我们目前思考的核心问题：对我来说，哪个信号对你来说才是最重要的？——如果你能诚实地在代理式工作流（agentic workflow）中定义这一点，那正是我们看到的一些开源项目正在做的：比如使用 GitHub Actions，再结合一个调用 AI 的代理式工作流，并设定规则。例如：“如果 Kyle 在某个项目中提交并获得了合并的 PR，且他的 GitHub 账户关联了一个社交账号，而这个社交账号存在时间超过一定期限。” 这些非常复杂的衡量标准对你而言很重要，因为大多数开源项目其实已经在脑海中内置了这类启发式规则，哪怕没有写进贡献指南里。你可以把这种规则提取出来，然后应用到实际中，直接说：“哦，我们不接受这个 PR。” 构建一种能够适应每个人需求的灵活机制，比简单地说“嗯，这个账户太年轻了”要好得多。因为一旦这样，攻击者就会创建大量账户，等待它们“老化”。需要达到一定的星标数量？这就是星标膨胀（star inflation）的成因。需要拥有一定数量的仓库？

Swyx [00:40:46]: 天啊，是的。

Kyle [00:40:47]: 再加上 PR。他们互相创建仓库，互相提交 PR，然后进来干点坏事。所以很难找到合适的衡量标准。因此我认为，我们更应该关注如何提供工具，让你自己选择最适合你的方案。当然我们会提供一些默认标准，但信任的本质最终会归结为某种形式的人类数字身份（human digital ID），就像大家一直在讨论的那样——我该如何证明“是我”？

Swyx [00:41:13]: 把你的眼睛给我。

Kyle [00:41:14]: 在互联网上，把眼睛给我。没错。

Swyx [00:41:18]: 我得继续下一个话题了，但显然我可以就此聊一整天，因为我整个职业生涯都与 GitHub 和开源相关。星标？太表面了，大家都知道。但我发现，达到十万星标的最快速度是我见过最快的——有些人几个月就做到了。但与此同时，我根本不信任它。这些星标中有多少是真实的？有多少是机器人或别的什么？我不知道该怎么问，但我们能做些什么？比如……

Kyle [00:41:49]: 只是

Swyx [00:41:49]: 星标是不是已经坏了？还是说它还行？

Kyle [00:41:51]: 我觉得有两个层面。很明显，我们一直在努力寻找用户制造垃圾内容的方式，比如只进行“星标游戏化”的行为。一旦发现，我们就将其清除。

Swyx [00:42:08]: 但这就像打地鼠一样。

Kyle [00:42:10]: 完全就是打地鼠游戏。

Swyx [00:42:11]: 没办法。

Kyle [00:42:11]: 现在还有 AI 加持，情况更复杂了。但我觉得更重要的问题是，很多“最快达到 X”的现象，是因为我们现在邀请了更多人加入 GitHub 上的软件开发。整个时代的氛围就是“蜂拥而至”，而且

Swyx [00:42:32]: 不只是开发者了。

Kyle [00:42:33]: 并不只是你和我。无论你怎么定义“开发者”，它不再仅仅是那些长期编程的人。还包括那些刚刚开始写代码，或者是在 AI 时代才加入进来的人。现在

Swyx [00:42:44]: 最新的 Octoverse 数据是多少？我记得上次提到 GitHub 上有八千万开发者。

Kyle [00:42:50]: 哦，现在已经超过两亿了。

Swyx [00:42:53]: 好的，那你看到了吗？

Kyle [00:42:55]: 是的，现在已经有超过两亿开发者了。

Swyx [00:42:56]: 但其实不是“开发者”，对吧？是拥有 GitHub 账号的人。

Kyle [00:43:00]: 所以，这正是目前 GitHub 内部最常争论的话题。从我的角度来看，专业企业级开发者和普通开发者之间确实存在区别。但我认为，在软件开发早期阶段，我们花太多时间去区分“开发者”的细分类型，其实是不值得的。

Swyx [00:43:29]: 一旦涉及门槛设置

Kyle [00:43:31]: 100% 是。

Swyx [00:43:31]: 那么，谁才算开发者？

Kyle [00:43:31]: 100% 是。因为我刚开始写代码的时候，根本不算开发者。我那时只是想……

Swyx [00:43:36]: 哦，不，我七年前就在学编程之前克隆过一个项目。后来我写了关于自己学习编程的经历，结果有人说我是个骗子，因为我有 GitHub 账号。我说：“不，我只是用 GitHub，但我并不懂……” “我根本不知道自己在做什么。”

Kyle [00:43:49]: 我记得那件事。我记得那些帖子，而且说实话，那完全是胡扯。所以我非常明确地站在一个立场上：如果你写代码，如果你有一个想法并把它变成某种可以运行和使用的应用，那么你当时可能仍然使用了 AI，但这没关系。但总有一天你会做下一步。你会创建一个大型项目——你将不得不学习这个数据库，修复某个 bug，诸如此类。我们所有人都在同一条路上前行，而这些人也在听说最新的代理技能包、新的 CLI 工具或任何新东西。这些项目的数量在上升，是因为你想成为这个时代的参与者，就像我当初刚成为开发者时，想加入 Ruby 社区一样，那时 Ruby 正在爆发式增长，而现在我只需要点击一下星标按钮就行了。所以我认为，是的，确实存在一些垃圾信息和游戏化行为，我们需要应对，但我真的认为我们正看到一批全新的用户群体，他们从一种技术转向另一种技术，因为他们并不是在维护一个 20 年历史的软件应用。他们是在周末为朋友或自己的新点子开发了一个小应用。正是这种现象导致了那些星星数激增的图表不断向右上方攀升。

Swyx [00:44:59]: 我觉得令人惊叹的是 GitHub 对这些用户的持续包容性。通常当一个平台进入新用户群体时，它们往往需要创建一个带有不同名称的“第二平台”来包装主平台。但不知怎么的，GitHub 却能够持续扩展，并且保持友好和易用。这真的很棒。

Kyle [00:45:19]: 这也是为什么我认为，当我们尝试涉足更像低代码这类领域时，会遇到这样的情况。我们开始做 Spark，就是作为一种快速构建并运行应用的方式。但现实是，无论我们试图在上面加多少层封装，只要我们做了封装，我们依然会把代码展示给你看。这几乎成了我们的基本原则：我们永远不会隐藏代码，因为

Swyx [00:45:52]: 为什么要隐藏呢？

Kyle [00:45:52]: 对啊，这就是重点所在。不过，我认为通过像 Spark 这样的工具，我们学到的一点是：对大多数开发者而言，Spark 的真正价值在于它提供了简单的运行环境。你可能会用某个运行时或托管服务来部署，或者直接自己构建然后运行。但这种让过程变得更简单的打包方式，对于那些真正想构建软件的人而言其实并不必要——他们不只是想做一个“应用”，目标略有不同。因此，我想让你进来，让你感到舒适。对我来说，作为一个并非传统意义上进入软件开发领域的人，我希望任何人都能跨越那道鸿沟，不再畏惧。我觉得我们现在仍处于一个“STEM”的时代。我有两个孩子，一个 12 岁，一个 8 岁，他们总是被反复提醒：“我们要让他们进入 STEM 领域。” 我也做着所有好父母该做的事情，比如：“哦，你想学编程？” “是的，我想学编程。” 就报编程课。但如今，他们已经不再害怕做软件了。我认为，正是这一点让我长久地留在 GitHub。每个人都应该有能力去构建一个东西，就像我可以轻松更换家里的电灯开关一样。我不会去打开配电箱，因为我可能会把自己电死。但我可以换掉那个灯开关。每个人都应该能说：“这个该死的应用不能按我的意愿工作，我希望它这样运行。” 我觉得，正是这种理念让我们多年来一直与 GitHub 紧密相连，无论是顺境还是逆境，因为我们始终相信：GitHub 是所有开发者的家园，我们希望每个人都能拥有那种感觉——有了一个想法，我把它实现了，天哪，它真的出现了。

Swyx [00:47:37]: 好的，接下来我要问些更有挑战性的问题。

Kyle [00:47:42]: 很好。

Swyx [00:47:42]: 现在是容易的时期，还是艰难的时期？

Kyle [00:47:45]: 哦，在 GitHub？这是艰难的时期。当然，是艰难的时期，但与此同时，我刚刚和团队聊过，我说：“这也是我记忆中 GitHub 最棒、最激动人心的时刻。” 因为

Swyx [00:47:57]: 最好的时代，最坏的时代。从来都不是单一的。

Kyle [00:47:59]: 因为我们一直在讨论 Octoverse 报告。通常我们每年发布一次 Octoverse 报告，查看数据后我们会说：“天哪！” 上个月我在 Universe 大会上就说：“这是我们在历史上增长最快的一年。” 而现在，我们一个月内完成的工作量，已经超过了去年一整年的总量。

Swyx [00:48:20]: 你说的是 PR 吗？

Kyle [00:48:21]: 提交（commits）。

Swyx [00:48:21]: 提交，对。

Kyle [00:48:22]: PRs。基本上，几乎所有我们衡量的指标都显示出了远超以往的增长幅度，而且这种增长正在以全新的方式打破我们的系统，而不是旧的方式。比如，webhooks 多年来一直以不可靠著称？

Swyx [00:48:38]: 这是谁的错？

Kyle [00:48:39]: 不再是我的了，但有一段时间，我确信你能找到一条推文，上面写着“是我干的，我很抱歉。”不过现在，这个问题已经在大规模层面被重写，系统至今仍在稳定运行，没有出现故障。我们现在发现的问题不仅仅是那些人们偶尔在 Twitter 或互联网上提到的简单问题，比如“嘿，为什么是这样？”当然，确实存在一些本不该存在的愚蠢问题。但如今我们面对的是更复杂、新颖的权限问题，这些问题只会在跨所有不同对象或系统的超大规模场景下才会发生，以至于我们现在必须重写底层系统。确实，有些问题让我们措手不及，正如我之前所说。增长速度是惊人的，但我们也在取得实质性的进展。一旦我们重新构想并重构了底层基础架构，或者至少是其中的部分组件，我就非常期待未来能实现什么。因为这不再只是我们自己，还有所有新加入的开发者、他们的代理程序以及各种工具协同工作所能带来的可能性。因为这些协作仍会发生在 GitHub 工具和社区中。但只要我们无法满足你的需求，那就是艰难的一天。我们内部也面临同样的问题。我们通过 github.com 运营，当然，当系统出现问题时，我们也拥有备份机制来保障自身运营，但我们同样会感受到影响。如果系统不工作，对我们来说它就是不工作的，这正是 GitHub 实践“狗粮”（dogfooding）理念的承诺所在——这一点一直如此。我们使用的是和你一样的工具，而不是某个超级秘密版本。因此，我们不仅需要它对我们的客户好，也需要它对开源社区好。而现在，代理程序的数量呈指数级增长，它们也在推动这一趋势。

Swyx [00:50:32]: 我想为那些可能没看过你推文的音频听众做个补充说明。25 年前，GitHub 达到了十亿次提交。现在，每周的提交量已达 2.75 亿次，如果增长保持线性，今年将有望达到 140 亿次。这个速度还维持吗？我不知道，但这已经持续了一段时间。

Kyle [00:50:48]: 是的，它还在加速。

Swyx [00:50:50]: 大致如此。

Kyle [00:50:50]: 它仍在持续加速。

Swyx [00:50:51]: 现在是四月，所以没错。

Kyle [00:50:51]: 没错，这是四月份的数据。

Swyx [00:50:53]: 好的，所以基本上你们实现了每年 14 倍的增长，对吧？我认为这是一个典型的扩展性问题。我想尝试认真地分析一下这个问题：很多人经历过 14 倍的增长，但他们并没有像你们一样遭遇宕机。这很关键——我们能不能深入探讨一下？为什么会这样？具体是什么地方出了问题？我们正在采取哪些措施来修复？任何能让社区安心的信息都可以。

Kyle [00:51:18]: 所以，正如我之前说的，我们在多个方面看到了增长带来的挑战。其中一些增长问题，也是我提到要大力增加 CPU 资源的原因，尤其是在 Actions 方面。更多的工具、更多的代理程序、更多的 PR 意味着更多的构建任务，而更多的构建任务又意味着需要更多的 CPU。因此，我们正在通过数据中心扩展资源，同时显然也在讨论迁移到 Azure，并引入额外的云计算能力，因为我们单纯就需要更多 CPU。GPU 的需求虽然也有，但目前不如 CPU 那么紧迫。我们当然也需要 GPU，但现阶段 CPU 成为了瓶颈。

Swyx [00:51:53]: 确实非常依赖 CPU。

Kyle [00:51:54]: 在底层服务方面，多年来我们一直在拆分数据库基础设施，以便让各个服务之间有更清晰的认知隔离。然而，我们持续遇到困难的地方在于权限系统。目前，我们许多权限层都依赖于一个内部称为 MySQL One 的数据库，熟悉 GitHub 历史的老用户应该知道我在说什么。多年来，我们一直在从 MySQL One 中剥离功能模块，因为我们使用 Vitess 和其他技术进行分片处理，并将其作为一个整体进行管理。

Swyx [00:52:31]: 这件事很有名，PlanetScale 就是从这里诞生的。

Kyle [00:52:32]: 完全正确。Sam 是一位老 Hubber，也是我的朋友。因此，我们不断寻找机会将这些模块解耦，并在全球范围内部署。另一个有趣且独特但也颇具挑战性的地方是，我们还将上述所有内容打包成一个黑盒容器，供使用 GitHub Enterprise Server 的本地部署用户运行。这意味着我们要把刚才说的所有内容，不仅在公有云上运行，还要在本地环境运行，甚至还要为需要数据驻留（data residence）的客户提供支持，即要求数据存储在单一地理位置。每一个场景都有其独特的数据存储方式，无论是 MySQL 还是权限配置。正是这些差异导致了一些中断事件的发生，而且这些故障往往不是局限于某一个组件，而是广泛影响整个系统。

Swyx [00:53:17]: 数据库正在被填满。

Kyle [00:53:17]: 还不太行。没错。部分原因就在于此。我认为，过去几年里，业界的很多项目似乎正在转向单体仓库（monorepo），而我们之前的方向正好相反。过去仓库更小，但数量更多；而现在我们看到的情况恰恰相反：仓库变大了，虽然仓库总数未必减少——因为有新的增长——但我们确实看到了越来越多的大仓库。大型仓库、尤其是大型单体仓库一直存在一个独特的性能问题。因为每个仓库都略有不同，特别是当仓库内部的文件块（blobs）非常庞大时。为此，我们做了大量工作，这些改进可能大多数人都没有亲身体验过，除非你正处在单体仓库的场景中。但 Git 基础设施层的这些优化确实有助于整个系统的提升，因为许多让单体仓库运行得更好的改进，同样也提升了所有仓库基础设施的性能。我可以继续列举其他类似的例子，比如我们正在改变任务队列（job queuing）的方式——我暂且用这个说法来解释——也就是在底层技术上进行重构。

Swyx [00:54:32]: 我曾经花了两年时间专门做任务队列相关的工作，所以……

Kyle [00:54:34]: 所以这其实是一个逐步演进的过程，主要原因是我们当初构建系统时，假设了工作流管道的容量保持不变，只是通过这些管道的人会越来越多。但如今情况变了，在某些地方，比如一次 git push 的大小，过去通常在一个特定范围内，现在已不再成立。

Swyx [00:55:03]: 哦，是的。

Kyle [00:55:03]: 或者

Swyx [00:55:05]: 我每天推送上千行代码的提交

Kyle [00:55:06]: 平均来说，100% 是这样

Swyx [00:55:06]: 每天都有上千行的提交

Kyle [00:55:07]: 合并请求（PRs）也是同样的情况。我们讨论过如何优化这些流程，并做出了一些调整，但有些技术选型并不奏效，导致系统变慢，无法满足用户需求。因此，我们一直在重新审视这些问题，意识到“好吧，这显然不对，不能再把钱浪费在错误的方案上了，现在必须用正确的方式来做。” 所以，这涉及很多方面。回顾我在 GitHub 历史上经历过的规模扩展，几乎总是两种选择：垂直扩展，尤其是数据库方面；或者水平扩展。比如，当更多人开始使用某个服务时，我们就增加服务器，把它们部署在数据中心或云上。而现在，我们处于一种“对角线”状态：垂直扩展已经不再有效，水平扩展也不再适用，因为我们现在都面临 CPU 或 GPU 资源的限制。于是，我们不得不深入那些已经运行了 10 到 15 年的服务，打开它们并说：“好吧，这个服务的规则已经真正发生了变化，现在我们需要重写它。” 这些都不是借口。我们必须要做这些工作，必须让它变得更好。

Swyx [00:56:22]: 实际上作为一名基础设施工程师，我觉得“这是我见过的最有趣的扩展挑战之一。”

Kyle [00:56:26]: 正是如此。这就是难点所在。当我们没有公开谈论这些问题时，我曾想站出来解释一下发生了什么。这部分源于 GitHub 很早以前的一种理念：我们的服务是否正常运行，直接关系到用户的体验。我知道你是开发者，所以你自然希望了解背后发生了什么。但与此同时，当我们说“嘿，这个服务没有按预期表现，我们现在必须去修改它”，我们并不是想隐瞒任何事情。而是因为——这是我们的责任，因为你期望我们始终在线，而我认为这一点早已深深植根于 GitHub 的核心起源之中。现在，我们团队试图做的就是完成所有这些工作，并更加透明地与大家沟通，分享更多的技术细节，撰写博客文章，发布更新，让参与建设的工程师在完成工作后，直接告诉大家：“这是我们在做什么。” 我认为，这才是我们希望回归社区的承诺：我们依然非常认真对待自己的使命，只是过去没有逐一告诉你每一步进展。现在让我们一起做到这一点，并持续构建和扩展系统，以支持未来的发展——无论是 14 倍、30 倍还是 50 倍，甚至是下一个指数级增长。

Swyx [00:57:40]: 首先，这是一个极好的回答。我认为

Kyle [00:57:44]: 如果以上内容有任何不准确之处，我提前道歉。

Swyx [00:57:47]: 我觉得一切都很好。

Kyle [00:57:47]: 只是因为我还在深入研究这些细节，但这不是我的日常职责。不过，关键在于，我们所有人都在从这个层面去审视问题。

Swyx [00:57:58]: 当然，如果有人愿意帮忙，他们也可以加入进来。

Kyle [00:58:00]: 绝对欢迎。

Swyx [00:58:01]: 所以我认为这很好。但我相信人们也想知道：你们什么时候能度过最艰难的阶段？我们是否已经识别出所有问题？这会不会永无止境？Git 是否已经坏了？我们是否需要修改 Git 协议？到底有多少东西需要被打破？已经过去一段时间了，所以我认为大家真的想知道：我们该如何恢复到每个人都期待的那种 GitHub 的可靠性？

Kyle [00:58:30]: 所以最近几周我们的可用性比之前三周、再之前的三周等等都要好得多。这些改进带来的好处对我们来说仍然非常明显。我认为我们仍在处理我提到的那个数据库部分，这需要一点时间来修复，因为我们需要……

Swyx [00:58:59]: 我脑子里想到的答案是：打电话给 YouTube。

Kyle [00:59:03]: 所以最终 YouTube 是……

Swyx [00:59:04]: 因为他们也使用 Vitess。

Kyle [00:59:05]: 他们确实也在用 Vitess。但是，

Swyx [00:59:09]: 就像那个在 YouTube 负责扩展的家伙？

Kyle [00:59:11]: 嗯，我相信他后来去了 PlanetScale，并且也是 PlanetScale 的一员。但就像……

Swyx [00:59:16]: 哦，你是说 Sugo？

Kyle [00:59:17]: 我觉得是的。没错。所以，因此……

Swyx [00:59:19]: 他现在在 Superbase。

Kyle [00:59:20]: 啊。

Swyx [00:59:21]: 那里还有一整套关于 Postgres 的戏剧性事件，对吧？

Kyle [00:59:25]: 有些情况确实是这样。我认为另一部分原因是，我们正在推进获取更多计算资源的计划，这将显著缓解当前的问题，尤其是在 Actions 方面，因为很多底层故障实际上都与之相关。

Swyx [00:59:39]: 我告诉你，Actions 就是万恶之源。

Kyle [00:59:42]: 它当然也有优点。

Swyx [00:59:47]: 在某种程度上。

Kyle [00:59:47]: 毕竟它是 CI、侧项目等的核心计算层。

Swyx [00:59:52]: 是主要收入来源吗？比如……

Kyle [00:59:54]: Actions？

Swyx [00:59:55]: 不是？我不知道。

Kyle [00:59:56]: 像 Actions 这样的……

Swyx [00:59:57]: 我花了很多钱在计算资源上，对吧？

Kyle [00:59:58]: 像 Actions 确实是整体业务的重要组成部分，但我认为我们最终也……

Swyx [01:00:06]: 存储？

Kyle [01:00:07]: 我们通过权益免费赠送了大量分钟数。但这就是我之前说的，每个人都在用它。我们通常称之为 CI/CD，但现实是人们不仅用它做 CI/CD，还用于

Swyx [01:00:17]: 自动化。

Kyle [01:00:17]: 各种处理和自动化，完全正确。因此，这也包括计算资源方面的优化，这部分也在改善我们的可用性。

Swyx [01:00:26]: 这是我对 Actions 的滥用。我一直……

Kyle [01:00:29]: 哦，是的。

Swyx [01:00:29]: 我每天都在抓取数据，然后我就告诉别人去……

Kyle [01:00:34]: 谢谢你的服务。

Swyx [01:00:35]: 去狗吧，因为我……但这也是我追踪 Actions 全部历史数据的方式。不管怎样，

Kyle [01:00:41]: 所以一部分原因就是这个。我认为未来三个月里，每个月你都会看到我们出现可用性问题的次数越来越少，系统崩溃的情况也会越来越少。这不仅仅是停止了增长，而是我们依然保持着前所未有的快速增长速度。只是那些我们一直在努力改进的基础架构，终于开始见效了。这些改进不是那种“小改动带来大产出”的增量式提升，而是需要一定时间才能显现效果的实质性变化，之后我们会看到可用性的阶梯式跃升。

Swyx [01:01:14]: 我们以前在亚马逊做过一件事，我不知道这是否常见，比如自动化的软件验证或负载测试模拟之类的。我现在感觉，你已经拥有了整个 GitHub 的完整地图。你可以假设任何维度的增长率，然后直接运行系统进行推演，对吧？我觉得应该有一种方式，比如建立一个 GitHub 的系统模型，看看哪些地方会出问题。但显然，我只是个旁观者，离实际问题太远了。

Kyle [01:01:39]: 但没错，完全正确。我认为从十一月到现在，我们一直在走这条路并持续投入工作。因为十月的时候，我们甚至还在说：“哇，看这增长！”然后你开始看到图表

Swyx [01:01:53]: 它并没有

Kyle [01:01:53]: 真正地爬升起来。哦，我们之前只在 N 规模下测试过，现在可能已经达到了 N 的立方级，至少在某些维度上是这样。所以我们现在必须重新构建系统，确保它能承受这样的规模。

Swyx [01:02:08]: 让我们聊聊 Copilot 吧。最初创建 Copilot 的人有多少？

Kyle [01:02:15]: 哎呀。

Swyx [01:02:18]: 因为我数了一下，有十二个认证成员。

Kyle [01:02:19]: 我们没有……是的，开玩笑归玩笑，我忘了最初 GitHub Copilot 团队到底有多少人。不过，当时团队规模其实更大。

Swyx [01:02:30]: 我听说是 Alex，还有三个人。

Kyle [01:02:32]: Alex 参与了开发，Udo 也参与了，还有很多其他人在团队里。

Swyx [01:02:35]: 然后还有他们整个管理层。好吧，所以在当时取得了巨大的成功。我记得最后一个数字，Mario 来参加我的会议时提到了一亿美元的里程碑。最近好像是三亿美元。我也可能已经过时了。

Kyle [01:02:53]: 我不记得我们公开分享过具体金额。

Swyx [01:02:54]: 好的，没问题。那现在 Copilot 的状态如何？它作为一个概念已经被微软更广泛地采纳了。但在 GitHub 内部呢？

Kyle [01:03:03]: 所以我认为，我们当初在推出 Copilot 时面临的一个挑战是，我们一开始直接推出了代码补全功能，效果非常出色、强大等等。之后大约一年半的时间里，我们主要致力于模型微调的工作，因为我们的客户以及整个行业都在讨论：“我们该如何进一步提升准确性和性能？”因此，我们投入大量精力进行微调，包括在更大规模的代码补全、下一条编辑建议等方面进行优化。

Swyx [01:03:43]: 让我澄清一下：你们是针对一个模型进行微调，还是为每个客户单独微调一个模型？

Kyle [01:03:48]: 每个客户——嗯，两者都有。一方面是对整体使用场景进行统一模型的微调，另一方面也支持希望将此作为服务使用的客户进行个性化微调。就在那个时候，新一代模型出现了，也正是同一时期，各种其他 AI 编程工具相继涌现，因为模型的速度大幅提升。于是大家都会问：“GitHub Copilot 发生了什么？这么长时间过去了。” 我想说的是，当时我们正处在一个阶段：我们想提升每个人的使用效果，因此专注于微调，因为它能带来更好的结果。然后模型本身也变得更好了。从那以后，我们就一直在探索这样一个方向：当然，我们拥有出色的代码补全功能，并且在底层模型上投入巨大，通过后训练（post-training）优化了更先进的模型，比如语言特定的模型，来提供更优的后续建议。所有这些功能都融合在 GitHub Copilot 的“无形”之中，但如今我们已经构建了一个统一的底层 SDK 和框架，用于支持我们的编程代理（coding agent）Copilot。新的 CLI、新的桌面应用、云代理都共享同一个 SDK。因此，我们经历了一个关键节点：既要弄清楚客户真正需要什么，又要通过分析和洞察（Sherlocking）来理解需求，然后提出问题：“最终用户到底需要什么？” 我们认为，这不仅仅是关于代码生成的问题，而是关于如何利用这些具备编程代理能力的运行时或框架，在更广泛的场景中发挥作用——不仅限于编码体验，比如我可以分发一系列任务，或者用 Fleet 将单个任务拆解，又或者像 Goal 那样的自动驾驶模式。同时，我们也在思考：如何将这种能力应用于安全修复？如何对每一个进入 GitHub 的 Issue 都自动部署一个编程代理，看看是否可以解决？如何遍历我的仓库，检查所有文档并提取出不一致的地方？这种程度的 AI 编程代理自动化，我认为是我们当前看到的重要趋势。当我们审视现状时，会发现我们仍然处于类似但又截然不同的流程中，只是所有事情都在同时发生。不再像过去那样，我会创建一个 Issue 来跟踪我的想法。你可能直接就会说：“去做吧。”

Swyx [01:06:22]: 直接去做。

Kyle [01:06:22]: 你会说：“嘿，直接把它建出来就行。” 对吧？尽管现在仍有很多开放的 Issue 和项目，比如 Peter 使用 OpenClaw 这类工具，把他的代理全部投向这些问题。这种基础设施层，加上一个极佳的编码体验，能够处理多路复用（multiplexing）等复杂场景，正是我们通过 GitHub Copilot 所构建并仍在持续建设的内容。因此，对于那些很久没有使用 GitHub Copilot 的人来说，尤其是那些曾经被它吸引的人——我完全理解这一点。我强烈建议你们去看看最新的 GitHub Copilot 应用程序。那是我现在每天都在用的工具。当然，如果你更喜欢 CLI，我们也提供了 CLI 版本，同样可以访问所有模型，支持“自带密钥”（bring your own key）的方式。我们仍在不断改进自己的模型，并且也在使用它们。这整个体验与之前完全不同，但我认为，从更广泛的角度来看，软件开发的本质以及编程代理在整个流程中的作用，已经超越了仅仅写代码，甚至不只是验证或部署代码。这正是我们所拥有的独特视角。另一个关键方面是上下文能力。

Swyx [01:07:44]: 哦，天哪。

Kyle [01:07:44]: 我们还在努力。这就像一件事：我认为，最终让我在 GitHub 上感到圆满的，是当 GitHub 能够按照 Kyle 的方式运行，或者 Shawn 的方式，或者其他任何人的方式运行。我们将这些行为规则化、记忆化，整合到系统中，但……

Swyx [01:08:03]: 嗯，这其实是一个开放的研究问题，对吧？就像……

Kyle [01:08:05]: 完全正确。百分之百。

Swyx [01:08:07]: 等你实现了，那就是 AGI 了。是的。

Kyle [01:08:07]: 百分之百。但即使我们能做到这样——让我的团队无需我手动定义所有规则，就能随着方法论的自然演进，获得完整的体验，并全面理解我依赖项或开源项目中正在发生的事情——这也已经是一个巨大的进步，让我们能够继续通过 GitHub Copilot 提供真正独特且有价值的东西。

Swyx [01:08:29]: 是否还有我们尚未探索的形式？我觉得我们先是做了代码补全，然后是广义上的“代理式 IDE”，比如 Cursor 最近非常流行地推广了这一概念。现在，焦点转向了代理编排、后台代理等等。还有安全审查，感觉每个人都在把代理扔向一切。整个 SDLC（软件开发生命周期）都被代理覆盖了。我们是不是已经到达了历史的终点？接下来是不是就只剩下微调和优化了？

Kyle [01:09:04]: 我觉得我们目前仍处于人工智能的“高度近视”时代。现实情况是，出于各种无聊的安全和治理原因，至少对大多数人的工作而言，为什么我的编码代理（即使它只是后台运行的代理）无法保留我在编程之外所有活动中所能获取的上下文信息？对我来说，AI中最有趣的部分其实是真正的环境式AI（ambient AI），而不是某个助手名称之类的东西。我几乎尝试了所有工具中的每一个功能，但它们都没有按照我希望的方式工作，因为它们只是试图捕捉、编码化并回忆信息。而我真正想要的是——回到最初的想法——当我正在构建下一个版本的 webhook 或实现一个新功能时，它能了解每一份规格文档、每一封邮件、我在线上的每一次对话，以及关于这个功能如何实现的所有相关信息，并能够将这些信息作为其决策过程的一部分。但目前没有任何工具能做到这一点。因此我认为，这就好像软件开发工作是一个单线程任务，只需要一个开发者就够了。一旦我写出完美的代码，我们就完成了。但事实从来都不是这样。真正重要的是团队其他成员的背景、公司当前在做什么、现在流行什么等等。我认为，这正是我们超越单纯优秀的编码代理的巨大机会。而这正是我认为 OpenClaw 如此有趣的原因：没错，它连接了 Kyle 这个人所关心的所有数据源，现在我的问题是：“好吧，我该如何利用这些信息，每天作为一个软件开发者持续地整合使用，而不仅仅是提供一种启动编码代理的新方式？”这就是我们现在所处的位置。我们说：“好吧，我会在底层使用这个 CLI 或这个 SDK。”但这并不是我所说的重点。我指的是，当我跟你聊天时，它会自动下载播客，然后意识到：“哦，Kyle 看起来需要这个应用或这个东西……”这种级别的

Swyx [01:11:16]: 它直接推荐给你。

Kyle [01:11:16]: 就是这种程度的连接性，我认为我们在软件领域还有很长的路要走。因为当我们拥有这条“红色线索”可以拉出来的时候，这个想法不仅能用最完美的方式写出代码，还能结合我或我们团队所积累的所有品味、判断力和专业知识，并将其融入实际的实现过程中。

Swyx [01:11:42]: 极端情况下，就是 AI 在替你管理生活，对吧？我觉得这里存在一种令人不安的控制反转，就像我实际上正在以开发者理解框架的方式去做这件事——比如好莱坞原则：“别打电话给我，我会打电话给你。”也就是说，在某个时刻会出现控制权的反转：你不应该再告诉 AI 该做什么，而是 AI 告诉你该做什么。这有点吓人，但也可能更好。

Kyle [01:12:10]: 就像 Nat 一样，我记得 Nat Friedman 在一次 Stripe 活动上分享过他的 OpenClaw 经验，他把 OpenClaw 连接到自己的摄像头，让它观察自己。

Swyx [01:12:20]: 它还重定向了他的 Uber 路线。而且，

Kyle [01:12:23]: 在某种程度上，我其实很希望 OpenClaw 能提醒我喝水。我不知道是否想让它改变我的车的行驶路线，但我认为这正是我想表达的意思：它需要掌握更多可用的信息，才能真正对我有所帮助。我仍然不认为我们已经接近讨论通用人工智能（AGI）的程度。我只是在说，每次我不得不告诉你一些我关心的事情——哪怕是我之前说过一次或十次的事——它都应该能知道、编码化或访问到这些信息。像“梦想中的想法”这类项目，是在尝试做某种类似的事情，但我认为如果我们能更进一步测试，一个更加主动的角度将对软件开发者带来更大的帮助。

Swyx [01:13:05]: 是的。另外让我想到的一点是，OpenClaw 让我联想到微软竟然专门为此设立了一个 CVP（首席产品官）。为什么？

Kyle [01:13:16]: 因为你觉得他们不该这么做吗？

Swyx [01:13:17]: 不，我不确定。我觉得 CVP 是个很高的职位。为什么这件事这么重要？微软甚至都不拥有 OpenClaw。到底是什么，到底是什么……

Kyle [01:13:29]: 所以——今年的 Microsoft Build 大会上我们也谈了很多这方面的话题。我认为，OpenClaw 做到的关键一点是，它为人们建立了一种连接，使他们能够访问你所拥有的资源，并以一种过去人们试图通过自己构建代理来实现的方式为你做事。当你从工作场景的角度去思考时，如果有一个类似 Claw 的对象，我可以直接在我的工作设备上运行它，或者让它访问我的工作资产，并且在 Windows 上运行良好，那该有多好。因此，我认为 OpenClaw 已经成为了一个具有价值的代理的化身，因为它能理解我，因为它可以访问我所有的信息，并且能够使用计算机。因此，它所能做的事情远超一个仅专注于任务的流程或像聊天工具这样的简单应用。这不正是 Build 大会的目标之一吗？今年我们在 Build 上尝试采取一种截然不同的方式：毫不掩饰地面向开发者。我们试图展示更深层次的投资，而不仅仅是说：“嘿，”就像你说的，“为什么你们要设立 OpenClaw 的首席产品官？”原因很简单：我们面临的一个问题是，我们的代理如果不在 Mac Mini 或托管设备上安装，而是安装在个人设备或工作设备上，那么我们需要在操作系统层面实现更好的沙箱机制。我需要能够使用这个 Claw，而不会因此被开除。于是微软说：“好的，那我们也来做这件事吧。”接着又问：“那我应该在哪里与这个代理进行交互呢？我们每个人是否都应该在工作中拥有一个可用的 Claw？很可能。”就这样，事情就顺理成章了。此外，微软也在持续为开源项目做出大量贡献。据我了解，随着获取的信息越来越多，我发现微软在开源项目本身上的投入非常巨大，但出于某种原因，这些团队似乎并不想因此获得任何赞誉或认可。然而，许多核心贡献者或团队都是全职投入到开源项目中的。我认为这一点恰恰体现了差异所在：为什么我们要如此重视像 Claw 这样的东西？为什么我们要关注 Windows 上的沙箱技术？为什么我们要研究云环境下的沙箱方案？为什么我们要深入探索这些问题？因为最终，我们需要更多平台级组件。我们不需要每个人都去构建完全相同的顶级产品。如果我们是为开发者服务，那就要求我们提供所有这些组件，并告诉你们它们是什么、如何工作以及为何值得感兴趣，而不是一遍又一遍地只交付单一垂直方向的产品。

Swyx [01:16:23]: 我觉得，也许可以这样理解：微软是最初的操作系统公司，而现在，AI 正在催生新的操作系统。

Kyle [01:16:35]: 是的，我认为我们现在正处在一个时代，需要帮助搭建这座桥梁。玩笑归玩笑，操作系统必须与五年前的样子不同，因为现在使用它的不再只是人类用户。这彻底改变了整个概念。不再是“好吧，我的 Claw 会创建一个用户账户”这种模式，事实并非如此。因此，就像我们所有人一样，我们都必须更深入地审视整个技术栈，一直深入到 Azure 中的硅层，去思考：“好吧，我们现在到底需要什么？”因为工作负载已经不同了。不再只是“我们需要更多的推理能力”，而是“我们需要什么样的推理能力？我们需要什么样的计算能力来运行这些代理或代理式流程？”这是一个非常有趣的多层问题，与过去五到六年里软件行业的情况完全不同。那时我们参加各种会议，总是听到类似的话：“SaaS 产品有了新功能，这是有史以来最好的 SaaS 产品。”

Swyx [01:17:42]: 有一段时间确实很无聊。

Kyle [01:17:43]: 现在却像是——天啊，我们已经进入物理领域了。

Swyx [01:17:47]: 太棒了。

Kyle [01:17:48]: 我们正在面对物理学问题，这令人兴奋。

Swyx [01:17:50]: 我们——我们现在正试图制造室温超导体，还是在努力中。这永远不会结束。不，我认为这是一个非常好的总结。你觉得还有什么我们没提到，但你希望表达出来、值得我们涵盖的内容吗？

Kyle [01:18:07]: 我真的非常兴奋，大家如果正在关注我们 Build 大会上的公告，可以去官网查看。我觉得这些内容会激发大家的好奇心和兴趣，因为微软正在为开发者做出一个巨大的转变。如果你平时使用的是 Mac 或 Linux 设备，并且觉得“我根本不用 Windows”，那么现在出现的一些改进可能会让你感到惊讶：“哦，原来他们真的想这么做？”——我这里说的不是游戏玩家周末在 Windows 电脑上打游戏的情况，而是指你日常工作的主力设备。从这一点出发，再到“构建一个智能体或应用，然后部署并运行在工作环境中”是什么样的体验？我认为这正是关键所在。我一直和团队强调：周末怎么开发，工作中就应该怎么开发。但如果你在一家 Fortune 100 或 Fortune 500 公司工作，你大概率不会只是随便写个代码就直接发布到某个服务上。你需要经过安全和合规流程。那我们如何在工作中也能保持同样的速度呢？我认为，我们已经推出了一系列产品来提供这种灵活性和强大能力，同时适应企业环境。此外，我之前提过几次，这个功能真的非常酷。如果你有任何方式接触 M365，一定要看看 WorkIQ 和 FoundryIQ。这些简化了上下文引擎的小工具简直太棒了。我们已经将它们提供给 GitHub 的开发者和员工使用，通过这些工具，你可以轻松地围绕自己工作中的所有信息提出问题。而 FoundryIQ 更能让你在所有现有的数据源中做同样的事情——不需要迁移到新工具，只需连接即可。它的能力令人惊讶，而且你的老板不会因此被解雇，IT 部门也不会因为它泄露隐私信息而关闭它。这就是我认为有时被忽略的关键点：当我们谈论这些全新平台时，虽然它们很强大，但很多人却说：“哇，这太厉害了，但我不能用。” 而原因并不是因为我在 GitHub 工作，而是……

Swyx [01:20:34]: 因为我不被允许，是吧？

Kyle [01:20:35]: 正是因为不被允许，因为这些工具无法满足大型复杂企业的全部需求。

Kyle [01:20:35]: 所以，无论是从日常使用的设备带来的好奇，到“天哪，我明天就能在工作中用上这个了”的震撼，再到拥有这样的上下文层和智能支持，这是一次巨大的变革。所以请务必去看看。我很乐意听到反馈——我在社交媒体上并不害羞，欢迎大家告诉我哪些地方好用、哪些不好用。希望这些内容能给大家带来一些惊喜。

Swyx [01:21:07]: 我听到的是——首先，我觉得这是一个很棒的宣传。实际上，我的理解是：你应该把 WorkIQ 团队和 Copilot 团队放在一起合作。因为你提到的那个“上下文问题”，正是他们解决得足够好的部分，足以让你完成工作，这简直太疯狂了。

Kyle [01:21:23]: 是的，我们最近几个月一直在做的就是这件事，这几乎就是现实发生的事。

Swyx [01:21:29]: 我早就预测你会走到这一步。

Kyle [01:21:30]: 完全正确，你完全说对了。代码和代码资产的问题确实有点特殊。但除此之外……

Swyx [01:21:36]: 就是这样。

Kyle [01:21:37]: 我们都在一起工作。

Swyx [01:21:37]: 核心就是上下文。

Kyle [01:21:37]: 现在我们都在围绕上下文协同工作，没错，一切都归结于上下文。

Swyx [01:21:40]: 太棒了，太好了。我会去参加的，我打算在那里做几场分享，还会采访 Satya。

Kyle [01:21:43]: 很好。

Swyx [01:21:43]: 我会去采访 Satya。

Kyle [01:21:46]: 我知道。

Swyx [01:21:47]: 不过，当我刚开始做播客的时候，我邀请了 Jeff Dean。Jeff 就像是我未来想见的人中的名人堂成员之一，Satya 也在名单上。那我该问 Satya 什么问题呢？

Kyle [01:21:57]: 我认为最好的问题是问他：两年或三年后，他认为什么是真实的？这个问题听起来可能很随意，但实际上，通过他看待 AI、推理、token 问题以及我们未来实际工作方式的角度，你可以看到微软内部最近发生的一些转变，推动我们走向一个不再有四五个甚至七八个独立系统、不再到处缺乏上下文的状态。那么，为什么这种做法在两年后会真正见效？因为我认为……

Swyx [01:22:41]: 哇，这真是个大胆的问题。好吧，我会问的。我会说这是受你启发的，但……

Kyle [01:22:45]: 当然可以。

Swyx [01:22:45]: 这是个大胆的问题，因为说实话，外界有很多怀疑。所以，是的，我希望能得到他一个直白的回答，这会让很多人安心，说实话，也会给我很多写作素材。非常感谢你抽出时间，感谢你所做的一切。作为 CEO，你其实不必亲自对外发声，但因为你权威、背景深厚，尤其是你在 GitHub 的经历如此真实，我们这些外部人能真切感受到。谢谢你。

Kyle [01:23:16]: 当然，非常感谢。谢谢您，Sean。