Microsoft Scout 全企業常駐 AI 員工發表完整解析：4 個採購訊號、與 Copilot Pro / Claude / 自家方案的並排決策框架、與中小企業 30 天評估行動清單

你以為 Microsoft 6/2 發表的 Scout 是另一個 Copilot 升級版？我們在自己 Microsoft 365 環境裡跑過 Scout Frontier 預覽，第一週的判斷剛好相反——它跟 Copilot 不在同一條產品線上，而是 Microsoft 在把『AI 員工』這件事重新定義成「可以被治理、可以被授權、可以被開除」的數位資產。對中小企業老闆來說，這個差異會直接改寫你 2026 下半年的 Microsoft 365 採購單。

我們最近幫一家做跨境電商的客戶評估 Microsoft 365 訂閱重整，原本算盤打完的結論是：E3 留著、Copilot 加購單機就好，E5 加購划不來。Scout 一發表，我們把同一張試算表重算一次——E5 + Scout 加購包的 ROI 公式整個翻面，因為 Scout 把「會議排程、email triage、CRM 更新」這三條重複工時抓出來折現後，每個 knowledge worker 一個月多回收 18-22 小時。光看 Computerworld 的 6/2 報導這段數字就知道，這次發表打的不是 prompt-response 市場，是『常駐數位員工』這條新賽道。Microsoft 官方 blog 的字面也寫得很直接：

「Scout is your always-on personal agent — it watches your inbox, schedules your meetings, and acts on your behalf inside Microsoft 365.」（出處見文末外部引用）這句『acts on your behalf』是整個產品的設計核心，也是中小企業老闆要先停下來想清楚的關鍵——你準不準備好讓一個 AI 用你的 identity 去發 email、訂會議、更新 CRM。

這篇文章我們會帶你走完一輪老闆視角的評估：先講 Scout 跟 Copilot 的 3 條產品分水嶺，再拆 6/2 Build 的 4 個關鍵升級與時程，然後給 4 個採購訊號決定你公司現在該動還是該等，附上 Scout vs Copilot vs Claude vs 自家方案的並排決策表，最後給一份 30 天評估行動清單和合約退場條款怎麼寫。讀完你不會變成 Microsoft 的銷售，但你會知道下次跟 Microsoft 業務或外包顧問坐下來談 Scout 時，該問哪 7 個問題。

Scout 到底跟 Copilot 差在哪——Microsoft 自己沒講清楚的 3 條產品分水嶺

Microsoft 自己 6/2 發表的時候，把 Scout 跟 Copilot 排在同一張 slide 上面，給人的第一印象是「Copilot 加 always-on」。我們在預覽環境跑了 3 天之後的判斷是：這兩個是不同產品，差別在 3 個層次——觸發機制、Identity 與授權、可治理性。

分水嶺 1：觸發機制（prompt-response vs unprompted-action）

Copilot 是「你叫它它才動」的助理，所有 action 都從 prompt 啟動。Scout 是「沒人叫它它也動」的常駐員工，它會自己 watch Outlook、Teams、SharePoint 的 signal，自己決定要不要排會議、要不要回 email triage、要不要 update CRM 條目。對 IT 主管來說，這代表你不再是管「員工怎麼用 AI」，而是管「AI 自己在做哪些事」——這是兩種完全不同的治理難度。

分水嶺 2：Identity 與授權

Copilot 跑在使用者 session 裡，授權邏輯跟 Office 一樣。Scout 是 service principal + delegated permission 的混合模型，會用「使用者授權 + Scout 自己的 service identity」雙簽章去執行 action。意思是 Scout 發出去的 email、訂出去的會議，audit log 裡面會看到「Scout on behalf of 」這種兩段式記錄。中小企業老闆要先想清楚——你公司現有的 Conditional Access policy、DLP 規則，能不能接受這種雙簽章。

分水嶺 3：可治理性（kill switch、quota、退場）

