00:00:00GitHub 刚刚发布了一个非常有趣的工具。它被称为“智能体工作流（Agentic Workflows）”，旨在简化
00:00:05CI/CD 流水线管理，通过提供一种使用自然语言
00:00:12编程来编排工作流的方式。这是一个非常酷的想法，它可能会使我们维护和管理
00:00:18仓库的方式发生现代化变革。在这段视频中，我们将深入了解 GitHub 智能体工作流是如何运作的，
00:00:24我还会展示如何为您自己的仓库进行设置。这将会非常有趣，
00:00:28让我们开始吧。
00:00:30GitHub 智能体工作流是 GitHub Next 和微软研究院的一个新项目，
00:00:40它是他们称为“持续 AI（Continuous AI）”宏伟愿景的一部分。其目标是超越简单的自动化，进入一个
00:00:47他们称为“生产性模糊（Productive Ambiguity）”的概念。其理念是传统 GitHub Actions 是确定性的。
00:00:54如果发生 X，就执行 Y。但像分拣 bug、更新文档
00:01:00或捕获架构缺陷这类任务，需要一定的判断力。而智能体工作流允许您
00:01:06用平实的 Markdown 描述这种判断并执行。但这同时也意味着
00:01:11需要建立一些护栏，这就是为什么它旨在采取“Action 优先”的方法。
00:01:16基本上，它继承了整个 GitHub Actions 生态系统，如团队可见的日志、机密管理
00:01:23以及可审计的权限。这样你就获得了智能体的智能，同时也拥有了
00:01:29标准 CI/CD 流水线的护栏。这些智能体默认以最小权限运行，这意味着它们
00:01:35可以分析你的代码并建议改进，但如果没有通过预定义的经过清理的路径进行明确批准，
00:01:41它们就无法执行写操作。所以基本上，这个想法是创建一个
00:01:46带有安全护栏的 AI DevOps 助手。而且设置起来非常
00:01:52简单。你只需要使用 GitHub CLI 扩展添加它，就可以开始了。
00:01:57工作流本身分为两个步骤。你首先创建一个包含
00:02:03智能体指令的 Markdown 文件，然后对该文件运行 `gh aw compile`，系统就会读取
00:02:10你的自然语言指令，并将它们转化为健壮、锁定的 GitHub Actions
00:02:16工作流，存储在指定的 `.log.yaml` 文件中。然后你将这些更改推送到你的仓库，
00:02:22智能体就会自动激活。让我们做一个小演示来看看它是如何运作的。这里
00:02:29我创建了一个空项目，首先我将创建一个简单的 Python 文件，目前只带有一些
00:02:34数据变量。稍后我们会回到这个文件，但现在这就是我们需要的全部。
00:02:39现在我们需要创建一个 `.github` 文件夹，然后在其中创建一个 `workflows` 子文件夹。并且
00:02:46确保遵循这个命名规范，以便智能体工作流在编译
00:02:51Markdown 文件时知道去哪里寻找。然后让我们创建一个名为 `agent.md` 的 Markdown 文件。这个文件基本上
00:02:57由两部分组成。第一部分是页眉，你可以在其中指定该智能体将拥有哪些权限。
00:03:03你还需要指定将使用哪个 AI 服务商。在我的例子中，我将
00:03:09使用 Copilot。之后的所有内容都可以自由发挥。你只需使用自然语言
00:03:15描述智能体需要做的事情。在这个演示中，我将创建这个“大 O 审计员”，它的工作
00:03:21是检查代码提交，计算任何新代码的大 O 复杂度，如果效率低下，
00:03:27就识别并建议更好的优化方法。我还将要求它
00:03:33以 Markdown 格式的表格显示结果，以便快速查看。现在我回到根目录并运行
00:03:38`gh-aw-compile`。如果一切正确，我们应该会收到这条消息，提示我们已经编译了
00:03:45一个新的工作流。如果我们现在查看文件树，你会注意到我们现在有一个 `.log.yaml`
00:03:51文件，这是由脚本自动编译的，还有一个名为 `aw` 的新文件夹，
00:03:57里面包含一个 GitHub Actions 日志文件。现在我们可以将这些更改推送到我们的仓库。最后
00:04:03你应该做的一件事是将你选择的 AI 服务商的 API 密钥设置为 secret，这样智能体工作流
00:04:10才能访问它。在我的例子中，我选择了 Copilot 作为引擎，所以我在这里提供我的 Copilot GitHub 令牌。
00:04:15既然一切都搞定了，我将把所有这些更改推送到 GitHub。此时，
00:04:21智能体工作流应该已经设置完毕，可以激活了。由于我配置的工作流是
00:04:26在任何新的拉取请求（PR）上激活，那么让我们创建一个新的拉取请求来测试一下。
00:04:32我现在将为我的仓库创建一个新分支。在这个新分支中，我将向我们的 `main.py` 文件添加一个
00:04:37用于搜索匹配记录的新函数。但我故意把这个函数写成
00:04:44具有非常低效的 大 O 复杂度。所以如果我提交包含此代码的拉取请求，
00:04:50我们的智能体应该会识别出该函数效率低下并建议一些改进。所以
00:04:56让我们现在试试。我已经添加了代码，推送了更改，回到 GitHub，让我们现在打开
00:05:02一个新的拉取请求。现在你会注意到，一旦我开启请求，智能体工作流流水线就会
00:05:08立即激活并开始处理我们的代码更改。流水线大约花了
00:05:13三分钟完成。现在我们看到，我们的“大 O 审计员”确实识别出了我们的函数
00:05:20效率低下。它给出了详细的解释，并像我要求的一样
00:05:26提供了一个格式良好的表格，随后是一个提出更好解决方案的部分。看，它甚至计算了
00:05:33通过实施优化方案我们可以获得的性能提升。所以我希望这个例子能向你展示，
00:05:39只需极简的设置，我们就可以使用智能体工作流在我们的代码库周围添加一些额外的安全检查。
00:05:44这就是“生产性模糊”发挥作用的地方，我们可以要求智能体
00:05:51利用其自身的判断力来解决维护代码质量和性能等高级目标。当然，
00:05:56这目前仍然是 GitHub Next 的一个研究原型，你可能会遇到
00:06:01一些延迟。而且你肯定仍然需要人工参与来验证最终检查。但是
00:06:07这是“持续 AI”更广泛愿景的一部分，我们可以利用 AI 智能体的力量来自主地
00:06:14监控和管理我们的 CI/CD 流水线。说到自治系统，如果你
00:06:19正在管理生产环境，你就知道保持一切顺利运行是一项 24/7 全天候的工作。
00:06:25这就是为什么我建议查看 Better Stack，因为我们最近推出了我们自己的 AI
00:06:31SRE，它可以帮助你在睡觉时处理值班突发事件。这样你就可以停止四处救火，转而专注于
00:06:38实际交付代码。以上就是全部内容。如果你觉得这段视频有用且
00:06:42信息丰富，请点击视频下方的点赞按钮告诉我。别忘了
00:06:47订阅我们的频道。我是来自 Better Stack 的 Andris，我们下个
00:06:52视频见。