GitHub Next 谈仓库自动化：CI/CD 之外需要 Continuous AI

当我谈论智能体仓库自动化时，我谈论的是从个人 AI 生产力到软件开发生命周期内 Continuous AI 的转变。编码智能体不只是开发者在终端里打开的工具。它们也可以成为按计划运行、可审计、协作式的流程，在我们睡觉时改进仓库。

这就是我演讲《智能体仓库自动化革命》的框架。我在 GitHub Next 工作，我们的使命很宽泛：探索软件开发的未来。在过去一年里，这个未来已经与 AI 密不可分，但我认为业界过度聚焦于这一变革的一面。

大家熟悉的画面是 Copilot：一位拥有强大助手的个人开发者。这很重要。个人生产力很重要。但软件开发一直还有另一极：团队流程、SDLC、围绕集成、部署、质量、分诊和协作的持续自动化。

我的观点是，我们应该在 CI 和 CD 之外增加第三根支柱：Continuous AI。

把这场演讲用作智能体上下文

Tessl 已将我 AI Native DevCon 演讲转化为你的智能体可用作上下文的技能。你也可以观看完整录像。

什么是 Continuous AI？

Continuous AI 是在持续进行的软件流程中使用自动化或半自动化的 AI 工作流。它是重复性的、集成的、协作式的、可审计的，并由仓库事件或计划触发。

一旦你开始留意，例子随处可见。持续文档。持续代码改进。持续分诊。持续故障分析。持续无障碍检查。持续性能调查。这些都是我们本就想要做的活动，但往往因为需要稀缺的人力时间而无法频繁进行。

重要的转变在于，AI 可以疏通其中一些工作流。与其把每个质量、文档和分诊问题都推回给个人开发者，我们可以让仓库自动化处理一些持续性的工作。

这改变了一天的感受。我曾描述过醒来看到代码改进：由安全的仓库自动化在一夜之间创建的拉取请求。以已经过分析、改进或分诊的仓库开始新的一天，与盯着休眠的问题积压是完全不同的体验。

为什么这属于 GitHub Actions？

如果 CI/CD 平台是构建和部署自动化的答案，它们也应该成为 AI 自动化答案的一部分。Continuous AI 需要一个归宿，而让这个归宿与你其他持续流程相同，可能非常合理。GitHub Actions 已经为开发者提供了一个自动化游乐场：计算、存储、网络、事件，以及一个在仓库上下文中运行工作流的熟悉场所。

GitHub Agentic Workflows 是 Continuous AI 的一种实现，建立在这一理念之上。它接收智能体工作流规范，并将其加固为 GitHub Action。重点不是简单地把提示词包进 YAML。重点是在带有护栏的平台上运行人们已经熟知的编码智能体，例如 Claude Code、Copilot CLI、Gemini CLI 或 Codex 风格的智能体。

仓库变成了一座软件工厂。一个签入的小文件就能定义工作流。加固步骤将其转化为 action。工作流可以按计划、在 issue 事件、在拉取请求上，或通过其他触发器运行。

这之所以强大，是因为工作流就位于工作已经发生的地方。它可以读取仓库数据、检查 issue、生成 pull request、评论 issue，并连接到现有的 GitHub 数据模型。

为什么安全性决定速度？

自动化只有在安全的前提下才能扩展。如果有人谈论无人值守的编码智能体自动化，却没有安全架构，那就应该立即引起质疑。

个人生产力有着不同的安全动态。开发者常常关闭摩擦，因为他们希望智能体在本地环境中运行得更快。自动化则相反。轨道越好，火车就能跑得越快。更强的边界会带来更多信心，让工作流得以运行。

GitHub Agentic Workflows 的安全模型在设计上就是狭窄的。智能体步骤以只读方式运行，不能直接访问机密，运行在容器内，并且输出通道非常有限。它可能被允许创建一个 issue 或一个 pull request，但不能在任何地方执行任意写入。

通常还有一个预加载步骤。传统的确定性自动化会收集日志、CI 数据、仓库状态或其他输入。智能体在受限环境中接收这个信息包。然后一个单独的应用阶段处理狭窄的输出，各阶段之间有威胁检测和人工监督。

Pull request 仍然是人工控制的节点。这些工作流不会合并自己的 PR。人工审查步骤是架构的一部分。

这就是智能体自动化如何变得有界且可审计，而不是仅仅又一个附带模型的无人值守脚本。

仓库辅助会改变什么？

我重点关注的一个工作流是面向维护者的仓库辅助。开源维护者承受着巨大压力。一个仓库可能有数百个未解决的 issue，每个都需要利用晚上的空闲时间来分类、分析或修复。结果就是停滞：有价值的项目名义上还活着，但没有任何进展。

