Anthropic 托管的 Claude 平台登陆 Google Cloud：完整功能与谷歌账单一并拿下

到底变了什么

Anthropic 在 2026 年 10 月 22 日宣布，Claude Models on Google Cloud（Anthropic managed）正式全面可用（GA）。一句话概括这次变化：Google Cloud 的客户现在可以直接拿到完整的 Claude Platform，而不必等 Google 把新功能逐一集成进自己的托管版本。Google Cloud 次日（10 月 23 日）也在官方博客确认了同一件事：Anthropic managed 部署选项 GA，与已有的 Google managed 选项并存。

关键在于，这不是又上架了一个新模型，而是一次“部署方式”的补齐。两个选项提供的模型是同一批前沿模型——Anthropic 列出的是 Claude Fable 5.1、Opus 5.5、Sonnet 5.5 和 Haiku 5.5，并承诺新模型上线时同步出现在 Anthropic managed 选项中。真正的区别不在模型本身，而在谁运营服务、谁是数据处理者、新功能何时到手，以及你签的是谁的条款。

对已经在 Google Cloud 上跑业务的团队来说，另一个实际意义是账单没有分裂：Anthropic 的说法是沿用现有的 Google Cloud IAM 凭证，账单走同一张 Google Cloud 发票，Claude 的用量可以抵扣已有的 Google Cloud 承诺额度。Google 的博客也用了同样的表述：统一账单、承诺额度可抵扣。这意味着团队不需要为了用上完整的 Claude Platform 就另起一套采购和权限体系，至少在 Anthropic 和 Google 各自的公告口径里是这样。

两条路线，一张对照表

Google Cloud 上现在有两条用 Claude 的路。下表综合了 Anthropic 公告与 Google Cloud 博客的说法，两边口径一致的地方可以放心看，不一致或只提了一边的地方，本文在表后单独说明。

维度	Anthropic managed（新 GA）	Google managed（已有选项）
运营方与数据处理者	Anthropic 运营服务，Anthropic 是数据处理者	Google Cloud 是数据处理者
适用条款	Anthropic 的商业条款	已有的 Google Cloud 客户协议
模型上线时间	新模型上线当天即有	新模型上线当天即有
平台新功能与 Beta	与原生 Claude Platform 同一天上线	等集成进 Google 托管基础设施后陆续上线
身份与权限	使用 Google Cloud IAM 凭证	Google Cloud 原生身份体系
账单与承诺额度	同一张 Google Cloud 发票，可抵扣符合条件的承诺额度	标准账单，可抵扣符合条件的承诺额度
审计与管控	保留 Cloud Audit Logging（据 Google 博客）	VPC Service Controls、客户自管加密密钥（CMEK）
数据驻留	目前提供美国（US）与全球（Global）端点	美国、欧盟、亚太的数据驻留选项
原生集成	以 Claude Platform 完整功能见长	Model Armor、Agent Engine、BigQuery 等 Google Cloud 原生集成

表里最容易被误读的一行是“模型上线时间”。Google 博客明确写了：两条路线都是新模型上线当天即有。也就是说，选 Google managed 并不会在模型本身上落后；落后的是模型之外的平台功能——Managed Agents、Skills、代码执行这类能力，以及未来的 Beta。反过来，选 Anthropic managed 也不是“更高级”，而是把数据处理者和合同方换成了 Anthropic。这是一个取舍，不是升级。

所谓“完整平台”，到底包括什么

Anthropic 公告列出的完整功能清单，比一句“API 全家桶”具体得多，值得按用途拆开看。

先是 Agent 能力。Claude Managed Agents（Beta）面向长时间运行的 Agent，卖点是不用自己管基础设施；Agent Skills 让团队把可重复的工作流教给 Claude，以求输出稳定一致；Advisor Strategy（Beta）则是让 Agent 在执行中咨询一个顾问模型，相当于给 Agent 加一层智能复核。Computer Use 允许 Claude 操作浏览器或桌面完成任务，这类能力在自动化场景里有用，但也意味着权限和审计要先想清楚，不能只看演示效果。

