Claude Code源码泄漏一鲸落万物生

首页

AI教程

热心网友

转载

2026-05-28

问题出在 source map 文件（.map）上。当你发布一个 TypeScript 包到 npm 时，构建工具链会生成这些文件，它们的作用是在程序崩溃时，让堆栈追踪能指向实际的源代码行，而不是指向某个被压缩成一团的代码块的第 1 行第 48293 列。

但关键在于，source map 包含了原始源代码。是完整的、一字不差的源代码，以字符串形式直接嵌在 JSON 文件里。那个叫 sourcesContent 的数组，装的就是每个文件的全部内容，包括所有注释、内部常量，甚至系统提示词。

{
  "version": 3,
  "sources": ["../src/main.tsx", "../src/tools/BashTool.ts", "..."],
  "sourcesContent": ["// 完整的原始源代码", "..."],
  "mappings": "AAAA,SAAS,OAAO..."
}

最讽刺的地方在于，Anthropic 为了防止内部信息泄露，甚至还专门设计了一个名为 “Undercover Mode” 的完整子系统。结果呢？代码还是通过最常规的渠道泄露出去了。这再次印证了一个朴素的道理：再精妙的智能设计，有时候也抵不过一个配置正确的 .npmignore 文件来得实在。

既然源码已经摆在面前，这无疑是一个绝佳的学习机会。下面，我们就来深入拆解一下 Claude Code 这套系统的核心设计，看看顶尖团队是如何构建一个可靠 AI 编程助手的。

系统架构以及核心模块

从泄露的源码来看，Claude Code 的架构清晰地体现了现代 AI 工程化的核心思想。

设计特点

1. Harness Engineering：60% 模型 + 40% 工程

Anthropic 在自家的提示词里就明确写道：

模型能力（60%）：理解用户意图、生成代码和操作、进行推理和规划。
工程管理（40%）：系统提示词架构、工具权限系统、记忆管理、安全审查、上下文优化、错误恢复。

这个比例分配揭示了一个重要事实：再强大的模型，也需要一套精心设计的工程系统来“驾驭”，才能稳定、可控地发挥其能力，实现所谓的“智能涌现”。

实现模型本身的领先需要巨大的投入，且结果往往像“炼丹”一样充满不确定性。因此，“驾驭工程”（Harness Engineering）在今年大行其道，而 Claude Code 的源码正是其价值的最佳验证。AI 模型天生就像一匹野马，能力强悍，但其“幻觉”和发散性也带来了强烈的不可控与不可预测性，你很难确切知道它下一步会做什么。而 “Harness” 就是套在它身上的那套缰绳和马鞍。

具体到工程管理，它包括：

模型可用工具的管理与调用
多层安全机制
长期记忆系统
上下文窗口管理

所有这些组件，共同将 AI 从一种“不可控”的能力，转变为一个稳定、可交付的工程系统。目前 OpenAI 和 Anthropic 都非常推崇这种工程范式，而 Claude Code 的源码，可以说是 Harness Engineering 的一本活体教程。

2. 系统提示词动态拼接

Claude Code 的提示词系统设计得相当巧妙。系统提示词并非一个庞大的、固定的字符串，而是在运行时由模块化、可缓存的章节动态组合而成的 string[] 数组。

这套设计分为静态和动态两部分：

静态部分是全球数百万用户共享的同一份缓存，做到了省时省力。内容包括：你是 Claude Code、不要编造数据、不要随意删除文件、优先使用专用工具而非总是调用 Bash、不要过度工程化、不要添加用户未要求的功能等等。这些规则写得非常具体，每一条都像是踩过坑之后总结出的血泪教训。

动态部分则根据具体项目情况加载。比如用户在 .claude.md 中的自定义配置、个人偏好、接入的 MCP 工具，或者当前 Git 仓库的状态等。这部分每个用户甚至每个项目都可能不同，使得大模型的回答能更贴合具体场景。

