Claude泄露代码值得学习的东西

我花了一晚上阅读代码并基于它构建东西。如果你在构建 AI 智能体,以下是你需要知道的。

1、实际泄露了什么(以及没有泄露什么)

2026 年 3 月 31 日,一位安全研究员注意到 Claude Code npm 包有些奇怪。版本 2.1.88 附带了一个 59.8MB 的 source map 文件。Source map 是 Bun(Claude Code 使用的运行时)默认生成的调试产物。有人忘记将 *.map 添加到 .npmignore 文件中。就这样。配置文件中缺失的一行。

Source map 引用了 Anthropic 的 Cloudflare R2 存储桶中的未混淆 TypeScript 文件。全部可下载。约 1,900 个文件。512,000 行代码。几小时内,代码库在 GitHub 上被镜像,不到两小时就达到了 84,000 多颗星。GitHub 历史上增长最快的仓库,对于一个本不应该公开的代码库。

交互式数据

让我澄清一些我看到人们误解的事情。

没有暴露任何客户数据。 这是 CLI 工具的源代码,不是数据库泄露。没有凭据、没有用户对话、没有 API 密钥。Anthropic 确认这是打包错误。

没有泄露模型权重。 代码是围绕 Claude 的软件工具链,不是 LLM 本身。你不能用这个运行你自己的 Claude。你得到的是编排层:Claude Code 如何管理工具、内存、上下文、权限和多智能体协调。

这不是传统意义上的安全漏洞。 这是应该从 npm 包中排除的构建产物。对 Anthropic 的构建流水线来说很尴尬,但这是任何快速交付的团队都可能犯的错误。讽刺的是,泄露的代码中包含一个叫做"Undercover Mode"的系统,专门设计用于防止 Anthropic 员工意外地将内部细节泄露到公共仓库中。它和所有其他东西一起泄露了。

这不是故意的。 我知道人们在争论这个,因为时间点与 4 月 1 日吻合,而且 Anthropic 在公关方面度过了艰难的一周(对 OpenCode 项目发出停止和终止函)。但证据很清楚:他们一直在向 GitHub 仓库发送大量 DMCA 撤除通知,他们撤回了 npm 包,他们的 Cloudflare R2 存储桶被关闭了。你不会用计划好的发布来做这些。战略路线图的暴露成本太高了,尤其是在 IPO 准备期间。t3.gg 的 Theo 说得好:"如果你认为这是故意的,我有几座桥要卖给你。"

有一个说得通的理论:Anthropic 正在调查 Claude Code 中的速率限制问题。多名员工发帖称看到了比预期更高的速率限制命中率。在他们尝试从生产构建中获取更好的错误日志时,可能包含了用于调试的 source map。然后忘记从 npm 包中排除它们。这符合这类事情通常发生的方式:一个调试更改,没有人记得撤消。

如果你想克隆泄露的仓库,请注意: 源代码引用了 npm 上不存在的内部工作区包。有人已经用一次性邮箱注册了这些包名。如果你克隆并盲目运行 npm install,可能会拉取恶意代码。请小心。

2、有什么以及为什么重要

几个月来我一直在构建自己的 AI 智能体。它在一台专用 Mac Mini 上 24/7 运行。所以当这次泄露发生时,我不是为了八卦而阅读它。我阅读它是为了学习。我花了一晚上研究架构,将其与我构建的东西进行比较,并提取有用的东西。

如果你在构建 AI 智能体或想了解这项技术的实际发展方向,以下是你需要知道的。

2.1 三层内存系统

这可能是泄露中最重要的架构发现。Claude Code 使用一个三层内存系统:

  1. 核心索引(MEMORY.md): 一个轻量级的指针文件,始终加载到上下文中。每个条目不超过 150 个字符。它是索引,不是内存本身。
  2. 主题文件: 分布在独立文件中的详细知识,当索引表明它们相关时按需获取。
  3. 原始转录: 永远不会完整重新读取。只在需要时根据特定标识符进行 grep。

