GitHub 的 Agents 计划 — Kyle Daigle, GitHub

欢迎，谢谢邀请。

对。

是的，我现在职责范围扩大了。我在 GitHub 已经工作了 13 年，一直从事开发者相关的工作，我自己也是以开发者身份加入的。现在我还兼任微软的开发者 CMO。所以，所有关于开发者的经验、热情，以及我们如何与他们合作、沟通、把产品推向市场，这些专长也被带到了更广泛的微软生态中，帮助每一位使用或希望使用微软产品的开发者，获得类似他们在 GitHub 多年来的体验。从某些方面来说，这是一个很不同的角色，但它也是建立在我在 GitHub 积累的经验之上——说实话、保持真实、展示如何使用产品，然后让产品自己说话。现在只是把这些做法推广到整个微软。

怎么说呢——

对我来说，这挺有意思的。头衔一直让我觉得有点奇怪。我加入 GitHub 时是开发者，我写了那么多——

什么？

对，我翻过一些老照片，当时大家在讨论 GitHub 是怎么建起来的。我构建了 webhooks，和团队一起开发了 API，构建了平台层，直到 2018 年，任何与 GitHub 集成的部分，要么是我写的，要么是我带领工程团队做的。这就是我热情的起点——帮助人们构建东西，交付给他们的客户。作为开发者，为开发者构建东西，一直非常独特。随着我的角色扩大，我不仅能和开发者交流，还能和企业客户、商业领袖沟通，充当一个翻译层。这么多年来，GitHub 一直运作得很独特，比如疫情后远程办公并不像 GitHub 2008 年刚起步时那么新奇。所有这些远程团队管理的经验，如何做好这件事，逐渐演变成了更大的角色，最终成为 COO——在微软收购后，如何让 GitHub 保持它一贯的运作方式。然后就这样延续下来。对我来说，我仍然写代码，热爱写代码，但问题始终在于人。支持自己的员工是更难的问题，向开发者和企业买家传达我们在构建什么、为什么重要，也是更难的问题，因为这是两种完全不同的信息。所以，能在 COO、CMO 和开发者身份之间切换，我想这就是我在 GitHub 待了这么久的原因。

对，他毫不客气地指出了这一点。你可以想象，对吧？你可以看到我作为开发者的正常时期，比如 2013、2014 年，然后进入管理岗位，最终成为 COO。你看到的是，我借助 AI 重新开始写代码了，就像在营销、运营和编码之间连接问题一样。我发现构建 agent 和工作流，把非常不同的问题连接起来，正是驱动我的动力。所以，一部分是写软件，很大一部分是连接大量不同的数据源来帮助我。但这完全是我自己，深入 AI 领域，试用我们的工具，也试用别人的工具。但对我来说，为像我这样虽然是技术出身但也是非技术领导者的人构建东西，以及我们如何能超越简单的问答式使用这些工具——我认为很多非技术人员，你的雇主会说，你必须用 AI，所以每个人都在用 ChatGPT、Copilot、Claude 之类的，真正深入思考这能怎么帮到我。我发现，不是写篇博客、做点简单例子那种。而是帮助人们找到工作流，比如：我需要你今天审阅所有 PR，我需要你查看我们网上发布的所有内容，我需要你回顾过去三个月的工作，搜索我 Obsidian 笔记中所有提到这个的内容，然后查看我在 Teams 上的工作转录。用 WorkIQ 调用 MCP 服务器，抓取所有转录，搜索 Slack，然后为我制定本周实际的信息传达计划。这在以前是不可能的。对我来说，AI 以及这次发布的大部分内容，其实不是向前构建，而是向后递归循环。我总是在看之前发生了什么：回顾这一周，告诉我我们做了什么，哪些有效，哪些无效，然后告诉我接下来三四天，基于这种回顾和一点前瞻，你会调整什么。我发现这更有价值，尤其是对非技术人员，因为这种回顾正是 LLM 擅长的——找出所有模式，提取出来，然后应用到短短几天或短时间内。我构建并发布了很多内部工具。每次打开笔记本电脑，我都会用新的 GitHub Copilot 桌面应用和工作流，它一直在为我运行工作流。各种不同的事情。当然，最终都托管在 GitHub 上。

对。

怎么做呢？我觉得，当我们开始在工程部门之外内部推广 AI 时，我特别在意的一点是：我们必须以一种不让任何人改变工作方式的方式来推进。我不想教别人用某个工具，也不想教别人学新东西。所以我们试过一些工具，大部分都不行，因为得先让人上手，得教他们怎么用。最后我们实际上做的是，在内部构建了一套技能。我们每个人都有自己的技能集，然后我们把 CLI 分发给了所有人，包括非技术人员，基本上就是让它能读取我们写的所有内容。对我们来说，这些内容通常来自 GitHub、Teams、邮件和 Slack。Teams 主要用于视频通话。

对。我们用 Teams 做视频沟通，但不用它聊天。GitHub 用了很久，我们一直讲 ChatOps，所有东西都集成在 Slack 里，每条命令、每个流程都在里面。

对，我们还在用 Slack。它对我们来说是个专用工具。说实话，迁移出去的成本高得离谱，因为所有工具都嵌在那个范式里，而且两者各有优缺点，工作方式完全不同。我们还在用很多不同的工具，因为我们需要这些专用工具。

各个团队都有自己的运作方式，我觉得这取决于你想做什么。

但我们确实会跨所有工具工作。通过给每个人访问所有这些上下文的权限，比如新的 WorkIQ MCP 服务器——如果你生活在 M365 生态里，这还挺酷的——我可以问它各种回溯性问题。这对我们远程工作的团队来说非常重要。不在办公室会错过很多东西，而我们的团队分布在全球各地。所以大部分是回顾性的。然后我们会自动把发现或行业报告发布到 GitHub issues 或 discussions 里，比如今早、今天、昨天发生了什么，跑一些自动化流程。我们会用 app，也可能用 GitHub Actions 配合 Agentic 工作流来执行。然后推送到 GitHub，继续对话。对我们来说，非技术侧主要是回顾和前瞻。当然，对很多人来说，还包括构建应用、推送到 GitHub Pages 或托管到其他地方。但关键是让每个人都拥有这种能力：本来要花一周搞明白的事，现在我们可以说，好，我建了一个技能，放到 repo 里，大家一起共享，然后用 CLI 或 app 直接跑。

