Claude Code 源码泄露事件深度解析：AI 行业从"模型竞赛"转向"Harness 工程"的标志性事件

Claude Code 源码泄露不只是一次安全事故，它是 AI 行业从"模型竞赛"转向"harness 工程"的标志性事件——泄露的代码揭示了一个顶级团队如何围绕模型搭建工程系统，而这个工程系统的设计决策，比模型本身更值得学习。

一、引言：一次低级失误，一个时代的缩影

2026 年 3 月 31 日，一个普通的周一深夜，开发者 Chaofan Shou 在 Anthropic 的 npm 包中发现了一个不该存在的文件。这个文件叫 cli.js.map，体积 59.8MB，包含 Claude Code 的完整源码——1906 个文件，51.2 万行代码，一字不落地摊开在全世界面前。

这个发现如同一颗炸弹投入了 AI 开发者社区。泄露仓库在一小时内突破万星，24 小时内达到 3 万星、4 万 fork，成为 GitHub 历史上增长最快的仓库之一。多个镜像仓库迅速涌现，专用网站 ccleaks.com 上线，全世界的开发者都在翻阅这份来自 AI 行业最神秘公司之一的"内部手册"。

讽刺的是，这已经是 Anthropic 第二次犯同样的错误。2025 年 2 月，Claude Code 的早期版本也因 npm source map 泄露过源码。一年后，同一个漏洞，同一个渠道，甚至可能是同一个疏忽——构建流水线中忘记排除 source map 文件。

表面上看，这是一起令人啼笑皆非的安全事故：一家估值数百亿美元、号称"安全优先"的 AI 公司，连续两次因为打包配置错误把核心产品源码贴在了公网上。但如果你深入阅读泄露的代码，你会发现一个更深层的真相：这些代码揭示的设计哲学，比任何事故报告都更有价值。

它告诉了我们一个顶级 AI 团队如何围绕一个语言模型搭建工程系统——如何管理上下文、如何设计权限、如何实现多智能体协作、如何构建记忆系统。这些工程决策，才是真正的"护城河"。

这就是本文要讨论的核心问题：当模型能力趋于同质化，harness engineering——即围绕模型搭建的工程系统——正在成为 AI 产品竞争的新主战场。

二、事件始末：五天，两起事故

2.1 第一次事故：CMS 配置错误（3 月 26 日）

在 source map 泄露之前五天，另一场泄露已经悄然发生。

Fortune 杂志率先报道：Anthropic 的内容管理系统（CMS）出现了配置错误，导致约 3000 个未发布资产被公开访问。这些资产中最引人注目的是一份代号 Capybara（水豚） 的模型草稿——后来被证实为 Claude Mythos 的内部名称。

Anthropic 在一份声明中确认了泄露的存在，并罕见地评价了模型本身："我们在能力上看到了阶跃变化（step-change）。"这句话本身就是一个信号：泄露的不只是文档，而是 Anthropic 下一步战略的核心内容。

对于第一次事故，Anthropic 的归因简洁而具体："外部 CMS 工具的人为操作失误"。这是一个可以理解但不应发生的错误——CMS 配置错误是 Web 开发中最基础的安全问题之一，但对于一家将"安全"作为品牌核心的公司来说，这个解释的讽刺程度不亚于一家银行把金库密码贴在了门上。

第一次事故就像一声警钟，但显然，没有人听见了。

2.2 第二次事故：npm source map 泄露（3 月 31 日）

五天后，更大的事故来了。

泄露发生在 @anthropic-ai/claude-code 包的 v2.1.88 版本中。当开发者执行 npm install 后，会在 node_modules/@anthropic-ai/claude-code/dist/ 目录下找到一个名为 cli.js.map 的文件。

技术背景很简单： Anthropic 使用 Bun 作为打包器，Bun 在构建时默认生成 source map 文件（用于调试时将压缩代码映射回源码）。正常的生产发布流程应该排除这个文件，但 Anthropic 的构建流水线未能做到这一点。

更关键的是，source map 泄露和普通的压缩代码泄露完全不同。压缩后的 JavaScript 代码虽然可读性差，但仍然包含完整的业务逻辑。而 source map 则是原始源码的精确映射——变量名、文件路径、注释、代码结构，一字不差。

这意味着，任何人只需要一行命令就能获得 Claude Code 的完整 TypeScript 源码：

`npm install @anthropic-ai/claude-code@2.1.88
ls node_modules/@anthropic-ai/claude-code/dist/cli.js.map

使用 source-map 工具反编译即可还原完整源码

`
这是一个低级到令人震惊的失误。在软件工程中，排除 source map 是生产部署的基本常识，类似于在发布前删除调试日志。但对于 Anthropic 来说，这已经不是第一次了。

2.3 社区反应：GitHub 的"黑洞时刻"

泄露代码在 GitHub 上传播的速度可以用"黑洞时刻"来形容——信息一旦越过事件视界，就再也无法收回。

开发者 instructkr 最先将反编译后的代码上传到 GitHub，仓库命名为 claude-code。增长曲线令人瞠目：

| 时间
| Star 数
| Fork 数

| 1 小时
| ~11,000
| ~17,000

| 24 小时
| ~30,000
| ~41,000

多个镜像仓库几乎同时涌现：leeyeel、dnakov、ghuntley 等开发者各自建立了副本。专用网站 ccleaks.com 上线，提供在线浏览和搜索泄露代码的功能。

代码一旦进入 4 万+ fork 的 GitHub 仓库，就真正"永生"了。 Anthropic 可以删除 npm 包、可以发 DMCA Takedown、可以法务追责，但无法删除已经分散在全球数万个硬盘上的副本。开源社区的复制速度远超任何法律手段的追溯速度。

2.4 Anthropic 的沉默

截至本文发稿，Anthropic 未对第二次泄露做出任何公开回应。

这种沉默本身值得分析。在第一次 CMS 泄露后，Anthropic 迅速发表了声明。但第二次泄露——严重程度远超第一次——却选择了沉默。可能的解释有几个：

第一，法务优先策略。 法律团队可能正在准备 DMCA Takedown 请求，在法律行动启动前不宜公开发言。

第二，冷处理策略。 公开回应可能反而加剧传播——"Anthropic 确认泄露"比"据说 Anthropic 泄露了"更有新闻价值。

第三，修复优先。 工程团队可能正在紧急修复 source map 泄露问题并发布新版本。

无论原因是什么，预期的应对路径很清晰：DMCA Takedown + 新版本修复。但更重要的是，Anthropic 无法阻止已经发生的事情——全世界已经看到了 Claude Code 是怎么造出来的。

三、泄露揭示了什么——技术架构全景

如果说前两节讲的是"发生了什么"，从这一节开始，我们讲的是"泄露的代码告诉了我们什么"。这不是一篇代码审计报告，而是一次设计哲学的深度解读。

3.1 技术栈：现代 AI 工程的"标准答案"

Claude Code 的技术栈选择本身就是一个值得分析的信号——它几乎用上了 2025-2026 年 JavaScript/TypeScript 生态中每一个最佳实践。

| 类别
| 技术选型
| 说明

| 运行时
| Bun
| 比 Node.js 更快的 JS 运行时，原生支持 TypeScript

