小編精選 - 技術文章翻譯 · 05月09日

把 Copilot Studio 轉成 Claude Code 化後，竟然能用 Copilot Studio 本身來建置 Power Platform 的故事

將 Microsoft 內部人員公開的「Copilot Studio Code」與 Power Platform 的代碼優先建置儲存庫結合起來，做了一個有點 meta 的 PoC：讓 Copilot Studio 反過來扮演建置包含 Copilot Studio Agent 在內的 Power Platform 環境的一方。

總結

Microsoft 的吉田先生（Taiki Y.）公開的 copilot-studio-code，是一個讓 Copilot Studio 以 類似 Claude Code / GitHub Copilot CLI 的程式碼代理程式 身分運作的 MCP 伺服器。
我把它和 Geek Fujimura 先生（Hiromichi Fujiwara）公開的、以代碼優先方式建置 Power Platform 的開發標準儲存庫：CodeAppsDevelopmentStandard 結合，實際試了只告訴它「想用 Power Platform 做一個員工到職導引應用程式」之後，從 Dataverse → Power Apps → Power Automate → Copilot Studio Agent 都能從 Copilot Studio 裡建起來
Power Apps 的部分，是 Copilot Studio 自己寫出大量 .tsx，還自己讀懂 TypeScript 的建置錯誤並自行修正後重新建置成功。
不過老實說……我認為 Copilot Studio 本來就不是為 AI 編碼而設計的，所以 上下文上限很低，而且會話歷史也只會參照最近 10 回合。實際運作會變成以重試與上下文壓縮為前提。本文也會把這些卡住的點一併寫出來。

1. 前言 — 為什麼會想做這件事

Claude Code、Codex CLI、GitHub Copilot CLI。終端機／編輯器上的 AI 編碼代理程式 已經相當普及。

另一方面，我現在關注的是 希望能根據業務需求，快速自動建起一個 Power Platform 的展示環境。像是 Dataverse 的資料表設計、Power Apps 的 React 實作、Copilot Studio Agent 的建立，都想交給 AI 編碼代理程式，一口氣串起來完成。

為什麼想把「AI 製作的對象」放在 Power Platform 上

這裡先說個前提。若是 AI 編碼代理程式，從零開始做 Web 應用程式自由度當然更高。那為什麼偏偏是 Power Platform？

我的理由是：「AI 做出來之後能不能正式上線」，最後其實是由基礎架構層決定的。

（出處：節錄自 Geek Fujimura 先生的影片〈用客製化 Agent × Skills，只靠自然語言把 Power Platform 從零建起來〉）

Geek Fujimura 先生影片中解釋的這段內容非常容易理解，我也非常有共鳴。
即使 AI 非常快速地幫你寫好程式碼，認證／授權、整合生態系、可擴充性、治理、ALM/DevOps、AI Ready 這些基礎架構層如果要從零堆起來，最後還是會耗掉非常多時間。
好不容易做出來的應用程式，卻因為資安需求無法在公司內部推開，這是最可惜的情況之一。

Power Platform 的優勢就在於 這些基礎架構本來就已經準備好了（建構在 Microsoft 的安全與合規基礎之上）。所以我認為，AI 開發出的應用程式可以更順利地在企業內部部署。

看到「Copilot Studio Code」後想到的事

就在這個時候，Microsoft 的吉田先生在 LinkedIn 上公開了 copilot-studio-code。

可把 Copilot Studio 以 Claude Code 的方式運作、能讀寫本地工作區的 MCP 伺服器實作

看到這個之後，我突然想到：

如果把它和 Power Platform 的代碼優先建置儲存庫結合起來，不就能從 Copilot Studio 建置 Power Platform 了嗎？

而且建置內容還包含 Copilot Studio Agent。也就是說，會變成 Copilot Studio 建 Copilot Studio 的構圖。

如果未來能從 Teams 或 M365 Copilot 的入口直接做開發，這不是很酷嗎！？……於是我就真的試了。

2. 能做到什麼（先講結論）

我用的題目只有一句：「想用 Power Platform 做一個員工到職導引工具的展示環境」。

接著 Copilot Studio 做了這些事（依時間順序）：

Phase內容結果0讀取儲存庫 + Dataverse / Power Apps / Power Automate / Copilot Studio 基本設計✅1Dataverse 詳細設計 + 產生設定腳本 + 執行（Solution、資料表、欄位、關聯）✅2Power Apps UI 設計、React + TypeScript 實作（大量 .tsx 生成 → 建置 → 自我修復 → 部署）✅2.5Power Automate 詳細設計（流程說明書、Prompt 集合的生成這次先略過）✅3Copilot Studio Agent 詳細設計 → 生成圖示圖片 → 手動建立 Agent → 透過部署腳本一次寫入設定✅

