一个智能体入口取代一群助手，采购判断要跟着换

一家制造集团的 IT 负责人今年列了一张表，把公司已经在用的 AI 工具按「谁买的」分栏。表拉到第二十行还在往上加：办公套件里的聊天助手、研发用的编码工具、CRM 自带的服务智能体、财务部门自己搭的流程智能体。每个工具有自己的登录方式、自己的权限配置、自己的月度账单。到了第四季度做预算，他发现一个简单的问题没人答得上来：这二十个工具加在一起，公司今年在 AI 上花了多少，换回了什么。

这个问题在内部推动了一种很自然的反应，就是收敛。与其让二十个工具各自管自己的记忆和权限，不如收进一个入口，用一套身份、一套审计、一张账单。10 月 8 日的 Gemini at Work 2026 上，Google 把这条路走到了台面上：对话、知识工作、图像生成、写代码并执行，全部放进同一个智能体（Google Cloud 发布原文）。

这次发布的措辞泄露了它想改变的东西

Google 对外的描述是：你可以直接和它对话，也可以派给它一个目标，或者让它按时间表执行、由事件触发。它跑在网页、手机、桌面和命令行上，同时进入 Workspace、Microsoft 365 和 Slack，也能以无界面的方式嵌进第三方应用。换句话说，它不再是一个需要你打开的产品，而是一个始终在线的工作对象。

分水岭落在一句接口描述里：你给它目标，不给它指令。指令是一步一步做，目标是委托一个结果。要把结果交出去，智能体必须自己记得上下文、知道能动哪些系统、并且能在几天里持续跑完。Google 的打算是让它常驻云端，一份记忆、一份上下文、一张个性化图谱，关掉笔记本之后任务继续跑，下次打开还在原地。

为了撑住「委托结果」这个承诺，这次发布把三样东西摆到了产品层：多智能体编排（按任务临时拉起一组子智能体，每个子智能体有自己的身份）、coworker agent（有固定角色、跨天跨会话持续存在，有自己的 @agents.company.com 邮箱和独立存储，只能看到团队授权给它的上下文）、以及四类记忆（会话、语义、程序、情景）。工具注册表和技能注册表则是让部门把自己那套做事方法发布成可复用的条目，供全公司的智能体调用。

模型被做成可换件，说明供应商自己知道它会贬值

同一篇发布里还有一句话值得单独摘出来：Gemini 是智能体，它底下的模型是另一个选择。它按任务挑模型，今天在 Gemini 家族和 Anthropic 的 Claude 之间编排，未来再接其他模型，理由写得也很直白：最好的模型每几个月就换一次，把选择留着，你的上下文、技能和数据就不用跟着搬家（原文）。

这句话是全篇最诚实的地方。厂商主动把模型解耦，等于承认模型层会持续商品化，留不住溢价。那么用户留在平台上的到底是什么，答案只剩三样：上下文与记忆、技能与工具的定义、以及执行与审批的记录。迁移成本的位置也就跟着变了。2024 年企业担心的是提示词绑在某一家模型上，2026 年真正的问题是我的组织记忆存在谁的库里、能不能搬走。

收敛的好处是真的，来自治理面的物理减少

分散的助手带来的麻烦主要在管不了。二十个工具意味着权限散在二十个后台，审计要一家一家去问，支出分摊只能按座位数平摊，而座位数跟谁在用 AI 干活没有关系。收敛到一个入口之后，身份、权限、审计、支出上限落在同一层，这是组织能真正开始管理 AI 成本的前提。

治理侧的配置也印证了这一点。这次发布给的是可验证的智能体身份、由 OAuth 传播的权限、按智能体归属的动作级审计、agent 沙箱与 agent 网关，以及按项目实时封顶的支出上限，触发之后智能体会被暂停（现场细节见 Futurum 的现场分析）。同一条路线在今年 4 月已经露过一次头：Gemini Enterprise Agent Platform 接替 Vertex AI，新增的正是 Agent Identity、Agent Registry、Agent Gateway 和执行轨迹（4 月发布）。身份的注册、网关的拦截、轨迹的留存，这些不是助手该有的功能，是基础设施该有的功能。

厂商给出的规模数字需要标清性质：财富 100 强里接近 90% 在使用 Gemini Enterprise，接近 500 个云客户各自处理过超过一万亿 token。这两个数都是 Google 自己在会上说的，没有第三方核验，而且「在用」与「把关键流程放上去」是两件事（Futurum）。真正能说明整合压力的，是这些客户名单背后的采购逻辑，而不是百分比本身。

