如何用 Copilot Studio 在 Microsoft Teams 裡做一個無程式碼 IT 服務台代理

一句話結論：Microsoft Copilot Studio 讓不會寫程式的人也能做出一個直接在 Microsoft Teams 裡回答重複性 IT 問題的代理，答案來自 SharePoint 上的知識來源。它能可靠地吸收掉「VPN 怎麼連」這一層的量。它不做故障排除，而且轉真人這條路必須第一天就建好，不能事後再補。

一家 120 人公司的 IT 經理週一早上打開 Teams，看到十一則私訊。其中四則是同一個問題：在家怎麼連 VPN。兩則是新同事問報帳系統在哪。一則印表機。一則訪客 Wi-Fi 密碼。剩下三則是真正的問題。

那三則才是工作。另外八則是一筆「打斷稅」——單看每則三十秒，加起來是每天一小時的情境切換，而且全部落在公司裡唯一那個同時也能解決真正問題的人身上。

Microsoft Copilot Studio 瞄準的正是這個缺口，而它的賣點是：你不需要開發人員。這個賣點大體成立，但有一個具體而且重要的天花板。

為什麼同樣的五個 IT 問題每天都在打斷你

把過去一個月裡發給「擔任 IT 角色的那個人」的 Teams 私訊翻一遍，形狀是一致的：少數幾個問題佔了大部分的量，它們有穩定且正確的答案，而且由不同的人在無法預測的時間提出。正是這個組合讓它們變得昂貴——一季問一次的問題不值得自動化，但一個一週問四次、答案已經寫下來而且不會變的問題，值得。

文件解決不了它，原因在於「提問發生在哪裡」。有人在週二早上 8:40、在 Teams 裡、在走進會議的路上撞到了 VPN 提示框。打開內部網站、找到搜尋框、把問題組織成一個查詢，比直接給那個「我知道他會回我」的人打一行「VPN 怎麼連」要費力。所以他們就那麼做了，每一次都是——這意味著任何能解決這件事的東西，都必須在問題已經被提出的那個地方給出回答。在一家用 M365 的公司裡，那個地方就是 Teams。

Copilot Studio 到底讓你不寫程式就能做出什麼

Copilot Studio 是微軟用來建構對話式代理的低程式碼環境。你在一塊視覺化畫布上工作，用自然語言描述行為，指定它應當據以作答的內容，然後發布——可以發布到 Microsoft Teams，在那裡它就像一個員工可以對話的對象。

具體能力、連接器清單和授權模式都會隨產品演進變化。在把某條流程押在某一項具體功能上之前，先在微軟的現行文件裡確認——本文講的是這套建置的形狀，而不是一份有保存期限的功能清單。

主題、觸發詞，以及接上一個真實的知識來源

兩個機制承擔了大部分工作。

主題（Topics） 是你定義的對話流程：一組觸發語句，以及代理辨識到其中之一時該做什麼。「重設我的密碼」、「我忘記密碼了」、「帳號被鎖了」都可以走向同一段腳本化回覆，裡面放著你真實的重設連結和你真實的政策。這一部分是決定性的——答案是你寫的，所以你確切知道它會說什麼。

知識來源（Knowledge sources） 涵蓋了所有你沒有腳本化的部分。你把代理指向一批內容——一個 SharePoint 網站、上傳的文件、指定的網頁——它便根據這些材料生成答案，而不是憑一般常識作答。這才是讓這套建置變得可行的關鍵：你不必預判每個問題的每一種問法，因為你本來就在維護的那份 IT 政策頁面，直接成了答案集。

它在哪裡轉真人——以及為什麼這條路必須第一天就存在

最重要的、要先建的東西，是出口。

一個說不出「我不知道，這是一張工單」的代理一定會猜，而一個掛著公司名字的工具給出的、自信的錯誤答案，比根本沒有這個工具傷害更大。員工對出現在公司 Teams 裡的東西，信任度遠高於對網站上的聊天機器人——而這份信任只夠花一次。

先建升級路徑，再建答案。每一段對話都需要一條看得見的通往人的路——一個隨時都在的「轉真人」選項、一個在代理比對不上問題時自動移交的動作，以及一張把對話內容一起帶走的工單，好讓接手的人不必從零開始。如果你的團隊用 ServiceNow、ServiceDesk Plus、Jira 或類似系統跑服務台，移交就應該落在那裡。

一套可落地的建置流程：從一份重複問題清單到一個能用的 Teams 代理

這是一個可重現的順序，整件事是幾個下午，而不是一個專案。

