谷歌云

10 月 8 日，谷歌云在 Gemini at Work 2026 发布会上正式推出 Gemini 智能体，定位「通用工作智能体」。按官方说法，用户只需要给一个目标，它就能在单一界面里完成问答、知识工作、内容创作、代码编写与运行，并能调用企业内部工具和第三方服务。这是谷歌云把智能体打包进企业订阅的关键一步。 为什么这次不一样 过去企业上 AI，要先做一道选择题：用 OpenAI 的模型还是 Anthropic 的，用微软 Copilot 还是谷歌 Gemini。谷歌这次的策略是把选择权收回平台——Gemini 智能体底层既可以调自家的 Gemini 系列，也可以调用 Anthropic 的 Claude 模型，未来还计划支持其他领先的私有与开源模型。对企业 CIO 来说，这意味着你不再需要为每个工作负载选模型，平台替你路由。 这种「模型无关」策略，本质是谷歌云在用 Workspace 的存量客户做杠杆。已经买了 Gemini Enterprise 或 Workspace 订阅的公司，不需要额外采购，就能让员工用上智能体。切换成本被压到最低。 商业化含义 对谷歌云，这一步的财报意义在于：智能体不是按 token 卖，而是按席位订阅卖。一个企业版席位每月几十到上百美元，不管你用多少 token。这把过去「用多少付多少」的用量风险，从用户身上转移到了平台身上——平台必须把单位推理成本压得足够低，才能在订阅制下保持毛利。 对竞品，这是直接挑战：微软 Copilot 也在走同样的路，但它绑定的是 OpenAI；谷歌同时接 Claude，等于在模型层给了企业「第二供应商」的安全感。在企业采购最忌讳单一供应商的今天，这一点很有杀伤力。 判断 2026 年下半年，企业 AI 采购正在从「买模型」转向「买智能体席位」。谷歌云这一步，等于宣告智能体不再是开发者玩具，而是和邮箱、文档一样的标准办公套件。谁能把智能体做进已有订阅里，谁就能吃到最大一波企业预算。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：谷歌云Gemini智能体

9 月底以来，各家大厂都在补「开发智能体」的官方工具链。谷歌这边对应的是 ADK（Agent Development Kit）：一套 Python 框架，配合云上的 Agent Engine，可以把本地调试好的智能体直接托管成一个带日志、可扩展的线上服务。相比自己在服务器上拼 Flask 加队列，这套组合把「造完 → 上线」的工程摩擦压到最低。 一条最小链路 本地用 pip install google-adk 装套件，然后按它的原语组织代码：一个 Agent 带 instruction，挂上 tools，可以嵌套子 Agent。本地调试时用 adk run 你的agent 在命令行里对话，快速改提示词。 调通之后，用 adk deploy agent_engine 把它推到谷歌云的 Agent Engine，平台会分配一个 HTTP 端点，自动带上会话持久化与调用日志。后续要改提示词，本地改完再部署，不用碰服务器。 两个设计要点 工具即函数：ADK 里一个 Python 函数加装饰器就是一个工具，模型自动获得调用它的能力。把读数据库、调内部 API 的动作封装成函数，比手写 JSON Schema 直观得多。 可观测先于优化：部署后先在 Agent Engine 控制台看每一步的轨迹——模型调了哪个工具、花了多少 token、在哪一步卡住。没有轨迹就谈优化，都是猜。 判断 框架之争的下半场，比的不是谁的抽象更优雅，而是谁把「本地 → 托管 → 观测」的链路做顺。ADK 加 Agent Engine 的组合，对已经在谷歌云上的团队是顺理成章的选择；跨云团队则可以把它当一个参照系，去衡量其他框架的托管体验。 补一个省钱细节：本地调试时用便宜模型快速迭代，部署到 Agent Engine 后再切到 Gemini 旗舰模型做正式推理。因为代码与模型解耦，这个切换只改一行配置，不用重写逻辑。另外，把成本敏感的工具调用加上缓存——读同一份配置文件，别让 Agent 每次都重复读、重复计费。 ...

