GitHub-Agentic-Workflows-Unleash-AI-Driven-Repository-Automation

最近，GitHub推出了技术预览版的GitHub Agentic Workflows。根据GitHub的说法，这一工具利用能够理解上下文和意图的编程代理，实现了对复杂、重复性仓库任务的自动化处理。这样一来，诸如自动问题分类与标记、文档更新、持续集成故障排除、测试优化以及报告生成等工作流程都能得到有效简化。

我们最初开发GitHub Agentic Workflows，是出于对这样一个简单问题的探索：在人工智能编程代理的时代，带有严格安全机制的仓库自动化系统应该是什么样的？显然，GitHub Actions是一个很好的起点——毕竟它正是GitHub平台上实现可扩展仓库自动化的核心工具。

GitHub Agentic Workflows充分利用了大语言模型的自然语言理解能力，让开发者能够通过简单的Markdown文件来定义自动化目标，从而清晰地描述所需的处理结果。随后，编程代理会利用GitHub Actions来执行这些指令。

这种设计使得这些自动化工作流程能够在现有的权限管理、日志记录、沙箱测试以及审计机制基础上继续运行，同时还加入了额外的安全控制措施，从而确保“代理程序能够持续稳定地运行”。该架构还广泛使用了隔离式的沙箱环境，用于存放代理程序和MCP服务器，这样一旦某个组件出现故障，也不会影响到整个系统。代理程序被置于防火墙的保护之下，它们只能访问开发者明确指定的资源。

此外，该系统还设置了严格的安全机制，以确保人工智能决策功能能够安全地融入持续集成流程中。默认情况下，这些工作流程仅具有只读权限；任何写入操作，比如创建拉取请求或问题报告，都必须经过安全审核流程，这样才能确保这些操作的合法性与可控性。

GitHub指出，开发者也可以选择另一种方法：直接将Copilot或Claude等编程代理的命令行界面集成到标准的GitHub Actions YAML工作流程中。不过，这样做会赋予代理程序超出其实际所需权限的范围。

GitHub列举了一些具体的应用案例，包括自动问题分类、文档维护、代码质量优化、每日状态报告等等。这些应用体现了该公司所倡导的持续人工智能理念。根据GitHub的说法，无论是Agentic Workflows还是持续人工智能技术，都是为了辅助现有的持续集成/持续交付流程，而不是取代它们；同时，这些技术也能确保人类在诸如批准拉取请求这样的决策过程中继续发挥关键作用。

GitHub Agentic Workflows的配置信息通常保存在一个Markdown文件中，该文件包含两个部分：第一部分使用YAML格式来指定各种配置细节，比如工作流程的执行时机、所需权限、输出结果以及使用的工具；第二部分则用自然语言来描述具体的任务内容。以下是一个示例：

# 每日仓库状态报告

为维护者生成每日状态报告，内容应包括：
- 最近的仓库活动（问题、拉取请求、讨论记录、版本发布、代码变更）
- 进度跟踪、目标提醒及重点事项
- 项目现状及建议
- 维护者需要采取的行动步骤

报告应简洁明了，并附上相关问题/拉取请求的链接。

在Hacker News上，woodruffw表达了对“持续人工智能”这一概念的担忧，但他也指出，使用大语言模型来生成工作流程规范其实是很有用的：

我确实认为让大语言模型帮助开发CI/CD工作流程是有价值的，但为什么非要让它参与到CI/CD的过程中去呢？

wiether指出，那种结合YAML和markdown格式的工作流程设计“糟糕至极”，完全违背了“让非技术人员也能以低代码方式创建自己的工作流程/实现CI自动化”的初衷。

最后，ljm表示担心使用智能代理型人工智能会带来额外的负担，并强调他们不希望任何形式的工作流程因生成式AI而导致他们的仓库中充斥着多余的代码重构或文档维护任务。

如前所述，GitHub的智能代理工作流程仍处于技术测试阶段，尚未准备好投入实际生产环境。如需了解更多工作流程示例，GitHub建议开发者参考Peli的Agent Factory。