其次是连接外部系统与知识的能力。Files API 用于上传和跨对话引用文档；Citations 把回答锚定在源文档上；Web Search 与 Web Fetch 给模型补实时外部信息；MCP Connector（Beta）则是不写客户端代码就能把 Claude 接到其他工具上。对做企业内部助手、客服、研发辅助的团队来说，这一组往往比模型参数更决定落地成败——因为它决定了 Claude 能不能读到你自己的数据、以及回答有没有出处。

最后是成本与性能管理。Prompt Caching 降低重复上下文的成本和延迟；Batch Processing 面向大批量异步任务。Anthropic 还给了开发者环境 Claude Console：写提示词、配置 Agent、在托管环境里运行、监控用量和成本、按工作区管理访问与安全。这些过去是原生 Claude Platform 用户才有的完整体验，现在通过 Google Cloud 也能拿到，前提是你选的是 Anthropic managed 路线。

Fast Mode 与价格：只说厂商公布的数字

与 GA 同步的另一条消息是：Claude Opus 5.5 的 Fast Mode 也对 Anthropic managed 用户全面可用。按 Anthropic 的说法，Fast Mode 优先保证速度，输出 Token 生成速度最高可达 2.5 倍，适用场景是快速迭代、实时调试和对输出速度敏感的交互式 Agent。注意“最高可达”三个字——这是厂商说法，不是实测承诺，不同任务、不同负载下的实际加速会不一样。

价格方面，Anthropic 公告给出的数字同样是厂商口径：Opus 5.5 Fast Mode 的输入与输出 Token 价格分别为每百万 8 美元和 40 美元。本文没有在两篇一手公告里找到其他模型在这一选项下的完整价目表，也没有找到与标准模式的逐项价差表。如果你要据此做预算，正确的做法是拿这个数字当起点，再去 Anthropic 的官方价目页核对你实际要用的模型与模式，而不是把这一组数字当成全部 Claude 模型的定价。

Google 博客的表述则更笼统：两条路线“同样的定价”。这句话的合理理解是，同一模型在两条路线下不因路线不同而改价，而不是说所有模型、所有模式都只有一个价。预算时仍以 Anthropic 的价目表为准，路线本身不是折扣项。

谁最适合选哪条路

如果你所在的团队已经在原生 Claude Platform 上用 Agents、Skills、代码执行这类能力，或者你的产品路线图依赖 Beta 功能第一时间可用，Anthropic managed 是更直接的选择：功能到达时间与原生平台一致，不用等集成排期。同样，如果你的工作流已经围绕 Claude Console、Files API、Citations 展开，换到这条路线后这些能力不需要降级或找替代品。

如果你所在的组织对数据处理者有硬性要求——合同、合规或客户承诺里写明了数据处理者必须是 Google Cloud，或者业务对数据驻留有严格的区域要求（例如必须落在欧盟或亚太），那 Google managed 仍是 Anthropic 自己推荐的选项。Anthropic 公告的原话是：需要 Google Cloud 作为数据处理者、有严格区域数据驻留要求、或想要 Model Armor、Agent Engine 这类原生集成的客户，继续选 Google managed。Google 博客也列出了同样的理由，并补充了 CMEK 和 VPC Service Controls。

还有一种常见情况：你现在已经在 Google managed 上跑着 Claude，模型本身用得挺好，只是不确定要不要换。这时决策点不应该只看功能清单，而要看你到底缺不缺那些“还没集成过来的平台功能”。如果缺的是某个 Beta 或某个平台能力，换路线有明确收益；如果缺的只是更新的模型，两条路线本来就同一天给，那就没必要为换而换。

切换之前，先核对这五件事

