前言

公司電腦上只能使用 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)」分頁反覆調整,穩定後再分享。


1. 什麼是「宣告式代理程式」

Agent Builder 建立的東西稱為宣告式代理程式(declarative agent)。這個詞不太直觀,所以先拆開來說明。

「宣告式」的意思是,不是自己準備 AI 的核心(模型或推理引擎),而是只要「宣告」它的行為就能完成客製化。具體來說,要宣告以下 3 件事:

  • 手順(Instructions):這個代理程式是什麼、應該怎麼行動
  • 知識(Knowledge):要參考哪些資料來回答(SharePoint、檔案、Web 等)
  • 動作(Actions):可以執行什麼(※Agent Builder 不能建立,後述)

重點在於,底層 AI 與 Microsoft 365 Copilot 本體完全相同。協調器、基礎模型、可信任的 AI 服務──這些都直接借用 Copilot 本體。因此不需要自架主機,也不需要額外基礎設施。最接近的想像方式,就是「把既有 Copilot 換上一套專屬人格、知識與規則」。

因為這樣設計,宣告式代理程式會直接繼承 Microsoft 365 的安全性與合規性。後面會提到,這對處理公司內部資料是非常大的優勢。

2. Agent Builder 與完整版 Copilot Studio 的差異

這裡是第一個關卡。Microsoft 的世界裡有好幾種「建立代理程式」的方法,名稱也很像,所以容易混淆。先把本文的範圍講清楚。

Agent Builder(本文對象)Copilot Studio(完整版)啟動位置Microsoft 365 Copilot App 內獨立的 Web App難易度無程式碼低程式碼外部 API 動作不可可多通道部署只在 Copilot 內Teams / Web / 各種通道環境隔離・ALM・DLP簡易完整Dataverse 消耗不消耗預期用途快速、簡單的公司內部代理程式複雜工作流程、核心系統整合官方文件把 Agent Builder 定義為「適合快速且簡單專案的即時對話式 AI 開發體驗」。而且明確寫著:如果需要整合外部服務等進階功能,就應該使用 Copilot Studio。

換句話說,判斷標準很簡單:

  • 只要能「參考」內部文件或 Web 來回答 → Agent Builder
  • 需要對外部系統「寫入」或「執行」→ Copilot Studio

如果是在公司裡只能碰 Copilot 的情況,多數情境先用 Agent Builder 就夠了。之後若想正式擴充,也可以透過後面會提到的「複製到 Copilot Studio」移轉。

3. 前提條件──你的授權能做什麼

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 加入知識來源時,遇到「沒有選項可選」或「加入就報錯」,通常原因是以下幾種。

症狀懷疑原因根本沒有 SharePoint 可加的手段沒有 Copilot 加購+沒有用量計費(也就是上表右欄那種狀態)可以加,但使用者端沒反應使用者不符合所需授權/用量計費特定檔案讀不到檔案保護(加密、密碼、使用者自訂權限。見第 10 章)整個 SharePoint 都不能用租用戶啟用了 Restricted SharePoint Search(在此設定下無法把 SharePoint 當作知識來源)如果公司已正式指派 Microsoft 365 Copilot(加購授權),那麼 SharePoint、檔案、郵件與 Teams 都能作為知識來源,屬於完整功能。反過來說,如果卡在上面那些問題,最可靠的做法是向資訊部門確認自己的授權類型,以及租用戶是否啟用了用量計費。同時也要注意,管理員可能在 Microsoft 365 管理中心控制了 Agent Builder 的可用性或分享範圍,所以如果「選單沒出現」或「不能分享」,也要懷疑是租用戶政策。

4. 建立步驟──從啟動到完成

接下來進入實作。以下依照最新 UI(2026 年 6 月時點)說明。

4.1. 啟動 Agent Builder

  1. 開啟 Microsoft 365 Copilot App(m365.cloud.microsoft,或 Teams / 桌面版 Copilot)
  2. 從左側導覽列的「代理程式」選擇「新增代理程式(New agent)」(官方文件或畫面上有時也會顯示為「建立代理程式(Create agent)」)
  3. 選擇建立方式

