[music]

大家好，感谢各位的到来。我叫何塞·帕拉福克斯（Jose Palafox）。我在 GitHub 已经工作了六年半的时间。我是加入团队不久后，微软收购了 GitHub，随后 GitHub 又收购了一个名为 Semmel 的工具（一家安全公司）。因此，在过去五到六年里，我的主要职责一直是推动我们安全业务的发展。而在过去一年中，我重点聚焦于人工智能领域，但我的核心角色是深入一线，与客户合作探讨如何采用我们的技术，以及如何在其组织内部规模化部署这些技术。

今天我们要讨论的内容主要是关于平台上的智能体（Agents）的介绍，我喜欢将智能体分为两种不同的模式。一种是像我在流水线中后台运行的自主型智能体，另一种是我本地使用的、用于执行各种具体任务的局部智能体。接下来，我将向大家介绍如何构建这些智能体，如何思考它们的设计与扩展策略，以及利用智能体能实现哪些不同的工作流。本次演讲将保持较高层面的概览性质。

如果在会后大家有更多问题，或者想进一步交流，欢迎随时找我。演讲结束后我会留在会场后方与大家闲聊。大家可以过来和我深入探讨您的具体使用场景。这里先快速预览一下平台上可用的功能。为了让大家有个清晰的起点，我通常喜欢从 Copilot 在平台上的整体数据流入手进行基础讲解。因为很多人对 Copilot 背后的工作原理不太熟悉，也可能不了解我们所有的不同接口。

为了让大家对产品功能有个快速预览，你们可以使用几种不同的界面来与编码智能体交互。首先是 IDE（集成开发环境），其次是 GitHub CLI，这是一个轻量级的桌面界面。你可以从 CLI 中获取任何会话并进行流式传输。例如，如果你想合上笔记本电脑或暂时离开电脑一段时间，你可以将智能体委托给 github.com 让其在后台运行；或者使用命令 /remote进行流式传输，通过移动设备登录并实际操控智能体。

此外还有 SDK（软件开发工具包）。如果你想创建运行在 Slack 或 Teams 内部的智能体，或者向那些可能没有 GitHub 许可证的团队成员暴露某些特定功能，通过 SDK 可以非常轻松地实现。因此，你可以使用 CLI 或 SDK来构建应用程序。无论通过哪个入口进入系统，你最终都会接触到这个蓝色的模块，我们称之为 Cappy 或 Copilot API 服务。

这也常被称为“Harness”（框架/容器）。这是负责所有复杂工程任务的组件，它接收你的输入并进行分块处理，发送给模型；确保不重复使用来自开源提供商的内容；为你处理身份验证、指标日志记录和审计日志记录等基础设施层面的所有待办事项。当然，一旦你发送消息进来，我们会将其传递给模型提供商。

无论通过哪个入口进入系统，都会经过这个框架处理，然后我们将输出发送给模型提供商。一旦我们收到模型的返回结果，我们会对其进行过滤，然后将结果显示给你看。这就是产品背后工作原理的高层概览，帮助大家理解可以通过哪些入口接入以及如何与之交互。

现在，如果你从 CLI 开始使用，你会遇到一些内置的智能体。我认为了解这些内置智能体很有用，因为这有助于理解智能体的功能，因为实现方式有很多种——无论是称为智能体还是技能，最终都归结为标记语言。因此，看看我们如何在平台上以可利用的方式实现智能体是很有帮助的。

我输入了 /agents，这会调出 CLI 框架中默认的内置智能体列表。你可以看到我有好几个选项。例如，如果你想探索一个代码库，我不一定需要使用最大的模型来完成这项任务。因此，我们有一个专门的“研究智能体”，也就是我们的“探索者智能体”。你可以通过关键字或在 CLI 中调用 /命令来触发它。

它会启动一个使用 Haiku（小型模型）的小规模模型，去调查代码库的情况。如果你已经制定了一个计划并写好了规划文档，想要让不同的模型提供商来审计这个计划——因为它们的训练数据和权重不同——这也是可以的。例如，“橡皮鸭”是一个内置智能体，它可以验证由 Opus 模型生成、经过 GPT 等通过的计划。

