技术速递｜六个编码智能体，一个生产级系统：基于 AKS-Lab-GitHubCopilot 的 AgenticOps 实战指南

作者：卢建晖 - 微软高级云技术布道师

排版：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 在实践中的样子。

两层智能体 ------ 不要把它们混淆

这个实验中的第一个认知难点，是要区分两类完全不同的智能体群体：

层级	它是什么	它存在于何时	示例
应用智能体	你交付的产品 ------ 在运行时工作的 ZavaShop 智能体集群，用于解决业务问题	生产环境（AKS + ACA）	InventoryAgent、SupplierAgent、LogisticsAgent、PricingAgent、OrchestratorAgent
编码智能体	在开发阶段负责编写这些应用智能体的团队	你的 IDE + GitHub	requirements-analyst、mcp-builder、agent-builder、orchestrator-architect、test-author、deploy-engineer

这两类智能体都基于 **Microsoft Agent Framework（MAF）**构建。它们都使用 GitHub Copilot SDK 作为模型提供方。但它们存在于软件开发生命周期中的不同层级，而整个实验也是围绕这种区别来组织的。

如果你只记住本文中的一件事，那就是：编码智能体是你用来构建应用智能体的方式。这就是整个 AgenticOps 闭环，用一句话压缩后的本质。

GitHub Copilot Coding Agent 与 Custom Coding Agents

在 GitHub Copilot 生态中，"编码智能体"有两种形态，而这个实验同时使用了它们。

远程 GitHub Copilot Coding Agent

这是运行在 GitHub 侧、异步、以 PR 驱动的智能体。你给它分配一个 Issue，它会启动一个隔离的沙箱环境，编写代码、运行测试，并提交一个 Pull Request 供人工审查。你不会看到它工作的过程 ------ 你只会审查它产出的结果。

在 ZavaShop 中，Lab 04（Testing）明确使用了这个智能体：你会将一个失败的评估场景创建成一个 Issue，并分配给 Copilot；随后，该智能体会返回一个 PR。你的职责是担任人工质量门槛，而不是亲自敲击键盘。

来自 AGENTS.md 的一个重要治理决策：远程 Coding Agent 仅被允许对 src/ 与 tests/ 提交 PR ------ 在没有人工审查的情况下，绝不能修改 infra/。这一条规则，就是智能体感知型策略的教科书式示例。

本地 Custom Coding Agents

这些是在 IDE 内部使用、职责范围明确的专业化智能体，你可以在 Copilot Chat 中通过 @ 选择它们。它们以 *.agent.md 文件的形式存在于 .github/agents/ 中，并会在 VS Code 重新加载后被自动发现。每个智能体只负责仓库中的一个明确部分。

这个实验中包含了六个这样的智能体：

阶段	智能体	负责范围	拒绝规则
需求	requirements-analyst	specs/*.md	拒绝编写代码
MCP 工具	mcp-builder	src/mcp_servers/*	每次只处理一个 server
专业化智能体	agent-builder	src/agents//*	每次只处理一个 specialist
编排	orchestrator-architect	src/agents/orchestrator/、src/shared/、docker-compose.yml	负责连接与编排，而不是业务逻辑
测试	test-author	tests/**	从不修改 src/
部署	deploy-engineer	infra/、.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 会驱动一个或多个智能体；智能体生成 commits；commits 触发 CI；CI 决定是否允许进入下一阶段。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-GitHubCopilot ------ 本文所基于的仓库。
使用 Copilot 处理任务的最佳实践 ------ 将任务委托给 Copilot 时的治理模式。
GitHub Copilot SDK (Python) ------ 本实验中所有智能体使用的 Provider。