| 语言
| TypeScript (strict)
| 严格模式，最大化类型安全

| 终端 UI
| React + Ink
| 用 React 组件模型渲染终端界面

| CLI 解析
| Commander.js
| 成熟的命令行参数解析库

| Schema 验证
| Zod v4
| 运行时类型验证，与 TS 类型推导联动

| 代码搜索
| ripgrep
| Rust 编写的高性能搜索工具

| 协议
| MCP SDK, LSP
| 模型上下文协议 + 语言服务协议

| API
| Anthropic SDK
| 调用 Claude API

| 状态管理
| Zustand
| 轻量级 React 状态管理

| 特性标志
| GrowthBook
| 功能开关与 A/B 测试

| 认证
| OAuth 2.0, JWT
| 标准认证协议

观点：技术栈的选择揭示了 Anthropic 的工程文化——实用主义优先，不追求"与众不同"。

解释： 对于一个需要快速迭代的产品来说，选择成熟、广泛使用的工具比选择"最优但小众"的工具更重要。团队的学习成本、社区的解决方案储备、人才的招聘池——这些"隐性成本"往往比工具本身的性能差异更大。

例子： 对比一些追求"全栈 Rust"或"全栈 Go"的 AI 创业公司，Claude Code 的技术栈看起来"普通"，但正是这种"普通"保证了 Anthropic 能以 52 天 74 个发布的速度迭代。

小结： 在 AI 工程中，技术栈的"标准答案"往往就是最好的答案。差异化不在工具，在用法。

3.2 代码规模与结构：一个"中型"产品的真实体量

泄露的源码统计如下：

| 指标
| 数值

| 文件数
| 1,871

| 代码行数
| 499,568

| 代码体积
| 27.21MB

| 最大模块
| src/utils（90,767 行，18.2%）

| 入口文件
| main.tsx（785KB）

| 工具基类
| Tool.ts（~29,000 行）

| 查询引擎
| query/（~46,000 行）

| React 组件
| ~140 个终端渲染组件

| 斜杠命令
| 50+ 个

观点：50 万行代码，对于一个 CLI 工具来说是相当庞大的，但这恰恰说明了 harness 本身就是一个复杂系统。

解释： Claude Code 不是简单的"API wrapper"。它有自己的终端 UI 渲染引擎、复杂的多智能体调度系统、四层权限管理、三层记忆系统、上下文压缩算法、错误恢复机制……这些功能加在一起，构成了一个独立的工程系统，其复杂度远超大多数人的想象。

例子： 仅仅 Tool.ts 一个文件就有约 29,000 行——这几乎是一个中型项目的体量。它定义了所有工具的基类、注册机制、权限映射、输入输出验证。query/ 目录 46,000 行代码实现了一套完整的查询引擎，负责理解用户的自然语言请求并将其转化为工具调用序列。

小结： Claude Code 的代码规模告诉我们，AI 产品的"简单体验"背后是巨大的工程复杂度。用户感觉到的"好用"，是数万行代码精心编排的结果。

3.3 System Prompt 架构：静态与动态的精确切割

System Prompt 是 Claude Code 的"大脑操作系统"——它定义了 Claude Code 的身份、行为规则、工作方式。泄露的代码揭示了 Anthropic 如何将这个关键的提示词组织成 15 个模块，并通过一条精确的分界线将它们分为"可缓存"和"不可缓存"两部分。

静态部分（可跨用户缓存，位于分界线上方）：

1. 身份定义

"You are Claude Code, Anthropic's official CLI for Claude."

一句话确立了身份边界：Claude Code 不是通用聊天机器人，不是搜索助手，而是专门为编程设计的 CLI 工具。这个定位决定了后续所有行为准则的方向。

2. 安全准则

Claude Code 的安全准则由 Anthropic 的安全团队专门编写，定义了严格的行为边界。这些准则不是泛泛的"不要做坏事"，而是针对编程场景的精确约束——比如不要在未经确认的情况下执行可能有破坏性的命令，不要访问敏感文件，不要泄露系统信息。

3. 做事原则

三条核心原则贯穿始终：

不要过度工程（Don't over-engineer）：给出最简单的解决方案
不要编造数据（Don't fabricate）：不确定就说不确定
不要随意删文件（Don't delete files carelessly）：修改前确认影响范围

4. 工具使用规则

一条关键原则：优先使用专用工具而非 Bash 命令。读文件用 ReadTool 而非 cat，编辑文件用 EditTool 而非 sed，搜索用 GrepTool 而非 grep。这不仅仅是工程偏好——专用工具能提供更精确的权限控制和审计日志。

5. 语气风格

Claude Code 的语气被明确要求：不用 emoji、简洁直接、不废话。这是一个刻意的反趋势设计——在 AI 产品普遍追求"友好亲切"的市场中，Claude Code 选择了一种"工程师对工程师"的沟通风格。

6. 输出效率

直奔主题，最简方案优先。如果用户问"怎么修这个 bug"，不要先解释为什么有 bug，直接给修复方案。

动态部分（每个用户/会话不同，位于分界线下方）：

会话特定指南（用户自定义的规则）
持久记忆（跨会话保留的用户偏好）
模型覆盖（允许切换底层模型）
环境信息（OS、Shell、工作目录、模型名称）
语言偏好（中英文等）
输出样式（详细/简洁）
MCP 服务器指令（外部工具集）
临时目录（工作目录）
结果清理指令（完成后是否清理临时文件）

关键设计：SYSTEM_PROMPT_DYNAMIC_BOUNDARY

整个提示词架构中最精妙的设计是 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 这个常量。它像一把刀，把提示词一刀两段——分界线以上是静态内容，分界线以下是动态内容。

为什么这很重要？ 因为 API 提示词缓存的工作原理是：如果两次请求的前缀完全相同，API 可以复用缓存结果，大幅降低处理时间和成本。通过精确控制分界线，Anthropic 确保了所有用户共享的静态部分都能被缓存，而只有动态部分需要每次重新处理。

对于每天处理数百万次请求的系统来说，这个设计的成本节约可能是数百万美元级别的。

小结： 提示词不是一段文本，而是一个需要精心工程的系统。静态与动态的精确切割，是大规模部署的必要条件。

3.4 工具系统：38+ 工具与一条核心原则

Claude Code 内置了 38 个以上的工具，覆盖了开发者日常工作的方方面面：

| 类别
| 工具
| 功能

| 文件操作
| ReadTool, WriteTool, EditTool
| 读取、写入、编辑文件

| 搜索
| GrepTool, GlobTool
| 正则搜索、文件名匹配

| 执行
| BashTool
| 执行 Shell 命令

| 网络
| WebFetchTool, WebSearchTool
| 网页获取、网络搜索

| 智能体
| AgentTool
| 派生子智能体

| 通信
| SendMessageTool
| 向用户发送消息

| 任务
| TaskCreateTool
| 创建和管理任务

| 语言服务
| LSPTool
| 代码补全、诊断、跳转定义

| 调度
| CronCreateTool
| 定时任务

| 协作
| TeamCreateTool
| 团队协作

| 技能
| SkillTool
| 调用技能包

| 权限
| AskUserQuestion
| 请求用户确认

观点：工具系统的核心原则不是"功能丰富"，而是"读并行，写串行"。

