兑换启动额度并完成租户设置后，许多启动团队不会从深入学习Azure门户开始。 一个更常见的起点是配置 AI 辅助开发工作流，使开发人员能够留在他们已喜欢的终端或编辑器中，同时安全地将该工作流连接到Azure。 本文介绍如何使用 GitHub Copilot CLI 或 Claude Code 在Azure上从帐户设置迁移到代理驱动的开发。 我们还将讨论相关的 MCP 服务器和工具，以支持开发人员使用基于 CLI 的开发人员工作流。
Prerequisites
在开始之前，请确保：
- 已兑换 Microsoft for Startups 启动额度。
- 激活了Azure赞助订阅。
- 已完成兑换后的 Azure 账户设置。
- 配置了公司支持的Microsoft Entra租户、自定义域和管理员权限，以便环境不会绑定到单个人员。
- 已兑换 GitHub 福利。 有关详细信息，请参阅如何对 GitHub、AKS 和 AI 模型使用启动额度。
Tip
兑换额度后，立即配置 Azure 租户。 添加其他用户和管理员，配置您的企业域名，并确认您的 Microsoft for Startups 额度已激活。 有关详细信息，请参阅设置Azure帐户。
设置开发环境
在配置代理、MCP 服务器或Azure访问权限之前，请设置基线开发人员环境，使团队能够一致地在本地工作。 目标是不强制每个启动进入一个确切的工具链，但为了确保开发人员能够进行身份验证、安装所需的 CLI 工具，并为手头的任务选择正确的工作模式。
在 VS Code 中选择正确的交互模式：CLI 与代理模式
AI 辅助开发可以在终端、编辑器或GitHub托管的环境中进行。 最佳选择取决于任务。
| 交互模式 | 在以下情况下使用 | 可以预期什么 |
|---|---|---|
| GitHub Copilot CLI | 需要在终端中直接控制。 | 该助手可帮助你浏览存储库、运行设置任务、回答代码问题，以及将 MCP 支持的工具与可见审批步骤一起使用。 |
| 代理模式下的 GitHub Copilot 对话助手 | 你正在积极更改编辑器中的代码。 | 助手有助于你在项目上下文中规划、查看、编辑和优化代码。 |
| GitHub托管的编码代理 | 该任务规模较大，可以独立运行，并应以拉取请求的形式提交。 | 该智能体研究了代码库，制定了计划，在某个分支上进行了修改，并提交了拉取请求以供审核。 |
示例提示
将这些示例用作起点，并将其适应存储库和审批模型。
GitHub Copilot CLI：验证Azure设置
Review this repository and explain how to run it locally.
Do not edit any files yet.
Then, using azure-mcp tools, verify that:
- Resource groups and deployed resources match the expected naming convention.
- RBAC is scoped correctly, with no broad Owner assignments.
- Diagnostics and monitoring are enabled for key resources.
Summarize findings and gaps as pull request comments.
代理模式下的 GitHub Copilot 对话助手：实现基础设施和 CI/CD
Create an initial IaC and CI workflow.
Add:
- An infra folder with a Bicep or Terraform structure.
- A GitHub Actions workflow that validates infrastructure and runs tests.
- A rollback note in the pull request template.
Use minimal viable defaults and keep the structure modular for later expansion.
GitHub 托管的代码代理：规划并发起拉取请求
Create an implementation plan for the feature described in docs/feature-spec.md.
If the plan looks safe:
- Make the changes on a new branch.
- Add or update tests.
- Update documentation.
- Open a pull request with a summary and testing steps.
推荐的起点
对于大多数启动团队，请从最简单的安全工作流开始：
- 使用 Copilot CLI 验证Azure和GitHub设置。
- 在代理模式下使用Copilot 对话助手进行 VS Code 中的交互式更改。
- 使用 GitHub 托管的编程代理来处理面向拉取请求的较大规模工作。
- 仅在定义每个工具所需的权限、审批模型和日志记录后，才添加 MCP 服务器。
为代理和 IDE 设置工具
接入工具的作用是将你的代码代理和 IDE 连接到正确的上下文和能力。 MCP（模型上下文协议）服务器为代理工具提供了访问已批准的功能的结构化方法，例如Microsoft文档、存储库帮助程序或Azure资源操作。 像对待任何其他开发人员依赖项一样对待载入：自动配置、验证连接并确保访问边界清晰。
将 IDE 和开发人员工具连接到编码代理
- 选择主要的客户端体验，例如采用支持代理工作流的 VS Code，或终端优先工作流。
- 安装并登录你的代理工具（例如 Copilot 对话助手、Copilot CLI 或 Claude Code），并使用你所在组织批准的身份进行登录。
- 确定属于用户设置的内容以及属于工作区设置的内容。 使用工作区设置来配置仓库专用的 MCP 服务器、提示词和防护规则，使它们能够随代码一起流转。
- 查阅代码库中的说明，例如编码规范、构建和测试命令，以及有关代理不应执行哪些操作的规则。 对于 Claude Code，本指南通常存储在
CLAUDE.md. - 定义工具的安全默认值。 对文件写入和 Shell 命令要求明确批准，并将代理可在无人值守情况下运行的任何命令列入允许列表。
- 通过要求代理运行小型方向任务（例如映射存储库、运行测试或建议小型重构）来验证设置。 通过差异对比和 CI 确认结果。
建议的 MCP 服务器
-
Microsoft Learn MCP 服务器：当代理需要受信任的当前Microsoft文档和代码示例时，请使用此服务器。 公共远程终结点为
/api/mcp. 有关详细信息，请参阅 Microsoft Learn MCP 服务器入门。 - Azure MCP 服务器：当代理需要检查、查询和管理开发环境中的Azure资源时，请使用此服务器。 有关详细信息，请参阅 Azure MCP 服务器入门。
Important
仅将代理连接到批准的 MCP 服务器。 优先选择已列入允许列表的端点、最小权限的工具权限范围以及可审计日志。 如果工具可以写入存储库或部署资源，请将其视为生产访问并适当地对其进行门控。
构建Azure优化代理团队
对于Azure上的企业级 B2B 解决方案，请从简单的代理模型开始，并仅在明确Azure特定职责的情况下对其进行扩展。 Azure指南将登陆区域视为可缩放、安全和管理环境的建议起点。 它还区分平台登陆区域，后者提供共享服务，例如标识、连接和管理，以及用于保存应用程序和环境的工作负荷资源的应用程序登陆区域。 在两者中，启用核心控制，例如 Azure RBAC、成本管理和Microsoft Defender for Cloud。
这种区别对于 B2B 产品很重要，因为目标不只是要快速推出功能。 目标是构建企业客户可以信任的产品。 Microsoft 针对 Azure 上生产级智能体的入门指南指出了团队在超越原型阶段后变得至关重要的设计领域：多租户、应用层、编排层和上下文层。 企业方案还需要注意多个客户的安全性、可靠性和适应性。
推荐的 Azure 代理角色
Microsoft 提供了可用于代理工作流的Azure Skills。 初创公司还可以将 gstack 模式 用作多代理工程团队的模型。 以下角色是针对在 Azure 上构建企业级 B2B 产品的初创公司推荐的 Azure 优化扩展。
产品和需求规划代理
将此智能体作为新任务的入口。 它将产品要求变成一个简短的实施计划，其中包括功能范围和非功能要求，例如租户隔离、治理需求、部署约束和运营预期。
Azure平台架构师代理
使用此代理塑造平台登陆区域和环境基础：租户设置、管理组、订阅策略、连接性、标识、治理基线和共享平台服务。 Azure登陆区域指南将这些决策定位为基础，并建议将登陆区域模型用作大规模Azure环境的标准化起点。 使用 azure-enterprise-infra-planner 技能 作为起始点。
企业应用程序架构师代理
使用此代理专注于 应用程序登陆区域 和业务工作负荷本身。 对于 B2B 解决方案，此角色拥有工作负载边界、环境分离、应用程序层设计，以及特定于租户的逻辑如何映射到更广泛的平台基础。
标识和安全代理
使用此代理查看企业访问控制和工作负荷保护。 Azure Well-Architected 指南将身份视为主要安全边界，并建议实施严格、有条件且可审计的身份和访问管理。 此角色会审查身份验证模式、工作负荷标识、RBAC 边界、网络分段和安全默认值。
Azure DevOps 和 IaC 代理
使用此智能体来负责“通过代码实现一切”的层面：部署模板、平台自动化以及可重复的资源预配。 Azure 运营卓越指南将基础架构与平台自动化和 DevOps 连接起来，而 Azure 治理指南则建议新环境采用基于 Bicep 或 Terraform 的部署流程。 以 azure-prepare 技能为起点。
可靠性和可观测性代理
使用此智能体查看系统运行状况、警报和生产环境的行为。 Azure Well-Architected可靠性指南建议对运行状况状态进行建模、设计监视和警报策略，以及使用指标、日志和跟踪来跟踪关键流和工作负荷组件。
Azure集成代理
使用此代理使开发人员体验保持在真正的Azure环境中。 Azure MCP 服务器允许 AI 代理通过自然语言与Azure资源进行交互，并且可以从 GitHub Copilot CLI、GitHub Copilot编码代理、基于 SDK 的应用和其他与 MCP 兼容的客户端使用。 从 azure 部署技能 开始，并针对环境对其进行修改。
治理与成本代理
随着初创公司从依靠信用额度支持的试验阶段迈向企业级运营，可使用此代理来落实预算控制、标记、策略分配和合规护栏。 Azure治理指南建议自动护栏、Azure Policy强制执行以及预算和警报等成本控制。 Azure 合规性和 Azure 成本技能是很有用的起点。
审阅者和 QA 代理
使用这些代理在合并之前查看正确性、安全性、边缘情况、登陆区域对齐、访问边界、监视覆盖范围和基础结构更改安全性。 从 azure 验证技能 开始，并针对客户和环境需求对其进行修改。
这与通用 gstack 设置有何不同
gstack 样式模式（Think → Plan → Build → Review → Test → Ship → Reflect）仍然是一个有用的起点，因为它提供角色分离、评审循环和简单的操作模型。 建议的更改是将通用工程群转变为一个团队，该团队反映Azure体系结构边界：平台基础、工作负荷设计、安全性、自动化、可观测性和治理。 这种结构使Azure特定的关切无法成为事后考虑。
从一开始就采用规范驱动开发、基础设施即代码和 CI/CD 进行构建
在开始构建Azure时，请将应用程序代码、基础结构和部署视为一个工程系统。 使用工作流，而不是在一个位置设计产品，在另一个位置预配基础结构，并稍后自动执行部署：
- 该规范定义预期结果。
- 基础结构即代码（IaC）定义了所需的Azure环境。
- CI/CD 通过可重复的流水线来验证和部署变更。
此方法可减少意向与实现之间的偏差，为团队提供共享的真相来源，并帮助你从原型扩展到生产环境。
示例工作流
在规范中定义特征。
在编写代码之前，使用规范优先方法捕获问题、用户、要求、约束和成功条件。
让 Planner 代理创建一个实现就绪的功能简介。
规划器阐明了范围和要求，以便工作流从显式计划开始，而不是临时提示。
让Azure平台架构师代理设计该功能的Azure基础。
此代理决定该功能如何适应Azure环境，包括标识、治理、网络、管理和登陆区域放置。
让 Azure DevOps 和 IaC 代理将基础结构定义为代码。
使用 Bicep 或 Terraform 实现所需的 Azure 资源、环境结构和部署配置，并将其存储在版本控制系统中。
让Azure集成代理验证真正的Azure环境。
将工作流连接到Azure感知工具（如 Azure MCP 服务器），以便代理可以检查资源、验证假设，并针对实际Azure环境工作，而不是猜测。
让审阅者和 QA 代理审核更改。
在合并前，审查正确性、安全性、边界情况、监控、日志记录和健康检查。
使用拉取请求和 CI/CD 验证和部署该功能。
将应用程序代码、IaC 和部署工作流更改放在拉取请求后面，以便在合并之前运行生成、测试和验证。
使规范、基础结构和部署工作流保持同步。
将规范、IaC 和管道视为生活项目，以便部署的系统在一段时间内与预期设计保持一致。
这种模式为初创公司提供了一种更可靠的方式，帮助它们在 Azure 上从首次构建过渡到可投入生产的交付阶段。 你的团队无需再依赖手动配置门户、彼此割裂的脚本或未记录在案的决策，而是采用一套工作流：规范承载设计意图，IaC 定义 Azure 环境，CI/CD 则在每次交付时确保一致性。
Summary
基于代理的开发通过结合明确的规范、专用代理角色、Azure感知工具以及可重复的交付工作流，帮助启动人员从想法转向实现。 该团队从定义应生成的内容的规范开始，使用计划将该意向转化为技术决策和任务，并通过版本控制的工作流实现应用程序代码和基础结构，而不是临时更改。
强大的工作流也会因采用专门化角色而受益，而不是依赖一个通用的编程助手。 对于 Azure 项目而言，当代理能够使用支持 Azure 的工具（例如 Azure MCP Server），并且更改可以通过拉取请求、差异比较、测试和 CI/CD 进行审查时，基于代理的开发会更有用。
这种方法可以帮助初创公司快速构建，同时避免未来返工。 对于创始人来说，这意味着更快的第一次部署、更少的手动配置错误、更清晰的评审，以及从原型到生产级软件的更流畅的路径。