关键洞察是他们称之为"怀疑性内存"。智能体将自己的内存视为提示,而不是事实。在根据记忆做某事之前,它会先对照实际代码库进行验证。内存说某个函数存在?先检查。内存说某个文件在这个路径?使用前先验证。

这解决了上下文熵的问题——在长时间运行的会话中智能体性能的逐渐退化。大多数智能体运行时间越长,表现越差,因为它们的上下文充满了过时的观察。这个架构保持活动上下文很小(只是索引),并且只加载需要的内容。

我一直在运行类似的模式,工作内存按计划滚动,永久索引跨会话持久化。泄露证实了这是正确的方法。验证步骤是我现在正在添加到我自己的系统中的东西。

2.2 空闲时的内存整合(autoDream)

泄露包含一个在 services/autoDream/ 目录中的系统,叫做 autoDream。它是一个后台内存整合引擎,作为具有只读项目访问权限的分叉子智能体运行。必须通过三道门才能运行:距离上次运行至少 24 小时、至少完成 5 个会话、以及整合锁必须可用。

触发时,它运行四个阶段:定位(扫描内存目录)、收集(从日志中提取新信息)、整合(写入和更新主题文件)和修剪(保持总内存在 200 行和 25KB 以内)。

为什么这对您重要:如果您在构建任何跨多个会话运行的智能体,无界的内存会杀死您。不是立即的。随着时间的推移。您的智能体开始引用不再真实的事情,重复观察,并用噪音填充上下文。您需要某种形式的整合。autoDream 分叉只读子智能体的方法很干净,因为它不会意外地破坏智能体当前正在处理的任何内容。

2.3 工具架构

Claude Code 定义了 40 多个离散工具,每个都包裹在权限门控中。泄露中最大的文件是大约 29,000 行的 Tool.ts,定义了工具类型和权限模式。每个工具操作都通过 PermissionGate 结构进行细粒度访问控制。

三件事很突出:

  • 文件读取去重: 在重新读取文件之前,它会检查文件自上次读取以来是否已更改。如果没有,它会跳过读取并使用缓存版本。听起来很明显,但大多数智能体设置不这样做,而 token 节省会快速累积。
  • 大结果卸载: 当工具产生巨大结果(比如搜索大型代码库)时,它将完整结果写入磁盘,只将预览和文件引用传递回上下文。这保持了上下文窗口的清洁,同时仍然使数据可用。
  • 回合变更时 CLAUDE.md 重新插入: CLAUDE.md 文件不是只在开始时加载一次。它会在每个回合变更时(当模型完成并且用户发送新消息时)重新插入到对话中。不是在历史记录的顶部,而是在新消息发送的位置。这种重复注入保持模型与您的指令一致,即使在长时间对话中原始系统提示已经远离活动上下文。

如果您在使用 CLAUDE.md 文件(您应该这样做),最后一个细节很重要。您的指令不是一次性的入门读物。它们在对话过程中被积极地重新读取。这就是为什么结构良好的 CLAUDE.md 文件对智能体行为有如此大的影响。在运行了 1000 多个会话后,我写了如何构建我的 CLAUDE.md

2.4 多智能体协调

泄露揭示了协调器模式。一个 Claude 智能体充当领导者,生成并管理多个并行工作智能体。工作者在自己的隔离上下文中运行,具有受限的工具权限。它们通过 XML 结构化的任务通知进行通信,并通过暂存目录共享数据。协调器的系统提示强调"并行性是你的超能力"。

这里巧妙的实现细节:子智能体共享提示缓存。不是每个工作者都用自己的上下文启动(支付完整的输入 token 成本),它们都共享相同的上下文前缀,只在任务特定指令处分支。这就是使多智能体协调在经济上可行的原因。没有缓存共享,启动五个工作者意味着支付五倍的输入成本。有了它,您为共享上下文支付一次,只为任务特定部分增量付费。这可能就是为什么协调器模式尚未发布的原因。即使有这种优化,成本计算仍然很残酷。

