一家公司的销售资料在 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 搜索并安装。先确认任务能被接手，再考虑扩大自动运行范围。