Claude Code源码泄露后的真相：它不是聊天机器人，是Agent操作系统

先说个有意思的事。

2026年3月31日，Anthropic的Claude Code源码泄露了。512,000行TypeScript，GitHub史上最快增长——50,000 stars in 2 hours，现在已经超过110,000。

很多人都在找那个”神秘的system prompt”。

结果呢？确实找到了。但真正让人震惊的，不是prompt写了什么，而是这512,000行代码背后暴露出的架构真相：

Claude Code根本不是”一个会调工具的聊天机器人”，它是一个Agent Operating System。

一、为什么这件事会改变研发逻辑？

你可能会问：不就是源码泄露吗？有什么大不了的？

大问题在于：它暴露了一个范式转移。

过去两年，所有coding agent都在走同一个路子：

• 一个system prompt
• 几个文件编辑工具
• 一个bash工具
• 一个CLI壳

很多人以为这就是终点。只要prompt写得够好，模型够聪明，就能做出好产品。

但Claude Code的源码告诉你：这条路走错了。

它不是靠一个prompt撑起来的，而是靠一整套系统：

这就解释了一个困扰很多人的问题：

为什么Claude Code的手感比其他coding agent稳那么多？

不是因为Anthropic用了更强的模型，而是因为它把”好行为”制度化成了系统。

二、Prompt不是文本，是编排器

这是源码里最让人意外的发现之一。

很多人以为system prompt就是一段静态文案。但Claude Code的prompts.ts告诉你：prompt是runtime assembly。

2.1 静态前缀与动态后缀

源码里有个关键设计：SYSTEM_PROMPT_DYNAMIC_BOUNDARY。

边界前是静态部分：

• 身份定位（interactive agent）
• 基础系统规范（runtime reality）
• 做任务哲学（行为约束）
• 风险动作规范（blast radius）
• 工具使用规范（tool grammar）
• Tone and style（产品质感）

边界后是动态部分：

• Session-specific guidance（当前会话约束）
• Memory prompt
• MCP instructions（按连接状态注入）
• Language/output style
• Token budget
• Brief/proactive等feature-gated section

这个设计值钱在哪？

它不是”把能想到的都写进prompt”，而是把prompt当作可编排的runtime资源来管理。

2.2 Prompt cache economics

源码注释里明确说：

边界前尽量可cache 边界后是用户/会话特定内容 不能乱改，否则会破坏cache逻辑

这说明Claude Code已经不是”会写prompt”，而是在做：

Prompt assembly with cache economics

也就是说，它连system prompt的token成本与缓存命中都做了工程化优化。

普通人只想”prompt能跑”，Claude Code想的是”prompt能跑，而且尽量复用cache，不白烧token”。

这就是产品级系统思维。

三、Agent不是万能worker，是分工系统

这是源码里最核心的设计之一。

3.1 三大built-in agents

Claude Code不是让一个agent什么都做，而是明确分工：

3.2 ExploreAgent：为什么只读这么重要？

源码里明确规定：

不能创建文件 不能修改文件 不能删除文件 不能移动文件 不能写临时文件 不能用重定向/heredoc写文件 不能运行任何改变系统状态的命令

只允许：

• Glob/Grep/FileRead
• Bash只允许读操作：ls, git status, git log, git diff, find, grep, cat, head, tail

为什么要这么极端？

因为探索和实现是两回事。

很多coding agent的问题，就是让一个agent既研究、又规划、又实现、又验收。最终哪件事都不够稳定。

Claude Code的做法是：把探索裁成read-only specialist，降低角色混杂。

3.3 VerificationAgent：对抗式验证的价值

这是源码里最让人印象深刻的设计之一。

它的prompt开头就点出两类失败模式：

1. verification avoidance：只看代码、不跑检查、写PASS就走
2. 被前80%迷惑：UI看起来还行、测试也过了，就忽略最后20%的问题

然后强制要求：

• build
• test suite
• linter/type-check
• 根据变更类型做专项验证
• frontend要跑浏览器自动化
• backend要curl/fetch实测响应
• CLI要看stdout/stderr/exit code
• 必须做adversarial probes
• 每个check必须带command和output observed
• 最后必须输出VERDICT: PASS / FAIL / PARTIAL

这说明VerificationAgent不是”再跑一次测试”，而是一个adversarial validator。

这非常强，因为它把很多LLM常见的”差不多就算了”直接用prompt反制掉了。

四、Fork机制：解决上下文污染问题

这是源码里最精巧的设计之一。

4.1 Fork不是”再开一个agent”

源码里的fork语义非常特殊：

