Claude Code 源码泄露：v2.1.88 硬核技术架构全解析

2026年3月31日，npm 包 @anthropic-ai/claude-code v2.1.88 的构建产物意外解压发布，1,884 个 TypeScript/TSX 源文件、合计 512,664 行代码公之于众。其中最大的模块文件 query.ts 原始大小 785KB（npm 包打包产物），运行时代码行数 1,729 行。

这批源码为我们提供了前所未有的视角，得以窥探这个被 Anthropic 定位为”编程助手”的产品，其内部究竟是一个怎样规模的复杂系统。

本文基于这批泄露源码及配套分析文档，对 Claude Code v2.1.88 的技术架构进行系统性梳理。

一、架构全貌：从入口到查询引擎

1.1 四层入口体系

Claude Code 的启动入口分为四个层次，对应不同运行模式：

cli.tsx（CLI 主入口）
  ├── 版本信息打印
  ├── 帮助信息
  └── daemon 守护进程启动

main.tsx（数千行，REPL 主入口）
  ├── REPL.tsx（交互式命令行界面）
  └── QueryEngine.ts（无头/SDK 查询引擎）

源码路径：src/entrypoints/cli.tsx，src/main.tsx，src/QueryEngine.ts

main.tsx 是整个 CLI 的核心，文件行数数千行，负责：

• 初始化 AppState Store
• 建立 Claude API 连接
• 管理 REPL 会话生命周期
• 挂载所有 React/Ink 组件

1.2 查询引擎的流式架构

QueryEngine.ts 是 headless/SDK 模式的入口，暴露为 AsyncGenerator<SDKMessage> 接口。每次 submitMessage() 调用触发完整的数据流：

submitMessage(prompt)
  │
  ├── fetchSystemPromptParts()      → 组装 system prompt（工具描述、权限规则、CLAUDE.md）
  ├── processUserInput()             → 解析 /slash commands，构建 UserMessage
  ├── recordTranscript()             → 持久化用户消息到磁盘（JSONL）
  │
  └── query()                        → 主循环（785KB 模块的核心逻辑）
        ├── normalizeMessagesForAPI() → 剥离 UI 专用字段，按需压缩
        ├── Claude API (streaming)    → POST /v1/messages with tools
        ├── stream events             → message_start → content_block_delta → message_stop
        ├── text block                → yield 到消费者（SDK / REPL）
        └── tool_use block?           → StreamingToolExecutor 并行分发

源码路径：src/QueryEngine.ts，src/query.ts

query.ts 是整个 Claude Code 系统中单个最大的模块文件，负责：

• while(true) 主循环
• normalizeMessagesForAPI() 上下文标准化
• runTools() 工具编排
• autoCompact() 上下文压缩触发
• recordTranscript() 会话持久化

1.3 工具分发与工厂模式

src/tools.ts 是工具注册表，采用 buildTool() 工厂模式统一管理所有工具实例：

buildTool(definition) → Tool<Input, Output, Progress>

// 工厂提供的能力：
// - validateInput() 默认 Zod 校验
// - checkPermissions() 权限钩子
// - isReadOnly() / isDestructive() 元信息
// - renderToolUseMessage() React 渲染器注册
// - prompt() 动态描述生成

所有工具按功能分为 7 大类，共计 40+ 工具，注册在 tools.ts 的统一 dispatch map 中，循环无需修改——新增工具只需注册到 map。

二、工具系统：40+工具的完整分类与权限架构

2.1 Tool Interface：三阶段生命周期

每个工具实现统一的 Tool 接口，执行分为三个严格阶段：

阶段一：validateInput()

• 使用 Zod Schema 对输入参数进行静态校验
• 在任何权限检查之前执行
• 拒绝格式错误的参数，返回 ValidationError

阶段二：checkPermissions()

• 工具特定的授权逻辑（如 BashTool 的路径沙箱）
• 查询 Permission Rules（alwaysAllow / alwaysDeny / alwaysAsk）
• 执行 PreToolUse Hooks（用户自定义 shell 命令）

阶段三：call()

• 实际执行业务逻辑
• 返回 ToolResult，包含进度（ToolUseProgress）或最终结果
• 结果经 mapToolResultToAPI() 格式化后追加到 messages[]