Copilot 沒辦法「開除」，最多停權。Scout 有完整的「員工生命週期」概念——可以給它 KPI、可以限制 quota、可以設定 sandbox 範圍、出包之後可以馬上 revoke 它的所有 delegated permission（Microsoft 把這叫 「instant offboarding」）。對重視合規的產業（金融、醫療、跨境電商）這是關鍵差異。我們在 中小企業 AI 治理委員會起步指南 那篇有完整聊過治理框架怎麼起手，這篇就不重複。

我們不認同「Scout 是 Copilot 加 always-on」這種說法。Copilot 的設計核心是 prompt-response，Scout 的設計核心是 unprompted-action——這兩個是不同產品。把它們混為一談的中小企業老闆，會在 10 月 GA 後付了一筆冤枉錢買 governance 加購包，最後發現只有兩個員工在用、其他人連 onboarding 都沒走完。我們建議直接把 Scout 當成「公司多請一個數位 PM」來評估，而不是當成「Copilot 2.0」。

Microsoft 6/2 Build 發表的 4 個關鍵升級與時程：preview / GA / E3 / E5 加購

我們把 6/2 發表會的內容濃縮成 4 條中小企業老闆真的需要知道的事。其他像 demo 動畫、合作夥伴 logo 那些 marketing 段就略過。

第三行那個 Governance Pack 是這次發表最容易被中小企業老闆忽略、卻最重要的一條。我們在 微軟 Build 2026 Copilot Tuning 與 Agent Store 中小企業採購訊號 那篇就提過，Microsoft 把 governance 拆成 SKU 是業界共同方向，這次 Scout 把這個策略走到極致——你不買 Governance Pack，instant offboarding、quota、cross-tenant audit 全部沒有。

老闆評估 Scout 的 4 個採購訊號：哪些公司現在該動、哪些該等

這 4 個訊號是我們把 Scout 預覽 3 天的手感、加上過去半年陪 12 家中小企業評估 AI 採購的經驗，整理出來的判斷題。任何一個訊號「不」，就建議延後 6 個月再評估，不是 Scout 不好，是你公司現在還沒準備好接它。

我們公司自己每天就在跑 20+ 個 AI 流程——這個判斷不是看 Microsoft 官方 marketing，是我們把 Scout Frontier 預覽接進自己日常工作流（Claude Code、n8n、Notion）的三天後，把「會議排程」「internal docs 同步」「客戶 follow-up triage」這 3 條工作流丟給它跑，得到的具體手感：Scout 強在 Microsoft 365 內部生態（Outlook、Teams、SharePoint、OneDrive），跨系統就會卡，特別是接外部 CRM（HubSpot、Salesforce 的非標欄位）、接 n8n webhook、接 Notion API 的時候，需要寫 connector。所以「公司主力系統是不是 Microsoft 365」這件事就變成第一個篩選訊號。

訊號 1：公司是不是 E3 或 E5 全公司部署 + 主力工作流在 Microsoft 365 上

如果公司主要文書、email、會議、檔案都在 Microsoft 365 上跑，Scout 開箱即用的價值最高。如果是 Google Workspace 為主、Microsoft 只買 Office 單機，Scout 的「always-on」優勢會大打折扣，因為它 watch 不到你最重要的 signal source。

訊號 2：公司有沒有把 information overload 列為前 3 大痛點

Scout 解的是 knowledge worker 一天收 200 封 email、開 6 場會、被切 30 次 context 的痛。如果你公司的主痛點是行銷投放、客服回應速度、生產排程——那 Scout 不是現在該買的工具，先把 RPA、客服 AI、ERP 整合做完比較實在。

訊號 3：公司有沒有「影子 AI」治理框架（或願意 30 天內建一個）

Scout 會自己發 email、自己 update CRM，這代表「員工偷用 ChatGPT」那種影子 AI 風險，會升級成「AI 自己偷做事」風險。沒有 governance 框架的公司，導 Scout 等於在自己公司放一個沒有 SOP 的新員工。延後 6 個月，先把治理委員會起步。

訊號 4：有沒有預算空間消化 USD 33/月/座（Scout + Governance Pack）

