Build 2026 把代理變系統

我把 Microsoft Build 2026 拆成可抄的代理系統做法：上下文、執行環境、模型路由、治理與模板。

我最近一直在看各家代理框架，看到後來真的很膩。簡報上都很會講，什麼自動化、什麼多步推理、什麼幫你把事情做完；可一落地就開始漏氣。模型會回得很快，卻常常快到亂答；工具接得很滿，結果一碰到權限、記憶、檢索、稽核，就整個像臨時拼起來的玩具。我不是沒試過，我是試太多次了。

所以我看到 Microsoft Build 2026 的這篇 〈Be yourself at work〉 時，第一個反應不是興奮，是皺眉。因為它雖然還是有一點平台味道，但講的東西意外務實：代理不是單一模型加一個 prompt 而已，而是一整套系統，包含上下文、執行環境、模型選擇、治理和開發流程。這才像真的有做過案子的人會講的話。

他們不是在賣模型，他們在賣上下文

「對任何組織來說，差異化的重點不再是取得智慧，而是擁有權。」

這句話很直白，也很像大廠會講的那種話，但我覺得它抓到重點了。問題從來不是「有沒有模型」，而是「代理到底懂不懂你的工作場景」。

翻譯一下就是：模型只是引擎，真正值錢的是它能不能抓到你公司的脈絡。Microsoft 把這層拆成幾個方向：Microsoft 365 內的工作脈絡、Microsoft Fabric 的結構化資料、企業知識檢索，以及外部網路資訊。它們想講的不是「再塞一個向量資料庫」，而是「把上下文變成平台能力」。

我以前做過一個內部助理，模型很強，工具也不少，但答案一直不好用。後來回頭看才發現，問題不是模型不夠聰明，是它根本不知道誰在問、問的是哪個專案、哪些資料能看、哪些只能參考。它拿到的是一堆碎片，當然只能亂湊。

實操上，我會把上下文至少切成三層：

• 身份與權限：誰在用、屬於哪個團隊、可以碰哪些工具。
• 企業知識：文件、工單、CRM、行事曆、會議紀錄、內部 API。
• 即時資訊：網頁、政策文件、版本公告、公開文件、競品頁面。

這三層不分開，代理就會把私有資訊和公開資訊混在一起，答出來的內容看起來很順，實際上很危險。這種錯最煩，因為它不是大爆炸，是慢慢把你信任磨掉。

我會建議你先不要急著做「記憶系統」，先做「上下文分層」。只要你把身份、企業知識、即時資訊拆開，後面檢索、權限、稽核都會好做很多。這一步很土，但很有用。

Web IQ 這段，我會先抄走

Microsoft 在文裡提到一個我覺得最有實作味的東西：Web IQ。他們把它描述成給代理做即時 grounding 的一層，強調速度、模型無關、而且支援 MCP。這種說法聽起來很像行銷，但方向其實對。

白話一點說，就是不要叫代理自己去網路上亂翻。你要的是「相關段落」，不是「一整頁搜尋結果」。代理最浪費時間的地方，常常不是推理，而是找資料、刪垃圾、再把垃圾吞回去。這種流程很吃 token，也很吃時間，還很容易把不重要的內容當成重點。

我之前做過一個研究助理，最痛的地方就是搜尋層。網頁抓回來一堆，模型每次都像在垃圾堆裡撿報紙。最後不是答非所問，就是引用到過時內容。那時我就很確定，檢索層不能只是「搜尋 API + 把結果丟給模型」這麼粗暴。

實操上，我會這樣做：

• 搜尋和抽段落分開，不要把整頁 HTML 直接塞進 prompt。
• 回傳的是 passage，不是 page。
• 每個片段都要帶來源網址、時間戳、可信度。
• 檢索層盡量做成模型無關，別把整個系統綁死在單一供應商。

如果你現在就要做一版，最小可行架構其實很單純：先搜尋，再做段落排序，再做來源過濾，最後才交給代理循環。不要讓模型自己猜資料在哪裡，因為它猜的時候通常都很自信，這才是最麻煩的地方。

他們終於開始談執行環境，不只談 prompt

這段我看得最順眼。Microsoft 沒有只講「代理需要知識」，而是把執行環境也一起端上來：沙箱、容器、主機代管執行、Windows、Windows Subsystem for Linux、還有各種治理工具。意思很明顯，代理不是聊天框，它是會真的去做事的程式。

