科技巨头争夺AI智能体的工作入口

从回答走向交付

10月8日，Google Cloud宣布Gemini agent，提出让用户交代目标，由软件规划步骤、连接业务系统并交回完成的工作。AI智能体，是能够围绕目标调用工具、执行操作的软件；这次发布把它推向知识工作、内容制作和代码运行的共同入口。变化不仅在于回答更完整：一旦用户把任务交出去，平台就要保存进度、取得操作权限，并承担任务运行所需的资源。对企业而言，选择智能体也因此变成选择一套工作运行环境。能否接管入口，要看它能在多大范围内把任务可靠地做完。

现有应用成为大厂承接任务的起点，但各家的动作范围与推出状态需要分开看。Google把入口放进Workspace，宣称Gemini在邮件、文档和日历中沿用同一套记忆、技能与控制。Microsoft把Copilot入口分成Home、Code和Autopilot，分别承接协作、构建软件和持续委派任务，9月25日公告仍安排分阶段推出。Apple把入口嵌进Siri及系统应用，9月14日开始推出英文测试版，Outlook等新增应用操作则列为即将提供。这些路径共同利用已有的应用关系，减少用户重新连接资料的负担；企业评估时仍需区分已开放的操作与后续推出的功能。

收费方式牵动任务

任务交给谁，也受到谁付钱的影响。Financial Times将Meta的Muse描述为日常事务工具，并把其商业方向解释为从智能体促成的交易中抽成；报道没有给出抽成比例或付款方安排。OpenAI的dots则被定位于复杂工作，Financial Times称它最初只向每月ChatGPT订阅费用至少100美元的客户开放。这是访问门槛，不能据此算出完成一项工作的成本。由这两种定位可以推断，前者需要把用户意图接到可成交的服务，后者需要让付费用户获得足以支撑订阅的工作产出。商业模式由此牵动产品先解决什么问题。

交易路线首先遇到的是外部网站的准入。Financial Times援引Jefferies分析师数据称，约三分之二的旅游、商务和预订网站以某种方式屏蔽Muse。这个范围不能扩大为全部互联网，也不代表每一次访问都失败；它说明智能体替人操作，还取决于服务提供方是否接纳这种访问。按照该报的分析，Meta因此承受着与网站建立直接联系的压力。如果接入进一步变成商业协议，平台就可能影响订单被送往哪些商家。对商家而言，智能体带来客流的同时，也把接入条件和交易关系推到经营决策前面。

云端接着跑靠什么

工作任务则把平台推向持续运行。按Google的说明，云端执行让持续数小时或数天的任务在用户关掉电脑后继续运行。共享记忆让Gemini跨设备和渠道沿用同一套上下文，减少用户重复交代业务背景。子智能体是它动态创建的临时专项代理，各有身份，用于协调并行或顺序步骤。这三项分别处理运行位置、任务信息和工作拆分，不能只靠聊天界面完成。Google还提出具有固定角色和持久存储的团队成员型智能体，访问范围限于用户或团队提供的上下文。由此可以看出，长期执行需要同时管理状态和身份，任务越深入业务系统，授权边界就越需要明确。

Microsoft的安排把运行环境直接纳入企业管理。其9月25日公告称，Autopilot在企业租户内拥有自己的身份、记忆、计算机和工作区；租户可以理解为企业在云服务中的独立管理空间。公司同时推出预览版Copilot Managed Runtime，让生成的代码在企业Microsoft 365环境内运行，由IT部门治理。Code则在沙箱中执行，沙箱是限制程序活动范围的隔离环境。这些设计针对的是软件开始行动之后的管理需求。管理员要决定它能连接哪些业务数据、运行哪些应用，业务团队也要划定可以委派的任务范围；这些设置决定企业实际能够委派的范围。

预算也会叫停任务

持续运行还需要一个明确的费用边界。Google在10月8日的完整公告中说明，费用监测覆盖模型处理文本所用的token和沙箱成本。项目预算可以设硬上限，触顶后该项目的智能体暂停，用户可在控制台选择恢复。费用按项目追踪，企业可以把AI支出归入具体部门。按这套设计，预算触顶会中断任务执行，企业必须把费用上限与交付要求一起设定。Google还提出按任务调度模型，具体支出仍取决于模型调用和运行资源的使用。财务部门需要知道钱花在哪项工作上，任务负责人则需要知道余额是否支持工作继续完成。

这也给数据中心读者提供了更具体的需求线索。前述云端长任务、子智能体协调和托管代码运行环境，涉及模型推理、代码执行、存储和网络。推理是模型根据输入生成结果的计算过程。从架构可以推断，运营者需要协调这些资源，并保存任务跨步骤、跨时段的状态。持续执行不等于GPU全天满载，智能体可能等待工具返回，也可能执行普通程序。公告没有提供足以推算新增GPU数量的任务负载数据，不能直接把运行时长换算成加速器需求。对云平台来说，交付条件还包括任务进度能否保留、资源使用能否计量，以及预算中断能否被业务团队处理。

落地案例保留人工关口

Google Cloud与运动品牌On在10月8日发布的联合公告，为这套承诺提供了一个有边界的实例。公告称，On用AI智能体迁移了24项核心服务，其中15项迁移由内部工程师完成。智能体负责代码库分析、基础设施配置生成和测试验证等专项步骤。公告同时说明，工程师审查生成的代码、执行基础设施变更，并批准生产切换。这里的生产切换，是把线上业务转到新环境的关键操作。这个案例支持的判断是，智能体已经可以参与复杂工程任务的执行，但高影响决策仍由人承担。公告描述的执行范围是经过拆分、设有检查环节的专项工作。

On的做法也说明，交付成果需要具体的验收边界。配置脚本可以交给软件生成，工程师仍要检查它是否适合实际环境；测试步骤可以自动执行，线上变更仍要有人授权。这份联合公告没有给出完整的模型、运行资源与工程师复核成本，因此无法据它计算每次迁移的总成本。它的证据价值在于明确列出了已执行的工作与保留的人类职责。企业采购时可以沿用这样的划分，先确定哪些步骤能够委派、哪些结果必须复核，再判断一项订阅或云服务能承接多少实际工作。

入口取决于可托付范围

把这些发布放在一起，大厂争取的授权已经从读取信息延伸到调用系统、运行代码和保存长期任务。从这些方案可以判断，大型科技公司争夺的工作入口，已经延伸到数据访问、任务运行和费用管理；用户能托付多少工作，取决于这些环节能否一起受控。Google把模型选择与智能体层分开，也说明模型可以更换，而工作上下文和管理关系仍留在平台中。企业选择入口时，因而需要把可验收的成果、管理员能够实施的权限，以及可承担的运行费用一并纳入决定。智能体能接下多少任务，最终要落实到这套可执行、可核查的委派关系里。