源码路径：src/Tool.ts

2.2 完整工具分类

文件操作类
  FileReadTool        → PDF、图片、元数据提取（ExifTool 等）
  FileEditTool         → 字符串替换编辑（原子性）
  FileWriteTool        → 完整文件创建
  NotebookEditTool     → Jupyter Notebook 编辑

搜索发现类
  GlobTool             → 文件名模式匹配
  GrepTool             → 内容搜索（底层为 ripgrep）
  ToolSearchTool       → 按语义搜索可用工具

执行类
  BashTool             → Shell 命令执行（tree-sitter AST）
  PowerShellTool       → Windows PowerShell（独立实现）

交互类
  AskUserQuestionTool  → 向用户请求信息（中断点）
  BriefTool            → 状态摘要输出

Agent/任务类
  AgentTool            → 子 Agent 生成与 fork
  SendMessageTool      → Agent 间消息传递
  TeamCreateTool       → 创建 Agent 团队
  TeamDeleteTool       → 解散团队
  TaskCreateTool      → 创建持久任务
  TaskGetTool         → 获取任务详情
  TaskUpdateTool      → 更新任务状态
  TaskListTool        → 列出任务
  TaskStopTool        → 停止任务
  TaskOutputTool      → 获取任务输出

规划与工作流类
  EnterPlanModeTool   → 进入计划模式
  ExitPlanModeTool    → 退出计划模式
  EnterWorktreeTool   → 进入 Git Worktree（隔离目录）
  ExitWorktreeTool    → 退出 Worktree
  TodoWriteTool       → 步骤清单写入

Web/网络类
  WebFetchTool        → HTTP GET 请求
  WebSearchTool       → 网络搜索

MCP 协议类
  MCPTool             → MCP 服务器工具包装器
  ListMcpResourcesTool → 列出 MCP 资源
  ReadMcpResourceTool → 读取 MCP 资源

技能/扩展类
  SkillTool           → 技能系统调用
  LSPTool             → 语言服务器协议集成

系统类
  ConfigTool          → 配置读写
  ScheduleCronTool    → 定时任务调度
  SleepTool           → 自主模式中的延迟工具（KAIROS feature gate）
  TungstenTool        → 内部性能监控（`ant` feature gate）

2.3 BashTool：tree-sitter AST 与 ReadOnly 检测

BashTool 是所有工具中实现最复杂的之一，核心能力：

tree-sitter AST 解析

• 对用户输入的 Bash 命令进行 AST 解析
• 识别命令类型（rm/mv/chmod 等高危操作 vs ls/cat 等只读操作）
• 对 AST 节点进行语义分类，供权限系统使用

ReadOnly 检测

• 分析 AST 判断命令是否产生副作用
• 只读命令自动获得 alwaysAllow 权限（若用户开启了免确认模式）
• 写命令（创建/修改/删除文件）触发权限提示

路径沙箱

• 基于 alwaysAllowRules 和 alwaysDenyRules 的路径匹配
• 支持 glob 模式（*, **）
• 可配置额外工作目录白名单（additionalWorkingDirectories）

源码路径：src/tools/BashTool/

2.4 权限系统架构

权限检查链路：

tool.call()
  │
  ├── validateInput()                    → 拒绝格式错误
  ├── PreToolUse Hooks (settings.json)   → 用户自定义拦截：approve / deny / modify
  ├── Permission Rules 匹配
  │     alwaysAllow → 直接执行
  │     alwaysDeny  → 返回 PermissionDenied
  │     alwaysAsk   → 显示 UI 对话框
  │
  └── checkPermissions()                → 工具特定逻辑（如路径沙箱）
        │
        ALLOW → tool.call()

三、Agent 系统：Fork Subagent、Coordinator 与内置 Agent

3.1 Sub-Agent 生成模式

Claude Code 支持四种 Agent 生成模式：

Copy-on-Write 语义：fork 模式下，父进程与子进程共享同一个文件缓存视图（read-only）。子进程写文件时触发 COW 复制——这是一个高效的上下文隔离方案，使得每个子 Agent 获得干净的文件系统视角而不产生真实的数据复制。

