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

新的 Copilot Studio 已正式 GA，所以重新整理一下「harness」與 credit 計費體系

※本文章是以 2026/8 時點的公開資訊（Copilot Studio 官方部落格、Microsoft Learn、Copilot Credits Guide 2026 年 8 月版）為基礎整理而成。未來仍有可能變更，因此在簽約或導入決策時，請務必確認最新的官方資訊。

前言

2026 年 8 月 3 日，過去以預覽版提供的新 Copilot Studio 正式進入一般可用（GA）。同時，也正式公布了名為「GitHub Copilot harness」的新名稱，以及以 Copilot Credits 計價的用量型收費制度。

我先前已在以下文章中實際試用過新的 UI 與工作流程，但隨著 GA，術語與授權制度都大幅整理過了，因此想在本文重新整理一次整體輪廓。

這次特別想釐清兩個點：其一是，是否仍能在許多企業原本假設的「Microsoft 365 Copilot 授權使用權（fair use）」範圍內使用；其二是，是否會從建立階段就開始收費。這兩點，是準備開始評估新 Copilot Studio 的人最先應該掌握的重點。

到底什麼是「harness」？

這次發表中突然出現的「harness」這個詞，老實說，第一次聽到時很多人可能都沒有概念。先來把這個詞整理一下。

官方定義

在 Copilot Credits Guide（2026 年 8 月版）中，harness 被定義為：

讓代理程式進行規劃、推理、維持上下文，並與工具、系統及其他代理程式協作以完成任務的「軟體支架（scaffolding）」

個人理解

如果只看這句，還是有點抽象，所以我個人會這樣理解：

生成式 AI 的模型（LLM）本身，只能輸出文字等內容。它不能自己寄信，也不能自己搜尋 SharePoint；實際上是模型先輸出「我想用這個工具這樣做」之類的文字，然後由接收到這些文字的外圍系統來執行。更進一步來說，模型本身每次呼叫都是沒有記憶的狀態（無狀態），而會話上下文與處理過程中的中間狀態，也都是由模型外部的機制負責重新整理並傳回模型。

因此，需要有一套圍繞模型的機制，將「輸出的文字轉換成實際處理，並把結果再回傳給模型，讓它做下一步判斷」。這整套機制，就是 harness。

比喻來說，模型是引擎，而 harness 是車體。即使是同一顆引擎，若車體設計不同（例如規劃方式、工具呼叫方式、結果確認方式、處理迴圈的跑法不同），整體表現也會完全不一樣。harness 這個詞本身原本就有「馬具」的意思，所以也可以把它想成「替模型這匹馬裝上馬具，讓它拉著業務這台貨車前進」。

與以往「協調處理（orchestration）」的關係

可能有人會想：「這不就是以前說的生成式協調處理嗎？」我認為兩者的層次稍微不同。不過，未來這個詞可能不會再那麼常用。

Orchestrator：決定要如何組合工具與知識的「大腦」部分
Harness：把這個判斷真正執行起來的迴圈與基礎架構；Orchestrator 是建構在其上

Microsoft 的發表中也有這樣的說明：「新的 orchestrator 是建立在新的 coding harness 與 CLI 層之上」。

對於用語變更的感想

以下完全是個人感想。

老實說，這種用語的推出方式，對於想從 Copilot 延伸到 Copilot Studio 的人，以及公民開發者來說，我覺得不太友善。「生成式協調處理」這個詞本來也不是很容易懂的詞，但……

我認為 Copilot Studio 真正的價值，在於讓那些不一定懂開發的人，也能成為主角，思考「要把哪一段業務流程交給 AI 代理程式處理」。事實上，新的 UI 也已開始降低門檻，例如過去從 Power Virtual Agents 時代延續下來所需要的知識、以及設計 topic 結構的技術門檻，都已經逐漸下降。這是非常值得肯定的改變。