缓存机制在两个层面运作：

API 层面：静态章节使用 cacheScope: 'global' 进行跨组织缓存。
应用层面：章节的计算结果会缓存起来，直到执行 /clear 或 /compact 命令才被清除。

这种“动态边界”（Dynamic Boundary）的设计，同时解决了成本问题和定制化问题。上层的静态部分全球共享缓存，下层的动态部分则按需独立加载。

3. Auto 模式背后的四层安全审查

Claude Code 有 7 种权限模式，其核心是 auto 模式，即由 ML 分类器自动审批操作。

权限模式的切换顺序（通过 Shift+Tab 循环）是：default → plan → acceptEdits → auto* → default。需要注意的是，auto 模式需要特性开关 TRANSCRIPT_CLASSIFIER 开启才会出现在循环中。而 bypassPermissions 模式不在这个循环里——它只能通过 --dangerously-skip-permissions 参数或 CLAUDE_CODE_REMOTE 环境变量显式激活，属于正常的“危险模式”。

图中左侧展示的四层安全审查是 permissions.ts

第一层：规则强制拒绝（alwaysDenyRules）
最先执行。检查用户或组织配置的黑名单规则，例如 Bash(*) 或 Agent(*)。一旦命中，操作立即被拒绝，流程直接终止，不会进入后续任何层。这是优先级最高的最强拦截。

第二层：规则强制询问（alwaysAskRules）
无论当前处于何种模式，命中此规则都会强制弹出用户确认弹窗。这里有一个关键的设计：当工具的 checkPermissions() 方法返回 decisionReason.type === 'safetyCheck' 时（对应 .gitconfig、.bashrc、.mcp.json、.claude.json、ssh/id_* 等敏感文件路径），即使在 bypassPermissions 模式下也无法跳过，必须询问用户。这些文件一旦被篡改，后果往往是灾难性的。

第三层：工具自检权限（checkPermissions()）
每个工具都有自己独立的权限自检逻辑，根据目标路径、命令内容、风险等级等因素进行判断，返回 allow、ask 或 deny。例如，FileEditTool 会检查目标路径是否在工作目录内，BashTool 会分析命令的危险等级。

第四层：模式路由决策（PermissionMode）
只有当前三层全部通过后，才由当前的权限模式来决定最终行为：

dontAsk：全部拒绝执行（即外部文档中提到的“yolo”模式，语义是“不要问，直接拒”）
auto：交给 ML 分类器（YOLO Classifier）自动裁决
bypass：跳过所有剩余的检查，直接允许（但请注意，真正危险的操作早已在前两层被拦截）
default：弹出用户确认弹窗

这个四层设计的精妙之处在于：bypassPermissions 模式看似能绕过所有限制，但实际上它只能跳过第四层的“询问”动作。前三层的规则拦截、强制询问规则以及对敏感文件的保护，早已在流程更早的阶段执行完毕，真正危险的操作根本走不到第四层。

YOLO 分类器（第四层 auto 模式的核心）在性能上做了“成本递增”的快速路径优化：先判断是否符合 acceptEdits 条件（工作目录内的安全编辑，无需调用 AI）→ 再看是否在安全工具白名单内（只读工具，跳过分类器）→ 最后才触发真正的 ML 分类器 API 调用。这样，大多数日常操作都不会引发额外的 AI 查询开销。

拒绝追踪（Denial Tracking）是一个防止死循环的工程细节：当分类器连续拒绝 3 次或累计拒绝 20 次后，系统会自动从“自动拒绝”降级为“弹出用户确认”，避免 Agent 陷入无限被拒的循环。在无头模式（如 CI/CD）下，达到上限则会直接抛出 AbortError 终止任务，防止无效的 token 消耗。

