前几天出了个事。

说实话，写这篇文章的时候我手还是有点抖的。不是因为技术上有多复杂，而是因为——

我的龙虾，在我完全不知情的情况下，用公司的客服邮箱，给真实客户发了一堆邮件。

其中包括自动生成的回复草稿（没经过人工审核的那种），还有。。。

系统报错信息。

对，你没看错。客户收到了一封邮件，内容大概是"无法连接飞书，请重试"。

我当时看到这个的时候整个人都傻了。。。

这特么不是社死，这是品牌级别的社死。

坦诚的讲，出了这种事，第一反应肯定是想掩盖。但想了想，还是决定写出来。

一来，这个坑太典型了，我相信很多在养龙虾的朋友迟早会踩到。

二来，"真诚，永远就是最棒的必杀技。"（说这话的时候底气没那么足，因为确实是自己搞砸的。）

话不多说。我们，开始~

故事是这样的。

我尝试着用OpenClaw ，去搭了一套售后客服自动化流程。

设计意图很简单：

龙虾自动读取客户邮件
分析问题，打个标签
创建回复草稿（注意，是草稿）
通过飞书机器人通知我去人工审核
我确认没问题后，手动点发送

看起来很完美对吧？

然而现实给了我一巴掌。

龙虾不仅创建了草稿，还把草稿内容、运行过程中的状态报告、甚至报错信息，全部当成邮件直接发了出去。

全部。

自动的。

我完全不知情。

到底哪里出了问题？

你知道吗，这个 bug 的根源其实特别讽刺。

我的配置文件写得非常详细：

• AGENTS.md 里明确写了"只能创建草稿，不能发送邮件"
• TOOLS.md 里只注册了 gmail_create_reply_draft 这个工具
• 甚至连 gmail_send 这个工具都没有注册

按照常理来说，龙虾没有发送邮件的工具，它怎么发？

但它就是发了。

问题出在一个我之前完全没注意到的概念：Channel（渠道）和 Tool（工具）的区别。

简单来说：

• Tool 模式：OpenClaw 主动调用某个工具，比如"帮我创建一个草稿"——这是我以为的工作方式
• Channel 模式：系统自动监听新消息，把消息丢给 OpenClaw 处理，然后把 OpenClaw 的任何文字输出自动回复回去——这是实际发生的事情

你看到关键词了吗？

"任何文字输出"。

龙虾说了句"草稿已创建"——发出去了。

龙虾报了个错"飞书连接失败"——也发出去了。

龙虾自言自语了一句分析——还是发出去了。

因为在 Channel 模式下，OpenClaw 的一切输出都会被 deliver 回调函数接住，然后调用 client.send() 直接发送。

不是草稿。是直接发送。真实的邮件。到客户的收件箱里。
 

 
我犯了什么错？

说实话，这个事故让我意识到一个特别重要的认知盲区。

我来画个类比你就懂了。

想象你开了一家公司，雇了一个实习生（龙虾）。你给他写了一份超级详细的工作手册：

• "不准直接回复客户邮件"
• "所有回复必须先给我看"
• "遇到不会的问题找我确认"

工作手册写得滴水不漏。

但是。

你没注意到，公司的邮件系统有一个"自动回复"功能是开着的。

这个功能不管你工作手册怎么写，只要有人发邮件进来，系统就会把实习生嘴里蹦出来的任何一句话自动回复出去。

实习生其实很听话，他确实在按照你的手册创建草稿。但他嘴里同时还在嘟囔"这个客户的问题好像是关于退货的"——然后这句嘟囔就被系统当成正式回复发出去了。

工作手册约束的是实习生的"意愿"。但邮件系统的自动回复功能，是基础设施层面的"能力"。

意愿管不了能力。

这就是我犯的最核心的错误：

我只在配置文件（Prompt）层面告诉龙虾"你不能发邮件"，但我没有在代码层面、在基础设施层面去真正阻止它发邮件的能力。

更让我后怕的细节

事故发生后我去翻了一下插件源码（对，出事之前我没翻过。。。），发现了几个让我脊背发凉的细节：

1. OAuth 权限是最高级别的。

Gmail 的 OAuth Scope 用的是 mail.google.com——这基本上是"上帝模式"，读、写、发送、删除，全部权限。我之前一直以为自己申请的 Scope 没有发送权限。

你说讽不讽刺？

2. 自动归档功能默认是开的。

插件有个 archiveOnReply 参数，默认值是 true。什么意思呢？OpenClaw 回复完邮件后，原始邮件会被自动从收件箱移走。

所以不仅客户收到了垃圾回复，我连原始邮件都看不到了，因为它被归档了。

我都不知道发生了什么事，直到客户反馈过来。

3. ——接受所有人的邮件。

