Claude Code架构深度解析：泄露源码揭示了什么
Claude Code泄露的源码暴露了512K行生产级TypeScript代码。以下是完整的架构解析——工具系统、查询引擎、多智能体模式与上下文压缩。
大家好，我是 Dora。2026 年 3 月，我并没有打算深挖什么。一条消息出现在我的信息流里：“Claude Code 的源代码通过其 npm 注册表中的 map 文件泄露了。”
我关掉了当前的标签页，头也不回。
接下来是我研究一款量产 AI 工具实际构建方式中，最真正有趣的一个下午。不是因为泄露事件本身——那种热度来得快去得也快——而是因为这份代码本身是件稀罕事：一个真实交付、在商业上占据主导地位的 Agentic CLI，以 512,000 行的细节呈现在眼前。
以下是我的发现。
为何泄露的源代码是难得的架构研究机会
Claude Code 泄露后，源代码浮出水面——通过 Anthropic 自家 npm 包中一个配置有误的 .map 文件暴露——开发者们很快意识到，这并非一个套在聊天 API 外面的包装器。根据 cybersecuritynews.com 对该事件的分析，此次泄露涉及约 1,900 个文件、超过 512,000 行严格类型的 TypeScript，仅主入口文件就达 785KB。
技术栈本身就已经很有意思：运行时是 Bun（而非 Node.js），终端 UI 渲染使用 React 搭配 Ink，全程采用 Zod v4 进行 Schema 校验。在 CLI 中使用 React 组件模式，意味着要在终端内处理状态管理、重新渲染和可组合的 UI 组件。这是一个经过深思熟虑的、大胆的选择。
值得研究它的理由，远不止是表情包：Claude Code 架构中的这些模式，同样适用于任何正在构建严肃 Agentic 系统的团队。
工具系统——40 余个自包含、权限隔离的模块
首先让我印象深刻的，是工具系统的隔离有多干净。每个工具都独立定义自己的输入 Schema、权限级别和执行逻辑。工具之间没有共享的可变状态偷偷流窜。
BashTool 和 FileReadTool 同处一个注册表，但风险特征截然不同。Bash 执行会改变系统状态；文件读取是只读的。架构对此区别对待，为每个工具设置独立的权限层级，而非统一使用一个宽泛的策略。这种分离在量产 Agentic 系统中至关重要——权限模型在工具间泄漏，是迟早会爆发的安全和可靠性隐患。
AgentTool 是最妙的一个。它让系统能够像普通工具调用一样派生子 Agent——无需专门的编排层，也不需要独立的进程模型。子 Agent 是同一个工具注册表的一等公民。这个设计决策保持了架构的扁平性和可预测性。
仅工具基础定义一项就跨越约 29,000 行 TypeScript。这不是臃肿——而是严格的 Schema 校验、权限执行和错误处理在这种规模下真实的样子。Anthropic 官方 Claude Code 文档印证了这种以工具为核心的理念：工具，才是让系统具备 Agentic 能力的根本所在。
46,000 行的查询引擎——Claude Code 真正的大脑
QueryEngine.ts 有 46,000 行。请先消化一下这个数字。
这个模块负责处理所有 LLM API 调用、流式传输、缓存和编排——全部在一个文件里。这听起来像是一个危险信号——根据你的代码库规范，质疑它完全合理——但其中的逻辑是自洽的：所有接触模型 API 的代码都在一个地方，这意味着重试逻辑、速率限制处理、上下文预算管理和流式错误都被放在一起统筹考虑。
自愈查询循环是最出乎我意料的部分。当上下文预算接近上限时，引擎不会崩溃，也不会请求人工介入。它会自动触发压缩，在触及上限之前开辟出一个缓冲区，并生成一份关于已讨论内容的结构化摘要。这不是临时补丁——这是经过设计的行为。对于任何构建长时运行 Agent 会话的人来说，这个模式直接值得深入研究。
多 Agent 编排——协调者、工作者与邮箱模式
多 Agent 系统对危险操作使用了泄露源代码中所称的邮箱模式。实际含义是这样的：一个正在执行任务的工作 Agent，无法自行批准高风险操作。相反，它会向协调者的邮箱发送一条请求，然后等待。协调者评估后，选择批准或拒绝。
原子声明机制防止两个工作者同时处理同一条审批请求——在任何具有并行执行的系统中，这是一个细微却至关重要的细节。所有 Agent 共享同一内存空间，意味着整个团队无需冗余地重新获取，就能保持上下文的连贯性。
这与那种每个 Agent 都拥有完全自主权的朴素多 Agent 设计，有着实质性的不同。带有审批门控的协调者/工作者分工，是在不引发混乱的前提下实现并行的方法。构建自己的 Agentic 系统编排层的团队，在设计之前不妨先通读一下 Anthropic 的 Agentic 模式文档。
三层上下文压缩——为长时会话而设计的工程
对于任何构建量产 AI 应用的人来说，这可能是整个代码库中最具直接参考价值的工程设计。
Claude Code 使用三种不同的压缩策略，各自在不同时机触发：
MicroCompact 在本地编辑缓存内容，零 API 调用。旧的工具输出被直接裁剪。快速、低成本、透明。
AutoCompact 在对话接近上下文窗口上限时触发。它预留 13,000 个 Token 的缓冲区，然后生成最多 20,000 个 Token 的会话结构化摘要。内置断路器——连续三次压缩失败后停止重试。没有无限循环。
Full Compact 压缩整个对话，然后重新注入最近访问的文件（每文件上限 5,000 个 Token）、活跃计划和相关 Skill Schema。压缩后，工作预算重置为 50,000 个 Token。
值得注意的是，这个架构对那些完全跳过压缩的工具意味着什么。不管理上下文预算的 Agentic 工具，在规模化时会直接失败——悄无声息地降级，或触发硬性错误。三层方案是从一开始就为会话持久性而设计的罕见案例，而非事后补丁。
特性标志即架构——108 个在生产环境中不存在的模块
泄露源代码中一个讨论较少的发现：108 个特性门控模块，通过 Bun 的编译期死代码消除，从外部构建中剔除。
KAIROS、VOICE_MODE、DAEMON——这些在你安装的版本中并不存在。代码存在于源代码中，但 Bun 在编译期根据特性标志配置将其消除。生产包干净地交付。这就是如何在不动用户手中已有版本的情况下，迭代新能力。
有一个广为记录的讽刺之处：Undercover Mode——一个专门防止内部代号出现在 git 提交或输出中的子系统——出现在了泄露的源代码里。这个为防止泄露而构建的系统，没能阻止泄露本身。这不是灾难性的安全失败，但它对软件交付流水线中风险真正积聚的位置，是一次有教育意义的提醒。
内置于核心循环的遥测
泄露源代码中有两个遥测信号，让我反复回味：
一个挫败感指标追踪骂人词频作为 UX 信号。如果用户在对着工具骂街，说明某些地方坏掉了——这是一个领先指标，而非滞后指标。
一个 “continue” 计数器追踪用户在会话中输入”continue”的频率。对于一个 Agentic CLI，这是停滞的代理指标——Agent 失去动力、人类不得不推一把的时刻。
这两个都不是虚荣指标。两者都能浮现出标准分析工具会错过的具体失败模式。如果你在构建任何具有长时交互会话的 AI 产品，以这种方式对 Agent 行为进行埋点，是值得投入的工程时间。
这对构建者的技术选型意味着什么
研究这份 Claude Code 架构之后，坦诚的收获是：从零开始构建一个量产 Agentic CLI，是一项相当可观的工程投入。工具系统、查询引擎、多 Agent 编排、上下文压缩和遥测，合在一起代表的是数年的迭代，而非数月。
这不是反对自建的理由。这是一个提醒，要清楚地认识到自己在承担什么。邮箱审批系统和三层压缩这样的模式是可以移植的——你不需要 512,000 行代码才能实现核心思路。
自建与采购的考量发生转变的地方，在于模型访问和聚合。这个架构假定直接访问单一模型提供商。跨多个模型提供商工作、或需要保持模型无关性的团队，面对的是一套完全不同的权衡。
这里的模式值得借鉴。在决定复现它之前，其复杂性值得充分理解。
常见问题
Claude Code 的工具系统与标准函数调用有何不同？
标准函数调用将工具视为一个扁平列表。Claude Code 在每个工具上增加了独立的权限门控、隔离的执行上下文，以及在每个边界处的 Schema 校验——防止跨工具状态泄漏，并强制执行最小权限访问。当 BashTool 可以修改系统状态时，这一点尤为重要。
什么是邮箱模式，构建者应该在什么时候使用它？
它将危险操作从工作 Agent 路由到协调者进行审批，而不是自主执行。任何时候只要你有并行 Agent 执行，并且需要针对高风险操作引入人工介入或分级审批机制，就应该使用它。吞吐量有成本，安全有收益。
Claude Code 如何在大规模使用中处理上下文窗口限制？
三层压缩：MicroCompact（本地编辑，无 API 成本）、AutoCompact（接近上限时触发，生成带预留 Token 缓冲区的结构化摘要）、Full Compact（全量对话压缩，并选择性地重新注入文件）。专为无需人工干预的长时会话而设计。
什么是编译期特性标志，量产 AI 工具为何使用它们？
它们允许未发布特性的代码存在于源代码中，而不会出现在生产构建里。Bun 在编译期消除被关闭的代码，外部用户永远不会遇到尚未就绪的特性——将上线与就绪分离开来。
研究泄露的源代码并将其作为架构灵感来源，是否合法？
需要谨慎对待。泄露的源代码是 Anthropic 的知识产权。将架构模式用于教育目的进行研究，与直接复制代码处于不同的法律领域。Anthropic 官方文档仍然是你在其系统之上进行构建时的正确参考。如有疑问，请咨询你自己的法律顾问。
我一直萦绕心头的，是这套架构有多大程度上是关于优雅地管理失败。压缩上的断路器、危险操作的邮箱模式、工具间的权限隔离——这些都不是乐观主义的设计。它们是由那些曾亲眼看着事情出错、并决心在工程层面绕过它的人构建的。
这是一种不同于追求功能迭代速度的成熟。
好了，今天的分享到此结束。下次见。