你可以看到，所有这些智能体都指定了所使用的模型，这是你在构建自定义智能体时的一个选项。你可以始终控制使用的模型，并控制给予它的指令。如果这些现有的智能体无法完成你需要的任务——比如你有特定的任务、审查需求，或者必须满足合规或监管要求，并且你可能希望运行某个工具或一系列自定义的检查——那么你可以编写一个智能体。

如果你想这样做，可以使用 agent 命令，它会引导你完成将智能体添加到 CLI 环境的工作流。在这里你可以选择：是希望这个智能体现在你正在工作的 Git 项目级别可用，还是作为一个在用户层面、无论你在哪个项目中都可用的智能体。

我可能会选择在组织级别或个人用户级别创建它，然后使用 Copilot 来生成这个智能体。Copilot 会为我完成所有的脚手架搭建工作。例如，我可以生成一个检查 GitHub 变更日志的智能体……

了解，我会总结 Copilot 的最新功能或它所做的某些事情。所以我在今天早些时候已经这样做了，并使用平台内置的代理构建器生成了一个示例代理。这在所有界面中都是可用的。如果你使用 IDE，那里也有一个代理界面，可以与你一起完成类似的构建过程。

但好处在于它会搭建好所有的基础结构。比如，从一个简单的一行提示开始，“嘿，我想去查看变更日志并总结所有更改。”它会为我编写描述，格式化所有的元数据（front matter），构建成功标准，并尝试结构化方法论。它似乎知道如何编写这些文件。因此，你可以稍微“偷懒”一点，只需写出你想要完成的任务的一般描述，它就会为你填充所有细节。

当然，你可以随时进入这里编辑所有内容。比如你不喜欢它选择的源顺序（在这种情况下），我们可以更改它。例如，这个代理希望从 GitHub 路线图开始，但也许你只想直接跳转到变更日志，这样你就不会得到路线图的条目。你可以就在这里编辑它，这没什么大不了的。但这确实为你完成了所有的脚手架工作。

现在很酷的一点是，你创建了一个在测试环境中工作的代理。如果你有需要重复执行的任务，你可以调用这个代理来为你完成这些任务，这是第一步。但一旦你完成了这一步，你可能会想：“接下来我要做什么？”我认为下一步是如何分享这个代理，让其他人也能利用它。

在 Copilot 内部实现这一点的最简单方法是创建一个市场（marketplace）。市场只是一个仓库，其中一个目录里包含一些额外的 JSON 文件，声明“嘿，这是一个市场”。它赋予你在仓库内进行轻量级包管理的能力。如果我订阅了一个市场，我就可以同时更新所有代理，对它们进行版本控制等。

我可以通知人们安全漏洞的存在。内置的功能允许我与下游用户沟通。因此，当我进入公司并与他们讨论如何在组织内扩展 Copilot 的采用率时，创建市场通常是我与之合作的首要事项之一。很多时候，甚至没有中央仓库供团队贡献代理或技能。

所以如果你没有一个中心位置，你应该创建一个。基本上有一种能力可以将这些与本地客户端设备同步，然后推送不同的代理。你也可以使用组织内的特定目录或特定的仓库。例如，如果你在 GitHub 内，我处于组织级别，然后进入一个仓库，它必须命名为“GitHub Private”，这是我们使用的一种命名约定。

如果你有 GitHub 私有仓库，你将能够暴露代理文件。在这种情况下，我有三个代理，你可以看到从云代理中，我实际上可以在平台上调用该特定代理。正如我之前在图表中展示的，你可以从不同的交互区域与所有这些进行互动。这是云交互：如果我想委托给托管在平台上的云代理，我可以在这里这样做。

但好处在于，我在下拉菜单中展示的合规机器人（compliance bot）与仓库中的那个是同一个。这是一种将代理分发给团队的方式。如果我写了一个帮我检查变更日志的便捷代理，我可以将其发布在这里并与所有人分享。这将推送到每个人的 IDE 环境或 CLI 环境中，然后他们就可以调用我正在使用的同一个代理。

