从笔记本到流水线：用 GitHub Copilot 规模化自定义智能体

简要描述Brief Description

从你的笔记本电脑到流水线：借助 GitHub Copilot 扩展自定义智能体规模From Your Laptop to the Pipeline: Scaling Custom Agents with GitHub Copilot

目录Table of Contents

• 简介
  Intro
• 本地代理与自主代理
  Local vs autonomous agents
• Copilot 的底层工作原理
  How Copilot works under the hood
• CLI 中的内置代理
  Built-in agents in the CLI
• 构建自定义代理
  Building a custom agent
• 通过市场共享智能体
  Sharing agents with a marketplace
• 跨仓库代理
  Agents across repositories
• 智能体工作流：CI 中的智能体
  Agentic Workflows: agents in CI
• 从议题触发代理
  Triggering agents from issues
• 为什么流水线代理能够扩展规模
  Why pipeline agents scale
• 一个仓库中有 200 个代理
  200 agents in one repo
• 能够监控自身成本的智能体
  Agents that watch their own cost
• 总结
  Wrap-up

简介Intro

主持人：大家好，感谢各位到场。我叫 Jose Palafox，在 GitHub 工作了六年半。我是在微软收购 GitHub 后不久加入团队的，之后没过多久，GitHub 又收购了一款名为 Semmel 的工具。我们还收购了一家安全公司。过去五六年，我在 GitHub 的工作主要是拓展我们的安全业务。过去一年，我的工作重点基本转向了 AI；不过，我的职责是深入一线，与客户合作，探讨他们如何采用我们的技术，以及如何在组织内部扩大技术的应用规模。今天我们要聊的，主要是平台上的智能体入门介绍，大致分为两……Host: Hey everybody, thanks for coming. My name's Jose Palafox. I've been at GitHub for 6 and 1/2 years. So, I joined the team right after the Microsoft acquisition of GitHub and then shortly after GitHub acquired a tool called Semmel. We made an acquisition of a security company. And so, my role at GitHub really has been growing our security business for the last five or six years. In the last year, I really kind of focused on AI, but my role is to work in the field working with customers on how do they adopt our technology, how to think about scaling our technology inside of their organization. So, today what we're going to talk about is really just like an introduction to agents on the platform and there's sort of two

本地代理与自主代理Local vs autonomous agents

我喜欢从不同模式来理解智能体。一类是我放在流水线中运行的自主智能体，另一类是我用来完成各种工作的本地智能体。接下来，我会带大家了解如何构建它们、如何看待它们、如何考虑扩展它们，以及使用智能体可以实现哪些不同的工作流。这次演讲会比较概括。如果大家之后还有问题，想聊一聊，欢迎来找我。演讲结束后，我会在房间后面待一会儿，大家可以过来和我聊聊。我们可以进一步深入讨论你们的具体应用场景。下面先快速预览一下平台上提供的一些功能。为了开个头，我总喜欢先从……入手，建立一个基准。different modes that I like to think of agents in. There's like autonomous agents that I have off running in the pipeline and then I have local agents that I'm using to do various bits of work. So, I'm going to kind of walk you through sort of how to build those, how to think about them, how to think about scaling them, and think about different workflows that are possible using agents. This talk is going to be fairly high-level. So, if you have additional questions afterwards, you want to chat, feel free to grab me. I'll kind of hang out right after the talk in the back of the room. You can feel free to come by and chat with me afterwards. We can talk a little bit deeper about your use cases. This is a quick preview of just kind of things that are available on the platform. Just getting us started, I always like to baseline with sort of the

Copilot 的底层工作原理How Copilot works under the hood

Copilot 在平台上的整体数据流，因为很多人并不熟悉 Copilot 在底层是如何工作的，也可能不熟悉我们提供的各种不同界面。先快速介绍一下这款产品提供的功能：你可以通过几种不同的界面与编码代理交互，包括 IDE 和 GitHub CLI。GitHub CLI 是一种轻量级界面，可在你的桌面上运行。你可以对 CLI 中的任何会话进行流式传输。因此，如果你想合上笔记本电脑，或暂时离开电脑，可以将代理任务委派到 github.com，让它在后台运行；也可以使用 {slash} remote 命令进行流式传输。这样你就可以通过移动设备登录，并直接在移动设备上操控代理。overall data flow of how Copilot works on the platform because a lot of people aren't familiar with how Copilot works under the hood and and maybe aren't familiar with all of our different interfaces. So, just to give you a quick preview of what the product has, you've got a handful of different interfaces that you can use to interact with the coding agent. You've got the IDE, you've got the GitHub CLI, which is sort of a lightweight interface that sits on your desktop. You can take any session from the CLI and you can stream it. So, if you want to you know, close your laptop or walk away from your laptop for a period of time, you can either delegate the agent to github.com and have it go run in the background or you can stream it using a command {slash} remote and it'll let you log in through your mobile device and actually steer the agent from your mobile device.