某种程度上是的。

嗯，我觉得我们确实有——

对，我觉得现实是分两部分。首先，我认为那些庞大、完美、漂亮的技能时代正在结束——它们其实哪样都不沾。因为有一阵子，每天每条推文都在说：去下载这个完美管理的技能，它能搞定整个工作流。但我们发现，这周我和团队刚聊过技能这块，我们真正在讨论的是那些极其微小的技能，它们只做一件事，而且做得非常好，而不是像我说那种能生成完整报告的技能。那种东西在我们这边已经不存在了。通常是一个技能，比如给定任何 MCP 服务器，识别出最重要的营销信息。这才是关键。而不是把一堆工具拼起来，生成一个巨大的输出，因为几周、几个月过去，情况变了，你想调整那个大技能，结果就卡住了。所以我们现在讨论的是像乐高积木一样的东西，让说明书成为我们共同拼装的东西。而之前很多 AI 技能都是那种巨型的说明书风格。

当然，当然。

对，对，对。

对，我觉得是的。

完全同意。我觉得——对我来说，做总结这件事，你知道，我负责传播、公关、分析师关系、营销和客户活动。所以我的总结方式在每个场景下都完全不同，你明白吗？因为给分析师做总结，跟给客户会议或合作做总结完全是两回事。所以我觉得，这就是区别所在——就像我周六可能用的工具，或者我周六只为Kyle用的技能。那些东西背后要么有一个原子化的实际工具，要么是一种技能。然后Kyle关心的是X。但我觉得，当我们讨论工作、赋能营销和传播人员时，关键在于原子化的层面——这就是好的总结。然后，这是我在营销、传播或其他领域关心的东西。我认为，从开发者视角转向各种不同职业时，有趣的地方就在于这个矩阵问题：这个词对我来说的意义，跟对你、对分析师或销售人员的意义都不一样。这就是我们刚开始摸索的那个矩阵混乱——不是那些超级技能，而是一些细微的变体，但这些变体非常重要。这就像别人读完后会想：这是AI做的吗？你懂吗？或者，这完全合理，我在给Gartner做简报时也会期待这样的效果。

是的。而且我觉得最神奇的是，我可以直接把它拆开。比如，我可以去改插件的代码，或者用AI来做。但我觉得更神奇的是，收到一个回复后觉得不对，然后你直接打开技能，输入英文单词，结果就不同了。那个构建块非常独特。一旦我让大家都理解如何最好地做出那些改动，从而发挥最大效能，那就更好了。

对吧？

我觉得，秘诀一直是你识别模式和解决问题的能力。对于像我这样不再每天写代码的人来说，这让我作为开发者成功过，作为COO成功过，现在作为CMO也成功过。所以现在我能用Git和写代码，我就在应用那种模式发现和问题解决的能力。而且我仍然足够了解如何去做——比如，我想做一个应用，但不想搞砸或创建出无法运行、部署或扩展的东西。那种将额外业务知识应用起来、同时还能写代码的能力，我觉得特别有意思。这跟其他一些从技术领导转型为业务领导、现在又回去更新应用的人略有不同。他们很棒，但我觉得更有趣的是：我现在有了十多年的全新专业知识，为什么不把它作为开发者，结合这些AI工具来用呢？所以我绝对认为这让我更强大，但我觉得这对每个开发者也是如此。我认识的多数开发者朋友也都有其他潜在的技能和热情。当然，也有非常优秀、非常线性的计算机科学软件开发者。我只是发现，那些从不同职业转行、学过别的东西、做过随机事情然后成为开发者的人，或者开发者做过随机事情又回来的人，他们学习了额外的信息和技能，现在有了AI的力量——我可以在周六孩子们打长曲棍球时启动15个agent，这真的很强大。我觉得这让我找回了那种创造的感觉，这在大多数其他场景中很难复制。你第一次构建一个应用，点击它，展示给别人看，那种感觉太神奇了。而能够做到这一点，不仅限于代码，而是跨越各种不同类型的资产，这意义重大。我们每年做营收规划时，会讨论明年会是什么样子。当然，你可以想象，到处都是幻灯片，讨论我们要讲什么、叙事是什么等等。所以就像你说的，我想，我大概可以自己构建一个东西来做这个。这样我就不用去做整个电子表格，或者把它交给团队。于是我们经历了这个过程，我收集了所有信息，用了我提到的技能。我建了一个小应用，只是为了更方便地查看SQLite数据库中的一些信息。最终我构建了整个演示文稿，完全没碰那些东西。然后我想，好吧，我就直接向我们的CRO、CFO和他们的团队展示这个，但不提我是用AI做的。我建了一个技能，让它看起来完全不像AI驱动的。不错。不是漂亮，只是很明显不是AI——就像不要做任何有趣的事情。直接做。没错。我们全程做完了。它用了我在Obsidian里的笔记，用了之前提到的所有上下文和计划，从头到尾没人提过这是AI生成的。

一次都没有。没错。这根本不重要。所以现在我可以拿这个工具说，看，我不想让你去建幻灯片。它们只是帮我们互相分享信息。如果这个东西经过你一点打磨就能做到，然后我们可以一起看，那就太棒了。那些额外的工作毫无价值。对，我觉得让它看起来像人类做得那么差，或者建个小应用来操作数据，这本身就是一种优势。对于现在担任领导角色的开发者来说？因为就像我之前说的，这完全是一个人的问题。我知道你是否用了同事来建幻灯片，除非你花了很多时间不去用它。

对。

