Claude Code 源码泄露后值得学习的智能体架构

我花了一整晚阅读代码并基于它构建东西。如果你正在构建 AI agent，以下是值得关注的内容。 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 如何管理工具、记忆、上下文、权限和多 agent 协调。 这不是传统意义上的安全漏洞。这是一个本应从 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，你可能会拉取到恶意代码。要小心。 我已经构建自己的 AI agent 好几个月了。它在一台专用 Mac Mini 上 24/7 运行。所以当这次泄露发生时，我读它不是为看热闹。我读它是为了学习。我花了一整晚梳理架构，将其与我构建的东西进行比较，并提取任何有用的内容。 如果你正在构建 AI agent 或想了解这项技术实际走向何方，以下是值得关注的内容。 这可能是泄露中最重要的架构发现。Claude Code 使用一个具有三层的记忆系统： 1. 核心索引（MEMORY.md）：一个轻量级的指针文件，始终加载到上下文中。每个条目不超过 150 个字符。它是索引，不是记忆本身。 2. 主题文件：分布在独立文件中的详细知识，当索引表明它们相关时按需获取。 3. 原始转录：从不完整重读。仅在需要时对特定标识符进行 grep。 关键洞察是他们所谓的“怀疑式记忆”。agent 将自己的记忆视为提示，而非事实。在根据它记得的事情行动之前，它会对照实际代码库进行验证。记忆说某个函数存在？先检查。记忆说某个文件在这个路径？使用前先验证。 这解决了上下文熵问题，即 agent 在长时间运行的会话中性能逐渐下降。大多数 agent 运行时间越长表现越差，因为它们的上下文被过时的观察填满。这种架构保持活跃上下文很小（仅索引），只加载所需内容。 我一直在运行类似的模式：按计划轮换的工作记忆和跨会话持久存在的永久索引。这次泄露证实了这是正确的方法。验证步骤是我现在要添加到我自己系统中的东西。 泄露中包含一个名为 autoDream 的系统，位于 services/autoDream/ 目录中。它是一个后台记忆整合引擎，作为对项目具有只读访问权限的 fork 子 agent 运行。运行前必须通过三道关卡：距上次运行已过 24 小时、至少完成 5 个会话、且整合锁必须可用。 触发时，它运行四个阶段：定位（扫描记忆目录）、收集（从日志中提取新信息）、整合（写入和更新主题文件）、修剪（保持总记忆在 200 行和 25KB 以下）。 为什么这对你重要：如果你正在构建任何跨多个会话运行的 agent，无界记忆会害死你。不是立即。而是几周后。你的 agent 开始引用不再真实的东西，重复观察，用噪音填满上下文。你需要某种形式的整合。autoDream 的 fork 只读子 agent 的方法很干净，因为它不会意外破坏 agent 当前正在处理的任何东西。 Claude Code 定义了 40+ 个离散工具，每个都包裹在权限门中。泄露中最大的文件是 Tool.ts ，约 29,000 行，定义了工具类型和权限模式。每个工具操作都经过一个 PermissionGate 结构进行细粒度访问控制。 有三件事很突出： - 文件读取去重：在重新读取文件之前，它会检查文件自上次读取以来是否发生了变化。如果没有变化，就跳过读取并使用缓存版本。听起来显而易见，但大多数智能体配置并不会这样做，而节省的 token 会快速累积。 - 大结果卸载：当工具产生大量结果时（例如搜索大型代码库），它会将完整结果写入磁盘，只将预览和文件引用传回上下文。这能保持上下文窗口整洁，同时仍让数据可用。 - 轮次变更时重新插入 CLAUDE.md：该 CLAUDE.md 文件并非只在开始时加载一次。它会在每次轮次变更时（当模型完成且用户发送新消息时）被重新插入对话中。不是放在历史记录顶部，而是正好放在新消息发送的位置。这种重复注入能让模型即使在长对话中、原始系统提示已远远滚出活跃上下文时，仍与你的指令保持一致。 如果你正在使用 CLAUDE.md 文件（你应该使用），最后这个细节很重要。你的指令不是一次性的入门材料。它们会在整个对话中被主动重新读取。这就是为什么结构良好的 CLAUDE.md 文件会对智能体行为产生如此大的影响。我在运行了 1000 多次会话后，写过我是如何组织自己的文件的。 泄露内容揭示了 Coordinator Mode。一个 Claude 智能体作为主导者，并行生成和管理多个工作智能体。工作智能体在各自隔离的上下文中运行，工具权限受限。它们通过 XML 结构的任务通知进行通信，并通过一个暂存目录共享数据。协调者的系统提示强调“并行是你的超能力”。 这里巧妙的实现细节是：子智能体共享提示缓存。每个工作智能体不是带着自己的上下文启动（支付完整的输入 token 成本），而是共享相同的上下文前缀，只在任务特定指令处分叉。这正是多智能体协调在经济上可行的原因。没有缓存共享，启动五个工作智能体意味着支付五倍的输入成本。有了它，你只需为共享上下文支付一次，只为任务特定部分增量付费。这很可能就是 Coordinator Mode 尚未发布的原因。即使有这种优化，成本计算仍然很残酷。 这与我独立得出的模式相同。我构建了三个持久领域团队，由 Opus 主导者负责规划和委派，由 Sonnet 专家负责执行。这里的趋同很具体：规划的主导智能体、并行执行的专家工作智能体、结构化通信、最后的验证。 操作会被标记为 LOW、MEDIUM 或 HIGH 风险。有一个“YOLO 分类器”用于快速自动批准低风险操作。像 .gitconfig 和 .bashrc 这样的受保护文件会得到特殊处理。还有一个被提及的“AFK Mode”，会在用户离开时调整行为。 三个层级。和我构建的一样。同样的理由：自主智能体需要知道哪些操作可以安全地单独执行，哪些应该被标记，哪些需要人类介入。这一点与其说是新发现，不如说是确认了三层方法就是任何具有真实世界访问权限的智能体的正确默认设置。 下面是实用部分。这些是泄露内容中的模式，你可以将它们应用到自己的 AI 智能体配置中，无论你是在构建复杂系统，还是只是想从 Claude Code、Cursor 或任何 AI 编码工具中获得更多价值。 KAIROS（泄露内容中未发布的常驻守护进程）有 15 秒的阻塞预算。任何会耗时更长的主动操作都会被推迟。每个窗口最多 2 条主动消息。响应式消息（响应用户输入）完全绕过该预算。 为什么这很重要：如果你运行任何类型的主动智能体，无论是监控代码、发送通知还是检查事项，你都需要速率限制。不只是“不要刷屏”。而是结构化速率限制，对主动工作和响应式工作采用不同规则。没有它，你的智能体最终会在一条消息就够的情况下，30 秒内发送 4 条消息。 我在读到泄露内容的当晚就实现了这一点。一个简单的状态文件跟踪预算窗口。主动消息会被排队并恢复。响应式消息立即通过。大约 50 行 Python。 不要相信你的智能体的记忆。让它验证。每当你的智能体说“我记得文件 X 有函数 Y”时，让它先检查。记忆是提示。代码库才是真相。 这是泄露内容中最实用的单一要点。如果你正在使用 CLAUDE.md 文件、自定义系统提示或任何形式的持久上下文，请将它们视为需要验证的建议，而不是事实真相。文件会被重命名。函数会被删除。API 会变化。你的记忆不会。 autoDream 不只是删除旧记忆。它会合并相关观察、移除逻辑矛盾，并将模糊洞察转化为具体事实。如果你的智能体三个月前记录“用户可能偏好 X”，而昨天记录“用户确认了 X”，那么旧条目应该被更新，而不是与新条目并存。 我见过的大多数记忆系统（包括我此前自己的系统）都做基于时间的清理。旧内容会被归档或删除。这对防止记忆膨胀没问题，但它捕捉不到矛盾。两个相互冲突的观察可以共存数月。语义合并能解决这个问题。 我用本地 LLM（在 Mac Mini 上运行的 Qwen 9B）构建了一个版本，用于在夜间维护期间对相关条目进行聚类并合并。一个安全上限防止单次处理将任何部分减少超过 50%。你不需要做到这个程度。即使只是一个按主题对记忆条目分组并标记潜在矛盾的简单脚本，也比纯粹基于时间的清理更进一步。 泄露的 Coordinator Mode 将验证视为一个独立的对抗性阶段，拥有自己的工作智能体。不是“检查这是否有效”。不是清单。而是一个独立智能体，其职责是尝试破坏已构建的东西。 这与测试不同。测试问的是“它能工作吗？”对抗性验证问的是“我怎样才能破坏它？”这种区别很重要，因为构建某物的智能体对自己的工作存在盲点。一个带着明确提示“找出其中的问题”的全新智能体会捕捉到构建者遗漏的东西。 我把这个加进了我的夜班流程。在任何任务被标记为完成之前，一个独立的验证代理会运行两个阶段：存在性检查（交付物是否真的存在？）和对抗性挑战（尝试攻破它）。结果会写入验证日志。它已经抓到了原本会被交付出去的真实问题。 源码中包含一个 promptCacheBreakDetection.ts 文件，用粘性锁存器监控 14 种不同的缓存破坏向量。比如模式切换、模型变更、上下文修改。每一种都可能使你的提示缓存失效，而缓存未命中意味着你要为本可缓存的 token 支付全价。 如果你每天运行大量代理会话，缓存效率会直接影响你的成本。这一点很容易被忽视，因为你看不到浪费。但如果你跟踪它（我现在就在跟踪），你很可能会发现缓存命中率比你假设的要低，而且工作流中的某些特定模式正在破坏它。 相关：源码揭示了上下文窗口填满时使用的五种不同的压缩策略。如果你大量使用过 Claude Code，你可能遇到过它压缩之后就跟不上自己正在做什么的时刻。这仍然是个难题。但知道他们正在积极研究多种方法来解决它，说明这对你自己的长时间运行代理也值得投入。 我不只是读了泄露内容。我把它当作一次学习练习，并基于它构建了东西。就在当晚，我受泄露源码中的模式启发实现了五个模块： 1. 主动消息的阻塞预算。15 秒窗口，最多 2 条消息，延迟队列。 2. 语义记忆整合，使用本地 LLM 在空闲时间对观察结果进行聚类和合并。 3. 通过正则模式匹配进行挫败感检测。21 种模式，三个行动层级（退让、确认、简化）。快到可以在每条传入消息上运行。 4. 提示缓存监控器，跟踪命中率、估算节省量，并在效率下降时发出警报。 5. 对抗性验证作为夜班执行循环中的一个正式阶段。 总时间：大约 4 小时的阅读和构建。我已经有了基础（夜班、记忆系统、领域团队）。这些是叠加在上面的具体改进。 挫败感检测这一项值得提一下。泄露的代码使用正则模式来检测用户挫败感。比如“wtf”、“this sucks”、关键词匹配。一家 LLM 公司用正则做情感分析。但这很合理。你不会为了一件 5 毫秒就能模式匹配的事情去消耗一次 LLM 推理调用。我应用了同样的逻辑：21 种模式，快速评估，无需 API 调用开销就能给出行动建议。 泄露内容中并非所有东西都有用。有些是 Anthropic 特有的，有些出于充分理由尚未发布，还有些只是有趣但不实用。 Buddy System。一个 Tamagotchi 风格的终端宠物。18 个物种，分属不同稀有度层级，程序化属性如 DEBUGGING、PATIENCE、CHAOS。它确实很讨喜，我还有点喜欢它。但除非你是 Anthropic，想让 CLI 工具感觉更个性化，否则你不需要这个。 Undercover Mode。从开源贡献中剥离 Anthropic 归属信息。这是他们内部工作流特有的，员工在公共仓库上使用 Claude Code。除非你有同样的问题，否则不适用（如果你有，你可能已经知道了）。 反蒸馏机制。代码向 API 请求中注入伪造的工具定义，以毒化任何试图用截获流量训练模型的人。它还会在将推理链返回给窃听者之前对其进行摘要。从安全角度看很有趣。对构建代理没有用。 ULTRAPLAN。一种将复杂规划卸载到运行 Opus 4.6 的远程云容器、最长 30 分钟的模式。概念很酷。需要你很可能没有的基础设施，以及一个不常出现到足以证明值得构建它的用例。 原生客户端证明。API 请求包含计算出的哈希，证明它们来自合法的 Claude Code 二进制文件。实现在 Bun 原生 HTTP 栈（用 Zig 编写）的 JavaScript 运行时之下。这是 API 调用的 DRM。工程上很有趣，但不是你能或应该复制的东西。 这里有一点是大多数关于泄露的报道没有提到的：Claude Code 实际上并不是一个好的 harness。差得远。 在终端基准测试中，Claude Code 排名第 39。有 38 个 harness-模型组合得分高于它。如果只筛选 Opus，Claude Code 在所有 harness 中垫底。Cursor 的 harness 让 Opus 从 77% 的得分提升到 93%。Claude Code 用同一个 Opus 模型……77%。这个 harness 没有增加任何价值。 更有趣的是：当你在泄露源码中搜索“open code”（Anthropic 向其发送了停止侵权函的开源 CLI 项目）时，你会发现 Claude Code 多处引用 Open Code 的源码来匹配其行为。比如滚动实现。这个闭源项目在抄袭开源项目，而不是反过来。 所以这里真正有价值的不是 harness 代码本身。有价值的部分是底层的架构模式：他们如何处理记忆、上下文管理、多代理协调，以及未发布功能的基础设施。实际的 harness？你可以用任何开源替代品作为起点，构建一个更好的。 代码质量本身……还行。分析时得分大约 7/10。类型安全很扎实（500 多个文件中只有 38 处 any ). 错误处理还不错。但存在每个 5,000 多行的“上帝文件”，250 个文件中散落着一千多处功能标志引用，环境变量到处蔓延，日志记录前没有集中的秘密清理。测试文件没有包含在源码映射中（它们也不会被包含），所以这会影响评估，但代码库有明显技术债务。大量具体、可操作的 TODO 注释看起来已经很久了。 对于这个规模的快速迭代产品来说，这些都不罕见。但在你把泄露代码当作参考实现之前，值得了解这一点。模式值得研究。代码本身并不是有些人说的那样是黄金标准。 泄露中的44个功能标志描绘了即将到来的图景。KAIROS是其中最重要的一个：一个始终在线的后台代理，能够主动行动、维护每日日志、订阅webhook，并拥有自己的记忆整合周期。它在源代码中被引用了150多次。预计很快就会推出。 此外还有语音模式（按键说话界面）、计算机使用集成（截图捕获、点击和键盘输入内置于CLI中），以及用于多代理编排的协调器模式。 如果你今天正在使用Claude Code，值得了解的是，该工具正朝着始终在线的守护进程方向发展，而不仅仅是你需要帮助时才调用的CLI。我上面描述的模式（阻塞预算、记忆整合、风险层级）都是这一转变的基础设施。 关于这次泄露的大多数评论都集中在它对Anthropic意味着什么。尴尬、竞争风险、安全影响。这有道理，但不太有用。 有用的是，这是第一个在公开场合被完整记录的、生产级AI代理架构。不是研究论文。不是演示。而是在25亿美元ARR规模下运行的实际代码。它证实了代理构建社区的人们独立发现的模式在结构上是正确的。 我构建了一个交互式探索器，映射了整个代理循环、所有50多个工具、架构系统和隐藏功能。如果你想在不阅读原始TypeScript的情况下直观地探索泄露的架构，从那里开始。 定时自主执行。有界记忆与整合。多代理委托。基于风险的自主层级。怀疑式自我验证。这些不是聪明的技巧。它们是对构建真正运行的代理时出现的真实问题的趋同解决方案。我通过反复试验得出了其中大部分。在一个拥有80%企业采用率的生产系统中看到相同的模式，告诉我基础是坚实的。 构建严肃AI代理的门槛比行业所暗示的要低。你不需要研究实验室。你需要对几个具体问题进行清晰思考：代理何时应在无人监督下工作，记忆应如何保持有界，何时应进行委托，以及哪些操作需要人工把关。一旦你开始构建，答案就会变得显而易见。在你开始之前，它们一直隐藏着。 我写关于构建和运行AI代理的内容。不是理论。是在真实硬件上24/7运行的系统。 我已经用泄露中的这些架构模式更新了Claude Code Workshop：阻塞预算、怀疑式记忆、语义整合、对抗性验证和缓存优化。 如果你已经拥有它，获取新版本。如果你没有，它涵盖了技能、自动化以及在数月日常使用后真正持久有效的模式。 感谢阅读Digital Thoughts！这篇文章是公开的，所以请随意分享。 分享