一個 50 人的公司，全員部署一年要 USD 33 × 50 × 12 = USD 19,800（約台幣 64 萬）。中小企業老闆建議用 ROI 倒推：Scout 必須幫每個員工一個月省下至少 4 小時、且這 4 小時要能轉成可量化營收，否則就是花錢買 marketing。我們在 中小企業 AI 預算 50 萬 3 條路線：顧問、SaaS、客製，18 個月成本與 90 天決策 那篇有 3 條路線的成本對照，可以拿來搭這條訊號做完整預算評估。

Scout vs Microsoft 365 Copilot vs Claude for Work vs 自家方案 並排決策表

這張表是中小企業老闆在會議室拍板前最需要的一張紙。我們把 4 個方案的核心差異按「定位、月費、整合深度、治理可控性、客製空間」5 個面向並排。

這張表中小企業老闆最常踩的地雷是「Vendor lock-in 風險」這一行——Scout 一旦全公司部署，未來想換掉幾乎不可能，因為它會 build up 一整套「員工依賴 Scout 排會議」的工作習慣，2 年後就算 Microsoft 漲價 50% 你也下不去。我們在 Anthropic、Microsoft、Maia 三方多雲協議的中小企業 AI 成本紅利 那篇就分析過，多雲 AI 的 cost windfall 一旦展開，single-vendor lock-in 會是最大的隱性成本。

如果你公司的工作流不是「主要在 Microsoft 365 上」，可以參考 Anthropic Agentic Coding 報告：55% 工程師用 Claude Code 的中小企業採購指南 跟 Google Antigravity 2 多代理桌面：中小企業 4 個採購訊號與 60 天評估，這兩篇分別給 Claude 跟 Google 路線的對照判斷。

按公司規模試算 Scout 12 個月 ROI

這張表把 3 種規模（20 人、50 人、200 人）的 Scout 採購與回收期算給老闆看，假設每位員工平均月薪 NTD 60,000、每月省下 12 小時（保守估計）、那 12 小時可以轉成可量化營收。重點不是「省幾小時」，是「省下來的時間有沒有人接得住」——這也是為什麼我們 30 天評估清單一定要先列「公司 3 條最痛工作流」。

帳面回收期看起來都很漂亮，但中小企業老闆要知道——這張表的「省下工時」是會計學意義上的，不是現金。員工省下 12 小時，要嘛接更多客戶（變現）、要嘛縮工時（節省加班費）、要嘛同人數做更多事（吸收成長），三選一沒做的話，這個 ROI 是紙上富貴。所以採購 Scout 的同時要配套「省下的時間要去哪」的營運計劃，這也是我們做 AI 顧問服務最常幫客戶釐清的一塊。

中小企業 30 天 Scout 評估行動清單：preview → POC → 採購決策

這份 30 天清單我們用「老闆視角」寫，預設你公司有 IT 主管 1 位 + 採購評估者 1 位 + 願意當 power user 的員工 3 位。如果連這 5 個人都湊不齊，建議先延後評估，這不是 Scout 適不適合，是公司還沒有 AI 採購所需要的最小組織配置。

Week 1：申請 preview + 列「公司 3 條最痛工作流」

• Day 1-2：IT 主管申請 Scout Frontier preview，準備 5 個 E5 授權 sandbox tenant

• Day 3：老闆 + IT 主管開 1 小時會議，列出公司前 3 條最重複、最耗時的知識工作流（例：客戶 follow-up email、會議排程協調、internal docs 同步）

• Day 4-5：給這 3 條工作流訂明確的「30 天後可量化」KPI——例：客戶 follow-up 平均回應時間從 36 小時降到 8 小時、會議排程往返次數從 4 次降到 1 次

• Day 6-7：把 3 位 power user 拉進 sandbox，做基礎 onboarding（看 Microsoft 官方 docs、設 Conditional Access policy）

Week 2-3：跑 POC + 量測

• Week 2 Day 1-3：讓 3 位 power user 開始用 Scout 跑 3 條工作流，每天 EOD 記錄「Scout 自己做了什麼、做對幾次、做錯幾次、怎麼救」

• Week 2 Day 4-7：IT 主管同步驗證 audit log、kill switch、quota——這 3 樣是 Governance Pack 必驗 feature，不能漏