对。我的意思是，我仍然有幕僚长，因为区别在于——每次我们经历某种技术演进时，讨论的焦点并不是所有岗位都消失了。它们只是改变了，你知道吗？所以，是的，我不再需要有人花所有时间为我制作演示文稿的幻灯片，因为我不再需要了。但现在我需要的是那个人，他能在那些讨论中找到人与人之间的各种联系，帮我弄清楚：好的，我应该和这个团队、这个小组会面，他们有一个机会，我今天在旧金山，明天在西雅图。这类人际连接的部分仍然非常有价值，而且一直是幕僚长角色的重要组成部分。但现在，就像幕僚长不再拆阅信件来处理事务，而是处理电子邮件一样，你明白我的意思吗？这是同样的道理。现在他们不再制作那么多演示文稿，因为他们有能力让AI接手并分享给我。太好了。我们继续前进，因为这让我们能更快地行动，更迅速地做出更好的决策。

比如什么？

对，不，我的意思是，我觉得一个重要的时刻是在2018年收购完成之前，我在GitHub Universe上发布了Actions的第一个版本。所以那是——

对，我记得是2018年10月。对。天哪。对。我作为那个项目的工程负责人，发布了它。然后，是的，我们进行了收购，比如npm，就像你说的，Semmel、Dependabot、Pull Panda，还有很多其他东西。那是一个大事件——Pull Panda。对。Abby，Abby做得很好。在DX方面表现不错。你知道，那是在收购之后的一个重大转变。我不得不加入业务方面。

哦，我的意思是，我认为安全问题的头号来源可能是每个人底层仓库里的实际代码。我会说更早之前是——如果你还记得，我在这张图里有一些东西，我之前没说过。这最终是webhooks。对。大概在某个时候。Hookshot也在里面。所以那时候它叫GitHub services。你看到吗，它写着Hookshot、Hookshot FE（前端），然后写着GitHub services。GitHub services在旧时代，对吧？我们有一个Ruby代码的仓库。你可以在里面写任何Ruby代码，然后我们会代表你执行它作为一项服务。这样，如果你试图与某个东西集成，我们会为你运行它。

没有，因为那是2014年，你知道，所以显然有一些隔离，但主要是服务器层面的分离。那是一个例子，就像非常老版本的Pages，它运行在自己的容器化基础设施上，而不是Actions上。

Pages支撑着互联网。就像，你知道，在某种程度上，这些地方显然没有——据我所知——什么问题，但正是这些东西让我看着想：好吧，我们不能代表每个人运行任意的Ruby代码，你知道，然后现在把所有东西容器化到Actions中，容器化确实很好。但锁定——大多数人并没有将他们的工作流锁定到特定的SHA等等。所以，如果人们只是像任何依赖管理一样使用v1或最新版本，那会是一个很大的痛点。但从那天到“好吧，我们只是运行所有任意代码，基本上没问题”，再到现在的“不，我们有非常好的容器化，我们有一个新的底层代理容器化服务，我们在底层使用它，通过Azure，他们最近宣布了Azure Dev Compute，但它非常快，非常快的计算能力，可以快速启动你自己的云代理之类的。我们在新的一些部分底层使用它——Microsoft Dev Box？不，不，不。Dev Compute。

哦，它就在那里某个地方。

我们会剪掉这段。抱歉。但有了Dev Compute，你可以非常非常快地运行，非常快速地启动非常小的虚拟机。所以当你进行工具调用时，直接做就行。容器化。没错。所以我们正在使用它。绝对在朝那个方向发展，以保护我们免受最终运行的每一段代码的影响。

你知道——是的，我的意思是，当我们和团队交谈时，我认为对我们双方来说，重要的事情是找到一种方式让npm继续运行，它当时基本上支撑着互联网，现在在某种程度上更是如此，保持它的运行，继续扩展规模，我记得当时它遇到了扩展问题，他们正在进行一些重写。

是啊，问题就在这里。现在我跟人聊的时候，npm 的底层用途比当初我们把它和 GitHub 整合时要多得多。但最终目标一直没变。我们以前有 Pages，有全世界的代码。我们要确保 npm 能持续良好运行，为全世界服务。我们投入了大量时间和精力修复底层后端，比如之前聊过的 manifest 相关工作等等。现在则是真正努力提升 npm 的安全水平。但这是个独特的挑战：我们每做一个更安全的改动，都会影响很多人。安全至关重要，我们也非常认真对待。任何时候 GitHub 出问题，或者我们做了更安全但带来不便的改动，对开发者来说就像下雪天或一场必须扑灭的大火。所以我们改了 2FA 策略，改了 token 的工作方式。发现 token 被泄露或可能泄露时，我们会使其失效。我很喜欢 GitHub 那个自动创建 issue 的功能，但问题在于，我们既要推动社区前进，又不能破坏 npm 近 15 年来建立的契约。

我不知道。我不认为这能解决——Mitchell 今天刚聊过这个话题。我觉得从某些角度看，这不过是旧事重提。把所有东西都 vendor 起来。我记得 2013、2014 年就是这样。