1. 折扣不要事后补。Anthropic 公告明确提醒：已有折扣的客户，在开始使用 Anthropic managed 选项之前，先联系 Anthropic 或 Google Cloud 的客户经理，确认折扣正确适用；折扣不能追溯适用到已经产生的用量。这句话没有例外表述，意思是先谈好再开用量，而不是先跑起来再去要折扣。
2. 合同方变了。Anthropic managed 走 Anthropic 的商业条款，Google managed 走已有的 Google Cloud 客户协议。如果你的法务或采购流程对合同主体、数据处理条款有审批要求，换路线之前要先过这一关，而不是让工程师先在控制台点开。
3. 数据处理者变了。同样一句话的另一面：数据处理者从 Google 变成 Anthropic。这对隐私评估、客户承诺、内部合规文档都有影响，需要更新的文档应当在切换前列出来，而不是切换后补。
4. 端点范围先确认。Anthropic 公告写的是目前提供美国与全球端点。如果你业务对区域有明确要求，对照 Google managed 的美国、欧盟、亚太驻留选项逐一核对，不要默认“全球端点”就等于“可以落在任何区域”。
5. 你依赖的原生集成还在不在。如果你现在的工作流依赖 Model Armor、Agent Engine、BigQuery 这类 Google Cloud 原生集成，换路线之前先确认这些集成在 Anthropic managed 下是否同样可用、以及以什么方式可用。两篇公告都没有给出“全部原生集成在新路线下逐一可用”的清单，这一点不能默认。

不要和另一篇 VibeFix 文章混淆

这里需要划一条边界。VibeFix 此前已经发布过一篇题为《OpenAI 模型上架 Google Cloud》的文章（slug 为 openai-models-google-cloud-model-garden-october-2026），讲的是 OpenAI 的模型进入 Google Cloud 的 Model Garden、Codex 也能走谷歌账单。那篇文章的主角是 OpenAI，产品是 GPT 系列模型，与本文完全不同。本文的主角是 Anthropic，产品是 Claude Platform 在 Google Cloud 上的 Anthropic managed 部署选项。两篇的共同点只有一个：都发生在 Google Cloud 这个平台上、都涉及“模型厂商 + 云厂商账单”的组合。除此之外，厂商、模型、部署选项、数据处理者安排都不一样，不能互相引用对方的事实。

这条边界之所以值得单独写，是因为两篇新闻在时间上挨得很近、标题结构也容易让人混淆。如果你是在搜索“Google Cloud 上有哪些大模型可用”时同时看到这两篇，记住区分厂商名字就够了：OpenAI 那篇看 Model Garden，Anthropic 这篇看 Claude Platform 的两条部署路线。

目前仍不清楚的事

坦白说，两篇一手公告都没有回答所有实际问题，以下几点本文无法从已打开的一手来源中确认，写出来是提醒读者不要脑补。

• 从 Google managed 迁移到 Anthropic managed 是否有原地切换路径。两篇公告只说了新选项 GA、以及各自适合谁，没有描述已有用户如何迁移、用量历史与配置是否保留、切换过程是否停机。
• 除 Opus 5.5 Fast Mode 之外的完整价目。如前所述，Anthropic 公告只给出了 Fast Mode 的一组价格，Google 博客只说了“同样的定价”，其他模型的完整价目需要查 Anthropic 的价目页，本文不代劳编造。
• 经销商或合作伙伴渠道的特殊条款。两篇已打开的一手公告里都没有提到经销商限制或渠道特殊条款。本文因此不写任何关于经销商的结论；如果你是通过合作伙伴采购 Google Cloud 的，采购条款仍需以你自己的合同为准。
• “全球端点”的具体覆盖范围。Anthropic 公告只写了美国与全球端点，没有展开全球端点包含哪些区域、以及区域选择对延迟与合规的具体影响。
• 新功能在 Google managed 下的集成排期。Google 博客只说了“集成后陆续上线”，没有给出具体功能的具体时间表。等某个具体功能的团队，应当以该功能后续的官方更新为准，而不是按本文的发布时间推算。

对日常开发工作的影响

