Workspace MCP 接入将强制校验代理标记

Google 要求给调用 Workspace MCP 的 OAuth 客户端标记 AI Agent 身份，但原文给出的执行范围，比「Google 要封禁 AI Agent」窄得多：直接受影响的是通过自有、未标记客户端调用 Workspace MCP 的集成，普通 REST 调用不在这次变更范围内。

对使用 n8n 或自己接 Agent 工具的程序员，关键是分清调用路径、客户端归属，以及两个截止日期。作者称已在 2026-10-21 核对官方文档；下面按这份原文拆解，哪些要改，哪些不用动。

先看是不是 MCP，别看到 AI 就改配置

原文转述的官方规则是：从 2026 年 11 月 11 日起，Google Workspace MCP servers 会拒绝未标记为 agentic 的 OAuth 客户端请求。

这里的 agentic，是给客户端标注「用于 AI Agent」的身份。入口在 Google Auth Platform > Clients，OAuth 2.0 客户端对应的选项叫 Use this client for an AI-powered agent.。

判断是否受影响，不能只看工作流里有没有大模型，还要看它怎样访问 Google。

原文明确指出，仅调用 Google Workspace REST APIs 的应用和集成不受影响。n8n 内置的 Gmail、Sheets、Drive、Calendar 节点，如果走的是 REST，就不需要因为这项规则修改配置。一个流程即使先让模型生成内容，再用普通节点写入表格，也不能仅凭「用了 AI」认定它需要打标。

需要排查的是：使用自有 OAuth 客户端访问 Gmail、Drive、Docs、Sheets、Calendar 的 Workspace MCP endpoints，以及配置了自有 client IDs 的相关 Agent 工具。后者仍要检查实际调用路径，不能把所有 Agent 工具都算进强制范围。

11 月 11 日开始拒绝，12 日后可能必须换客户端

两个日期解决的是不同问题，不能合并理解成一个截止日。

2026 年 11 月 11 日是请求执行限制的起点。到了这一天，受影响的未标记客户端就可能调用失败。

2026 年 11 月 12 日是身份锁定节点。按原文描述，届时仍未标记的客户端会保持 non-agentic，之后若要调用 Workspace MCP servers，需要新建已标记的客户端，并更新所有引用旧客户端的配置。

因此，补救成本可能不止勾一个选项，还包括替换各处 client IDs。原文特别提醒检查 mcp_config.json 和其他 MCP 客户端设置。

作者称，现有客户端从 10 月 12 日起已可编辑这个选项；新建客户端的创建文档则说明，该设置创建后不能更改。这两条针对不同情形。准备新建客户端时，要先确定它承载哪类流量，再点击 Create。

为什么要先拆客户端，再给 Agent 打标

agentic 标记不会增加 scopes 或权限，它提供的是管理分类。

大白话讲，打标不会让 Agent 突然多读一份文档，而是让 Workspace 管理员能单独管理 Agent 的访问，不必同时调整真人用户的访问。

这也解释了原文为什么强调拆分：如果同一个 OAuth 客户端既服务用户交互功能，又承载 Agent/MCP 流量，直接给共享客户端打标，会把两类流量放到同一种身份下。作者转述的 Google 最佳实践是使用独立 client IDs，一个 standard，一个 agentic。

按这个逻辑，操作顺序应当是盘点客户端、确认用途、拆分混用客户端、标记 Agent 客户端，最后修改 MCP 配置。先勾选再调查用途，容易把原本不需要调整的功能一起卷进去。

我的判断

这篇最有用的地方，是把「工作流用了 AI」和「客户端访问 Workspace MCP」分开了。相较于给全部 OAuth 客户端统一打标，按调用路径分类更符合原文描述的执行边界。

但「使用 n8n hosted OAuth service，这次变化就与你无关」需要收窄理解。用户不拥有那个客户端，通常就无法亲自修改标记；这不等于服务提供方没有适配责任，也不能据此保证服务一定不受影响。

文章没有展示请求测试、错误响应或迁移对照数据，它是一份文档核对式解读。所谓「10 分钟清单」也只是作者的操作估计：客户端数量、共享程度、配置分散情况不同，实际时间会差很多。尤其是原文末尾「只有自有未标记客户端才会导致工作流失败」的绝对表述，不宜当作完整的可用性保证。

能拿来做什么

• 给现有 n8n 流程标注 Google 访问方式，先区分内置 REST 节点和 Workspace MCP 调用，把排查范围缩到实际受影响的部分。
• 到 Google Cloud console > Google Auth Platform > Clients 盘点自有客户端，记录每个 client ID 的用途，优先找出真人交互与 Agent 共用的客户端。
• 对确实需要拆分的客户端，完成 agentic 标记后，同步更新 mcp_config.json 及相关 MCP 设置，并验证原有调用能否成功。
• 使用托管 OAuth 时，向服务提供方确认 Workspace MCP 的适配情况；交付自动化流程时，也应写清 OAuth 客户端由谁维护。