没错。当时我们什么都 vendor。我们还在认真讨论：要不要把整个东西都拿过来？为什么这么大？我们只需要这一个文件。所以我认为，只取所需，或者让依赖项随时间变得极小，确实能在一定程度上帮助，但解决不了根本问题。因为漏洞这东西，让 agent 去审查，有无数种方式可以欺骗 agent 认为某个东西是安全的，然后把它拉进来。或者我们可以做静态代码分析、运行时测试来判断代码是否工作。我认为这才是需要持续投入的方向。问题只是范围：是我拉下来的这个庞大项目，还是其中一小块？无论如何，大多数公司都会对引入或 vendor 的包做一定程度的安全检查。这点不会变。Advanced Security 在做，Socket 也在做，大家都在做一部分。但具体怎么做，尤其是面对企业客户时，差异非常大。没有人想要单一的方式。我认为这一直是 GitHub 在世界上独特的定位。我和很多维护者聊过，也和很多人讨论过。我们很少主动发起一个流程或实践，然后强推给社区。我们通常等待类似 RFC 的社会化流程，或者等所有人都同意，然后才固化下来。否则——这符合你在生态系统中的角色。我们不想塑造一切，而是希望社区自己摸索出来。但如何平衡这种角色：既要尽可能保证安全，确保你不会因为人为因素被攻破——因为通常问题都出在人身上——又不要创造一个你不喜欢、Mitchell 不喜欢、其他开源项目也不喜欢的流程或锁定一个流程。这对我们来说一直是个棘手的平衡。我觉得我们在这方面聊得还不够。我们不可能用一种让所有人都满意的方式解决所有问题。所以请告诉我们，什么方案是有效的。Mitchell 提到那个 upvote 系统——我忘了叫什么。对，就是那个。我和他聊过，在 Twitter 上发了，也私信聊了。我们会继续努力。但重要的是，我真的很想听听什么对你来说不奏效。请尽可能具体和清晰地针对你的项目说明。多年来，他在行业里一直这么做，我很感激。因为有些地方我们需要改进，听到他的反馈后我们会修复，就像对待其他维护者一样。但在做这些改进、变得更安全，以及创建——我忘了他怎么称呼那个系统了。不是 proof 流程，也不是 claims 流程。你知道我在说什么吧？他的项目有一种让你“担保”的方式。对，就是那个 vouch 系统，用来表示“嘿，你应该接受我的 PR”。

我不知道。你看，你这么说，但他和他的社区很喜欢这个。然后我去和其他维护者聊，全球各地的维护者，他们会说“不，这对我没用”。这就是张力所在，但也是 GitHub 的美妙之处——取决于你怎么看。我们想帮助维护者，所以创建了各种工具，让你能更好地控制从 AI 和 PR 中接受多少内容。但你也可以使用这个项目。如果它流行起来，成为某种标准，那我们可能不会强制执行，但会把它加进去，因为这是我们通常的做法。

对。以前这个过程非常混乱。现在我们享受它成为标准流程的好处。接下来，我们需要找出下一个最佳流程，或者看看需要哪些调整。当你的 PR 有 80% 来自 agent 而非其他开发者时，pull request 会变成什么样？

我觉得每个想法都有它的价值。我不是在回避说好或坏，但我见过一种版本，比如托马斯创业公司里那种，把你构建的所有资产都放进去。我认为那里面有很好的想法。PR流程有各种不同的变体，但我觉得之所以没有一个标准答案，归根结底是因为我们试图将信任编码化。我们想说的是，如果肖恩审核了这个，我就信任它，因为你是肖恩，或者你是资深开发者，或者你是别的什么身份。而现在，当我们在一个流程中，一个智能体写代码，另一个智能体审核代码，然后凯尔再去查看时，信任是分散的。我们讨论的大多数工具更多是关于验证流程。我们有更多资产可以查看。所以我大概能判断这个PR好不好，但这仍然没有解决人类的问题：我在看一个PR时，想知道我能不能信任它。而我们仍然倾向于使用人类信号来做这件事，比如米切尔批准了，或者凯尔批准了之类的。所以我认为，这就是为什么大多数选项都没有真正解决这个问题，因为它是一个社会问题。归根结底，这是一个人类问题：需要有人审核并达成一致，或者你完全信任工具。是的，你把全部信任都赋予那个工具，我认为在某些情况下这绝对存在。

我觉得这更像是，我坐 Waymo 来这里，全程都在看手机，根本没看周围。还有其他一些自动驾驶车辆，我盯着路都不敢信任。而我认为这种信任是——

我觉得两者都有。两者都有。

就是这样。

嗯，取决于自动驾驶的级别，但我的意思是，我认为其中一部分是，我坚信这就像可验证的证据，比如事故数量、数据量等等，以及我在车里时的感受、它告诉我什么等人类因素。所以这就是为什么我觉得有些AI工具更能给我那种信任感，即使数据说这是100%准确的。你知道，我觉得我们需要更多时间来思考：我该不该信任这个？从软性的角度来看，有高自主性的初创公司、周末项目和开源项目，然后还有企业和受监管行业等等。这甚至是一个更难解决的问题，因为即使它被完全验证了，你不仅需要团队中人类的信任，可能还需要全球多个国家、多个监管机构的信任。所以我觉得，直到我们达到你说的那个临界点，在人类情商方面，我感觉“好吧，这感觉还行，我已经被充分证明了”，那么事情就会开始加速推进，最终我们就能在最困难的情况下信任它，并且感觉良好。

我认为目前我们没有以这种方式充分暴露的一个方面是某种程度的硬性信任和支持，对我来说，赞助就是一个很好的例子。它需要你付出一些代价，来证明我相信你的项目，我在某种程度上信任你。至少我想支持你。好吧。

我觉得随着我们不断前进，有越来越多的项目我亲自往赞助里投更多钱，因为我想支持它们。但我也知道，我可能从未见过他们本人，但我了解他们足够多的工作，所以我想支持他们。我不喜欢星标数或提交数的原因是，即使我们做了各种反滥用、去垃圾和去重的工作，这些都不是主动的社会信号。它们是被动的，最终是可以被游戏化的。你可能信任我，但另一个开源维护者可能不信任。你该用什么启发式标准来信任我？我认为这大概是我们目前思考的方向。我的哪个信号对你最重要？如果你能定义它，也许在智能体工作流中，就像我们看到一些开源项目做的那样，你有 GitHub Actions，然后有一个调用AI的智能体工作流。你设定规则，比如如果凯尔在任何项目中提交并接受了PR，并且他的GitHub账户关联了一个社交账号，且该账号存在时间超过一定期限，这些对你来说很重要的复杂衡量标准，因为大多数开源项目在头脑中都有这种启发式标准，即使没有写在贡献指南里。你可以拿这个去应用，然后直接说，我们不接受这个PR。构建一个我认为能适应每个人需求的东西，比直接说“这个账户太新了”要好一点，因为会发生什么？攻击者会去创建大量账户，然后等着它们变老。需要有一定数量的星标。这就是星标通胀发生的原因。需要有一定数量的仓库和PR。他们都会创建仓库，互相提交PR，然后进来做坏事。所以，很难找到衡量标准。因此，我们更多在考虑如何为你提供工具，让你可以选择最适合自己的方式。当然我们会给你一些标准，但信任向量最终会落到某种人类数字身份上，就像大家都在讨论的那样。我如何证明这就是我？给我你的眼球。给我你的眼球。

