Anthropic 那次不小心的源码泄露，倒是把 Claude Code 里不少有意思的小算盘全给抖了出来。先说几个核心发现：从反蒸馏的“投毒式”防御，到用正则表达式来抓用户的沮丧情绪，再到潜藏的自治工作流，这些细节拼在一起，基本就是一份关于它们如何设计、保护并规划下一代 AI 工具的完整蓝图。
反蒸馏
源码里藏着一个叫 ANTI_DISTILLATION_CC 的开关。一旦开启，Claude Code 往服务端发请求时，会额外带上 anti_distillation: ['fake_tools']。作用很直接：如果有人试图抓包录制 API 交互，拿这些数据去训练竞品模型，那训练集里就会混入大量伪造的工具调用。这招不算新鲜，但针对性确实很强——典型的“投毒式”防复制，很符合 Anthropic 一向的作风。
另外还有一层防护：反蒸馏机制还专门针对“记录交互过程再二次利用”的场景做了设计。当然，更直白地说，这更多是一种姿态：别来挨我。
Undercover mode
这个设定更有意思。源码里有个 undercover.ts，功能是当 Claude Code 被用在“非内部仓库”时，自动擦除所有可能暴露 Anthropic 内部背景的信息。它会要求模型别提内部代号、内部 Slack 频道、内部仓库名，甚至不要说“Claude Code”这个词。里面有一句注释非常直白：
这不是普通的隐身模式，而是单向伪装——可以强制开启，但没法强制关闭。在外部构建环境下，相关逻辑甚至会变成不可逆的默认行为。换句话说，如果 Anthropic 员工在开源项目里用 Claude Code 写 PR 或 commit，这套机制能让外部人员完全察觉不到有 AI 参与。
正则表达式
接下来这个，多少有点反直觉：用户挫败感检测，居然是靠正则表达式来完成的。在 userPromptKeywords.ts 里有一个超长的 regex，专门匹配 wtf、ffs、shit、this sucks、so frustrating 这类表达沮丧、愤怒甚至辱骂的输入。一家做大模型的公司，居然用 regex 来做情绪识别。
不过仔细想想，工程上这么做其实挺合理。如果目标只是判断用户是不是在骂工具，用正则的成本和速度远比再跑一次模型推理要划算。这也恰好反映了 Claude Code 的整体工程取向：不是所有问题都交给 LLM，很多地方仍然依赖传统的规则系统来完成。
Native client
在 system.ts 里，有一个叫 Native client attestation 的技术点。API 请求中会先放一个 cch=00000 的占位符，然后在请求真正发出前，通过 Bun 的原生 HTTP 栈（用 Zig 写的）把这五个零替换成一个计算出的哈希值。占位符长度固定，因此替换不会影响 Content-Length。而且这步操作发生在 JS 运行时之下，普通 JS 层的 hook 和改包基本看不出来。
这套机制几乎可以看作是一种“DRM for API calls”。结合之前发生过的一些事件（比如 OpenCode），Anthropic 显然是在技术和协议层面都在抗拒第三方客户端。
auto-compact
auto-compact 失败带来的浪费相当惊人。在 autoCompact.ts 的注释里，有一组统计数字：截至 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 的 bash 安全检查非常厚重。在 bashSecurity.ts 中，有 23 个编号检查，覆盖 18 个被封禁的 Zsh builtin、防止 =curl 这类 Zsh 等号扩展绕过、unicode 零宽字符注入、IFS 空字节注入，以及一个 HackerOne 审计中发现的 malformed token 绕过。这种专门针对 Zsh 威胁模型的细粒度防御，在同类工具里非常罕见。
同时，prompt cache 几乎渗透到了架构的每一个角落，这已经成为 Claude Code 性能设计的核心基座。
多袋里协调逻辑
和检测情绪形成对比的是，在 coordinatorMode.ts 里，协调多个 worker agent 的“算法”本身不是传统代码，而是一组系统提示词规则。比如：“不要敷衍地认可薄弱工作”、“在指导后续工作前必须先理解发现，不能把理解也外包给另一个 worker”。这说明 Claude Code 的多袋里协作有着很强的 prompt-driven orchestration 特征——一些核心调度行为并非由确定性流程硬编码，而是由另一层 LLM 指令编排出来。
封号
有人根据 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_* | 自动模式使用 | 中 - 自动化检测 |
所以整套采集体系可以总结为三层模型：
| 层级 | 内容 | 目的 |
|---|---|---|
| 身份层 | Device ID + Account UUID + Email + Fingerprint | 精确追踪用户 |
| 环境层 | OS + 架构 + 终端 + CI + 容器 + 部署环境 | 构建设备指纹 |
| 行为层 | 640+ 事件 + Token 用量 + 工具调用 + 进程资源 | 分析使用模式 |
这三层数据通过三条通道（1P API + Datadog + GrowthBook）实时上报。服务端可以对每个用户形成完整的使用画像，从多个维度检测异常并触发封号决策。因此，最安全的做法是使用 Vertex 等第三方提供商（它会自动禁用所有分析），或者设置 DISABLE_TELEMETRY=1，外加控制使用频率并坚持一人一号。
最后
说到底，这次泄露对 Anthropic 来说，真正的冲击不是代码本身，而是 feature flags 和产品方向几乎被完全曝光——这对企业的影响远比几行代码大得多。另外，Anthropic 在 2025 年底收购了 Bun，而 Bun 在 2026 年有一个 issue 提到生产模式下 source map 仍被输出。这就很有意思了——是不是可以合理怀疑，这次事故某种程度上等于 Anthropic 自己的工具链 bug 泄露了自己旗舰产品的源码？虽然这种推论听起来有点奇怪，但一旦和 AI 沾边，什么都有可能发生。毕竟，Openclaw 发布时都能把终端和会话模块一起泄露出去——AI 抽风，真的可以理解。