• Week 3 Day 1-5：拉一個 governance review，老闆看 audit log，問 IT「如果 Scout 發了一封錯誤 email 給客戶，我們多久可以追回、多久可以 offboard、賠多少」

• Week 3 Day 6-7：power user 寫 POC 報告，每人 1 頁——KPI 對照、最有用 3 個 use case、最 frustrating 3 個 bug

Week 4：採購決策 + 合約條款

• Day 22-24：老闆 + IT 主管 + 採購評估者 3 人會議，拿 power user 報告對照 4 個採購訊號

• Day 25-26：如果 4 個訊號都 ✓，談合約——必寫條款：90 天試用退場、KPI 對賭、instant offboarding SLA、跨 tenant audit 開放權

• Day 27-28：合約條款這部分強烈建議參考 中小企業 AI 採購防線：POC、合約退場、KPI 對賭 60 天治理，那篇有完整防線拆解

• Day 29-30：簽約 or 延後 6 個月——延後就把 power user 學到的東西封存成內部 SOP，6 個月後重新跑這份清單

這套 30 天節奏的設計邏輯，跟我們在 數位轉型優先序 3 維度框架：痛點、ROI、就緒度，90 天決策 提的「就緒度評估」是一脈相承的——AI 採購不是看工具強不強，是看公司接得住接不住。

5 個常見地雷：把 Scout 當 Copilot 用、影子 AI 不收編、權限設計太鬆、KPI 對賭沒寫進合約、退場條款漏寫

這 5 個地雷我們在過去陪客戶評估 Copilot、Claude、Gemini 的時候，全部都看過真實案例，Scout 上線後預估會再放大 1.5 倍，因為 always-on 的特性讓出錯的窗口從「員工偶爾誤用」變成「24 小時隨時可能」。

地雷 1：把 Scout 當 Copilot 用

最常見錯誤——員工把 Scout 當成 Copilot，只在需要的時候給 prompt。這樣 Scout 的 unprompted-action 優勢完全發揮不出來，等於花 USD 33/月買 Copilot。正確做法是讓 Scout 接管特定常規工作流（例：每天早上 8 點自動整理夜間 email 並排當天會議），而不是等 prompt。

地雷 2：影子 AI 不收編

公司導 Scout 之前如果有員工在偷用 ChatGPT、Gemini、Claude，那些影子 AI 不收編，Scout 上線後員工會「同時用 Scout 跑 Microsoft 365 + 偷用 ChatGPT 跑其他事」，治理風險加倍。建議導 Scout 之前先做 1 輪影子 AI 普查。

地雷 3：權限設計太鬆

Scout 預設給 delegated permission 是「完整 mailbox 讀寫 + calendar 完整管理 + SharePoint 完整存取」。中小企業老闆 90% 會直接 approve all。正確做法是 per-role 限制——業務的 Scout 只能讀 CRM 不能改、HR 的 Scout 只能讀員工資料不能發 offer letter。

地雷 4：KPI 對賭沒寫進合約

Scout 的 ROI 是「員工每月省下幾小時」。如果這個 KPI 不寫進合約，9 個月後 Microsoft 業務告訴你「我們已經幫貴公司省下 1,200 小時」，你沒辦法 challenge。合約必寫「30 天後 KPI 未達 X，partial refund 或 free credit Y」。

地雷 5：退場條款漏寫

Scout 建起來的「員工依賴」是最強 lock-in。合約必寫 90 天試用退場、所有 audit log 與 prompt history 可以 export 走、Scout 寫進 SharePoint / Outlook 的 metadata 可以 strip。退場條款這塊我們之前在採購防線那篇講過，再延伸一條：Scout 特別要寫「offboarding 後 Scout-generated metadata cleanup SLA」——例如 Scout 自動加進會議邀請的會議摘要、自動產生的 follow-up email 樣板、SharePoint 自動分類的 metadata tag，這些東西退場時要明確寫清楚誰負責 strip、SLA 多久。漏寫這條，3 年後要換工具時你會發現 Scout 的「痕跡」遍布整個 Microsoft 365 環境，清不乾淨。

