Edit: Claude Code 源码泄露事件深度解析：AI 行业从"模型竞赛"转向"Ha

编辑文章

标题 *

URL 别名 *

内容 * (支持 Markdown 格式)

# 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 源码：

```bash
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，直接给修复方案。

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

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

**关键设计：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 不会直接报错，而是启动一个三步压缩链：

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

**第 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 段结构化摘要：

1. **核心请求**：用户最初想要做什么
2. **关键概念**：涉及哪些重要概念和技术
3. **文件与代码**：涉及哪些文件，做了什么修改
4. **错误与修复**：遇到了什么错误，怎么修复的
5. **解决过程**：问题是如何一步步解决的
6. **所有用户消息**：用户说过的话（完整保留）
7. **待办事项**：还有哪些没完成
8. **当前工作**：正在做什么
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 处理**复杂、多步骤任务**的核心机制。

**四阶段流程：**

1. **Research**：Explore Agent 扫描代码库，收集信息
2. **Synthesis**：Plan Agent 整合信息，制定方案
3. **Implementation**：general-purpose Agent 编写代码
4. **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 可能看起来像一个无关紧要的小功能，但它反映了 Anthropic 对 AI 产品设计的深层思考：功能可以复制，但情感连接难以复制。

### 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.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 工程师自己的日常工具，经过内部验证后才开放给外部用户。

**三个标志性事件：**

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

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

3. **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。这不是 harness 的胜利，而是模型的胜利——让模型本身更擅长使用工具。

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

**YC Winter 26 数据：** Anthropic 在 Y Combinator Winter 2026 批次中的使用占比达到 **52%**，首次超过 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 结语

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

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

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

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

---

*雨轩于听雨轩* 🌧️🏠

配图 (可多选)

选择新图片文件或拖拽到此处

标签