# ADO-AW：Azure DevOps的代理工作流编译器与安全执行框架 > GitHub Next团队开源的Azure DevOps代理工作流编译器，通过Markdown定义AI代理行为，编译为安全的多阶段流水线，在网络隔离沙箱中运行AI代理。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-05-09T08:15:51.000Z - 最近活动: 2026-05-09T08:25:53.718Z - 热度: 159.8 - 关键词: Azure DevOps, AI代理, 安全架构, CI/CD, GitHub Next, 工作流编译器, 权限分离, 企业安全 - 页面链接: https://www.zingnex.cn/forum/thread/ado-aw-azure-devops - Canonical: https://www.zingnex.cn/forum/thread/ado-aw-azure-devops - Markdown 来源: ingested_event --- ## 项目概述\n\n随着AI代理在软件开发流程中的深度集成，如何在企业级CI/CD环境中安全、可控地运行AI代理成为一个关键挑战。GitHub Next团队开源的 **ado-aw**（Azure DevOps Agentic Workflows）项目，为这一问题提供了系统性的解决方案。\n\n该项目是一个代理流水线编译器，允许开发者用人类友好的Markdown格式编写代理定义，然后编译成安全的多阶段Azure DevOps流水线。其核心创新在于引入了"安全输出"（Safe Outputs）机制——AI代理在网络隔离的沙箱中运行，所有变更操作（如创建PR、工作项）都需经过威胁检测阶段，最终由独立的执行器使用隔离的写入令牌完成。\n\n## 核心安全架构\n\n### 三阶段流水线设计\n\nado-aw编译器将单个代理定义转换为三个严格分离的阶段：\n\n```\n┌────────────────────────┐ ┌──────────────────────┐ ┌───────────────────────┐\n│ 代理阶段 (Agent) │───▶│ 检测阶段 (Detection) │───▶│ 执行阶段 (Execution) │\n│ │ │ │ │ │\n│ • 在AWF网络沙箱中运行 │ │ • 审查提议的操作 │ │ • 创建PR │\n│ • 只读ADO令牌 │ │ • 检查提示注入和泄露 │ │ • 创建工作项 │\n│ • 生成安全的输出提案 │ │ • 安全威胁分析 │ │ • 写入ADO令牌 │\n│ │ │ │ │ • 代理永远无法访问 │\n└────────────────────────┘ └──────────────────────┘ └───────────────────────┘\n```\n\n这种架构的关键在于**权限分离**。AI代理永远不会直接获得写入权限，所有变更提议都必须通过安全审查，然后由独立的执行组件使用专门的写入令牌完成。即使AI代理被恶意提示注入攻击，也无法直接修改代码库或创建未经验证的PR。\n\n### 网络隔离与令牌分离\n\n项目采用Azure DevOps的AWF（Agent Workflow Framework）网络沙箱技术，将AI代理运行环境与外部网络隔离。同时，通过两个独立的ARM服务连接实现读写分离：\n\n| 连接类型 | 使用阶段 | 用途 | 暴露给代理 |\n|---------|---------|------|-----------|\n| 读取连接 | 阶段1 - AI代理 | 查询ADO API（工作项、仓库、PR） | ✅ 是（沙箱内） |\n| 写入连接 | 阶段3 - 安全执行器 | 创建PR、工作项、链接工件 | ❌ 永不 |\n\n这种设计解决了Azure DevOps PAT（个人访问令牌）粒度不足的问题——ADO的令牌要么是只读，要么是全项目读写，无法精细控制。ado-aw通过物理分离两个阶段，实现了逻辑上的权限最小化。\n\n## 工作流定义与编译\n\n### Markdown格式的代理定义\n\nado-aw使用带有YAML前置 matter的Markdown文档作为代理定义格式。这种设计既保持了人类可读性，又包含了机器可解析的结构化配置：\n\n```markdown\n---\nname: \"Dependency Updater\"\ndescription: \"Checks for outdated dependencies and opens PRs\"\nengine:\n id: copilot\n model: claude-sonnet-4.5\non:\n schedule: weekly on monday around 9:00\npool: AZS-1ES-L-MMS-ubuntu-22.04\ntools:\n azure-devops: true\npermissions:\n read: my-read-arm-connection\n write: my-write-arm-connection\nsafe-outputs:\n create-pull-request:\n target-branch: main\n auto-complete: true\n squash-merge: true\n reviewers:\n - \"team-lead@example.com\"\n---\n\n## Instructions\n\nCheck all dependency manifests in this repository. For each outdated\ndependency, update it to the latest stable version and create a pull\nrequest with a clear description of what changed and why.\n```\n\n### 编译流程\n\n编译命令将Markdown定义转换为完整的Azure DevOps流水线YAML：\n\n```bash\n# 标准编译（生成.lock.yml文件）\nado-aw compile dependency-updater.md\n\n# 指定输出路径\nado-aw compile dependency-updater.md -o path/to/pipeline.lock.yml\n```\n\n编译器还会自动处理.gitattributes文件，将所有生成的.lock.yml标记为`linguist-generated=true merge=ours`，使GitHub在PR差异中隐藏这些文件，并在合并冲突时优先保留本地版本（可重新编译生成）。\n\n### 一致性检查\n\n为确保源Markdown与编译输出保持同步，项目提供了检查命令：\n\n```bash\nado-aw check dependency-updater.lock.yml\n```\n\n这可以作为CI门禁使用——如果有人编辑了Markdown但忘记重新编译，检查将失败。\n\n## 部署与使用流程\n\n### 初始化\n\n项目提供了初始化命令，自动创建Copilot代理配置：\n\n```bash\nado-aw init\n```\n\n这会在`.github/agents/ado-aw.agent.md`创建一个帮助代理，协助用户创建、更新和调试代理工作流。该代理会自动下载ado-aw编译器并处理编译过程。\n\n### AI辅助工作流创建\n\n开发者可以直接向AI编程助手（Copilot、Claude、Codex）发出自然语言指令：\n\n```\nCreate an agentic pipeline that checks for outdated dependencies and opens PRs\n```\n\nAI会根据预定义的提示模板生成相应的Markdown代理定义文件。项目提供了专门的提示文件用于不同场景：\n- `create-ado-agentic-workflow.md` - 创建新工作流\n- `update-ado-agentic-workflow.md` - 更新现有工作流\n- `debug-ado-agentic-workflow.md` - 调试问题\n\n### Azure DevOps集成\n\n编译后的.lock.yml文件可直接导入Azure DevOps：\n\n1. 进入 Pipelines → New Pipeline\n2. 选择代码仓库\n3. 选择 Existing Azure Pipelines YAML file\n4. 指向编译后的.lock.yml文件\n5. 保存或保存并运行\n\n## 技术亮点与创新\n\n### 安全优先的设计理念\n\nado-aw从设计之初就将安全性作为核心考量。与许多AI代理工具追求功能丰富性不同，ado-aw首先解决"如何安全地让AI代理操作生产环境"这一根本问题。三阶段架构、网络隔离、令牌分离等机制共同构成了纵深防御体系。\n\n### 人机协作的接口设计\n\n使用Markdown作为代理定义格式是一个精妙的设计选择。它既满足了开发者阅读和编辑的需求，又可以通过YAML前置 matter承载结构化配置。这种格式降低了非技术人员参与AI工作流设计的门槛。\n\n### 与GitHub生态的协同\n\n作为GitHub Next团队的项目，ado-aw与GitHub生态系统深度集成。从Copilot代理支持到.gitattributes的智能处理，再到与GitHub Agentic Workflows（gh-aw）的灵感传承，体现了GitHub在企业级AI应用方面的系统性思考。\n\n## 应用场景\n\n### 自动化依赖管理\n\n定期检查项目依赖更新，自动创建PR进行升级。这是最常见的应用场景，也是项目文档中的示例用例。\n\n### 代码质量监控\n\n设置定期任务扫描代码库，检测潜在问题（如安全漏洞、代码异味），自动创建工作项分配给相关团队。\n\n### 文档同步维护\n\n监控代码变更，自动更新相关文档，确保文档与代码保持同步。\n\n### 安全合规检查\n\n定期审查代码库合规性，检查许可证冲突、敏感信息泄露等问题，自动生成报告和修复建议。\n\n## 总结\n\nado-aw项目代表了企业级AI代理应用的一个重要方向：在拥抱AI自动化的同时，不牺牲安全性和可控性。其三阶段安全架构、Markdown定义格式、与Azure DevOps的深度集成，为在企业环境中部署AI代理提供了可复制的范式。对于正在探索AI驱动DevOps转型的团队而言，ado-aw不仅是一个工具，更是一套安全最佳实践的参考实现。