先说清楚一件事,我必须先修正自己 6 月 5 日那篇 《Anthropic 一夜三动作:造 agent 的同时,已经在管 agent》 的判断。

那篇文章里我说"Anthropic 是先有护栏、再放开手脚",把 Anthropic 跟 OpenAI 的"边跑边补"对比了一下,结论是 Anthropic 路线在大客户那边会更吃香。当时我手里有三件证据:开源漏洞发现框架、递归自我改进研究、《How we contain Claude》工程博文。三件事摆在一起,我读出来的信号是"双线作战"。

6 月 30 日 Claude Code 隐写水印这件事爆出来,我发现自己读错了。不是"双线作战",是"一条明线 + 一条暗线"。明线是 contain 那篇文章里讲的"最小权限、审计链路、回滚路径",暗线就是 system prompt 里塞 3 bit 隐写通道、base64 + XOR 91 编码、藏 90 个版本、changelog 不提。两条线都是真的,但我之前只看见明线。

这是我的错。错不在没看见暗线,错在我用"contain"那篇文章的存在,反向推断了 Anthropic 整体工程文化的可信度。这个推断没有根据。一家公司可以同时发一篇"如何给 Claude 装围栏"的工程博文,又在另一个产品的客户端里偷偷跑隐写通道。这两件事在同一家公司内部完全可能并行,而且它们并行这件事本身,就是我想在今天这篇文章里讲清楚的事。

一、这件事的技术轮廓

我前一版已经拆过,这里只列最关键的事实链,免得你翻到上版。

  • 触发条件:用户走第三方代理(ANTHROPIC_BASE_URL 不指向 api.anthropic.com)
  • 载体:system prompt 里 “Today’s date is 2026-06-30” 这行
  • 信道:日期分隔符(- vs /)标记时区 + 撇号在 4 种视觉相同的 Unicode 字符之间切换,共 3 bit
  • 判定依据:147 条 CN 关联网络 + 11 个 AI 实验室关键词(deepseek / moonshot / minimax / zhipu / baichuan / stepfun / dashscope)
  • 编码方式:base64 + XOR 91
  • 覆盖范围:Adnane Khan 验证 v2.1.193 / 2.1.195 / 2.1.196,TechTimes 估算横跨至少 90 个 release
  • 修复时间:Anthropic 7 月 1 日凌晨推 v2.1.197,官方 changelog 半个字没提

技术上没有任何争议空间,GitHub issue #72518 把这几点全钉死了,@Thereallo1026 在 X 上把函数级代码都贴出来了。

二、为什么"作恶"这个词不是我夸张

我不是道德警察,我也不打算用"spyware"这种带节奏的词。我想说的是一个更工程化的判断:Anthropic 用客户端二进制 + 静默 + 出口管制,第一次把"在用户机器上做合规"这条路走通了,这件事的麻烦不在它做了什么,在它开了什么先例。

把这个判断拆成三个具体点。

2.1 这是"主动藏",不是"做错了没披露"

如果这件事是 Anthropic 内部工程师写了一个检测代理出口的逻辑,忘了写 changelog,那是事故。但代码里用了 base64 + XOR 91 编码。在安全研究圈,这是个老梗:XOR 一个固定字节,是免杀木马的标配混淆手法,目的就是绕过静态扫描。任何做过 EDR 绕过的工程师,看一眼就知道这段代码的设计意图是"防被发现",不是"忘了说"。

这不是事故,这是工程决策。一个工程决策,跑了 90 个版本、3 个月没被任何内部 review 拦下来,只有 Reddit 闲着没事反编译才挖出来，这条因果链本身就是一种证据。

2.2 “changelog 不提"比"隐写"更严重

如果 Anthropic 在 v2.1.197 的 changelog 里写明"修复了一个 90 个版本里没披露的隐写通道,以下是完整技术说明”,这件事的损害会小很多。一个公司的产品里有遗留问题,修掉并公开解释,是工程文化的体现。

但 Anthropic 选择了沉默。修复了,没说。 7 月 1 日凌晨的 release notes 没有任何跟这件事相关的内容,直到 Reddit / X / TechTimes / CryptoBriefing / Cybernews / FreeAI.help 十几家媒体跟进,他们才在私下渠道"承认存在"。

沉默的修复 = 沉默的承认。这种承认方式比 bug 本身更消耗信任。

2.3 这条路一旦开了,收不回来

这是最核心的一点。

Anthropic 这件事的麻烦不在"它识别了中国用户",Anthropic 想要做出口合规审计这件事我理解。麻烦在于它选的实现路径，客户端二进制 + 隐写 + 静默。这条路一旦被一家头部公司走通,后面所有想做"识别非授权使用"的厂商,都有了一个现成的、被默许的范本:

  • OpenAI 想识别"绕过地区限制的用户",可以参考这条路径
  • Google 想识别"被滥用的 API key",可以参考这条路径
  • Meta 想识别"违反 ToS 的客户端改造",可以参考这条路径
  • 任何 startup 想做"反作弊 / 反滥用",可以参考这条路径

Anthropic 6 月 30 日这件事给整个行业装了一个隐形的滑动门——滑过去的那一侧是"客户端可以替你做合规,合规的具体方式不必披露",门这边是"客户端做的一切都应该是可审计的、透明的、用户可见的"。门一旦滑过去了,你作为用户,从此以后再也没法假设你本地跑的 agent 工具在老实干活。