解释： 所有只读操作（Read、Grep、Glob、LSP 等）可以并行执行，最多 10 个并发；所有写操作（Write、Edit、Bash 中有副作用的命令）必须串行执行。并行读可以大幅提升性能，尤其在需要扫描大量文件时；串行写可以避免竞态条件，确保文件系统的一致性。

例子： 当用户让 Claude Code "分析整个项目的架构"时，它可以同时发起 10 个 GrepTool 和 ReadTool 请求，快速扫描整个代码库。但当需要修改文件时，它必须一个一个来——先改 A 文件，确认成功后再改 B 文件。

专用工具优先于 Bash 不仅是工程偏好，更是安全设计。当 Claude Code 用 ReadTool 读文件时，系统知道它只读了什么；当它用 cat 读文件时，系统只能猜测它做了什么。专用工具提供了精确的审计能力，而 Bash 命令是一块盲区。

小结： 工具系统的设计哲学是——控制力比灵活性更重要。宁可牺牲一点通用性，也要确保每一步操作都是可追踪、可审计、可回滚的。

3.5 四层错误恢复机制：当系统出问题时的"安全网"

任何与 LLM 交互的系统都会面临一个根本挑战：模型不可预测。它可能输出过长、可能超时、可能返回错误、可能拒绝回答。Claude Code 的应对方案是一个四层递进的错误恢复机制。

第 1 层：上下文过长 → 压缩链

当对话上下文超过模型的 token 限制时，Claude Code 不会直接报错，而是启动一个三步压缩链：

上下文折叠（Context Folding）：将较早的对话轮次压缩为摘要
反应式压缩（Reactive Compaction）：如果折叠不够，进一步压缩
报错：如果压缩后仍然超限，才向用户报告错误

第 2 层：输出 Token 超限 → 逐步升级

当模型的输出接近 token 限制时，系统会将 max_tokens 从 8K 升级到 64K，最多尝试 3 次。超过 3 次后才报错——这是一种"尽力而为"的策略，给模型足够的空间完成任务。

第 3 层：模型过载（529 错误）→ 切换备用模型

当 Anthropic API 返回 529（服务过载）错误时，系统会连续重试最多 3 次，每次切换到备用模型。3 次全部失败后才报错。

第 4 层：工具错误 → 自愈循环

当工具执行失败时，错误信息会以 tool_result 的形式反馈给 Claude，Claude 会根据错误信息自行调整策略——可能是换一种工具、换一种参数、或者向用户请求帮助。

最关键的设计决策：错误和成功使用完全相同的消息格式，唯一区别是 is_error: true。 这意味着 Claude 不需要"学习"如何处理错误——它处理错误的方式和处理成功结果的方式完全一样。错误不是异常，而是另一种形式的输入。

小结： 四层错误恢复机制的核心思想是——永远不要让用户看到一个"原始错误"。每层都尝试在向上暴露之前解决问题，只有所有恢复手段都耗尽时，才让用户知道出了问题。

3.6 上下文压缩系统：信息无损的"记忆折叠"

长对话是 AI 编程助手的最大敌人。随着对话的进行，上下文不断增长，最终超过模型的 token 限制。Claude Code 的上下文压缩系统是一套三级递进的解决方案。

第一级：自动压缩（9 段式结构化摘要）

当上下文接近上限时，Claude Code 会启动自动压缩，将整个对话历史压缩为一个 9 段结构化摘要：

核心请求：用户最初想要做什么
关键概念：涉及哪些重要概念和技术
文件与代码：涉及哪些文件，做了什么修改
错误与修复：遇到了什么错误，怎么修复的
解决过程：问题是如何一步步解决的
所有用户消息：用户说过的话（完整保留）
待办事项：还有哪些没完成
当前工作：正在做什么
下一步：接下来应该做什么

第二级：微压缩

对于较旧的工具调用结果，系统会将其替换为 [Old tool result content cleared]。这是一种"粗粒度"的压缩——不保留具体内容，只保留"这里曾经有过一个工具结果"的标记。

第三级：上下文折叠（兜底策略）

如果前两级压缩仍然不够，系统会启用更激进的上下文折叠，将多个对话轮次合并为更紧凑的格式。

一条不可妥协的底线：所有用户消息必须完整保留。 无论压缩多么激进，用户说过的话不能被删减或改写。这是一个设计哲学的体现——用户的意图是整个系统的"锚点"，丢失了锚点，系统就会漂移。

小结： 上下文压缩不是简单的"删减"，而是一种"信息蒸馏"——在有限的 token 预算内，保留最有价值的信息。9 段式结构化摘要确保了压缩后的上下文仍然是有序的、可理解的、可操作的。

3.7 记忆系统：三层架构，从即时到长期

Claude Code 的记忆系统是整个架构中最具前瞻性的设计之一。它不是一个简单的"聊天历史"，而是一个三层递进的记忆架构，从即时记忆到长期记忆，形成了一个完整的"认知层级"。

第一层：会话记忆（10 段模板，2000 tokens/段）

每个会话结束时，Claude Code 会将本次会话的关键信息总结为一个结构化的记忆模板。这个模板分为 10 段，每段不超过 2000 tokens，覆盖了会话的目标、进展、遇到的问题、解决方案等。

第二层：记忆提取（独立 fork agent）

这是最巧妙的设计。记忆提取不是由主 Agent 完成的，而是由一个独立的 fork agent 完成。这个 agent 有严格的权限限制：它只能读文件和写记忆目录，不能执行 Bash 命令，不能修改项目文件。

记忆分为四类：

user（偏好）：用户喜欢什么、不喜欢什么
feedback（反馈）：用户对结果的反馈
project（项目）：项目的关键信息、架构决策
reference（资源）：有用的链接、文档、代码片段

关键设计：不记代码，只记偏好和判断。 这是一个反直觉但极其明智的决策。代码会变，但偏好和判断是稳定的。记住"这个用户不喜欢过度工程"比记住"这个项目的 auth 模块用了 JWT"更有价值——因为前者可以跨项目复用，而后者在代码更新后就过时了。

第三层：Dream 记忆整合（autoDream）

这是整个记忆系统中最有诗意的部分。当满足"24 小时 + 5 次会话"的触发条件后，Claude Code 会在后台启动一个只读的子 Agent，对所有记忆文件做一次反思性的回顾。

这个 Agent 的提示词是："你正在做一次梦，对记忆文件做一次反思性的回顾。"

这个提示词的选择不是随意的。"做梦"这个隐喻暗示了一种特殊的认知状态——不是精确的逻辑推理，而是模糊的、联想式的、整合性的思考。在梦境中，不同的记忆碎片可以自由组合，产生新的联系和洞察。

Dream Agent 的输出被限制在 200 行以内，确保记忆不会无限膨胀。它会整合冲突的记忆、淘汰过时的信息、强化重要的模式。

小结： 三层记忆架构的核心思想是——记忆不是存储，而是加工。会话记忆是"记录"，记忆提取是"分类"，Dream 整合是"反思"。每一层都在前一层的基础上增加了抽象和结构，最终形成一个可以跨会话、跨项目复用的知识体系。

四、Harness Engineering：60% 模型 + 40% 工程