我觉得这其实有两方面。一方面，我们一直在想办法发现用户是否在制造垃圾内容——比如那种纯粹为了刷星的行为。一旦发现，我们就会剔除掉。但这就像打地鼠一样，现在完全是AI驱动的打地鼠游戏。不过我更想说的是，我观察到很多"最快达成X"的现象，往往是因为我们现在邀请更多人参与GitHub上的软件开发，整个潮流正在涌动。没错，这不只是开发者的事，也不只是你和我。无论你怎么定义"开发者"，都不只是那些写了很多年代码的人，还包括可能刚开始写代码、或者从AI时代才加入的人。

哦，现在已经超过2亿了。是的，没错，超过2亿开发者了。

这其实是目前GitHub内部大家最爱争论的话题。从我的角度看，专业的企业开发者和普通开发者之间确实有区别。但我觉得，在软件开发早期阶段，纠结于细分开发者群体、或者钻牛角尖，根本不值得花时间。

完全正确。因为我开始写代码的时候也不是开发者。我本来打算——

我当时也不知道自己在做什么。我记得那些帖子，那完全是胡说八道。所以我立场很明确：如果你创造代码，如果你有一个想法并把它实现成某种形式——比如我要运行它、马上用这个应用——你当时可能用了AI，但这没问题。总有一天你会做下一步：你会学习数据库，你会修复一个bug，等等。我们都在同一条路上。这些人也会听说新的Agent技能包、新的CLI工具或新东西。那些项目之所以涌现，是因为你想参与这个时代。就像我当初成为开发者时，Ruby正火，我想加入Ruby社区一样。现在你只需要点一下星标按钮。所以我认为，确实存在一些垃圾内容和刷量行为，我们在对抗这些，但我真的觉得我们正在看到一群全新的人，他们在不同技术之间切换，因为他们不是在维护一个20年的老软件，而是在周末为朋友或新想法搭建一个副业应用。这就是为什么你会看到那些星标图表直线飙升。

是的，这也是为什么我们在尝试进入更偏向低代码的领域时，比如我们开始做Spark，作为一种构建并运行应用的方式。我认为，每当我们试图在上面加一层表面包装时，我们仍然会展示代码。这算是一个原则。我们永远不会把代码藏起来。因为这才是重点。不过，我们从Spark这类东西中学到的是，对大多数开发者来说，Spark的真正价值在于简单的运行时。你可能已经有运行时或主机来用，或者你可以直接构建并运行。但让这个过程更简单的包装其实并不必要，尤其是对那些想构建软件、而不仅仅是构建一个应用的人来说——这两者目标略有不同。所以我想让你入门，让你感到舒适。作为一个并非传统进入软件开发领域的人，我觉得最好的事情就是让任何人都能跨越那道鸿沟，而不是被困在STEM的圈子里。我有个12岁和一个8岁的孩子，我们总说要让他们学STEM。我做了好父母该做的事，比如问他们想不想学编程，他们回答想，于是报了编程课。但现在他们不再害怕做软件了。我觉得这正是让我在GitHub待了这么久的原因。任何人都应该能去构建一个东西，就像我能去换家里的电灯开关一样。我不会去碰配电箱，因为可能会电死自己，但我能换那个开关。每个人都应该能说："这个破应用不按我想要的方式工作，我希望它这样运行。" 我认为，正是这种机会让我们多年来与GitHub紧密相连，无论顺境还是逆境——因为我们是所有开发者的家，我们希望每个人都能体验到那种感觉：我有一个想法，我创造了它，然后天哪，它就在这里了。

你是说GitHub？

这确实是个艰难时期。我是说，这确实不容易。而且，我刚刚跟团队说过，这也是我记忆中GitHub最令人兴奋的时期，因为这是最好的时代，也是最坏的时代。没错。因为我们刚才聊到Octoverse报告，通常我们每年做一次Octoverse报告，看看数据然后说，天哪，我十月份在Universe大会上说这是我们有史以来增长最快的一年。而现在，我们一个月内完成的工作量比去年一整年还多。你提到的PR、提交、PR，几乎我们看的每一项指标，都有某种程度的大幅增长。这种增长正在以全新的方式冲击我们的系统，而不是老问题。比如，webhook多年来一直以不可靠著称，这怪谁呢？现在不怪我了，但有一段时间，我敢肯定你能翻出一条推文说，是我干的，抱歉。但现在，它在规模层面被重写后依然正常运行，没有出问题。现在我们发现的不再是那些简单的问题，比如人们有时在Twitter或互联网上问的"为什么这样？"当然，确实存在一些不该有的愚蠢问题。但我们现在讨论的是独特的、新颖的权限问题，这些问题只会在跨所有不同对象的规模下出现。现在我们不得不重写底层系统。所以，有些问题确实让我们措手不及，我想我说过。增长是天文数字级的，但我们也取得了实质性的进展，我很兴奋，一旦我们重新构想底层基础层或至少部分组件，当不只是我们所有人、所有新晋开发者、他们的agent以及所有工具协同工作时，会有什么可能。因为这一切仍会在GitHub这个工具、这个社区中发生。但每当我们无法提供你想要的东西时，日子就不好过。我们内部也有同样的问题。我们通过GitHub.com运营。当然，我们有备份机制应对宕机等情况，但我们也感同身受——如果系统不工作，对我们也不工作。这就是GitHub"吃自己的狗粮"的承诺。一直如此。我们用的是和你一样的工具，没有秘密版本。所以我们也需要它对我们、对客户、对开源社区都足够好。而现在，还有指数级增长的agent也在使用它。

是的，实际上还在加速，仍在加速。没错。这是四月份的数据。

