Claude Code 源码泄露深度解析:AI Agent 的工程护城河

点击 蓝字  👆  关注 Ciphra 希弗

嗨咯！我是Ciphra 希弗～

“一次 npm 发布的配置疏忽，意外暴露了 4756 个源文件。但真正值得抄走的，从来都不是 Prompt。”

一、泄露事件始末

2026年3月31日，Anthropic 在 npm 上发布 Claude Code v2.1.88 时，意外将 cli.js.map 文件包含在内。

这是一个 source map 文件，约 60MB，包含 4756 个源文件、51.2 万行代码。它完整暴露了 Claude Code 的 TypeScript 源码——从 System Prompt 到工具链架构，从多 Agent 调度到权限系统。

这不是 Claude Code 第一次”裸奔”。2025年2月曾发生过类似的泄露。而这一次，规模更大，内容更完整。

社区瞬间沸腾。无数人如获至宝，疯狂扒取 System Prompt，以为抄走这段”咒语”就能复刻一个顶级的 AI 程序员。

但他们都走偏了。

顺着入口、工具链、权限调度和 Hook 系统一路拆解下去，你会发现：Claude Code 之所以极其”稳”，根本不在于它多会写 Prompt，而在于其背后那套令人叹为观止的 工程架构。

这套架构，才是 Anthropic 真正的护城河。

二、为什么 Prompt 不是核心竞争力？

先厘清一个根本问题：Prompt 到底是什么？

Prompt 是给大模型的”指令文本”。它告诉 AI：”你是一个编程助手，你应该这样思考，你应该遵循这些规则……”

很多人以为，Prompt 就是 AI 产品的”灵魂”。只要拿到 Prompt，就能复制产品。

但这个理解是错的。原因有三：

2.1 Prompt 是”静态”的，执行是”动态”的

Prompt 只是一段文字。它告诉你”应该怎么做”，但不保证你”真的会这么做”。

就像给你一本《如何开飞机》，你读了，不代表你会开。

真正让 AI “会开飞机”的，是一整套执行系统——它决定了 AI 在各种复杂场景下如何做决策、如何处理异常、如何从错误中恢复。

2.2 Prompt 是”表面”的，架构是”深层”的

Prompt 更像是用户界面——你能看到、能理解的部分。

但 AI 产品真正复杂的地方，都在水面之下：

• 如何管理上下文窗口？
• 如何调度多个子任务？
• 如何处理工具调用的失败？
• 如何保证操作的安全性？

这些问题的答案，都在代码里，不在 Prompt 里。

2.3 Prompt 是”可复制”的，工程经验是”不可复制”的

Prompt 可以被抄走。但”为什么要这样设计”、”这个边界值为什么是 0.7 而不是 0.8″、”这个异常为什么要这样处理”——这些工程经验，是无数次试错换来的，抄不走。

所以，与其研究 Prompt 写了什么，不如研究 为什么它要这样写，以及 它背后的系统是如何支撑这些指令的。

三、架构深度解析：Claude Code 的五大设计哲学

3.1 平台级微服务架构：不只是”一个脚本”

市面上大多数开源 Coding Agent 的结构非常单薄：一个主脚本 + 一段 Prompt + 几个工具函数。

但 Claude Code 是一个标准的 平台级微服务架构。

它拥有四大独立入口：

• CLI 入口：命令行交互模式

• 初始化入口：项目环境配置

• MCP 入口：模型上下文协议服务

• SDK 入口：供第三方集成的开发包

更关键的是，它内置了庞大的 生命周期管理系统：

• 后台任务的中断与恢复
• 僵尸进程的检测与清理
• 脏状态的重置与回滚
• MCP 连接池的防泄漏

这些东西看起来”不性感”，但它们决定了产品能不能 长期稳定运行。

很多 Agent 产品第一天演示很完美，第二天就因为上下文错乱、进程卡死、状态污染而没法用了。

Claude Code 把”运行后勤”当成了头等大事。这是一种工程成熟度的体现。

3.2 Prompt 组装学与上下文经济学

Claude Code 的 System Prompt 不是一长串固定文本，而是被一套精密的 编排器 动态拼装出来的。

这套系统的核心是一个叫 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 的分界标记。

它把 Prompt 分成两个区域：

这背后的经济学逻辑非常精妙：

大模型 API 都按 Token 计费。每次调用，都要把 Prompt 发送给模型。如果你的 Prompt 有 10000 个 Token，每次调用都要付这 10000 个 Token 的钱。