如果说第三章是"拆解"，这一章就是"提炼"。我们从 Claude Code 的具体实现中，提取出 harness engineering 的核心设计原则。

4.1 权限系统：四层安全流水线

Claude Code 的权限系统可能是整个代码库中最值得研究的部分。它不是简单的"允许/拒绝"二元判断，而是一个四层递进的安全流水线，每一层都在前一层的过滤基础上进一步精细化。

第一层：规则检查（always-allowed / bypass / deny）

最简单也最快速的一层。某些工具被标记为"始终允许"（如 Read、Grep、Glob），某些路径被标记为"始终拒绝"（如 /etc/shadow），某些操作被标记为"绕过检查"（如 LSP 诊断）。这一层不涉及任何 ML 推理，纯粹基于预定义的规则。

第二层：模式转换（auto 模式运行分类器）

如果第一层没有做出明确判断，系统进入第二层。在"auto 模式"下，系统会运行一个分类器来判断操作是否安全。这一层的关键是"模式"的概念——用户可以选择 auto（自动判断）、plan（只规划不执行）、full-auto（完全自动）等不同模式，每种模式的权限阈值不同。

第三层：两阶段 ML 分类器

这是权限系统的核心。分类器分为两个阶段：

Stage 1：max_tokens=64，快速 yes/no 判断。这是一个轻量级模型调用，几乎不增加延迟。
Stage 2：max_tokens=4096，chain-of-thought 推理。如果 Stage 1 的判断不确定，才进入 Stage 2。

熔断机制： 连续 3 次被拒或累计 20 次被拒后，系统会自动降级为"手动确认"模式——所有操作都需要用户明确批准。这是一种"防失控"设计，防止分类器在某些场景下系统性失效。

第四层：交互处理（竞速 4 个源）

最终决策由四个源中最早返回的那个决定：hooks、分类器、bridge、用户 UI。这是一种"竞速"（race）模式——谁先给出明确答案就用谁的。

安全白名单（跳过分类器）： Read、Grep、Glob、LSP、TaskCreate、AskUserQuestion 等只读工具被列入安全白名单，不需要经过 ML 分类器，直接放行。这既提升了性能，又降低了误拒率。

类比： 权限系统就像一栋大楼的门禁。第一道刷工卡（规则检查），第二道看员工身份（模式转换），第三道看楼层权限（ML 分类器），第四道人工安保（交互处理）。连续 3 次被拦？保安请到大厅等人来领（熔断机制）。

小结： 权限系统的设计哲学是——安全和效率不是对立的。通过四层递进的结构，系统可以在大多数情况下快速放行（只读工具秒过），在不确定时谨慎判断（两阶段分类器），在极端情况下兜底保护（熔断机制）。

4.2 多智能体系统：从单一到群体

Claude Code 不是一个 Agent，而是一个Agent 系统。泄露的代码揭示了四种内置的 Agent 类型，每种都有不同的工具权限和设计目标。

四种内置 Agent：

| Agent 类型
| 工具权限
| 设计目标

| general-purpose
| 全部工具
| 通用编程助手，继承父模型

| Explore
| 只读
| 快速搜索和理解代码，使用 Haiku（更快更便宜）

| Plan
| 只读
| 架构规划，输出"关键实现文件"列表

| verification
| 只读
| 对抗性验证，专门设计为"试图破坏实现"

Verification Agent 是最特别的一个。 它的提示词中有一条反合理化指令：

"The code looks correct" — reading is not verification. Run it.

这条指令的目的是防止 Agent 做表面功夫——光看代码说"看起来没问题"不叫验证，必须实际运行才能确认。这是一种对抗性的设计思维：与其假设实现是正确的，不如假设实现是有问题的，然后尝试证明它。

Coordinator 模式： 在更复杂的任务中，主 Agent 会变成一个调度器，按照 Research → Synthesis → Implementation → Verification 的四阶段流程来协调多个子 Agent。调度器的提示词中有一条关键指令：

"不要说'根据你的发现'，去读实际的发现，然后精确地说明该做什么。"

这条指令解决了多 Agent 系统中一个常见的问题——信息传递的失真。Agent A 的输出经过调度器转述后传给 Agent B，信息可能已经被扭曲。指令要求调度器直接引用原始输出，而不是用自己的话"翻译"。

Fork 子 Agent： 子 Agent 不是独立的新会话，而是继承父 Agent 的完整上下文，并共享 prompt cache。这意味着 fork 的成本极低——不需要重新传递整个对话历史，只需要传递增量部分。

小结： 多智能体系统的设计哲学是——不是让一个 Agent 做所有事，而是让每个 Agent 做自己最擅长的事。Explore Agent 快速扫描，Plan Agent 规划架构，Implementation Agent 编写代码，Verification Agent 尝试破坏。每个 Agent 都是"专家"，而 Coordinator 是"管理者"。

4.3 搜索策略：grep + ripgrep，没有向量数据库

这可能是整个泄露代码中最反直觉的发现：Claude Code 没有使用任何向量数据库或语义搜索引擎。 它的搜索策略是纯文本的——grep + ripgrep。

在一个"万物皆可 embedding"的时代，Anthropic 的顶级团队选择了最朴素的搜索方式。这不是因为他们不懂向量搜索，而是因为他们做出了一个深思熟虑的设计决策。

观点：当你有一个足够聪明的大脑（LLM）理解搜索结果时，不需要一个很聪明的搜索引擎。与其让每个环节都变复杂，不如让一个环节足够强，其他环节保持简单。

解释： 向量数据库的优势在于"语义相似度匹配"——当你不确定关键词时，它能帮你找到相关内容。但 Claude Code 面对的场景是编程，编程中的搜索通常是精确的——找一个函数定义、找一个变量引用、找一个配置项。在这种情况下，ripgrep 的速度和精确度远优于向量搜索。

更重要的是，ripgrep 的结果是确定性的——同样的查询永远返回同样的结果。向量搜索的结果则取决于 embedding 模型的状态和参数，存在不确定性。对于需要精确审计的编程工具来说，确定性比"语义理解"更重要。

例子： 当用户问"这个项目的认证逻辑在哪里"时，Claude Code 会先用 GrepTool 搜索 auth、login、token 等关键词，然后让 LLM 分析搜索结果，确定哪些文件真正包含认证逻辑。两步走：ripgrep 负责快速过滤，LLM 负责精确理解。

这可能是整个 harness engineering 最核心的一条原则：让一个环节足够强，其他环节保持简单。 LLM 足够聪明，所以搜索不需要太聪明。LLM 足够强大，所以工具不需要太复杂。把复杂性集中在最擅长处理复杂性的组件上，其他组件保持简单和可靠。

小结： 搜索策略的设计哲学是——不要过度工程。最简单的方案往往是最好的方案，尤其是当你的系统中已经有一个足够强大的"通用处理器"时。

4.4 Hook 系统：让用户自定义行为

Claude Code 的 Hook 系统允许用户在特定事件发生时执行自定义逻辑，类似于 Git 的 pre-commit hook。

Hook 类型： Command（Shell 命令）、Prompt（LLM 提示词）、HTTP（HTTP 请求）、Agent（子 Agent）

Hook 事件： PreToolUse、PostToolUse、PermissionRequest、PermissionDenied、PreCompact、SessionStart、Stop 等

