前言

Microsoft 365 Copilot 的代理程式建立器現在可以新增「技能」了。只要將 SKILL.md 與範本、腳本等隨附檔案打包成 ZIP 上傳，代理程式就會依照那些步驟執行作業。

將技能新增到 Agent Builder（Microsoft Learn）

※以本文撰寫時的官方文件來看，寫的是「預覽（僅 Frontier 計畫參與組織）」，但 訊息中心（MC1476977） 也有提到一般提供的部署。比較保險的做法，我想是直接確認你使用的租用戶中，「設定」分頁是否已出現技能。

之前，我曾在以下文章寫過 Copilot Studio 的「harness」以及 GitHub Copilot harness。

過去我個人一直認為，代理程式建立器是「用提示詞與知識就能輕鬆建立代理程式」的工具；至於較複雜的檔案製作、或是要依步驟處理的工作，則屬於其他 Copilot（例如 PowerPoint Copilot）或 Copilot Studio 的範圍。不過，既然現在加入了技能，背後還能跑腳本，這條界線就大幅改變了。

因此，我把之前在 Copilot Studio 的 GitHub Copilot harness 做過的驗證，換成同一個題材、同一段需求文，改在代理程式建立器上再跑一次。這次我想從結果中整理出「代理程式建立器的進化」以及「它和 GitHub Copilot harness 的差異」。

驗證前提

這是 2026 年 10 月時點的驗證。

由於建立器不能選模型，所以模型並沒有對齊。因此，這裡談的差異，會是把「harness、模型、以及自動判斷要考慮到哪裡」一起視為產品層級差異。以使用者角度來看，我認為這就是實際上的差異。

另外，測試次數也不算多。資料製作 1 次、改寫搜尋各 3 次，後半段「需要重新思考」的情境各 1 次。請把它當成趨勢來看。

代理程式建立器現在能做到的事

可以用 ZIP 新增技能

代理程式建立器的「設定」分頁多了「技能」區塊。從「新增」上傳包含 SKILL.md 與隨附檔案的 ZIP 後，技能就會和提示詞、知識一起顯示出來。

打開已新增的技能，可以確認 SKILL.md 的內容（指示）以及隨附檔案的資料夾結構。這次我隨附的是簡報零件集（PowerPoint）、零件目錄（Markdown），以及用來複製零件的 Python 腳本。

在製作排班的代理程式中，我也把兩個技能，加上員工主檔與編成規則的 Excel 一起作為知識（附加檔案）註冊進去。官方文件寫著，在預覽期間「技能與上傳檔案的知識不能併用」，但我這次的環境裡兩者同時放入也能運作。

技能的隨附檔案會在沙箱中執行

放進技能 ZIP 裡的範本與腳本，會被放到代理程式背後的沙箱（作業用的隔離環境）中，並可用 Python 讀寫。python-pptx（用程式產生 PowerPoint 的函式庫）也一開始就已經安裝好。

以下是載入並執行排班技能的畫面。

官方文件指出，沙箱無法連上網路，也不能新增套件。技能必須以「只使用內建內容即可運作」為前提來設計。

宣告式代理程式的自訂技能（Microsoft Learn）

連同格式一起使用範本來做資料

我把先前在 Copilot Studio 使用的技能——「附上 37 張的簡報零件集，挑選符合內容的零件複製後替換文字」——幾乎原封不動地放進建立器。需求是：用 3 份 Word 素材，為一家虛構公司的內部活動企劃做出 10 張投影片。

結果產出的 10 張資料，保留了零件集的配色、字型與圖形。它也會先用表格提出大綱請我確認，完成後再轉成圖片檢查外觀，這些步驟都有照 SKILL.md 的內容進行。

不過，其中一份附上的 Word 因上傳錯誤而無法讀取，另外還有我沒要求的計算值（每人金額）也被加進去，細節上還是需要確認。

另外，如果只是依範本製作 PowerPoint 資料，PowerPoint Copilot 其實也足夠了。也就是說，單純從「做出資料」這個角度來看，很多生成式 AI 的差距已經變小，這件事本身也已經相當普及，不太算差異化了。

我在這裡想強調的，不只是「建立器也能做資料」，而是它可以把範本與腳本當作技能隨附，並依照既定步驟處理這件事。

