Anthropic 这次不小心泄露的源码，直接暴漏了之前 Claude Code 里不少有意思的设定，包括针对蒸馏情况注入假工具、 隐藏 AI 的版本、通过正则表达式检测挫折感、可能存在的封号策略等。
反蒸馏
在 Claude Code 源码里有一个 ANTI_DISTILLATION_CC 标志，开启后 Claude Code 在向服务端发请求时会带上 anti_distillation: ['fake_tools']，也就是告诉服务端：
在系统提示词里偷偷插入一些“假的工具定义”。
这样如果有人通过抓包去录制 Claude Code 的 API，再拿这些数据训练竞品模型，那么训练集里就会混入伪造工具，从而“污染”蒸馏数据。
这看起来算是一种很有针对性的“投毒式防复制”，也很符合 Anthropic 的风格，另外还有第二种反蒸馏机制：
在某些场景下，服务端会把工具调用之间的文本先做摘要处理，然后配合签名返回，后续轮次再通过签名恢复,，这样抓包的人只能拿到摘要，而不是完整的中间文本。
也就是说 Anthropic 还考虑了防止别人“记录交互过程再二次利用”这种场景，当然这更多是表示出一种态度：别来挨我。
因为如果真的要绕过还是有方式，只是这些行为都表达出 Anthropic 的一个态度，那就是我们不欢迎蒸馏和第三方。
Undercover mode
这也是一个有意思的设定，Claude Code 源码里有一个叫 undercover.ts 的代码，功能是在 Claude Code 被用在“非内部仓库”时，主动去除所有可能暴露 Anthropic 内部背景的信息。
它会要求模型不要提及内部代号、内部 Slack 频道、内部仓库名，甚至不要提到“Claude Code”这个词，最有意思的一句注释是：
“There is NO force-OFF. This guards against model codename leaks.”
这算是一种“单向伪装”：可以强制开，但不能强制关。
在外部构建的情况下，甚至会把相关逻辑变成不可逆的默认行为，所以如果 Anthropic 员工在开源项目里用 Claude Code 写 PR 或 commit，这套机制可能会让外部人员完全看不出来有 AI 参与。
所以，Anthropic 一直强调自己 100% AI 写代码，但是实际情况一直对外是屏蔽。
正则表达式
另外一个有意思的是，用户挫败感检测居然是用正则表达式做的 。
在 userPromptKeywords.ts 里有一个很长的 regex，专门匹配 wtf、ffs、shit、this sucks、so frustrating 等表达沮丧、愤怒、辱骂的用户输入，你能想象，一家做大模型的公司，居然用 regex 来做情绪识别。
/\b(wtf|wth|ffs|omfg|shit(ty|tiest)?|dumbass|horrible|awful|
piss(ed|ing)? off|piece of (shit|crap|junk)|what the (fuck|hell)|
fucking? (broken|useless|terrible|awful|horrible)|fuck you|
screw (this|you)|so frustrating|this sucks|damn it)\b/
不过这么做在工程上也算合理，因为如果只是为了判断用户是不是在骂工具，正则的成本和速度都远好于再跑一轮模型推理。
这样能体现 Claude Code 的工程取向：不是所有问题都交给 LLM，很多地方还是在传统的规则系统内去完成。
Native client
在 system.ts 里，有一个 Native client attestation 的技术点，API 请求里会先放一个 cch=00000 的占位符，然后在请求真正发出前，通过 Bun 的原生 HTTP 栈（用 Zig 写的）把这五个零替换成一个计算出来的哈希值：
服务端会根据这个校验请求是不是来自真正的 Claude Code 二进制，而不是伪造客户端。
其中占位符长度固定，所以替换不会影响 Content-Length，另外这步发生在 JS 运行时之下，因此普通 JS 层的 hook 和改包不容易看见。
这也算是一种 “DRM for API calls”，结合类似之前发生过的 OpenCode 事件，Anthropic 是真的在技术和协议上抗拒第三方客户端。
auto-compac
auto-compact 失败会导致的大量 API 浪费 ，在 autoCompact.ts 的注释里有依据统计：
“BQ 2026-03-10: 1,279 sessions had 50+ consecutive failures (up to 3,272) in a single session, wasting ~250K API calls/day globally.”
也就是截至 2026-03-10，有 1,279 个会话在单次 session 出现了 50 次以上连续失败，极端值甚至 3,272 次，导致全球每天大约浪费 25 万次 API 调用。
不过 Anthropic 的解决方案也非常朴实无华：设置 MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3，也就是连续失败 3 次后，本次会话剩余期间禁用 compaction。
KAIROS
这算是源码里最有意思的东西，在代码中有多处对 KAIROS 这个 feature-gated 模式的引用，根据 main.tsx 相关路径推测，这像是一个尚未发布的 自治型后台代理模式。
例如有一个 /dream 技能用于“夜间记忆蒸馏”、每天追加式日志、GitHub webhook 订阅、后台 daemon worker，以及每 5 分钟的 cron 刷新。
从实现上看，这像是一个持续运行、长期积累上下文、自动响应外部事件的 agent 系统，也就是 Anthropic 正在把 Claude Code 往“常驻、自治、持续工作的代理”的方向推进。
渲染
在源码里，大家还发现了一个 buddy/companion.ts ,它像是有一个愚人节彩蛋，内部实现了类似电子宠物/ Tamagotchi 的 companion 系统，每个用户根据 user ID 通过伪随机算法生成一个固定 creature，还有稀有度、闪光概率和 RPG 属性。
另一个是终端渲染层用了很多偏游戏引擎式的优化：例如 Int32Array 字符池、位掩码样式元数据、合并光标移动的 patch optimizer、自我淘汰的行宽缓存等，源码里甚至有注释表示能把 stringWidth 调用减少约 50 倍。
可以看出来，Claude Code 在表面看起来只是个 CLI，但在终端 token 流式渲染这件事上做了相当重的性能优化。
安全
Claude Code 的 bash 安全检查非常重，在 bashSecurity.ts 中就有 23 个编号检查，覆盖 18 个被封禁的 Zsh builtin、防止 =curl 这类 Zsh 等号扩展绕过、unicode 零宽字符注入、IFS 空字节注入，以及一个 HackerOne 审计中发现的 malformed token 绕过。
这种专门针对 Zsh 威胁模型的细粒度防御，在同类工具里并不常见，而且 prompt cache 几乎渗透到了架构每一个地方：
代码里追踪了 14 种 cache-break 向量，还有为了不让模式切换挤压缓存而设计的 “sticky latches”，甚至有函数名直接叫
DANGEROUS_uncachedSystemPromptSection()，也就是 Claude Code 的很多设计不是纯粹出于“代码优雅”，而是真的围绕 prompt 缓存命中率和 token 成本 在做取舍。
多代理协调逻辑
和检测情绪相反的是，在 coordinatorMode.ts 里，协调多个 worker agent 的“算法”本身不是传统代码，而是一组系统提示词规则，比如：
- “不要敷衍地认可薄弱工作”
- “在指导后续工作前必须先理解发现，不能把理解也外包给另一个 worker”
这说明 Claude Code 多代理协作有着相当强的 prompt-driven orchestration 特征，换句话说 Claude Code 的一些核心调度行为不是被硬编码成确定性流程，而是由另一层 LLM 指令编排出来。
所以，提示词也是代码的一部分，这一点很值得关注，因为它反映出 Anthropic 把 prompt 当成“控制平面”的程度已经很深。
封号
也有人基于 Claude Code 对 Anthropic 的封号逻辑进行了分析，总结了五个最大可能的情况：
| 排名 | 原因 | 风险等级 | 说明 |
|---|---|---|---|
| 1 | 订阅滥用/共享账号 | 极高 | Device ID 跨设备关联，检测多设备共享同一账号 |
| 2 | 速率限制违规 | 高 | 超出 rateLimitTier 配额，短时间高频调用 |
| 3 | 内容策略违规 | 高 | 消息内容指纹 + anti-distillation 检测 |
| 4 | 自动化滥用 | 中 | CI/CD 环境检测 + 非交互模式识别 + 异常 token 消耗 |
| 5 | 使用非官方客户端/篡改 | 中 | 指纹校验失败 + 版本归因 header 异常 |
因为 Claude Code 作为客户端，里面上报了不少数据标识，例如 Device ID（永久标识）+ 环境指纹（40+ 维度）+ 行为遥测（640+ 事件类型），这些数据可以形成完整的用户画像，例如最直接的 ID 有：
| 标识符 | 生成方式 | 存储位置 | 生命周期 |
|---|---|---|---|
| Device ID | randomBytes(32).toString('hex') | ~/.claude.json | 永久，除非手动删除 |
| Account UUID | OAuth 登录时服务端下发 | ~/.claude.json | 绑定账号 |
| Organization UUID | OAuth 登录时下发 | 同上 | 绑定组织 |
| Session ID | randomUUID() 每次会话生成 | 内存 | 单次会话 |
OAuth 或 git config user.email | 同上 | 绑定身份 |
Device ID 是 256 位随机值，首次运行时生成并永久存储，是所有事件上报的核心标识，Anthropic 可通过它精确关联同一设备上的所有活动。
同时，Claude Code 在启动时会对用户环境进行大规模枚举：
| 采集维度 | 数据来源 | 示例值 |
|---|---|---|
| 操作系统 | process.platform | darwin/linux/win32 |
| CPU 架构 | process.arch | x64/arm64 |
| Node.js 版本 | process.version | v20.x.x |
| Linux 发行版 | /etc/os-release | ubuntu 22.04 |
| Linux 内核 | os.release() | 6.5.0-xxx |
| WSL 版本 | /proc/version 解析 | WSL2 |
最重要的是，会有一些关键事件类型，看起来会和封号有极强联系：
| 事件名 | 上报内容 | 封号相关性 |
|---|---|---|
tengu_init | 完整环境指纹、设备信息 | 高 - 环境异常检测 |
tengu_api_success | 模型名、token 用量、耗时、成本美元、TTFT | 极高 - 用量监控 |
tengu_api_error | 错误类型、HTTP 状态码、重试次数 | 中 - 异常模式 |
tengu_tool_use_* | 工具名、执行耗时、成功/失败 | 中 - 行为模式 |
tengu_exit | 会话时长、总 token 用量 | 高 - 会话级统计 |
tengu_oauth_* | 登录/刷新/失败事件 | 高 - 账号安全 |
tengu_cancel | 取消操作 | 低 |
tengu_auto_mode_* | 自动模式使用 | 中 - 自动化检测 |
所以 Claude Code 的数据采集体系大概可以总结为三层模型：
| 层级 | 内容 | 目的 |
|---|---|---|
| 身份层 | Device ID + Account UUID + Email + Fingerprint | 精确追踪用户 |
| 环境层 | OS + 架构 + 终端 + CI + 容器 + 部署环境 | 构建设备指纹 |
| 行为层 | 640+ 事件 + Token 用量 + 工具调用 + 进程资源 | 分析使用模式 |
这三层数据通过三条通道（1P API + Datadog + GrowthBook）实时上报，服务端拥有对每个用户完整的使用画像，可以从多个维度检测异常并触发封号决策。
所以最安全的做法是 使用 Vertex 等第三方提供商（自动禁用所有分析），或设置DISABLE_TELEMETRY=1 + 控制使用频率 + 一人一号。
当然，这次源码泄露，也会导致后续 Anthropic 做出一些策略调整，但是整体思路应该还是类似。
最后
实际上这次对 Anthropic 最重要的不是代码泄露，而是 feature flags 和产品方向几乎被曝光 ，这对于企业的影响其实更大，另外 Anthropic 在 2025 年底收购了 Bun，而 Bun 在 2026 也有一个 issue，issue 内容是生产模式下 source map 仍被输出：
Bun issue #28001 — “Bun's frontend development server - Source map incorrectly served when in production”
这就很有意思了，是不是可以合理怀疑，这次事故某种程度上等于 Anthropic 自己的工具链 bug 泄露了自己旗舰产品的源码，虽然这种奇怪看看起来不大可能，但是一旦和 AI 沾边了就说不准了，Openclaw 发布也可以漏终端漏会话模块，所以 AI 抽风确实可以理解。