正因如此，在入口處把主要是開發者圈子裡熟悉的術語擺到前面，雖然大概有行銷上的考量，但我個人還是覺得，這種說法會讓部分人感到門檻變高。

對我來說，對於從 Copilot 延伸使用，或從公民開發延伸使用 Copilot Studio 的人而言，記住 harness 這個詞本身並不是最重要的。真正重要的是，從管理與業務改善的角度出發，去提出問題、思考要把哪些業務交給 AI 代理程式、將業務語言化與拆解，並在必要時重新檢視業務流程本身。

此外，也必須理解下一節要說明的「選擇哪一種開發方式，能做什麼，以及如何計費」。知道大概要花多少錢，也有助於判斷這件事是否比仍由人來處理更有價值。

因此本文也只把用語解釋到這裡，之後會聚焦在決策所需的資訊。

3 種 harness 與新舊 Copilot Studio 的對應

目前 Copilot Studio 支援 3 種 harness。官方指南的整理如下。隨著這次發表，傳統 Copilot Studio 也被重新定義為 Standard harness 與 Copilot Chat harness。大多數情況下，可理解為過去使用的是 Standard harness。暫時先這樣重新定義，以便對照理解。

harness 定位官方範例 GitHub Copilot harness 以代理式建立體驗最佳化整體業務流程讀取發票、與訂單核對，並將例外情況送交核准流程的應付帳款代理程式 Standard harness 以 topic 與 flow 為基礎的規則式對話型代理程式。現在大多數代理程式都屬於此類將 PC 申請導入核准／派工工作流程的 IT onboarding 代理程式 Copilot Chat harness 以組織知識自訂 Microsoft 365 Copilot 從 SharePoint 內容回答問題的員工 FAQ 代理程式

新舊 UI 的對應，我認為可以簡單理解為下面這樣：

新的 Copilot Studio（新 UI，從首頁的「Try now」進入的體驗）所建立的代理程式與工作流程，會運行在 GitHub Copilot harness 上
傳統的 Copilot Studio（classic）所建立的代理程式，會運行在 Standard harness 或 Copilot Chat harness 上

重點在於，既有 harness（也就是傳統 Copilot Studio，昨天之前其實還沒有被稱為 harness）並不是被廢棄，而是與新架構並存。官方部落格也明確說明，Copilot Chat / Standard harness 既支援既有代理程式，也支援新建立的代理程式，並會持續支援。既有代理程式也不會被自動切換到新的 harness。正確的理解是：這不是「取代」，而是「依情境增加可選方案」。

另外，官方文件也明確指出一個注意事項：無法將在新體驗中建立的代理程式轉換成 classic，也無法將在 classic 中建立的代理程式轉換成新體驗。也就是說，建立時要先選擇要用哪一種體驗，之後無法來回轉換。

授權制度：到底在哪裡會產生費用

接下來是重點。先直接下結論：

GitHub Copilot harness 的代理程式，不論是否擁有 Microsoft 365 Copilot 授權，所有使用都採 Copilot Credits 的用量型計費。

過去 Standard harness 的代理程式，在 Microsoft 365 Copilot 授權使用者於公司內部（已驗證的 B2E）情境下使用時，會被整理為包含在使用權（fair use）內。這項整理在 Standard / Copilot Chat harness 上未來仍會持續，但 GitHub Copilot harness 從一開始就不在其範圍內。這是這次最大的變更，也是對過去以 Microsoft 365 Copilot 授權為前提規劃推廣的企業來說，成本設計前提會改變的地方。

收費可分成 3 個階段來看

GitHub Copilot harness 的收費，可以用「建立」「測試與評估」「執行」這 3 個階段來理解。新的 UI 由 Build / Preview / Evaluate / Monitor 4 個分頁構成，因此我先把實際畫面與收費對應起來。

我個人認為，「建立」與「測試／評估」階段也會產生費用，這點影響相當大；從 IT 管理者的角度來看，必須防止不小心消耗掉大量 credits。