你應該可以看到 read_file / run_shell / glob 等各種工具被連續呼叫。Copilot Studio 讀取本地檔案、執行 Python 腳本，然後把結果回傳到對話中。這一切都發生在 Copilot Studio 的對話畫面裡。

最後完成的 Power Apps 與 Copilot Studio Agent（到職導引協調員）大概是這樣。

圖示也是自動生成的，說明與指示也全都由部署腳本寫入。自己手動碰的只有建立空白 Agent 那一步而已。
（火箭圖示很可愛）

3. 機制 — Copilot Studio Code 是什麼

copilot-studio-code 簡單說，就是一個「可以被 Copilot Studio 呼叫的本地 MCP 伺服器」。

公開的工具有：

工具用途read_file讀文字檔list_dir列出目錄glob搜尋檔案grep使用正規表示式搜尋write_file新增或覆寫edit_file精確比對後取代run_shell執行本地命令我對它的理解大概是這樣。

Copilot Studio 在雲端，但實際的檔案操作與命令執行由本地 MCP 伺服器負責。雲端到本地的連線則透過 Microsoft Dev Tunnel 建立 HTTPS 通道。

以上是吉田先生公開儲存庫本身的內容，接下來才是我想測試的部分。

4. 組合 — Power Platform 代碼優先建置標準

copilot-studio-code 的工作區不一定得指向哪個特定儲存庫。Web 應用程式的儲存庫也可以。

但我想建置的是 Power Platform。

因此，我把先前整理好的、用來代碼優先建置 Power Platform 的開發標準儲存庫（CodeAppsDevelopmentStandard）設定成這個 MCP 的 WORKSPACE_ROOT。

這個儲存庫裡包含以下內容：

AGENTS.md — 給 AI 代理程式看的開發規則
README.md — 整個儲存庫的指南
docs/POWER_PLATFORM_DEVELOPMENT_STANDARD.md — Phase 0 到 Phase 3 的開發標準
docs/DATAVERSE_GUIDE.md — 資料表設計、Lookup、Choice、Web API
.agents/skills/{architecture, dataverse, code-apps, power-automate, copilot-studio}/SKILL.md — 各 Phase 對應的技能
React + TypeScript + Tailwind + Power Apps Vite Plugin 的樣板

這次我沒有把 .agents/skills 直接註冊成 Copilot Studio 的 Tool，而是用比較單純的方式，讓它透過 MCP 的 read_file / glob 自行去讀，作為判斷材料。

5. 實際做法 — 示範情境

5.1 輸入 Prompt

先讓 Copilot Studio 讀入儲存庫。

請先讀取 CopilotStudioCode_CodeApps 儲存庫的 README，理解這個儲存庫的目的、結構，以及 CodeApps 的開發流程。

之後我只丟了這一句：

我想用 Power Platform 做一個員工到職導引工具的展示環境

我刻意沒有提供完整的業務需求（理由在第 6 章）。而是讓代理程式自己設計。

5.2 Phase 0 — 讀取儲存庫與設計

Copilot Studio 先按以下順序讀資料：

用 list_dir 掌握儲存庫結構
用 read_file 讀 AGENTS.md、README.md、docs/POWER_PLATFORM_DEVELOPMENT_STANDARD.md
用 glob 搜尋 .agents/skills/**/SKILL.md
只讀取必要的技能檔

接著產出的設計提案如下。

資料層：{prefix}_department（部門主檔）、{prefix}_tasktemplate（任務樣板）、{prefix}_onboarding（到職流程）、{prefix}_onboardingtask（個別任務）
UI 層：Power Apps（Code Apps）
通知／自動化：Power Automate
FAQ／AI 助理：Copilot Studio

它確實遵守了開發標準中的規則，例如「英文 schema 名 + 日文／中文顯示名」、「主表 + 子表 + 主檔」等等。看起來也有依照業務需求做 UI 選擇。

5.3 認證先用另一個終端機處理

在進入 Phase 1（Dataverse 建置）之前，需要先對 Microsoft 365 / Dataverse 做裝置代碼認證。

這件事無法直接在 Copilot Studio 的對話畫面完成。因為裝置代碼認證必須互動式地在瀏覽器打開 https://microsoft.com/devicelogin 並輸入代碼，所以必須先在另一個終端機執行 python auth_helper.py，建立 .auth_record.json。

代理程式也有認知到這點，並且有明確提醒我「請先在終端機完成認證」。
（Codex 和 Claude Code 會直接幫你顯示裝置代碼，但 Copilot Studio 看起來比較難做到）