翻譯一下就是：只要代理能讀檔、寫檔、跑指令、呼叫服務，runtime 就不是配角，而是主角。很多團隊做代理 demo 的時候都很順，因為是在筆電、Notebook、或某個臨時腳本裡跑；一旦進到正式環境，就開始撞安全政策、撞檔案系統、撞權限、撞工具版本。最後你不是在 debug 代理，是在 debug 平台。

我自己踩過最煩的一次，是把一個看起來很漂亮的工作流搬到正式環境，結果每一個步驟都要補權限，補到後來整個流程變得又慢又碎。那時我才懂，代理如果真的要上線，先定義邊界，再定義行為，順序不能反。

實操上，我會直接照這個順序來：

• 先定義執行邊界，再定義代理能做什麼。
• 能寫、能刪、能呼叫外部系統的動作，一律放沙箱。
• 政策要宣告式，別把檢查散在五個服務裡。
• 本機和雲端的執行條件要盡量一致，不然你只是在製造假成功。

這一塊我覺得比炫技重要多了。因為只要代理開始動手，治理就不是附加功能，是基本配備。你不先把 runtime 管好，後面再漂亮的 prompt 都只是表面功夫。

模型選擇還是重點，不是備註

Microsoft 這次也很明顯在推多模型策略，像是 MAI-Thinking-1、MAI-Image-2.5、MAI-Voice-2、MAI-Transcribe 1.5、MAI-Code-1，再加上 GitHub Copilot、VS Code 和 GitHub 這些開發場景。這不是單純秀模型，而是在講「模型路由」。

也就是說，不要迷信一顆模型打天下。推理、分類、摘要、轉錄、圖片生成、程式碼修補，本來就不是同一種工作。你硬要拿同一顆模型全包，最後不是成本爆掉，就是品質不穩，或兩個一起來。

我以前做過一個客服代理，最早也是一顆模型打到底。結果分類很爛、摘要還行、回覆又太慢。後來我把它拆成路由器：先用便宜模型判斷任務類型，再交給對應的專用模型處理，整體就順很多。這種做法很無聊，但很有效。

實操上，我會建議你這樣設計：

• 先做模型路由器，不要把模型寫死在每個步驟裡。
• 每種任務都要知道哪顆模型最適合，別只看排行榜。
• 評估指標要對準你的工作流，不要拿通用 benchmark 自嗨。
• 保留失敗退路，包含延遲、成本、政策限制三種情況。

如果你團隊現在還是「一顆模型跑全部」，我真的建議你早點拆。不是因為多模型比較潮，是因為它比較像真的系統。

治理如果不先做，代理只會變成事故機器

這篇裡面我覺得最值得注意的，是 Microsoft 把治理講得很前面。他們提到 Agent 365、ASSERT、Agent Control Specification，還有一套用多個代理找漏洞的安全系統 MDASH。這些名詞很多，但核心其實只有一個：代理一旦會動手，就要能被識別、被限制、被稽核。

白話說，代理不是「有沒有回答」的問題，而是「它到底是誰、能做什麼、碰過什麼、出事怎麼停」。這些如果不先設計，後面一切都會很痛。很多團隊喜歡說先做 prototype，再補控制；我聽到這句就想翻白眼，因為那通常代表最後根本補不回來。

我見過最慘的狀況，是代理可以發信、改文件、呼叫 API、觸發工作流程，結果權限和紀錄各自散在不同系統。真的出事時，連誰下的指令都查不乾淨。這種系統不是不聰明，是不可信。

實操上，我會直接要求這幾件事：

• 每個代理都要有自己的身份，不要只共用一把 API key。
• 所有工具呼叫都要記錄輸入、輸出和政策判斷。
• 評估環境和正式權限要分開。
• 上線前先測 kill switch，不要等事故發生才找按鈕。

如果你想看別家怎麼處理，也可以對照 Anthropic 的工具文件，或看 MCP 生態怎麼談工具接法。大家講法不同，但問題都一樣：模型能動手之後，控制平面就不能再隨便。

本機開發還是很重要，別被雲端話術騙了