这是我独立得出的相同模式。我构建了三个持久的领域团队,由一个 Opus 领导者规划和委派,以及执行的 Sonnet 专家。这里的趋同是具体的:规划的领导者智能体、并行执行的专业工作者、结构化通信、最终验证。

2.5 风险分类

操作被标记为低、中或高风险。有一个"YOLO 分类器"用于快速自动批准低风险操作。像 .gitconfig.bashrc 这样的受保护文件得到特殊处理。还有一个引用的"AFK 模式",在用户离开时调整行为。

三层。和我构建的一样。同样的推理:自主智能体需要知道哪些操作可以单独安全执行,哪些应该标记,哪些需要人工参与。这个与其说是启示,不如说是确认三层方法只是任何具有真实世界访问权限的智能体的正确默认值。

3、你现在就可以使用的五个模式

这是实用部分。这些是泄露中的模式,您可以应用到自己的 AI 智能体设置中,无论您是在构建复杂的东西,还是只是想从 Claude Code、Cursor 或任何 AI 编码工具中获得更多。

3.1 阻塞预算

KAIROS(泄露中未发布的始终在线守护进程)有一个 15 秒的阻塞预算。任何耗时更长的主动操作都会被延迟。每个窗口最多 2 条主动消息。响应式消息(响应用户输入)完全绕过预算。

为什么这很重要:如果您运行任何类型的主动智能体,无论是监控代码、发送通知还是检查事物,您都需要速率限制。不仅仅是"不要发送垃圾邮件"。针对主动工作和响应式工作的不同规则进行结构化速率限制。没有它,您的智能体最终会在 30 秒内发送 4 条消息,而 1 条就足够了。

我在阅读泄露的当晚就实现了这个。一个简单的状态文件跟踪预算窗口。主动消息排队并恢复。响应式消息立即通过。大约 50 行 Python。

3.2 带验证的怀疑性内存

不要信任您的智能体内存。让它验证。每次您的智能体说"我记得文件 X 有函数 Y"时,让它先检查。内存是提示。代码库是真相。

这是泄露中最实用的收获。如果您在使用 CLAUDE.md 文件、自定义系统提示或任何形式的持久上下文,请将它们视为需要验证的建议,而不是基本事实。文件被重命名。函数被删除。API 会更改。您的内存没有。

3.3 语义内存合并

autoDream 不仅仅是删除旧的内存。它合并相关的观察、移除逻辑矛盾,并将模糊的洞察转化为具体事实。如果您的智能体三个月前注意到"用户可能偏好 X",而昨天"用户确认了 X",旧条目应该被更新,而不是与新条目一起保留。

我见过的大多数内存系统(包括我之前的)都进行基于时间的清理。旧的东西被归档或删除。这对于防止内存膨胀很好,但它不能捕捉矛盾。两个相互矛盾的观察可以共存数月。语义合并解决了这个问题。

我使用本地 LLM(在 Mac Mini 上运行的 Qwen 9B)构建了一个版本,在夜间维护期间对相关条目进行聚类和合并。安全上限防止在单次传递中将任何部分减少超过 50%。您不需要做到这一步。即使是按主题对内存条目进行分组并标记潜在矛盾的简单脚本,也比纯粹基于时间的清理有所提升。

3.4 对抗性验证

泄露的协调器模式将验证视为一个独立的、对抗性的阶段,有自己的工作智能体。不是"检查这是否有效"。不是清单。一个单独的智能体,其工作是尝试破坏所构建的东西。

这与测试不同。测试问"它有效吗?"对抗性验证问"我如何破坏它?"区别很重要,因为构建某物的智能体对自己作品有盲点。一个具有明确提示"发现问题"的新智能体会捕捉到构建者遗漏的东西。