代价集中在三个地方，而且都不在功能列表上

第一处是单点。一个入口意味着一次故障、一次配额调整、一次定价变化，影响的是全公司的工作流，而不是某一个部门的工具。Futurum 在分析里明确记录：这次大多数公告没有披露价格，也没有给出正式可用日期（同上）。没有价格和可用日期的承诺，在采购上意味着预算定不下来，风险也定不了价。

第二处是捆绑。入口会把预算从点解决方案那里吸走，点工具的价值被压缩成注册表里的一个技能条目。这对买方未必是坏事，但需要看清一件事：你原来按人头买的那几个工具，未来的续约谈判会越来越像在为一个已经包含在上层入口里的能力重复付费。

第三处是搬家。当记忆是平台的私有格式，退出的成本落在把组织上下文重新教一遍，而不只是换一个供应商。这一条最难量化，也最容易被忽略，因为它在签约那天不花一分钱，只在三年后的一次续约里一次性收账。

还有一件容易被漏掉的事：coworker agent 有了自己的邮箱、日历和存储之后，它在企业目录里就是一条正式的记录。组织要处理的问题于是从「部署一个工具」变成了「给一个岗位办理入职和离职」，包括它离职时那些文件和会话归谁、它的历史动作在审计里留多久。这件事在技术方案里通常不会写，但在合规检查里一定会问。

技能注册表还会带出一个新的权限面。按 Google 的设计，团队可以把自定义的工作流发布到公司级注册表，供其他部门的智能体调用（发布原文）。一次发布的影响范围因此超出发布者自己的团队：一个部门写的技能被另一个部门引用之后，改一句措辞就会同时改变后者的行为。企业需要先定一条规则，谁能往公司级注册表发布、发布之后怎么回滚、出问题谁负责，而这条规则通常不在平台的默认配置里。

采购要问的四个问题，每个都有可验证的答案

第一，记忆能不能导出成可读的格式。要的是下一个人或下一个系统能直接使用的结构，日志和一段总结都不够用。验证方法很简单：让供应商导一次，找一个没参与过项目的人读，看他能不能说出上下文里有哪些约束。

第二，技能的定义是不是纯文本。如果「如何做这件事」以提示与规格的形式存在，它就能在别的运行时里跑；如果它被编译进平台的黑盒，那你买的是一段只能在这里执行的经验。

第三，单个智能体的身份能不能独立撤销。撤销之后，它历史上做过的动作还能不能查到归属。这一条决定了事故发生时你能不能只切断一个面，而不是停掉整个入口。

第四，支出上限的语义是什么。超限之后是暂停、降级还是继续跑，通知谁，谁能改这个上限。一个没有明确语义的封顶，在真实预算里等于没有。

我们的判断

企业今年买的不是一个更聪明的助手，是一套组织记忆的所有权。定价应该按搬家的成本来算，而不是按能不能换模型来算；换模型这一项供应商已经替你解耦了，剩下不能解耦的部分才是议价筹码真正的来源。这个判断有一个可检验的推论：如果记忆和技能可以干净地导出，那么同一套工作流换平台应该只需要改适配层，而不是重写判据；反过来，任何一次平台迁移都要重新标注一批验收标准，就说明你买到的不是工具，是依赖。

这个判断有边界。任务单步、用量不大、不跨系统写入的团队，收敛带来的治理收益大于搬迁风险，没有必要为了可携带性自建一层编排。流程跨监管边界、审计记录要交给外部机构的企业则相反，可携带性优先于整合度。Deloitte 在对近 550 位美国高管的调查里发现，80% 认为自己在基础自动化上已经成熟，只有 28% 对「自动化加智能体」这么说，同期只有 12% 认为智能体投入能在三年内回本（Deloitte TMT Predictions 2026）。成熟度没到这个位置的企业，先收敛入口确实能少走一段路；已经跑在关键流程上的企业，就该把可携带性写进合同。

本周能做的一件事

挑三条真实任务，最好是跨系统的，比如「从合同里提取付款条款并写进 ERP」。要求供应商把这三条任务的历史轨迹各导出一次，然后一起看导出文件里有什么：有没有工具调用的记录，有没有决策点，有没有人工批准的时间戳。如果导出的只是一段读起来很顺的总结，说明你买到的是结论，不是记录。结论没法用来回看过程，也没法跟着你搬家。

这件事的成本是一次会议，收益是你能在签约前知道三年后的退出价。