加速開發者透過 MCP 伺服器與代理程式的入職流程

在兌換啟動點數並完成租戶設定後，許多新創團隊不會先深入學習 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 與 Agent 模式

AI 輔助開發可以在你的終端機、編輯器或 GitHub 上架的環境中進行。 最佳選擇取決於任務內容。

互動模式 在下列情況下使用 可以期待什麼
GitHub Copilot CLI 你想要在終端機裡直接控制。 助理協助你探索倉庫、執行設定任務、回答程式碼問題，並使用具備可見審核步驟的 MCP 工具。
GitHub Copilot Chat 的代理模式 你正在編輯器中修改程式碼。 助理協助你規劃、審查、編輯及精煉程式碼，同時保持專案情境。
GitHub 託管編碼代理程式 這項任務規模較大，可獨立進行，且應以 pull request 的形式提交回來。 代理程式會研究儲存庫、擬定計畫、在分支上進行修改，並開啟拉取請求供審核。

範例提示

以這些範例作為起點，並調整到你的資料庫和核准模式。

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 Chat 代理模式：實作基礎設施與 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 代管的編碼代理程式：規劃並開啟 Pull Request

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.

對大多數新創團隊來說，從最簡單且安全的工作流程開始：

  1. 使用 Copilot CLI 來驗證你的 Azure 和 GitHub 設定。
  2. 在客服模式中使用 Copilot Chat 進行 VS Code 的互動變更。
  3. 使用 GitHub 託管的程式代理程式來處理較大型的拉取式請求工作。
  4. 只有在定義每個工具所需的權限、核准模式和日誌後，才加入 MCP 伺服器。

為代理程式和 IDE 設定工具

入職工具的重點是將你的程式代理程式和 IDE 連接到正確的情境與功能。 MCP（模型情境協定）伺服器為代理工具提供結構化的方式，以存取核准的功能，如 Microsoft 文件、倉庫輔助工具或 Azure 資源操作。 將新人入職視為其他開發者依賴：自動化設定、驗證連線，並確保存取邊界清晰。

將你的 IDE 和開發工具連接到程式代理程式

  1. 選擇主要客戶體驗，例如具備代理啟用工作流程的 VS Code，或以終端機為優先的工作流程。
  2. 使用您組織核准的身份，安裝並登入您的代理工具，例如 Copilot Chat、Copilot CLI 或 Claude Code。
  3. 決定哪些應該放在使用者設定，哪些應該放在工作區設定裡。 使用工作區設定來設定存放庫專屬的 MCP 伺服器、提示詞和防護機制，讓它們能隨程式碼一同移轉。
  4. 檢查倉庫指示，例如程式碼慣例、建置與測試指令，以及代理不應該採取的動作規則。 對於 Claude Code，這份指引通常儲存在 CLAUDE.md。
  5. 為工具定義安全預設值。 要求對檔案寫入和 Shell 指令進行明確批准，並將代理程式可在無人值守情況下執行的任何指令加入允許清單。
  6. 透過要求代理執行一項用於熟悉環境的小任務來驗證設定，例如了解程式碼儲存庫的結構、執行測試，或提出小幅重構建議。 用差異和信賴值來確認結果。
  • Microsoft 學習 MCP Server：當您的代理需要可信且最新的Microsoft文件與程式碼範例時，使用此伺服器。 公開遠端端點為 /api/mcp。 欲了解更多資訊，請參閱 Get Start with the Microsoft Learn MCP Server。
  • Azure MCP Server：當代理程式需要檢查、查詢並管理開發環境中的Azure資源時，會使用此伺服器。 欲了解更多資訊，請參見 Get started with the Azure MCP Server。

Important

只將代理連接到核准的 MCP 伺服器。 優先採用列入允許清單的端點、最小權限的工具權限範圍，以及可稽核的日誌。 如果某個工具可以寫入儲存庫或部署資源，請將其視為正式環境的存取權限，並施加適當的控管。

建立一個 Azure 優化的代理團隊