但 Anthropic 提供了 Prompt Cache 功能：如果多次调用的 Prompt 前缀相同，这部分可以被缓存，费用大幅降低（通常是原价的 10%）。

Claude Code 的设计正是为了最大化利用这个特性：

• 把不变的内容放在前面 → 可以被缓存
• 把变化的内容放在后面 → 不影响缓存

更绝的是，当系统触发子 Agent 时，会刻意 对齐主线程的上下文前缀，就为了复用主线程的缓存。

这种对”上下文经济学”的极致压榨，是做 Demo 时完全不需要考虑的。但在商业产品里，能省下 巨额成本。

3.3 多 Agent 分工与权限隔离

这是 Claude Code 架构中最精彩的部分。

它不是”一个 AI 在干活”，而是 多个 AI 角色分工协作。

Explore Agent（探索者）

职责：摸清情况，理解项目结构。

关键约束：纯只读模式。

它被”物理阉割”了所有写权限——不能修改文件、不能运行 Bash 命令、不能改变任何系统状态。

为什么要这样设计？

因为”探索”这个阶段，AI 最容易”手滑”。它可能好奇地翻看各种文件，一不小心就改了什么。限制成只读，就杜绝了这种风险。

Plan Agent（规划者）

职责：制定计划，输出规格说明。

同样约束：纯只读模式。

它的任务是”想清楚怎么做”，而不是”动手做”。在计划没被确认之前，不允许碰代码。

Execute Agent（执行者）

职责：真正写代码、改文件。

拥有完整的写权限，但必须严格按照 Plan Agent 输出的规格来执行。

Verification Agent（验证者）

职责：检查执行结果是否正确。

这是整个系统中最关键的角色。

它的核心目标不是”看代码对不对”，而是 “想方设法搞坏它”（Adversarial Probes）。

它被强制要求：

• 必须跑通 Build
• 必须跑测试套件
• 必须抓取真实网络响应
• 必须尝试各种边界条件

为什么要这样设计？

因为大模型有一个致命弱点：它喜欢”自欺欺人”。

当你让 AI 自己检查自己的工作时，它很容易”睁一只眼闭一只眼”——”看起来差不多，应该没问题吧？”

解决这个问题的唯一方法，就是让”写代码的 AI”和”找茬的 AI”角色分离。

做裁判的，就不能下场踢球。

3.4 工具治理流水线：每一步都有”安检”

当 Claude Code 决定调用一个工具（比如修改文件）时，不是一步到位，而是要经过一条长长的 治理流水线：

1. 输入校验（Zod Schema）
   → 参数格式是否正确？类型是否匹配？
        ↓
2. 风险预判分类器
   → 这个操作有多危险？是"读文件"还是"删除整个目录"？
        ↓
3. Pre-Hook（执行前干预）
   → 用户是否配置了自定义钩子？需要拦截或修改参数吗？
        ↓
4. 核心权限系统仲裁
   → 当前模式下允许这个操作吗？需要用户确认吗？
        ↓
5. 实际执行
   → 调用工具完成操作
        ↓
6. Post-Hook（执行后处理）
   → 需要做哪些收尾工作？日志记录？状态更新？
        ↓
7. 异常恢复
   → 如果出错了怎么办？回滚？重试？报错？

这里的 Hook 系统尤其强大。它允许用户在工具执行前后插入自定义逻辑：

• 篡改输入参数
• 补充上下文信息
• 直接阻断流程
• 触发副作用

整个设计基于一个核心假设：事情一定会出岔子。

因此在每一步都埋下了兜底机制。绝不让一个写错正则的 Bash 命令毁掉整个项目。

3.5 反”甩锅”调度机制

在多 Agent 协同中，最怕的是 懒惰委派（Lazy Delegation）。

什么是懒惰委派？

主 Agent 没听懂用户要什么，就把模糊的需求直接丢给子 Agent → 子 Agent 瞎猜 → 结果完全跑偏

这就像一个经理，没搞清楚客户需求，就让下属”看着办”。结果必然是灾难。

Claude Code 在源码中专门立了规矩：禁止懒惰委派。

主 Agent 被强制要求承担”消化需求”的责任。给子 Agent 分配任务时，必须：

• 提供清晰的背景上下文
• 指定精准的文件路径和行号
• 明确要排除的干扰项
• 说明预期的输出格式

自己没想清楚，就不许派发任务。

