随着 AI 代理在软件开发讨论中占比日益增加，我开始思考它们对自己作为 DevOps 工程师角色可能意味着什么。它们在交付流水线中能提供哪些帮助？能够支持哪些决策？还有哪些情况我仍希望自己或他人能够牢牢掌控？
毫无疑问，DevOps 已经涉及大量的自动化。我们构建流水线来测试代码、检查问题，并在不同环境之间移动更改。但决定是否让发布继续进行需要上下文。通过的测试提供了有用的证据；但它们无法回答关于变更风险的所有问题。
这使得发布审查成为一个有趣的实验场景。代理能否帮助解释证据、突出关注点，并为批准部署的人准备更好的问题？我的意思是，我已经把代理当作同事来交流，到目前为止效果不错。
我使用 GitHub Actions 和 Microsoft Foundry 构建了一个小型概念验证，以探讨这个问题。我想了解其中的关键环节：证据如何传达给审查者、建议如何影响工作流程，以及审批如何仍然保持在人工控制之下。
本文将该实验分享给其他同样思考自己角色的 DevOps 和平台工程师。文章将逐步介绍我构建的内容、它所展示的内容，以及在生产环境中采用此方法之前仍需改进的地方。
该实现包含两部分。GitHub Actions 运行一个 确定性的发布审查，并演示环境批准门禁。另外，Microsoft Foundry 代理在游乐场中审查相同的示例证据。工作流目前尚未调用 Foundry，其预发布和生产作业模拟部署。
这一界限很重要。这是一个面向代理辅助发布流程的实用基础，并且有明确的集成路径。
仓库： balop3e/agentic-devops-poc
此概念验证展示了什么
我想探讨的问题很简单：AI 推荐如何融入发布流程，而不成为批准生产的权威。
| 组件 | 在此演示中发生的事情 |
|---|---|
| GitHub Actions | 运行测试，生成示例证据，执行审查，并排序作业。 |
| Python review script | 应用固定规则生成风险评分和建议。它不会调用 AI 模型。 |
| Microsoft Foundry agent | 通过独立的手动操作场景审查相同的证据。 |
| GitHub production environment | 为配置的审查者暂停生产作业。 |
| Deployment jobs | 打印演示消息；它们不会部署应用程序。 |
实际的单元测试在证据生成之前运行。然而，发布证据使用预设的低风险和高风险场景。其测试计数、覆盖率变化和漏洞计数是用于练习审查逻辑的预定义输入。
组件如何连接
图 1. 已实现的工作流程与独立的 Foundry 实验。在此版本中，AI 响应不会反馈到工作流程。
推送到 main 或手动运行工作流会启动构建和测试作业。该作业成功后，工作流会生成一个 JSON 证据文件并将其存储为制品。审查作业读取该制品并发布 Markdown 报告。
当审查暴露 proceed 决策时，会运行预演模拟。生产模拟此外还需要手动运行并设置 deploy_production=true、成功的预演以及满足生产环境的保护规则。
与此同时，我将证据粘贴到 Foundry 中，以探索 AI 生成解释的质量。这使得工作流演示保持可重复，同时让我能够单独检查模型的响应。
从结构化的发布证据开始
AI 审查者需要明确的输入。在未提供证据的情况下询问发布是否安全会鼓励假设。
演示使用了提交、工作流运行、目标环境、测试、变更大小、覆盖率、漏洞、数据库迁移和依赖变更等字段。以下是一个带有占位符标识符的低风险输入示例：
{
"commit_sha": "example-commit",
"workflow_run": "example-run",
"deployment_target": "production",
"total_tests": 24,
"failed_tests": 0,
"changed_files": 6,
"coverage_delta": -1.1,
"high_vulnerabilities": 0,
"critical_vulnerabilities": 0,
"database_migration": false,
"external_dependency_change": false
}
请注意，这些数字是样本数据，而非实际测量结果。模式将 coverage_delta 定义为百分点变化，从 80% 降至 78.9% 相当于 -1.1 个百分点的变化。原始演示报告中使用了百分号，精度不足。
在实际流水线中，我会从测试运行器、覆盖率报告、漏洞扫描器和部署元数据中填充这些字段。我还会加入证据时间戳和制品摘要，以便审查能够与确切的发布候选版本关联。
仓库中包含 schemas/release-evidence.schema.json。仅拥有该文件不会自动强制执行契约；当前的审查脚本会将 JSON 加载到 Python 数据类中，而不调用 JSON Schema 验证器。运行时的 schema 验证和一致性检查（例如确保失败的测试数不超过总测试数）是后续工作。
将政策与解释分离
Python 审查采用固定的评分规则。无论最终的风险标签如何，失败的测试或严重漏洞都会产生 block 建议。其他信号会加分，包括高严重性发现、更大的变更、覆盖率下降、迁移以及依赖变更。
低风险 fixture 会产生 proceed，风险等级为低，得分为零。这些是说明性评分模型的输出。零分并不能保证发布是安全的，得分也不是失败的概率。
有一个实现细节值得关注，assess_release() 可以返回 proceed_with_extra_review，但 write_github_output() 会将所有非阻塞的建议映射为 proceed。生产批准门限仍然适用，但工作流不会为该中间状态强制执行单独的额外审查流程。
在扩展此模式之前，我会明确保留该状态并定义所需的额外审查。更一般地说，政策应在代码中做出强制性决策；模型应解释证据并提出问题。
将审批纳入部署平台
在提示或报告中编写“人工审批必需”并不能强制执行审批。此演示中的相关控制是 GitHub 环境配置。
工作流的生产作业引用 production。在该环境上配置的必需审阅者规则会使作业等待。下面的简化摘录说明了这种关系；它并不是一个完整的工作流：
deploy_production:
runs-on: ubuntu-latest
needs: [agent_review, deploy_staging]
if: >-
github.event_name == 'workflow_dispatch' &&
github.event.inputs.deploy_production == 'true' &&
needs.agent_review.outputs.decision == 'proceed'
environment:
name: production
steps:
- name: Simulate deployment
run: echo "Protected job released to run."
仅凭 YAML 引用本身并不会产生审查者要求。 我仍然需要单独配置环境保护规则。为了实现独立审查，我启用了防止自审的功能，并选择了另一位符合条件的审查者。同时检查管理员旁路设置，并限制允许的部署分支或标签。GitHub 当前的文档指出，Free、Pro 和 Team 计划的必需审查者仅适用于公开仓库。请参阅 部署保护规则。
图 2. 在确定性审查和暂存仿真完成后，生产仿真将等待环境审查。
正如演示所示，工作流在此门口等待，并在获得批准后继续完成。这表明该门在该运行中起作用，但并不能证明由第二个人独立批准，也不能证明旁路已被禁用。仅凭一条打印的日志消息表明有人批准，本身并不能作为门被强制执行的证据。
在生产环境中实施时，也需要保护工作流更改和部署凭据。跳过受保护环境的作业不应拥有通往相同生产权限的另一条路径。
Azure Pipelines 可以通过对环境等资源的 审批和检查 支持类似的模式。这提供了一种将审批控制保持在 AI 响应之外的另一种方式。
探索 Microsoft Foundry 中的 AI 审查者
Foundry 部分为审查者分配一个特定的任务，解释提供的发布证据，并为批准者准备有用的上下文。
主要概念包括 Foundry 资源、项目、模型部署和代理。资源定义服务边界；项目组织工作；模型部署提供推理；代理添加说明，并在配置时提供工具。游乐场提供一个交互式环境来测试行为。Microsoft 在其 Foundry 概览 中描述了该平台。
为此次实验，我使用了 gpt-4o-mini 和一个名为 devops-release-review-agent 的代理。它记录了演示配置，而不是为每个发布过程推荐特定模型。
说明要求提供风险等级、建议、原因、对人工审查者的问题以及简洁的批准摘要。还告诉代理不要声称生产已获批准，并在测试失败或存在关键漏洞时建议阻止。
图 3. Foundry 代理审查粘贴到游乐场的证据。这与 GitHub Actions 执行是分离的。
对于提供的低风险证据，响应建议继续并向批准者提出了问题。这是一个有用的解释示例，但一次有利的响应并不能建立可靠性。该实验未展示自动修复、部署工具或多代理系统。
提示描述了预期行为，它们不是访问控制。发布审查代理不应具有批准自身部署或更改批准配置的权限。
了解在连接管道之前的权限
在设置过程中，我遇到了管理 Azure 资源与在其中使用 AI 服务之间的重要区别。
Azure 的 控制平面 负责管理任务，如创建资源和分配角色；数据平面 负责服务操作，如调用模型和使用代理。订阅所有者本身不会授予所有 Foundry 数据平面权限，门户设置可以添加单独的角色分配。
在 Foundry RBAC 文档 中检查您的身份所需的具体操作和范围。当前文档使用的名称包括 Foundry User 和 Foundry Agent Consumer，较旧的界面可能仍显示 Azure AI 角色名称。仅调用代理的身份不应不必要地获得广泛的管理权限。
对于未来的 GitHub-to-Foundry 集成，我将使用 Azure 的 OpenID Connect 和 Microsoft Entra 工作负载身份联合，而不是存储的长期客户端密钥。工作流需要 id-token: write 来请求 OIDC 令牌，Azure 角色分配决定所得到的身份可以执行什么操作。其信任配置必须与预期的仓库和工作流上下文匹配。
代理审查身份和生产部署身份应具有独立的职责和权限。
跨团队复用该模式
该仓库包含一个可复用的审查工作流和一个 Team Scaling Demo 调用者。两个示例团队使用不同的证据配置调用同一实现：
| 调用者 | 证据配置 | 预期审查结果 |
|---|---|---|
| 支付团队 | 低风险 | 继续 |
| 身份团队 | 高风险 | 阻止 |
图 4. 演示仓库中的团队特定作业复用了相同的审查实现。
成功的审查作业表示分析已完成。这并不一定意味着部署被允许；脚本可以成功生成 block 决策。调用者必须在其部署条件中消费该输出。伸缩演示本身没有部署作业。
这展示了在单个仓库内的复用。将其扩展到独立的仓库需要额外的工作。特别是，被调用工作流中的 actions/checkout 通常会检出调用者的仓库。共享的审查代码必须有意分发，例如作为版本化的操作或软件包，而不是假设其脚本存在于每个调用者中。GitHub 在 重用工作流 中文档了执行上下文。
我会让平台团队负责证据合同、审查实现、提示版本和评估用例。产品团队将提供发布证据，并保留其部署和批准配置的所有权。
我在投入生产前会添加的内容
下一次迭代应解决若干具体的差距：
- 收集并验证真实证据。 解析实际报告，拒绝缺失或不一致的字段，并将每次审查绑定到提交和可部署的制品。
- 明确集成 Foundry。 在审查作业中调用所选代理 API，并根据输出模式验证响应。保持确定性策略与 AI 建议之间的明确区别。
- 定义失败行为。 超时、模型不可用或响应格式错误绝不能静默地变成批准。应暂停以供审查或遵循已记录的回退策略。
- 将发布文本视为不可信的输入。 提交消息、拉取请求描述和日志可能包含针对模型的指令。应将它们与可信指令分开，并防止审查者修改策略或获取部署权限。
- 评估困难案例。 包括缺失的证据、相互矛盾的信号、失败的测试、关键漏洞、迁移以及试图覆盖指令的行为。当提示或模型发生变化时，重新检查行为。
- 记录决策和结果。 保留证据、策略结果、AI 输出、提示和模型版本、审查者决策以及部署结果。在声称有改进之前，衡量审查的有用性、延迟和成本。
这些是提出的增强功能，而非此仓库已展示的能力。
我学到的
能够证明或亲身体验将代理注入流程的效果对我来说非常重要。这使我能够为治理需求做好准备，不仅在执行我的工作时，而且在做出业务决策时也是如此。最有用的结果是职责划分更加清晰。GitHub Actions 执行工作流。确定性规则评估显式策略。Foundry 可以帮助解释证据。环境保护规则控制受保护作业何时可以运行。
此 PoC 演示了这些部分，但不声称已经实现完整的 AI 驱动交付平台。连接代理是下一步的技术工作；验证其有用性并保持审批边界完整是下一步的工程责任。
如果您正在探索此方法，请从您团队已经在做的发布决策开始。定义证据，使策略明确，然后测试 AI 审查者是否能帮助人们更好地理解该决策。
源代码和文档
实现与文档已于 2026 年 9 月 25 日完成审核。截图展示的是最初的演示内容；产品界面和访问要求可能会有所变化。