對於建置於 Azure 上的企業級 B2B 解決方案，請從簡單的代理程式模型開始，並僅在 Azure 特定職責明確時再加以擴展。 Azure 指引將著陸區視為可擴展、安全且受治理環境的建議起點。 它也區分了平台著陸區（提供身份、連接性和管理等共享服務）與應用程式著陸區（用於應用程式與環境的工作負載資源）。 在兩者中，啟用核心控制功能，如 Azure RBAC、成本管理，以及 適用於雲端的 Microsoft Defender。

這個區別對 B2B 產品很重要，因為目標不僅是快速推出功能。 目標是打造一個企業客戶能夠信賴的產品。 Microsoft 針對在 Azure 上建置生產級代理所提出的新創指引，特別點出當團隊不再停留於原型階段時，以下設計領域會變得至關重要：多租戶、應用層、協調層，以及情境層。 企業情境也需要關注安全性、可靠性及跨多客戶的適應性。

Microsoft 提供 Azure 技能，你可以根據業務員工作流程調整。 新創公司也可以將 gstack 模式 作為多代理工程團隊的範本。 以下角色是建議提供給在 Azure 上打造企業級 B2B 產品的新創公司的 Azure 最佳化延伸角色。

  1. 產品與需求規劃代理

    將此代理程式作為新工作項目的主要入口。 它將產品需求轉化為包含功能範圍及非功能性需求的簡短實施計畫，例如租戶隔離、治理需求、部署限制及營運期望。

  2. Azure 平台架構師代理程式

    利用此代理來塑造平台著陸區與環境基礎：租戶設定、管理群組、訂閱策略、連接性、身份、治理基線及共享平台服務。 Azure著陸區指引將這些決策定位為基礎，並建議以著陸區模型作為大規模Azure環境的標準化起點。 以 Azure 企業基礎設施規劃工具 作為起點。

  3. 企業應用程式架構代理程式

    利用這個代理專注於 應用程式的著陸區 和業務工作負載本身。 對於 B2B 解決方案，這個角色負責工作負載邊界、環境分離、應用層設計，以及租戶特定邏輯如何映射到更廣泛的平台基礎。

  4. 身份與安全代理

    使用此代理程式檢視企業存取控制與工作負載保護。 Azure Well-Architected指引將身份識別為主要邊界，並建議嚴格、有條件且可稽核的身份與存取管理。 此職務會審查認證模式、工作負載識別碼、RBAC 邊界、網路分段及安全預設值。

  5. Azure DevOps 與 IaC 代理程式

    使用這個代理程式來擁有「一切皆由程式碼完成」層：部署範本、平台自動化，以及可重複的配置。 Azure 營運卓越指引將基金會與平台自動化及 DevOps 連結起來，Azure治理指引則建議新環境採用基於 Bicep 或 Terraform 的部署流程。 以 azure-prepare skill 作為起點。

  6. 可靠性與可觀察代理

    使用此代理來檢視健康狀況、警示及生產行為。 Azure Well-Architected 可靠性指引建議建模健康狀態、設計監控與警示策略，並利用指標、日誌與追蹤追蹤關鍵流程與工作負載元件。

  7. Azure 整合代理

    使用這個代理程式，讓開發者的體驗紮根於真實的 Azure 環境。 Azure MCP Server 讓 AI 代理程式透過自然語言與 Azure 資源互動，並可從 GitHub Copilot CLI、GitHub Copilot 編碼代理程式、基於 SDK 的應用程式及其他相容 MCP 用戶端使用。 先從 Azure 部署技能 開始，並針對你的環境進行修改。

  8. 治理與成本代理程式

    利用此代理執行預算、標籤、政策指派及合規防護，協助新創公司從信用資助的實驗邁向企業運營。 Azure治理指引建議自動化護欄、Azure 原則執行及成本控制措施，如預算與警示。 azure-compliance 和 azure-cost 技能是不錯的起點。

  9. 審查員與品質保證代理

    利用這些代理在合併前檢視正確性、安全性、邊緣案例、著陸區對齊、存取邊界、監控覆蓋範圍及基礎設施變更安全。 先從 Azure 驗證技能 開始，並根據客戶和環境需求進行修改。

