作者卢建晖 - 微软高级云技术布道师排版Alan Wang转变从“AI 帮我写代码”到“AI 为我的仓库写代码”两年来我们一直将 GitHub Copilot 视为一个内联结对程序员—— 一个驻留在编辑器中的智能自动补全工具。如今这种定位已经正式过时了。新的现实是智能体化交付一组具名、职责明确的 AI 智能体负责你的代码仓库中的不同部分每个智能体都拥有自己的工具、技能以及拒绝规则。它们会生成 Pull Request。它们会运行测试。它们会执行部署。当其中一个完成自己的阶段后它会将工作交接给下一个智能体。在 microsoft/AKS-Lab-GitHubCopilot 的五个实验中你将交付ZavaShop—— 一个运行在 AKS Azure Container Apps 上的多智能体零售供应链控制平面与此同时你也会逐步内化一种能够迁移到任何项目中的运营模型。仓库中的所有内容规格说明、智能体、MCP 服务器、测试、Bicep、Helm、GitHub Actions都由六个 GitHub Copilot 自定义编码智能体在你的 IDE 中协同编写外加运行在 GitHub 上、用于闭合 PR 工作流的远程 GitHub Copilot Coding Agent。这就是AgenticOps在实践中的样子。microsoft/AKS-Lab-GitHubCopilothttps://github.com/microsoft/AKS-Lab-GitHubCopilot/?wt.mc_id3reg_webpage_reactor两层智能体 —— 不要把它们混淆这个实验中的第一个认知难点是要区分两类完全不同的智能体群体层级它是什么它存在于何时示例应用智能体你交付的产品 —— 在运行时工作的 ZavaShop 智能体集群用于解决业务问题生产环境AKS ACAInventoryAgent、SupplierAgent、LogisticsAgent、PricingAgent、OrchestratorAgent编码智能体在开发阶段负责编写这些应用智能体的团队你的 IDE GitHubrequirements-analyst、mcp-builder、agent-builder、orchestrator-architect、test-author、deploy-engineer这两类智能体都基于 Microsoft Agent FrameworkMAF构建。它们都使用 GitHub Copilot SDK 作为模型提供方。但它们存在于软件开发生命周期中的不同层级而整个实验也是围绕这种区别来组织的。如果你只记住本文中的一件事那就是编码智能体是你用来构建应用智能体的方式。这就是整个 AgenticOps 闭环用一句话压缩后的本质。GitHub Copilot Coding Agent 与 Custom Coding Agents在 GitHub Copilot 生态中“编码智能体”有两种形态而这个实验同时使用了它们。远程 GitHub Copilot Coding Agent这是运行在 GitHub 侧、异步、以 PR 驱动的智能体。你给它分配一个 Issue它会启动一个隔离的沙箱环境编写代码、运行测试并提交一个 Pull Request 供人工审查。你不会看到它工作的过程 —— 你只会审查它产出的结果。在 ZavaShop 中Lab 04Testing明确使用了这个智能体你会将一个失败的评估场景创建成一个 Issue并分配给 Copilot随后该智能体会返回一个 PR。你的职责是担任人工质量门槛而不是亲自敲击键盘。来自 AGENTS.md 的一个重要治理决策远程 Coding Agent 仅被允许对 src/ 与 tests/ 提交 PR ——在没有人工审查的情况下绝不能修改 infra/。这一条规则就是智能体感知型策略的教科书式示例。本地 Custom Coding Agents这些是在 IDE 内部使用、职责范围明确的专业化智能体你可以在 Copilot Chat 中通过 选择它们。它们以 *.agent.md 文件的形式存在于 .github/agents/ 中并会在 VS Code 重新加载后被自动发现。每个智能体只负责仓库中的一个明确部分。这个实验中包含了六个这样的智能体阶段智能体负责范围拒绝规则需求requirements-analystspecs/*.md拒绝编写代码MCP 工具mcp-buildersrc/mcp_servers/*每次只处理一个 server专业化智能体agent-buildersrc/agents//*每次只处理一个 specialist编排orchestrator-architectsrc/agents/orchestrator/、src/shared/、docker-compose.yml负责连接与编排而不是业务逻辑测试test-authortests/**从不修改 src/部署deploy-engineerinfra/、.github/workflows/不会修改应用代码这里真正重要的模式并不仅仅是“我们创建了一些自定义智能体”。真正关键的是每个智能体都会声明它负责什么以及它拒绝做什么。正是这种“拒绝边界”才使整个系统能够安全地进行委托。如果没有这一点它就只会变成一个更吵闹的自动补全工具。.github/prompts/ 中的三个工作流 Prompt 将这些智能体串联起来因此你无需记住整个执行顺序/feature-from-issue —— issue → spec → code → tests → PR → deploy/spec-to-code —— 将现有 spec 推进为代码 测试/ship-it —— 质量门禁 → 构建 → 推送 → ACR/ACA/AKS 发布 → smoke tests evals这是我目前见过的、最接近可编程软件开发生命周期的东西。AgenticOps 的定位DevOps 为我们带来了可重复的基础设施。MLOps 为我们带来了可重复的模型生命周期。而当你需要运营的对象本身就是一组自治智能体时 —— 无论是在构建阶段还是运行阶段 —— 你就需要 AgenticOps。这个实验将 AgenticOps 的四大支柱具体化了规格说明作为契约/requirements-analyst 会生成 specs/.md 文件其中包含目标、契约以及评估场景。在这些 spec 存在之前仓库中的其他任何内容都不会开始构建。Spec 是人类审查者真正阅读的事实来源。Skills 作为活文档.github/skills//SKILL.md 文件中存放的是共享的、与具体智能体无关的知识 —— 比如 Python 约定、Kubernetes 模式、MAF 惯用法。每个编码智能体都会声明在编写代码之前必须查阅哪些 skill。这就是防止知识漂移的方法知识只存在于一个地方并在需要时被动态引入。Evals 作为质量门禁仓库运行着一个四层测试金字塔以及五个黄金评估场景S1–S5。uv run poe check 会在本地和 GitHub Actions 中同时运行。由 Copilot 编写的 PR 必须通过与人类开发者相同的质量门槛 —— 没有例外。与智能体身份绑定的可观测性每个智能体都会通过 structlog 输出 agent.name、agent.run_id 与 agent.span_id。当生产环境中出现异常时你可以从“这个评估失败了”一路追踪到“这个版本的这个智能体在这次运行中以这些参数调用了这个工具”。这四大支柱并不是 ZavaShop 专属的。它们是任何 AgenticOps 系统的共同契约职责边界清晰、契约即代码、评估作为门禁、每个 span 都具备身份信息。逐步走读整个 Workshop哪个智能体在什么时候负责什么这五个实验其实是同一个故事的五个章节 —— ZavaShop 如何从一个空白的 Azure 订阅逐步演变成一个在线运行的零售控制平面。每一个实验都会激活不同的编码智能体子集。Lab 01 —— 环境准备此时还没有编码智能体你首先会完成平台基础设施的部署AKS 集群、ACA 环境、Azure Container Registry、Key Vault以及所有智能体都会使用的 Workload Identity。随后你会将这六个 Custom Coding Agents 安装到 IDE 中。可以把这一步理解为招聘开发团队并为他们发放工牌。Lab 02 —— 智能体创建四个智能体开始参与至此流程正式落地。你会先在 Copilot Chat 中使用 requirements-analyst为每个 ZavaShop 应用智能体生成规格说明。随后mcp-builder 会被调用四次用于生成四个 MCP Server 的脚手架 —— 每个业务域对应一个库存数据库、供应商 API、物流 API、定价 API。接着agent-builder 会再运行四次用于构建类型化的 ChatAgent 专家智能体。最后orchestrator-architect 会通过一个 MAF Workflow 将它们连接在一起。这个实验令人惊叹之处在于它的交接规范。每一个编码智能体在结束自己的阶段时都会明确写出下一步应该调用哪个智能体。并不是你在编排整个流程 —— 真正进行编排的是这些智能体。Lab 03 —— 多智能体编排与配置两个智能体参与此时编排器不再只是一次性的 LLM 调用而是变成了一个确定性的工作流。密钥会从 .env 迁移到 Key Vault。整个智能体集群可以通过 Docker Compose 在本地启动运行。这一阶段是 orchestrator-architect 的高光时刻 —— 它负责连接 A2A 端点、注册 MCP 工具、完成 Key Vault 配置注入以及接入 OpenTelemetry。规格说明依旧来自 requirements-analyst除此之外其余工作全部由编排模块完成。Lab 04 —— 测试两个编码智能体同时登场/test-author 会构建四层测试金字塔单元测试、MCP 契约测试、集成测试、评估测试。然后你会切换模式将一个失败的评估场景创建为 GitHub Issue并分配给远程 GitHub Copilot Coding Agent。该智能体会异步工作、提交 PR而 uv run poe check 则负责决定它是否通过。这一实验是“本地智能体 vs 远程智能体”区别真正从抽象概念变成实际工程实践的地方。Lab 05 —— 部署与运行部署专家登场/deploy-engineer 会为 AKS 中的 orchestrator 编写 Helm Chart并为 ACA 中的 specialist 智能体编写 Bicep 模块。随后/ship-it 工作流 Prompt 会执行完整流水线质量门禁 → ACR 构建 → ACA 部署 → AKS 发布 → smoke tests → evalsGitHub Actions OIDC 还会在每次主分支推送时重新运行同样的流水线。请注意贯穿这五个实验的核心模式全程没有人工从零编写生产环境代码。人负责设定目标、审查规格说明、批准 PR以及执行质量门禁。而真正敲击键盘完成代码编写的是智能体。Coding Agents 如何改变 DevOps 流水线从这个实验中抽离出来退一步思考当你采用这种模式后你的 DevOps 流程究竟发生了什么变化工作的原子单位发生了变化。在传统 DevOps 中工作的单位是 commit。而在 AgenticOps 中工作的单位变成了 spec。一个 spec 会驱动一个或多个智能体智能体生成 commitscommits 触发 CICI 决定是否允许进入下一阶段。Commit 不再是起点而变成了一种衍生产物。代码审查的形态发生了变化。你不再是在审查“这个人类是否理解了代码库”而是在审查“这个智能体是否遵守了它的拒绝规则、是否查阅了对应 skills以及它生成的结果是否通过了 evals”。审查者花在代码风格上的时间会减少而更多关注意图。很多时候比起代码 diff本身产生它的 spec 更值得关注。治理开始变成结构性的而不是流程性的。过去你可能会写一篇 wiki 页面告诉大家“不要在未经审查的情况下修改 infra”。而现在你会把这条规则编码进 AGENTS.md 中并明确禁止该智能体的工具集访问 infra 路径。策略不再是一份希望人类记得执行的检查清单而成为了智能体定义本身的一部分。CI 流水线被扩展了。除了 build / test / deploy 之外现在还会多出一个 eval 阶段用于询问“系统在这些黄金场景下是否仍然行为正确”而且无论 PR 是由 Copilot 编写还是由人类编写都必须通过完全相同的 eval 阶段。流水线成为了最终的平权者。新人上手被大幅压缩。一个新工程师不再需要阅读 50 页 wiki 才能开始工作。他们只需要阅读 AGENTS.md选择对应的智能体然后由这个智能体一步一步引导他们。组织知识不再只存在于资深工程师的大脑中而是存在于 .agent.md 与 SKILL.md 文件中。最终带来的效果是一条更快、更统一、更容易审计的流水线。更快是因为智能体能够并行化那些原本需要人类串行完成的工作。更统一是因为每一次变更都会经过同样的六智能体模板。更容易审计是因为每一个产物都拥有明确的作者以及它必须遵守的拒绝规则。收获AKS-Lab-GitHubCopilot 这个 Workshop 同时在教授三层内容。表层内容是“如何在 AKS 上构建一个多智能体零售系统”。中层内容是“如何使用 GitHub Copilot Custom Agents 与远程 Coding Agent”。而最深层、也是我认为最重要的一层是如何设计一种开发流程使 AI 智能体成为拥有明确边界职责的一等参与者而不是一个自由发挥的 Copilot。如果你想把这种模式带离实验环境真正应用到自己的项目中那么有三种模式特别值得保留先定义边界再赋予能力不要给智能体所有工具只给它完成任务所需的最小能力范围。Specs 是人与智能体之间的 API即便你的技术栈还没有完全准备好也应该尽早投入 requirements-analyst 风格的流程。Evals 不可妥协从智能体能够创建 PR 的那一刻开始你就必须拥有一个不关心作者是谁的质量门禁。克隆 microsoft/AKS-Lab-GitHubCopilot 仓库执行 Developer: Reload Window在 Copilot Chat 中选择智能体然后看着六位队友出现在你面前。这就是 DevOps 流水线的未来 —— 而且它已经开始真正落地了。microsoft/AKS-Lab-GitHubCopilothttps://github.com/microsoft/AKS-Lab-GitHubCopilot/?wt.mc_id3reg_webpage_reactor资源microsoft/AKS-Lab-GitHubCopilot —— 本文所基于的仓库。https://github.com/microsoft/AKS-Lab-GitHubCopilot/?wt.mc_id3reg_webpage_reactor使用 Copilot 处理任务的最佳实践 —— 将任务委托给 Copilot 时的治理模式。https://docs.github.com/copilot/using-github-copilot/coding-agent/best-practices-for-using-copilot-to-work-on-tasks/?wt.mc_id3reg_webpage_reactorGitHub Copilot SDK (Python) —— 本实验中所有智能体使用的 Provider。https://github.com/copilot/copilot-sdk/?wt.mc_id3reg_webpage_reactor