這比較像是 Copilot Studio Code 本身的限制，而不是 Copilot Studio 的問題；畢竟它不是那種會直接操作瀏覽器的執行環境。

5.4 Phase 1 — Dataverse 建置

認證完成後，透過 run_shell 執行 python setup_dataverse.py。

從建立 Solution → 建立資料表 → 新增欄位 → 設定關聯，整個流程都透過 Dataverse Web API 跑起來了。
如果途中出錯，代理程式會自己用 read_file 讀取紀錄並重試。

5.5 Phase 2 — Power Apps 實作

Copilot Studio 先做詳細設計，

接著就按照這個設計，連續寫出大量 .tsx 檔案。

型別定義
頁面元件（home / new-hires / new-hire-detail / tasks / templates / resources / not-found）
共用元件（layout / sidebar / header / list-table）
用來連接 Dataverse 資料來源的 hooks
路由設定

全部都對齊 .agents/skills/code-apps/SKILL.md 中定義的 React + TypeScript + Tailwind + Power Apps Vite Plugin 技術棧……
接著執行 npm run build。

TS2536: Type 'string' cannot be used to index type 'TaskTemplate'

建置失敗。 出現 TypeScript 型別錯誤。

……但 Copilot Studio 接下來就 自己重做了一次。

用 read_file 重新讀取出錯的檔案
找出 T extends object 這個泛型限制下，item[key] 不被允許的問題
透過 edit_file，把 (item as Record<string, unknown>)[key as string] 這種型別斷言套用到 5 個地方
重新建置

🎉 建置成功。

之後再用 pac code push 上傳到 Power Apps Solution……Power Apps 就完成了🎉

而且最後做出來的 Power Apps 乍看之下真的像那麼回事。側邊欄、頁首、表格檢視、詳細檢視，結構已經達到可作為業務應用程式使用的程度。

額外說明：Copilot Studio 同學中途可能得撐高起來

進入建置錯誤修復迴圈之後，Copilot Studio 的回應開始從日文逐漸切換成英文。

一開始是：

ListTable コンポーネントを確認します。問題が分かりました。

到中段則變成：

Now I need to fix all the pages. The ListTable generic constraint is now object instead of Record<string, unknown>...

完全英文了。我推測是因為上下文上限逐漸逼近，語言維持被排到後面去了（第 6 章會再說明）。

5.6 Phase 2.5 — Power Automate 設計

這部分它也確實有好好做設計。

不過這次我也稍微調整了開發標準。

因為用程式碼方式開發 Power Automate 時，舊版設計器有時會啟動，或是無法穩定建立動作；即使是 Codex / Claude Code / GitHub Copilot CLI，行為也不夠穩定，
所以我改成在新版設計器的 UI 上使用 Copilot 來建置 Power Automate。

因此，設計完成後接下來就是「操作手冊 + Copilot Prompt 集合的生成」。
不過既然設計都已經有了，這部分理論上也能生成……只是礙於時間，我就先跳過了。

5.7 Phase 3 — Copilot Studio Agent 建置

最後的階段，是建置 Copilot Studio Agent（也就是它自己本身）。

Copilot Studio 自己做了這些事：

提出 Agent 的目的、指示、Topic 設計方案
提出圖示圖片的生成方案（多個候選）→ 選定後實際生成圖示
產生部署腳本（deploy_agent.py）

人類做了這些事：

在 Copilot Studio 建立空白 Agent → 從 URL 複製 Bot ID 並交給它

這部分如同 Geek Fujimura 先生影片中說明的，沒辦法用命令列直接建立，所以還是得在 Copilot Studio 的 UI 上操作。
但其實也就只有這一步而已。指示文字、說明文字、圖示設定、Topic 設定，全部都由部署腳本透過 Dataverse Web API 寫入。

它生成的火箭風格圖示挺不錯的。

6. 說實話……各種坑點

讀到這裡你可能會覺得「其實 Copilot Studio 也做得到不少事嘛」，但以現在的狀況來說，沒有那麼簡單。

接下來說說卡住的地方。大致上有三個：

6.1 其實 Copilot Studio 並不是為 AI 編碼而設計的，我覺得上下文限制很低

這是最大的障礙……上下文上限低得很明顯。

把 copilot-studio-code 用來讀取儲存庫的主要檔案（AGENTS.md + README.md + 各種 SKILL.md）時，感覺光這些內容就幾乎把上下文吃掉大半。之後 Prompt 的反應開始不正常、回應變得極短、甚至對話無法成立，這些跡象都出現了。

因此，輸入端也得做一些取捨。