我将这个添加到我的夜班流程中。在任何任务被标记为完成之前,一个单独的验证智能体运行两个阶段:存在性检查(可交付成果是否真的存在?)和对抗性挑战(尝试破坏它)。结果进入验证日志。它发现了本会发布的真正问题。

3.5 提示缓存意识

源代码包含一个 promptCacheBreakDetection.ts 文件,监视 14 个不同的缓存中断向量,具有粘性锁存器。像模式切换、模型更改、上下文修改这样的事情。每个都可能使您的提示缓存失效,而缓存未命中意味着您在为本可以缓存的 token 支付全价。

如果您每天运行许多智能体会话,缓存效率直接影响您的成本。这个很容易被忽略,因为您看不到浪费。但如果您跟踪它(我现在这样做),您可能会发现您的缓存命中率比您假设的要低,并且工作流中的特定模式正在破坏它。

相关:源代码揭示了当上下文窗口填满时的五种不同的压缩策略。如果您大量使用过 Claude Code,您可能遇到过压缩然后失去跟踪正在做什么的时刻。这仍然是一个难题。但知道他们正在积极研究多种方法来解决它,告诉您这也值得在您自己的长期运行智能体上投入。

4、我一个晚上构建了什么

我不仅仅是阅读泄露。我把它当作学习练习并基于它构建东西。当晚,我实现了五个受泄露源码中模式启发的模块:

  1. 阻塞预算 用于主动消息。15 秒窗口,最多 2 条消息,延迟队列。
  2. 语义内存整合 使用本地 LLM 在空闲时间对观察进行聚类和合并。
  3. 挫败感检测 通过正则表达式模式匹配。21 个模式,三个操作层级(退后、承认、简化)。足够快,可以在每条传入消息上运行。
  4. 提示缓存监视器 跟踪命中率、估计节省,并在效率下降时发出警报。
  5. 对抗性验证 作为夜班执行循环中的正式阶段。

总时间:大约 4 小时的阅读和构建。我已经有基础(夜班内存系统、领域团队)。这些是在其上层叠的具体改进。

挫败感检测值得说明。泄露的代码使用正则表达式模式来检测用户的挫败感。像"wtf"、"this sucks"这样的关键词匹配。一家 LLM 公司使用正则表达式进行情感分析。但这是有道理的。您不会在 5 毫秒内就能模式匹配的事情上消耗 LLM 推理调用。我应用了相同的逻辑:21 个模式、快速评估、无需 API 调用开销的操作建议。

5、不值得你花时间的东西

并非泄露中的所有内容都有用。有些是 Anthropic 特有的,有些因为好的原因未发布,有些只是有趣但不实用。

伙伴系统。 电子宠物风格的终端宠物。18 个物种跨越稀有度层级,像 DEBUGGING、PATIENCE、CHAOS 这样的程序化状态。它真的很迷人,我有点喜欢它。但除非您是 Anthropic,想让 CLI 工具感觉更个性化,否则您不需要这个。

卧底模式。 从开源贡献中剥离 Anthropic 归属。适用于他们内部工作流,员工在公共仓库上使用 Claude Code。除非您有同样的问题(如果有,您可能已经知道了),否则不适用。

反蒸馏机制。 代码在 API 请求中注入虚假的工具定义,以毒害任何试图在拦截流量上训练模型的人。它还在将推理链返回给窃听者之前对其进行总结。从安全角度看很有趣。对构建智能体没有用。

超计划。 一种将复杂规划卸载到远程云容器的模式,运行 Opus 4.6 长达 30 分钟。酷概念。需要您可能没有的基础设施,以及一个不经常出现到足以证明构建它的用例。

原生客户端证明。 API 请求包含计算的哈希,证明它们来自合法的 Claude Code 二进制文件。在 JavaScript 运行时之下的 Bun 原生 HTTP 堆栈(用 Zig 编写)中实现。这是 API 调用的 DRM。有趣的工程,但不是您能够或应该复制的东西。

6、关于工具链本身的令人不安的事实