omit subagent_type就是fork自己 fork继承完整conversation context 研究任务很适合fork 实现任务如果会产生大量中间输出，也适合fork fork很便宜，因为共享prompt cache 不要给fork单独设model，否则cache命中会变差

这个设计本质上是在解决一个大问题：

怎么让复杂子任务并行运行，但不污染主上下文？

这是多agent系统里非常核心、也非常难做对的一件事。

4.2 Cache-identical prefix

源码注释里明确说：

fork path会尽量继承父线程的system prompt和tool defs 以保持API request prefix byte-identical 从而提高prompt cache命中

这是非常高级的设计：

普通人只想”子任务能跑”，Claude Code想的是”子任务能跑，而且尽量复用主线程cache，不白烧token”。

五、Tool不是直接裸调，是治理pipeline

这是源码里暴露出的另一个范式转移。

5.1 工具执行链

Claude Code的工具执行不是”模型决定→直接跑函数”。实际链路：

1. 找tool
2. 解析MCP metadata
3. 做input schema校验
4. 做validateInput
5. 为Bash启动speculative classifier check
6. 运行PreToolUse hooks
7. 解析hook permission result
8. 走permission决策
9. 再次根据permission updatedInput修正输入
10. 真正执行tool.call()
11. 记录analytics/tracing/OTel
12. 运行PostToolUse hooks
13. 处理structured output/tool_result block
14. 失败则走PostToolUseFailure hooks

这是一条标准的runtime pipeline，而不是直连函数调用。

5.2 Hook是runtime policy layer

源码里Hook支持：

• PreToolUse
• PostToolUse
• PostToolUseFailure

而且hook结果不仅仅能”记日志”，还能：

• 返回message
• blockingError
• updatedInput
• permissionBehavior
• preventContinuation
• stopReason
• additionalContexts

这说明Hook是runtime治理层，不是旁路日志。

六、上下文是稀缺资源

这是源码里贯穿始终的设计哲学。

Claude Code大量设计都在围绕上下文做优化：

• system prompt动静边界
• prompt cache boundary
• fork path共享cache
• skill按需注入
• MCP instructions按连接状态注入
• function result clearing
• summarize tool results
• compact/transcript/resume

这说明他们不是把token当免费空气，而是当runtime预算来管理。

七、这件事为什么会改变研发逻辑？

回到核心问题。

Claude Code源码泄露的价值，不是让你抄一段prompt，而是告诉你：

coding agent的护城河，不是模型更聪明，而是系统更制度化。

7.1 它把”好行为”制度化

Claude Code最大的优势之一，不是模型更聪明，而是：

它不把”好习惯”交给模型即兴发挥，而是写进prompt和runtime规则里。

例如：

• 不要乱加功能
• 不要过度抽象
• 不要瞎重试被拒绝的工具
• 不要未验证就说成功
• 不要随便做风险操作
• 不要让fork输出污染主上下文
• 匹配skill时必须执行skill
• verification不能只看代码，必须跑命令

这种制度化，会极大提高系统一致性。

7.2 它的生态是”模型可感知”

这是Claude Code另一个很强的点。

很多系统也有插件，也有工具，也有外部协议，但模型本身不知道：

• 有哪些扩展
• 什么时候该用
• 怎么用

Claude Code不一样。它通过：

• skills列表
• agent列表
• MCP instructions
• session-specific guidance
• command integration

让模型”知道自己的扩展能力是什么”。

这才是生态真正能发挥作用的关键。

八、最后的问题

源码泄露后，很多人在问：

能不能复刻Claude Code？

答案是：能，但很难。

因为它的护城河不是一段prompt，而是：

• Prompt architecture
• Tool runtime governance
• Permission model
• Hook policy layer
• Agent specialization
• Skill workflow packaging
• Plugin integration
• MCP instruction injection
• Prompt cache optimization
• Async/background/remote lifecycle
• Transcript/telemetry/cleanup/task system

少一个都行，但会显著掉”手感”。

更深的问题是：

如果Claude Code的真正秘密是”制度化好行为”，那我们是不是应该重新思考coding agent的研发范式？

过去两年，所有人都在追求”更强的模型”、”更聪明的prompt”。

但Claude Code的源码告诉你：

真正决定产品手感的，不是模型有多聪明，而是系统有多制度化。

这会不会是coding agent范式转移的开始？

zelle

参考来源：

• Claude Code 源码深度研究报告^[1] – Xiao Tan, 2026-03-31
• Layer5 Blog – Claude Code Source Leak^[2] – 技术分析
• dev.to – The Great Claude Code Leak^[3] – 深度解读
• Alex Kim Blog – Claude Code Source Leak^[4] – 代码分析

引用链接