你也可以使用 SDK。因此，如果你想创建运行在 Slack 或 Teams 内部的智能体，或者想通过 SDK 将某些单独的功能提供给一组可能没有 GitHub 许可证的团队成员，都可以相当轻松地实现。你可以使用 CLI 或 SDK 构建应用程序。无论你从上方哪个入口进入，都会到达这里的蓝色方框，我们称之为 Cappy，也就是 Copilot API 服务；它也被称为“运行框架”（harness），对吧？它负责处理所有复杂的工程任务：接收你的输入并将其拆分成块，再发送给模型；确保不会重复任何来自开源提供商的内容；为你处理身份验证、指标日志记录和审计日志记录，以及平台基础设施方面的各种琐事。You've also got the SDK. So, if you want to create agents that live inside of Slack or inside of Teams, I'm exposed some individual functionality to a set of team members that maybe don't have a GitHub license, you can do that pretty easily through the through the SDK. So, you can build applications using the CLI or the SDK. Regardless of what door you go through on the top, you're going to hit this blue box here and this is what we call Cappy or the Copilot API service and this is also referred to as like the harness, right? This is the thing that does all the difficult engineering tasks taking your input and chunking them and sending them to the models making sure that you're not repeating any content from open source providers, dealing with authentication for you, dealing with metrics logging, dealing with audit logging, all of the kind of like to-dos of the infrastructure of the platform.

然后，当然，一旦你发送消息，我们就会接收它并传递给模型提供商。所以，无论你从哪个入口进入，都会经过这个运行框架，然后我们会把你的输出发送给模型提供商。收到返回结果后，我们会对其进行筛选，然后展示给你。这大致就是产品在底层的工作方式，让你对可以通过哪些不同入口使用它，以及在哪些环节可以与它交互，有一个高层次的了解。And then of course, once you send a message in, we take that and we pass it to the model providers. So, regardless of which door you go into, you hit the harness and then we take your output and we send it to the model providers. Once we get the output back, we filter it and then display that back to you. So, that's sort of under the hood how the product works just so you kind of have like a high-level understanding of the different doors you can go through and and where you can touch it.

CLI 中的内置智能体Built-in agents in the CLI

现在，比如说如果你从 CLI 入手，就会有一些内置代理。我觉得了解一下这些内置代理很有用，这样可以弄清楚代理是做什么的，因为实现代理或技能的方式有很多种，而说到底，它们最终都是用 Markdown 标记的。因此，看看我们如何在平台中实现代理，以及你可以如何使用它们，会很有帮助。我只要输入 {slash} agents，就会显示 CLI 框架自带的默认代理。你可以看到这里有好几个，对吧？比如说，如果我想探索一个代码库，不一定非要用最大的模型来做这件事。因此，我们提供了一个专门的研究代理，也就是 explorer 代理。你可以通过关键词调用它，或者在 CLI 中实际输入 {slash} 命令来调用它。它会启动一个使用 Haiku 的小型模型，然后去调查代码库，对吧？Now, if you're starting in the CLI for example, you have a handful of embedded agents and I think it's useful to kind of look at the embedded agents just to understand what agents do because there's like a lot of different you know, potential ways that you could implement whether it's an agent or a skill or you know, it all just ends up being marked down at the end of the day. So, it's useful to kind of see how um we're implementing agents in the platform in a way that uh you can utilize. So, I just type {slash} agents, and all this does is drop up the um the default agents that are part of the CLI harness here. You can see I have a handful of them, right? So, if I want to explore a code base, for example, I don't necessarily want to use the biggest model possible uh in order to do that. So, we have a specialized research agent, which is our explorer agent, um that you can call or invoke uh through a keyword or actually invoking like the {slash} command um in in in the CLI, and it'll spin up, you know, a small model using Haiku, um and go and investigate a code base, right?