1. 先數問題，別急著建東西。把過去一個月和 IT 有關的 Teams 私訊和郵件過一遍，做個計數。不要憑印象——真的去數。你要找的是被問過三次以上、且答案穩定的問題。多數公司會找出五到八個。這份清單就是你的範圍，而這次計數同時也給了你一個日後用來對照的基準。

2. 把答案寫成答案，而不是寫成政策。對每個問題，寫下你真的會回給同事的那段話。「打開公司入口 App，在 VPN 下點連線，在手機上通過 MFA 驗證」——而不是「遠端存取依照存取控制政策進行開通」。把它們放在一處，一個問題一個標題。這份文件就是你這個代理的全部品質。

3. 把那份文件放在代理讀得到、你也改得動的地方。IT 網站底下的一個 SharePoint 頁面或文件庫就很合適。要點在於：以後更新答案是編輯一個頁面，而不是重新打開建置工具——這正是讓代理不會在六週後就過期的原因。

4. 建立代理並把它指向那個來源。在 Copilot Studio 裡新建一個代理，用自然語言給它寫清楚角色——它為員工回答內部 IT 問題，依據是經過審核的 IT 知識來源，不確定時移交給人——然後把你的 SharePoint 位置加為知識來源。確認它是以什麼身分去驗證這個來源的，因為這決定了它讀取內容時適用的是誰的權限。

5. 把量最大的那兩三個問題寫成明確的主題。VPN 那個、密碼那個，以及你清單最上面的那個。這些答案你希望每次都逐字正確，包括那個確切的連結。其餘的交給知識來源。

6. 建好升級主題。一個「轉真人」觸發詞、一個針對未比對到問題的兜底動作，以及一條通往你工單系統、並且帶上對話紀錄的路徑。

7. 用真實的問題去測，而且要用人們真實的問法。不是「我該如何建立 VPN 連線？」，而是「vpn連不上」、「vpn進不去」、「在家vpn??」。如果代理只處理措辭工整的問題，它一接觸現實就會失敗。

8. 先發布給一個小規模試行群組——五到十人，最好包含一位習慣性提問者。跑兩週，把每一段對話都讀一遍，而不是讀彙總指標。你會在這裡發現兩個你原本不知道很常見的問題，以及一個悄悄錯了的答案。

9. 然後再推開，並且保持每月讀一次對話紀錄。未比對到的問題就是「接下來該補什麼」的佇列，而一個沒人檢視的代理，是一個正在慢慢過期的代理。

自建 Copilot Studio 代理 vs 有專人值守的服務台 vs 開發人員做的機器人

• 自建 Copilot Studio 代理。起步成本最低、不需要開發人員，而且它原生活在 Teams 裡——問題本來就在那兒被問出來。對已知的、有文件的、穩定的問題處理得不錯。它的邊界是真實的：它不做故障排除，除了你明確接上的東西之外無法操作你的系統，而且它的品質上限就是它背後那份文件的品質。最適合有人願意負責的公司裡的一線資訊型問題量。
• 有專人值守的服務台。回答代理答不了的那些——需要診斷、需要判斷、需要更動帳號，或者需要判定某件事是不是資安事件的那些。它不需要你寫任何東西就能擴充，涵蓋你涵蓋不了的時段，而且對「解決」而不只是「回答」負責。代價是一份合約，以及按人或按工單計的費率。當你真正需要卸掉的是排障量時，它才是對的選擇。
• 開發人員基於模型 API 做的機器人。彈性最大——任意整合、自訂邏輯、你能描述出來的任何行為。同時歸屬成本也最大：得有人去做、去託管、去做資安、去維護，而且明年還得在。當需求確實塞不進任何現成平台時，它才是對的。我們在用 Claude 在 Slack 裡做一個 IT 服務台機器人那篇裡詳細寫過這條路線。

對多數以 M365 為底座的中小企業，誠實的答案是第一種加第二種：代理吸收掉重複的資訊型問題量——佔了工單則數的大部分，卻幾乎不佔難度——有專人值守的服務台處理剩下的，而那部分本來就是真正的工作。

一個無程式碼代理會在哪裡走到盡頭

它回答，但不診斷。「我電腦很慢」沒有一個已寫好的答案——要得到答案，需要一來一回，中間帶著判斷。代理會產出泛泛的建議，先浪費使用者的時間，然後浪費你的。

除非你把它接上去，否則它改不了任何東西，而「接上去」正是風險所在。讀一個政策頁面是低風險的。重設密碼、把人加進某個群組、解鎖帳號，都是特權操作，把這些接進一個對話式代理是一個資安設計決策，而不是一個無程式碼動作。「不需要開發人員」這個說法，恰恰是在這裡不再夠用。