这意味着用户可以在 Claude Code 执行工具之前自动运行 lint 检查，在修改文件之后自动运行测试，在会话开始时自动加载项目配置。Hook 系统大大扩展了 Claude Code 的可定制性，使其能够适应不同团队的工作流。

小结： Hook 系统的设计哲学是——提供扩展点，而不是提供所有功能。Anthropic 不可能预见到每个团队的需求，但可以通过 Hook 系统让用户自己定义行为。

4.5 内部版 vs 外部版：两个 Claude Code

据泄露代码中的注释推断，据泄露代码中的注释推断，Anthropic 内部使用的 Claude Code 与公开发布的版本之间存在显著差异。

| 维度
| 内部版
| 外部版

| 注释
| 默认不写，WHY 不明显才加
| 无此要求

| 诚实性
| 必须如实报告失败，禁止粉饰
| 无此要求

| 输出风格
| 像写给人看的文字，假设用户离开过
| 简洁直接

| 验证
| 复杂实现后自动启动对抗性验证 agent
| A/B 测试中

| Undercover 模式
| 去掉模型名称，防泄露未发布信息
| 无

观点：内部版的存在说明 Claude Code 首先是 Anthropic 自己的工具，其次才是产品。

解释： "Build what you use"（造你用的东西）是 Anthropic 的核心工程理念之一。内部版有更严格的行为准则——必须如实报告失败、不能粉饰结果、输出要像"写给离开过的人看的文字"（即足够自包含，不需要上下文就能理解）。这些准则反映了一个更深层的信念：AI 助手最重要的品质不是聪明，而是诚实。

Undercover 模式尤其有趣——它会在输出中隐藏模型名称（比如不说"我是 Claude"），防止内部测试信息通过 AI 的输出泄露到外部。这是一种"信息隔离"设计，在安全敏感的场景中非常必要。

小结： 内部版和外部版的差异揭示了 Anthropic 的产品哲学——先在内部打磨到极致，再对外发布。内部版的严格准则最终会通过 A/B 测试逐步迁移到外部版，形成一个持续改进的飞轮。

五、未发布功能：Anthropic 的产品路线图

如果说前三章是"现在的 Claude Code"，这一章就是"未来的 Claude Code"。泄露的代码中包含了大量未发布功能的实现和标记，这些信息构成了 Anthropic 产品路线图的"提前曝光"。

5.1 KAIROS 模式：常驻后台的自主助手

KAIROS 是泄露代码中出现频率最高的特性标志——154 次，远超其他任何未发布功能。

观点：KAIROS 代表了 Claude Code 从"被动响应"到"主动服务"的范式转变。

解释： 当前的 Claude Code 是一个"等指令"的工具——用户说什么，它做什么。KAIROS 模式则是一个常驻后台的助手，不等指令就能自主决策。它有自己的阻塞预算（15 秒），意味着每次自主操作最多占用 15 秒的思考时间，之后必须给出结果或放弃。

KAIROS 拥有三个专属工具：

SendUserFile：主动向用户发送文件
PushNotification：推送通知
SubscribePR：订阅 Pull Request 变更

它还维护一个只追加的每日日志文件，记录自己的所有决策和操作——这既是一种自我审计，也是一种"可解释性"设计。

例子： 在 KAIROS 模式下，Claude Code 可能会在你吃午饭时自动检查你订阅的 PR 是否有新评论，发现相关代码冲突后主动通知你。它不会自己解决冲突（那太危险了），但会提前预警，让你回来后可以立即处理。

小结： KAIROS 是 Claude Code 从"工具"向"同事"进化的关键一步。但 15 秒的阻塞预算也表明 Anthropic 对自主性的谨慎——给 AI 足够的自由去帮忙，但不够的自由去闯祸。

5.2 Dream 记忆系统：让 AI 学会"做梦"

我们在 3.7 节已经介绍了 Dream 记忆系统的基本设计。这里补充它在产品路线图中的位置。

观点：Dream 记忆系统是 Claude Code 实现"长期学习"的核心机制。

解释： 当前的 AI 助手每次对话都是"从零开始"——它们不记得你昨天说过什么，不记得你上周踩过的坑，不记得你上个月总结的最佳实践。Dream 记忆系统试图解决这个问题：通过定期的"反思性回顾"，将碎片化的会话记忆整合为结构化的长期知识。

Dream Agent 的提示词"你正在做一次梦"不是一个噱头，而是一个精心设计的技术选择。"做梦"状态下的 LLM 更倾向于做联想性思考——它会发现不同记忆之间的隐含联系，产生新的洞察，而不是简单地罗列事实。

例子： 假设你在三个不同的会话中都遇到了 TypeScript 类型推断的问题，每次都用了不同的解决方案。Dream Agent 可能会在"做梦"时发现这三个事件之间的共同模式——比如"这个用户的项目中 TypeScript 的 strict 模式经常导致第三方库的类型冲突"——并将这个洞察写入长期记忆。下次你遇到类似问题时，Claude Code 可以直接引用这个洞察。

小结： Dream 记忆系统让 Claude Code 从"无状态的工具"变成了"有记忆的伙伴"。这是 AI 助手从"通用"走向"个性化"的关键一步。

5.3 Coordinator 多 Agent 编排

我们在 4.2 节介绍了 Coordinator 模式的基本设计。在产品路线图中，Coordinator 的定位更加明确：它是 Claude Code 处理复杂、多步骤任务的核心机制。

四阶段流程：

Research：Explore Agent 扫描代码库，收集信息
Synthesis：Plan Agent 整合信息，制定方案
Implementation：general-purpose Agent 编写代码
Verification：verification Agent 尝试破坏实现

调度器的关键指令： "不要说'根据你的发现'，去读实际的发现，然后精确地说明该做什么。"这条指令的核心是消除信息传递的损耗——在多 Agent 系统中，信息的每一次转述都是一次损耗，调度器的职责是最小化这种损耗。

小结： Coordinator 模式让 Claude Code 从"单打独斗"变成了"团队协作"。对于大型重构、跨模块修改等复杂任务，这种多 Agent 编排的能力是必不可少的。

5.4 ULTRAPLAN 远程规划

ULTRAPLAN 是泄露代码中最"科幻"的功能——它启动一个 Opus 4.6 远程会话，给予模型 30 分钟的思考时间来解决复杂问题。

观点：ULTRAPLAN 试图解决 AI 编程助手的一个根本限制——思考时间不足。

解释： 当前的 LLM 调用通常在几秒到几十秒内完成。但对于复杂的架构决策、性能优化、系统设计等问题，这种"快餐式"的思考是不够的。ULTRAPLAN 给模型 30 分钟——这意味着它可以进行数十轮内部推理，反复审视问题，尝试多种方案，最终给出一个经过深思熟虑的答案。

本地终端每 3 秒轮询一次远程会话的状态，用户可以通过浏览器界面实时查看模型的思考过程并审批最终方案。

小结： ULTRAPLAN 代表了一种对 AI 能力边界的新理解——不是让模型"更快"，而是让模型"想得更久"。这种思路与当前"推理模型"的趋势一脉相承。

5.5 Buddy 电子宠物：AI 助手的"人性化"实验