如果你，嗯，你知道，已经制定了一个计划，对吧？而且你已经写好了规划文档，想让另一个模型提供商来审核这个计划，因为它有不同的训练数据和不同的模型权重，那好，你可以这么做。Rubber Duck 就像一个内嵌的智能体，它会验证我们知道是由 Opus 编写的计划，再让 GPT 之类的模型过一遍。嗯，你可以看到，所有这些模型——或者说所有这些智能体——都会指定所用的模型，而这正是你构建自定义智能体时可选的配置之一。你可以随时控制自己使用的模型，也可以控制提供给它的指令。所以，如果这些模型或这些智能体没有完成你需要它们做的事，对吧？If you um you know, have a plan that you've done, right? And you've written out a planning document, and you want a different model provider to come and audit the plan because it has different training data and different model weighting, uh then fine, you can do that. Rubber duck is like a embedded agent that will validate a plan that we know was written by Opus with, you know, a pass from GPT or something like that. Um you can see in all of these models they specify or in all of these agents they specify the model, and that's one of the options that you have when you're building custom agents. You can always control the model that you're using, and then you control the instructions that you're giving it. So, if these model or these um agents aren't doing, you know, something that you need done, right?

如果你有一项具体任务或审查，或者有必须满足的合规或监管要求，也许你有想运行的工具，或者一系列为你量身定制的检查。也许你想编写一个智能体。你知道，如果你愿意，可以直接在这里使用 agent 命令，它会带你完成一个工作流程……If you have a specific task or a review or you have a compliance or um regulatory requirement that you have to meet, and maybe you have a tool that you want to run or um a series of checks that you want to have that are custom to you. May maybe you want to write an agent. And you know, if you uh want, you can you can just use the agent command here, and it will um set you through like a a work uh a

构建自定义智能体Building a custom agent

将代理添加到 CLI 环境中的工作流程。这里我可以选择：要把它设在项目级别，比如我正在处理的 Git 项目中；还是把它设为用户级别的代理，这样无论我正在处理哪个项目，都可以使用，对吧？嗯，也许我会把它设在组织级别，或者我的个人用户级别。然后我就用 Copilot 创建它。Copilot 会帮我完成所有脚手架搭建。比如说，我可以生成一个代理，让它查看 GitHub 的变更日志，然后总结所有最新功能，或者总结 Copilot 做过的某些事情。今天早些时候我就这么做了，用平台内置的这个代理构建器生成了一个示例代理，对吧？workflow to add an agent into your your CLI environment. So, here I'm getting to pick, you know, do I want this on the project level like in the Git project that I'm working on, or do I want this as like a um an agent that's available regardless of which project I'm working on at the user level, right? Um so, maybe I'll say I'm out of that at the at the org level or at my my my individual user level. And then I go ahead and create this with Copilot. Copilot will do all the scaffolding for me. So, um if I uh want, I can generate an agent that maybe uh you know, looks at the GitHub change log and it um you know, will summarize all of the latest features or something that that Copilot did. So, I did that earlier today and just generated a sample agent, you know, using this uh agent builder that's built into the platform, right?

而且所有这些界面中都能使用。嗯，你知道，如果你有 IDE，里面也有一个 agents 界面，可以用同样的方式和你一起完成构建流程。不过好处是，它会把所有东西都搭建好。比如，你只要输入一句简单的提示：“嘿，我想去看变更日志并总结所有改动。”它就会帮我写好描述，整理好所有前置元数据，构建成功标准，也会试着梳理方法。它好像就是知道该怎么编写这些文件。所以，你可以稍微偷个懒，对吧？你只要大致描述一下想完成什么，我们就会帮你补全所有细节。当然，你也可以在这里编辑所有内容，对吧？And this is available in all of the interfaces. Um you know, if you have the IDE, you have an agents interface there as well that will do the same kind of build build process with you. But, what's nice is it scaffolds everything out. So, from like a basic one-line prompt that just says, "Hey, I want to go to the change log and summarize all the changes." It'll write the description for me. It'll format all the front matter. It will um structure success criteria. It'll take an attempt at structuring methodology. Like, it kind of knows how to write these files. So, you get to be uh you know, somewhat lazy with it, right? You you you just write a general description of what you want to get done. We'll fill in all the specifics for you. You can of course come in here and edit all of this, right?