建立方式有 3 種:

  • 用自然語言描述(「描述(Describe)」分頁,推薦):直接用聊天描述想做什麼,系統會自動產生名稱、描述、手順、知識來源與啟動提示。想快速做出草稿,這個最快。
  • 手動設定(「設定(Configure)」分頁):選擇「跳過到設定(Skip to configure)」後逐項填寫。適合需要細部控制時。
  • 從範本開始:例如 Prompt Coach、Writing Coach、Learning Coach 等預先設定的範本。開啟範本後切到「設定」分頁,可以看到 Microsoft 建議的「手順寫法」範例。這其實很值得一看,建議一開始至少看過一次。

4.2. 設定基本項目

在「設定(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 為主要操作方式,請把這點記在心上。

5. 新增知識(Knowledge)──最新上限值

代理程式聰不聰明,幾乎取決於你讓它參考什麼。以下整理 2026 年 6 月時可指定的知識來源與上限。這些數字在過去一年常常被調高,所以本文可視為「2026 年 6 月的快照」。

  • 公開 Web 網站:最多 4 個 URL。URL 最多到 2 層(像 https://example.org/a/b/c 這種 3 層的不行),不能帶查詢參數。也可以透過「搜尋所有網站(Search all websites)」切換成全 Web 搜尋。
  • SharePoint:最多 100 個檔案(2025 年 7 月從 20 提升到 100)。可指定網站 / 資料夾 / 檔案 URL,或用檔案選擇器。會直接尊重既有權限與秘密度標籤。
  • OneDrive:最多 50 個檔案(2026 年 5 月正式加入 Agent Builder)。
  • 上傳(內嵌)檔案:最多 20 個。.doc/.docx/.pdf/.ppt/.pptx/.txt 每個檔案 512MB,.xls/.xlsx 為 30MB。不能以資料夾單位上傳。
  • Teams 聊天:最多可範圍指定 5 個特定聊天。透過 My Teams chats and meetings 可涵蓋所有聊天與會議(※需 Copilot 加購授權)。
  • Outlook 郵件:透過 My emails 可涵蓋整個收件匣(※需 Copilot 授權,且不可做範圍指定)。
  • People 資料:組織內的人員資訊。擁有 Copilot 授權者預設為開啟。
  • Copilot 連接器:管理員啟用的連接器(Jira / ServiceNow / Confluence / GitHub / Azure DevOps 等)。也可以指定屬性範圍。

設定上很重要的是「Only use specified sources(僅使用指定來源)」切換。如果把它開啟,系統在需要搜尋的問題上會只使用指定來源。不過要注意,即使開了,也不能完全阻止一般 AI 知識介入。若你希望「只能根據公司文件回答」,這種嚴格控制是完整版本 Copilot Studio 的領域。

實務技巧(SharePoint 集中與 Excel)

像我這種情境,最有效的方法是把公司內部的規格書、資料表、操作手冊集中到 SharePoint 的單一網站(或文件庫),再把那個網站/資料夾 URL 指定為知識來源。這樣就不必逐一列出 20 個檔案,也能自動跟著檔案增減更新(索引會有幾分鐘延遲)。

如果要用 Excel 提供量測資料,建議把資料集中在同一個活頁簿裡的一個工作表,回答準確度會更好(.xlsx 上限 30MB)。如果散在多個工作表,代理程式常常會不確定該看哪裡。

6. 手順(Instructions)的寫法──這裡才是核心

手順最多可寫 8,000 字元,但真正重要的是結構,而不是字數。以下把官方「如何撰寫有效手順」指南的重點,轉成實務觀點來說明。

  • 用 Markdown 做結構化:用 #/## 當標題,順序重要就用編號清單,並列任務用項目符號,工具名稱用 backtick,重點用粗體。代理程式會讀結構。
  • 用具體動詞寫「該做什麼」:比起一直寫「不要做什麼」,用 search/check/summarize 這類動詞描述行為更有效。
  • 把任務切成原子步驟:不要寫成「抽出指標並摘要」,而是拆成「1. 抽出指標 → 2. 摘要觀察結果」。
  • 務必指定語氣、冗長度、輸出格式:例如「語氣:專業且簡潔」「輸出:每個段落 3 個條列」。不指定的話,每次都會有差異。
  • 加入自我檢查步驟:像是「最終化前先確認是否已包含所有必要項目」這一句,就能穩定品質。

以下是一個手順骨架範例(以公司內部的初步判讀代理程式為例,節錄)。

# 目的
協助使用者初步判讀公司內部設備異常。

# 回應規則
- 只有在資訊不明確時,才一次問一個確認問題。
- 資訊以精簡條列或表格呈現。
- 進入下一步前,務必先確認。

# 步驟
## Step 1: 了解狀況
- 目的:確認問題。
- 行動:若說明模糊,只問 1 個聚焦的問題。
- 轉移:若已明確,進入 Step 2。

## Step 2: 對照已知現象
- 目的:排除已知故障。
- 行動:參考 SharePoint 的障礙紀錄。
- 轉移:若無對應項目,進入 Step 3。

# 輸出格式
- 步驟與清單採條列,結構化資料使用表格。
- 避免長段落,方便快速掃讀。

注意模型更新後,行為可能改變

另外有件不起眼但很重要的事。宣告式代理程式的基礎模型,在 2025 年底到 2026 年間,已從 GPT-5.1 更新到 GPT-5.2。過程中,手順的解讀方式也從「逐字照寫」變成「優先理解意圖、具備適應性」。

這會造成什麼問題?原本照你預期運作的手順,在模型更新後可能會被重排,甚至自行補進推論。越重要的代理程式,越應該在官方公告模型更新時重新測試。若行為開始漂移,有時在手順開頭加上一句「一律逐字解讀指示,不要自行添加推論」(穩定化標頭),就能暫時穩住。

另外,為了規避 8,000 字元限制而把手順藏到 SharePoint 等知識來源裡,這種做法要避免。知識來源會受到注入攻擊分類器的處理,不保證一定會被當作指令,還會擴大攻擊面。手順就放在手順欄,知識就放在知識欄。不要混用角色,這是鐵則。

7. Actions 的部分──誠實說明不能做什麼

先講在前面,免得期待落空。Agent Builder 不能建立呼叫外部 API 的 Actions。像是建立票單、寫入核心系統,這類「執行型」功能都不在這個工具的範圍內。

把外部系統作為知識來源來整合(以讀取為主)可以透過 Copilot 連接器做到。但再往上──API 外掛、MCP 伺服器整合、REST API、訊息延伸功能、互動式 UI 小工具(MCP Apps)──就屬於 Microsoft 365 Agents Toolkit(VS Code)或完整版本 Copilot Studio 的範圍了。

如果不先劃清這條線,很容易高估「Agent Builder 什麼都能做」,最後卡住。以讀取為主就用 Agent Builder,需要寫入或執行就直接認定要用完整版本,這樣最健康。

8. 測試・分享・組織部署

8.1. 測試(「試試看」分頁)

名稱、說明、手順填完後,「試試看(Try it)」分頁會啟用,你可以像正式版一樣對正在建立的代理程式進行對話測試。邊調整設定、邊用同樣問題反覆測試回答變化──品質就是這樣磨出來的。

我的實務建議是先準備 5~10 個代表性問題,在它們都穩定答對之前,不要分享給任何人。把相同問題在加了知識前後各試一次,就能清楚知道新增知識有沒有發揮效果。

8.2. 分享

按下「Create(建立)」後,預設只會建立成自己可見(private)。接著再透過「Share(分享)」擴大範圍。

  • 特定使用者 / 群組:可指定個人、保全群組、Microsoft 365 群組、Teams
  • 組織內所有人:整個租用戶的人都能透過連結使用
  • 僅自己:預設值

這裡最重要的是權限處理。如果知識來源使用了 SharePoint,分享對象若沒有該內容的存取權,回答中就不會包含那些內容。代理程式不會額外賦予新權限(No new privileges 原則)。這在安全上非常理想,能從結構上防止「沒有權限的人看到機密」的事故。

8.3. 組織目錄(Built by your org)的正式公開

如果要作為全公司正式工具發佈,就要走組織目錄申請流程。選擇目標代理程式,從 Edit 進入「提交到組織目錄(submit to org catalog)」。管理員會在 Microsoft 365 管理中心審核,通過後就會出現在 Agent Store 的「Built by your org」。

9. 能否參考別人做的代理程式內容

這是在公司裡代理程式變多後一定會出現的問題。「想看同事做得很好的代理程式手順來學」、「想模仿運作順利的版本」──結論是,作為一般使用者,無法看到別人代理程式的內部內容(手順與知識結構)。

9.1. 使用者只能看到「表面」

對於被分享的代理程式,非建立者的一般使用者只能看到以下這些「表面」資訊:

  • 代理程式名稱、說明、建立者名稱
  • 啟動提示(會話開場範例)
  • 詢問「這個代理程式能做什麼?」時顯示的摘要

反過來看不到的是「內部」,也就是手順(Instructions)、知識來源的具體組成(參考了哪些 SharePoint 網站或檔案)、以及功能細節設定。這些都放在建立者專用的「設定(Configure)」分頁裡,使用者看不到。

更進一步,從別人分享來的代理程式不會出現在自己的「我的代理程式(My agents)」清單裡。清單裡只會有自己建立的項目。也就是說,不只不能編輯,連查看設定的入口都不存在。Microsoft 也明確寫了:被分享的代理程式,接收者不能編輯,編輯權仍屬於擁有者。

9.2. 誰能看到什麼

角色使用(聊天)表面資訊手順・知識結構一般使用者(分享對象)可可不可建立者(擁有者)可可可(「設定」分頁)管理員(AI 管理員 / 全域管理員)──可可查看(管理中心,唯讀)只有管理員比較特別:可以從 Microsoft 365 管理中心的 Agent Registry,以唯讀方式查看整個組織中所有代理程式的手順與知識結構(Data & tools 分頁)。一般使用者與管理員能看到的範圍差很多,這點要特別注意。

9.3. 沒有「複製」功能──想參考就得透過人

官方並沒有提供把別人的代理程式「複製(Make a copy / Duplicate)」出來的功能。網路上有些文章寫可以用 Make a copy 複製,但 Microsoft Learn / Microsoft 支援中心的官方文件並沒有這種說法。官方有提供的複製類操作只有兩種,而且都只限自己擁有的代理程式:

  • Copy to Copilot Studio:把自己的代理程式移到完整版本 Copilot Studio
  • Download .zip file:把自己的代理程式以 .zip 匯出(裡面有 declarativeAgent.json,手順與知識參考會以明文方式寫在裡面)

所以如果你想參考別人做得很好的代理程式,現實上還是得透過人來協助。

  1. 直接請建立者分享手順或設定(最快)
  2. 請建立者下載 .zip,讓你看 declarativeAgent.json
  3. 請管理員透過 Agent Registry 協助查看

9.4. 如果想和團隊一起養成

如果是「多人想一起編輯同一個代理程式」,單靠 Agent Builder 做不到。宣告式代理程式不支援共同編輯,也不支援擁有權移轉。這種情況要先把代理程式複製到 Copilot Studio,再透過 Studio 端的「共同編寫(collaborative authoring)」新增編輯者。不過編輯者另外需要 Copilot Studio 授權,而且也不是以群組,而是以個人為單位加入。

如果一開始不知道這件事,常常會以為「大家一起養一個就好」,結果中途卡住。所以如果有團隊運營的需求,建議早點以 Copilot Studio 為前提設計。

10. 受保護檔案與存取權限的關係──這裡最容易卡住

在設計開發現場,資料表、規格書、量測結果的 Excel、供審查用的 PowerPoint,常常都會加上秘密度標籤(Sensitivity label)、加密、密碼保護。當你想把這些當作知識來源時,可能會發現它們沒有照預期運作。這是 Agent Builder 最容易卡住的地方之一,所以另外成章整理。

要先掌握的是:保護有兩個層次,而且必須同時滿足,代理程式才能讀到內容。

  1. 檔案本身的保護(秘密度標籤・加密・密碼・IRM)
  2. SharePoint / OneDrive 的存取權限(誰能存取該檔案)

「明明有存取權,卻沒有出現在回答裡」的問題,大多都是卡在第 1 項檔案保護。以下逐一說明。

10.1. 上傳(內嵌)檔案時

這是從自己電腦上傳並內嵌的情況。把官方文件轉成實務語言後,可以理解為:

  • 在啟用了加密的租用戶中,帶有秘密度標籤的 Office 檔案不能作為知識來源。
  • 有密碼保護的檔案可以上傳,但檔案旁邊會出現錯誤,無法使用。
  • 如果內嵌檔案有秘密度標籤,只有對該標籤具有擷取(EXTRACT)權限的使用者才能使用代理程式。沒有 EXTRACT 權限的人可以看到代理程式和說明,但無法安裝或使用。
  • 代理程式的回應也會自動帶上其所參考內容中最高優先級的秘密度標籤。

也就是說,把機密 Excel 或 PowerPoint「先上傳內嵌再說」的作法,如果有保護機制,很高機率會失敗。後面會提到,這類檔案正確作法不是內嵌,而是透過 SharePoint 參考。

10.2. 參考 SharePoint / OneDrive 時

當你用 URL 或檔案選擇器指定 SharePoint / OneDrive 檔案時,代理程式會直接尊重既有的存取權限與秘密度標籤。規則如下:

  • 如果代理程式使用者沒有該 SharePoint / OneDrive 檔案的存取權,內容就不會出現在回答中。代理程式不會給你任何新的權限(No new privileges)。
  • 要讓 Copilot 或代理程式讀取帶有加密秘密度標籤的檔案,使用者必須同時具備該標籤的檢視(VIEW)與擷取(EXTRACT)權限。只有 VIEW 不夠,無法摘要內容。
  • 帶有使用者自訂權限(user-defined permissions)的秘密度標籤檔案,Copilot 代理程式無法讀取。這是結構上不支援,不管權限有沒有給都一樣。
  • 即使沒有秘密度標籤,但如果檔案是透過 Azure Rights Management(RMS)加密,仍然需要 VIEW / EXTRACT 權限。

這裡還有一個重要前提:如果 SharePoint 與 OneDrive 端沒有啟用「Office 檔案的秘密度標籤」,那麼 Copilot 對加密檔案可存取的範圍,會只限於在 Windows Office App 中開啟期間(data in use)。租用戶是否已在 SharePoint / OneDrive 層級啟用秘密度標籤,是管理員層級的事;如果你想穩定把加密檔案當知識來源,最好先向資訊部門確認。

10.3. 把兩層合在一起看

如果把存取權與保護的關係整理成表,會像這樣。

檔案狀態內嵌上傳SharePoint / OneDrive 參考無保護可用有存取權即可使用有秘密度標籤(無加密)可用有存取權 + 尊重標籤後可用有秘密度標籤(有加密)不可用使用者必須具備 VIEW + EXTRACT 權限。也要先啟用 SP/OD 標籤有使用者自訂權限的標籤不可用不可用(代理程式無法讀取)密碼保護出現錯誤,無法使用因無法開啟,實際上不可用RMS 加密(無標籤)不可用預期上需要使用者具備 VIEW + EXTRACT 權限實務上的建議很簡單:如果想把受保護的 Excel / PowerPoint 當作知識來源,不要用內嵌上傳,而是放到權限設定正確、且有秘密度標籤的 SharePoint 再參考。並且確認使用者不只擁有檔案存取權,也有對標籤的 EXTRACT 權限。只要先把這兩件事搞清楚,就能少掉大量「明明有權限卻不回答」的困擾。

另外,如果整個組織的 DLP 政策有做例如「只允許 Copilot 處理某些秘密度標籤的檔案」這類控制,代理程式不讀特定檔案也可能是被租用戶側的 DLP 擋掉。遇到這種狀況時,也要把這個可能性放在心上。

11. 安全性與治理──處理內部資料的安心因素

把公司資料餵給 AI,本來就是一件讓人緊張的事。不過 Agent Builder 的宣告式代理程式,在結構上已經把這種風險壓低很多。

  • 繼承 Microsoft 365 的資料保護:尊重既有權限與秘密度標籤,不會新增權限。
  • 不會用於模型訓練:透過企業資料保護,提示與公司內部內容不會被拿去訓練基礎模型。
  • 管理員可集中管理:在管理中心的 Copilot > Agents 可列管、啟用/停用、封鎖代理程式;也能透過 Agent Registry 監控所有代理程式。

但內嵌(上傳)檔案要特別注意。官方明確指出,內嵌檔案不適用資訊屏障(Information Barriers),而且任何可存取該代理程式的人,都能看到來自內嵌檔案的回答。另外,Lockbox 與客戶自管金鑰(CMK)也不支援。

因此,高敏感資料最好不要內嵌上傳,而是透過權限控管的 SharePoint 參考來提供。這樣可以直接沿用既有的權限邊界,從結構上降低外洩風險。

12. 名稱有點亂的問題──術語整理

最後整理一下最容易混淆的「名稱」。Microsoft 這個領域的品牌名常常更動,所以網路上的解說文章會因時期不同而叫法不一。

產品本體名稱:

  • 以前的「Microsoft 365 Chat」→ 內部名稱「BizChat(Business Chat,現在仍會出現在網路呼叫中)」→ 現在依授權有無分成「Microsoft 365 Copilot(Work)」或「Microsoft 365 Copilot Chat」
  • 2025 年 1 月,舊的「Microsoft 365(Office)App」更名為「Microsoft 365 Copilot App」(URL 也變成 m365.cloud.microsoft)。2026 年初社群一度熱議「Office 改名了」,其實只是把一年前的更名再拿出來討論,Word/Excel 等產品名與授權都沒變。

Agent Builder 本身的名稱:

  • 2024 年 10 月以「Copilot Studio agent builder」之名登場
  • 某些文件會寫成「Copilot Studio lite」
  • 現在的正式名稱是「Agent Builder in Microsoft 365 Copilot」

官方文件的 URL 與中繼資料裡,仍會殘留 copilot-studio copilot-studio-lite 之類舊稱,所以搜尋時有時會跳到舊名稱的頁面。只要記得「現在正式名稱是 Agent Builder」,就不容易被各種寫法搞混。

總結

「公司裡只能用 Microsoft 365 Copilot」這個限制,若你知道 Agent Builder,其實沒想像中那麼綁手綁腳。整理如下:

  • Agent Builder 是在 Copilot App 內,以無程式碼、無額外費用建立宣告式代理程式的功能。
  • 它擅長的是參考公司內部資料與 Web 回答;呼叫外部 API 的 Actions 則是完整版本 Copilot Studio 的領域。
  • 知識來源重質不重量。把公司文件集中在 SharePoint 的單一網站,然後用 URL 指定,實務上最省事。
  • 手順要用 Markdown 結構化,明確寫出語氣、輸出格式與自我檢查步驟。因為模型更新可能改變行為,重要代理程式在更新後要重新測試。
  • 別人分享的代理程式內容,使用者看不到手順與知識結構。要參考就得透過建立者或管理員;若要團隊共同養成,則應改用 Copilot Studio。
  • 安全性會繼承既有權限與秘密度標籤,所以用 SharePoint 參考來提供,結構上是安全的。只有內嵌檔案不支援資訊屏障這點要留意。
  • 受保護的 Excel / PowerPoint(秘密度標籤、加密、密碼)在內嵌時很容易被擋。最好放到 SharePoint 再參考,並確認使用者既有存取權與 EXTRACT 權限都到位。
  • 如果之後想正式擴充,可以「複製到 Copilot Studio」移轉,但郵件、上傳檔案、Teams 聊天不會自動繼承,需要重新設定。

我建議先從一個屬於自己的小型代理程式開始──不管是公司規章問答入口,還是設備手冊的初步判讀──先做一個,再用「試試看」分頁慢慢養大。免寫程式就能做到這個程度,說真的很方便。

另外,本文是根據 2026 年 6 月時點的官方文件(多數於 2026 年 4~5 月更新)整理而成。上限與名稱未來很可能還會變動,上線前請務必再確認官方最新資訊。這篇是以興趣寫的,若有不精確之處還請見諒。

參考連結


原文出處:https://qiita.com/sukimaengineer/items/15ddf5601ff29ef8d376


精選技術文章翻譯,幫助開發者持續吸收新知。

共有 0 則留言


精選技術文章翻譯,幫助開發者持續吸收新知。
🏆 本月排行榜
🥇
站長阿川
354
🥈
我愛JS
💬1  
3
評分標準:發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次
📢 贊助商廣告 · 我要刊登