第四层中的 YOLO 分类器是整个管线里最有趣的部分。YOLO 意为“你只活一次”，但它实际做的事情却一点也不“莽撞”——每次主 AI 想要执行一个操作（比如运行一条命令、写入一个文件）时，都会有一个独立的 AI 分类器来判断这个操作是否安全。这个分类器拥有自己独立的系统提示词，与主 AI 完全不同，是专门为安全审查而训练的。

它的判断主要分为三种：

Allow：安全，直接放行。
Soft Deny：需要谨慎，会降级为需要用户确认。
Hard Deny：直接拦截，用户无法覆盖此规则。

这恰恰解决了早期 AI 编程工具中常见的问题：一旦主 AI 的上下文被污染或产生幻觉，就可能做出危险的误操作。用一个独立的、专用于安全检查的 sub-agent 来做最终裁决，是 Claude Code 在工程化上做得比较好的一个方面。

4. IDE 桥接

Claude Code 支持通过 MCP（Model Context Protocol）与外部工具和服务桥接。但 MCP 是一个比较消耗 token 的服务，几乎每个 MCP 工具的定义都会消耗几千个 tokens，带来实实在在的成本。这也是为什么很多人更倾向于使用 skill 而不是 MCP 的原因之一。

针对这个问题，Claude Code 在源码层面做了四层 token 优化：

① 懒加载 + ToolSearchTool（核心）
默认情况下，所有 MCP 工具都被标记为 defer_loading: true，从初始的 API 请求中移除，不进行预加载。只有当 AI 真正需要某个工具时，才通过专门的 ToolSearchTool 按需发现并加载。这套机制由 ENABLE_TOOL_SEARCH 环境变量控制，分为三档：

模式	触发条件
`tst`（默认）	始终懒加载，MCP 工具永不预加载
`tst-auto`	超过 context window 的 N%（默认 10%）才懒加载
`standard`	禁用，所有工具全部预加载（旧行为）

② Tool Schema 缓存（防缓存抖动）
工具 schema 在 API 请求中处于第二个位置（系统提示词之前），任何字节变化都会导致整个约 11K token 的工具块及其下游缓存全部失效。源码注释揭示了三个导致字节抖动的根本原因：GrowthBook 特性开关翻转、MCP 服务器重连、tool.prompt() 里的动态内容。toolSchemaCache.ts 模块的作用就是在会话第一次渲染时锁定 schema 的字节，此后任何“重渲染”事件都不会改变实际发送出去的内容。

③ MCP 指令 Delta 系统（防 system prompt 缓存失效）
原本，MCP 服务器连接时的 instructions 会通过 DANGEROUS_uncachedSystemPromptSection() 方法在每一轮对话中重建并注入系统提示词，每次晚连接都会打断 prompt 缓存。新的 Delta 系统（mcpInstructionsDelta.ts）改为使用持久化的 attachment 来宣告变更——只记录 addedNames / removedNames，每轮扫描历史 attachment 来重建当前指令集，系统提示词本身保持静态，从而不再打断 prompt cache。

④ Deferred Token 分类追踪
在上下文分析时，区分 isLoaded（已加载，计入实际 context 占用）和 isDeferred（懒加载未触发，不计入）两类 MCP token。自动压缩（auto-compact）的触发阈值也只看 loaded 部分，避免那些尚未被使用的工具的“幽灵成本”影响压缩决策。

5. 记忆与上下文管理

5.1 设计理念：只记偏好，不记代码

Claude Code 的记忆系统遵循一个非常巧妙的设计理念：只记录偏好，不记录代码。

原因很直接：代码是动态变化的，今天写的函数明天可能就重构了。如果记忆里存了“函数 X 在第 30 行”，一旦代码重构，这条记忆就变成了误导信息。所以 Claude Code 的做法是：记忆只存储人的判断与偏好（比如代码风格、项目结构说明），而代码内容永远去源文件里实时读取。