所以，如果你不喜欢它选择的顺序，比如这里选取信息源的顺序，我们可以改，对吧？比如说，这里想先用 GitHub 路线图，但你可能希望它直接跳到变更日志，这样就不会获取路线图里的条目。你可以直接在这里编辑，对吧？没什么大不了的。不过，它已经帮你完成了所有脚手架工作。现在好的一点是，你已经创建了一个能在这个运行框架中工作的智能体。所以，如果你有需要重复执行的任务，就可以调用这个智能体来帮你完成，对吧？这算是第一步。不过，做到这一步之后，你大概就会想：“接下来我该做什么？”我觉得，下一步就是想想如何分享这个智能体，对吧？其他人要如何利用它？So, if you don't like uh the order that it's um picking, you know, sources in this case, um we could change that, right? Like, this one wants to start with, you know, use the GitHub roadmap, but maybe you want it just to jump straight to the change log, so you're not getting roadmap items. You know, you can just edit it here, right? There's no no big deal. But, this does all the scaffolding work for you. What's nice now is you've created like an agent that works in the harness. So, if you have repeat tasks that you have to do, you can call this agent to do those tasks for you, right? Um that that's kind of step one. Uh but, once you do that, you're kind of like, "What's the next thing that I got to go do?" And I think um you know, the next thing is how do I share this agent, right? How do other people uh take advantage of it?

而在 Copilot 中实现这一点，最简单的方法就是这样。And the easiest way to do that inside of Copilot is to do that

与市场共享智能体Sharing agents with a marketplace

通过建立一个市场来实现。市场其实就是一个仓库，只是在其中一个目录里多了一点 JSON，用来说明：“嘿，这是一个市场。”它能为你在仓库内提供一些轻量级的包管理功能。这样一来，如果我订阅了某个市场，就可以同时更新所有智能体，也可以给它们做版本管理，诸如此类。我还可以通知大家有关安全漏洞的信息。你知道，它内置了一些功能，让我能够与下游用户沟通。所以，当我开始与企业合作，探讨如何在组织内部推广 Copilot 时，建立一个市场往往是我首先会着手做的事情之一。很多时候，团队甚至没有一个中央仓库来提交智能体或技能。um by making a marketplace. So, a marketplace is just a repository with a little bit of extra uh JSON in one of the directories that says, "Hey, this is a marketplace." And what it does is it gives you some light package management capabilities inside the repo. So, if I subscribe to a marketplace, then I can update all the agents simultaneously. I can version them, things like that. I can notify people of security vulnerabilities. You know, there's features built in that allow me to communicate with the users that are downstream for me. So, creating a marketplace is oftentimes one of the first things that I work with companies on when I go in and try to talk with them about how to scale Copilot adoption inside their organization. A lot of times there's not a central repository for teams to even contribute agents or skills to.

所以，如果你没有一个中心位置，就应该创建一个，对吧？而且基本上有一种功能，可以将这些内容同步到本地客户端设备，然后推送给不同的代理。你也可以使用组织内的特定目录或特定仓库。比如说，如果你在 GitHub 里，我现在位于组织级别，然后进入了一个仓库，而它必须命名为 GitHub private，对吧？这是我们采用的命名约定；但如果你有一个 GitHub private 仓库，就可以公开代理文件。在这个例子中，我这里有三个代理，你可以看到，通过云端代理，我实际上能够在这个平台上调用那个特定代理。所以，我之前在图表中给你展示过，你可以从不同的界面与所有这些代理进行交互。So, if you don't have a central location, you should generate one, right? And there is a capability basically to sync those with the the local client device and then pushing and out different agents. You can also use a specific directory inside of your organization or specific repo. So, if you're inside of GitHub, I'm at the org level here, and then I went into a repository, and it has to be named GitHub private, right? This is a naming convention that we've used, but if you have a GitHub private repository, you'll be able to expose agent files. So, in this case, I have three agents here, and you can see from the cloud agent, I'm actually able to call that specific agent on the platform. So, I showed you earlier in the diagram, you know, you can you can interact with all of these from different surface areas.

