在《手搓生产级 AI Agent 系统》系列中,我们已经讨论了Agent的规划、工具调用与运行时治理。本篇进入第27篇,结合Google Cloud在Gemini at Work 2026发布的Gemini agent,讨论企业级Agent的集成机制与落地启示。
官方事实:Gemini agent是什么
根据Google官方博客,Google Cloud在Gemini at Work 2026上宣布了Gemini agent,将其定义为"a universal agent for work"(面向工作的通用Agent)。官方给出的核心能力包括:
- 工作从prompt window开始:Gemini拥有组织的全部业务上下文,可用于知识工作、问答、内容创作到编码,全部在单一prompt box中完成。
- 它会规划工作、使用技能和工具、连接云客户的业务系统,并把完成的结果带回用户已经在使用的文档、收件箱和开发者环境中。
- 它会为任务选择最佳模型,具备内置成本控制,并且最重要的是具备企业客户所需的安全性、管理和治理能力。
官方同时指向Google Cloud博客获取更多信息。以上是资料明确支持的事实边界,下面进入工程分析。
集成机制:从"业务上下文"到"业务系统"
官方表述中有两个关键词值得拆开:business context(业务上下文)与business systems(业务系统)。前者决定Agent"知道什么",后者决定Agent"能做什么"。
在自建系统中,这两者通常对应两条不同的链路。业务上下文一般通过检索层注入:把CRM、ERP、工单、文档库中的结构化与非结构化数据做索引,在推理前按需召回。业务系统则通过工具层接入:每个可执行动作封装为一个带schema的工具,由Agent在规划阶段选择调用。
Gemini agent把这两条链路收敛到"单一prompt box",意味着产品层屏蔽了检索与工具编排的复杂度。对自建系统的启示是:不要把上下文注入和工具调用混在一个抽象里。上下文是只读的、可缓存的、可降级的;工具调用是有副作用的、需要幂等与审计的。二者混用会导致权限模型无法收敛。
技能与工具:规划与执行的分离
官方提到"plans the work, uses skills and tools"。这里隐含一个架构判断:规划与执行是分离的。规划产出的是任务分解与工具选择序列,执行负责实际调用。
在自建Agent中,这种分离带来两个工程收益。第一,规划结果可以被审查。高风险动作可以在执行前插入人工确认或策略校验。第二,执行可以被重试与补偿。工具调用失败时,规划层不需要重新推理,只需按既定序列重放或走补偿分支。
需要提醒的是,官方并未披露Gemini agent的规划器实现、工具协议或重试策略,因此上述属于通用工程建议,不是对该产品内部机制的描述。
模型选择与成本控制
官方明确提到"chooses the best model for the job"和"built-in cost controls"。这对应自建系统中的一个常见痛点:单一模型无法同时满足延迟、成本与质量。
工程上通常采用路由策略:按任务类型、输入长度、是否需要工具调用等特征,把请求分发到不同规格的模型。成本控制则需要在路由之上再加一层预算:按租户、按会话、按任务设置token上限,超限时降级或中断。官方把这两点作为产品能力列出,说明企业采购时它们已是硬性要求,而非优化项。
安全、管理与治理
官方把"security, administration, and governance"列为"most importantly"。这是企业Agent与个人Agent的分水岭。
在自建系统中,治理至少需要覆盖三层:身份层(Agent以谁的身份调用业务系统)、权限层(能访问哪些数据、能执行哪些动作)、审计层(每次规划与调用是否可追溯)。Gemini agent强调连接云客户的业务系统,意味着权限边界必须与客户既有IAM体系对齐,而不是另建一套。
对中国企业构建Agent的启示
第一,集成优先于模型。官方把业务上下文与业务系统连接放在能力列表前列,说明企业Agent的价值主要来自系统集成深度,而非模型本身。
第二,治理是准入条件。安全、管理、治理被官方列为最重要项,自建系统若在早期不设计权限与审计,后期改造成本极高。
第三,结果要回到用户已有的工作界面。官方强调把完成的结果带回文档、收件箱和开发者环境。Agent不应要求用户迁移到新界面,而应嵌入既有工作流。
第四,成本控制要内置。官方将其与模型选择并列,说明多模型路由加预算约束应作为运行时基础设施,而非事后优化。
小结
Gemini agent的官方信息给出了企业Agent的能力轮廓:业务上下文、技能与工具、业务系统连接、模型选择、成本控制、安全治理。对正在手搓生产级Agent系统的团队而言,这些点可以直接映射为架构模块。下一篇将继续沿系列主线,讨论运行时治理的具体实现。