這和一般 Gstack 配置有什麼不同

Gstack 風格的模式（Thinking → Plan → Build → Review → Test → Ship → Reflect）仍是有用的起點，因為它提供角色分離、審查循環及簡單的操作模型。 建議的變更是將通用的工程群體轉變為一個反映 Azure 架構邊界的團隊：平台基礎、工作負載設計、安全、自動化、可觀察性與治理。 這種架構避免了 Azure 專屬的問題被忽略。

從第一天起就使用規格驅動的開發、基礎架構即程式碼（Infrastructure as Code）和 CI/CD 來建置

當你開始在 Azure 上建置時，請將應用程式碼、基礎架構和部署視為一個工程系統。 與其在一個地方設計產品、在另一個地方配置基礎設施，然後再自動化部署，不如採用以下工作流程：

  • 規範定義了預期的結果。
  • 基礎設施即程式碼（IaC）定義了所需的 Azure 環境。
  • CI/CD 透過可重複執行的流程來驗證及部署變更。

這種方法減少了意圖與實作之間的差異，讓團隊擁有共享的真實來源，並幫助你從原型擴展到生產環境。

規格驅動、IaC 優先的 Azure 交付

範例工作流程

  1. 在規格中定義該特徵。

    採用規格優先的方法，先捕捉問題、使用者、需求、限制條件及成功標準，再撰寫程式碼。

  2. 讓規劃人員製作一份可實施的專案簡報。

    規劃工具會釐清範圍與需求，使工作流程從明確計畫開始，而非臨時提示。

  3. 請Azure平台架構代理設計該功能的Azure基礎。

    此代理決定該功能如何融入 Azure 環境，包括身份、治理、網路、管理及登陸區配置。

  4. 讓 Azure DevOps 和 IaC 代理程式以程式碼定義基礎結構。

    在 Bicep 或 Terraform 中實作所需的 Azure 資源、環境結構及部署設定，並存放在版本控制中。

  5. 讓Azure整合代理驗證真實Azure環境。

    將工作流程連接到支援 Azure 的工具，例如 Azure MCP Server，讓代理程式能檢查資源、驗證假設，並針對實際 Azure 環境操作，而非隨意猜測。

  6. 讓審查員和品質保證人員審核變更。

    合併前檢視正確性、安全性、邊緣案例、監控、日誌記錄及健康檢查。

  7. 使用 pull request 和 CI/CD 來驗證並部署這個功能。

    將應用程式程式碼、IaC 和部署工作流程變更放在拉取請求後面，這樣建置、測試和驗證都能在合併前執行。

  8. 保持規格、基礎設施和部署流程同步。

    將規格、IaC和管線視為活生生的產物，讓部署的系統隨時間保持與預期設計的一致性。

此模型為新創公司提供更可靠的途徑，讓其從初次建置推進到 Azure 上可投入生產的交付。 團隊不再需要依賴手動入口網站設定、彼此脫節的指令碼，或沒有文件記錄的決策，而是能擁有一套工作流程：由規格明確表達意圖、由 IaC 定義 Azure 環境，並由 CI/CD 在每次交付時確保一致性。

Summary

基於代理的開發結合明確的規格、專業代理角色、Azure 感知工具及可重複的交付流程，幫助新創從構想邁向實作。 團隊從定義應建置內容的規範開始，利用規劃將意圖轉化為技術決策與任務，並透過版本控制的工作流程而非臨時變更來實作應用程式程式碼與基礎架構。

一個強大的工作流程也受益於專門的角色，而非單一的編碼助理。 對於 Azure 專案而言，當代理能使用具 Azure 感知能力的工具（例如 Azure MCP Server），且所做的變更能透過提取要求、差異比較、測試和 CI/CD 進行審查時，以代理為基礎的開發會變得更實用。

這種做法幫助新創公司快速建構，避免未來重做。 對創辦人而言，這意味著更快的首次部署、更少手動設定錯誤、更清晰的審查，以及從原型到生產級軟體的更順暢路徑。

  • 上次更新時間：