Google Cloud 的 Gemini Agent：想成为每位员工的常驻数字同事

2026 年 10 月 8 日，Google Cloud 在 Gemini at Work 2026 上发布了 Gemini agent，官方称其为「面向工作的单一通用 Agent」。按官方博客的说法，工作从此从「提示窗口」开始：Agent 掌握组织的业务上下文，从知识工作、答疑、内容创作到写代码，都在同一个提示框里发起；它自己规划工作、调用技能与工具、连上企业的业务系统，然后把「做好的东西」送进你原本就在用的文档、收件箱和开发环境里；它还会自己挑选最合适的模型，自带成本控制，并具备企业客户要求的安全、管理与治理能力。

Gemini agent 的目标是把「一整件事」交出去，而不是一次一个提示

从「助手集合」到「一个 Agent」

Google 过去几年在卖一堆助手：写邮件的、做表格的、写代码的，各管一摊。这次的赌注不同——把员工从「管理多个 Agent」里解放出来，改成「委派一个目标」。你告诉它要做成什么，它自己搞清楚怎么做、去哪个系统拿数据、最后交回成品。这个转向听起来只是交互变化，其实是架构变化：一旦 Agent 要为结果负责，它就必须有自己的身份、记忆和权限边界，而不是寄生在某个人类的会话里。

# A coworker agent is not a chatbot session. It is an identity that
# gets provisioned like a new hire: account, mailbox, calendar, storage.
agent_spec:
  name: event-planner-agent
  mode: coworker            # vs. "personal assistant"
  identity:
    workspace_account: [email protected]
    mailbox: [email protected]
    calendar: shared            # bookable by humans
    drive: /Shared/Events
    directory_listing: true
  attestation: cryptographic   # every action is attributable
  surfaces: [web, ios, android, windows, mac, cli, chat, m365, slack]
  approvals:
    - create_calendar_event     # auto
    - spend_money: human_approve
    - contact_external: human_approve

四类记忆，而不是一个「上下文」

真正有工程含量的是记忆架构。Google 把它拆成四类：会话记忆负责手上这件事的状态；语义记忆沉淀关于公司与领域的知识；流程记忆是学到的、可回放的工作流；情景记忆记录上一次做过什么、结果如何。拆开的意义在于，「记住一切」根本不是设计——一个只进不出的上下文字典，最后会变成没人能维护的垃圾抽屉，既拖慢推理，也稀释真正有用的信息。

# You hand over an objective, not a sequence of steps. The agent
# keeps working across days; execution lives in the cloud, so you
# can start on a laptop and pick it up from a phone.
from time import sleep

def delegate(agent, objective, deadline_hint=None):
    run = agent.start(
        objective=objective,
        # agents can only read what a team explicitly shares with them
        data_scope="team_shared_only",
        spend_cap_usd=250,
        notify=["slack://#events", "mailto:[email protected]"],
    )
    while not run.done:
        # long-running work: poll, do not block a request thread
        print(run.status, run.current_step)
        sleep(60)
    return run.artifacts      # docs, slides, PRs, tickets

四类记忆：会话、语义、流程、情景

同事型 Agent 的身份从哪来

VentureBeat 点出的关键细节是：这类 Agent 会在组织现有的生产力基础设施里拥有自己的身份——专属邮箱、日历、Drive 与目录条目，员工可以在 Google Chat 里 @ 它、让它改文档。更重要的是一条边界：同事型 Agent 只能访问团队成员明确共享给它的信息，而不是继承某个真人的整套权限。对要接触财务记录、客户数据库、法务文件的组织来说，这条边界决定了项目能不能过安全评审。这条边界有很实际的后果。面向单个员工的个人助手，天然继承了一条已经存在的问责链：有主管、有考核周期、有离职流程。而一个部门级的同事型 Agent 默认什么都没有——这正是「开通方式与授权」比看上去更重要的原因。如果你说不出这个 Agent 归谁所有、谁复核它的产出、项目结束时它的邮箱怎么处理，那你就不是招了一个同事，而是部署了一个没人负责、却有写入权限的服务账号。