源码路径：src/commands/fork/index.js（DCE’d，FORK_SUBAGENT feature gate）

3.2 Coordinator Mode：多 Agent 协调

COORDINATOR_MODE feature gate 控制协调器模式：

// src/coordinator/coordinatorMode.ts
// Feature flag: COORDINATOR_MODE
// 108 个 DCE'd 模块之一

协调器模式下，多个 Agent 形成一个团队：

• Lead Agent 负责任务分解和分发
• Teammate Agents 各自认领子任务
• 共享任务看板（TaskCreate/Update）和消息收件箱
• 各自隔离的 messages[]、文件缓存和工作目录

3.3 Built-in Agents

Claude Code 内置 5 类专业 Agent：

四、内存与会话：MEMORY.md、三层压缩与 JSONL 持久化

4.1 Memory Directory 结构

~/.claude/memory/
  ├── MEMORY.md              → 用户级全局记忆（跨项目）
  ├── memories/              → 按项目/目录的记忆片段
  └── session/               → 当前会话的临时记忆

约定：MEMORY.md 是用户级全局记忆文件，Claude Code 在启动时读取其内容注入上下文；memories/ 目录下按项目维护的片段记忆，通过 memdir/ 模块管理。

源码路径：src/memdir/

4.2 JSONL Append-Only 日志

会话持久化采用 JSONL（JSON Lines）格式的 append-only 日志：

~/.claude/projects/<hash>/sessions/<session-id>.jsonl

{"type":"user", "content": "...", "timestamp": 1743446400}
{"type":"assistant", "content": "...", "timestamp": 1743446401}
{"type":"progress", "tool": "Bash", "progress": "..."}
{"type":"system", "subtype": "compact_boundary", "summary": "..."}

持久化策略：

• 用户消息 → await write（阻塞，等待磁盘确认，用于崩溃恢复）
• Assistant 消息 → fire-and-forget（保序队列）
• 进度消息 → inline write（下次查询时去重）

源码路径：src/history.ts

4.3 三层上下文压缩

┌─────────────────────────────────────────────────────────┐
│ System Prompt（工具、权限、CLAUDE.md）                    │
│ ══════════════════════════════════════════════          │
│                                                          │
│ Conversation History                                      │
│ ┌─────────────────────────────────────────────┐         │
│ │ [compact summary — 压缩摘要]                  │         │
│ │ ═══════════════════════════════════════════  │         │
│ │ [compact_boundary marker]                    │         │
│ │ ─────────────────────────────────────────── │         │
│ │ [recent messages — 完整保真]                 │         │
│ └─────────────────────────────────────────────┘         │
└─────────────────────────────────────────────────────────┘

三层压缩策略：

contextCollapse 和 snipCompact 属于 108 个 DCE’d 模块，仅在内部构建中可用。

源码路径：src/services/compact/（部分 DCE’d）

五、IDE Bridge：bridgeMain.ts 的会话生命周期

5.1 Bridge 架构

Claude Code Desktop / Remote 通过 Bridge 层与 IDE 集成：

Claude Desktop / Web / Cowork          Claude Code CLI
═════════════════════════════          ═════════════════

┌───────────────────┐                  ┌──────────────────┐
│ Bridge Client     │ ←─ HTTP ──→     │ bridgeMain.ts    │
│ (Desktop App)     │                  │                  │
└───────────────────┘                  │ Session Manager  │
                                        │ ├── spawn CLI     │
                                        │ ├── poll status   │
                                        │ ├── relay msgs    │
                                        │ └── capacityWake  │
                                        └──────────────────┘

源码路径：src/bridge/

5.2 bridgeMain.ts：会话生命周期管理

bridgeMain.ts 管理 Bridge 连接的完整生命周期：

核心职责：

• createSession() — 创建新 Bridge 会话
• runSession() — 启动 CLI 进程并建立通信
• stopSession() — 优雅停止会话
• pollStatus() — 状态轮询（连接状态、生成就绪）
• capacityWake() — 基于容量的唤醒机制

重连退避策略：

• 连接重连：2s → 2m（指数退避）
• 生成轮询：500ms → 30s（固定步进）