它沒有輕重緩急的概念。一個使用者回報說「有個我不認識的檔案要我啟用巨集」，需要的是立刻有人介入，而不是一條知識庫答案。代理分不清「不方便」和「事故」。你的升級邏輯必須分得清，否則一次真正的資安事件收到的會是一個聊天機器人的回覆。

它的知識精確地等於你那份文件的水準，而文件會腐壞。三月份還對的 VPN 答案，在九月用戶端更新之後就錯了。無論對錯，代理都會一樣自信地繼續回答。這份文件的歸屬權，才是運行這套東西真正的持續成本。

把它做對：資料來源權限、授權，以及什麼時候該讓 IT 介入

知識來源上的權限是所有事情裡最該先弄對的一件。代理以什麼身分驗證到 SharePoint，決定了它是遵循提問者本人的存取權限，還是以更寬的權限去讀。請用一個低權限帳號明確驗證，而不要靠假設。同時也要意識到旁邊那個問題：如果你的 SharePoint 權限本來就鬆，一個能檢索它的代理會讓既有的過度共用變得極易被撞見——那是一個先該修的既有毛病，我們在為 Copilot 上線做 Microsoft 365 租用戶準備裡寫過。

在規劃推廣之前查授權，而不是在試行之後。Copilot Studio 的授權與容量模式和你的 Microsoft 365 授權席次是分開的，而且已經改過不止一次。在決定全公司上線之前，先確認現行模式，並算清你預期的訊息量實際要花多少錢——這是試行卡住最常見的原因。

套用你的 Power Platform 治理。資料外洩防護政策、環境規劃，以及誰被允許在你的租用戶裡建立和發布代理。沒有這一層，「不需要開發人員」就會變成好幾個由不同部門做出來、各自指向不同文件、給出不同答案的失管代理。

在建之前先定下誰來負責。一個沒有主人的代理，是一份介面友善的負債。

選路線、設計升級邏輯、審查一個代理被允許碰什麼，這些是 AI+ 支援的工作——就緒度評估比建置本身更要緊。底下的租用戶衛生、SharePoint 權限和日常維護，是一般的託管 IT 支援。而當代理移交時，它需要一個真實的去處：我們的 24×7 多語言服務台是一支基於 ITIL 的團隊，接下代理關不掉的工單，支援英語、普通話和粵語，並與 ServiceNow、ServiceDesk Plus 或 Jira 整合。

常見問題

我真的不需要開發人員來做這個嗎？

就本文描述的這種建置而言——一個從 SharePoint 來源回答有文件問題、發布到 Teams、帶移交的代理——確實不需要。變化發生在你希望代理去*執行動作*的時候：重設密碼、修改群組成員、建立帳號。那些需要連接器、需要權限設計、需要資安審查，到那一步你就需要一個專業做這件事的人，無論中間涉及多少程式碼。

Copilot Studio 需要什麼 Microsoft 365 授權？

Copilot Studio 的授權與標準 Microsoft 365 授權席次是分開的，而且其模式——容量、訊息包，或者與其他 Copilot 授權綁售——已經被修訂過不止一次。請查看微軟現行的授權頁面，並在推廣之前而不是試行之後為你預期的訊息量算好價，因為成本是隨用量而不是隨人數增長的。

代理會不會看到某個使用者本不該存取的檔案？

這完全取決於你如何設定了到知識來源的驗證方式，這也正是它該被最先驗證的原因。用一個刻意設定的低權限帳號去測，確認代理不會呈現這個帳號自己打不開的東西。另外，如果你的 SharePoint 權限本來就過寬，這一刻正是它變得可見的時候——去修權限，而不是指望代理嘴緊。

我們怎麼知道它什麼時候在給錯答案？

靠讀對話紀錄，尤其是第一個月。指標告訴你的是量和自助解決率；它們不會告訴你 VPN 那個答案自從用戶端更新之後就一直是錯的。設一個月度檢視，讓某個人讀一批對話樣本和全部未比對到的問題。同時給員工一個在對話裡就能說「這個是錯的」的明顯途徑，並把這些回報當作你能拿到的最高價值訊號。

這和用 Claude 或 ChatGPT 在 Slack 裡做 IT 機器人有什麼不同？

工具不同、平台不同、做它的人也不同。開發人員基於模型 API 做的機器人更有彈性，但需要一個開發人員去做並讓它一直活著。Teams 裡的 Copilot Studio 是一塊 IT 經理不寫程式就能用的畫布，代價是只能在平台支援的範圍內工作——而且如果你本來就是一家 M365 公司，員工不用安裝任何東西、也不用學任何東西就會用。