GitHub Copilot进化！从AI结对编程到SWE代理交响乐团，Project Padawan引领2025“代理之年”。VS Code集成Agent Mode，Copilot化身SRE，赋能开发者。未来软件开发，自然语言是关键，人人皆可编程！
译自：GitHub Copilot Wants To Become Your Peer Programmer
作者：Frederic Lardinois
GitHub 最初在 2021 年介绍了其现在无处不在的 Copilot。当时，这家微软旗下的公司将其描述为“一种新的 AI 结对程序员，可以帮助你编写更好的代码”。增强开发人员能力并使用 AI 来消除大部分日常繁琐工作的总体使命没有改变。但正如 GitHub CPO Mario Rodriguez 在拉斯维加斯举行的 Google’s Cloud Next 大会期间接受我采访时所说的那样，该公司现在正处于 Copilot 项目的第二阶段。
“我们命名为 Copilot 是有原因的，”他说。“我们的想法是，嘿，人是中心，我们将使用 Copilot 的力量来增强这个人，消除苦力，帮助他们更快地编写代码，提高生产力，所有这些。我认为该战略的第一波在两年多的时间里发挥了作用——我们在这方面非常成功。”
在微软宣布其最新季度收益后不久的另一次采访中，GitHub CEO Thomas Dohmke 指出，Copilot 现在拥有 1500 万用户，这一数字在一定程度上是由于 GitHub 去年年底开放了 免费的 Copilot 层。
大约一年前，GitHub 推出了 Workspace，它让开发人员可以使用自然语言进行编码——远早于“vibe coding”进入主流。Rodriguez 承认 GitHub 可能在这方面有点早，但他显然也认为这是未来的发展方向，其中加入了大量的 AI 代理。
今年 2 月，GitHub 宣布了 Project Padawan，Copilot 的自主 SWE 代理，它在许多方面将 Workspace 概念提升到了一个新的水平。
“在我看来，我们现在正在进入第二波——接下来是软件开发未来发展的方向，”Rodriguez 说。“下一个发展方向完全是关于代理技术，我们认为，它实际上采用了两种模式——同步，我的意思是 VS Code 或任何其他工具，然后能够使用这些代理来增强我。但现在，通过自然语言，我可以告诉它，‘去，做这个’，代理会找出所有的步骤。”
他说，这就是 Project Padawan 的全部意义所在。这里的想法是让系统能够并行处理多个 GitHub 问题，例如，通过将多个问题分配给代理——这是单个开发人员无法做到的。
“我认为可以公平地说，2025 年是 SWE 代理之年，在越来越多的任务中，开发人员可以同步或异步地与代理合作，”Dohmke 说。
目前，在 VS Code 中，代理模式处理同步任务，Dohmke 将其比作与结对程序员一起工作，因为它本质上是 Copilot 和开发人员之间的来回交互。
Dohmke 指出，最初的 Copilot 主要是一个与 AI 模型进行结对编程的工具。
“我认为最初的 Copilot，首先是自动完成，然后是聊天，解决了这种情况，而代理模式将其扩展到您实际上将键盘交给另一个人，让他们编写一段时间，但您仍然负责[从……的角度来看]结对中的角色是如何分配的，”Dohmke 说。
但有了 Project Padawan，这种情况现在发生了变化。Dohmke 指出，大多数开发人员都在团队中工作，并且他们与团队中的同行进行全天候的沟通，而经理（或 Scrum master）则分配工作。Dohmke 认为，一旦你将 SWE 代理引入循环，开发人员就会成为多个代理开发人员的同行。例如，这些代理开发人员甚至可以与站点可靠性工程 (SRE) 代理合作，后者监控公司基础设施的健康状况，然后在出现问题时将 GitHub 问题分配给 SWE 代理。
图片来源：Frederic Lardinois/The New Stack。
“这就是对等程序员，你基本上会成为一组代理的对等方，或者，正如我喜欢称呼的那样，代理的交响乐团，”Dohmke 说。“现在，他们仍然在为人类开发人员工作，对吧？那是交响乐团的指挥，因为归根结底，这些代理仍然需要分配给它们工作，并且在流程结束时，需要有人来审查。”
现在，Rodriguez 说，该团队完全专注于执行这个代理愿景，这在一定程度上成为可能，因为自 GitHub 首次演示 Workspace 以来，模型本身已经变得更加复杂。Rodriguez 指出，例如，在 Workspace 的早期，GitHub——以及用户——正在处理规划阶段。但是现在，由于模型在自我规划方面变得更好，并且还具有调用工具的能力，因此模型本身可以处理大部分这些工作。
“现在这些模型可以比以前更好地选择合适的工具。仍然需要做更多的事情，但是一旦你得到一个非常擅长规划，非常擅长选择合适的工具，然后他们继续在代码编写和理解方面变得更好——一旦你有了这三个组成部分，你就可以解锁以前不存在的东西，”他说。
这就是 Copilot 最近推出的 Agent Mode 的用武之地。它可以从头开始创建应用程序，或帮助开发人员调试、重构或扩展其现有应用程序。（它也可以创建文档。）
随着微软年度 Build 大会即将到来，我们很可能会在未来几天听到更多关于 Project Padowan 的状态。
显然，GitHub 并不是这个游戏中唯一的公司，即使它是首批推出 AI 代码完成工具的公司之一，像 Cursor、replit、Windsurf 等公司可能几乎拥有与 GitHub 在这个领域一样多的关注度。
“我认为我们将大放异彩的地方在于上下文，”Rodriguez 说。“如果你将正确的上下文传递给模型，模型会做得很好。如果你将错误的上下文传递给模型，它就不会。”
对于 GitHub 来说，这种上下文不仅仅是代码，还包括它对团队中人们如何协作的了解。“我们已经固有地拥有本质上的人员图和工作图。因此，代码图、人员图的结合，以及当我们扩展到应用程序图时，我认为这将为我们提供一种拥有上下文的方式，并且尝试看看 Copilot 可以用它做什么会非常有趣，”他说。
Rodriguez 还指出，他不担心竞争对手。“我认为这对人类来说是一件健康的事情。这是在这个领域中的正常运作方式。我认为 Thomas [Dohmke] 和我经历这件事的北极星是：我们能创造出最好的产品吗？如果我们创造出能够解决客户需求的最佳产品，那么这对我们来说就是成功，这就是我们继续痴迷的事情。”
Copilot 也可以在所有流行的 IDE 以及 GitHub.com 本身中使用，这是 Rodriguez 认为该公司具有重大优势的另一个领域。
在早期，Copilot 通过采用每月 10 美元的固定费用，为如何为此类服务收费设定了基准。随着时间的推移，它增加了额外的层级，但在今年早些时候，当它在 Copilot 中提供了一些更高端的模型时，它通过限制“高级模型请求”来稍微改变了一些。对于这些，用户将收到有限的请求分配（Pro 用户每月 300 个，新推出的每月 39 美元的 Pro+ 计划用户每月 1,500 个）。额外的请求将花费每个请求 0.04 美元。
“这是我们正在采取的一种方式，”Rodriguez 在谈到这些变化时说。“这主要是为了支持这种同步 Agent Mode 和异步 Agent Mode。所以我认为这是我们正在前进的方向。[...] 我们总是会看看我们应该如何发展我们的商业模式，以及我们想要在哪里发展它，以及我们想要如何发展它，以及所有这些事情。现在，这就是我们前进的方向。有一个许可证，然后是一个超出该许可证的消费模式。”
GitHub 及其高管经常谈论他们希望获得 10 亿用户，并让几乎任何人都可以进行编程。像它的竞争对手一样，该公司计划实现这一目标的方式是使用自然语言，并将大型语言模型 (LLM) 作为请求和实际代码之间的中介。 “我们在 2021 年对自然语言下了很大的赌注，”Rodriguez 说，“顺便说一句，Copilot 最初的优点并不是它可以提前编写一些代码。IntelliSense 那时已经可以做到这一点并自动完成任务。2021 年让我震惊的是，你可以写一条评论，在评论中输入一些内容，机器理解了它，然后能够在此之后编写一些大的东西。我一生中从未见过这种程度的准确性——而且它不是非常准确，可能只有 15% 或 20%——但没有 MLOps 管道曾经做到过。所以我认为自然语言是关键。”
他补充说：“需要跟上的是人机界面，以便能够释放你想要完成的事情。自然语言的另一个很酷的地方是，你可以用你的母语说话，并用你的母语完成事情，但在编程中，情况并非如此。”
Rodriguez 似乎并不太担心这对整体编码技能意味着什么，尤其是对于初级开发人员而言。
他说：“我认为对我们来说，需要发生的是对软件开发人员的重新定义，这就是为什么这对我们来说是 10 亿。如果你考虑一下，今天的 IDE 被称为专业开发人员，我认为这限制了人类进步的加速。在我看来，你应该去看看如果世界上 10% 的人口可以成为软件开发人员会发生什么？”
但是，当这些开发人员无法阅读和理解模型为他们编写的代码时会发生什么？Rodriguez 认为这可能是一个短期问题，但是“未来 100 年阅读代码是什么样的？”他问道。“为什么它需要如此静态？我认为你必须押注于人类，并且会有一个进化。”
当我向 Dohmke 提出类似的问题时，他给出了类似的答案，但他也补充说，在他看来，初级和高级开发人员之间的区别不是他们编写的代码量，而是代码的质量。虽然模型可能会随着时间的推移在编码方面变得更好——因此在某些方面可能更像高级开发人员本身——但它们可能仍然缺乏某些方面。
他说：“我认为，从根本上讲，他们缺乏我所说的技艺。因此，他们实际上无法取代真正的高级开发人员。他们将永远是高级开发人员的助手，是仍然负责、驾驶飞机或驱动软件生命周期的人。”