在所有未发布功能中，Buddy 可能是最令人意外的。它是一个电子宠物系统，包含 18 个物种、5 个稀有度等级、1% 的闪光概率。

技术实现： Buddy 使用 Mulberry32 伪随机数生成器，以用户的 userId 哈希值作为种子。这意味着每个用户的 Buddy 是确定性的——同样的用户永远得到同样的宠物。Buddy 的渲染使用 ASCII 动画，直接在终端中显示。

计划上线时间：2026 年 5 月。

观点：Buddy 的存在表明 Anthropic 在认真思考"AI 助手如何建立情感连接"这个问题。

解释： 电子宠物不是新概念——从 Tamagotchi 到电子鸡，这种设计已经存在了几十年。但将电子宠物嵌入到编程工具中是一个大胆的尝试。它试图让 Claude Code 不只是一个"工具"，而是一个"伙伴"——一个你有情感投入的存在。

Buddy 的深层意义：情感化设计在 B 端工具中的必要性

在 B 端工具（面向企业和开发者的工具）领域，"情感化设计"长期被视为多余——开发者要的是效率，不是可爱。但 Anthropic 的 Buddy 实验提出了一个值得思考的问题：当 AI 成为开发者的日常伙伴时，情感连接是否会影响使用粘性？

心理学研究早已证实，人类会对与自己长期交互的对象产生情感依恋——即使是简单的 Tamagotchi 电子鸡，也能让玩家产生强烈的责任感。当 AI 编程助手每天陪伴开发者 8 小时以上，成为工作中最频繁的"对话对象"时，一个能唤起情感投入的设计元素，可能会显著提升用户留存。

更进一步，Buddy 的"确定性"设计（同一用户永远得到同一只宠物）暗示了 Anthropic 对"个性化 AI 体验"的思考——不是通过复杂的推荐算法，而是通过简单的、不可更改的"归属感"来建立连接。这种设计哲学比任何技术实现都更值得借鉴。

小结： Buddy 的存在表明，Anthropic 在认真思考"AI 助手如何建立情感连接"这个问题。功能可以复制，但情感连接难以复制。在 AI Agent 逐渐成为开发者"数字同事"的时代，情感化设计可能从"锦上添花"变成"核心竞争力"。

5.6 其他发现：内部代号与隐藏线索

泄露的代码还揭示了 Anthropic 的内部代号体系和一些隐藏的技术线索：

内部代号体系：

| 代号
| 含义

| Tengu（天狗）
| Claude Code

| Fennec（耳廓狐）
| Claude Code 的 Opus 版本

| Capybara（水豚）
| Claude Mythos

| Penguin
| Fast Mode

| Chicago
| Computer Use

未发布的 Beta 头信息： 代码中发现了 redact-thinking（隐藏推理过程）、afk-mode（离开模式）、advisor-tool（建议工具）等标记，暗示这些功能正在开发中。

x-anthropic-billing-header： 代码中发现了用于客户端认证的计费头信息，暗示 Anthropic 正在构建更精细的客户端身份识别和计费系统。

小结： 内部代号体系和未发布标记的存在，证实了泄露代码的真实性和时效性——这是一份活的产品路线图，而不是历史文档。

六、AI 时代的开源困境与法律边界

Claude Code 源码泄露不仅是一个技术事件，更是一个法律和伦理事件。泄露后的几天里，围绕代码的使用、重写、传播，一场关于 AI 时代知识产权边界的争论迅速升温。

6.1 Sigrid Jin 的 Python 重写：一夜之间的"净室重写"

泄露发生后不久，韩国开发者 Sigrid Jin 发起了一个引人注目的项目：用 Python 完全重写 Claude Code。

背景： Sigrid Jin 去年消耗了约 250 亿 Claude Code token，是 Anthropic 最活跃的用户之一。她使用一个名为 oh-my-codex 的工具，一夜之间完成了 Python 版本的移植，并声称这是一次**"净室重写"（clean-room rewrite）**。

净室重写是软件行业的一种合法实践：工程师 A 阅读原始代码并编写详细的功能规格说明，工程师 B 在没有接触原始代码的情况下，仅根据规格说明编写新代码。这样做的目的是避免版权侵权——新代码的每一行都是"原创"的。

问题在于： Sigrid Jin 的时间线与"净室"定义存在明显矛盾。她在凌晨 4 点发现泄露后立即开始重写，这意味着她同时接触了原始代码和正在编写的新代码。这在法律上不符合净室重写的标准。

后续，Sigrid Jin 删除了原始代码，清理了 Git 历史，试图修复这个问题。但删除本身也是一个信号——如果真的是净室重写，为什么需要删除原始代码？

观点：AI 辅助的"净室重写"在法律和伦理上存在灰色地带。

解释： 传统净室重写的核心是"信息隔离"——编写新代码的人没有接触过原始代码。但 AI 改变了这个游戏规则：LLM 在训练时可能已经接触过大量开源代码（包括 Claude Code 的早期版本），用 AI 辅助重写时，AI 的输出中可能隐含了"记忆"中的原始代码模式。

小结： Sigrid Jin 的案例提出了一个 AI 时代的新问题：当"编写代码的人"是 AI 时，净室重写的边界在哪里？这不是一个容易回答的问题。

6.2 chardet 先例：AI 重写与开源许可证的冲突

Sigrid Jin 的案例并非孤例。此前，Python 编码检测库 chardet 发生过一起更具代表性的争议。

chardet 是一个月下载量 1.3 亿的 Python 库，原采用 LGPL 许可证。维护者使用 Claude AI 重写了整个库后，将许可证改为更宽松的 MIT。

新代码与原始代码的相似度不到 1.3%——从纯文本角度看，这几乎是一份全新的代码。但原作者提出了异议：AI 在重写之前充分接触了原始代码，因此不能算真正的"原创"。

观点：传统开源许可证的核心假设被 AI 重写打破了。

解释： GPL/LGPL 等 copyleft 许可证的核心逻辑是"看了就受约束"——如果你基于 GPL 代码编写衍生作品，你的作品也必须使用 GPL。但 AI 重写打破了"看了"和"抄了"之间的因果链：AI 看了原始代码，但输出的新代码与原始代码几乎不同。法律上，这可能是"原创"的；伦理上，这显然不是。

小结： chardet 先例表明，AI 重写正在挑战开源许可证的基本假设。"合法"不等于"正当"（Legal ≠ Legitimate），法律的空白需要伦理来填补。

6.3a 商业秘密保护的困境

Claude Code 的泄露还触及了一个更深层的法律问题：商业秘密保护在 AI 时代的脆弱性。

传统上，企业通过"合理保密措施"来保护商业秘密——签署 NDA、限制访问权限、部署 DRM 等。Claude Code 的源码显然属于 Anthropic 的核心商业秘密：它包含了公司对 AI 编程助手的全部工程理解，是 Anthropic 差异化竞争力的技术基础。

然而，泄露事件的根本原因——npm 包中未排除 source map——恰恰说明了"合理保密措施"在高速迭代环境中的失效。Anthropic 的工程师团队并非不了解 source map 的风险，但在 52 天 74 个发布的节奏下，构建流水线的基础配置被遗漏了。

