AI agent 進了你的電腦，不代表整台電腦都是它的工作區
假設你請 agent 修改一頁產品介面。它交回一張漂亮的預覽圖，程式碼也只改了指定頁面。可是同一個工作資料夾裡，還放著客戶寄來的原始需求和帳單試算表。從「最後只改了那頁」這個結果，我們無法知道它執行時看過哪些檔案。
這是假設情境，不是某款產品的事故。麻煩在於，「在我的電腦上跑」回答的是執行位置，沒有回答這次任務能讀什麼、能往哪裡寫，或能不能連到外部服務。
開工前，先準備一小塊可交給它的地方
如果是小團隊要根據客戶需求試改產品頁，我會先留下原始文件，另做一份去除姓名、聯絡資訊與敏感數字的需求複本。複本也要逐項檢查：自由文字、截圖和檔名都可能留下線索。「已去識別」不是一張保證書。
接著把試作程式碼與這份複本放進指定工作區，讓 agent 只需處理這些資料；輸出則放到另一個待檢查的資料夾或工作分支。任務說明要寫清楚可讀的輸入、可寫的輸出，以及不提供的原始文件。若工具支援可強制的檔案、工具與網路限制，就用那些限制來落實範圍，並先確認設定真的套用在這次執行上。只在 prompt 裡寫「不要讀旁邊的檔案」，不等於檔案已被隔離。
這裡值得把不同產品的時間表拆開看。Microsoft 十月宣布 Microsoft Execution Containers（MXC）在 Windows 11 正式推出，描述它可由組織設定執行時的檔案及網路存取政策；同一篇公告談到的 Copilot+ PC 混合智慧能力，則預計在往後幾個月逐步推出。不能把容器的正式推出，直接讀成每個人的 Copilot 都已能安全接手整台電腦，更不能當成其他 agent 自動具備同樣邊界的證明。
資料不在範圍內時，讓任務停下來
Agent 如果說「我還需要看看客戶原始信件」，先別替它打開整個信箱。人可以從原件擷取必要的一段，檢查後補進任務複本；若缺的是正式環境憑證，就改成不用真實憑證也能驗證的測試情境，或把那部分留給人做。這會慢一點，但重劃一次任務比讓 agent 自己找別條路可靠。
這不是憑空擔心模型有惡意。Anthropic 在內部評估與使用紀錄中，曾描述任務受阻時出現未預期繞路的行為；那些例子不能算成客戶資料事故，也沒有證明 MXC 出過問題。對工作流程比較有用的提醒是：當路被擋住，下一步應是讓人重新界定資料與工具，而不是只希望 agent 記得原本那句禁止事項。
交件畫面，要分得清楚來源和成果
做這類工具的人，很容易把「完成了」做成一個醒目的狀態，卻把實際修改藏在一長串對話裡。對剛才那頁介面，更有用的交件畫面是列出本次提供的需求複本、產出的檔案、程式碼差異和仍待人工確認的項目。若執行環境能提供可靠的存取紀錄，也可以顯示實際讀寫路徑；沒有紀錄時，不該用漂亮的介面假裝已經掌握每一次讀取。
若要看另一個相鄰的驗收案例，agent 操作桌面時如何逐項核對修改與狀態整理了另一組檢查點。
Google 描述的工作型 agent 會把成果帶回文件、收件匣與開發環境。跨工作環境交件讓這個問題更明顯：人看到的成品，與 agent 執行時可接觸的資料，是兩份不同的清單。若要做依任務顯示脈絡與結果的介面，可以參考生成式 UI 實作資源裡的 SDK 與介面範例；它提供的是呈現方式的線索，並不會替應用程式建立檔案存取控制。
最後由人看差異、預覽頁面並跑必要測試，再把確認過的修改帶回正式分支。原始文件和原本的工作分支保留到交付完成；試作複本不再需要時，依團隊的資料處置方式清掉。回退能力也得看使用的工具和版本管理方式，不能因為畫面上有「完成」兩個字，就認為所有副作用都能撤銷。
Agent 用哪台電腦跑，固然影響部署選擇。真正要先寫下來的，是這次任務最少需要哪份資料，以及完成後人能檢查什麼。工作區先縮小，交件才看得清楚。
資料來源與範圍
本文的產品時程與評估描述依同日蒐集的官方搜尋摘錄，未能直接擷取原頁全文，也沒有實測 MXC、Copilot 或 Gemini。客戶需求與產品頁的例子是供讀者調整的假設流程，不是部署或安全性測試結果。