收到Google AI连接的迁移通知，不必先把所有邮件、日历和文档集成都推倒重来。真正要查的是哪些程序在调用Workspace的MCP服务，哪些仍然只走普通REST接口，以及它们有没有共用一个OAuth客户端。迁移范围取决于调用方式，不取决于公司是否已经开始用AI。

Google在10月12日的开发者公告中，要求调用Workspace MCP服务的OAuth客户端选择“用于AI驱动的Agent”。公告同时明确，只调用Workspace REST API的非AI集成不受这项变化影响。相关MCP服务目前属于开发者预览范围，团队应先确认自己是否实际使用。

共用客户端时，把AI部分拆出来

一些早期集成可能把普通功能和AI功能放在同一个客户端下。Google对此给出的处理方式，是为AI Agent另建客户端，仅将新客户端标记为AI用途，原客户端继续服务非AI功能。这样做的重点是分开用途，不是借迁移扩大访问范围。

先列出真正调用MCP的工作流，比按产品名批量处理更可靠。同样是Gmail，一段普通收信程序与一个通过MCP读取邮件的助手，受到的要求可能不同；同一个界面也可能同时使用两种连接。不能看到“邮件自动化”四个字就认定全部需要迁移。

对接方给出连接说明时，应能说清使用哪个接口、哪个客户端承担AI功能，以及普通功能是否仍依赖旧客户端。这里不需要在群里传密钥。客户端标识和用途可以用于核对，秘密凭据仍应留在原来的受控存放位置。

拆分后要分别验证两条路径。AI连接按其实际权限完成小范围测试；普通收信、通知或文档处理则检查仍走原来的连接。不要用“AI助手能打开邮箱”作为所有旧自动化正常的证明，也不要为测试方便扩大邮件访问范围。

按公告日期安排，不把标记当成授权

公告写明，Workspace MCP服务将从11月11日起拒绝未标记为AI用途的客户端请求；到11月12日仍未标记的客户端将保持非AI分类，之后如需MCP须新建AI客户端并更新应用。两个日期承担不同描述，安排迁移时不应自行合并成一个宽松的截止时间。

只使用普通REST接口的团队，可以记录不受此项变化影响的依据，不必为赶日期更换正常连接。确有MCP依赖的团队，则应在生效前完成客户端用途核对、必要拆分及应用更新。具体步骤仍按账户的管理权限、预览资格与官方指引执行，不绕过平台授权。

AI用途标记也没有回答助手能读取哪些邮件、可以修改哪些文档。它解决客户端分类，实际权限仍是另一道边界。AI邮件发送权限的有效期讨论何时收回动作权限；客户端迁移不能顺带延长这类授权，更不能当成所有业务动作的批准。

对中国销售团队与海外技术方共建的助手，交接应明确新客户端服务哪些AI功能、旧客户端保留哪些普通功能。遇到故障才知道二者共用身份，会把一次局部连接问题扩大成整套邮件流程的排查。

交接时把AI功能、新客户端和普通功能、旧客户端逐项对应，并分别记录测试结果。没有使用MCP就不必制造一次迁移；确实混用时，普通接口可以按公告继续使用原客户端，不用随着AI部分一起重建。

参考来源