新 UI 分頁角色 Credit 消耗 Build 指示詞、知識、工具、技能、模型的組成手動組成免費。只有以自然語言請 AI 幫忙建立時才會消耗 Preview 預覽聊天的互動測試會消耗（與執行相同） Evaluate 透過建立與執行測試集進行品質評估會消耗（與執行相同） Monitor 檢視任務、存取過的檔案、活動免費

以下數值皆為 Copilot Credits Guide 2026 年 8 月版中所載的官方參考值（1 credit = 0.01 美元）。

【階段 1】建立（自然語言建構）

在新的 Copilot Studio 中，可以直接用自然語言請系統幫你建立代理程式本身。

不過，手動配置完全不會消耗 credits。包含 Build 分頁與 Monitor 分頁在內，所有手動設定都明確標示為免費。

會被收費的是用自然語言讓 AI 幫你建立代理程式或工作流程的情況。消耗量可依一次建立 session 中自己送出的訊息數（conversation-turn）來估算。

情境回合數預估 credits 日圓換算參考（1 美元 = 150 日圓） Light 1～2 回合 1～20 約 2～30 日圓 Medium 3～5 回合 21～60 約 32～90 日圓 Heavy 6 回合以上 61～約 92 日圓～ Light 的例子是像「幫我做一個摘要郵件的代理程式」這種一鍵式指示；Heavy 的例子則是包含委派代理程式、工具輸入輸出定義、啟用記憶體等完整設計指示。

老實說，我覺得建立階段的收費比原先想像中還要輕很多。即使是最重的 Heavy，1 個 session 也大約是 100 日圓左右的量級。對於「從建立階段就開始收費」這件事，其實不必過度擔心，這是我個人的結論。

【階段 2】預覽、測試與評估（Evaluation）

這裡是注意重點。預覽中的測試對話，以及 Evaluation 的執行，會消耗與下一節「執行」相同的 credits。也就是說，測試不是「因為屬於建立的一部分所以比較便宜」，而是「與正式執行相同的成本」。

在驗證過程中若反覆執行測試，成本中心通常會比建立更偏向這一塊。例如，若執行 50 次 Light 等級的測試，就會消耗 5,000～15,000 credits（50～150 美元）。因此，驗證專案的預算應該不是按建立費來估，而是按測試執行次數來估。

【階段 3】執行（公開、展開後的執行）

公開後實際執行時的消耗，取決於模型、執行階段、上下文與工具這 4 個要素。官方對不同情境的參考值如下。

情境特徵預估 credits 每次約日圓換算（參考） Light 少量來源、輕度推理、成果物不超過 1 個 100～300 約 150～450 日圓 Medium 多來源、結構化推理、成果物 2 個以上 300～500 約 450～750 日圓 Heavy 廣泛來源彙整、深度推理、多個成果物 500～約 750 日圓～官方範例中，Light 的例子是「確認每日營運郵件並將狀態摘要發布到頻道」，Heavy 的例子則是「執行跨多年的法遵稽核，產出報告並透過 SharePoint、Teams、電子郵件發送」。

從這個單價也能看出 Microsoft 想要的使用分工。每次 150～450 日圓的成本，如果是人類要做 15～30 分鐘的工作，那是合理的；但若拿來做幾十秒就能完成的 FAQ 回答，就明顯偏貴。換句話說，高頻、單次工作量很輕的對話型用途，仍適合 Standard / Copilot Chat harness（在 Microsoft 365 Copilot 使用權範圍內）；而即使頻率較低、但單次業務價值很高的自律流程，則適合 GitHub Copilot harness。從價格也能看出這樣的分工。

credits 用完會怎樣？

當環境配置的 credits 用完後，所有需要 credits 的功能都會停止。不只是面向終端使用者的代理程式回應會停掉，建立者端的自然語言建構、預覽與評估也都無法使用。雖然系統會提供一定程度的超額緩衝，以避免業務直接中斷，但處理方式仍只有三種：重新分配既有容量、加購，或設定用量型（Pay-as-you-go）計費 meter。