原本我想給它更詳細的業務需求範例（例如假想公司的入職／離職／異動 IT 手配郵件內文與業務訪談備忘錄），但如果整段直接貼上去，就會在那個時間點消耗大量上下文。所以這次我就壓縮成「我想用 Power Platform 做一個員工到職導引工具的展示環境」這一句，讓代理程式自己設計。
雖然這也變成一種「觀察它能不能自主設計」的測試，結果算是不錯；但若是要丟很細的設計內容進去，恐怕不太適合。

6.2 Copilot Studio 只記得最近 10 回合的對話紀錄

這是這次碰到的問題裡，文件證據最清楚的一項限制。

Microsoft Learn 的 Generative Orchestration FAQ 明確寫著：

For conversations, the system references the last 10 turns of conversation history to fill in inputs and determine the most relevant capabilities to invoke.(譯：在對話中，系統會參照最近 10 回合的對話歷史來補齊輸入值並判斷應呼叫哪些功能)

出處：FAQ for generative orchestration - Microsoft Copilot Studio

也就是說，Phase 0 做出的 Dataverse / Power Apps / Power Automate / Copilot Studio 設計，到了 Phase 2.5 時大概早就已經從會話歷史中消失了。
而且每次為了排錯多問幾輪，又會再往前擠掉更多內容。

我實際上在 Phase 2.5 時，也看到了 Copilot Studio 這樣的反應：

However, I don't have the conversation history from Phase 0.

（譯：不過，我手上沒有 Phase 0 的會話歷史。）

這點是我自己的進行方式不夠友善……應該在每個 Phase 結束時都讓它用 write_file 輸出文件才對。
那樣一來，即使後面的會話歷史被擠掉，它也可以再用 read_file 讀回自己產生的設計書。

6.3 影片只拍成功的場次

這點我也老實說。

其實 我重試了幾十次！！！！！！
大多數失敗大概都是受上下文上限影響，做到一半就開始無法正常對話。

也就是說，目前再現性不高。只是 PoC 層級「真的跑得動」而已，還不到正式運用。 如果要這樣理解，會比較符合現況……

如果目標是自然語言式開發，那老實說，還是直接用 Claude Code / Cursor / Codex CLI / GitHub Copilot CLI，穩定性與生產力都會高上好幾百倍。

7. 即便如此，我還是覺得值得一試的個人理由

老實說，目前還稱不上「實用」，比較像是「PoC」。但我仍然對這個組合很有未來感，也覺得很有趣。原因有三個：

理由 1：AI 編碼代理程式的選擇變多了

過去說到 AI 編碼代理程式，大多是 Claude Code / Cursor / Codex CLI / GitHub Copilot CLI，主要介面都是「開發者本機上的終端機或 IDE」。

這次的組合，等於證明了可以把 Copilot Studio 的對話畫面當成 AI 編碼的介面。
對於「不想開終端機的人」或「希望整個流程都留在 Microsoft 365 生態系內」的組織來說，這可能是新的選擇。

理由 2：完全依靠 Microsoft 生態系的體驗很有吸引力

從企業治理角度來看，能在 Microsoft 原生生態系中完成 AI 編碼體驗，是很有衝擊力的。
（雖然這次還是用了本地 MCP 伺服器）

理由 3：Copilot Studio 建 Copilot Studio

這是我最單純感興趣的地方。
現在已經是 AI 代理程式彼此建構 AI 代理程式也很自然的時代了，那 Copilot Studio 可不可以也做到同樣的事？我一直有這個想法。

CodeAppsDevelopmentStandard 裡面已經包含把 Copilot Studio Agent 設定值寫入的技能，所以如果這個 PoC 能穩定運作，並且未來新增與連線也都能用命令完成，那麼看起來就有機會做到：由一個 Copilot Studio Agent 去設計並建置另一個 Copilot Studio Agent。
雖然也能預見大量 Shadow AI Agent 產生的未來，但那就是 Agent365 的工作了。

8. 總結

Microsoft 內部人員公開的 copilot-studio-code，是一個能把 Copilot Studio 變成 AI 編碼代理程式 的 MCP 伺服器。
把它和 Power Platform 的代碼優先建置標準儲存庫 組合起來，就能從 Copilot Studio 的對話畫面一路推進到 Dataverse / Power Apps / Power Automate / Copilot Studio Agent 建置。
不過，上下文上限低、只記得最近 10 回合對話、而且必須以重試為前提的現實 仍然存在。這只能算 PoC，不是正式運用。若要老老實實做開發，Claude Code / Codex CLI 當然還是更好。
即便如此，能探索到 「Copilot Studio 建 Copilot Studio」 這種未來感十足的可能性，還是很有意思。