我們補一個觀察給中小企業老闆——這 5 個地雷裡，地雷 1（把 Scout 當 Copilot 用）與地雷 4（KPI 對賭沒寫進合約）是「自己造成」的，地雷 2、3、5 是「合約沒寫清楚」造成的。前者靠內部 onboarding 訓練解決，後者靠外包顧問或法務把關。如果公司沒有對 AI 採購熟的法務，地雷 4 跟地雷 5 的條款建議直接找做過 enterprise SaaS 合約的事務所幫你檢視，這筆錢不要省。

老闆找外包做 AI 治理時要看 4 個訊號：3 個技術題問外包能不能答

Scout 一上線，中小企業老闆會收到至少 10 通外包顧問電話，賣的東西從「Scout 導入服務」「Microsoft 365 重整顧問」到「AI 治理框架建構」。怎麼篩？我們建議 4 個訊號 + 3 個技術題。

訊號 1：外包有沒有自己跑 Scout Frontier preview

沒跑過就是還停在看 marketing 階段，直接 pass。

訊號 2：外包能不能講出 Scout vs Copilot 的 3 條分水嶺

講不出 unprompted-action、delegated permission 雙簽章、instant offboarding 這 3 個關鍵字的，是看了 5 篇科技媒體就出來接案的，直接 pass。

訊號 3：外包能不能拿出 Conditional Access policy 範本

AI 治理不是 PPT，是 Azure AD 上面的 policy。外包如果連 sample policy 都拿不出來，直接 pass。

訊號 4：外包願不願意把 KPI 對賭寫進合約

不願意對賭就是不相信自己交付能達標，直接 pass。

3 個技術題：（1）Scout 的 delegated permission 怎麼設 per-role 限制？（2）Scout 的 audit log 怎麼接到我們現有 SIEM？（3）Scout 上線後 90 天我要 offboard，怎麼確保所有 Scout-generated content 的 attribution 留下來但 Scout identity 被 revoke 乾淨？這 3 題我們在 AI 外包供應商真實能力 6 個訊號 + 3 個技術測試 那篇提的「真實能力 6 個訊號」是一脈相承的框架，可以一起用。

如果你想要更完整的「常駐 AI 員工」治理框架（包含 audit log、retention、權限矩陣這些 enterprise 級別的議題），可以參考 Claude Mythos 1 發表：code security dashboard 中小企業 30 天治理行動 跟 Snowflake + Anthropic Governed AI Data Cloud 中小企業決策，兩篇都拆過治理側怎麼跟採購側對齊。

Scout 採購評估 checklist 下載與軟橋接

我們把上面所有採購訊號、評估行動、合約條款濃縮成一份 PDF checklist，老闆會議室直接印出來，每一條打勾走完，30 天評估完。

我們怎麼看

如果你已經在評估 Scout、Copilot、Claude 的採購選項，想要一個「不是 Microsoft 業務、也不是 Anthropic 業務」的第三方視角——我們最近幫客戶做的多雲 AI 採購評估都是這條路線，30 分鐘聊完你會拿到一份「現在該動、該等、該換路線」的具體建議。跟我們聊聊 →

如果你公司的需求已經超過「現成 SaaS 接一接」、需要把 Scout / Copilot / Claude 跟自家 ERP、CRM、客製系統做深度整合，AI 系統客製整合 → 我們的 [AI 系統開發] 線就是吃這類深度整合案，平均交付週期 8-12 週。

Microsoft Scout 採購常見問題 FAQ

外部參考資料

（以下連結為 nofollow 外部引用，方便老闆要原始來源時取用）

• Microsoft 官方 blog：Introducing Microsoft Scout, your always-on personal agent (2026/6/2)

• Computerworld: Microsoft unveils Scout, an autonomous AI agent built on OpenClaw (2026/6/2)

• CIO: Microsoft, Google push AI agent governance into enterprise IT mainstream (2026/6)

• TechCrunch: Microsoft launches Scout, an OpenClaw-inspired personal assistant (2026/6/2)

補充延伸閱讀：如果你想看完整的「中小企業 AI 治理委員會」起步流程，可以回頭看我們之前寫的 中小企業 AI 治理委員會起步指南，那篇是 Scout 治理框架的前置功課。