把 OpenClaw 接進公司，我第一個問 IT 的問題是 audit log 怎麼設
Microsoft 在 Build 2026 宣布把 OpenClaw 更深整合進 Windows 跟 Microsoft 365，討論串的焦點幾乎馬上從「功能有多酷」跑到了「企業環境能不能真的管得住」。我覺得這個位移本身就很說明問題。
在 fintech 環境裡，我們過去半年也在評估把 agentic workflow 接進幾個內部工具，包括合約審閱、郵件分類、排程自動化。功能不是問題，現在的模型能力夠，讓人頭大的是另一層：這個 agent 在做事的時候，我到底能控制它到什麼程度？出錯的時候我能追到哪一步？
傳統系統有成熟解法，agent 很多都沒有。
以我們試接排程系統的經驗來說，agent 的 write scope 如果沒有明確限制，第一周就會出事。我們沒出事，是因為一開始強制 read-only，讓它只能讀行事曆資料、產出草稿，任何實際寫入都要人工確認。聽起來保守，但這個設計讓我們在第一個月安全地收集錯誤 pattern。blast radius 被控在一個人工審閱步驟裡，失控範圍可預測。
問題是：這種 read-only / write scope 的邊界，在 Microsoft 的 execution container 框架裡能不能精確設定？從目前看到的 sandbox 機制說明，方向是對的，但細節還不夠。企業真正需要的粒度是：這個 agent 在「合約審閱」這個 workflow 裡可以讀 OneDrive 的特定資料夾、可以寫草稿到另一個資料夾、不能存取 Teams 訊息、不能呼叫外部 API。光說「在安全容器裡跑」還不夠，RBAC 能不能細到這個層級才是關鍵。
Reddit 那串有人說 Copilot 本來就有 agentic capability，接 OpenClaw 進去可能只是多一層風險。我理解這個質疑，但問題放錯地方了。重點不在層數，在於每一層的 policy 有沒有辦法讓 IT 管理員獨立設定。如果這次整合讓 agent 的行為邊界可以用跟 Intune、Azure AD 一樣的方式管理，那意義在於：企業第一次有辦法以 service account 的層級對待 agent，給它獨立的身份、獨立的 audit log、獨立的 approval gate，而不是讓它掛在員工帳號底下偷偷做事。這兩個架構，責任歸屬的清晰度差很多。
但這也是我目前最大的疑問：這套治理框架到底是真的產品能力，還是 marketing 話術？
Microsoft 很習慣先宣布再做。幾位工程師在討論串裡直說，真正能在企業穩定跑可能還要一年。我不驚訝。但就算功能都到位，canary rollout 這件事如果企業沒有辦法自己控，從 5% 用戶開始測、有問題能快速 rollback，不管功能多強都不敢動。我們在 fintech 推任何新系統都是這個邏輯，agent 進來也不例外。假設我現在要在 500 人公司的 IT 部門推這套，第一階段我只會給 10 個工程師的測試群組，scope 只有讀 Outlook 草稿的權限，跑兩週確認 audit log 格式對、incident 追蹤機制有效，再考慮下一步。這個過程可能要三到六個月，跟新聞稿的時間表對不上是正常的。
我認為接下來一年，企業 agent 的競爭點不會是「它能幫你做什麼」，會是「你能對它做什麼」。能限制、能監控、能分階段放量、出問題能追到每一個操作節點，責任邊界清楚，這些才是 IT 部門、法務、合規真正在評估的東西。Microsoft 如果把這次整合做成這個方向，而不只是讓 agent 更會幫你寫 Word 文件，那才是企業場景真正有意義的事。
文件還沒夠細，先保留評估。
作者：鍵盤工人