10 月 8 日，谷歌云在 Gemini at Work 2026 上推出「Gemini 智能体」：一个统一界面里同时处理问答、知识工作、内容创作与代码。这标志着企业 AI 从「侧边栏补全」正式进到「派一个智能体去干活」。对管理员来说，新问题不是「接不接」，而是「怎么发、发给谁、能碰什么数据」。 开启的三个关键决策 第一，范围先窄后宽。不要第一天就给全员开放全部知识源。先选一个高频部门（如市场或客服）做试点，让智能体只读指定的 Drive 文件夹与 Confluence 空间，验证回答质量再扩。 第二，知识源要白名单制。Gemini 智能体能挂企业知识，但默认绝不能让它扫整个 Drive。按团队挂目录，敏感合同、财务报表先排除在外。 第三，保留人工出口。智能体起草的邮件、文档默认走「建议」而非「自动发送」。让它完成初稿，人来按发送，这个边界在试点期别动。 日常落地的两个抓手 用它做「会议纪要 → 待办分派」闭环：会后让智能体从录音与文档里抽行动项，自动写进任务表； 用它做内部知识问答，把最常被问的二十个问题写成示例，测它的回答是否跑偏，再据此补知识库。 判断 企业智能体的落地，技术难度已经让位给组织难度。谷歌把界面做进全员工作台，等于把选择推给了每一个管理者：你到底愿意让智能体看到多少内部信息。试点跑稳之前，宁可保守——智能体越能干，权限收敛就越值得多花一周。 再提醒一个组织细节：智能体发出去之后，要指定一个「知识管理员」定期清理过期文档。知识库越积越旧，智能体会一本正经地引用已作废的流程。每月让管理员过一遍挂载目录，比事后向业务解释「为什么它说错了」划算得多，也比事后救火省精力。 智能体落地，七分靠组织，三分靠技术。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Gemini智能体

Reco 发现某财富 100 客户内部有 2.1 万个无人认领的智能体，Gartner 预测 2028 年财富 500 强平均在用智能体将超 15 万个。面对这种蔓延，技术侧的应对正在成形：谷歌云在其 Agent 平台上规划了一整套组件——Agent Studio、Agent-to-Agent Orchestration、Agent Registry、Agent Identity、Agent Gateway、Agent Observability。这组名字连起来读，其实就是在给智能体社会建立「户籍制度」。 为什么先要身份证 治理混乱的根，是你不知道有哪些智能体存在、它们是谁、能干什么。Reco 扫描出 2.1 万个影子智能体，靠的是事后发现；更理想的做法是事前登记。 Agent Registry 就是这个登记处：每个智能体创建时先注册，有名字、有归属、有能力描述。Agent Identity 则是它的身份证：每个智能体有独立身份凭证，调什么系统、持什么权限，都绑定在这个身份上。 这组组件在搭什么 从前沿视角看，这不是单点功能，而是一整条治理链路： Registry（登记）：解决「有哪些智能体」——清点家底。 Identity（身份）：解决「它是谁」——给每个智能体发独立凭证。 Gateway（网关）：解决「它能碰什么」——所有外部调用过统一网关做权限校验。 Observability（可观测）：解决「它干了什么」——全链路追踪，出问题可回溯。 把这四件事拼起来，恰好对应责任三要素：可追溯、有归属、能问责。 判断 智能体蔓延不会靠写禁令解决，只能靠给每个智能体一个可查的身份、一条可审的链路。谷歌云这套组件代表的方向是：让治理变成基础设施，而不是事后救火。 Reco 的 context graph 思路也值得对照——它把智能体、应用、账号、人员与权限连成一张关系网，本质上是在给蔓延的智能体做「关系图谱」。有了这张图，企业才知道哪个智能体在替哪个员工、用哪份权限、访问哪个系统做事。这比单纯清点数量重要得多，因为治理的难点从来不是数清，而是理清关系。 但要清醒，技术底座铺得再全，如果组织不愿给每个智能体指定真实的人类所有者，身份证也可能变成一堆无人认领的户口。工具只能登记责任，不能代替人承担责任。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：智能体身份登记

当地时间 10 月 8 日，谷歌云在「Gemini at Work 2026」推出 Gemini 通用工作智能体。按官方博客描述，它从单一提示框出发，掌握组织全部业务上下文，自主规划工作、调用技能与工具、连接企业业务系统，最后把完成品直接送回文档、收件箱与开发环境；它会自选最优模型、内置成本控制与企业级安全。技术圈关心的不是它又一个 Agent，而是它选了一条和垂直 Agent 截然不同的架构路线。 两条路线的分野 过去一年主流的 Agent 路线是垂直的：做客服就专门搭一个客服 Agent，做代码就专门搞一个编码 Agent，每个场景独立工作流、独立工具集、独立微调。Manus 这类产品也走专精框架路线。 谷歌这次押的是另一条：一个通用根智能体，内部再按任务动态编排。你不指定用哪个 Agent，只给目标，它自己判断该调什么技能、连什么系统、用哪个模型。 通用路线的技术含义 从前沿拆解，这条路押注三件事： 强根模型：通用编排靠一个理解能力极强的底座模型来做「总指挥」，而不是靠人工写死流程。 上下文即业务：它不重新接一套数据，而是直接吃企业完整业务上下文，让规划基于真实业务状态。 模型路由：同一个任务里，简单步骤走便宜模型，难步骤走贵模型，系统自动调度。 代价也很明显：通用路线对根模型能力、上下文工程、企业系统打通的要求极高，一旦根模型判断失误，整链都会偏。 判断 这场「通用根智能体 vs 垂直专精 Agent」的路线之争，本质是在赌一件事：未来的工作入口，是收敛成一个万能框，还是拆成无数专用工具。谷歌用 10 月 8 日的发布投了前者一票。这条路能不能成，取决于根模型的编排能力是否真的够用——接下来半年的真实部署案例，会给答案。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：通用智能体与架构