匯入全部清單進行搜尋

我也做了把含有 6,500 筆客訴的 SharePoint 清單當作知識，並詢問「把符合的客訴全部列出來」的驗證。

建立器會在沙箱中把清單完整讀成表格，再用程式篩選。以下是我要求「所有在精密齒輪箱 GB-200 出現異音的客訴」時的回答。打開「程式碼與執行」後，可以看出它是把清單讀成 CSV（pd.read_csv('ClaimRecords.csv')），再依產品名稱與內容中的詞語篩選。它完整回傳了正確的 22 筆。

像是「同時具備故障且重大程度高、但還未完結」這樣結合三個條件的問題，也會先說明使用了哪些條件，再正確回傳 14 筆。

像這樣用產品名、客戶名、期間、嚴重度等欄位來篩選的問題，件數都能準確抓出來。若沒有符合項，也會回答「沒有符合」，不會把其他相似故障硬套進來。

以前的知識搜尋（RAG：透過搜尋找出與問題接近的列再讀取）不擅長「回傳全部」，所以我個人覺得這是最大的進化。這一點 Copilot Studio 的 GitHub Copilot harness 也一樣，兩者都是把清單讀成 CSV 再進行分析。

※以前不僅無法把清單加入知識，即使能加進去，精準度也不太理想。以這點來看，確實進步很多。

像是搜尋有表記差異的產品名、修正「原因應該只有一個」這種錯誤前提，建立器也都能正確回傳數字。

依固定規則進行組合

我也試了排班（依生產計畫、休假希望、員工主檔，按照編成規則排出一週班表）。建立器會用技能附帶的驗證腳本檢查自己的方案，兩次執行都沒有任何必須規則違規。

第一次時，它判斷技能附帶的組合處理無法滿足資格條件，於是自己寫了最佳化處理重新排。

在回答確認問題後，約 2 分 10 秒內就回傳了附驗證結果的回答，以及班表、調整備忘錄、出勤依賴備忘錄這 3 個檔案。它回報必須規則違規 0 件、總人數 52 人／52 人；而我另外用其他腳本檢查輸出的檔案，也確實沒有規則違反。它也沒有隱瞞夜班次數偏差超過目標這件事。

第二次則是邊手動修正邊進行，因此結果也略有不同。雖然每次的解法不一定相同，但只要是規則明確、而且可以用腳本驗證正確性的工作，建立器現在也已經能做到這個程度了，這是我這次最大的感受。

我覺得 Copilot Studio 較擅長的場景

如前所述，建立器能做到的事已經大幅擴展。不過從這次結果來看，也有一些情況讓我覺得「這種時候，Copilot Studio（GitHub Copilot harness）也許更擅長」。

改寫搜尋

第一個是語句不統一的搜尋。

建立器每次都只用了「1 秒推理」，先用一開始決定好的詞彙搜尋一次就直接回答。Copilot Studio 則是先查看目標列的寫法列表再決定用詞，並在看到結果後進行加減修正，例如「這一列不是生鏽，所以排除」、「也要對照其他說法」等。

以下是在以一筆客訴為起點、詢問「同種類的不良，包含不同說法的全部」時，Copilot Studio 思考中的畫面。它會確認像「防潮袋破了」這種列不是生鏽所以排除，並縮小查看表記列表。

在同樣的需求下，建立器只得出 21 筆（正解 25 筆）。它沒有多抓錯誤資料，但漏掉了「白鏽」以及「鍍層表面氧化變黑」的資料。

我也試過在提示詞中明寫步驟，例如「建立表記列表並全部讀取」「回答前再執行一次並比對」，但建立器的件數沒有改變。它雖然會執行像是件數確認這種較省工的步驟，但「看完結果再重新搜尋」這種步驟被省略了。

需要重新思考的場景

第二個是中途發現「怪怪的」而需要重新思考的場景。我把兩個「如果直接回答一次就會答錯」的情境，分別丟給兩邊。正解都已經先用原始資料算好驗證過了。

情境 1：材料不一致

我把生產計畫、休假希望、前月實績的 Excel 附上，請排班（員工主檔與編成規則已註冊為知識）。