现在我就有了复用性：我可以在市场中发布它们，也可以直接作为资产在我的业务中发布，任何人都可以调用。这使我能够实现标准化。如果你查看所有这些产品的成本模型，使用它们最便宜的方式是获得“现金命中”（cash hits），即在常见数据上回合之间要有精确匹配。

拥有可复用的组件将提高你的现金率（即命中/成功使用的比例）。如果成本是一个顾虑，构建可复用的代理并确保人们以相同的方式解决问题，而不是每次都重新发明轮子，是降低总体账单、提高现金率的好方法。

因此，再次强调这个“.github/private”目录是你如何在组织内部向所有人共享代理的方式。你可以创建一个跨组织工作的市场，甚至可以在外部工作。我们有一个名为“awesome-co-pilot”的仓库，其中包含许多示例代理等东西。你可以将其注册为市场。

这完全是内部的，管理员可以推送它给我。有时我在与代理一起工作时做的最后一件事是希望能够跨仓库使用代理。这些合规代理面临的最大挑战之一是它们总是从代理所在的仓库开始运行。

如果我的代理生活在这个仓库中，也许它们无法在其他仓库采取行动。我需要在其他仓库启动该代理，以便它在该仓库中具有权限。在 Copilot 应用中有一个名为“Orchestrate”的命令。编排（Orchestrate）是我们跨仓库的水平扩展方案。

这将允许你设置一系列 GitHub 问题作为代理的目标，然后启动子代理来解决所有这些任务。但好处在于它会在其应该工作的仓库中启动代理。所以如果你想在微服务内部处理一个任务，比如修改 API，然后因此必须在下游的某个地方进行修改。

编排（Orchestrate）将允许你设置几个代理，以便同时跨仓库进行更改。我可以使用预定义的代理（pre-canned agents），如果它们在我可用的其他市场中，或者由我的组织管理员推送给我。我可以在这里召唤它们去各个仓库工作，并保持它们在某种程度上……

使用这个编排工具的任务，这实际上涉及三个层面：如何在本地使用智能体。在本地使用智能体有很多实用价值，但有时我不希望在本地运行智能体。我实际上希望将智能体作为仓库的一部分来运行，某些智能体可能会执行仓库中的维护任务。因此，我希望在特定仓库上以该仓库的预算运行它们，而不是使用我的个人预算。或者我想用仓库的身份来运行它，而不是用我个人的身份。并非每个智能体都需要由我来采取行动执行任务。

有些维护任务是代表项目必须完成的。当我们在这种模式下工作时，有一个名为“智能体工作流”（Agentic Workflows）的框架可以使用。这是一个相当简单的概念：Copilot CLI 可以以无头模式运行。我可以调用 Copilot CLI，使用 -p 参数并基本上传递一个一次性提示词让它去执行。如果我在 GitHub Actions 运行器或某种 CI 系统中运行它，我就有了一个在管道中为我运行的智能体。

我可以触发它在仓库发生的事件时运行。例如，在发布版本时，我想更新文档；或者每周更新我的上下文文件。在这种模型下，我有很多想要执行的维护任务。如今在发生大量智能体开发的仓库中，存在的一个最大问题是添加了大量的 spaghetti 代码（混乱的代码）和重复代码。智能体在实现函数时很懒惰，对命名空间的处理也很随意。

它们会在代码库中创建大量的常量重复。因此，你可能需要一个智能体来检查代码库，识别去重的机会，然后为你创建一系列问题单。如果使用这个智能体工作流框架，其优点在于我们会内置“人在回路”的触发器。这样你可以审查并决定何时真正花费资金进入流程的下一阶段。

在这个流程中，我看到第一个智能体可能按计划运行，它在仓库中寻找机会让我改进代码库。假设它识别出三个可以改进的地方。开发者阅读后，决定这些修复是否值得进行，并通过作为问题单评论的斜杠命令来表达。他们会进入问题单说：“好的，将此问题推进到流程的下个阶段。”