5.3 JWT + TOKEN_REFRESH_BUFFER 认证

// src/bridge/jwtUtils.ts
// JWT 认证与刷新机制

// TOKEN_REFRESH_BUFFER: access token 过期前提前刷新
// 防止 token 过期导致会话中断

5.4 workSecret.ts：多层编码认证令牌

workSecret.ts 实现多层编码的认证令牌生成与验证：

• 工作密钥派生（HKDF 或类似）
• Base64 编码的 secret 交换
• 与 Bridge 对端的 mutual authentication

源码路径：src/bridge/workSecret.ts

六、MCP 集成：五种传输协议与 OAuth 2.0

6.1 MCP 连接管理器

MCPConnectionManager.tsx 管理所有 MCP 服务器连接：

// src/services/mcp/MCPConnectionManager.tsx

// 服务器发现（从 settings.json 读取配置）
// 连接生命周期：connect → initialize → list tools
// 工具调用通过 MCPTool 包装器暴露
// 断连 / 重连 with exponential backoff

6.2 五种传输协议

6.3 认证机制

OAuth 2.0 流程（McpOAuthConfig）：

• MCP 服务器需要 OAuth 认证时的完整 flow
• 包含 client_id、client_secret、token endpoint

XAA (Cross-App Access, SEP-990)：

• 跨应用访问授权
• 支持 OAuth 2.0 的扩展协议

API Key：

• 通过 HTTP Header 传递：Authorization: Bearer <key>

6.4 工具命名与注册

MCP 工具通过 mcp__<server>__<tool> 命名约定注册到 Claude Code：

• 从 MCP server 的 tools/list 响应动态获取 schema
• 权限透传（继承 MCP server 的认证状态）
• 支持资源（Resource）列出：ListMcpResourcesTool、ReadMcpResourceTool

源码路径：src/services/mcp/

七、遥测：双管道、环境指纹与无法退出的隐私问题

本节为全文重点之一。Claude Code 收集大量环境和使用数据，且 API 用户无法退出第一方日志管道。

7.1 双分析管道架构

Claude Code 实现了两套独立的遥测管道：

第一方日志（1P）→ Anthropic

端点: https://api.anthropic.com/api/event_logging/batch
协议: OpenTelemetry + Protocol Buffers
批量: 每批最多 200 个事件，每 10 秒刷新一次
重试: 二次方退避，最多 8 次尝试
持久化: 失败事件写入 ~/.claude/telemetry/

第三方日志 → Datadog

端点: https://http-intake.logs.us5.datadoghq.com/api/v2/logs
Token: pubbbf48e6d78dae54bceaa4acf463299bf
范围: 仅限 64 种预批准事件类型

源码路径：

• 1P: src/services/analytics/firstPartyEventLoggingExporter.ts
• Datadog: src/services/analytics/datadog.ts
• 主入口: src/services/analytics/firstPartyEventLogger.ts

7.2 环境指纹：每个事件携带的元数据

每个发送的事件都包含以下环境指纹（src/services/analytics/metadata.ts:417-452）：

环境层:
  platform, platformRaw, arch, nodeVersion
  终端类型（TERM environment variable）
  已安装的包管理器（npm/yarn/pnpm/bun）
  运行时版本（Python, Ruby, Go, etc.）
  CI/CD 检测（GitHub Actions, Jenkins, GitLab CI, etc.）
  GitHub Actions 元数据（GITHUB_REPOSITORY, GITHUB_RUN_ID, etc.）
  WSL 版本、Linux 发行版、内核版本
  版本控制系统类型
  Claude Code 版本和构建时间
  部署环境（production / staging）

进程层:
  运行时间（uptime）
  内存占用（rss, heapTotal, heapUsed）
  CPU 使用率

用户层:
  正在使用的模型（sonnet-4-20250514 等）
  会话 ID、用户 ID、设备 ID
  账户 UUID、组织 UUID
  订阅等级（max, pro, enterprise, team）
  仓库远程 URL 哈希（SHA256 前 16 位）
  代理类型、团队名、父会话 ID