# The memory architecture is the interesting engineering choice.
# Four stores, because 'remember everything' is not a design.
MEMORY = {
    "session":    "state for the task in flight; discard on completion",
    "semantic":   "accumulated facts about the company and domain",
    "procedural": "learned workflows the agent can replay",
    "episodic":   "what happened last time, and what came of it",
}

def recall(agent, task):
    ctx = agent.memory.semantic.search(task.topic)
    ctx += agent.memory.procedural.match(task.intent)   # repeatable recipes
    ctx += agent.memory.episodic.recent(task.domain)     # prior attempts
    return ctx

# Splitting these is what stops 'context' from becoming a junk drawer
# that grows forever and helps nobody.

策略必须收在网关，而不是散在各处

Google 的治理设计有三层：每个 Agent 有密码学可验证的身份；动作全部进审计日志，包括它创建隔离环境执行代码的时刻；Agent Gateway 在 Agent 与外部系统之间执行全组织策略，代码执行另加沙箱。这套结构的逻辑和 Uber 的 MCP 网关一致——治理收敛到一处，才能回答「谁允许调用什么」这个唯一答案，而不是五十个团队各自即兴发挥。

# An Agent Gateway enforces organisation-wide policy on every
# outbound call. Sandboxing bounds what generated code can touch.
agent_gateway:
  default: deny
  rules:
    - { from: "*",            to: "internal.registry",   allow: true }
    - { from: "coworker-*",   to: "salesforce",          allow: true, scope: "read" }
    - { from: "coworker-*",   to: "github",              allow: true, scope: "pull_request" }
    - { from: "coworker-*",   to: "public_internet",     allow: human_approve }
  budgets:
    project_spend_cap: true          # pause the agent when exhausted
    attribute_costs_to: department
  code_execution:
    sandbox: true
    record_isolated_envs_in_audit_log: true

代码执行被放进沙箱，动作记入审计日志

模型可换、成本可控，才是能落地的前提

架构上还有两个细节值得注意。其一，模型是可替换的：Google 提供自家 Gemini 模型，据 VentureBeat 报道该 Agent 已可使用 Anthropic 的 Claude，更多专有与开源权重模型也在计划中。其二，配套的智能路由按性能与成本为每个工作负载挑模型，加上项目级支出上限——预算耗尽时可暂停 Agent 活动——以及把成本归属到具体部门。对企业来说，这两点往往比模型排行榜更能决定项目生死。把竞争背景摆进来，就能看清这次发布的时间点。微软在 9 月 25 日推出了更新版 Copilot，把生产力工作、软件开发与持续自动化放在一起；OpenAI 在 9 月 29 日的 DevDay 上推出常驻的 dots agents；Anthropic 在 10 月 6 日宣布 Claude 与 Google Docs、Sheets、Slides 的原生集成；而 SpaceXAI 于 8 月 11 日发布、自带云电脑的 Grok Bot，是结构上最接近的同类产品。它们的下注方向完全一致：助手不再是聊天机器人，而是长期在线的数字工作者。真正的差别在于——身份住在哪里，以及由谁来治理它。

# Smart routing picks the model per workload instead of pinning one
# model for the whole platform - cheaper models for cheap steps.
ROUTING = {
    "summarise_email":  {"model": "small", "why": "high volume, low stakes"},
    "write_pr":         {"model": "frontier", "why": "needs real reasoning"},
    "draft_contract":   {"model": "frontier", "why": "consequential output"},
    "extract_fields":   {"model": "cheap", "why": "verifiable output"},
}

def plan(agent, objective):
    steps = agent.decompose(objective)
    # complex work can fan out to temporary, specialised sub-agents
    if len(steps) > 5:
        return agent.spawn_subagents(steps, ttl="run")
    return steps

# The open question Google did not answer: pricing, GA date, and
# whether every capability lands in existing Gemini Enterprise plans.

还有哪些没有答案

官方给出的采用数据很亮眼：近九成《财富》100 强公司在用 Gemini Enterprise，BNP Paribas 向 6.5 万余名员工部署，日本 SOMPO 自建了一万多个自定义 Agent。但这些并不等于新通用 Agent 的采用。悬而未决的问题同样明确：单独定价未知、是否包含在现有订阅未知、正式可用时间表未知、管理员能否逐项开关 Agent 的 Workspace 存在感未知。如果你在评估它，先把这几项写进采购问题清单。