以下是大多数泄露报道没有提到的:Claude Code 实际上不是一个好的工具链。甚至差得远。

在终端基准测试上,Claude Code 排名第 39。有 38 个工具链-模型组合得分更高。如果您只筛选 Opus,Claude Code 在工具链中垫底。Cursor 的工具链让 Opus 从 77% 的分数提高到 93%。Claude Code 让同一个 Opus 模型……77%。工具链没有增加任何东西。

更有趣的是:当您在泄露的源代码中搜索"open code"(Anthropic 发出停止和终止函的开源 CLI 项目)时,您会发现 Claude Code 多次引用 Open Code 的源代码以匹配其行为。像滚动实现这样的事情。闭源项目在复制开源项目,而不是反过来。

所以这里真正有价值的不是工具链代码本身。有价值的部分是底层的架构模式:他们如何处理内存、上下文管理、多智能体协调,以及未发布的功能基础设施。实际的工具链?您可以从任何开源替代方案开始构建一个更好的。

代码质量本身……还行。分析时,它得分约 7/10。类型安全很扎实(在 500 多个文件中只有 38 个 any 实例)。错误处理体面。但有超过 5,000 行的"上帝文件",散落在 250 个文件中的一千多个功能标志引用,环境变量蔓延,以及日志记录前没有集中化的秘密清理。测试文件不包括在 source map 中(它们不会被包括),所以这影响了评估,但代码库有明显的技术债务。很多具体的、可操作的 TODO 注释看起来很旧。

对于这种规模的快速移动产品来说,这些都不罕见。但在您将泄露的代码视为参考实现之前,值得了解。模式值得研究。代码本身不是有些人所说的金标准。

7、未发布功能揭示了 Claude Code 的发展方向

泄露中的 44 个功能标志描绘了即将到来的图景。KAIROS 是大头:一个始终在线的后台智能体,主动行动、维护每日日志、订阅 webhook,并有自己的内存整合周期。它在源代码中被引用了 150 多次。预计将很快推出。

还有语音模式(按键通话界面)、计算机使用集成(截图捕获、点击和键盘输入内置到 CLI 中),以及用于多智能体编排的协调器模式。

如果您在使用今天的 Claude Code,值得知道这个工具正在朝着成为始终在线的守护进程的方向发展,而不仅仅是在需要帮助时调用的 CLI。我上面描述的模式(阻塞预算、内存整合、风险层级)都是这种转变的基础设施。

8、为什么这次泄露实际上对您有益

大多数关于这次泄露的评论都集中在它对 Anthropic 意味着什么。尴尬、竞争风险、安全影响。这是有效的,但不是很有用。

有用的是,这是第一个完整的、生产级 AI 智能体架构,被完全公开记录。不是研究论文。不是演示。是在 25 亿美元 ARR 规模上运行的实际代码。它证实了智能体构建社区中人们独立发现的模式在结构上是正确的。

我构建了一个交互式探索器,映射了整个智能体循环、所有 50 多个工具、架构系统和隐藏功能。如果您想在不阅读原始 TypeScript 的情况下可视化探索泄露的架构,从那里开始。

计划的自主执行。有界的带整合内存。多智能体委派。基于风险的自主层级。怀疑性自我验证。这些不是聪明的黑客。它们是对构建实际运行的智能体时出现的真实问题的趋同解决方案。我通过试错得出了它们中的大多数。在具有 80% 企业采用率的生产系统中看到相同的模式告诉我基础是稳固的。

构建严肃 AI 智能体的障碍低于行业的建议。您不需要研究实验室。您需要对几个特定问题的清晰思考:智能体何时应该无人监督地工作,内存应该如何保持有界,何时应该委派,以及哪些操作需要人工门控。一旦开始构建,答案就变得显而易见。在那之前,它们保持隐藏。


原文链接: Claude Code's Source Got Leaked. Here's What's Actually Worth Learning.

汇智网翻译整理,转载请标明出处