請排出 10 月 5 日那一週的班表。我會附上檔案。

我在附上的材料中埋了 3 個不一致：

• 週六備註寫的是「週六僅日班」，但夜班需求人數卻是 2 人
• 週日區分是「停工（設備維護）」，但日班需求人數卻是 4 人
• 休假希望中，包含一位不在員工主檔裡的員工休假申請

如果是人來處理，通常會在開始排之前先問「這裡到底哪個才對？」

情境 2：後補條件

即使在沒有不一致的材料上先排完班，我也在同一段對話中連續加了兩次條件。

鈴木先生（EMP-02）因急病，10/8 和 10/9 不能上班。請重新排這一週的班表。

另外，加藤先生（EMP-10）這週不能排夜班了。請重新排。

加上第二個條件後，能排夜班的檢驗員只剩 1 人。編成規則要求「每個班別至少 1 名有資格者」以及「夜班後隔天休假」，因此同一個人不可能連續兩晚上班，這樣就沒有辦法在滿足全部必須規則的前提下排出班表（這點已先用計算確認過）。這題正確答案應該是「無法排出」。

結果

情境 2 的第一個條件（鈴木先生急病）也看得出差異。Copilot Studio 老實回報不足人數並提供選項；建立器則是忘記前一次的班表，反過來問我「請附上」，重新排出的表也仍然少 1 名夜班人員。

差異最大的地方，是第二個條件（無法解的條件）。Copilot Studio 會逐一計算能上夜班的檢驗員，說明「兩晚一定會沒有檢驗員」，手動重新排了 3 次，之後又自動搜尋約 3 萬種組合來確認。最後還寫明「還沒有產生新的班表。前一次的檔案不能套用到這次的條件。」

建立器在相同條件下則做出班表，並報告「必須規則違規 0 件」。

在實務上，最麻煩的就是「看起來排出來了，但其實違反規則」這種情況。這次能避開這種問題的是 Copilot Studio。

另外，在有表記差異或錯誤前提的問題上，建立器也有正確回傳數字，但 Copilot Studio 會補充一些雖然沒被問到、卻有助於判斷的內容，例如「已讀成相同表記」、「16 筆都是同一個產品」之類。我覺得這裡也能看出同樣的傾向。

個人觀察：分出強項與弱項的關鍵，或許是「重擬計畫」能力

以下是我個人的看法。

建立器之所以能做得更多，我認為是因為它也像 GitHub Copilot harness 一樣，會在沙箱裡把資料以表格方式載入，再用程式分析。像是完整計數、依欄位篩選、依規則組合再驗證，這些事情在建立器裡也已經能做到了。

不過，我會覺得 Copilot Studio 較擅長的，是看完結果後察覺「不對勁」，並重新規劃的場景。改寫搜尋、材料不一致、無法解的條件，都是需要「發現沒有被明說的事情，然後停下來、懷疑、再找一次」的工作。

關於搜尋，我再補充一下。像 RAG 這種使用向量索引的方式，索引端會幫你撈出語意相近的內容，但不容易回傳全部。把全部資料載入後用程式檢查的方式，網羅性雖然大幅提高了，但能不能找出語意相近與改寫，則取決於代理程式是否會自己想出接近的詞再去查，並讀取結果後重新來過。

也就是說，對於這種全量型的方式來說，「是否真的找到需要的資訊」取決於有沒有跑這個重檢循環。GitHub Copilot harness 在這方面，確實會消耗比較多時間與 credit。

就 credit 來看，在排班重想情境（材料不一致與後補條件）的對話中，畫面顯示大約是 105 credits。這不是單次請求，而是包含確認回覆與追加條件的整段對話總量。作為參考，這個月同一個代理程式反覆跑了數十次之後，排班代理程式總共約用掉 484 credits，客訴搜尋代理程式則約 397 credits。以重複測試的次數來看，我個人覺得這比想像中還算節制。

我認為，透過在提示詞中寫成步驟，某種程度上可以補足一部分。但在這次測試範圍內，即使把步驟寫進去，建立器也只會執行比較省事的部分。我覺得它雖然可以用提示詞彌補，但仍然會有無法完全補上的領域。

除此之外的差異，以及未來可能擴大的地方