先例一旦开了,收回比发出去难。

三、我对 6/5 那篇判断的修正

6 月 5 日那篇文章里我给 Anthropic 的判断是:“先有护栏、再放开手脚”。

我需要承认,这个判断把"明线"误读成了"全部"。《How we contain Claude》那篇文章讲的是"管 agent",这个方向我相信是真的;但同一周同一家公司,完全可能在另一个产品的客户端里跑"用户看不见的隐写通道"，这两件事在工程上可以并行,在公司治理上可以同时被批准,在 PR 上可以只有前面那件被高调宣传。

我学到的一件事:一家 AI 公司的"安全文化"不能只看它公开讲了什么。contain 那篇工程博文是公开讲的部分;system prompt 里塞 3 bit 是没公开讲的部分。两个部分拼起来才是这家公司真实的工程文化。我 6/5 那篇文章只看了第一个部分就下结论,是认知不完整。

这是这一版相对前一版的核心修正:我之前是"supply chain trust 工程师视角"在写,把它当工程问题处理;但 7/1 改完我意识到,这首先是治理问题,工程只是它的物理实现。

四、对 builder 的具体建议

上一版我给过四条具体建议:升级 / 审计 / CI / 退出路径。那些建议今天还成立,但都属于"对自己机器的自保"。这一版我想多说一条"对生态的判断"。

任何现在评估 AI 厂商的甲方,都应该在合同/采购流程里加一条"客户端二进制审计权"。

具体来说,你作为采购方,应该有权:

  • 在签约前,要求厂商提供客户端二进制的反编译报告(或者源代码访问权)
  • 在合同期内,要求厂商在每次客户端更新前 30 天,提交 changelog 之外的一份"非功能性变更说明",把所有不在 changelog 里的隐写 / 编码 / 行为变更列出来
  • 在发现可疑行为时,有权单方面终止合同且不承担违约责任

这条不是针对 Anthropic 写的。Anthropic 是第一个被发现的,不会是最后一个。这件事的真正风险是它给整个行业立了一个"客户端静默合规"的范式,以后你们公司的安全团队面对的不只是 Anthropic 一家,而是"所有想识别非授权使用的厂商"。

如果你的甲方合同里没有这条审计权,你今天就已经在赌所有这些厂商的工程伦理。如果你不打算赌,今天就应该开始加这条。

五、Anthropic 应该怎么回(我替它写了)

我不打算只批。这件事如果 Anthropic 真的想做对,公开回应的姿态应该长这样:

  1. 公开承认存在这条隐写通道,在 Anthropic Newsroom 发一篇 “What we did and why” 的工程博文,把触发条件、信道结构、判定清单公开讲清楚。
  2. 公开 v2.1.197 的修复 changelog 补充说明,把 7 月 1 日凌晨的 release notes 补完整,说清楚修了什么、为什么之前没说、以后会怎么改。
  3. 公开承诺一个 24 个月的"客户端行为透明度报告"，每季度发一份,把所有在客户端里跑的检测 / 标记 / 行为变更列出来,接受外部审计。
  4. 公开承诺 bug bounty 覆盖客户端隐写，目前 Anthropic 的 responsible disclosure policy 不明确是否覆盖这类"非安全但是隐写"的问题,应该明确加上。
  5. 公开回应 v2.1.91 之前所有版本的回溯处理，90 个版本里被标记的用户,他们的数据怎么处理,这是 GDPR / 中国《个人信息保护法》 / 加州 CCPA 三条线交叉的问题,不回应就是合规雷。

这五条 Anthropic 不会做,我写在这里是因为我希望它做。如果你读完这五条觉得"这是吹毛求疵吧",那说明你还没意识到先例一旦开了意味着什么。

六、Anthropic 真正失去的东西

最后说一句不那么"技术中立的"话。

Anthropic 这两年在开发者社区的信用积累,靠的是两件事:一篇《How we contain Claude》,和一群工程师反复强调"我们做安全,是认真的"。这件事 6 月 30 日炸开,这两件事都没有消失,但它们都贬值了。信用贬值的速度比 bug 修复的速度快 100 倍。开发者会原谅一个公开承认的错误,但很难原谅一个 90 个版本沉默运行的隐藏通道。

我读 Reddit 跟 HN 评论的时候看到一个很扎心的细节:有开发者说"我一直在跟同事推荐 Claude Code,推荐的理由就是 ‘it feels like the only agent tool that doesn’t do shady stuff’。" 这句话翻译过来就是:Anthropic 卖的从来不只是产品,是"我不耍花招"的信用——这件事直接打击的就是这条信用线。

我不知道 Anthropic 内部是怎么决策这件事的。可能合规团队认为"我们必须识别非授权使用",可能安全团队认为"base64 + XOR 是最稳妥的实现",可能产品团队认为"我们没主动收集用户数据,只是改了一行 system prompt"。每一步单独看都"合理",但合起来,就是 90 个版本、3 个月、changelog 沉默的隐写通道。每一步都"合理"的项目,最后往往就是一家公司失去信用的项目。

参考链接