公司電腦上只能使用 Microsoft 365 Copilot。Claude、ChatGPT 和外部 API,都被資訊系統部門的政策封鎖了。──我想,處在這種環境的工程師其實不少。
不過,「只能用 Copilot」反過來說,也就是「把 Copilot 用到極致就好」。而且 Microsoft 365 Copilot 內建了 Agent Builder(代理程式建置工具)這個功能,不需要額外費用,就能建立屬於自己的 AI 代理程式。可以讓它參考公司內部的 SharePoint、規格文件、Web,幾分鐘內、不寫一行程式碼,就做出「專屬 Copilot」。
本文會根據 2026 年 6 月時點的最新規格,整理如何使用這個 Agent Builder 建立宣告式代理程式(declarative agent)。Microsoft 這個領域的名稱與 UI 常常改,所以我會特別意識「是什麼時間點、哪個功能」來撰寫。
另外,本文聚焦的是內建在 Microsoft 365 Copilot App 中的簡化版,也就是 Agent Builder,而不是正式版 Copilot Studio(可用低程式碼做外部系統整合的工具)。兩者看起來相似但其實不同,如果混為一談,會嚴重誤解「能做什麼、不能做什麼」。本文前半也會先整理這些差異。
先直接講結論。
Agent Builder 是可從 Microsoft 365 Copilot App 左側窗格啟動的無程式碼宣告式代理程式建立功能。只要你的環境能使用 Microsoft 365 的 Copilot Chat,就能在不加費用的情況下啟動;只要宣告「指示(Instructions)」和「知識(Knowledge)」,就能建立一個直接使用 Copilot 基礎架構(同一個協調器與基礎模型)的代理程式。不過,SharePoint 之類的公司內部資料能否作為知識來源,會因授權而異(後述)。
但它不能建立可呼叫外部 API 的「動作(Actions)」。這是完整版本 Copilot Studio 的領域。Agent Builder 擅長的是「參考內部資料與 Web 來回答問題」這種以讀取為主的代理程式。
先列出最新規格數字(截至 2026 年 6 月。這類上限在過去一年常被調高,實際上線前請務必再確認官方最新數值)。下面列出的上限與規格不因授權而改變,但「能不能使用該項目」會因授權而不同。右欄另外標示「只有 Copilot Chat(無用量計費)時是否可用」。
項目上限・規格只有 Copilot Chat 時可用嗎手順(Instructions)8,000 字元○公開 Web 網站最多 4 個 URL(最多 2 層、不可帶查詢字串)○知識來源總計最多 20 個△(僅 Web)SharePoint 檔案最多 100 個✕OneDrive 檔案最多 50 個✕上傳(內嵌)檔案最多 20 個 / 1 檔 512MB(Excel 為 30MB)✕Teams 聊天最多可將 5 個範圍指定為知識來源✕也就是說,只有 Copilot Chat(無用量計費)時,這張表中實際可用的只有「手順」和「公開 Web」;包含 SharePoint 在內的公司內部資料來源項目都不能使用。手順的 8,000 字元上限則是所有授權共通,不會因授權而增減。要使用公司內部資料,必須有 Copilot 加購授權或啟用用量計費(詳見第 3 章)。
建立完成後,可以從「僅自己 → 特定使用者/群組 → 全組織」逐步分享;正式公開到組織目錄(Built by your org)則需要管理員核准。基本流程就是先做成自己的專屬版本,在「試試看(Try it)」分頁反覆調整,穩定後再分享。
Agent Builder 建立的東西稱為宣告式代理程式(declarative agent)。這個詞不太直觀,所以先拆開來說明。
「宣告式」的意思是,不是自己準備 AI 的核心(模型或推理引擎),而是只要「宣告」它的行為就能完成客製化。具體來說,要宣告以下 3 件事:
重點在於,底層 AI 與 Microsoft 365 Copilot 本體完全相同。協調器、基礎模型、可信任的 AI 服務──這些都直接借用 Copilot 本體。因此不需要自架主機,也不需要額外基礎設施。最接近的想像方式,就是「把既有 Copilot 換上一套專屬人格、知識與規則」。
因為這樣設計,宣告式代理程式會直接繼承 Microsoft 365 的安全性與合規性。後面會提到,這對處理公司內部資料是非常大的優勢。
這裡是第一個關卡。Microsoft 的世界裡有好幾種「建立代理程式」的方法,名稱也很像,所以容易混淆。先把本文的範圍講清楚。
Agent Builder(本文對象)Copilot Studio(完整版)啟動位置Microsoft 365 Copilot App 內獨立的 Web App難易度無程式碼低程式碼外部 API 動作不可可多通道部署只在 Copilot 內Teams / Web / 各種通道環境隔離・ALM・DLP簡易完整Dataverse 消耗不消耗預期用途快速、簡單的公司內部代理程式複雜工作流程、核心系統整合官方文件把 Agent Builder 定義為「適合快速且簡單專案的即時對話式 AI 開發體驗」。而且明確寫著:如果需要整合外部服務等進階功能,就應該使用 Copilot Studio。
換句話說,判斷標準很簡單:
如果是在公司裡只能碰 Copilot 的情況,多數情境先用 Agent Builder 就夠了。之後若想正式擴充,也可以透過後面會提到的「複製到 Copilot Studio」移轉。
Agent Builder 的結構是「工具本身可用,但可作為知識來源的資料會因授權不同而變」。這點很值得正確掌握。
先把容易誤解的一點講清楚:Agent Builder 這個工具本身,即使只有 Copilot Chat 授權也能使用。只要是能使用 Microsoft 365 Copilot Chat 的環境,就可以不加授權地啟動 Agent Builder,並且實際建立代理程式(從「建立代理程式 / Create an agent」進入)。授權影響的不是「工具能不能開」,而是「你能建立的代理程式內容」──也就是哪些資料來源能當作知識。
具體來說,在只有 Copilot Chat(無用量計費)時,可以免費建立只靠手順或公開 Web 的代理程式;但一旦想把 SharePoint 等公司內部資料作為知識,就會碰到授權限制。尤其是 SharePoint,最常發生「以為能用、開始做了才發現不能用」的情況,所以我把不同授權能用哪些資料來源整理成表。
知識來源Copilot 加購(進階版)用量計費(pay-as-you-go)啟用只有 Copilot Chat(無用量計費)手順僅限 / 公開 Web○○○SharePoint○○✕OneDrive○○✕上傳(內嵌)檔案○○✕Copilot 連接器○○✕郵件 / People / Teams 訊息・會議○✕✕另外,Agent Builder 的啟動與建立,在右欄「只有 Copilot Chat」的情況下也做得到;這和表格各列是不同概念。表格表示的是「能不能把這些知識來源組進代理程式」。
重點有 3 個。
首先,SharePoint 屬於中階功能。要使用它,必須有 Microsoft 365 Copilot 加購授權,或者在租用戶中啟用用量計費(Copilot Credits)。如果兩者都沒有,只有「Copilot Chat」的情況下,SharePoint、OneDrive、內嵌檔案與連接器都不能用,只能做手順型代理程式或參考公開 Web 的代理程式。
再來,郵件、People、Teams 屬於更高一階,必須有 Copilot 加購授權,用量計費無法使用。
最後,很容易忽略的是:這些條件不只套用在建立者,也套用在使用者身上。也就是說,如果是「建立者有進階授權、使用者只是免費 Copilot Chat」,那麼把 SharePoint 作為知識來源的代理程式,使用者端是無法正常運作的。和代理程式互動的使用者,也必須有 Copilot 加購授權,或者所屬租用戶已啟用用量計費。
這裡說的「SharePoint 不能用」,是指不能把 SharePoint 當作代理程式的知識來源來參考。平常開啟或編輯 SharePoint 檔案不受影響,授權不會限制這部分。被封鎖的是讓代理程式把它當作公司內部資料來讀取的能力。
如果想把 SharePoint 加入知識來源時,遇到「沒有選項可選」或「加入就報錯」,通常原因是以下幾種。
症狀懷疑原因根本沒有 SharePoint 可加的手段沒有 Copilot 加購+沒有用量計費(也就是上表右欄那種狀態)可以加,但使用者端沒反應使用者不符合所需授權/用量計費特定檔案讀不到檔案保護(加密、密碼、使用者自訂權限。見第 10 章)整個 SharePoint 都不能用租用戶啟用了 Restricted SharePoint Search(在此設定下無法把 SharePoint 當作知識來源)如果公司已正式指派 Microsoft 365 Copilot(加購授權),那麼 SharePoint、檔案、郵件與 Teams 都能作為知識來源,屬於完整功能。反過來說,如果卡在上面那些問題,最可靠的做法是向資訊部門確認自己的授權類型,以及租用戶是否啟用了用量計費。同時也要注意,管理員可能在 Microsoft 365 管理中心控制了 Agent Builder 的可用性或分享範圍,所以如果「選單沒出現」或「不能分享」,也要懷疑是租用戶政策。
接下來進入實作。以下依照最新 UI(2026 年 6 月時點)說明。
m365.cloud.microsoft,或 Teams / 桌面版 Copilot)建立方式有 3 種:
在「設定(Configure)」分頁中,主要可設定的項目與上限、建議如下。
項目上限重點名稱30 字以描述性且獨特為佳圖示PNG / 192×192px / 1MB 以下可從 AI 生成、圖庫或上傳選擇說明1,000 字會出現在應用程式目錄中,請簡短且精準手順(Instructions)8,000 字元代理程式的核心。後述知識總計 20 個來源重質不重量啟動提示不限制可提示常用問題回應模式Auto / Quick / Think deeper預設為 Auto回應模式有 3 種:Auto(自動調整速度與深度,預設)、Quick response(簡潔且快速)、Think deeper(適合複雜任務、會更深入思考)。使用者在執行時也可以覆寫。
另外有一個已知陷阱。官方明確說明:如果從主 Copilot 用 @mention 呼叫這個代理程式,設定的預設回應模式不會套用。這是設計如此,所以如果你要以 @mention 為主要操作方式,請把這點記在心上。
代理程式聰不聰明,幾乎取決於你讓它參考什麼。以下整理 2026 年 6 月時可指定的知識來源與上限。這些數字在過去一年常常被調高,所以本文可視為「2026 年 6 月的快照」。
https://example.org/a/b/c 這種 3 層的不行),不能帶查詢參數。也可以透過「搜尋所有網站(Search all websites)」切換成全 Web 搜尋。.doc/.docx/.pdf/.ppt/.pptx/.txt 每個檔案 512MB,.xls/.xlsx 為 30MB。不能以資料夾單位上傳。My Teams chats and meetings 可涵蓋所有聊天與會議(※需 Copilot 加購授權)。My emails 可涵蓋整個收件匣(※需 Copilot 授權,且不可做範圍指定)。設定上很重要的是「Only use specified sources(僅使用指定來源)」切換。如果把它開啟,系統在需要搜尋的問題上會只使用指定來源。不過要注意,即使開了,也不能完全阻止一般 AI 知識介入。若你希望「只能根據公司文件回答」,這種嚴格控制是完整版本 Copilot Studio 的領域。
像我這種情境,最有效的方法是把公司內部的規格書、資料表、操作手冊集中到 SharePoint 的單一網站(或文件庫),再把那個網站/資料夾 URL 指定為知識來源。這樣就不必逐一列出 20 個檔案,也能自動跟著檔案增減更新(索引會有幾分鐘延遲)。
如果要用 Excel 提供量測資料,建議把資料集中在同一個活頁簿裡的一個工作表,回答準確度會更好(.xlsx 上限 30MB)。如果散在多個工作表,代理程式常常會不確定該看哪裡。
手順最多可寫 8,000 字元,但真正重要的是結構,而不是字數。以下把官方「如何撰寫有效手順」指南的重點,轉成實務觀點來說明。
#/## 當標題,順序重要就用編號清單,並列任務用項目符號,工具名稱用 backtick,重點用粗體。代理程式會讀結構。search/check/summarize 這類動詞描述行為更有效。以下是一個手順骨架範例(以公司內部的初步判讀代理程式為例,節錄)。
# 目的
協助使用者初步判讀公司內部設備異常。
# 回應規則
- 只有在資訊不明確時,才一次問一個確認問題。
- 資訊以精簡條列或表格呈現。
- 進入下一步前,務必先確認。
# 步驟
## Step 1: 了解狀況
- 目的:確認問題。
- 行動:若說明模糊,只問 1 個聚焦的問題。
- 轉移:若已明確,進入 Step 2。
## Step 2: 對照已知現象
- 目的:排除已知故障。
- 行動:參考 SharePoint 的障礙紀錄。
- 轉移:若無對應項目,進入 Step 3。
# 輸出格式
- 步驟與清單採條列,結構化資料使用表格。
- 避免長段落,方便快速掃讀。
另外有件不起眼但很重要的事。宣告式代理程式的基礎模型,在 2025 年底到 2026 年間,已從 GPT-5.1 更新到 GPT-5.2。過程中,手順的解讀方式也從「逐字照寫」變成「優先理解意圖、具備適應性」。
這會造成什麼問題?原本照你預期運作的手順,在模型更新後可能會被重排,甚至自行補進推論。越重要的代理程式,越應該在官方公告模型更新時重新測試。若行為開始漂移,有時在手順開頭加上一句「一律逐字解讀指示,不要自行添加推論」(穩定化標頭),就能暫時穩住。
另外,為了規避 8,000 字元限制而把手順藏到 SharePoint 等知識來源裡,這種做法要避免。知識來源會受到注入攻擊分類器的處理,不保證一定會被當作指令,還會擴大攻擊面。手順就放在手順欄,知識就放在知識欄。不要混用角色,這是鐵則。
先講在前面,免得期待落空。Agent Builder 不能建立呼叫外部 API 的 Actions。像是建立票單、寫入核心系統,這類「執行型」功能都不在這個工具的範圍內。
把外部系統作為知識來源來整合(以讀取為主)可以透過 Copilot 連接器做到。但再往上──API 外掛、MCP 伺服器整合、REST API、訊息延伸功能、互動式 UI 小工具(MCP Apps)──就屬於 Microsoft 365 Agents Toolkit(VS Code)或完整版本 Copilot Studio 的範圍了。
如果不先劃清這條線,很容易高估「Agent Builder 什麼都能做」,最後卡住。以讀取為主就用 Agent Builder,需要寫入或執行就直接認定要用完整版本,這樣最健康。
名稱、說明、手順填完後,「試試看(Try it)」分頁會啟用,你可以像正式版一樣對正在建立的代理程式進行對話測試。邊調整設定、邊用同樣問題反覆測試回答變化──品質就是這樣磨出來的。
我的實務建議是先準備 5~10 個代表性問題,在它們都穩定答對之前,不要分享給任何人。把相同問題在加了知識前後各試一次,就能清楚知道新增知識有沒有發揮效果。
按下「Create(建立)」後,預設只會建立成自己可見(private)。接著再透過「Share(分享)」擴大範圍。
這裡最重要的是權限處理。如果知識來源使用了 SharePoint,分享對象若沒有該內容的存取權,回答中就不會包含那些內容。代理程式不會額外賦予新權限(No new privileges 原則)。這在安全上非常理想,能從結構上防止「沒有權限的人看到機密」的事故。
如果要作為全公司正式工具發佈,就要走組織目錄申請流程。選擇目標代理程式,從 Edit 進入「提交到組織目錄(submit to org catalog)」。管理員會在 Microsoft 365 管理中心審核,通過後就會出現在 Agent Store 的「Built by your org」。
這是在公司裡代理程式變多後一定會出現的問題。「想看同事做得很好的代理程式手順來學」、「想模仿運作順利的版本」──結論是,作為一般使用者,無法看到別人代理程式的內部內容(手順與知識結構)。
對於被分享的代理程式,非建立者的一般使用者只能看到以下這些「表面」資訊:
反過來看不到的是「內部」,也就是手順(Instructions)、知識來源的具體組成(參考了哪些 SharePoint 網站或檔案)、以及功能細節設定。這些都放在建立者專用的「設定(Configure)」分頁裡,使用者看不到。
更進一步,從別人分享來的代理程式不會出現在自己的「我的代理程式(My agents)」清單裡。清單裡只會有自己建立的項目。也就是說,不只不能編輯,連查看設定的入口都不存在。Microsoft 也明確寫了:被分享的代理程式,接收者不能編輯,編輯權仍屬於擁有者。
角色使用(聊天)表面資訊手順・知識結構一般使用者(分享對象)可可不可建立者(擁有者)可可可(「設定」分頁)管理員(AI 管理員 / 全域管理員)──可可查看(管理中心,唯讀)只有管理員比較特別:可以從 Microsoft 365 管理中心的 Agent Registry,以唯讀方式查看整個組織中所有代理程式的手順與知識結構(Data & tools 分頁)。一般使用者與管理員能看到的範圍差很多,這點要特別注意。
官方並沒有提供把別人的代理程式「複製(Make a copy / Duplicate)」出來的功能。網路上有些文章寫可以用 Make a copy 複製,但 Microsoft Learn / Microsoft 支援中心的官方文件並沒有這種說法。官方有提供的複製類操作只有兩種,而且都只限自己擁有的代理程式:
declarativeAgent.json,手順與知識參考會以明文方式寫在裡面)所以如果你想參考別人做得很好的代理程式,現實上還是得透過人來協助。
declarativeAgent.json如果是「多人想一起編輯同一個代理程式」,單靠 Agent Builder 做不到。宣告式代理程式不支援共同編輯,也不支援擁有權移轉。這種情況要先把代理程式複製到 Copilot Studio,再透過 Studio 端的「共同編寫(collaborative authoring)」新增編輯者。不過編輯者另外需要 Copilot Studio 授權,而且也不是以群組,而是以個人為單位加入。
如果一開始不知道這件事,常常會以為「大家一起養一個就好」,結果中途卡住。所以如果有團隊運營的需求,建議早點以 Copilot Studio 為前提設計。
在設計開發現場,資料表、規格書、量測結果的 Excel、供審查用的 PowerPoint,常常都會加上秘密度標籤(Sensitivity label)、加密、密碼保護。當你想把這些當作知識來源時,可能會發現它們沒有照預期運作。這是 Agent Builder 最容易卡住的地方之一,所以另外成章整理。
要先掌握的是:保護有兩個層次,而且必須同時滿足,代理程式才能讀到內容。
「明明有存取權,卻沒有出現在回答裡」的問題,大多都是卡在第 1 項檔案保護。以下逐一說明。
這是從自己電腦上傳並內嵌的情況。把官方文件轉成實務語言後,可以理解為:
也就是說,把機密 Excel 或 PowerPoint「先上傳內嵌再說」的作法,如果有保護機制,很高機率會失敗。後面會提到,這類檔案正確作法不是內嵌,而是透過 SharePoint 參考。
當你用 URL 或檔案選擇器指定 SharePoint / OneDrive 檔案時,代理程式會直接尊重既有的存取權限與秘密度標籤。規則如下:
這裡還有一個重要前提:如果 SharePoint 與 OneDrive 端沒有啟用「Office 檔案的秘密度標籤」,那麼 Copilot 對加密檔案可存取的範圍,會只限於在 Windows Office App 中開啟期間(data in use)。租用戶是否已在 SharePoint / OneDrive 層級啟用秘密度標籤,是管理員層級的事;如果你想穩定把加密檔案當知識來源,最好先向資訊部門確認。
如果把存取權與保護的關係整理成表,會像這樣。
檔案狀態內嵌上傳SharePoint / OneDrive 參考無保護可用有存取權即可使用有秘密度標籤(無加密)可用有存取權 + 尊重標籤後可用有秘密度標籤(有加密)不可用使用者必須具備 VIEW + EXTRACT 權限。也要先啟用 SP/OD 標籤有使用者自訂權限的標籤不可用不可用(代理程式無法讀取)密碼保護出現錯誤,無法使用因無法開啟,實際上不可用RMS 加密(無標籤)不可用預期上需要使用者具備 VIEW + EXTRACT 權限實務上的建議很簡單:如果想把受保護的 Excel / PowerPoint 當作知識來源,不要用內嵌上傳,而是放到權限設定正確、且有秘密度標籤的 SharePoint 再參考。並且確認使用者不只擁有檔案存取權,也有對標籤的 EXTRACT 權限。只要先把這兩件事搞清楚,就能少掉大量「明明有權限卻不回答」的困擾。
另外,如果整個組織的 DLP 政策有做例如「只允許 Copilot 處理某些秘密度標籤的檔案」這類控制,代理程式不讀特定檔案也可能是被租用戶側的 DLP 擋掉。遇到這種狀況時,也要把這個可能性放在心上。
把公司資料餵給 AI,本來就是一件讓人緊張的事。不過 Agent Builder 的宣告式代理程式,在結構上已經把這種風險壓低很多。
但內嵌(上傳)檔案要特別注意。官方明確指出,內嵌檔案不適用資訊屏障(Information Barriers),而且任何可存取該代理程式的人,都能看到來自內嵌檔案的回答。另外,Lockbox 與客戶自管金鑰(CMK)也不支援。
因此,高敏感資料最好不要內嵌上傳,而是透過權限控管的 SharePoint 參考來提供。這樣可以直接沿用既有的權限邊界,從結構上降低外洩風險。
最後整理一下最容易混淆的「名稱」。Microsoft 這個領域的品牌名常常更動,所以網路上的解說文章會因時期不同而叫法不一。
產品本體名稱:
m365.cloud.microsoft)。2026 年初社群一度熱議「Office 改名了」,其實只是把一年前的更名再拿出來討論,Word/Excel 等產品名與授權都沒變。Agent Builder 本身的名稱:
官方文件的 URL 與中繼資料裡,仍會殘留 copilot-studio copilot-studio-lite 之類舊稱,所以搜尋時有時會跳到舊名稱的頁面。只要記得「現在正式名稱是 Agent Builder」,就不容易被各種寫法搞混。
「公司裡只能用 Microsoft 365 Copilot」這個限制,若你知道 Agent Builder,其實沒想像中那麼綁手綁腳。整理如下:
我建議先從一個屬於自己的小型代理程式開始──不管是公司規章問答入口,還是設備手冊的初步判讀──先做一個,再用「試試看」分頁慢慢養大。免寫程式就能做到這個程度,說真的很方便。
另外,本文是根據 2026 年 6 月時點的官方文件(多數於 2026 年 4~5 月更新)整理而成。上限與名稱未來很可能還會變動,上線前請務必再確認官方最新資訊。這篇是以興趣寫的,若有不精確之處還請見諒。
原文出處:https://qiita.com/sukimaengineer/items/15ddf5601ff29ef8d376