是的。就像我说的，我们在几个不同地方遇到了增长问题。其中一些增长问题正是我们——我刚才提到，我们在大力推动更多CPU，特别是在Actions方面，更多工具、更多agent、更多PR意味着更多构建、更多构建和更多CPU。所以我们不仅在扩展数据中心，显然我们也在讨论迁移到Azure，增加额外的云计算资源，因为我们确实需要更多CPU，当然也需要GPU，但现在CPU也成了瓶颈。在底层，关于一些基础服务，我们多年来一直在拆分数据库基础设施，以便在各服务之间实现更好的认知隔离。我们持续感到痛苦的地方是权限管理。目前，我们的许多权限层都放在一个我们内部称为MySQL 1的数据库中，老Hubbers会知道我在说什么。所以我们多年来一直在把东西从MySQL 1中剥离出来，因为我们使用Vitesse和其他技术进行分片。

百分之百。Sam，老同事兼朋友。所以找到这些机会来拆分并全局部署。另一件我认为既独特又棘手的事情是，我们还将我刚才提到的所有东西放在一个黑盒容器中，以GitHub Enterprise Server的形式提供给本地部署的用户。所以我们把刚才说的所有内容都做本地部署，同时也为需要将数据放在单一位置的客户做数据驻留配置。每个场景在如何将数据存储到MySQL或权限设置方面都有独特的特点。这就是一些宕机发生的地方，你看到的问题更普遍，而不仅仅是某个特定服务不工作。没错。所以部分原因在于，我认为在其他一些地方，agent更活跃，或者更多项目似乎转向了monorepo，而多年来行业一直在朝相反方向发展。仓库更小，但数量更多。现在我们看到相反的趋势：仓库更大，但数量并没有减少，因为还有新增长，我们只是看到更多大型仓库。大型仓库、大型monorepo一直有独特的性能问题。因为每个都略有不同，特别是如果仓库底层的blob非常大。我们做了大量工作，你可能——除非你遇到monorepo的情况，否则大多数人可能没经历过。但Git基础设施层的改进确实有助于整个系统，因为许多让monorepo运行得更好的改进也让所有仓库基础设施运行得更好。所以我可以继续往下说，比如另一个方面，我们正在改变——我们正在改变任务队列的方式，用更好的说法就是，改变底层技术。

所以这有点像是一点一点拼凑起来的，主要是因为我们在构建时，某种程度上假设了工作管道的规模会保持不变，只是会有更多人通过每条管道。但现在，比如 git push 的大小原本是固定的，现在已经不是这样了。没错。你知道，或者平均来说，PR 也是一样，PR 也是同样的情况。我们讨论过优化它并做出改变，但有些技术选择并不奏效，它变慢了，速度不够快，没有满足用户的需求。所以我们一直在逐步淘汰这些做法，意识到那不对，就不再继续投入，而是用正确的方式重新来做。所以这涉及很多方面，不像我在 GitHub 历史上经历的扩展问题那样，通常只有两种选择：垂直扩展，特别是针对数据库；或者水平扩展。比如有更多人使用这个服务，我们就增加更多服务器，部署在数据中心或云端。但现在我们处于一种对角线状态，垂直扩展不再有效，水平扩展也行不通，因为全球范围内我们都有 CPU 或 GPU 的限制。现在我们不得不拆开那些运行了 10 或 15 年的服务，承认这些服务的规则已经彻底改变，必须重写它们。这都不是借口，而是我们必须做的工作，必须让它变得更好。

这就是难点所在。当我们没有公开讨论时，我站出来说，嘿，我想解释一下发生了什么。部分原因源于 GitHub 非常古老的传统，那就是我们的正常运行时间出了问题，服务宕机了。

我知道你是开发者，所以你想更深入了解情况。但与此同时，我们承认这个服务没有达到预期，需要去改变它，我们并不是想隐瞒什么。这只是我们的问题，因为你期望我们保持服务在线。我认为这深深植根于 GitHub 的核心起源。所以现在我们团队要做的是完成这些工作，并且更多地谈论它，分享更多技术细节，写博客、发帖子，让完成工作的工程师直接告诉你我们做了什么。我认为这是我们想重新与社区建立的契约：嘿，我们仍然非常认真对待我们所做的事。之前我们没有告诉你每一部分，现在让我们开始这样做。我们会继续构建和扩展，以支持未来的增长，不管是 14 倍、30 倍还是 50 倍，无论下一个指数级增长是什么。

如果其中任何部分有点不准确，我提前道歉，因为虽然我还在深入参与，但这并不是我的日常工作。但关键在于，我们都在那个层面上关注它，你知道吗？

是的，当然。

是的。

是的。所以，最近几周我们的可用性比之前三周好得多，再之前三周也是如此。所以很多改进仍然在为我们带来回报。是的。我认为我们还在处理我提到的那个数据库问题。这需要一点物理时间，需要一点时间来修复。因为我们不得不——

所以 YouTube 最终也用了 Vitess。

是的。我相信那个人去了 PlanetScale，我也曾是 PlanetScale 的一员，但你是说 Sugo？我想是的。他现在在 Supabase。

是的，完全正确。所以一部分是那个问题，另一部分是我们获取额外计算资源的举措将大大缓解这个问题，特别是在 Actions 方面，因为很多底层宕机实际上与 Actions 有关。Actions 是万恶之源。它有它的优点，因为它是 CI 或副项目等的核心计算层。Actions？

我的意思是，Actions 让我在计算上花了很多钱，对吧？是的。Actions 绝对是整体业务的一部分，但我想说，我们最终也赠送了很多分钟数，作为我们权益的一部分，就像我说的那样。每个人都在用它。我们把它当作 CI/CD 来谈论，但实际上人们用它来做 CI/CD 以及各种处理和自动化。没错。所以部分原因也是计算资源的问题，这也在缓解我们的可用性问题。

感谢你的贡献。

当然。你知道吗？

是的。所以无论如何，我想说，部分问题会得到解决。我预计在接下来的三个月里，你会看到可用性问题越来越少，宕机事件越来越少。这不仅仅是停止宕机，而是我们仍然在经历比以往更快的增长。只是我们一直在努力的那些底层改进终于开始见效了。这些改进不像那种小改动带来大产出的渐进式改进，而是需要一些时间的实质性改变，然后你会看到可用性的阶跃式提升。