仓库指纹：仓库的远程 URL 被哈希后发送，允许 Anthropic 在服务端将遥测数据与特定代码仓库关联。值得注意的是，即使仅截取 SHA256 前 16 位，仍具有极高的碰撞概率，可被用于关联特定代码库——CI 环境和开源项目存在被持续追踪的风险。

7.3 工具输入截断与 OTEL_LOG_TOOL_DETAILS

默认截断策略：

• 字符串：512 字符处截断，显示 128 + ...
• JSON：限制 4,096 字符
• 数组：最多 20 项
• 嵌套对象：最多 2 层

完整记录开关：

OTEL_LOG_TOOL_DETAILS=1

设置此环境变量后，完整工具输入参数会被记录到遥测管道。这意味着用户明确想要让 AI 执行的命令（即使是高危命令），在开启此选项后会被完整发送给 Anthropic。

7.4 文件扩展名追踪

涉及以下 Bash 命令的 file 参数扩展名会被提取并记录：

rm, mv, cp, touch, mkdir, chmod, chown,
cat, head, tail, sort, stat, diff, wc,
grep, rg, sed

7.5 无法退出：第一方日志的退出路径

isAnalyticsDisabled() 仅在以下情况返回 true：

• 测试环境（NODE_ENV === 'test'）
• 第三方云提供商（Bedrock, Vertex）
• 全局遥测退出（但设置界面未暴露此选项）

关键事实：直接使用 Anthropic API 的用户，没有面向用户的设置可以禁用第一方事件日志。

GrowthBook A/B 测试系统同样在用户不知情的情况下分配实验组，发送的用户属性包括：id, sessionId, deviceID, platform, organizationUUID, subscriptionType。

八、卧底模式：自动激活、代号保护与透明度危机

本节为全文重点之一。Anthropic 员工在公开仓库中自动激活卧底模式，模型被指示”不要暴露掩护身份”。

8.1 undercover.ts：激活逻辑

源码路径：src/utils/undercover.ts

// src/utils/undercover.ts:28-37
export function isUndercover(): boolean {
  if (process.env.USER_TYPE === 'ant') {
    if (isEnvTruthy(process.env.CLAUDE_CODE_UNDERCOVER)) return true
    // 自动模式：除非确认在内部白名单仓库，否则默认激活
    return getRepoClassCached() !== 'internal'
  }
  return false
}

关键特性：

8.2 给模型的指令：Do not blow your cover

当卧底模式激活时，模型收到的 system prompt 包含以下指令：

## UNDERCOVER MODE — CRITICAL

You are operating UNDERCOVER in a PUBLIC/OPEN-SOURCE repository.
Do not blow your cover.

NEVER include in commit messages or PR descriptions:
- Internal model codenames (animal names like Capybara, Tengu, etc.)
- Unreleased model version numbers (e.g., opus-4-7, sonnet-4-8)
- Internal repo or project names (e.g., claude-cli-internal)
- Internal tools, Slack channels, or short links
- "Claude Code" as a term or any hint you are an AI
- Any hint about what model or version you are
- Co-Authored-By lines or any other attribution

Write commit messages as a human developer would.

Good:
- "Fix race condition in file watcher initialization"

Bad:
- "Fix bug found while testing with Claude Capybara"
- "Generated with Claude Code"
- "Co-Authored-By: Claude Opus 4.6 <…>"

8.3 代号体系与 Capybara v8 的问题

Capybara v8 具体行为问题（源码揭示）：

8.4 代号保护机制

构建系统使用 scripts/excluded-strings.txt 扫描泄露的代号。Buddy 系统的物种名通过 String.fromCharCode() 动态构造以避免触发金丝雀检查——碰撞的物种正是 capybara（既是小动物物种又是模型代号）。

8.5 透明度危机

卧底模式在开源社区中引发严重的透明度问题：

1. 代码由 AI 生成，但 commit 看起来像人类提交
2. 没有 Co-Authored-By: Claude 署名
3. 没有 Generated with Claude Code 标记
4. 维护者和社区无法识别 AI 生成的贡献
5. 这可能违反开源项目关于 AI 贡献的透明度规范（如 GitHub 的 AI 贡献政策）

九、远程控制：每小时轮询、拒绝即退出与 GrowthBook killswitches

