Gemini Agent 与 Coworker：企业级 Agent 为什么需要独立身份、持久任务和策略网关

2026 年 10 月 8 日，Google Cloud 在 Gemini at Work 宣布面向工作的统一 Gemini Agent。重点并非推出更大模型，而是把执行运行时、跨应用上下文、技能与工具分发、独立身份、模型调度和治理连接成产品体系。本文以 Google 官方发布及 Agent Platform 文档为依据，解析其架构价值与可复用边界。

1. 从“会回答问题”到“作为团队成员完成工作”

传统 AI 助手的运行单位通常是一次对话：用户提问、模型生成结果、会话结束。跨应用任务则不一样。例如，让一名运营 Agent 定期整理销售数据、在团队文档里更新报告，并按授权向同事同步结果：它需要记住已做过的工作、访问多个系统、处理持续数天的执行，还必须证明“谁做了什么、是否有权限”。

Google 提出的 Gemini Agent 让工作从一个入口发起，但不被一个对话界面束缚：可在浏览器、移动设备、桌面、Workspace、Microsoft 365、Slack、CLI 等入口接收任务，持续在云端执行。官方将其描述为统一的工作 Agent，而底层模型可以更换。

这里的核心变化是：Agent 作为“长期存在的工作主体”，不再等同于一个 LLM 调用或聊天窗口。

flowchart TB U["Web / Mobile / Workspace / Slack / CLI"] --> O["Unified Agent Orchestrator"] O --> T["持久 Task / Session / Execution 状态"] O --> M["Context & Memory"] O --> S["Skills Registry"] O --> R["Tools / MCP Registry"] O --> L["Smart Model Routing"] O --> W["临时 Subagents / 持久 Coworkers"] W --> G["Identity + Gateway Policy"] R --> G G --> X["企业系统 / API / MCP Server"] W --> B["Sandbox：代码与文件操作"] X --> A["Audit Trail / 结果 / 回写"] B --> A A --> T

分层	Google 公布的能力	工程层真正要回答的问题
Orchestrator	统一入口、计划任务、动态分派 Subagents	任务如何恢复、重试、取消与避免重复副作用
Models	当前可跨 Gemini 和 Claude 调度	哪类任务用何模型，效果与成本如何权衡
Skills	内置、团队和个人技能，可注册复用	Skill 版本、信任来源、权限和执行条件如何治理
Tools	连接企业应用、MCP、企业工具目录	每个工具如何鉴权、审计和限制出站访问
Context	跨设备和应用共享上下文、持久记忆	记忆来自哪里，如何纠错、过期和隔离
Runtime	云端长期执行、动态 Subagents 与持久 Coworkers	状态机、检查点、超时、异步结果怎样处理
Governance	独立身份、Policy、Sandbox、Gateway	如何将模型意图转成可验证、可拒绝的动作

上图是根据官方公开能力整理的逻辑架构，并非 Google 未公开的内部微服务实现图。

四种 Memory：解决四个不同的复用问题

官方把上下文划分为四类：

Session memory：当前长任务的上下文，跨小时或数天保持。
Semantic memory：从文档、系统与协作中形成的结构化知识。
Procedural memory：任务操作方法，包含 Agent 自己生成或更新的 Skills。
Episodic memory：过去做过什么、在哪个场景做过的事件记忆。

这一划分的意义在于，事实、操作规程与历史经历不应混成一段永久追加的 Prompt。在通用实现里，它们应有不同写入条件、检索方式和过期策略。尤其是 Procedural memory：模型“学会某个流程”，不等于这个流程自动获得更高权限。

3. 临时 Subagent 与 Coworker Agent 不是一回事

Google 区分两类“协作主体”：

维度	动态 Subagent	Coworker Agent
生命周期	围绕某次任务临时创建	面向长期角色与多次任务持续存在
工作范围	某一步的搜索、分析、编码等	项目协调、资料维护、跨部门协作等
状态	主要依附一次任务的上下文	需要自己的持久上下文、职责和历史
身份	可具有任务级 Agent Identity	可拥有独立 Workspace 账号、邮箱、日历、Drive 等
授权	应限制在分派任务所需范围内	团队按照共享关系与角色持续授权

官方示例里，Coworker 可以加入 Chat 群组、被 @mention，在文档评论中提出编辑，以自身身份留下历史记录。重要点是它以独立身份行动，只能接触团队赋予它的内容，而不是默认继承创建者全部权限。

flowchart TB U["团队提出工作目标"] --> P["持久 Coworker<br/>独立身份与角色"] P --> A["动态创建 Subagent A<br/>检索资料"] P --> B["动态创建 Subagent B<br/>整理方案"] A --> P B --> P P --> C{"工具调用授权检查"} C -->|允许| D["写文档 / 发消息 / 更新记录"] C -->|敏感动作| E["请求审批 / 拒绝"] D --> F["可审计的任务结果"]

这个区别比“Multi-agent 有几个模型并行”更本质：工作身份的生命周期与单次推理任务的生命周期不同。

4. 真正的基础设施突破：身份与授权进入执行链路

Agent Identity：给非人工作主体可审计的身份

Google Agent Platform 文档公开了 SPIFFE-based Agent Identity：每个 Agent 使用与其运行环境绑定的身份和证书；对 Google Cloud 可以使用证书绑定的访问凭据；访问外部系统则依目标使用 OAuth、OIDC、API Key 等受控认证方式。

必须区分两种权力来源：