对我们来说，这可能是规划阶段。也许我会调用另一个管道智能体，即生成产品需求文档（PRD）的产品经理智能体。它将为我界定功能范围并制定计划，然后将其交给平台上的 Copilot 进行实现。随后开发者再次进入回路，可能在验收阶段查看代码并评估是否真的要将其纳入项目。

现在我有了管道智能体。管道智能体的真正酷之处在于它们的扩展能力。在本地工作的挑战在于你处于单个会话中或依赖你的设备。如果设备宕机或网络中断，工作流程就会被打断。而这些智能体在平台上运行，因此它们独立于你自主运行。

如果你想看这种工作方式的最大化示例，GitHub AW 项目本身——即构建所有这些智能体的框架——完全是由智能体构建的。该团队有一个内部目标，他们只使用移动设备进行开发，因为他们完全通过斜杠命令与该应用程序交互。

为了让你感受一下完全由智能体主导的开发项目是什么样的，这是我们的框架，里面大约有 200 个智能体在运行管道的不同部分。所有这些智能体都遵循我们在幻灯片中展示的类似工作流程，这种架构是可复用的。让我试着随机挑选其中一个看看它是做什么的。

这是检查其他智能体的每日报告，这是一个元智能体，它在监控事物。它按计划每天运行，并且有一个正在工作的 agent.md 文件。每次这个智能体运行时，都会生成一些 Markdown 报告、操作或输入给另一个智能体，然后我们继续触发它。你可以随意查看这里，有数百个这样的项目正在创建中。

GitHub 也捆绑了一些我们提供的智能体。在 GitHub Next 组织内部，有一个名为 Agentics 的项目。Agentics 有大约 30 种不同的管道智能体，你可以直接从货架上取下来在你的项目中运行。其中一些会执行我们讨论过的代码去重，还有一些是不同类型的审查者。

如果你需要 QA 审查员，或者想要一个幽默、只会讲笑话的智能体，这里就有各种各样的示例智能体可以拉取并放入管道中。但这样做的好处是将工作负载从你的机器上移开。我认为当我们重新思考成本问题时，将工作负载从本地机器移除对于优化成本至关重要。

如果我让组织里的每个人都使用 AI，并告诉他们去使用它，但我无法看到他们实际是如何使用该工具的。我就没有任何优化机会。我无法判断他们使用的智能体是否过于冗长，或者甚至是否在完成任务。我也无法知道工具调用是成功还是失败。

我无法判断他们是否对所有事情都使用智能体推理，或者是否正确构建小的 bash 脚本来执行不同的搜索功能等。对我来说有很多优化机会，但如果我看不到这些情况，我就无法进行任何优化。因此，通过将工作负载从笔记本电脑移入 CI 环境，我就能看清正在发生的事情。

每个运行的智能体都配有遥测数据（telemetry）。我可以进入 SIM 或某种日志平台查看：我的代码去重智能体是如何运行的？

仓库？这对我来说成本是多少呢？我可以基于平均令牌使用量进行调整。我还可以执行诸如“嘿，每当智能体超出其预期运行成本的第90百分位数时，就去调查为何超过阈值”这样的操作。我希望它能告诉我可以获取哪些调试信息，以便我进一步评估或改进它；或者如果我看到某个工具调用反复失败，也许我想对不同前端元数据进行A/B测试，又或者想对不同的模型进行A/B测试，看看它们是否能产生符合我要求的输出，从而让我在某个时候选择一个更便宜的模型。所有这些可能性都在于将智能体纳入流水线中。

总之，这是一次对平台中智能体的快速概览。我们讨论了如何在本地构建智能体、如何通过平台共享智能体，以及最终如何将这些智能体移入流水线。如果你想就其中任何部分进行深入交流，我会在会场后方。欢迎上前找我，或者在LinkedIn上添加我为好友并私信联系我。我很乐意继续探讨这个话题。

我在GitHub担任技术布道师角色，如果你认识我们的GitHub AE（企业专家），想与我聊天，随时可以通过他们联系我。我们也可以取得联系并进行简短的交流。非常感谢你今天的时间。