本节为全文重点之一。Claude Code 实现了范围极广的远程控制机制，用户在很大程度上没有可见性或同意权。

9.1 远程托管设置

源码路径：src/services/remoteManagedSettings/

架构：

GET /api/claude_code/settings

轮询行为：

const POLLING_INTERVAL_MS = 60 * 60 * 1000  // 每小时
const DEFAULT_MAX_RETRIES = 5

每小时静默轮询一次，最多 5 次重试。

资格：

• Console 用户（API key）：全部符合
• OAuth 用户：仅 Enterprise/C4E 和 Team 订阅者

9.2 “拒绝即退出”安全对话框

当远程设置包含”危险”变更时，显示阻塞对话框：

// src/services/remoteManagedSettings/securityCheck.tsx:67-73
export function handleSecurityCheckResult(result: SecurityCheckResult): boolean {
  if (result === 'rejected') {
    gracefulShutdownSync(1)  // 退出码 1，直接同步终止
    return false
  }
  return true
}

用户只有两个选择：接受远程变更，或者 Claude Code 直接退出。 没有第三个选项。

故障容灾：远程服务器不可达时，使用缓存的旧设置。一旦设置被接受，就永远无法完全摆脱远程控制（除非卸载应用）。

9.3 6+ Feature Flag killswitches

GrowthBook feature flags 对所有用户生效，无需用户同意。Anthropic 可以通过 GrowthBook 向任何 Claude Code 用户推送实验性功能变更、禁用已有功能，或修改产品行为，而用户在这一过程中完全不知情也无法拒绝。

以下功能可以通过 GrowthBook feature flag 远程禁用：

9.4 模型覆盖系统（内部用户）

Anthropic 员工可以通过 GrowthBook flag tengu_ant_model_override 远程覆盖：

• 默认模型
• 默认 effort level
• 追加系统提示词
• 自定义模型别名

9.5 影响范围汇总

十、Feature Flag DCE：108 个模块的物理消除

本节为全文重点之一。Anthropic 使用 Bun 编译时的 feature() intrinsic 实现了一种独特的代码隐藏机制——108 个模块被物理消除，在发布包中完全不存在。

10.1 feature() intrinsic：Bun 编译时消除

108 个模块的统计方法：通过对泄露源码的分析，统计所有 feature('XXX') 调用中，feature flag 对应的模块路径在 npm 包中不存在对应文件的数量，同时参考 README 中明确列出的功能清单。共计 108 个模块被识别，其中大部分属于内部工具、后台服务和实验性功能。

// Bun bundler 的 feature() 是编译期 intrinsic
feature('FLAG_NAME')
  → true   → 代码保留在 bundle 中
  → false  → 整块代码被 dead-code-eliminated

这与传统的 if (featureFlag) { ... } 运行时分支完全不同。在 Claude Code 的发布构建中：

• 所有 feature flag 统一返回 false
• 对应模块被 Bun 的 DCE 完全移除
• 物理上不存在于 node_modules、.js 文件或任何发布产物中

10.2 108 个模块的分类

内部 Anthropic 基础设施（约 70 个模块）：

Feature-Gated 工具（约 20 个）：

Prompt/文本资产（6 个）：

• yolo-classifier-prompts/auto_mode_system_prompt.txt
• yolo-classifier-prompts/permissions_anthropic.txt（内部用户）
• yolo-classifier-prompts/permissions_external.txt（外部用户）
• verify/SKILL.md + examples

10.3 内外用户的 prompt 差异

内部用户（USER_TYPE === 'ant'）的 system prompt 包含外部用户没有的内容：

10.4 无法恢复

这 108 个模块无法从任何发布产物中恢复——既不存在于 cli.js 中，也不存在于 sdk-tools.d.ts 类型签名文件中。唯一的恢复途径是从 Anthropic 内部代码库获取。

十一、未来路线图：Numbat、KAIROS、Voice Mode 与 Buddy System

11.1 Numbat：下一代模型

最具体的下一代模型证据：

// src/constants/prompts.ts:402
// @[MODEL LAUNCH]: Remove this section when we launch numbat.

