Gemini Agent 统一工作架构

Gemini Agent：统一工作入口、持久执行与多 Agent 协作

作者
DeepSeekAgent.io 编辑部
发布
更新

Google Cloud 在 2026 年 10 月 8 日发布 Gemini Agent，将问答、知识工作、内容创作和代码执行收进同一个工作 Agent。用户不再需要先判断该打开哪个应用、选择哪种模型或编排哪条工作流，而是直接交付目标；Gemini Agent 负责规划任务、选择 Skills 与工具、连接企业系统，并返回完成后的文档、邮件、分析结果或代码。

这次发布最重要的变化不是又增加一个聊天入口，而是把模型、Agent、工具和运行环境拆成不同层。Gemini Agent 可以在任务执行时选择不同模型，动态创建 Sub-agent，在云端持续运行，并在 Gmail、Drive、Docs、Slides、Sheets、Chat、Calendar、Slack、Microsoft 365、命令行和第三方应用中保持同一份上下文。

一个 Agent，覆盖问答、办公与代码执行

Gemini Agent 的入口可以出现在网页、移动端、Windows、macOS、Google Workspace、Microsoft 365、Slack 和命令行中，也能以 Headless Agent 接入第三方应用。不同入口共享记忆、Skills、权限和控制策略，因此任务不会因为切换设备或应用重新开始。

Google 把它定义为“面向工作的统一 Agent”，能力包括：

  • 回答问题和检索组织知识；
  • 在 Docs、Sheets、Slides 和邮件中完成知识工作；
  • 生成图片与媒体；
  • 编写并运行代码；
  • 根据时间表或事件触发任务；
  • 连接 MCP Server、企业软件、数据库与桌面文件。

它不是把所有工作都塞进一次模型调用，而是把入口统一，把模型选择、工具调用和执行过程留给 Agent 层处理。

任务关掉电脑后仍然继续

Gemini Agent 运行在云端。需要数小时或数天的任务可以在用户关闭电脑后继续执行，之后从其他设备回来仍能看到原来的任务状态。它保留四类记忆：当前任务的 Session Memory、组织知识形成的 Semantic Memory、工作方法形成的 Procedural Memory，以及历史执行形成的 Episodic Memory。

这解决了长任务最常见的产品断点：本地进程、某个浏览器标签页或一次聊天结束后，Agent 不应丢失任务身份和已完成的工作。持久执行也提高了运行时要求——系统需要明确的任务状态、暂停与恢复、成本上限、权限边界和审计记录，而不只是让 Agent Loop 无限续轮。

临时 Sub-agent 与长期 Coworker Agent

Gemini Agent 可以为复杂任务动态创建临时 Sub-agent。每个 Sub-agent 有自己的身份和职责，主 Agent 按并行或串行关系协调它们，工作可以持续数小时或数天。

Google 同时引入了更长期的 Coworker Agent。它更像组织中的固定成员，拥有独立身份、@agents.company.com 邮箱、持久存储和受限上下文，可以被加入 Chat、文档评论和团队流程。它以自己的身份留下操作和版本记录，而不是借用某个员工的账号执行所有动作。

两种设计对应不同任务：临时 Sub-agent 适合一次性拆分和并行处理；Coworker Agent 适合长期角色、持续上下文与团队协作。此前的 Agent Harness 组件消融也显示，明确职责的任务型 Sub-agent 能提升结果，而没有边界的通用委派会增加调用和上下文成本。Gemini Agent 把这种任务边界进一步落实到身份、存储和权限上。

Agent 与模型正式分离

Gemini Agent 不等于固定使用某一个 Gemini 模型。Google 明确把 Agent 与底层模型分开：系统目前可以在 Gemini 系列和 Anthropic Claude 模型之间选择，未来还会加入其他私有或开放模型。Smart Routing 根据任务质量与成本选择模型，并允许一个大型项目组合多种模型。

这与模型—Harness 评测得出的结论一致：同一模型在不同 Harness 与任务中的结果可能大幅变化，同一 Harness 也不存在对所有模型和任务都最优的固定组合。Gemini Agent 选择把模型适配做成运行时能力，而不是让用户在任务开始前永久绑定一个模型。

真正值得观察的是路由层能否同时利用三类信号：

  1. 任务类型与难度；
  2. 模型在当前工具和 Harness 下的历史表现；
  3. 实时 Token、Sandbox 与执行成本。

如果只有“复杂任务用大模型、简单任务用小模型”，就还没有真正解决模型与 Harness 的匹配问题。

Skills、工具与上下文成为企业基础设施

Gemini Agent 提供工具注册表与 Skills 注册表。工具负责连接 Slack、Confluence、Git、Jira、Salesforce、ServiceNow、BigQuery、Postgres、Snowflake、MCP Server 和桌面文件；Skills 则以模块化说明、知识和工作流教 Agent 如何完成多步骤任务。

团队可以发布共享工具和 Skills，个人也可以创建自己的 Skills。Agent 在运行时选择所需能力，而不是把所有说明和工具定义放进每轮上下文。Google 还把身份、细粒度权限、审计、Agent Sandbox、Agent Gateway 和实时支出上限放到同一套治理层中。

因此，这次发布的竞争重点不只是“谁的模型更强”，而是谁能把上下文、工具、技能、身份、成本和审计组织成长期可运行的系统。

Gemini Agent 与 DeepSeek Harness 的位置不同

维度Gemini AgentDeepSeek Harness
产品形态Google Cloud 管理的企业工作 Agent可组合、可扩展的开源 Agent Harness
主要入口Workspace、Slack、Microsoft 365、Web、移动端、桌面与 CLIWeb UI、CLI、Desktop 与可扩展运行时
执行方式云端持久执行，跨设备保持任务本地或远程运行，可通过 Session 与插件扩展
多 Agent临时 Sub-agent 与长期 Coworker AgentSub-agent、Agent Teams 与 Profile 组合
模型策略Smart Routing，多模型运行时选择Provider、模型与 Profile 由用户配置
治理企业身份、权限、审计、网关与支出上限Review、Sandbox、插件权限与运行时策略

Gemini Agent 更接近一个已经连接企业数据和办公入口的托管工作系统；DSH 更接近允许开发者替换模型、Profile、插件与 Agent Loop 的 Harness。两者都在证明同一件事：Agent 的能力越来越由模型之外的运行时决定。

对 DSH 生态的启示

Gemini Agent 给 DSH 后续产品和内容留下了四个值得持续跟踪的方向：

  1. 持久任务不是无限循环。 长任务需要可恢复状态、清晰的停止条件、人工接管和预算上限。
  2. Sub-agent 必须有身份和职责。 任务型分工比无边界地增加 Agent 数量更有效。
  3. 模型路由要理解 Harness。 选择模型时需要考虑工具调用稳定性、错误恢复和任务成本，而不只是模型榜单。
  4. Skills 与工具需要注册、权限和审计。 能被发现只是第一步，谁能运行、能访问什么、产生多少成本同样重要。

Gemini Agent 把这些能力作为统一企业产品发布，DSH 则提供更开放的实验与组合空间。接下来真正有价值的比较，不是做功能清单，而是用相同任务测量完成率、执行时间、模型调用、Token、权限请求与失败恢复。

相关阅读

参考资料