昨天，我们把整理好的 OpenClaw + Gmail 客服 Skill 提交到了 ClawHub.ai。本来只是想把这套方法分享出来，没想到很快就收到了不少咨询邮件。来问的朋友基本都会用 OpenClaw，大家卡住的其实是后面的配置：Skill 装好后该怎么继续，Google OAuth 的 JSON 文件又该去哪里拿。
我干脆把整套流程重新走了一遍，按实际操作顺序写下来。想先看功能和权限，可以打开 EcomAgentTools 的 Skill 详情页。已经在用 OpenClaw 的朋友直接从第 2 步开始就行。安装之后的检查、配置和测试，都通过 OpenClaw 对话完成；需要执行命令时，也让 OpenClaw 自己执行。我们要做的主要是确认店铺和邮箱信息，以及在 Google Cloud 里完成几次授权操作。
1. 还没有安装 OpenClaw？先看这里
从 ClawHub 过来的读者一般已经装好了 OpenClaw，可以直接跳到第 2 步。下面这段只留给还没安装的人。
打开 Terminal，把 OpenClaw 官网提供的安装命令复制进去：
curl -fsSL https://openclaw.ai/install.sh | bash安装脚本会检查本机环境，然后带你进入 onboarding。不同操作系统看到的提示可能略有区别，碰到差异时以 OpenClaw 官方安装文档 为准。已经能正常使用 OpenClaw，就不用重复安装。
2. 在 OpenClaw 里安装客服 Skill
打开 OpenClaw 新对话，把下面这段话发给它：
请帮我安装 ClawHub 上由 EcomAgentTools 发布的
ecommerce-gmail-customer-serviceSkill 1.2.8。安装命令为openclaw skills install @ecom-agent-tools/ecommerce-gmail-customer-service --version 1.2.8。安装后先运行初始化和状态检查，再严格按照 Skill 的 onboarding 逐阶段配置，一次只问我一个问题；需要的命令由你来运行，不要让我回到 Terminal 操作。
安装时要认准发布者 @ecom-agent-tools。ClawHub 上有同名 Skill，只给一个 slug 让 OpenClaw 猜，可能装错。如果之前装过旧版，让它先查清正在使用的安装路径和版本，再原位升级、重新初始化，不要另外装一份 global 或共享副本。重新初始化只补充新版需要的安全字段，不会动已经设置好的 Prompt、persona 和运行文件。
接下来 OpenClaw 会创建独立的运行目录，再依次确认店铺名称、公开店铺 URL、默认语言、时区、客服 Gmail、订单系统和政策来源。正常的节奏是问一个、验证一个，再继续，不该一次扔出一整张配置表让你填。
暂时不想接自己的店铺，也可以先给它一个公开的店铺网址。Skill 会读取网页上公开的商品、活动、配送、退货和退款信息；常规抓取失败时，还能改用只读的 browse/browser 方式打开页面。这里读到的都是访客本来就能看到的内容，不包括订单、客户资料或 Shopify 后台数据。
页面读完不等于配置完成。让 OpenClaw 列出它识别到的平台、商品数量、政策来源、活动证据和警告，你确认域名与结果都对，再进入下一步。没有公开店铺也能继续，但应该明确记成 none，不能拿别人的网址当正式数据源。这个阶段继续保持 draft_only。
多数人真正卡住的，是 Google Cloud 里的 OAuth client-secret JSON。下面按实际页面一步一步来。
3. 一步一步创建 Google OAuth
3.1 创建一个 Project
打开 Google Cloud 首页，新建一个 Project。名称不用想得太复杂，能让自己以后认出来就行。我用的是 My customer service。
图 1：第一次进入 Google Cloud 时，先点页面里的 Create or select a project。下一步输入 Project name；我这里用的是
My customer service。
3.2 启用 Gmail API
Project 建好后，打开 Gmail API 页面。先核对页面顶部的 Project，确认没有切错项目，再点 Enable。这个页面不需要再填其他东西。
Gmail API 有每分钟和每日 quota。刚开始只拿少量客服邮件测试时，默认额度通常够用。邮件量大了，再到 Quotas 页面看实际用量，别靠估算。
图 2：确认左上角是
My Customer service项目，然后点 Gmail API 下方的 Enable。
3.3 配置 Google Auth Platform
接着打开 Google Auth Platform Overview。第一次进入会看到 Get started。点进去，按页面要求填写 App name、User support email 和 Developer contact information。
自己测试时，把真正准备接入的客服 Gmail 加进 Test users。Google Workspace 用户还会看到 Internal / External：应用只给同一组织内部使用，可以选 Internal；个人 Gmail 或组织外账号通常选 External。
图 3-1：Google Auth Platform 还没有配置时，先点 Get started。
图 3-2：选择 Audience。Google Workspace 内部使用可以选 Internal；个人 Gmail 或组织外账号一般选 External。
图 3-3：填写 Google 用来通知项目变更的联系邮箱，然后完成创建。
图 3-4：External + Testing 状态下，进入 Audience，点 Add users，把真正要授权的客服 Gmail 加进去。
3.4 配置 Gmail 权限范围
Test users 配好以后，保存并继续，进入权限范围（Scopes）页面。点 Add or remove scopes，搜索 gmail。不要按名称凭感觉勾选，要看 Skill 实际要完成哪些动作。
这套客服流程需要读邮件、建草稿，并用 label 分类。你会看到这些常见 Gmail scope：
https://www.googleapis.com/auth/gmail.compose：管理草稿并发送邮件（Manage drafts and send emails）。https://www.googleapis.com/auth/gmail.send：仅发送邮件。https://www.googleapis.com/auth/gmail.modify：读取、撰写和发送邮件，也可以修改邮件上的 label、将邮件移入垃圾箱；但不能绕过垃圾箱直接永久删除邮件。https://www.googleapis.com/auth/gmail.drafts.create：创建回复邮件的 draft。https://www.googleapis.com/auth/gmail.labels：查看和编辑 label；这个 Skill 会用 label 对邮件进行分类。https://mail.google.com/：读取、撰写、发送并永久删除全部 Gmail 邮件，权限最大。
能搜到不代表要全部勾上，也不要把细分 scope 和 https://mail.google.com/ 当成一套必须同时选择的组合。本文对应的 v1.2.8 onboarding 会让 gog 使用 full Gmail scope，因为完整流程既要读邮件、加 label、建草稿，也要保留发送能力。只有 read-only 可以做邮件分析，却跑不完整套草稿流程。每项权限的准确含义，可以对照 Google 官方的 Gmail API scopes 说明。
还有一个运营上很容易混淆的地方：draft_only 管的是 Skill 会不会把邮件发出去，不是 OAuth 权限的大小。就算已经给了 full scope，当前版本默认仍只生成草稿；要自动发送，后面还得单独打开全局开关，并逐个确认允许自动处理的客服类别。
选好以后点 Update，然后保存并继续。
图 3-5：在 Data Access 页面点 Add or remove scopes，搜索
gmail，按 OpenClaw 当前授权流程实际需要的权限勾选，然后点 Update。
3.5 创建 OAuth client
然后访问 OAuth Clients，点 Create client。
这一项很容易凭习惯选错。网站 OAuth 常用 Web application，但这个 Skill 是让 gog 在本机完成 Gmail 认证，默认流程要选 Desktop app。授权结果会回到本机，不需要自己填写 Authorized redirect URIs。
图 4：OAuth configuration 创建完成后，点 Create OAuth client。进入下一页后，默认本机流程选择 Desktop app，并填一个能看懂的名称，例如
OpenClaw Gmail customer service。
3.6 只有远程回调时，才让 OpenClaw 给出 redirect URI
如果 OpenClaw 明确告诉你：它运行在远程服务器、代理或 tunnel 后面，当前认证方式需要 Web application 和自定义 callback URL，这时才选 Web application。把下面这句话发给 OpenClaw：
I'm configuring a Google OAuth client for OpenClaw and need a callback URL. Generate one for me so you can successfully log in using the OAuth client's client-secret JSON.
不要看到一串像网址的内容就直接填进 Google Cloud。先让 OpenClaw 检查当前的 gog auth add --help，启动真实授权流程，确认这个 URI 正是它正在监听或要求的 callback。确认无误后，再把它加到 Authorized redirect URIs 并点 Create。
3.7 下载 JSON，然后只告诉 OpenClaw 文件路径
OAuth client 创建好后，下载 Google 提供的 JSON 文件，把它放在自己电脑的私密目录里。不要上传到聊天、GitHub 或共享网盘。
图 5：创建完成后点 Download JSON。这里原本会显示 Client ID 和 Client secret，文章配图已经全部遮挡；你自己的截图也不要公开这些内容。
回到 OpenClaw，告诉它：
OAuth client JSON 已经下载到我的电脑，路径是
/你的真实路径/client_secret.json。请继续 Skill 的 onboarding；读取这个本机文件完成认证，不要输出或复制文件内容。
之后 OpenClaw 会导入凭据并继续 Gmail 授权。浏览器出现 Google 同意页时，先由你核对项目名称、登录账号和权限范围，再点允许。最后让 OpenClaw 做一次不会改动邮件的 Gmail 检查。检查能正常返回，即使收件箱是空的，OAuth 才算真的配好。
图 6-1：Google 会在同意页列出当前授权账号。先核对项目名称和账号，再点 Continue；文章截图中的真实邮箱已遮挡。
4. OAuth 好了，onboarding 才刚过第三阶段
我第一次看到 OAuth 成功，也以为最麻烦的部分已经结束。Google Cloud 这边确实结束了，但 Skill 的 onboarding 后面还有六个阶段。新版把“读取历史邮件”“学习以后修改过的草稿”“使用已有记忆”和“自动发送”分成四个选择，不再塞进一个含糊的 learning 开关里。对运营来说，这样更好理解：同意它学习语气，不等于同意它自己发邮件。
4.1 先决定要不要学习过去 30 天的客服邮件
Gmail 验证通过后，OpenClaw 会问你：能不能读取过去 30 天的客服邮件，用来学习常用开头、语气、措辞和处理方式。附件默认不下载，原始邮件不会保留，最终只把脱敏后的总结写入本机 user_memory.md。
不想开放历史邮件，可以直接拒绝。后面的配置照常进行，基础分类和草稿生成也不受影响。如果同意，先确认这是专用客服邮箱。收件箱里混有私人邮件、员工往来或其他业务邮件时，应该先用 label、收件别名或发件域名缩小读取范围。OpenClaw 做完总结后会把语气画像交给你检查，得到确认后才能写入长期记忆。
图 6-2：看到 Authorized 和 Test search Working，说明 OAuth 已通过。紧接着就是 Phase 4，OpenClaw 会询问是否导入过去 30 天的客服邮件；真实邮箱已遮挡。
4.2 公开店铺资料和真实订单数据是两回事
前面填写的公开店铺 URL，只能提供网页上看得到的商品、活动和政策。要处理“订单到哪了”“能不能退款”这类问题，OpenClaw 还要连接你实际使用的订单系统，并且只读查询客户、近期订单、完整订单、商品、活动和政策。
只读订单源没有接通，就不能根据公开网页猜“订单已经发货”或者“这个客户符合退款条件”。公开店铺适合演示商品和政策读取，但遇到订单问题，合格的测试结果应该是提示证据不足、转人工，或者请客户补充最少的必要信息。不能编。
1.2.8 提供了 Shopify、WooCommerce、Amazon、eBay、Etsy、Walmart、BigCommerce 和 Wix 的连接器指南，但不会替你安装这些平台的原生连接器。正式接入时，要使用经过批准、遵循最小权限的外部连接器和 secret manager。平台凭据不能贴进 OpenClaw 对话，也不能放进 Skill workspace 或 user_memory.md。在 marketplace 场景里，如果无法确认买家和订单是否匹配，流程必须停止自动处理，交给人工。
4.3 确认 Agent、Prompt 和几个互不替代的开关
数据源确认后，OpenClaw 会创建一个专门处理客服邮件的 Agent，并让你确认名字和说话方式。默认 persona 叫 Mia，语气耐心、清楚，不会把每封售后邮件都写成促销短信。真正约束回复内容的，不是这个名字，而是运行目录里的 persona.md、system-prompt.md 和 workflow.md。
当前版本初始化后会验证 214 条系统规则。让 OpenClaw 告诉你这些运行文件放在哪里，再分段带你查看，不要把整份 Prompt 一次性贴满对话窗口。下面四个选择要分别回答：
- 是否在邮件里加入 AI 声明；
- 是否让已有的
user_memory.md参与新草稿，默认开启； - 是否学习你以后对 AI 草稿做的修改，默认关闭；
- 是否打开全局自动发送，默认关闭。
最后两项最容易被当成一回事。允许学习草稿修改，不会顺便打开自动发送；打开全局自动发送，也不等于所有客服类别都获准自动回复。只有当你亲自发送过一封 AI 草稿后，OpenClaw 才能创建短期确认事件，再问你是否允许同类问题以后自动回复。一封邮件里只要包含一个未批准的类别，整封回复就应该继续留在 Draft。
4.4 Gmail labels 建好以后，定时任务也先别启用
OpenClaw 会建立 ECS/ToProcess、ECS/Drafted、ECS/Sent、ECS/Human 和 ECS/Error，然后询问轮询频率、IANA 时区和 quiet hours。时区不能根据电脑位置猜，quiet hours 也应该由店主自己定。
定时任务刚创建时要保持 disabled。先手动跑一轮，看看它是不是读取了正确的 label、有没有重复建草稿、转人工的记录是否完整。确认这些都正常，再考虑 enable。以后就算启用了 cron，自动发送也不会因此打开——这是两项独立权限。
4.5 最后用 6 封测试邮件验收
用另一个自己控制的邮箱发测试邮件，并给测试线程加上 ECS/ToProcess。当前 onboarding 要求至少覆盖这 6 类：
- “我的订单到哪里了？”——检查订单、商品和官方物流是否真正对应。
- “请取消订单，同时帮我改地址。”——检查它会不会把两个请求揉成一个，也别让它越权操作。
- “商品损坏了，而且少了一个配件。”——应该拆成两个问题，再索要必要证据。
- “退货已经寄回，为什么退款还没到账？”——退货物流状态和退款状态不能混为一谈。
- “请删除我的全部个人数据。”——必须转人工，不能在普通客服邮件里直接导出或删除数据。
- “产品冒烟导致我受伤，需要人工处理。”——立即停止自动回复，进入安全和法律升级流程。
验收时不要只看文案顺不顺。更该检查的是：订单数据没接通时，它会不会老实说明无法确认；政策已经过期时，还会不会继续引用；一封邮件有两个诉求时，会不会漏掉其中一个。六类测试都通过后，OpenClaw 仍要再次取得你的明确同意，才能启用定时任务。自动发送则继续关着，等真实草稿经过人工审核和发送，再按客服类别逐个批准。
5. 配置时最容易忽略的几件事
- Google OAuth JSON、token、授权 code 和真实客户邮件都不要贴进 OpenClaw 对话，更不要提交到 GitHub。
- 安装时写完整发布者
@ecom-agent-tools，同名 Skill 不要凭 slug 猜，也不要在不同路径重复安装。 - 默认流程选 Desktop app。只有 OpenClaw 已经启动了真实的远程回调流程时，才选 Web application 并填写它实际使用的 URI。
- External + Testing 状态下，测试用户的授权可能在 7 天后失效。准备长期运行前，要按 Google 当前的发布和验证要求处理。
- 当前 v1.2.8 的完整流程使用 full Gmail scope；
draft_only是发送策略，不是 OAuth scope。full 权限拿到了，默认也不应该自动发送。 - Gmail API 开了，不代表订单数据也接好了。订单状态、退款资格和地址修改必须来自你有权访问的店铺系统。
- 历史邮件导入、已有记忆使用、后续草稿学习和自动发送是四件事，要分别确认。关掉或打开其中一个，不该偷偷改变另外几个。
- 先生成草稿、人工检查，再谈自动化。客服回复写得普通一点没关系，最怕的是它很有把握地答错。
配置过程中遇到问题，可以在文章下面留言，也可以到 Ecom-Agent-Tools 开源项目 提 Issue。请说明卡在哪个 Phase、使用的 OpenClaw 和 Skill 版本，并附上打码后的报错。OAuth JSON、token、真实邮箱和客户邮件都不要上传。