這次的驗證，是讓它在聊天中接收需求，並在我提供的資料範圍內產出答案。

我個人認為，若是以下這類工作，Copilot Studio 擅長的場景還會更多。

工具整合、聊天以外的觸發條件、複數代理程式

代理程式建立器不能註冊自訂動作或連接器來操作外部系統（有需要時，系統會引導你複製到 Copilot Studio）。

Agent Builder 概觀（Microsoft Learn）

Copilot Studio 可以串接外部系統，也能用郵件到達、時間等非聊天事件作為觸發條件來自動運作，還可以串接多個代理程式。從「讓 AI 代理程式代替人處理一部分工作」的角度來看，能做到這些，所能承接的工作範圍會大不相同。

而且，越是這類工作，就越常需要看中途結果再決定下一步。這次看到的「重擬計畫」差異，隨著工作變長、變複雜，應該會越來越明顯。

檔案傳遞

這次的驗證範圍，是使用者在聊天中附加檔案，代理程式再把產出的檔案透過聊天回傳。即使在這個範圍內，建立器也曾在對話中失去前一次結果，說出「請附上前一次製作的班表」。

但如果把代理程式用在實際工作上，檔案傳遞通常不會只在聊天裡完成。像是下面這些流程就很常見：

• 當檔案被放到指定位置時，觸發代理程式去處理
• 依處理結果更新原始檔或其他檔案
• 把完成的檔案上傳到 SharePoint 等其他位置，交給相關人員

在 Copilot Studio 的 GitHub Copilot harness 中，搭配工作流程之後，已經朝向把「接收、處理、更新、儲存到其他位置」串起來的方向前進。雖然目前仍有部分不穩定之處，這點也還需要再驗證；但如果能把代理程式的推理與工具結合，最後一路送到成果物，能承接的範圍應該會進一步擴大。

目前的代理程式建立器，還是以聊天中的附加與回傳為主。能不能把「接收檔案、處理、交付」當成一整段工作交給它，也很可能會成為未來差異的一部分。

harness 本身的進化速度

GitHub Copilot harness 顧名思義是以開發者每天都在使用的東西為基礎，因此我感覺它本身的進化速度很快。

相較之下，代理程式建立器背後實際用的是什麼 harness，公開資訊中找不到。這次我看到它的執行環境資料夾結構和 Copilot Studio 不一樣，所以我猜它可能是另一種機制，但細節不清楚。從未來進化速度這個角度來看，我認為也多少會拉出一些差距。

即便如此，代理程式建立器的進化仍然很令人感激

話雖如此，我仍然覺得代理程式建立器的進化，對非常多使用者來說是很有幫助的。

像是把範本連同格式一起拿來做資料、或是能從平常使用的 Microsoft 365 Copilot 畫面輕鬆試做完整搜尋，這些都變得更容易了。這次驗證中，對於規則明確、而且可以驗證正確性的工作，它也已經能做到相當高的水準。

就我個人而言，比較實際的作法是：先用代理程式建立器體驗「只要用技能把步驟交給它，就能做到這個程度」；當工作變成需要看結果再重新思考，或是需要外部系統、觸發條件、複數代理程式時，再考慮 Copilot Studio。

總結

這次我從同一個題材的驗證出發，整理了代理程式建立器加入技能之後能做到什麼，以及它和 Copilot Studio 的 GitHub Copilot harness 有什麼不同。

• 建立器現在也已經能做到：將資料完整載入後搜尋、連同格式一起使用範本做資料、依規則組合並驗證
• 需要看結果後察覺問題並重新擬定計畫的場景（改寫搜尋、材料不一致、無法解的條件），我認為 Copilot Studio 比較擅長
• 若是包含工具整合、觸發條件、多代理程式的長流程工作，這種傾向可能會更明顯

這畢竟只是 2026 年 10 月時點、且測試次數不多的結果。我也覺得這和我自己的測試方式有關，所以也很期待能收集到更多「我這邊的情況是這樣」之類的資訊。

希望這篇文章能幫助你思考代理程式建立器與 Copilot Studio 的使用分工。

原文出處：https://qiita.com/Takashi_Masumori/items/c559b0291db39b2169c1