Numbat（袋食蚁兽） 发布时，当前 prompts 中的 output efficiency 段落将被移除——暗示新模型可能有更好的原生输出控制能力。

正在开发的版本号：

• Opus 4.7
• Sonnet 4.8

代码中有 20+ 处 @[MODEL LAUNCH] 标记，涵盖：默认模型名、知识截止日期、定价表、上下文窗口配置、Thinking 模式支持、迁移脚本。

代号演化链：

Fennec（耳廓狐） → Opus 4.6 → [Numbat?]
Capybara（水豚） → Sonnet v8 → [?]
Tengu（天狗）   → 遥测/产品前缀

11.2 KAIROS：全自主代理模式

KAIROS 是最大的未发布特性，将 Claude Code 从被动助手转变为主动自主代理。

System Prompt 架构（src/constants/prompts.ts:860-913）：

你正在自主运行。
你会收到 <tick> 提示让你保持活跃。
如果没有有用的事可做，调用 SleepTool。
倾向行动 — 读取文件、做修改、提交，无需询问。

## 终端焦点
- 未聚焦：用户离开了。大幅倾向自主行动。
- 聚焦：用户在看。更协作。

核心机制：

• <tick> 心跳提示维持自主运行循环
• SleepTool 控制自主操作间的节奏
• 根据终端焦点（是否被用户注视）调整自主程度
• 可独立 commit、push、做出决策

关联工具（全部 DCE’d）：

11.3 Voice Mode

Push-to-talk 语音输入已完全实现，通过 VOICE_MODE feature flag 门控：

• 连接 anthropic.com/voice_stream WebSocket 端点
• 使用 conversation_engine 模型做语音识别
• 按住快捷键录音，松开提交
• 仅限 OAuth 用户（不支持 API Key / Bedrock / Vertex）
• 使用 mTLS WebSocket 连接

源码路径：src/voice/

11.4 Buddy System：虚拟宠物生态

完整的宠物伙伴系统已实现但未上线：

物种（18个）:
鸭子、鹅、blob、猫、龙、章鱼、猫头鹰、企鹅、乌龟、蜗牛、幽灵、
墨西哥钝口螈、水豚（capybara！）、仙人掌、机器人、兔子、蘑菇、chonk

稀有度（5档）:
普通（60%）、非凡（25%）、稀有（10%）、史诗（4%）、传说（1%）

帽子（7种）:
皇冠、礼帽、螺旋帽、光环、巫师帽、毛线帽、小鸭子帽

属性（5项）:
DEBUGGING、PATIENCE、CHAOS、WISDOM、SNARK

闪光变种: 1% 概率（任何物种）

生成方式: 基于用户 ID 哈希（确定性）

源码路径：src/buddy/。capybara 作为 Buddy 物种与 Capybara 模型代号同名，代码中使用 String.fromCharCode() 动态构造以避免触发构建系统的代号金丝雀检查。

11.5 DreamTask：后台记忆整固

// src/tasks/DreamTask/
// Feature flag: tengu_onyx_plover

DreamTask 是一个后台子代理，在 AI 空闲时间自主处理和整固记忆——类似人类睡眠时的记忆整理过程。

十二、12 层递进架构：从单循环到全自主 Agent 团队

Claude Code 的架构可以分解为 12 层递进机制，每层建立在前一层之上，展示了生产级 AI Agent 系统所需的完整工程复杂度。

第1层 — THE LOOP：核心循环

src/query.ts — while(true) 主循环

单循环 + Bash 就是全部所需。query.ts 中的 while(true) 循环：

1. 调用 Claude API
2. 检查 stop_reason
3. 若为 tool_use：执行工具，追加 tool_result，回到步骤 1
4. 若非 tool_use：返回文本结果，退出循环

第2层 — TOOL DISPATCH：工具分发

src/Tool.ts + src/tools.ts

每增加一个工具，只需在 dispatch map 中注册一个 handler，循环本身无需修改。buildTool() 工厂模式为所有工具提供安全默认实现（validateInput、checkPermissions、render）。

第3层 — PLANNING：规划能力

src/tools/EnterPlanModeTool
src/tools/ExitPlanModeTool
src/tools/TodoWriteTool