这就是云端交互，对吧？如果我想委托给一个托管在平台上的云端智能体，就可以在这里操作。不过，这里下拉菜单里展示给你看的合规机器人，和仓库里的那个是同一个，这点很棒，对吧？所以，这是一种把智能体分发给团队的方式，对吧？比如，我编写了一个方便的智能体，能帮我检查变更日志，那么我就可以在这里发布它，并分享给其他所有人，对吧？这样一来，它就会推送到每个人的 IDE 环境或 CLI 环境中，然后他们就能调用我正在使用的同一个智能体。这样一来，我就实现了复用，对吧？比如，我可以把它们发布到市场中，也可以直接将它们作为资产发布到我的企业内部，让任何人都能调用，对吧？This is the cloud interaction, right? If I want to delegate to a cloud agent that's hosted on the platform, I can do that here. But what's nice is this compliance bot that I'm showing you here in the the drop-down is the same compliance bot that's in the repository, right? So, this is a way of distributing agents out to the team, right? So, if I write a handy agent that checks the change log for me, then I can publish it here, and I can share that with everybody else, right? So, this will push to everyone's IDE environment or push to their CLI environment for them, and then they can just call the same agent that I'm working on. So, now I have some reuse, right? Like I can publish them in a marketplace, I can publish them directly as um assets inside of my business that anybody can call, right?

这就是我能够实现标准化的方式，对吧？如果看看所有这些产品的成本模型，使用它们最省钱的方式就是获得缓存命中，对吧？你希望针对常见数据，不同轮次之间能够精确匹配。使用可复用组件会提高缓存命中率，对吧？所以，如果成本是个顾虑，那么构建可复用的智能体，并确保大家用相同的方式解决问题，而不是每次都重新造轮子，就是降低总体账单、提高缓存命中率的好方法。再说一次，这个 .github 私有目录就是你在组织内部向所有人共享智能体的方式，对吧？这样，你就可以建立一个跨组织运作、甚至能在外部使用的市场，对吧？我们有一个名为 awesome co-pilot 的代码仓库，里面有许多示例智能体之类的内容。And this is what's allowing me to do standardization, right? If you look at the cost model for all of these products, the cheapest way to use them is to get cash hits, right? You want exact matches between turns on common data. And having reusable components will drive up your cash rate, right? So, if cost is a concern, um building reusable agents and making sure that people are solving problems in the same way, uh rather than reinventing the wheel every time, is a good way to drive down your your overall bill, drive up your cash rate. So, again, this um dot GitHub private directory, this is how you would share an agent internally to everyone inside the org, right? So, you can make a marketplace that will work across organizations, that could even work, you know, externally, right? So, we have a repository called awesome co-pilot that has a bunch of um you know, example agents and things.

你可以将其注册为一个市场。这完全是内部使用的，对吧？而且这就像是管理员可以把它推送出去。有时候，我和智能体协作时，最后想做的一件事就是能够跨代码仓库使用智能体。而这些……最大的挑战是……You could register that as a marketplace. This is purely internal, right? And this is like an admin can push this out. The last thing that I want to do sometimes um when I'm working uh with an agent is I want to be able to use um agents across repositories. And the biggest challenge with these uh

跨仓库代理Agents across repositories

例如，合规代理的特点之一是，它们总是从代理所在的仓库开始运行。所以，如果我的代理位于这个仓库中，它们可能无法在其他仓库中采取操作，对吧？我需要在另一个仓库中启动代理，这样它才拥有该仓库的权限。在 Copilot 应用中，有一个名为 orchestrate 的命令。orchestrate 用于跨仓库横向扩展。因此，你可以将一系列 GitHub Issue 设为代理的目标，然后启动多个子代理来处理所有这些任务。好处是，它会在代理应该工作的仓库中启动代理。所以，如果你想在某个微服务中执行一项任务，比如修改 API，然后还要因此在下游某处做出更改，Orchestrate 就能让你设置多个代理，同时进行跨仓库更改。compliance agents, for example, is that they're always starting in the repo where the agent lives. So, if I have agents living in this repository, um they maybe can't take action in other repositories, right? I need to start the agent in the other repo so that it has permissions in that repository. Um inside of the co-pilot app, there's a command called orchestrate. Um and orchestrate is our horizontal scaling for across repo. Uh so, this will allow you to set a series of GitHub issues as uh goals for the agent, and then spin up sub agents to address all of those tasks. But, what's nice is that it will spin up agents in the repository that it's supposed to be working in. So, if you want to take a task inside of a microservice where you're like modifying an API and then you have to make a change somewhere downstream because of that, Orchestrate will allow you to set up several agents that are going to make cross-repo changes simultaneously.