Repo Assist 是一个 GitHub Agentic Workflow 示例，它会按节奏唤醒，读取自己的记忆，并从一组面向维护者的任务中进行选择。根据仓库所有者的配置方式，它可以对 issue 进行分类、提出改进建议、管理标签、发表分析评论或创建 pull request。

设计这类自动化有不同的方式。一种风格是智能体工厂或智能体动物园：许多小型工作流，每个都针对特定类型的仓库任务构建。我们写过一些示例，比如持续简化、语义函数重构、样式调整、文档编写，以及其他难以用普通确定性脚本表达的主观改进。另一种风格更接近我自己的偏好，即一个单一工作流，包含各种各样的维护者任务，并在每次运行时选择要做什么。

我在 FSharp.Data 上使用了它，那是我维护的一个仓库。在使用 Repo Assist 之前，该仓库有大量积压的 issue，几乎没有什么进展。启用之后，维护工作再次变得令人愉快。我们处理了积压问题，发布了主要版本，并将多年未解决的 issue 转化为前进的进展。

同样的模式也适用于其他仓库，不同的维护者根据自己的需求定制工作流。输出并不完全相同，因为仓库并不相同。但共同的模式是，停滞的工作可以重新流动起来。

这就是更深层的理念：仓库自动化将积压转化为可能行动的来源，而不是一堆愧疚。

我们应该如何看待代码仓库？

我现在把代码仓库看作人类与智能体的知识工厂。它是问题、拉取请求、CI 结果、文档、代码、人类和智能体汇聚的地方。

CI/CD 已经让代码仓库成为构建和部署的自动化工厂。智能体工作流为这条工厂流水线增添了新的机器：分诊、简化、重构、文档、无障碍、性能、问题分析和质量改进。

一旦你采纳这种视角，流转就变得重要。有些仓库被阻塞，有些在顺畅流转，有些因为缺乏有用的输入而闲置，有些则受制于人类或组织决策——这完全没问题。目标不是让工厂在夜里不受控制地运转，而是设计好流转，让正确的工作以正确的质量和成本推进。

因此，仓库所有者变成了工厂或流转的设计者。他们决定哪些输入重要、哪些工作流运行、允许哪些输出渠道、人类把关点设在哪里，以及工作推进前需要哪些质量检查。

这包括决定工厂何时应该被阻塞或闲置。如果某个工作流在等待人类决策，那不是失败，而是意味着自动化已经到达了组织判断至关重要的节点。错误在于清除了一个堵塞、庆祝了智能体，然后忽视了下一个工作卡住的交接点。一旦仓库变成工厂，就必须在整个系统范围内管理流转。

这就是应用于软件开发的流程工程。其他工程学科已经花了几十年思考流转、吞吐量、瓶颈、质量门禁和生产系统。我们需要在 AI 原生的软件工作中更多地运用这种思维。

质量信号从何而来？

当输入质量很高时，持续 AI 会变得尤为强大。May Walter 与 Hud 的合作是我在演讲中提到的一个好例子：生产信号可以每周供给智能体分析，使性能工作比偶尔的性能冲刺频繁得多。

如果你对生产故障、请求问题、CI 耗时、无障碍缺口或代码健康有探针，智能体工作流就能定期把这些信息呈现给团队。工作流的好坏取决于其背后的观测系统。更好的探针创造更好的自动化。

在我自己的工作中，我描述了针对 N+1 数据库请求和 CI 改进等问题的子工厂。重点不是手动修复一个问题然后继续，而是退后一步，添加质量门禁或改进工作流，让整个工厂下次流转得更好。

这就是把智能体当作一次性助手与把智能体当作仓库自动化一部分之间的区别。

工作会怎样？

一个常见的担忧是，AI 自动化只是取代了已经在做的工作。我认为这是错误的模型。有大量工作今天没有被做，是因为受限于人力或成本太高。

性能冲刺不够频繁。无障碍检查资源不足。旧问题无人重新审视。文档变得过时。仓库陷入沉寂。质量改进因为没人有时间而等待。

持续 AI 让一些以前负担不起的工作成为可能。这并不会取代人类，而是将人类的角色转变为设计流转、审查输出、设置门禁，以及决定哪些自动化值得运行。

这就是我在 AI Native DevCon London 上提出的论点：智能体驱动的代码仓库自动化革命，不仅仅是为了让单个开发者变得更快。它的意义在于将代码仓库转变为更安全、更持续的人机软件工厂。