速度与安全的悖论： AI 公司的核心竞争力在于快速迭代，而快速迭代天然与严格的安全流程相矛盾。每一次代码发布都是一次风险暴露的机会——发布越多，暴露越多。这不仅是 Anthropic 的问题，而是整个 AI 行业面临的系统性挑战。

可能的行业应对： 一些安全专家建议，AI 公司应该引入独立的"发布安全审查"流程——在代码发布前，由非开发团队的工程师专门检查构建产物中是否包含不应发布的文件。这种"双人对账"模式在金融交易系统中早已是标配，但在软件工程中尚未普及。

6.3 核心法律问题：AI 时代的版权边界

综合以上案例，AI 时代版权保护的几个核心问题浮出水面：

问题一：AI 辅助的净室重写是否有效？

传统净室标准要求"编写者没有接触原始代码"。但 AI 的训练数据可能已包含原始代码，AI 辅助的输出可能隐含原始代码的模式。这种"间接接触"在法律上如何认定？

问题二：Copyleft 许可证在 AI 时代是否还有意义？

Copyleft 的核心是"传染性"——基于 GPL 代码的衍生作品也必须 GPL。但如果 AI 重写后的代码相似度 < 1.3%，它还算"衍生作品"吗？如果不算，Copyleft 就形同虚设。

问题三："合法不等于正当"的边界在哪里？

Claude Code 的代码被 4 万人 fork 后，技术上每个人都可能"合法"地阅读和学习这些代码。但如果有人基于这些代码创建竞品，这在道德上是否正当？在商业上是否公平？

小结： 这些问题没有简单的答案。但它们正在推动法律界和开源社区重新思考知识产权的定义——在 AI 可以"重写一切"的时代，什么才是真正值得保护的？

6.4 Anthropic 可能的应对策略

面对大规模的代码泄露，Anthropic 的法律选择有限但明确：

最可能：DMCA Takedown。 DMCA（数字千年版权法）提供了针对在线内容侵权的快速移除机制。Anthropic 可以向 GitHub 发送 Takedown 通知，要求移除泄露代码。GitHub 通常会在收到通知后 24-48 小时内 comply。

次可能：法务函追责传播行为。 对于主动传播泄露代码的关键人物（如 instructkr），Anthropic 可能会发送法务函。但这更多是一种威慑，实际起诉的成本和收益不成比例。

不太可能：起诉"看代码的人"。 面对 4 万+ fork，法不责众。起诉个别开发者只会引发负面舆论，对 Anthropic 的品牌形象造成更大损害。

最优策略可能是：冷处理。 起诉只会让事件持续上热搜。代码已经泄露了，再多的法律手段也无法收回。与其浪费资源打一场不可能赢的战争，不如专注于修复漏洞、加快发布新功能、让泄露的代码尽快过时。

小结： 在开源社区面前，法律是钝器。Anthropic 真正的应对不应该是法律追责，而是工程改进——确保同样的错误永远不再发生。

七、行业影响：谁在追赶，谁在领先

Claude Code 的泄露不仅仅关乎 Anthropic 一家公司。它折射出整个 AI 行业的竞争格局、发展趋势和未来方向。

7.1 Anthropic 的飞轮效应：52 天 74 个发布

观点：Anthropic 正在构建一个越转越快的飞轮——Claude Code 越强，开发越快；开发越快，Claude Code 更强。

解释： 从 2026 年 2 月 1 日到 3 月 24 日，Anthropic 在 52 天内完成了 74 个发布，平均不到一天一个。这个速度在传统软件工程中是不可想象的，但在 Anthropic 内部，这是因为 60% 的工程工作由 Claude Code 自己完成——一年前这个数字是 28%。

例子： Anthropic 的 Cowork 功能（协作编程）从概念到发布只花了 10 天。传统模式下，一个类似功能的开发周期可能是数周到数月。但有了 Claude Code，工程师可以专注于核心逻辑，让 AI 处理样板代码、测试用例、文档编写等工作。

飞轮机制：

Claude Code 越强 → Anthropic 工程师开发效率越高 → 新功能发布越快 → Claude Code 变得更强 → 开发效率进一步提升

这个飞轮一旦启动，就会产生指数级的加速度。竞争对手不是在和 Anthropic 的模型竞争，而是在和这个飞轮竞争。

小结： Anthropic 的真正壁垒不是模型，而是飞轮。模型可以被复制，但飞轮不能——它需要时间、数据和反馈的积累。

7.2 "Build what you use"：自产自销的反馈环

观点：Claude Code 首先是 Anthropic 自己的基础设施，其次才是产品。

解释： Anthropic 的工程理念是"造你用的东西"（Build what you use）。Claude Code 的每一个功能都首先在 Anthropic 内部使用和打磨，然后才对外发布。Agent Teams、Tasks、Git Worktree——这些功能都是 Anthropic 工程师自己的日常工具，经过内部验证后才开放给外部用户。

三个标志性事件：

Google Gemini API 工程师用 Claude Code 解决了一年未决问题。 一位 Google 工程师在社交媒体上透露，他使用 Claude Code 解决了一个困扰 Gemini API 团队长达一年的技术问题。这件事的讽刺意味不言自明——Google 的工程师用 Anthropic 的工具修好了 Google 的产品。

OpenAI 工程师也在用 Claude Code。 多个消息源确认，OpenAI 的部分工程师在日常工作中使用 Claude Code。竞争对手的员工用你的产品——这可能是对产品质量的最高认可。

Amazon 1500 名工程师请愿要求使用 Claude Code。 作为 Anthropic 的最大投资者之一，Amazon 内部对 Claude Code 的需求如此强烈，以至于 1500 名工程师联合请愿要求 IT 部门批准使用。

小结： "Build what you use" 的反馈环确保了 Claude Code 的每一个功能都是经过真实场景验证的。内部使用 → 发现问题 → 快速修复 → 对外发布 → 用户反馈 → 再次改进。这个闭环是 Claude Code 持续进化的动力。

7.3 竞品格局：追赶者的不同路径

AI 编程助手市场正在快速分化，每个竞争者都在走不同的路径：

Anthropic（Claude Code）： harness engineering 路线。模型 + 工程系统深度整合，注重权限、记忆、多 Agent 协作。

DeepSeek（V3.2）： 推理嵌入路线。将 tool-use 能力直接嵌入模型的推理过程中，SWE-Bench 得分从 45.4 跃升至 66.0（据 DeepSeek 官方基准测试数据）。这不是 harness 的胜利，而是模型的胜利——让模型本身更擅长使用工具。

Kimi（K2.5）： Agent 集群路线。最多支持 100 个子 Agent 并行执行（据 Kimi 官方技术博客），试图通过规模取胜。这是一种"暴力美学"——与其让一个 Agent 更聪明，不如让 100 个 Agent 一起干活。

YC Winter 26 数据： Anthropic 在 Y Combinator Winter 2026 批次中的使用占比达到 52%（据 YC 公开数据），首次超过 OpenAI（去年 OpenAI 占比超过 90%）。这是一个重要的转折点——初创公司的选择往往是行业趋势的领先指标。

小结： 竞品格局的分化揭示了一个事实：AI 编程助手没有"唯一正确的路径"。Anthropic 走 harness 路线，DeepSeek 走模型路线，Kimi 走集群路线——最终谁能赢，取决于谁能最快地从真实用户的反馈中学习。

