JeecgBoot AI专题研究 | Claude Code 源码泄露事件深度解析与 Harness Engineering 实践启示
源码仓库（Gitee 镜像）：gitee.com/jeecg/claud…
引言：一个打包配置的疏忽，掀开了 AI 编程工具的底牌
2026年3月底，AI 编程圈发生了一件足以载入史册的"乌龙事件"——Anthropic 旗下的明星产品 Claude Code，其完整 TypeScript 源码因一个调试文件的误发布而全面曝光。没有发布会，没有官方声明，1902 个源码文件、超过 51 万行代码，就这样"裸奔"在了全球开发者面前。
这不是一次精心策划的开源行动，而是一次令人啼笑皆非的工程事故。但对于每一个使用 AI 工具的开发者来说，这次泄露反而提供了一个前所未有的学习窗口——我们终于能看清，一个顶级 AI 编程助手到底是怎么"组装"出来的。
事故还原：Source Map 文件为何不该出现在生产包中
整个事件的导火索，是 Anthropic 在更新 @anthropic-ai/claude-code npm 包时，将一个体积高达 59.8 MB 的 cli.js.map 文件遗留在了生产发布包中。
Source Map 是前端开发中再常见不过的辅助工具，它记录着压缩后代码与原始源码之间的逐行映射关系，本应仅存在于开发环境。然而这一次，任何人只需下载这个公开的 npm 包，就能从这份 .map 文件中完整还原出 Claude Code 的全部 TypeScript 源代码。
更耐人寻味的是，这并非 Anthropic 第一次犯这个错误。早在 2025 年 2 月 Claude Code 刚发布时，就出现过一模一样的泄露，当时 Anthropic 紧急删除了旧版 npm 包。时隔一年多，同样的失误再度上演——这不禁让人感叹，或许 Anthropic 的 CI/CD 流水线本身也需要一个 Claude Code 来帮忙做代码审查。
消息传开后，开发者社区迅速响应。有人将提取出的源码上传到 GitHub，README 标注"仅用于安全研究与供应链分析"。短短半小时内 star 数突破 5000，一小时后破万，且 fork 数比 star 还多——显然，大家都在抢时间备份，担心随时被下架。
技术全景：51 万行代码背后的架构蓝图
泄露的规模远超预期。1900 余个源文件完整暴露了 Claude Code 的技术选型：React + Ink 构建终端 UI，Bun 作为运行时，Commander.js 处理 CLI 解析，Zod v4 负责 Schema 校验，再加上 ripgrep、MCP SDK、LSP 协议集成、OpenTelemetry + gRPC 链路追踪——几乎囊括了现代前端工程体系的半壁江山。
但真正有价值的，不是技术栈清单本身，而是它揭示了 Anthropic 对"AI 编程助手"这一产品形态的完整设计哲学。
核心三板斧
万能工具箱（Tools）：40 多个独立模块覆盖文件读写、Bash 执行、MCP 调用、子代理生成等能力。内置 LSP 协议集成，直接对标专业 IDE 的功能边界——这意味着 Claude Code 的目标不只是"聊天式编程"，而是要成为一个可以替代部分 IDE 功能的全能工作台。
超级大脑（QueryEngine.ts）：单文件 4.6 万行代码，承载了所有推理逻辑、Token 计数和复杂的"思维链"循环。仅这一个文件的代码量，就已经超过了许多完整项目的规模。
协同系统：源码中出现了 coordinator（多智能体协调器）和 bridge（连接 VS Code / JetBrains 的桥梁），表明 Claude Code 早已具备多机协同和深度嵌入主流 IDE 的实战能力。
Harness Engineering：为什么同一个模型，不同产品体验天差地别
2026 年有一个越来越热的概念叫 Harness Engineering（笼具工程）。核心观点是：AI Agent 好不好用，不仅取决于底层模型多强，更取决于围绕模型搭建的工程系统有多精良。这套系统包括工具集成、约束规则、反馈循环、安全机制、记忆管理……所有把 AI 从"能力强但不可预测"变成"稳定可靠能交付"的基础设施。
Claude Code 的源码，堪称一本 Harness Engineering 的活教材。
System Prompt 的精密拼装
当你在 Claude Code 中输入一条指令时，AI 实际接收到的信息量远超你的想象。源码中的 prompts.ts 文件揭示了完整的系统提示词构建过程——你的指令只是冰山水面上的那一角。
静态部分（所有用户共享，可缓存优化）：
- 身份定义："你是 Claude Code，Anthropic 的官方 CLI 工具"
- 安全准则：由专门的安全团队编写的行为边界
- 做事原则：不过度工程、不编造数据、不随意删文件
- 工具使用规则：优先使用专用工具而非 Bash 命令
- 风格要求：简洁直接，不使用 emoji
动态部分（每个用户独立加载）：
- CLAUDE.md 配置文件
- 当前工作目录和操作系统信息
- 已连接的 MCP 服务器描述
- 自动记忆文件
- Git 仓库状态
源码中有一个名为 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 的常量，将整个 system prompt 一刀切为两段——分界线以上所有用户共享缓存，节省 Token 消耗和响应时间；分界线以下每用户独立加载，确保个性化体验。这个设计既简单又高效。
另外一个容易被忽视的成本：据分析，每接入一个 MCP 服务器，光工具定义就会固定消耗 4000-6000 个 Token。接入 5 个 MCP Server，工具描述就占满了上下文的 12% 左右。工具不是越多越好，每一个都有认知成本。
四层安全流水线：Auto 模式背后的隐形守护
很多人以为 Auto 模式就是"所有操作直接放行"，但事实远非如此。源码中存在一个完整的权限分类器系统，每当主 AI 想执行一个操作，都会有一个独立的 AI 分类器在后台评估安全性。
这套安全机制是一个四层流水线：
- 规则匹配层：查已有规则，命中直接放行
- 低风险过滤层：识别低风险操作，跳过后续检查
- 白名单层：只读工具自动放行
- AI 审查层：调用独立的 Claude Sonnet 做安全分类（温度设为 0，保证输出确定性）
还有一个熔断机制：连续 3 次被拒或累计 20 次被拒后，系统自动降级为手动确认模式。打个比方，就像大楼的门禁系统——第一道刷工卡自动过，第二道看身份，第三道查楼层权限，第四道才是人工安保审查。连续被拦三次？保安直接把你请到大厅等人来领。
这就是 Harness Engineering 的精髓：你不只要告诉 AI 能做什么，更要设计它在什么条件下不能做什么。
记忆系统：只记偏好，不记代码
Claude Code 的 auto memory 功能是用户体验中最令人印象深刻的设计之一。它能自动记住你的编码偏好——比如你喜欢 TypeScript、习惯用中文引号、不喜欢 AI 味太重的输出风格。
但源码揭示了这套系统远比表面精巧：
- 触发时机：记忆提取不是每条消息都启动，只有 AI 完成一轮回答时才触发，且有限流机制，每 N 轮才检查一次
- 隔离执行：提取工作由独立的 fork agent 完成，这个子 AI 继承主对话上下文，但只能读文件和写入记忆目录，连 Bash 命令都无权执行
- 严格分类：记忆被分为四类——
user（用户偏好）、feedback（行为反馈）、project（项目信息）、reference（外部资源）
最精妙的设计决策是**"不记代码"**。代码在持续演进，但记忆不会自动同步更新。如果记忆中存储了"函数 X 在文件 Y 的第 30 行"，下次对话时代码已经重构，这条记忆就变成了误导信息。因此 Claude Code 的策略是：记忆只存储人的偏好和判断，代码事实永远从源码中实时读取。
源码中还有一个名为 autoDream 的功能——当满足特定条件（距上次整理超过 24 小时、积累超过 5 个新会话）时，系统会自动启动后台 Agent 整理记忆文件。名字取得很有意味：像人在睡眠时整理白天记忆一样。
上下文压缩：9 段式结构化提取
对话变长时，Claude Code 会自动压缩历史内容。但这不是简单的"帮我总结一下"，而是一套结构化的9 段式提取方案：
- 核心请求
- 关键概念
- 文件和代码
- 错误和修复
- 解决过程
- 所有用户消息
- 待办任务
- 当前工作
- 下一步行动
其中最关键的规则是：所有用户消息必须完整保留。用户的每一句话都可能包含隐性偏好——AI 可能在第 3 轮对话中被纠正了某个做法，压缩时若丢弃这条纠正，后续就会重蹈覆辙。
这个设计给我们的启示是：如果你在多轮对话中需要保持 AI 的记忆连贯性，别只说"总结一下之前聊了什么"，而应当给出明确的结构——哪些信息必须保留、哪些可以丢弃、按什么格式组织。结构化压缩比自由总结可靠太多。
隐藏功能大揭秘：守护进程、电子宠物与卧底模式
比架构设计更让人兴奋的，是那些从未被官方提及的隐藏功能。
Kairos 模式：一个尚未发布的守护进程系统。它不是普通的功能插件，而是具备"持久生命"的自主后台进程，支持后台会话和记忆整合。换句话说，Claude 未来可以化身"永不离线"的 AI 智能体，在后台持续处理任务，并不断加深对你项目的理解。在源码的 feature flags 中，KAIROS 出现了 154 次，是出现频率最高的标记。
Buddy System（电子宠物系统）：这大概是整次泄露中最出人意料的发现。src/buddy/ 目录下藏着一套完整的虚拟宠物系统——18 种物种（鸭子、猫、龙、水豚、仙人掌……）、6 种眼睛样式、完整的稀有度体系（从普通到传说）。代码注释中还写了一句："Mulberry32, good enough for picking ducks"（用来挑鸭子够用了）。严肃的工程项目里藏着这样的彩蛋，让人会心一笑。
Undercover Mode（卧底模式）：当 Anthropic 员工在公共仓库操作时自动激活，强制抹除提交记录中的所有 AI 痕迹，且无法手动关闭。
Coordinator Mode 和 Auto Mode：前者让 Claude 调度并行从属智能体协同工作；后者是自动审批工具权限的 AI 分类器，目标是消除繁琐的手动确认流程。
此外，源码中还出现了下一代模型 Claude Mythos 5.0 的内部代号——「卡皮巴拉」。
多 Agent 协作：像真实公司一样运转的组织架构
Claude Code 的 Agent 系统可能是整份源码中最复杂的模块。utils/swarm/ 目录下实现了一套企业级的多 Agent 协作框架：
- 每个 Team 由 Leader 和多个 Teammate 组成
- 支持三种执行方式：同进程隔离、tmux 窗口、iTerm2 分割窗格
- 每个 Agent 拥有独立的邮箱文件进行异步通信
- 每个 Agent 可以在独立的 Git Worktree 中工作，互不干扰
还有一个精妙的权限冒泡机制：Teammate 遇到需要确认的操作时，权限请求会向上冒泡给 Leader，而不是直接打断用户。Leader 来决定是否批准。这与管理真人团队的逻辑如出一辙——任务如何拆分、信息如何流转、冲突如何解决、结果如何合并。
内部版 vs 外部版：Anthropic 的"双标"透露了什么
源码中大量的 USER_TYPE === 'ant' 判断揭示了内外部版本的显著差异：
| 维度 | 内部版 | 外部版 |
|---|---|---|
| 代码注释 | 默认不写注释，只在 WHY 不明显时才加 | 无此限制 |
| 诚实性 | 明确要求"测试失败就说失败，没验证就说没验证" | 无此约束 |
| 输出风格 | "像写给人看的文字，假设用户已离开丢失上下文" | "简洁直接" |
| 卧底模式 | 抹除 system prompt 中所有模型名称 | 不适用 |
| 验证机制 | 完成实现后自动启动独立 Agent 做对抗性验证 | 无 |
这些差异说明，Anthropic 把 Claude Code 当成了内部效率的核心工具，内部版本的严格要求，就是他们认为 AI 应该如何工作的理想状态。
一个反直觉的发现：最先进的 AI 工具，用的是最朴素的搜索
你可能以为 Claude Code 搜索代码用了向量数据库、Embedding 索引——毕竟整个 RAG 行业都在推这套方案。
实际上用的是 grep 和 ripgrep。最朴素的文本搜索，没有 Embedding，没有向量数据库。
为什么有效？因为当你有一个足够聪明的大脑（LLM）来理解搜索结果时，就不需要一个同样复杂的搜索引擎。grep 提供精确匹配，LLM 负责理解结果之间的语义关系。
与其让每个环节都变复杂，不如让一个环节足够强，其他环节保持简单。 这可能是 Harness Engineering 中最值得铭记的设计原则。
写在最后：60% 靠模型，40% 靠工程
翻完这 1900 多个文件，最大的收获可以浓缩为一个判断：Claude Code 好用，60% 靠模型能力，40% 靠 Harness 工程。
模型能力决定了它能不能做，Harness 决定了它做得好不好、稳不稳、安不安全。你觉得"这 AI 好靠谱不会乱来"，背后是四层安全流水线。你觉得"这 AI 居然记得我的偏好"，背后是一个限制严格的记忆提取管线。你觉得它搜代码搜得准，背后其实就是 grep 加一个足够聪明的大脑。
同样的底层模型，套上不同的 Harness，就是完全不同的产品体验。市面上那么多 AI 编程工具，底层都在调 Claude 或 GPT 的 API，使用体验却天差地别。差异不在模型，在工程。
而这次事故本身也是一个绝佳的提醒：AI 时代，最大的风险往往不是 AI 太强，而是人在基础操作上的疏忽。 一个忘记剔除的 .map 文件，比任何开源声明都更有力量。
总结
Claude Code 源码泄露事件，意外地为整个行业提供了一份关于 AI 工程化的教科书级参考。从精密的 System Prompt 拼装、四层安全流水线、到"只记偏好不记代码"的记忆哲学、9 段式上下文压缩，再到多 Agent 协作的组织架构——每一个设计决策都在回答同一个问题：如何让一个强大但不可控的 AI，变成一个可靠且值得信赖的工程伙伴。
对于每一个正在构建 AI 应用的开发者来说，这些设计思路都值得认真研究和借鉴。
本文为 JeecgBoot AI 专题研究系列文章。