我個人認為，對於正式上線的環境，事先設定 Pay-as-you-go meter 作為保險，未來很可能會幾乎是必須的做法。

credits 的購買方式：可以事先購入嗎？一定要 Azure 訂閱嗎？

聽到「用量型計費」，很多人會以為一定要有 Azure 訂閱，但實際上購買方式有好幾種，也可以選擇預先購買型。整理如下。

購買方式內容 Azure 訂閱特點 Pay-as-you-go meter 1 credit = 0.01 美元，月底後付必要（需在 Power Platform 系統管理中心將計費方案繫結到環境）無需承諾，超量時也可作為保險 Copilot Studio 授權（credits 容量套件）每月 200 美元可得 25,000 credits。不需 Azure 訂閱可月繳到期失效（不累積）。實際單價較便宜 Copilot Credit Pre-Purchase Plan（P3）年度預付的 credits pool，依規模可享 5～20% 折扣必要（以 Azure 入口網站中的 Reservation 方式購買）按年失效。可列入 MACC 抵扣 Microsoft Agent Pre-Purchase Plan（ACU）可跨 Copilot Studio 與 Microsoft Foundry 消耗的年度預付必要（同上）適合跨平台的企業

所以，對於「事先購買的 credits 也可以嗎？」這個問題，答案是可以。credits 會在租戶層級集中成池，不論是透過哪一種購買方式取得，都可以分配到環境中消耗。只有在使用 Pay-as-you-go meter 與 Pre-Purchase Plan（以 Azure Reservation 方式處理）時，Azure 訂閱才是必要的；如果只是購買 credits 容量套件，就算沒有 Azure 訂閱也可以開始使用。這是我的理解。

※購買途徑會因組織的合約型態（EA / CSP 等）而有所不同，實際採購時建議確認最新的 Copilot Studio 授權指南，並與帳戶團隊確認。

每月成本概算模型

最後附上一個可用於對客戶說明的簡單估算公式。

每月 credits 消耗 ≒
  （每日執行次數 × 依情境的 credits × 稼動日數）
  ＋ 驗證／修改期間的測試執行量（與執行同單價）
  ＋ 自然語言建構部分（每個 session 約 1～60 credits）

例如，若某個 Medium 情境的代理程式每天執行 20 次、每月 20 個工作日，則 300～500 credits × 20 次 × 20 天 = 每月 12～20 萬 credits（1,200～2,000 美元）。如果把這個金額和「同樣業務若由人執行所需的工時」相比，就很適合作為投資判斷的材料。

總結

這次整理了 GA 後的新 Copilot Studio（GitHub Copilot harness）中，harness 這個術語的意義，以及 credits 計費制度。重點如下：

harness 是「讓模型真正開始工作的支架」。使用者不必死記術語，只要掌握「選哪種做法、能做什麼、怎麼計費」即可
新 UI = GitHub Copilot harness；傳統 UI = Standard / Copilot Chat harness。既有 harness 並非被淘汰，而是共存
GitHub Copilot harness 不屬於 Microsoft 365 Copilot 授權使用權範圍，全部都是 credits 用量型收費
手動配置免費。用自然語言建立的成本很輕，大約每個 session 幾元到 100 日圓左右；成本中心主要在測試／評估與實際執行（每次 150 日圓以上）
credits 可以透過預先購買型（容量套件、P3）或用量型（Pay-as-you-go）購買。正式環境建議併用 Pay-as-you-go meter，作為超量保險

我個人覺得，隨著官方提供更具體的參考值，整體收費模式比一開始預想的更容易估算。不過，對於原本以 Microsoft 365 Copilot 授權為前提來規劃的企業來說，這確實是前提改變的一件事，因此建議先在測試環境分配 credits 上限，並在管理測試執行次數的前提下小規模開始。

希望這篇文章能對正在評估新 Copilot Studio 導入與成本設計的朋友有所幫助。