~/.claude/projects//memory/
├── MEMORY.md          # 索引文件（<200 行，~25KB，每条目 <150 字符）
├── preferences.md     # 用户偏好（TS 风格、书写习惯等）
├── project-structure.md # 项目结构说明
├── testing.md        # 测试规范
└── debugging.md      # 调试技巧

MEMORY.md 是一个纯索引文件，不存储具体内容。其格式固定为 - [Title](file.md) — 一行摘要，超过限制的条目会被 autoDream 进程自动剪枝。

5.2 双引擎记忆提取机制

记忆系统由两个独立的引擎驱动，分工明确：

引擎一：实时提取（extractMemories）
在每轮对话结束时运行。
触发条件（需同时满足三者）：

AI 完成了一个完整的回答（没有后续的 tool calls）。
满足 N 轮阈值（由 GrowthBook 的 tengu_bramble_lintel 开关控制，默认每轮都触发）。
主 agent 在本轮对话中没有直接写入记忆文件（互斥保护）。

触发后，会启动一个 forked agent，完整继承父对话的 prompt cache，最多执行 5 轮（read → write）。运行时，会预先扫描记忆目录生成清单（manifest）并注入 prompt，避免浪费一轮对话去做 ls 操作。提取出的记忆分为四类：用户偏好、行为反馈、项目信息、外部资源引用。

引擎二：autoDream 梦境整合
在后台周期性运行，用于整合历史记忆。
采用“三门”触发机制，按成本从低到高依次检查：

时间门：距离上次整合 ≥ 24 小时。
会话门：上次整合后产生了 ≥ 5 个新的会话（不含当前会话）。
锁门：成功获取排他锁，防止并发整合。

三门全部通过后，启动 forked subagent 执行四阶段整合：

阶段	工作内容
Phase 1 — Orient	`ls` 记忆目录，读取 MEMORY.md，浏览主题文件防止重复。
Phase 2 — Gather	优先读取日志 → 漂移记忆 → 窄范围搜索 transcript JSONL 文件。
Phase 3 — Consolidate	将新记忆合并入已有文件，将相对日期转换为绝对日期，删除已被推翻的旧事实。
Phase 4 — Prune	更新 MEMORY.md 索引，维持 <200 行 + ~25KB 的限制，解决文件间的矛盾。

两个引擎共用同一套权限沙箱：FileRead/Grep/Glob 无限制；Bash 仅允许只读命令（如 ls、cat、grep）；FileEdit/FileWrite 仅限在 memoryDir 目录内操作；其余写操作一律拒绝。

5.3 上下文压缩

当对话上下文过长时，Claude Code 会自动触发压缩。压缩并非简单的截断，而是使用一套结构化的九段式模板来提取关键信息：

核心请求 → 2. 关键概念 → 3. 文件与代码 → 4. 错误与恢复 → 5. 解决过程 → 6. 所有用户消息 → 7. 待办任务 → 8. 当前工作 → 9. 下一步指南

这套模板确保了压缩后的上下文仍然能让 AI 快速恢复工作状态，最核心的内容基本能得到完整保留。

5.4 搜索策略：不用 RAG，只用 Grep

很多人谈到 AI 编程工具的代码搜索时，第一反应是向量数据库、embedding 索引、RAG 检索。但 Claude Code 的选择完全相反——它根本不用 RAG，而是直接搜索代码本身。

搜索的主力是 Grep：没有 embedding，没有语义匹配，没有向量数据库。

这个逻辑很清晰：上下文窗口已经足够大（1M token 可以装下整个代码库），grep 正则表达式精确且不会误匹配，本地搜索是毫秒级响应。更关键的是——与其把检索逻辑做得无比复杂，不如让 AI 利用其自主能力来决定怎么搜索。随着模型能力越来越强，这个选择也显得越来越合理。

6. BUDDY - 终端宠物系统