当地时间 10 月 8 日，谷歌云在「Gemini at Work 2026」大会上发布 Gemini 通用工作智能体。按官方博客的说法，它从一个统一的提示框出发，拥有组织的全部业务上下文，自己规划工作、调用技能与工具、连接企业内部系统，最后把成品直接送回你已经在用的文档、收件箱与开发环境里。它还会自己为任务选最合适的模型，并内置成本控制。换句话说，过去你在十几个软件之间切换的那串动作，被压进了一句话。 注意力曾经是我们最稀缺的认知主权 人的注意力是串行的，这是进化给大脑的硬约束：你没法同时深度思考两件事。过去几十年，我们用多窗口、标签页、看板来对抗这个约束，结果只是把自己切成了碎片。注意力分配——先做什么、后做什么、什么时候切换——被普遍认为是人类最后的认知主权之一。 单一提示框智能体做的事，恰恰是把这层主权也接过去。你只给目标，它负责在内部决定先查知识库、再写初稿、再跑一段代码验证。你不再需要为「下一步用哪个工具」分心，因为工具的编排被内化进了智能体。 外包的连续性 这其实是一种「外包的连续性」。过去你靠自己在脑子里维持一条工作流的连贯性，现在这条连贯性外置到了智能体那里。好处显而易见：碎片时间被缝合，切换成本趋近于零。 但代价也值得记下来： 当你不再经手每一步，你对任务的「手感」会退化。 当选择最优模型、控制成本都由系统代劳，你对「思考值多少钱」会逐渐失去直觉。 最危险的是，你可能忘了这条工作流原本是可以由自己设计的。 结论 单一入口不是终点而是信号：注意力这层最后的认知主权，也开始进入外包周期。会用它的人把它当放大镜，不会用的人把它当拐杖——区别只在于，你还记不记得自己原本会走路。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：单一提示框与注意力

10 月 8 日，谷歌云在 Gemini at Work 2026 发布会上正式推出 Gemini 智能体，定位「面向工作的通用智能体」。按谷歌官方博客的说法，工作从此在一个提示框里开始：它握有整个组织的业务上下文，从问答、知识工作到内容创作、写代码跑代码，都在单一界面完成，还能调用企业内部工具。最值得玩味的一点——它不只调用自家 Gemini 系列，还能调用 Anthropic 的 Claude 模型，未来接入更多第三方与开源模型。 它和以前的「企业聊天框」差在哪 过去的企业 AI 助手是问答机：你问一句，它答一句，事情到这儿就结束。Gemini 智能体的卖点是「给目标，不给步骤」。它自己规划工作、调用技能、跨 Gmail、Drive、Docs、Sheets、Slides、Chat、Calendar 串起多步任务，还能创建有独立身份和权限的「同事代理」，长期跑任务、再由多个子代理协同处理复杂工作。 换句话说，谷歌把 Agent 的颗粒度从「一个机器人」细化成「一支有身份、有权限、可委派的小分队」。这与企业 IT 最在意的审计、权限边界直接挂钩。 为什么敢同时调用 Claude 谷歌敢在自家智能体里接 Claude，背后是一个现实判断：企业要的不是某个最强模型，而是「这件事交给谁最稳」。推理用 Claude Opus 级、长上下文用 Gemini、代码再换一个后端——模型路由正在成为企业 Agent 的标配，而不是叛徒行为。 这也解释了为什么谷歌同步在 Gemini API 里推托管智能体公开预览：让开发者在托管的 Linux 沙箱里跑有状态智能体，自己不用搭虚拟机。 对企业 IT 而言，这种「同事代理」最大的吸引力，是它把权限与审计内嵌进了产品，而不是事后打补丁。这正是微软、OpenAI 们都在抢的同一套叙事。 判断 这一步的本质，是云厂商从「卖模型调用」转向「卖工作结果」。对企业买家来说，问题不再是接哪家 API，而是哪家的智能体能真正碰我的数据、走我的流程、还能被我审计。谷歌、OpenAI、Anthropic 三家这周几乎同时 all-in 工作智能体，入口之争已经没有退路。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Gemini智能体