对，完全同意。我想说，从去年十一月到现在，我们一直在做这方面的探索和工作。因为十月的时候，我们才注意到增长趋势，然后图表开始急剧上升，我们意识到之前测试的规模是 N，现在可能在某些维度上已经到了 N 的三次方。所以现在我们必须重新构建，确保它能承受那样的规模。

是啊，说正经的，我忘了具体数字，就是最初 GitHub Copilot 团队有多少人。不过，其实还有更大的团队。

Alex 参与过，Uga 也参与过，还有好多人。

我觉得我们没公开过具体金额。

对。

嗯，我觉得 Copilot 面临的一个挑战是，我们一开始推出的是代码补全功能，效果非常好，也很强大。在那之后的一年半里，我们主要专注于微调，因为客户和整个行业都在讨论如何提高正确性和性能。所以我们做了很多工作，对越来越大的代码补全或基于微调的下一个编辑建议进行微调。

两者都有。既针对整体使用场景微调一个模型，也为有需求的客户提供微调服务。差不多在那时候，新一代模型出现了，同时很多其他 AI 编码工具也冒了出来，因为模型速度大幅提升。所以很多人会问，GitHub Copilot 怎么了？这段时间在做什么？我想说，我们当时处于一个阶段，想要提升所有人的结果，所以专注于微调，因为那能带来更好的效果。然后模型本身变强了，从那以后，我们一直在探索，当然我们有很好的代码补全，也在底层模型上投入了大量资源，比如后训练、更好的语言特定模型建议等等，这些都属于 GitHub Copilot 代码补全的范畴。但现在我们也有了一个统一的 SDK 和框架，用于我们的编码 agent，也就是 Copilot 本身，还有新的 CLI、新的桌面应用、以及使用相同 SDK 的云 agent。所以有一段时间，我们既要弄清楚客户想要什么，模型又在某种程度上抢了我们的风头，然后我们思考，大家最终需要什么？我们认为不仅仅是代码生成，更重要的是能够使用这些编码 agent 式的框架或运行时，不仅限于编码体验——比如发送一堆任务、用 Fleet 分解单个任务、或者类似 Autopilot 的目标导向功能——还要能用于所有安全修复、每个 GitHub issue，直接放一个编码 agent 上去看看是否可行。如何遍历仓库、查看所有文档并提取信息？我认为 AI 编码 agent 的自动化是我们看到的一个重要方向。我们仍然在经历类似但非常不同的流程，只是所有事情同时发生。你不会再创建一个 issue 来跟踪某个构建想法，而是直接去做，说“嘿，把这个做了”。当然，仍然有大量开放的 issue 和项目在使用 issue 功能，比如 Peter 和 OpenClaw，他们可以把 agent 直接丢到那个基础设施层上。我们正在构建的，是一个真正优秀的编码体验，能够处理这种多路复用，这就是 GitHub Copilot 的方向。对于那些很久没用 GitHub Copilot、当初被它吸引的人来说，我强烈建议你看看 GitHub Copilot 应用，那是我现在每天用的工具。如果你喜欢 CLI，也可以用 CLI，支持所有模型和自带密钥。我们还在改进自己的模型，并同时使用它们。这是一种非常不同的体验。我认为更广泛的视角是软件开发以及编码 agent 如何在各个环节提供帮助，不仅仅是写代码、验证或部署，这是我们独特的切入点。另一方面是上下文的问题。天哪，我觉得最终让我在 GitHub 感到完整的事情是，当 GitHub 能像 Kyle 或 Sean 想要的那样运作，我们把这些都编码成规则、记忆等等。这仍然是一个开放的研究问题，100% 是的。但如果我们能做到，即使不需要我编码所有东西，随着方法有意识地变化，也能拥有完整的体验，理解依赖项和开源项目中发生的一切，那将是我们继续用 GitHub Copilot 提供独特价值的重要方向。

我觉得我们都还处在一个极度短视的AI时代，现实是，出于各种无聊的安全和治理原因——至少对大多数人的工作来说是这样。为什么我的编码智能体，哪怕全是后台运行的后台智能体，不会丢失它在编码之外我所做的一切中可用的所有上下文？是啊。我觉得AI中最有意思的是真正的环境智能，而不是插入某个助手名字的东西。我试过几乎所有别在身上的工具，它们都不像我希望的那样工作，因为它们只是试图捕捉、然后编码、再回忆。而我真正想要的是回到最开始——我正在构建下一版本的webhook，或者实现一个新功能。它应该知道每一份规格文档、每一封邮件、我在网上的对话、关于如何实现这个功能的一切，并能把这些作为决策的一部分。但这些工具最终都没做到。所以我觉得，这就像软件开发工作是一条单行道，只需要一个开发者。一旦我写出完美的代码，就完事了。但事实从来不是这样。它需要其他团队成员的上下文、业务在做什么、当下流行什么。我认为这是我们走向更广阔领域的巨大机会，而不仅仅是极其优秀的编码智能体。说实话，这也是为什么我觉得OpenClaw如此有趣——它确实连接了Kyle这个人类关心的所有数据源。现在我的问题是：我如何作为一个软件开发者，每天把所有这些东西连接起来使用？而不仅仅是拥有一种启动编码智能体的新方式。这就是我们现在的处境。我们说，好吧，我要在底层用这个CLI或这个SDK。但这不是我所说的。我说的是，我正在和你对话，它下载了播客，然后意识到：哦，Kyle听起来需要这个应用或那个东西。就是那种——没错。就是那种连接程度，我认为在软件领域我们还有很长的路要走。因为当我们有了那根红线，想要拉出那个想法时，它不仅能使用完美的方式编写代码，还能利用我或我们团队积累的所有品味、判断力和专业知识，并将其作为实际实现的一部分。

对。

我觉得Nat Friedman在Stripe的一个活动上分享过这个，他谈到OpenClaw时——他把OpenClaw连到了他的摄像头上，它就在看着——