所以，我可以使用那些预置智能体，对吧？如果我能在其他市场中使用它们，或者组织管理员把它们推送给我，我就可以在这里调用它们，让它们在各个代码仓库中执行任务，并通过这个 Orchestrate 工具让它们大致按计划行事。这其实就是如何在本地使用智能体的三个层面，对吧？在本地使用智能体很有用，对吧？但有时我不想在本地运行智能体。实际上，我希望把智能体作为代码仓库的一部分来运行，而且某些智能体可能会在仓库中执行维护任务。所以，我希望让它们在仓库中运行，使用该仓库的预算，而不是我的预算，对吧？或者我希望它使用仓库的身份，而不是我的身份，对吧？并不是每个智能体执行操作时都必须以我的身份进行。So, I can use the the pre-canned agents, right? If they're available to me in those other marketplaces or being pushed to me by my org admin, I can kind of summon them here to go do work in individual repositories and keep them sort of on task using this this Orchestrate tool. And that's really like three layers of how do I use agents locally, right? Like in in using agents locally has a lot of utility, right? But sometimes I don't want to run an agent locally. I actually want the agent to be run as a part of the repository and certain agents maybe are going to be performing like maintenance tasks in the repo. And so, I want to run them in the repo on that repo's budget, not on my budget, right? Or I want to run it using the repo identity, not my identity, right? Not every agent needs to be me taking an action.

你知道，这可能是一个需要代表项目完成的维护任务。当我们采用那种模式工作时，我们有一个……You know, it's it's maybe a maintenance task that has to be done on behalf of of the project. When we're working in that model, we have a

代理式工作流：CI 中的代理Agentic Workflows: agents in CI

可以使用一种称为智能体工作流的框架。智能体工作流的概念相当简单，比如可以在无头模式下使用 Copilot CLI。这样，我就可以调用 Copilot CLI，使用 -P 命令，基本上给它传入一个一次性提示，让它执行任务。然后，如果我把它放到 GitHub Actions 运行器或某个 CI 系统中运行，就有一个智能体在流水线中替我工作了，对吧？我可以根据仓库中发生的事件触发它。比如发布新版本时，我想更新文档；或者每周更新一次上下文文件。又或者，在这种模式下，我可能有各种维护任务要处理。比如，现在在大量进行智能体开发的代码仓库中，最大的问题之一就是不断加入大量杂乱无章的代码和重复代码。framework that you can use called agentic workflows. And agentic workflows is a pretty simple concept like the Copilot CLI can be used in a headless mode. So, I can call the Copilot CLI, I can use the dash P command and basically pass it a single prompt one-shot prompt for it to go do. And then if I take that and I run that inside of a GitHub Actions runner or in some CI system, then I have an agent that's running in a pipeline for me, right? So, I can trigger it on events that are happening in the repo. Like on a release, I want to update I want to update documentation. Or every week, I want to update my context files. Or, you know, in maybe a model like this, I have various maintenance tasks that I want to go do. Like one of the biggest problems today that's happening in repositories where a lot of agentic development is happening is there's lots of spaghetti code getting added, lots of duplicate code.

就像这些智能体在实现函数和命名空间方面都很懒。所以它们只会在代码库里不断制造重复的常量。也许你会想要一个智能体，让它检查代码库，找出可以去重的代码，然后为你创建一系列 issue。如果你使用这个框架，也就是智能体工作流框架，好处是我们会为你内置人在回路中的触发机制，这样你就可以审核并决定何时真正投入资金进入工作流的下一阶段。在这个流程中，你可以看到，第一个智能体也许会按 cron 计划运行。它会检查代码仓库，并找出三处可以改进代码库的地方。Like the agents are lazy about implementing, you know, functions and they're really lazy about namespacing. So, they'll just like create constant duplication inside the code base. So, maybe you want an agent that looks inside the code base, identifies opportunities for deduplication of code, and then creates a series of issues for you. And if you use this framework, this agentic workflows framework, what's nice is we'll we'll build in human in the loop triggers for you so that you can review and decide when you're actually going to spend money on side of the next phase of the flow. So, in this flow here, you see I have the first agent maybe running on a cron schedule. It's looking in the repo. It identifies, you know, three items where there's opportunity for me to make improvement in the code base.

好，很好。开发人员读到这些内容后，会决定这些问题值不值得修复。然后他们Okay, great. The developer reads that and then makes a decision about whether or not those things are worth fixing. And they

从 issue 触发代理Triggering agents from issues