对一线开发者来说，这次变化最直接的影响不是多了一个控制台入口，而是工作方式的统一。过去，一个团队如果既想用 Google Cloud 的身份体系和账单，又想用 Claude Platform 的全部能力，往往要在两套流程之间来回切换：权限在一边管，Agent 配置和用量监控在另一边看。现在 Anthropic managed 的说法是，身份继续留在 Google Cloud IAM 里，Agent 的开发、运行、监控则可以在 Claude Console 里完成，账单最终合并到同一张发票上。这种统一减少的是流程摩擦，而不是模型能力本身，评估时应当按流程收益来算，而不是按模型跑分来算。

具体到 Agent 开发，值得注意的组合是 Managed Agents、Skills 与代码执行的搭配。Managed Agents 解决的是长时间运行任务的基础设施负担，Skills 解决的是重复任务输出不稳定的问题，代码执行则让模型可以在一次调用内跑 Python、做可视化、分析数据。这三者拼在一起，覆盖的是“能持续跑、跑得稳、跑完能算数”这条链路。单独看任何一个都不新鲜，放在一起的意义在于，团队不需要再为每个环节各自找托管方案或写胶水代码。当然，这仍然不等于开箱即用：Skills 需要团队自己把工作流沉淀下来，代码执行的沙箱边界、数据访问权限、输出结果的校验流程，依然要按自己业务的安全要求去设计。

在知识连接方面，Files API、Citations、Web Search 与 Web Fetch 的组合，决定了一个内部助手能不能被信任。能引用内部文档、能把回答锚定在出处上、能在必要时补实时外部信息，这三点加起来，才让回答从“看起来合理”变成“可以追溯”。MCP Connector 的 Beta 身份则提醒使用者，连接外部工具的便捷性与稳定性之间还有一段距离：Beta 意味着接口与行为仍可能调整，生产系统在依赖它之前，应当先在非核心链路上验证，再决定是否放进关键路径。

成本管理同样需要换一种算账方式。Prompt Caching 对重复上下文多的场景确实能省钱，但前提是你的任务真的有大量重复上下文；Batch Processing 适合可以异步等待的大批量任务，却不适合对延迟敏感的交互场景。Fast Mode 的取舍也类似：它换的是输出速度，不是推理质量的提升，实时调试与交互式 Agent 能从中受益，但对可以慢慢跑的离线任务来说，为速度付溢价未必划算。换句话说，这次 GA 给的是一组可以组合的旋钮，而不是一个默认最优的配置，团队需要按自己的任务类型逐一试，而不是全盘照搬公告里的推荐场景。

还有一个容易被忽略的组织层面影响：当数据处理者与合同主体发生变化，相关的内部文档、供应商清单、安全评估记录都需要同步更新。这类工作不产生新功能，却决定了切换能不能顺利通过内部审批。提前把需要更新的文档列出来、把审批责任人定下来，往往比技术迁移本身更花时间，也更容易被低估。

最后补充一点关于选型心态的提醒。云厂商与模型厂商的合作组合正在变多，类似的“同一模型、两种托管方式”以后可能还会出现。面对这类新闻，最可靠的阅读方法是先分清三个问题：模型是不是新的，功能到达时间差在哪里，合同与数据处理者换成了谁。把这三个问题分开，标题里“全面可用”“完整平台”这类说法就不会被误读成“模型更强”或者“全面升级”，选型讨论也能更快落到自己真正要付的成本和要担的责任上。

一句话判断

这次 GA 的实质，是 Anthropic 把“完整 Claude Platform + Google Cloud 身份与账单”做成了一个正式选项，而不是让 Google Cloud 用户在“功能齐全”和“留在谷歌体系”之间二选一。现在两条路线各有明确的取舍：要功能到达速度，选 Anthropic managed；要 Google 作为数据处理者与原生集成，留 Google managed。选之前把折扣、合同主体、数据处理者、端点和原生集成这五项核对完，比先看演示再补流程要省事得多。