一家公司的銷售資料在 Drive，商機在 CRM，討論在 Slack，市場團隊還要把分析變成方案。引入 Agent 時，最難的通常不是讓它寫出第一份文件，而是決定：它從哪裡取得上下文，以誰的身份行動，做完的東西交到哪裡。
Google 在 2026 年 10 月 8 日公佈 Gemini agent，將問答、知識工作、內容創作和程式碼執行放進同一個企業 Agent。它不只是掛在 Gmail 旁邊的助手：公告明確描述了持久雲執行、獨立 coworker 身份、動態子 Agent、Skills、跨系統工具和治理。
Buda 則以可見的 Agent 工作區組織執行：聊天、持久檔案、終端、瀏覽器、預覽和 Git 共同指向同一臺雲電腦。兩者都有持續工作的目標，選擇取決於公司的工作記錄在哪裡、由誰管理，以及人準備怎樣檢查結果。
Google 把 Agent 放進現有組織裡
Google 的部署路線從企業現有系統出發。公告描述，Gemini 可在 Workspace、Microsoft 365、Slack、命令列和第三方應用中訪問，連線 Salesforce、ServiceNow、資料庫、Git、Jira 以及 MCP servers。工具與 Skills 可以進入公司共享 registry。
這條路線的具體優勢，是讓 Agent 在員工已經使用的文件、郵箱和身份體系中出現。Google 給出的例子是：營銷負責人把 events coordinator Agent 加到 Chat 群裡，讓它起草上線準備文件；同事也能在 Docs 評論中提及它，編輯以它自己的身份進入版本歷史。
coworker Agent 可以擁有獨立 Workspace 賬號、郵箱、日曆、Drive 和公司目錄身份，只看到團隊分享給它的內容。另一個機制是按任務動態建立臨時子 Agent，分別承擔並行或順序工作。長期崗位與臨時分工是不同概念，不要把兩種身份混為一談。
這次釋出的 Gemini agent 也不同於 Gemini Spark 和 Gemini 模型。Agent 是工作的執行與組織層，底層模型是另一個選擇；Google 公告提到 Gemini 與 Claude 模型，以及後續擴充套件模型選擇的計劃。
Buda 把執行現場放在一個可檢查的工作臺
在 Buda，一個 Agent 的聊天、Files、Terminal、Browser、Web Preview 和 Git 是同一雲電腦的不同檢視。生成的檔案可以直接開啟，命令和瀏覽器過程可以檢視，應用可以預覽，程式碼可以看 diff 和提交歷史。
這適合需要同時處理檔案、網頁和指令碼的工作。例如，把銷售提供的已批准資料整理成 CSV，執行分析指令碼，生成帶來源的市場報告，再準備方案草稿。負責人不必只接受一段“已完成”的回覆，可以檢查實際檔案、計算過程和待確認項。
Agent Drive 與 Space Drive給上下文提供兩種明確位置：前者儲存單個 Agent 的工作檔案和記憶，後者用於團隊與多個 Agent 共享材料。共享應是明確動作；把檔案放到私有 Drive，不等於它自動進入全團隊上下文。
Buda 的可見工作臺不替代企業系統授權，也不能據此推斷具備 Google 公告中的 Agent Gateway、企業身份傳播或等同的審計控制。採購需要把“執行能否檢查”和“公司政策如何強制執行”分別驗收。
同一份營銷方案，兩種上下文成本
可以從一份新品營銷方案開始：整理銷售反饋，形成方案草稿，再讓同事檢查與接手。
**Gemini 路線：**把現有文件和群聊分享給 coworker，確認 CRM 等系統的連線資格及許可權，讓它在原有 Docs 中準備方案。值得檢驗的是引用能否對應原記錄、Agent 身份能否追蹤、許可權變更是否生效，以及同事能否在現有文件流程裡接手。
**Buda 路線：**把批准的輸入與業務定義整理成任務包，放到指定共享位置；Agent 在工作區生成來源索引、分析檔案與方案。負責人透過瀏覽器、檔案或 Git 檢查過程，再把接受的結果交回業務系統。
Google 路線可能減少搬運原生文件的步驟；Buda 路線可以讓跨檔案、網頁與程式碼的執行產物集中可見。真正的接入成本包括材料準備、連線維護、許可權設定和最終結果回寫，而不只是第一次輸入 Prompt。
用四個採購問題作決定
| 問題 | Gemini agent 要驗證什麼 | Buda 要驗證什麼 |
|---|---|---|
| 權威材料在哪裡？ | 原業務系統連線、共享與查詢範圍 | 任務包、Drive 和工具的輸入邊界 |
| 誰管理身份？ | coworker／臨時 Agent 身份與公司政策 | Space、Agent、成員及外部工具授權 |
| 人檢查什麼？ | 系統內產物、版本記錄、可用審計日誌 | 檔案、命令、網頁過程、預覽與 Git |
| 結果如何交回？ | 原系統中的更新和接手流程 | 接受後的檔案交付或已驗證連線 |
如果核心資料已經在 Google Workspace 與公司受管系統中，並有管理者維護身份、政策和連線，先驗證 Gemini 的系統內路線更自然。
如果團隊的關鍵工作橫跨網頁研究、檔案加工、指令碼和應用產物，希望先用明確的任務包建立可見執行現場，Buda 更值得試點。工作臺、檔案組織和交付方式，是這條路線的重點。
同時使用時，保持一個權威輸入和一個接受後的結果。避免兩邊都維護同一份變化中的客戶資料；沒有確定回寫負責人，就不要讓兩個 Agent 同時更新同一系統。
把公告能力變成賬戶級驗收
Google 公告描述了 Agent identity、授權、審計、sandbox、Agent Gateway 與 spending controls。部署前要確認公司賬號已開放哪些功能，哪些需要管理員配置。
先確認實際套餐、地域、管理員配置、聯結器和開放範圍；再使用測試資料核對 Agent 能看到什麼、拒絕什麼、留下哪些記錄。Buda 也應對實際 Space 和工具授權做同樣檢查。兩邊都不要用釋出頁面替代真實賬戶測試。
第一個試點，交付五樣東西
選擇一項重複業務，只給最小必要資料，要求交付：
- **來源清單：**輸入記錄、日期、連結和業務定義。
- **實際產物：**報告、表格、指令碼或方案，而非完成宣告。
- **身份與訪問記錄：**誰執行、用了哪些系統、什麼被拒絕。
- **未完成項：**缺少的材料、失敗步驟、需要人工決定的部分。
- **接受記錄：**負責人接受哪個版本，交回哪個位置，誰維護下一次執行。
讓第二位同事在不借用原執行者賬號的條件下檢查並繼續任務。記錄缺失材料、重複解釋、許可權問題和核驗時間；不預設某個平臺更快。
在 Buda，可先開啟Agent Workspace，準備輸入與驗收標準。重複步驟再整理為 Skill；已有適用流程時，可在 Buda AI 的 Marketplace 搜尋並安裝。先確認任務能被接手，再考慮擴大自動執行範圍。