把这个表达成一个斜杠命令，他们可以把它作为 issue 评论发出来，对吧？所以他们进入 issue，然后说：“好，把这个 issue 推进到流程的下一阶段”，对吧？对我们来说，下一阶段可能是规划阶段，对吧？所以，也许我会调用另一个流水线智能体，对吧？也就是生成 PRD 的产品经理智能体，对吧？它会帮我确定这个功能的范围，生成一份计划，然后把计划交给平台中的 Copilot 来实现。接着，开发者可能会在验收阶段重新参与进来，对吧？我们来看看代码，评估一下是否真的要把它纳入项目。现在我有了流水线智能体。而真正酷的是……express that through a slash command that they can make as an issue comment, right? So, they they go to the issue and they say, "Okay, advance this issue to the next phase of the process, right?" For us, that's maybe a planning phase, right? So, maybe I'm going to call another pipeline agent, right? Which is the PRD generating product manager agent, right? That's going to scope the feature for me. It generates a plan. It hands it off to co-pilot in the platform for implementation. And then the developer comes back in the loop maybe at an acceptance phase, right? Let's look at the code and evaluate whether or not we actually want to take it in the project. Now I've got pipeline agents. And what's really cool about the

流水线智能体为何能够扩展Why pipeline agents scale

流水线代理就是它们实现规模化的方式。你知道，在本地工作面临的挑战是，你只能在一个会话中操作，或者只能用你的设备。如果设备出故障，或者网络中断，你知道，你的工作流程就会被打断。而这些代理运行在平台上，所以它们可以脱离你的操作自主运行。如果你想看看这种做法的极致形式，GitHub AW 项目本身——也就是构建所有这些代理的框架——完全是由代理构建的。而这个团队有个内部目标：他们只用移动设备进行开发，因为他们完全是通过那些斜杠命令与这个应用交互的，对吧？所以，只是想给你一个……pipeline agents is how they scale. You know, the the the the challenge with working locally is you're on like a single session or you're on your device. If your device goes down or you lose network activity, you know, your your workflow is interrupted. These are running in the platform, so they're running autonomously from you. If you want to see like a maximalist approach to how this works, the GitHub AW project itself, like the thing that is the framework for building all these agents, it is built entirely by agents. And this team has sort of an internal goal that they're only going to do their development on their mobile devices because they interact entirely with this application through those slash commands, right? So just to give you a

一个仓库中的 200 个智能体200 agents in one repo

大概感受一下一个完全由智能体主导的开发项目是什么样子。这就是我们的框架，对吧？里面有，我也说不准，大概 200 个智能体，分别负责流水线中的不同环节，对吧？它们都遵循类似的工作流，就是我们刚才那张幻灯片上展示的流程，对吧？这种架构是可以复用的。我看看能不能随便挑一个。这里我有点儿随机挑的意思，我们看看这个是做什么的，对吧？它会检查其他智能体的每日报告，对吧？这是一个负责观察其他事务的元智能体。它按日程每天运行，并且有自己的 agent.md 文件在这里运作，对吧？所以每次它运行时，都会生成一份 Markdown 报告，或者为另一个智能体生成某项操作或输入，然后我们就继续触发它。feel of like what a fully, you know, agent-led development project looks like, this is this is our our our framework, right? And it has I don't know, 200 agents in here that are all running different parts of the pipeline, right? And all of these follow a similar workflow that we just showed on that on that slide, right? That architecture is reusable. So let me see if I can just pick one of these. I'm a little bit picking at random here, but let's see what this one does, right? So this is checking daily reports on other agents, right? So this is a meta agent that's looking on things. It's running on a daily schedule and it has, you know, its agent.md file that's working away here, right? So every time this thing runs, it's generating some markdown report or some action or input for another agent, and then we're just continuing to trigger it.

你可以随意浏览一下这里。这里有数百个用于构建这个项目的智能体。GetHub 也有很多我们打包好的智能体。在我们的 GetHub Next 组织里，有一个叫 Agentics 的项目。Agentics 里有大约 30 种不同的流水线智能体，你可能会感兴趣，可以直接拿来用在自己的项目中。其中一些可以执行我们之前聊过的代码去重；另一些则是不同类型的审查者，比如 QA 审查者，或者你想要一个风趣、爱开玩笑的审查者。这里有各种各样的示例智能体，你可以挑选并放进流水线里。这样做的好处是，它能把工作负载从你的机器上卸下来。而且我觉得，回到成本这个话题，把工作负载从你的机器上卸下来，对优化成本至关重要，对吧？You can feel free to take a look through here. There's hundreds of these that are creating this project. GetHub also has a bunch of them that we've bundled up. So inside of our GetHub next organization, there's this project called Agentics. Agentics has 30 or so different pipeline agents that you may be interested in just pulling off the shelf and running in your project. Some of these will do the code deduplication that we talked about. Some of them are different types of reviewers, so if you need a QA reviewer or, you know, you want one that's funny and just makes jokes, like there's all kinds of different sample agents here that you can pull and drop into the pipeline. But what's nice about this is it gets the workload off of your machine. And I think when we shift back to thinking about cost, getting the workload off of your machine is key for optimizing cost, right?