在某种程度上，我其实希望OpenClaw能告诉我要喝水。我不确定我想让它改变我的车去哪，但我认为这正是我所说的——它需要掌握更多信息才能对我有用。我仍然不觉得我们在谈论AGI。我只是说，每次我不得不告诉你我在意的事情，或者我已经说过十几遍的事情，它应该能知道、编码或获取这些信息。像Dreaming Ideas这样的东西是在尝试做某种版本的这个，但我认为还有一个更主动的角度，如果我们能多测试一下，会对软件开发者有帮助。

你觉得他们不应该有吗？

比如，今年我们在微软Build大会上也会更多地讨论这个话题。我认为关键点在于，OpenClaw所做的就是建立了一种连接，让人们能够访问你拥有的资源，并为你执行操作，而以前人们只能尝试将这些功能硬编码到自己的代理中。所以，想想工作场景，如果能有一个类似Claw的对象，可以在我的工作设备上运行，或者能访问我的工作资产，在Windows上运行良好，那该多好。我认为OpenClaw已经成为一个有价值的代理的化身，它理解我，因为它能访问我所有的信息，并且能操作电脑。因此，它能做的远不止面向任务的处理流程或聊天工具。这也是Build大会的目标之一，对吧？今年我们在Build上试图采取一种截然不同的方式，毫不掩饰地瞄准开发者。我们想展示更大的投入，而不仅仅是说“好吧”。就像你说的，为什么要有OpenClaw的CVP？因为我们的一个问题是，如果你把代理安装在个人设备或工作设备上，而不是Mac mini或托管设备上，我们需要在操作系统层面提供更好的沙箱机制。我需要能使用那个Claw，而不会被炒鱿鱼。所以微软就决定，好吧，我们也来做这个。然后问题就是，我应该在什么地方与这个代理对话？是不是每个员工在工作时都应该有一个Claw可用？很可能。就是这样。而且，我们也在持续为开源项目做出大量贡献。微软，随着我了解更多信息，我觉得对开源项目本身的投入非常大，但出于某种原因，这些团队似乎不想居功或获得认可。但很多核心贡献者团队都是全职在推动开源项目。我认为这显示了差异：为什么我们如此关注像Claw这样的东西？为什么我们在研究Windows上的沙箱？为什么我们在研究云版本的沙箱？因为最终，我们需要更多的平台组件。我们不需要每个人都去构建完全相同的顶层产品。如果我们是为构建者而建，那就需要我们提供所有这些组件，并告诉你它们是什么、如何工作、为什么值得关注，而不是反复只交付单一垂直产品。

没错。

我认为我们也处在一个需要帮助搭建桥梁的时代。说正经的，操作系统需要与五年前不同，因为现在不只是你在使用它们了。这改变了整个概念。我的Claw不能去创建一个用户账户，那样行不通。所以，就像我们所有人一样，我们必须更深入地审视整个技术栈，一直深入到Azure的硅层，去思考我们现在需要什么。因为工作负载不同了。不只是需要更多推理能力，而是需要什么类型的推理？需要什么类型的计算资源来运行这些代理或代理流程？这是一个非常有趣的多层问题，而不是像过去五六年那样，我们去参加活动，说的都是同一套东西：SaaS产品有了新功能，这是有史以来最好的SaaS产品。那段时间挺无聊的。而现在，我们面对的是物理层面的问题，这很令人兴奋。

是的。我对大家关注我们在Build上的公告感到非常兴奋。你可以去网上看看。我希望这能激发大家的好奇心和兴趣，因为微软正在为开发者做出重大转变。如果你日常使用Mac或Linux设备，觉得“我不使用Windows”，那么现在有一些改进可能会让你惊讶，让你觉得“他们真的想这么做”。我指的是开发者，不是周末用Windows电脑打游戏的人。我说的是日常使用，从那个层面一直到在工作中构建、部署和运行代理或应用。我经常和团队讨论，我在周末如何构建，就应该在工作中如何构建。但如果你在财富100强或500强公司工作，你很可能不能随意编写一个应用就发布到某个服务上，你必须通过安全和合规审查。我们如何能在工作中也保持同样的速度？我认为我们提供了多种方案，让你在工作中也能获得同样的敏捷性和能力。另外，我提过几次，这真的很酷。如果你使用M365，一定要看看WorkIQ和FoundryIQ。简单来说，这些上下文引擎非常强大。我们已经把它们提供给GitHub的开发者，让员工能够就工作上下文中的任何内容提问。通过FoundryIQ，你可以在所有现有数据存储中做同样的事情，而不是迁移到新工具，只是把它们连接起来。这出奇地强大，你的老板不会被炒，IT部门也不会因为泄露隐私而关闭它。我认为这一点在讨论所有新平台时有时会被忽略，因为我可以使用它们，觉得“这太强大了”，但实际却用不了。不是因为我在GitHub工作，而是因为大型复杂公司无法满足所有要求。所以，无论是日常使用的趣味性，还是“天哪，我明天就能在工作中使用它，拥有那个上下文层和智能”，这都是一个巨大的转变。去看看吧。我不介意在社交媒体上交流，很乐意听到反馈，哪些好用，哪些不好用。希望能给大家带来一些惊喜。

所以，我们正在做的事情，实际上就是过去几个月一直在发生的。

完全没错。因为你说得太对了。代码和代码资产的问题确实有点特殊。但除此之外，是的，我们现在都在互相协作。一切都只是上下文的问题。

我觉得，最好的问题是问他，从现在起两三年后，他认为什么是真的？你知道，这听起来像是个随口一问的问题，但归根结底，他看待这个 AI 问题、推理问题、token 问题的方式，以及我们实际将如何工作——你可以看到微软内部最近发生的一些变化，正在推动我们走向一个不再是四、五、六、七、八个不同东西的局面。不再是到处缺乏上下文，而是为什么这种两年后的方法会取得成功？因为我认为——

是的，是的。

不客气，很感激。非常感谢你，Sean。