Claude Code 还引入了一个完整的、类似拓麻歌子（Tamagotchi）风格的伴侣宠物系统，名为 “Buddy”。这是一个确定性的扭蛋系统，具有物种稀有度、闪光变体和程序化生成的属性。

稀有度权重表如下：

稀有度	权重	概率	星级
Common	60	60%	★
Uncommon	25	25%	★★
Rare	10	10%	★★★
Epic	4	4%	★★★★
Legendary	1	1%	★★★★★

还有一个闪光概率彩蛋：闪光传说级（Shiny Legendary）的概率是 1% × 1% = 0.01%（万分之一）。

彩蛋 - 未发布的隐藏功能

除了上面这些已公开的设计，源码里还有很多在生产环境（prod）中被关闭的特性开关（Feature Flags），它们暴露了 Claude Code 未来可能的发展方向。

KAIROS - 永远在线的 Claude

一个持久运行的 Claude 助手，不需要等待用户输入，可以主动观察和采取行动。

日志系统：维护追加式日志文件，记录观察、决策和行动。
Tick 提示：定期接收提示，决定是否主动行动。
15 秒预算：超过 15 秒的阻塞操作会被延迟执行。
Brief 模式：极简输出模式，避免信息淹没终端。

ULTRAPLAN - 30 分钟远程规划

将复杂的规划任务卸载到远程 CCR 会话中运行，使用 Opus 4.6 模型，最多给予 30 分钟的思考时间。

识别任务 → 启动 CCR → 轮询结果 → 浏览器审批 → Teleport 回本地

Penguin Mode - 快速模式

内部称为 “Penguin Mode” 的快速响应模式，通过 API Beta Headers 启用，相关 Header 包括：

fast-mode-2026-02-01
redact-thinking-2026-02-12
afk-mode-2026-01-31

Coordinator Mode - 多智能体编排

支持并行管理多个工作智能体，实现研究、合成、实现、验证的完整工作流程。

研究阶段 (Workers 并行) → 合成阶段 (Coordinator) → 实现阶段 → 验证阶段

其核心原则是：“并行是你的超能力。Workers 是异步的。尽可能并发地启动独立的 workers。”

尾巴：一鲸落，万物生

在各家 AI Agent 产品竞争正酣的时候，Anthropic 的这一波源码泄露让局势骤然变得有意思起来。

AI Agent 在代码能力层面的跃升，如同内燃机问世——手工逐行敲代码的时代恐怕是回不去了。但随之而来的是一个新问题：AI 写出的代码，人类已经不可能逐行审查（line by line review），这个工程量甚至比写代码本身更耗时。所以，未来真正值钱的或许不是某个特定版本的模型，而是那套踩过无数坑后沉淀下来的“驾驭”系统（harness prompts）、安全规则和工程化共识——那才是业界真正的 know-how 财富。谁能把这套 Harness 搭得更好、更稳，谁就更有机会脱颖而出。

Claude Code 确实拥有强大的飞轮效应：它越强大，就越能帮助 Anthropic 把自己变得更强。52 天 74 次发布，Claude Code Work、手机远程控制、企业应用市场……这个迭代速度，其他产品很难正面追赶。

但这次泄漏，相当于把 v2.1.88 版本的整套设计图纸公开了。行业的起跑线，在某种意义上被重置了一次。

更有意思的是：借助 AI Agent 工具本身，任何团队都可以“左脚踩右脚”——用现有的 AI Agent 来快速理解、复制、迭代，甚至超越这套 Agent 架构。站在巨人的肩膀上，肩上的人也能成为新的巨人。可以预见，后续各个 AI Agent 产品的质量，肯定会比 v2.1.88 版本好上不少。如果照着现成的蓝图都做不好，那恐怕也没有发布的必要了。

来源:https://juejin.cn/post/7625484869305040939

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：Pacely：高效时间管理工具助你掌控工作与生活节奏下一篇：AI PDFGPT.IO：智能化PDF摘要与互动问答工具高效处理文档信息