Microsoft 也沒有完全忽略本機環境。他們提到像是 Windows、WSL、GPU passthrough、終端機體驗、還有開發盒子這些東西。這聽起來很像硬體廣告，但其實是在講一件事：開發者還是需要快速在本機把代理跑起來。

翻譯一下就是，雲端再方便，本機迭代還是最省時間。你要試 prompt、試工具、試 sandbox、試權限，本機如果卡得要命，整個團隊的節奏就會被拖死。很多 AI 專案最後不是死在模型，而是死在環境太碎。

我自己最討厭的就是那種「理論上可以跑」的開發流程。GPU 在這邊，Linux 在那邊，IDE 在另一邊，權限又要另外申請，最後每個人都在修自己的機器。這種時候你根本不是在做產品，你是在做安裝教學。

實操上，我會這樣要求：

• 本機開發要是正式路徑，不是玩具路徑。
• 本機權限和生產環境盡量對齊。
• 讓開發者能在本機先跑代理循環，不要每次都等遠端資源。
• GPU、沙箱、shell、檔案系統這些能力要整合，不要各自為政。

這件事很樸素，但真的省時間。你只要讓本機環境夠像正式環境，很多問題在上線前就會先露餡，總比上線後才爆來得好。

可抄的模板

# 代理系統模板：先上下文，再執行，最後才是模型

## 1. 上下文分層
- 身份層：使用者是誰、屬於哪個團隊、可用權限有哪些
- 企業層：文件、工單、CRM、會議紀錄、內部 API
- 即時層：網頁、公告、版本說明、公開文件、競品資訊

## 2. 檢索規則
- 回傳段落，不回傳整頁
- 每筆資料都帶來源網址、時間戳、可信度
- 企業資料與網路資料分開檢索
- 檢索層保持模型無關

## 3. 模型路由
- 推理模型：多步規劃、整合、判斷
- 便宜模型：分類、路由、短答
- 程式模型：程式碼生成與修補
- 語音/影像模型：只有在任務需要時才叫用

## 4. 執行政策
- 每個代理都要有身份
- 每次工具呼叫都要記錄
- 寫入與刪除動作一律沙箱化
- 網路存取必須明確授權
- 高風險動作要有人工確認

## 5. 執行環境
- 本機開發要盡量貼近正式環境
- 能用系統層沙箱就不要只靠應用層
- 本機與雲端都要能跑同一套代理流程
- 支援快速迭代，也支援集中部署

## 6. 評估方式
- 測實際工作流，不要只看通用 benchmark
- 量延遲、成本、正確率、失敗復原
- 對政策違規做回歸測試
- 只要檢索、模型或政策變更，就重跑評估

## 7. 上線順序
1. 先定義任務
2. 再定義上下文層
3. 再定義權限
4. 接檢索
5. 接模型路由
6. 接評估
7. 最後才上線

## 8. 最小提示詞骨架
你是 {{公司名稱}} 的內部代理。
你的任務是 {{任務}}。
只能使用下面列出的工具與資料來源。
請嚴格遵守執行政策。
如果缺上下文，就先問。
如果動作有高風險，就停下來請求確認。
回答要簡短、可追溯、可引用。

## 9. 工具白名單與黑名單
- 允許：search_web、read_docs、query_database、create_ticket、draft_email
- 禁止：delete_records、send_external_email、deploy_prod

## 10. 上線檢查清單
- [ ] 上下文來源已盤點
- [ ] 檢索已測過
- [ ] 模型路由已設定
- [ ] 沙箱已強制啟用
- [ ] 稽核紀錄已開啟
- [ ] kill switch 已測過
- [ ] 回歸評估都通過
- [ ] 申請與核准流程已寫清楚

這份模板不是照抄 Microsoft 原文，我是把它拆成我自己會用的版本。它的精神很簡單：上下文先行、執行環境第二、模型選擇第三、治理要一路跟著。你如果明天就要做內部代理平台，我會建議直接從這個順序開始。

我不會跟你說這樣最輕鬆，因為它一點都不輕鬆。但如果你的代理要真的做事，這就是比較像樣的做法，不是那種只會講話的 demo。

來源主要是 Microsoft 官方文章 Microsoft Build 2026: Be yourself at work，我把原文拆解後改寫成台灣開發者比較能直接拿去用的版本。其他參考連結包含 MCP、Microsoft Fabric、VS Code、Anthropic 工具文件，原創整理與模板是我自己補的。