Agent 自身权力：例如团队授予“读取共享项目报告”的权限。
用户委托权力：例如经用户 OAuth 同意后访问其私人日历。

独立身份不意味着可以绕过用户资源 ACL，也不意味着所有 SaaS 都原生支持 Agent Principal；企业外部系统往往仍需要 OAuth token、服务端代理或特定应用账号。Google 的 Auth Manager 正是用于管理这些不同的凭据与委托关系。

Gateway：权限控制不能只靠 Prompt

Google 官方将 Agent Gateway 放在客户端、Agent、其他 Agent、MCP 和外部 API 之间，用于流量与策略实施。其关键概念包括：

Agent Registry：已批准的目标、工具、MCP 和 Agent 目录。
IAM / Principal Access Boundary：把 Agent 身份映射到允许访问的资源，未明确授权的出站目标默认拒绝。
Model Armor / Semantic Governance：检查输入、工具内容与动作意图；自然语言策略可约束复杂业务行为。
Agent Sandbox：把代码执行与普通业务系统隔离，施加网络边界。

根据 Agent Gateway 文档，出站检查使用 IAP、SPIFFE 身份与 mTLS / DPoP 等机制。这些是 Agent Platform 公开的安全组件，不应据此推断每个 Gemini Agent 产品入口都已经以相同配置全面启用。

特别要注意：Semantic Governance 当前标记为 Preview，官方也明确提示 LLM 策略判断可能出错，建议先以 Dry Run 观察，再切到 Enforce。因此高风险动作必须叠加确定性 IAM、金额限额、审批与幂等检查，不能只依赖自然语言裁判。

5. 模型选择与成本：Harness 负责调度，而非绑定模型品牌

Google 公开描述的设计是“Gemini 作为 Agent，模型作为可替换底层”：目前宣称支持 Gemini 系列和 Claude，未来扩展其他模型；Smart Routing 将任务送往适合的模型，项目级实时支出上限触发后，Agent 可以暂停等待恢复。

其工程意义是：

将任务身份、上下文、Tools、Skills与模型供应商的上下文格式解耦。
简单任务可选廉价模型，复杂规划、长上下文或代码审查用更强模型。
预算需要进入状态机：到达支出阈值不应让流程“半完成、无记录”，而应保存 Checkpoint，并在恢复时检测幂等键、重新核验授权与外部副作用。

Google 未公开 Smart Routing 的详细实现、通用基准或跨模型切换的每一步内部协议；不应把以上工程原则误写成官方已公开算法。

6. 如何借鉴：一个可实现的最小 Cowork Runtime

无需等待 Gemini Agent 完整开放，就可以在现有全栈系统中验证同类设计：

flowchart TB A["用户 / Webhook / 定时任务"] --> B["Task API + Durable Queue"] B --> C["Orchestrator / Model Router"] C --> D["Scoped Skills + Tool Registry"] D --> E{"Policy Gate"} E -->|Read| F["只读工具调用"] E -->|Write| G["授权 / 审批 / Idempotency"] F --> H["Execution Ledger + Event Log"] G --> H H --> I["Checkpoint / Resume / Audit"] I --> J["Web / App / IM 状态同步"]

P0：跑通执行骨架。 最少建立 Task、Run、Step、Artifact、CredentialGrant、Approval 六种对象；Task 生命周期为 queued → running → waiting_approval / paused → completed / failed。所有工具调用绑定 agent_id、acting_user、scope、request_id 和 idempotency_key。

P1：让跨端与跨模型真正无关。 统一任务状态存服务器数据库；Web/移动端只负责订阅事件或读取快照，不让浏览器 localStorage 变成长期任务事实来源。引入模型适配、Skills 版本号、Tool schema 注册表，并为执行结果建立 Replay/Eval。

P2：使团队协作可治理。 为持久 Coworker 建立独立身份与最小权限；写操作需要人类确认或有界的自动授权。增加审计检索、密钥轮换、租户隔离、策略 Dry Run 和费用预算。对文件/代码类任务使用隔离 Sandbox。

建议先从一个具体角色验证，例如“每天分析客户工单、草拟处理建议、等待授权后更新 CRM”。比直接构造“万能 Agent”更容易验证权限、成功率、人工接管和业务价值。

7. 公开信息的边界与待验证假设

公开事实	尚需验证
2026-10-08 宣布统一 Gemini Agent、Coworker、跨入口持久执行	大规模真实任务成功率、异常恢复机制
官方宣称 Gemini / Claude 的模型选择、Smart Routing	模型选择算法、详细质量/费用对照
Google Agent Platform 提供 Identity、Registry、Gateway、安全文档	新 Gemini Agent 各入口实际开放的组件与配置范围
独立 Workspace Coworker 与长期记忆是公开产品方向	普遍可用时间、完整 API、价格及租户管理细节

截至此次发布，公开报道将新 Gemini Agent 描述为企业 Private Preview；不是已向所有开发者 GA 的通用开源 Harness。不能把营销演示视为完整、可复现的系统论文。

结论

Gemini at Work 2026 的最强信号是：企业 Agent 的核心资产逐渐从“选择哪个模型”，转向长期任务状态、组织上下文、可复用技能、独立身份和可强制执行的策略。真正可迁移的架构不是某个 Prompt 或产品界面，而是让 Agent 作为受治理的执行主体，跨模型、工具、设备和工作日持续完成任务。

主要一手资料

暂无英文版本