如果我让组织里的每个人都用 AI，并告诉他们去用，但我却看不到他们实际上是怎么使用这个工具的，那我就没有任何优化的机会，对吧？我根本看不到他们使用的智能体是不是话太多，或者是否真的完成了任务。我也看不到工具调用发生时是成功还是失败。我、我、我也不知道他们是不是所有事情都在用智能体推理，还是说他们有没有正确地编写一些小型 bash 脚本，来执行不同的搜索功能之类的。对我来说，有很多优化的机会，但如果我看不到这些情况，就没法做任何优化。所以，把工作负载从笔记本电脑上移走，放到 CI 里，我就能看到发生了什么，对吧？If I'm having everyone in my organization work with AI and I'm telling them to go use it, but I can't see how they're actually working with the tool. I don't have any opportunity to optimize, right? I can't actually see whether or not the agents that they're using are too verbose or are even achieving the task. I can't tell when tool calls are happening if they're successful or unsuccessful. I I I can't tell if they're using agent reasoning for all types of things or if they're you know correctly building little bash scripts to actually go and do uh different search functions and things like that. Like there's lots of optimization opportunities for me, but if I can't see it, I can't do any of that optimization. So, by getting the workload off of the laptop and moving it into CI, I get to see what's happening, right?

我让每一个 agent 都在运行，并且都接入了 Hotel 做埋点。所以，我可以去 SIM 或某种日志平台查看：我的代码重复检测 agent 在各个代码仓库中的运行情况如何？它花了我多少钱？对吧？我可以按平均 token 使用量进行细分，也可以做一些类似的事情。I have every single agent running and it's instrumented with hotel. So, I can go to a SIM or some kind of logging platform and look, does my code duplication agent agent, how does it run across repositories? How much does it cost me, right? I can pivot on average token use. I can also do things like

会监控自身成本的智能体Agents that watch their own cost

比如说：“嘿，每当某个智能体的运行成本超过我预期的 P90 时，就去调查它为什么超出了阈值，好吗？我希望它告诉我可以收集哪些调试信息，以便进一步评估或改进它，好吗？或者，如果我发现某个工具调用一次又一次地失败，也许我想对不同的前置提示内容进行 A/B 测试，或者对不同的模型进行 A/B 测试，看看它们能不能给我生成合适的输出，这样我以后就能选一个更便宜的模型，对吧？只要把智能体接入工作流，这些都能实现。总之，这就是对平台中的智能体做的一次快速、粗略的介绍。我们聊了如何构建一个……”say, "Hey, every time that an agent exceeds its P90 for what I expect it to cost me to run, go investigate why it exceeded its its threshold, right? I want it to tell me what debugging information I can I can take to evaluate it further or to improve it, right? Or if I see that a tool call's failing over and over, maybe I want to AB test different front matter or maybe I want to AB test different models and see if they produce like the the right output for me so I can pick a cheaper model at some point, right? All of this stuff is possible once I get the agents into the pipeline. Anyhow, so this was a quick and dirty kind of tour of agents in the platform, right? We talked through building an

总结Wrap-up

在本地运行 agent、通过平台共享 agent，最后再把这些 agent 接入工作流。如果你想进一步聊聊其中任何部分，我会在后面。欢迎过来找我，也可以在 LinkedIn 上加我并给我发消息。我很乐意继续交流。嗯，我在 GitHub 从事客户拓展工作，所以如果你认识自己的 GitHub 客户经理，也想和我聊聊，欢迎通过他们联系我。嗯，我们可以取得联系，简单聊一聊。非常感谢大家今天抽出时间。agent locally, sharing agents through the platform, and then eventually moving those agents into the pipeline. If you want to talk more about any part of that, I'll be in the back. Feel free to come up and grab me or you can add me on LinkedIn and ping me. I'm happy to continue the conversation. Um, I work at GitHub in a field capacity, so if you know your GitHub AE and you want to chat with me, uh, feel free to reach out with them. Uh, we we can get in touch and and have a quick conversation as well. Thanks so much for your time today.