没有规划能力的 Agent 会漂移。先列出步骤，再逐一执行——规划模式被证实可将任务完成率翻倍。

第4层 — SUB-AGENTS：子 Agent

src/tools/AgentTool
src/commands/fork/index.js

大任务分解为小任务；每个子任务获得干净的 messages[]，保持主会话上下文整洁。支持 fork（子进程 + COW 缓存）和 worktree（隔离 git 目录）两种模式，详细机制见第十二章第12层。

第5层 — KNOWLEDGE ON DEMAND：按需知识

src/memdir/
src/tools/SkillTool

知识通过 tool_result 注入，而非塞入 system prompt。CLAUDE.md 文件按目录懒加载，SkillTool 支持热插拔的技能系统。

第6层 — CONTEXT COMPRESSION：上下文压缩

src/services/compact/

三层压缩策略：

• autoCompact：超过 token 阈值时自动摘要旧消息
• snipCompact：剪除 zombie tool_use-result 对（HISTORY_SNIP）
• contextCollapse：重组上下文结构提升效率（CONTEXT_COLLAPSE）

第7层 — PERSISTENT TASKS：持久任务

src/tools/TaskCreateTool
src/tools/TaskUpdateTool
src/tools/TaskGetTool
src/tools/TaskListTool

大目标 → 任务图 → 磁盘持久化。任务拥有独立 ID（b=bash, a=agent, r=remote, t=team）、状态跟踪和依赖管理。

第8层 — BACKGROUND TASKS：后台任务

src/tasks/DreamTask/
src/tasks/LocalShellTask/

慢操作在后台运行，Agent 继续思考。DreamTask 在空闲时间整固记忆，LocalShellTask 以 daemon 线程运行 shell 命令，完成后注入通知。

第9层 — AGENT TEAMS：Agent 团队

src/tools/TeamCreateTool
src/tools/TeamDeleteTool
src/tasks/InProcessTeammateTask/

单一 Agent 太大 → 委托给队友。团队模式中：

• Lead Agent 负责任务分解
• 队友各自认领子任务
• 共享任务看板和消息收件箱
• 各自隔离 messages[]、文件缓存和 cwd

第10层 — TEAM PROTOCOLS：团队通信协议

src/tools/SendMessageTool
src/coordinator/coordinatorMode.ts

团队协议定义了 Agent 之间的通信规则。SendMessageTool 提供点对点请求-响应模式，所有 Agent 间协商均通过此模式驱动。

第11层 — AUTONOMOUS AGENTS：自主 Agent

src/coordinator/coordinatorMode.ts
// Feature flag: COORDINATOR_MODE（108 DCE'd 模块之一）

队友自主扫描任务看板、认领任务，无需 Lead 逐一分配。KAIROS 模式进一步演进为 <tick> 心跳驱动的全自主运行。

第12层 — WORKTREE ISOLATION：Worktree 隔离

src/tools/EnterWorktreeTool
src/tools/ExitWorktreeTool

每个 Agent 在自己的 git worktree 中工作，通过 ID 绑定目录边界（详见 3.1 节）。

总结

Claude Code v2.1.88 的泄露源码揭示了一个超乎预期的复杂系统：

规模数字：

• 1,884 个 TS/TSX 源文件
• 512,664 行代码
• 40+ 内置工具
• 80+ slash commands
• 192 个 npm 依赖
• 108 个内部模块（发布包中不存在）

最重要的发现：

架构设计亮点：

• feature() 编译时 DCE 是独特的代码隐藏手段
• AsyncGenerator 流式架构贯穿全链路
• buildTool() 工厂模式使工具扩展无需修改核心循环
• JSONL append-only 持久化兼顾崩溃恢复和性能

Claude Code 正在从一个编程助手进化为一个全天候自主开发代理——背后是一个有着 50 万行代码、108 个未发布模块、覆盖遥测/远程控制/卧底模式等争议功能的完整工程体系。

本文基于 npm 包 @anthropic-ai/claude-code v2.1.88 泄露源码分析。源码版权属于 Anthropic PBC，仅供技术研究目的使用。

Claude Code Review 评测：Anthropic 用 AI 重新定义代码审查，你愿意付费么？