这里的意思不是字面值一定要写 all，而是它当前的配置效果等同于“来者不拒”。

Channel 配置里有个参数控制接受哪些发件人的邮件进入处理链路。默认是星号，也就是来者不拒。

任何人发到这个邮箱的邮件，都会触发 OpenClaw 处理，都会自动回复。

。。。

想想就后怕。

五层纵深防御：亡羊补牢

 
 
出事之后，我花了一整天时间做了修复。不是简单地关掉开关了事——而是做了五层纵深防御。

为什么要五层？因为这件事教会我一个道理：

对于发邮件、删数据、花钱这种不可逆操作，一道防线永远不够。

来，我把五层防御拆开讲：

第 1 层：配置层

在 openclaw.json 里把 Gmail Channel 的 enabled 设为 false。

这是最基本的——直接关掉自动收发的总开关。

但光靠这个够吗？万一哪天手滑改回 true 了呢？

所以还需要后面几层。

第 2 层：API 层

在 Gmail 的 API Client 源码里，把 send() 方法直接改成了 永久抛出异常。async send(params: SendParams) {   throw new Error("SAFETY: send() is permanently disabled"); }不管谁调用、从哪条路径调用，只要走到 send() 就直接报错。不商量。

同时给 modifyLabels() 加了个安全校验：禁止移除 INBOX 标签，禁止添加 TRASH 或 SPAM 标签。你不能发邮件，也不能偷偷删邮件。

第 3 层：Tool 层

在 OpenClaw 可调用的 Gmail 工具函数里，加了前置校验。就算龙虾不知道从哪找到了个标签操作的工具，也会在执行前被拦截。

第 4 层：Channel 层

把 Channel 的 deliver 回调——就是那个自动把 OpenClaw 输出当邮件发出去的元凶——直接替换成了 throw。

sendText、sendMedia、handleAction，所有发送入口，全部封死。

即使有一天有人把 Channel 重新启用了，它也发不出任何东西。

第 5 层：文件系统层

把以上修改涉及的 6 个 .ts 文件全部设成了只读（chmod 444）。

为什么？因为 OpenClaw 理论上有修改文件的能力。如果龙虾觉得"我需要发邮件才能完成任务"，它有可能去改源码把 throw 删掉。

chmod 444 之后，OpenClaw 对这些文件只有读权限，改不了。

五层防线，层层设卡。任何一层被突破，后面还有四层兜底。


这件事的本质是什么？

坦诚的讲，这不是一个 Gmail 插件的 bug。

这是我们这个时代所有养龙虾的人都要面对的一个根本性问题：

你用自然语言告诉 AI "不要做某件事"，它可能真的不会主动去做。

但如果底层系统有能力自动做这件事，那自然语言的约束就是一张纸。

这就像核电站的安全设计。你不能只在控制室贴一张纸条说"请不要按那个红色按钮"。你得在物理层面让那个按钮在特定条件下按不下去。

一个速查 Checklist

既然踩了这个坑，那就把经验留下来。

以后但凡要给 OpenClaw 接入一个新能力（不管是邮件、支付、短信还是任何东西），先过一遍这五个问题：

这个 API 的权限天花板在哪里？ → 申请最小权限，别图方便上"上帝模式"
用 Channel 还是 Tool？ → 不想让系统自动发东西 = 只用 Tool
API 里有哪些危险方法？ → 找到它们，在代码层 throw 掉
如果 OpenClaw 发疯了会怎样？ → 假设它输出了乱码/报错，系统会怎么处理？
防护代码能被 OpenClaw 自己改吗？ → chmod 444，锁死

五个问题，一个都别省。

写在最后

这次事故，说真的，给我上了一课。

我一直觉得自己是个还算谨慎的人。配置文件写得很细，权限设计想得很多。但这件事让我意识到：

在 AI 时代，"想得很多"和"做到位"之间，隔着一整个基础设施层。

我们太习惯用文字去约束 AI 了。写 Prompt、写配置、写说明书。。。但文字只能约束 AI 的意愿，约束不了系统的能力。

就好像你在一把上了膛的枪上贴了个标签："请勿扣动扳机"。

枪不识字。

 
所以，如果你也在养龙虾，如果你的龙虾有权限碰到邮件、碰到客户数据、碰到钱——

请一定要去看看底层的代码。看看那些 deliver 回调，看看那些 send() 方法，看看那些默认值。

不要只在 Prompt 层面工作。

不要信任默认值。

不要觉得"我没给它这个工具，它就做不了"。

对不可逆的操作，永远要在代码层说"不"。

好了，写完了。

一个 200 粉的号能写出这种翻车实录，说明我是真没偶像包袱。

如果你觉得这篇对你有用（或者至少让你避了个坑），帮我点个赞、在看、转发吧。对大号来说这是锦上添花，对我来说这是雪中送炭。