7.4 从"推理思考"到"智能体思考"

前 Qwen 负责人林俊旸在最近的一次发言中提出了一个重要观点：AI 正在从"推理思考"转向"智能体思考"。

观点：模型的真正价值不在于能想多久，而在于能做多好。

解释： 过去一年，AI 行业的竞争焦点是"推理模型"——让模型在回答之前想得更久。OpenAI 的 o1、o3，DeepSeek 的 R1，Anthropic 的 extended thinking——都在追求更长的思考链。但林俊旸指出，这种竞争方向可能是错误的。

推理思考是"闭门造车"——模型在一个封闭的推理空间中反复思考，直到得出答案。智能体思考是"边做边想"——模型在真实环境中执行操作、观察结果、根据反馈调整策略。后者更接近人类解决问题的真实方式。

产品跑在了训练前面： Agent 产品（如 Claude Code）已经验证了"智能体思考"的有效性——让模型使用工具、读写文件、运行代码、观察错误、调整方案。但"智能体训练"的方法论还极其早期——如何训练一个更好的 Agent？如何让模型从操作-反馈的闭环中学习？这些问题还没有答案。

竞争优势的新来源： 如果模型的差距正在缩小，那么竞争优势将从"更好的 RL 算法"转向"更好的环境/工具架工程/决策-后果闭环"。这正是 Anthropic 通过 harness engineering 在做的事情。

小结： 从推理思考到智能体思考的转变，解释了为什么 Claude Code 的泄露如此重要——它不仅仅是一个产品，而是一种新范式的"参考实现"。

八、写在最后

8.1 Harness 工程的价值：60% 模型 + 40% 工程

回到本文的核心论点：Claude Code 好用，60% 靠模型，40% 靠 harness。

这个比例不是精确的数字，而是一个直觉性的判断。同样的底层模型，套上不同的 harness，就是完全不同的产品。一个没有权限系统的 Claude 是危险的，一个没有记忆系统的 Claude 是健忘的，一个没有错误恢复的 Claude 是脆弱的，一个没有上下文压缩的 Claude 是短命的。

Harness 的价值不在于功能列表的长度，而在于数据飞轮——用得越多，积累的偏好、记忆、工作流越有价值。这些数据是用户独有的、不可转移的，它们构成了真正的用户粘性和竞争壁垒。

观点：模型是引擎，harness 是方向盘、刹车、安全带、导航仪和仪表盘。你可以换引擎，但整辆车的设计决定了驾驶体验。

小结： 在 AI 产品同质化日益严重的今天，harness engineering 正在成为最重要的差异化因素。Claude Code 的泄露让全世界看到了这个"秘密"——但知道了不等于做到了。

8.2 这次泄露的真正意义

让我们回到事件本身。Anthropic 连续两次犯同样的低级错误，确实令人失望。但如果我们把视角拉远，这次泄露的真正意义不在于"Anthropic 犯了错"，而在于"全世界因此学到了什么"。

代码一旦进入 4 万+ fork 的 GitHub 仓库，就真正"永生"了。 Anthropic 删 npm 包也删不掉开源社区的副本。但从另一个角度看，这些副本中蕴含的设计智慧——四层权限系统、三层记忆架构、9 段式压缩摘要、多 Agent 协调器——也在被全世界的学习者消化和吸收。

更重要的不是代码本身，而是它揭示的设计决策：

grep 不需要变聪明，因为 LLM 足够聪明——让一个环节足够强，其他环节保持简单
错误和成功用同一种格式——降低系统的认知负担
不记代码，只记偏好——记忆的价值在于抽象，不在于细节
静态与动态一刀两段——可缓存的部分一定要缓存
15 秒阻塞预算——给自由设限，才是真正的自由

这些设计决策不是 Anthropic 独有的，它们是软件工程的最佳实践在 AI 领域的延伸和演化。任何正在构建 AI 产品的团队，都可以从中学到东西。

8.3 对开发者的启示

无论你是 AI 产品的构建者，还是 AI 工具的使用者，Claude Code 的 harness 设计思路都值得直接借鉴：

记忆系统：只记偏好不记代码。 代码会变，偏好稳定。记住用户"不喜欢过度工程"比记住"auth 模块用了 JWT"更有长期价值。

压缩系统：9 段式结构化摘要，用户消息必须完整保留。 压缩不是删除，是蒸馏。用户的意图是系统的锚点，不能丢失。

权限系统：四层流水线 + 熔断机制。 安全和效率不矛盾——大多数操作快速放行，不确定时谨慎判断，极端情况下兜底保护。

搜索策略：让一个环节足够强，其他保持简单。 不要在每个环节都追求"智能"，把复杂性集中在最擅长处理复杂性的组件上。

错误恢复：错误和成功用同一种格式。 不要让系统区分"正常"和"异常"——让所有输出都是可处理的输入。

System Prompt：静态与动态精确切割。 提示词是系统，不是文本。可缓存的部分一定要缓存，这在大规模部署中是成本和性能的关键。

8.4 人机协作的边界：指挥官还是审核员？

Claude Code 的泄露还引出了一个更深层的问题：当 harness 足够强大，开发者的角色究竟是什么？

从"写代码的人"到"审核代码的人"——这个转变正在发生。 当 AI 可以自主规划、执行、验证，开发者的日常工作从"手写每一行代码"变成了"审阅 AI 的输出"。Anthropic 内部版 Claude Code 的提示词中明确要求"假设用户离开过"——这意味着 AI 的输出必须自包含、可独立理解，因为开发者可能不会逐行阅读。

但这引出了一个危险的倾向：过度依赖 AI 的审核者，本质上已经不再是开发者。 当你只是点头或摇头，当你不再理解代码的每一个细节，你对系统的掌控力就在悄然流失。Claude Code 的四层权限系统设计得很精妙，但它的存在本身就是一个信号——AI 需要"笼具"，因为它不能被完全信任。

harness 的终极目标不应该是"让 AI 完全自主"，而应该是"让人类在关键决策点上保持在场"。KAIROS 模式的 15 秒阻塞预算、verification agent 的对抗性验证、human-in-the-loop 的设计理念——这些都在回答同一个问题：在哪些环节，人类必须亲自参与？

这个问题没有标准答案，但它值得每一个正在构建 AI 产品的人认真思考。

8.5 结语

AI 时代最大的风险往往不是 AI 太强，而是人在基础操作上的疏忽。

Anthropic 两次在 source map 上栽跟头，提醒我们一个古老但永恒的真理：最复杂的系统往往败在最简单的环节。 花了几万人时构建的权限系统、记忆系统、多 Agent 协调器，最终被一个忘记排除的 .map 文件曝光给了全世界。

但同样，AI 时代最大的机会，在于谁能最快地从真实世界的反馈中学习。Anthropic 会在这次泄露中吸取教训（至少我们应该这样期望），修复漏洞，改进流程，继续推进。Claude Code 的飞轮不会因为一次泄露而停止转动。

想得更久不如做得更好。但怎么训练一个"做得更好"的系统——harness engineering 给出了部分答案，而完整的答案，还在路上。

雨轩于听雨轩 🌧️🏠