这个看似简单的规则，实际上解决了一个非常深层的问题：责任链的清晰化。

在 AI 系统里，责任是最容易模糊的。当结果出错时，是 Prompt 的问题？是模型的问题？还是调度的问题？

通过强制”消化需求”这个步骤，Claude Code 确保了：每一个子任务都有明确的责任主体和清晰的边界。

四、从泄露看行业：AI Agent 的 2026

这次泄露事件，也让我们有机会重新审视整个 AI Agent 行业的现状和趋势。

4.1 AI Coding Agent 市场格局

值得注意的是，这些产品的差距正在缩小。Cursor 和 Windsurf 在 2026 年已经”打平”——同样的价格、相似的上下文窗口、重叠的 Agent 能力。

真正的差异化，将越来越体现在 底层架构的稳定性 和 多 Agent 协作的成熟度 上。

4.2 MCP 协议：AI Agent 的”USB 标准”

Claude Code 源码中大量使用的 MCP（Model Context Protocol），正在成为行业共识。

MCP 解决的是一个核心痛点：工具集成的碎片化。

在 MCP 诞生前，每个 AI Agent 都要自己实现一套连接数据库、文件系统、网络服务的接口。工具开发者要为每个 Agent 单独写适配器。

MCP 的价值在于 标准化：

• 工具开发者只需实现一次 MCP 接口
• 任何支持 MCP 的 Agent 都能直接使用
• 工具能力可以跨 Agent 复用

这就像 USB 标准——任何设备只要符合 USB 协议，就能插到任何电脑上用。

2026年，MCP 正在成为多模型协作的 行业标准。

4.3 多 Agent 架构：从”单打独斗”到”团队协作”

行业共识正在形成：2026 年是从单一助手转向多 Agent 编排系统的关键一年。

从 2024-2025 年的”单一 AI 对话循环”，进化到 2026 年的”复杂多 Agent 系统”，这个趋势与 Claude Code 源码中展示的架构完全吻合。

未来的 AI 产品，不会是”一个超级智能”，而是”一群专业助手”——有人负责探索，有人负责规划，有人负责执行，有人负责验证。

这种架构的复杂度远高于单一 Agent，但它的 可靠性 和 可扩展性 也强得多。

五、工程原则提炼：我们可以学到什么？

撕开 Claude Code 华丽的伪装，它给我们留下了五条极具价值的 AI 工程原则：

原则一：不要迷信大模型的”自觉性”

大模型不会自己变谨慎、变可靠。好的行为规范必须写成 铁律，风险操作必须有 硬性拦截。

系统设计时，永远假设模型会犯错、会越界、会偷懒。然后用制度来约束它。

原则二：实现与验证必须解耦

让 AI 自己检查自己的工作，永远是不可靠的。

解决”自欺欺人”问题的唯一方法，就是 角色分离：写代码的是一个 AI，找茬的是另一个 AI。

做裁判的，就不能下场踢球。

原则三：工具调用需要层层设卡

没有任何工具应该被模型无监督地随意调用。

输入校验、风险预判、权限仲裁、异常恢复——这套治理流水线是必需品，不是可选项。

每多一道关卡，就少一个生产事故。

原则四：管好你的上下文钱包

上下文窗口是稀缺资源，Token 就是钱。

能缓存的要缓存，能压缩的要压缩，能按需加载的绝不要一次性塞满。

Prompt Cache 的设计，不是”优化”，而是”生存”。

原则五：生态的本质是”认知注入”

接了插件不算完。你得想办法把工具清单、使用说明、最佳实践塞进模型的”脑子”里。

MCP 解决了”怎么调用”的问题，但”什么时候调用”、”怎么用好”的问题，需要更深层的设计。

六、结语

Claude Code 的源码泄露，给了整个行业一次难得的学习机会。

但真正值得抄走的，从来都不是那些 Prompt 文本，而是一套将 “行为约束、工具防错、分工制衡、Token 算计与生命周期” 无缝咬合的工程闭环系统。

正如一位开发者所言：

“做 Demo 可以靠 Prompt，做产品必须靠架构。”

Prompt 决定了 AI 的”上限”——它有多聪明、多有创造力。

但架构决定了 AI 的”下限”——它有多稳定、多可靠、多安全。

在商业产品的世界里，下限往往比上限更重要。

补齐这些短板，你的 Agent 也能从”聪明的玩具”进化为”生产力工具”。