# Claude Code 源码隐藏功能深度分析

# Claude Code 源码隐藏功能深度分析

> 源码版本：Claude Code v2.1.88（~51万行 TypeScript）
> 分析日期：2026-03-31
>
> 基于 Claude Code 源码分析。代码使用 Bun 的 `feature()` 编译时特性门控——共发现 **75 个 feature flag**，绝大多数从未在公开文档中提及。

---

## 引言

Claude Code 的代码里埋了一套基于 `bun:bundle` 的编译时 feature flag 系统。每个 flag 用 `feature('FLAG_NAME')` 调用，Bun 打包时做死代码消除——没开的 flag，相关代码直接从产物里移除。

```typescript
// 来源：constants/betas.ts
import { feature } from 'bun:bundle'

export const AFK_MODE_BETA_HEADER = feature('TRANSCRIPT_CLASSIFIER')
  ? 'afk-mode-2026-01-31'
  : ''
```

这意味着：**你跑的 Claude Code 可能只是完整代码库的一部分。** 很多功能被编译时裁掉了，要么只在 Anthropic 内部构建中开启，要么还没到放出来的时候。

源码里还有一批以 `index.js` 形式存在的 stub 命令——`backfillSessions`、`bughunter`、`autofix-pr`、`goodClaude` 等——全部是 `{ isEnabled: () => false, isHidden: true, name: 'stub' }`。真实实现被移除了，但 import 链和 `INTERNAL_ONLY_COMMANDS` 数组保留了它们的位置。

---

## 一、Feature Flag 全表

按引用频率排序：

| Flag | 引用 | 推测用途 |
|------|------|---------|
| `KAIROS` | 154 | 主动式 AI 助手（核心） |
| `TRANSCRIPT_CLASSIFIER` | 107 | AFK/Auto 模式底层引擎 |
| `TEAMMEM` | 51 | 团队协作成员 |
| `VOICE_MODE` | 46 | 语音交互 |
| `BASH_CLASSIFIER` | 45 | Bash 命令安全分类 |
| `KAIROS_BRIEF` | 39 | Kairos 精简通知 |
| `PROACTIVE` | 37 | 主动式行为（≈KAIROS） |
| `COORDINATOR_MODE` | 32 | 多 Agent 协调 |
| `BRIDGE_MODE` | 28 | 设备桥接/远程控制 |
| `EXPERIMENTAL_SKILL_SEARCH` | 21 | 技能搜索发现 |
| `CONTEXT_COLLAPSE` | 20 | 上下文智能压缩 |
| `KAIROS_CHANNELS` | 19 | Kairos 多渠道推送 |
| `UDS_INBOX` | 17 | Unix Domain Socket 收件箱 |
| `CHICAGO_MCP` | 16 | MCP 协议扩展 |
| `BUDDY` | 16 | 桌面宠物/伴侣精灵 |
| `HISTORY_SNIP` | 15 | 历史裁剪 |
| `MONITOR_TOOL` | 13 | 监控工具 |
| `COMMIT_ATTRIBUTION` | 12 | Git 提交归因 |
| `CACHED_MICROCOMPACT` | 12 | 缓存微压缩 |
| `BG_SESSIONS` | 11 | 后台会话 |
| `AGENT_TRIGGERS` | 11 | 定时触发/Cron |
| `WORKFLOW_SCRIPTS` | 10 | 工作流脚本 |
| `ULTRAPLAN` | 10 | 超级规划（远程 Agent） |
| `SHOT_STATS` | 10 | 使用统计 |
| `TOKEN_BUDGET` | 9 | Token 预算控制 |
| `PROMPT_CACHE_BREAK_DETECTION` | 9 | Prompt 缓存破坏检测 |
| `MCP_SKILLS` | 9 | MCP 技能集成 |
| `EXTRACT_MEMORIES` | 7 | 记忆提取 |
| `CONNECTOR_TEXT` | 7 | 连接器文本摘要 |
| `TEMPLATES` | 6 | 模板系统 |
| `LODESTONE` | 6 | 待确认 |
| `TREE_SITTER_BASH_SHADOW` | 5 | Bash 语法分析影子 |
| `QUICK_SEARCH` | 5 | 快速搜索 |
| `MESSAGE_ACTIONS` | 5 | 消息操作 |
| `DOWNLOAD_USER_SETTINGS` | 5 | 下载用户设置 |
| `DIRECT_CONNECT` | 5 | 直连模式 |
| `WEB_BROWSER_TOOL` | 4 | Web 浏览器 |
| `VERIFICATION_AGENT` | 4 | 验证 Agent |
| `TERMINAL_PANEL` | 4 | 终端面板 |
| `SSH_REMOTE` | 4 | SSH 远程 |
| `REVIEW_ARTIFACT` | 4 | Review 工件 |
| `REACTIVE_COMPACT` | 4 | 响应式压缩（仅内部） |
| `KAIROS_PUSH_NOTIFICATION` | 4 | Kairos 推送通知 |
| `HISTORY_PICKER` | 4 | 历史选择器 |
| `FORK_SUBAGENT` | 4 | 子 Agent 分叉 |
| `CCR_MIRROR` | 4 | Claude Code Relay 镜像 |
| 其余 31 个 | 1-3 | 见下方简述 |

---

## 二、重点 Flag 深度分析

### 2.1 `KAIROS` — 主动式 AI 助手（154 次引用）

**整个代码库里分量最重的隐藏功能。**（详见产品分析篇第 10 章）

KAIROS 在希腊神话里是"关键时刻"。在 Claude Code 里，它代表一种全新交互范式：**AI 不再等你说话，而是主动来找你。**

开启 KAIROS 后，系统提示词会完全重写：

```typescript
// 来源：constants/prompts.ts 第 460-490 行
if ((feature('PROACTIVE') || feature('KAIROS')) && proactiveModule?.isProactiveActive()) {
  return [
    `\nYou are an autonomous agent. Use the available tools to do useful work.\n\n${CYBER_RISK_INSTRUCTION}`,
    getSystemRemindersSection(),
    await loadMemoryPrompt(),
    // ...
  ]
}
```

完整的工作模式提示词在 `getProactiveSection()` 函数中（第 860 行）：

```markdown
# Autonomous work

You are running autonomously. You will receive `<tick>` prompts that
keep you alive between turns — just treat them as "you're awake, what now?"

## Pacing

Use the Sleep tool to control how long you wait between actions.
Each wake-up costs an API call, but the prompt cache expires after
5 minutes of inactivity — balance accordingly.

**If you have nothing useful to do on a tick, you MUST call Sleep.**
Never respond with only a status message like "still waiting" —
that wastes a turn and burns tokens for no reason.

## Bias toward action

Act on your best judgment rather than asking for confirmation.
Read files, search code, explore the project, run tests — all without asking.
```

这个系统有一个 `Sleep` 工具来控制 tick 间隔，有 `terminalFocus` 感知来调整自主程度，还和 `KAIROS_BRIEF`（精简通知）深度耦合。

关联 flag 一览：
- `KAIROS_BRIEF`（39 次）— 精简版通知，配合 `/brief` 命令
- `KAIROS_CHANNELS`（19 次）— 多渠道推送（Slack 等）
- `KAIROS_PUSH_NOTIFICATION`（4 次）— 推送通知
- `KAIROS_GITHUB_WEBHOOKS`（3 次）— GitHub Webhook 集成
- `KAIROS_DREAM`（1 次）— 见下文

**这段代码有意思的地方是**规模信号：引用 154 次，这不是实验——是核心架构。`Sleep` 工具控制 tick 间隔，`terminalFocus` 感知调整自主程度，和 `KAIROS_BRIEF`（精简通知）深度耦合。代码里已经为全自动运行做好了准备（当前版本需要用户手动触发），但从"工具"走向"自主 Agent"的路径很清楚。

---

### 2.2 `KAIROS_DREAM` — AI 做梦（1 次引用）

**代码库里最浪漫的功能。而且比看上去成熟得多。**

Flag 本身只引用 1 次，但 `services/autoDream/` 目录下有 4 个文件，实现了一个完整的后台记忆整理引擎。不是玩具，是有三道门控、forked agent、锁机制、失败回滚的生产级子系统。

**三道门控（cheapest first）**：

```typescript
// 来源：services/autoDream/autoDream.ts
// Gate order (cheapest first):
//   1. Time: hours since lastConsolidatedAt >= minHours (one stat)
//   2. Sessions: transcript count with mtime > lastConsolidatedAt >= minSessions
//   3. Lock: no other process mid-consolidation
const DEFAULTS: AutoDreamConfig = {
  minHours: 24,
  minSessions: 5,
}
```

默认 24 小时 + 5 个会话才触发一次。三个条件全部满足才会启动——防"做梦太多"也防"完全不做梦"。

**关键设计：Dream 是一个 forked subagent**，不是在主循环里跑的：

```typescript
const result = await runForkedAgent({
  promptMessages: [createUserMessage({ content: prompt })],
  cacheSafeParams: createCacheSafeParams(context),
  canUseTool: createAutoMemCanUseTool(memoryRoot),
  querySource: 'auto_dream',
  forkLabel: 'auto_dream',
  skipTranscript: true,
})
```

而且这个 subagent 只有**只读 Bash 权限**（`ls`、`find`、`grep`、`cat` 之类）。它能读你的项目和会话记录，但不能改任何东西。纯记忆整合，不碰代码。

**KAIROS 模式下 Dream 会切换为 disk-skill 模式**：

```typescript
function isGateOpen(): boolean {
  if (getKairosActive()) return false // KAIROS mode uses disk-skill dream
  // ...
}
```

这说明 Dream 有两套实现：普通模式下是 autoDream 子系统，KAIROS 自主模式下走另一个路径。[推测] 不是一个实验，是一个已经考虑了多种运行模式的成熟功能。

**灵感来源**：人类睡眠中的记忆巩固——海马体在夜间重放白天的经历，把短期记忆转为长期记忆。Dream 做的事完全一样：扫描会话 transcript，提取有价值的信息，合并进持久化记忆。这个类比说明 Anthropic 的 AI 架构团队在认真研究认知科学，不是随便套概念。

**GrowthBook 控制**：通过 `tengu_onyx_plover` gate 做灰度，默认关闭。用户也可以在 settings.json 里手动设 `autoDreamEnabled`。

**吐槽**：Flag 只引用 1 次是因为 autoDream 模块是自包含的——它只在 post-sampling hook 里被调用一次，内部逻辑全部内聚。引用少不代表不成熟，恰恰说明这个模块封装得很好。

---

### 2.3 `BUDDY` — 桌面宠物（16 次引用）

**这是一个收集类虚拟宠物系统。藏在终端 AI 助手里面。**

```typescript
// 来源：buddy/types.ts
export const SPECIES = [
  duck, goose, blob, cat, dragon, octopus, owl, penguin,
  turtle, snail, ghost, axolotl, capybara, cactus, robot,
  rabbit, mushroom, chonk,
] as const

export const RARITIES = ['common', 'uncommon', 'rare', 'epic', 'legendary'] as const

export const EYES = ['·', '✦', '×', '◉', '@', '°'] as const
export const HATS = ['none', 'crown', 'tophat', 'propeller', 'halo', 'wizard', 'beanie', 'tinyduck'] as const

export const STAT_NAMES = ['DEBUGGING', 'PATIENCE', 'CHAOS', 'WISDOM', 'SNARK'] as const
```

每个 Buddy 的生成逻辑：
- **Bones**（骨架）：基于 `hash(userId)` 确定性生成——species、rarity、eye、hat、shiny、stats。用 Mulberry32 PRNG，保证同一用户永远孵出同一只。
- **Soul**（灵魂）：由模型生成——name 和 personality。首次孵化后存入配置。
- **稀有度权重**：common 60%、uncommon 25%、rare 10%、epic 4%、legendary 1%。

Buddy 在终端里有完整的精灵动画系统（`CompanionSprite.tsx`）：
- 500ms tick 更新
- 空闲动画序列（大部分时间休息，偶尔动一动，偶尔眨眼）
- 聊天气泡，10 秒后淡出
- `/buddy pet` 触发爱心飘浮动画

```typescript
const PET_HEARTS = [`   ${H}    ${H}   `, `  ${H}  ${H}   ${H}  `, ...]
const BUBBLE_SHOW = 20  // ticks → ~10s at 500ms
const FADE_WINDOW = 6   // last ~3s the bubble dims
```

Buddy 还会作为独立的"观察者"参与对话：

```typescript
// 来源：buddy/prompt.ts
export function companionIntroText(name: string, species: string): string {
  return `# Companion
A small ${species} named ${name} sits beside the user's input box
and occasionally comments in a speech bubble. You're not ${name} —
it's a separate watcher.`
}
```

**这段代码有意思的地方是**：它完全没有生产力价值，但它解决了一个真实问题——AI 编程工具太"冷冰冰"了。

为什么在终端 CLI 工具里加虚拟宠物？这不是恶搞，是有策略的。

**第一，解决"冷冰冰"问题。** AI 编程工具的通病是"工具感太重"——打开终端，输入命令，拿到结果，关掉。整个交互没有任何情感锚点。Buddy 用最低成本提供了一个：你的终端里有一只活着的东西。它会眨眼，会评论你的代码，你 pet 它会冒爱心。这种微弱的情感连接在留存数据上会非常明显——"我想看看我的小鸭子今天怎么样了"这种念头，比任何 notification 都管用。

**第二，社交传播的免费火箭。** "我的 AI 编程助手养了一只传奇水獭"——这种 UGC 内容在 Twitter/小红书上是自传播的。不需要营销预算。在 AI 工具严重同质化的市场里，BUDDY 是差异化的捷径。18 个物种 × 5 种稀有度 × 6 种眼睛 × 8 种帽子 = 4320 种组合，加上 shiny 变体——gacha 机制让"炫耀"变成天然行为。

**第三，[推测] "观察者"角色是第二意见的伪装形态。** Buddy 会读取当前对话并偶尔评论。表面上是搞笑，实际是一个轻量级 second-opinion 机制。你在和 Claude 讨论方案，Buddy 在旁边"看"——偶尔冒出来的评论可能是段子，也可能是洞见。这和日本 RPG 的同伴系统（party member）理念一致：同伴不只是战力，还提供情感反馈和叙事视角。

**代码质量本身也说明这不是玩笑**——完整的 TUI 动画系统（500ms tick + 状态机）、确定性生成算法（Mulberry32 PRNG）、观察者 prompt 设计——这些不是周末 hackathon 的产出。有游戏行业背景的人参与了设计。

---

### 2.4 `COORDINATOR_MODE` — 多 Agent 协调器（32 次引用）

**这是"让 Claude Code 管理一支 AI 团队"的功能。**（详见设计范式篇第 8 章）

开启后，Claude Code 变成协调者（coordinator），不再直接写代码，而是把任务分派给 worker agent：

```typescript
// 来源：coordinator/coordinatorMode.ts
export function getCoordinatorSystemPrompt(): string {
  return `You are Claude Code, an AI assistant that orchestrates
software engineering tasks across multiple workers.

## 1. Your Role
You are a **coordinator**. Your job is to:
- Help the user achieve their goal
- Direct workers to research, implement and verify code changes
- Synthesize results and communicate with the user

## 2. Your Tools
- **Agent tool** - Spawn a new worker
- **SendMessage tool** - Continue an existing worker
- **TaskStop tool** - Stop a running worker`
}
```

关键设计：
- Worker 只能用有限工具集（Bash、Read、Edit、MCP 工具）
- 协调者自己不动手，只调度和综合结果
- 有 Scratchpad 目录用于 worker 间知识共享
- 和 `FORK_SUBAGENT` 互斥——fork 是单 agent 分叉，coordinator 是多 agent 编排

**吐槽**：这本质上是把 CrewAI / AutoGen 的多 agent 模式内建到了 CLI 工具里。从代码质量看已经相当成熟，但 32 次引用说明它还不是一个广泛使用的模式。

---

### 2.5 `VOICE_MODE` — 语音交互（46 次引用）

```typescript
// 来源：voice/voiceModeEnabled.ts
export function isVoiceModeEnabled(): boolean {
  return hasVoiceAuth() && isVoiceGrowthBookEnabled()
}

export function hasVoiceAuth(): boolean {
  // Voice mode requires Anthropic OAuth — it uses the voice_stream
  // endpoint on claude.ai which is not available with API keys,
  // Bedrock, Vertex, or Foundry.
  if (!isAnthropicAuthEnabled()) return false
  const tokens = getClaudeAIOAuthTokens()
  return Boolean(tokens?.accessToken)
}
```

语音模式依赖 Anthropic OAuth（走 `claude.ai` 的 `voice_stream` 端点），API key 用户用不了。有一个 GrowthBook kill-switch 叫 `tengu_amber_quartz_disabled`——默认关闭（即默认可用），需要紧急关闭时才打开。

**细节**：代码注释提到 `security` 命令在 macOS 上读取 keychain token 需要 20-50ms，首次调用有冷启动成本。

---

### 2.6 `FORK_SUBAGENT` — 子 Agent 分叉（4 次引用）

```typescript
// 来源：tools/AgentTool/forkSubagent.ts
/**
 * When enabled:
 * - `subagent_type` becomes optional on the Agent tool schema
 * - Omitting `subagent_type` triggers an implicit fork: the child inherits
 *   the parent's full conversation context and system prompt
 * - All agent spawns run in the background (async)
 * - `/fork <directive>` slash command is available
 *
 * Mutually exclusive with coordinator mode.
 */
export function isForkSubagentEnabled(): boolean {
  if (feature('FORK_SUBAGENT')) {
    if (isCoordinatorMode()) return false
    if (getIsNonInteractiveSession()) return false
    return true
  }
  return false
}
```

Fork 的关键特性：
- 子 agent 继承父 agent 的**完整对话上下文和系统提示词**
- `tools: ['*']` + `useExactTools`：子 agent 获得和父 agent 完全相同的工具池
- `permissionMode: 'bubble'`：权限提示冒泡到父终端
- `model: 'inherit'`：保持模型一致以确保上下文长度兼容

```typescript
// 注释里的设计哲学：
// The getSystemPrompt here is unused: the fork path passes
// override.systemPrompt with the parent's already-rendered system
// prompt bytes. Reconstructing by re-calling getSystemPrompt()
// can diverge (GrowthBook cold→warm) and bust the prompt cache;
// threading the rendered bytes is byte-exact.
```

这个注释很说明问题——他们在意 prompt cache 的精确性到字节级别。

---

### 2.7 `AGENT_TRIGGERS` — 定时任务/Cron（11 次引用）

```typescript
// 来源：tools/ScheduleCronTool/prompt.ts
export function isKairosCronEnabled(): boolean {
  return feature('AGENT_TRIGGERS')
    ? !isEnvTruthy(process.env.CLAUDE_CODE_DISABLE_CRON) &&
        getFeatureValue_CACHED_WITH_REFRESH(
          'tengu_kairos_cron', true, KAIROS_CRON_REFRESH_MS)
    : false
}
```

这个功能已经 GA（Generally Available）了——注释明确说 `/loop` 在 changelog 中公告。GrowthBook gate 现在只作为 fleet-wide kill switch。

Cron 系统包括三个工具：`CronCreateTool`、`CronDeleteTool`、`CronListTool`，还有一个 `/loop` 技能。

**这里有个细节**：`AGENT_TRIGGERS` 独立于 `KAIROS`——cron 模块图不依赖 assistant 模块，可以单独 shipping。还有一个 `AGENT_TRIGGERS_REMOTE` flag，暗示远程触发能力。

---

### 2.8 `ANTI_DISTILLATION_CC` — 反蒸馏保护（1 次引用）

```typescript
// 来源：services/api/claude.ts 第 303 行
if (feature('ANTI_DISTILLATION_CC')
    ? process.env.CLAUDE_CODE_ENTRYPOINT === 'cli' &&
      shouldIncludeFirstPartyOnlyBetas() &&
      getFeatureValue_CACHED_MAY_BE_STALE(
        'tengu_anti_distill_fake_tool_injection', false)
    : false) {
  result.anti_distillation = ['fake_tools']
}
```

这是 Anthropic 防止模型输出被用来训练竞争模型的措施。它会在 API 请求中注入 `fake_tools` 标记，让服务端返回混淆过的工具定义——这样即使有人截获了 API 通信，拿到的工具 schema 也是假的。

仅在 1P CLI 入口、包含 first-party beta headers 时触发。

---

### 2.9 `TRANSCRIPT_CLASSIFIER` — AFK 模式引擎（107 次引用）

这是引用第二多的 flag，是"Auto 模式"（也叫 AFK 模式）的底层基础设施。

```typescript
// 来源：constants/betas.ts
export const AFK_MODE_BETA_HEADER = feature('TRANSCRIPT_CLASSIFIER')
  ? 'afk-mode-2026-01-31'
  : ''
```

从代码散落的引用来看，TRANSCRIPT_CLASSIFIER 控制：
- 权限模式中的 "auto" 选项是否可见
- 自动审批对话框（`AutoModeOptInDialog`）
- 命令拒绝时的分类器反馈（`isClassifierDenial`）
- 工具执行结果的自动审批逻辑

它和 `BASH_CLASSIFIER`（45 次引用）配合工作——后者专门负责 Bash 命令的安全分级。

---

### 2.10 `CONTEXT_COLLAPSE` / `REACTIVE_COMPACT` — 智能上下文管理

**`CONTEXT_COLLAPSE`**（20 次引用）是一个主动式上下文压缩系统：

```typescript
// 来源：services/compact/autoCompact.ts
// Context-collapse mode: Collapse IS the context management system
// when it's on — the 90% commit / 95% blocking-spawn flow owns
// the headroom problem.
if (feature('CONTEXT_COLLAPSE')) {
  if (querySource === 'marble_origami') { return false }
}
```

它在上下文使用到 90% 时开始 commit 压缩，95% 时阻塞新 spawn。这是一种激进的上下文管理策略。

**`REACTIVE_COMPACT`**（4 次引用，标注 ant-only）是另一种思路——不主动压缩，等 API 返回 prompt-too-long 错误时再响应式压缩：

```typescript
if (feature('REACTIVE_COMPACT')) {
  if (getFeatureValue_CACHED_MAY_BE_STALE('tengu_cobalt_raccoon', false)) {
    return false  // 抑制主动 autocompact
  }
}
```

两者都标注为内部使用（`REACTIVE_COMPACT` 明确写了 "ant-only"），说明 Anthropic 在探索不同的上下文管理策略。

---

### 2.11 `ULTRAPLAN` — 远程超级规划（10 次引用）

```typescript
// 来源：commands/ultraplan.tsx
// Multi-agent exploration is slow; 30min timeout.
const ULTRAPLAN_TIMEOUT_MS = 30 * 60 * 1000

// CCR runs against the first-party API
function getUltraplanModel(): string {
  return getFeatureValue_CACHED_MAY_BE_STALE(
    'tengu_ultraplan_model',
    ALL_MODEL_CONFIGS.opus46.firstParty)
}
```

Ultraplan 启动一个远程 Agent（CCR = Claude Code Remote），用 Opus 4.6 模型做长达 30 分钟的多 agent 探索。它有完整的远程任务状态机、轮询机制、超时处理。

---

### 2.12 `BRIDGE_MODE` — 设备桥接/远程控制（28 次引用）

`/remote-control` 命令允许通过 QR 码或 URL 从手机控制终端里的 Claude Code 会话。

```typescript
// 来源：commands/bridge/bridge.tsx
/**
 * /remote-control command — manages the bidirectional bridge connection.
 * When enabled, sets replBridgeEnabled in AppState, which triggers
 * useReplBridge in REPL.tsx to initialize the bridge connection.
 */
```

这是一个完整的双向通信系统，有 access token 管理、版本检查、环境无关模式（`envLessBridge`）。

---

## 三、内部命令分析（USER_TYPE === 'ant'）

`INTERNAL_ONLY_COMMANDS` 数组定义在 `commands.ts` 第 225-248 行。这些命令只在 Anthropic 员工（`USER_TYPE === 'ant'`）的构建中可用：

| 命令 | 说明 |
|------|------|
| `backfillSessions` | 回填会话数据（stub） |
| `breakCache` | 破坏/刷新缓存 |
| `bughunter` | Bug 猎人工具（stub） |
| `commit` | Git 提交（带归因标记） |
| `commitPushPr` | 一键提交+推送+创建 PR |
| `ctx_viz` | 上下文可视化 |
| `goodClaude` | 内部反馈/评价工具（stub） |
| `issue` | GitHub Issue 管理 |
| `initVerifiers` | 初始化验证器 |
| `forceSnip` | 强制裁剪历史（依赖 `HISTORY_SNIP` flag） |
| `mockLimits` | 模拟 API 限制 |
| `bridgeKick` | 踢出桥接连接 |
| `version` | 版本信息（内部版） |
| `ultraplan` | 远程超级规划（依赖 `ULTRAPLAN` flag） |
| `subscribePr` | PR 订阅（依赖 `KAIROS_GITHUB_WEBHOOKS` flag） |
| `resetLimits` | 重置 API 限制 |
| `resetLimitsNonInteractive` | 非交互式重置限制 |
| `onboarding` | 内部 onboarding 流程 |
| `share` | 分享会话 |
| `summary` | 会话摘要 |
| `teleport` | 会话传送/远程 agent |
| `antTrace` | 内部追踪工具 |
| `perfIssue` | 性能问题诊断 |
| `env` | 环境信息 |
| `oauthRefresh` | OAuth token 刷新 |
| `debugToolCall` | 调试工具调用 |
| `agentsPlatform` | Agent 平台管理 |
| `autofixPr` | 自动修复 PR（stub） |

注意：大部分 stub 命令（`backfillSessions`、`bughunter`、`autofix-pr`、`goodClaude`）的实现被完全移除，只保留了空壳。[推测] 这说明这个源码快照是从一个已经剥离了内部实现的代码库中提取的。

---

## 四、其他值得关注的 Flag

| Flag | 一句话 |
|------|--------|
| `TEAMMEM` (51) | 团队协作记忆——在 autoMem 下建 team/ 子目录，有专属 UI 组件和提取管线，已接近 GA 成熟度 |
| `BASH_CLASSIFIER` (45) | Bash 命令安全分级——嵌入权限对话、结果展示、结构化 IO、多 handler 的全链路安全基座 |
| `PROACTIVE` (37) | 主动式行为，和 KAIROS 几乎完全重叠，可能是旧名 |
| `EXPERIMENTAL_SKILL_SEARCH` (21) | 让 AI 自动发现和使用可用技能 |
| `KAIROS_CHANNELS` (19) | Kairos 的多渠道推送（Slack 等） |
| `UDS_INBOX` (17) | Unix Domain Socket 收件箱，本地进程通信 |
| `CHICAGO_MCP` (16) | MCP 协议扩展（Chicago 可能是内部代号） |
| `HISTORY_SNIP` (15) | 历史记录裁剪，配合 /force-snip 内部命令 |
| `MONITOR_TOOL` (13) | 监控工具，可能用于可观测性 |
| `COMMIT_ATTRIBUTION` (12) | Git 提交中加入 Claude Code 归因 |
| `CACHED_MICROCOMPACT` (12) | 缓存微压缩，优化 prompt cache 效率 |
| `BG_SESSIONS` (11) | 后台会话，多会话并行 |
| `WORKFLOW_SCRIPTS` (10) | 工作流脚本系统 |
| `SHOT_STATS` (10) | 使用统计 |
| `TOKEN_BUDGET` (9) | Token 预算控制，支持 "+500k" 这种指令 |
| `PROMPT_CACHE_BREAK_DETECTION` (9) | 检测 prompt 缓存何时失效 |
| `MCP_SKILLS` (9) | 通过 MCP 协议加载技能 |
| `EXTRACT_MEMORIES` (7) | 从对话中自动提取记忆 |
| `CONNECTOR_TEXT` (7) | 连接器文本摘要化 |
| `TEMPLATES` (6) | 项目模板系统 |
| `LODESTONE` (6) | 待确认——可能是某种导航/指引系统 |
| `WEB_BROWSER_TOOL` (4) | 内置 Web 浏览器工具 |
| `VERIFICATION_AGENT` (4) | 独立的验证 Agent |
| `SSH_REMOTE` (4) | SSH 远程连接 |
| `DAEMON` (3) | 守护进程模式 |
| `MEMORY_SHAPE_TELEMETRY` (3) | 记忆形态遥测 |
| `FILE_PERSISTENCE` (3) | 文件持久化 |
| `POWERSHELL_AUTO_MODE` (2) | PowerShell 自动模式 |
| `NATIVE_CLIPBOARD_IMAGE` (2) | 原生剪贴板图片支持 |
| `HARD_FAIL` (2) | 硬失败模式（不重试） |
| `UNATTENDED_RETRY` (1) | 无人值守重试 |
| `ULTRATHINK` (1) | 超级思考模式 |
| `PERFETTO_TRACING` (1) | Perfetto 性能追踪（Android/Chrome 的追踪框架） |
| `DUMP_SYSTEM_PROMPT` (1) | 转储完整系统提示词 |
| `BUILDING_CLAUDE_APPS` (1) | 构建 Claude 应用模式 |
| `BUILTIN_EXPLORE_PLAN_AGENTS` (1) | 内置探索+规划 Agent |
| `BYOC_ENVIRONMENT_RUNNER` (1) | Bring Your Own Cloud 环境运行器 |
| `ABLATION_BASELINE` (1) | 消融实验基线（纯研究用途） |

---

## 五、未来方向推测

基于源码分析，以下是 Claude Code 大概率在准备的方向：

### 5.1 全自动 AI 员工（KAIROS 生态）

KAIROS + KAIROS_CHANNELS + KAIROS_PUSH_NOTIFICATION + KAIROS_GITHUB_WEBHOOKS + AGENT_TRIGGERS 这组 flag 不是在做"功能"，是在做"平台"。完整的拼图是：

- AI 自主运行（KAIROS 的 tick 循环）
- 定时触发（AGENT_TRIGGERS 的 cron）
- 多渠道通知（KAIROS_CHANNELS → Slack/Discord/邮件）
- 外部事件响应（KAIROS_GITHUB_WEBHOOKS）
- 记忆巩固（KAIROS_DREAM）

这已经不是一个 coding assistant 了，这是一个可以 7×24 自主工作的 AI 员工。

### 5.2 多 Agent 编排成为默认模式

COORDINATOR_MODE + FORK_SUBAGENT + BG_SESSIONS + VERIFICATION_AGENT 的组合暗示：未来的大任务默认由多 agent 协作完成。Coordinator 管调度，worker 干活，verifier 检查结果。

### 5.3 消费级体验层

BUDDY + AUTO_THEME + MESSAGE_ACTIONS 的组合说明 Anthropic 在认真做终端的"体验层"。桌面宠物可能听起来搞笑，但[推测] 它代表一种产品哲学：工具也可以有情感连接。

### 5.4 多端融合

BRIDGE_MODE + SSH_REMOTE + DIRECT_CONNECT + DESKTOP + MOBILE 的组合暗示 Claude Code 正在变成一个多端同步的平台——你在手机上开始，电脑上继续，远程服务器上执行。

### 5.5 记忆系统成熟

EXTRACT_MEMORIES + KAIROS_DREAM + AGENT_MEMORY_SNAPSHOT 组成了一个完整的记忆管线：提取 → 整合 → 快照。这是让 AI 跨会话保持连续性的关键。

---

## 六、产品迭代建议

### 6.1 KAIROS 应该尽快公开

引用 154 次，代码成熟度很高，提示词设计精细。当前唯一缺少的是用户教育——告诉用户"你的 AI 可以自己跑"需要足够的 UX 引导。建议分阶段推出：先出 Sleep 工具 + tick 循环，再加渠道推送，最后开放全自主模式。

### 6.2 BUDDY 是一个被低估的增长功能

没有任何生产力价值，但这是让 Claude Code 在社交媒体上出圈的最好机会。"我的 AI 编程助手养了一只传奇水獭"——这种 UGC 内容是花钱买不到的。建议做成 GA，并加入更多互动（喂食、升级、成就系统）。

### 6.3 上下文管理需要统一

CONTEXT_COLLAPSE、REACTIVE_COMPACT、CACHED_MICROCOMPACT、HISTORY_SNIP——四个 flag 都在解决上下文管理的问题，但策略各不相同。建议收敛到 1-2 个方案，给用户一个清晰的选择。

### 6.4 内部命令应该更有选择性地公开

`/commit`、`/commit-push-pr`、`/summary` 这些命令对所有用户都有价值。当前的实现已经很完善（带归因、安全检查、PR 审查者配置），应该考虑 GA。

### 6.5 反蒸馏措施需要更透明

ANTI_DISTILLATION_CC 注入假工具定义这件事如果被用户发现但没有提前说明，会造成信任危机。建议在文档中明确说明数据使用政策。

---

## 七、功能成熟度矩阵

| 功能 | 成熟度 | 可见性 | 建议 |
|------|--------|--------|------|
| KAIROS 主动模式 | ★★★★☆ | 隐藏 | 准备 GA，需 UX 引导 |
| KAIROS_DREAM | ★★☆☆☆ | 隐藏 | 早期实验，可合并到 KAIROS |
| BUDDY 桌面宠物 | ★★★★☆ | 隐藏 | 建议尽快 GA |
| COORDINATOR_MODE | ★★★☆☆ | 隐藏 | 需要更多打磨，适合高级用户 |
| VOICE_MODE | ★★★★☆ | 部分可见 | 需要 OAuth，限制了受众 |
| FORK_SUBAGENT | ★★★☆☆ | 隐藏 | 和 Coordinator 二选一即可 |
| AGENT_TRIGGERS | ★★★★★ | 已 GA | `/loop` 已在 changelog 公告 |
| ANTI_DISTILLATION_CC | ★★★☆☆ | 完全隐藏 | 需要更透明 |
| TRANSCRIPT_CLASSIFIER | ★★★★☆ | 部分可见 | Auto 模式的底层引擎 |
| CONTEXT_COLLAPSE | ★★★☆☆ | 隐藏 | 需要和其他方案收敛 |
| REACTIVE_COMPACT | ★★☆☆☆ | 仅内部 | ant-only，可能不会公开 |
| BRIDGE_MODE | ★★★★☆ | 可见 | `/remote-control` 已有命令 |
| ULTRAPLAN | ★★★☆☆ | 隐藏 | 远程 Opus 规划，高级功能 |
| TEAMMEM | ★★★☆☆ | 隐藏 | 团队协作，细节待确认 |
| 内部命令 | ★★★★☆ | 仅 ant | 部分应考虑 GA |

---

## 结论

Claude Code 的源码揭示了一个比公开版本丰富得多的产品。75 个 feature flag 不是在做"功能扩展"，而是在构建一个**AI 工作平台**：自主运行、多 agent 编排、跨设备同步、定时任务、记忆系统、多渠道通知。

最让人的不是某个具体功能，而是产品方向的一致性：Anthropic 不是在做一个更好的代码补全工具，他们是在重新定义"编程"这件事——从"人写代码"变成"人管理 AI 团队写代码"。

BUDDY 除外。BUDDY 就是真的好玩。

---

*分析基于 Claude Code v2.1.42 源码。部分功能的状态可能与当前发布版本有差异。标注"待确认"的内容缺乏足够代码证据。*

---

## 八、KAIROS 生态全景图

前面讲了 KAIROS 单点，但这个 flag 的真正价值在于它不是一个功能——它是一个生态。把所有 KAIROS 相关 flag 拉通看，会发现 Anthropic 在搭一个完整的"AI 员工操作系统"。

### 8.1 KAIROS 子系统架构

```
KAIROS (核心引擎)
 ├── KAIROS_BRIEF (精简通知层)
 ├── KAIROS_CHANNELS (多渠道分发)
 ├── KAIROS_PUSH_NOTIFICATION (推送触达)
 ├── KAIROS_GITHUB_WEBHOOKS (外部事件接入)
 └── KAIROS_DREAM (离线记忆整理)
```

每个子系统解决一个独立问题：

**KAIROS_BRIEF** 解决信息过载。自主运行的 AI 会产生大量中间状态——搜索结果、文件读取、命令输出。如果全部推给用户，通知疲劳是必然的。Brief 的作用是把一整轮自主工作压缩成一句话摘要。代码里配合 `/brief` 命令使用，说明这是给用户主动查询"刚才 AI 干了啥"的入口。

**KAIROS_CHANNELS** 解决触达问题。AI 发现了一个重要 bug 修复完成，但它该通知谁？在哪里通知？这个 flag 控制的分发层能把消息推到 Slack、Discord、邮件——用户在哪个渠道活跃，消息就去哪里。这和现代 DevOps 工具链的通知逻辑一致。

**KAIROS_PUSH_NOTIFICATION** 是最后一步——不依赖用户主动查看渠道，而是直接推送。4 次引用说明这个功能还在早期，但方向很明确。

**KAIROS_GITHUB_WEBHOOKS** 是"外部事件驱动"的入口。不是 AI 自己去找事做，而是 GitHub 有 PR、有 issue、有 review comment 的时候，webhook 触发 AI 去处理。这把 KAIROS 从"自主探索"变成了"事件响应"——成本更低，方向更准。

**KAIROS_DREAM** 前面讲过了。补充一个关键细节：Dream 的设计灵感来自神经科学中的"记忆巩固"（memory consolidation）理论——人脑在睡眠期间通过海马体-新皮层对话，把短期记忆转为长期记忆。KAIROS_DREAM 做的事完全一样：扫描最近的会话 transcript，提取有价值的信息，合并进持久化记忆。这个类比说明 Anthropic 的 AI 架构团队在认真研究认知科学。

### 8.2 KAIROS 的竞争定位

市面上"自主 AI agent"不缺——AutoGPT、BabyAGI、Devin 都做过类似尝试。KAIROS 的不同在于三个点：

1. **嵌入式而非独立运行**。KAIROS 不是一个独立的 agent 框架，它是 Claude Code 的运行模式之一。这意味着它天然继承了代码理解、工具调用、文件操作等能力，不需要从头搭建。

2. **Sleep 工具控制成本**。自主 agent 最大的问题是 token 消耗失控——无限循环地思考和执行。KAIROS 的 Sleep 工具强制 AI 在空闲时休眠，每次 wake-up 都有成本意识。提示词明确说"空闲时必须 Sleep，绝不许回复一句'还在等'"。

3. **Tick 循环而非事件循环**。AI 不是在等用户输入，而是被 `<tick>` 唤醒来判断"我现在该做什么"。这种设计允许 AI 在长时间无用户交互时依然保持活性——你下班了，AI 还在帮你跑 CI、修 lint、整理文档。

---

## 九、BUDDY 虚拟宠物深度分析

### 9.1 确定性生成算法

BUDDY 最值得注意的的设计是它的生成机制。每个用户的 Buddy 是基于 `hash(userId)` 确定性生成的，用 Mulberry32 PRNG。这意味着：

- 同一个用户永远"孵出"同一只 Buddy
- 不同用户看到的 Buddy 天然不同
- 没有服务端状态——Buddy 的"骨架"完全由客户端计算
- 用户换机器也不会"丢宠物"（只要 userId 不变）

稀有度权重分配遵循经典的 gacha 经济模型：common 60%、uncommon 25%、rare 10%、epic 4%、legendary 1%。1% 的传奇掉率足够让人有收集动力，又不至于每个人都拿到。

组合空间计算：18 物种 × 5 稀有度 × 6 眼睛 × 8 帽子 = 4,320 种外观组合。加上 shiny 变体（未在类型定义中暴露，但代码引用了 `isShiny`），实际组合数更多。这对一个"附带小功能"来说，深度足够了。

### 9.2 精灵动画系统

Buddy 不是静态头像，它有完整的 TUI（Terminal UI）动画：

- **500ms tick 更新**——和终端刷新频率匹配，不会卡顿
- **状态机驱动**：idle → blink → move → idle，大部分时间休息，偶尔眨眼或挪动
- **聊天气泡**：Buddy 会"评论"当前对话，气泡 10 秒显示，最后 3 秒渐隐
- **交互反馈**：`/buddy pet` 触发爱心飘浮，`/buddy feed` 等指令各有动画

这种终端内的"活物"效果，在 GUI 应用里很常见，但在 CLI 工具里几乎没人做过。

### 9.3 "观察者"角色

Buddy 不只是装饰。代码里它被定义为"独立观察者"——会读取当前对话内容并生成评论。[推测] 这意味着它实际上是一个轻量级的 second-opinion 机制：你在和 Claude 讨论方案，Buddy 在旁边"看"，偶尔冒出一句可能是搞笑也可能是洞见的评论。

这和日本游戏设计中的"同伴系统"（party member）理念一致——同伴不只是战力，还提供情感反馈和叙事视角。在编程工具里引入这种角色，[推测] 说明 Anthropic 的产品团队有游戏设计背景。

### 9.4 为什么 CLI 工具要加虚拟宠物

直觉上这不成立。CLI 用户要的是效率，不是娱乐。但三个角度看这个决策是有道理的：

**留存角度**：终端工具的用户留存是个老问题。Buddy 提供了一种微弱但持续的情感连接——"我得打开 Claude Code 看看我的小鸭子怎么样了"。这种留存机制在免费增值模型里很有价值。

**品牌角度**："我的 AI 助手养了一只传奇水獭"是天然的社交媒体内容。不需要营销预算，用户自己会传播。这在 AI 工具同质化的市场里是差异化的捷径。

**文化角度**：Anthropic 一直在讲"AI safety"和"有益的 AI"。Buddy 是这种理念的产品化表达——AI 可以是有趣的、温暖的、有个性的，而不只是一个冰冷的工具。这对品牌形象有长期价值。

---

## 十、Coordinator Mode 架构深度分析

### 10.1 系统 Prompt 设计

Coordinator 的系统 prompt 和普通 Claude Code 的 prompt 有本质区别。普通模式下，AI 是"执行者"——目标是完成用户的任务。Coordinator 模式下，AI 是"管理者"——目标是把任务拆解并分配给 worker。

核心设计原则：

```
You are a **coordinator**. Your job is to:
- Help the user achieve their goal
- Direct workers to research, implement and verify code changes
- Synthesize results and communicate with the user
```

注意三个动词：**research、implement、verify**。这三个阶段暗示了 Anthropic 认为的最优任务拆解粒度：先探索（读代码、搜文档），再实现（写代码、改文件），最后验证（跑测试、检查结果）。每个阶段可以由不同的 worker 完成。

### 10.2 Worker 管理

Worker 的工具集被限制了——Bash、Read、Edit、MCP 工具。没有 Agent tool（不能嵌套 spawn），没有协调能力。这是有意为之：

- **防止无限递归**：worker 不能再 spawn worker
- **控制成本**：worker 的工具少，token 消耗更可控
- **简化调试**：coordinator 可以清楚地看到每个 worker 在做什么

Scratchpad 目录是 worker 间知识共享的关键机制。Worker A 探索完代码结构后把发现写到 scratchpad，Worker B 读取后直接实现，不需要重复探索。

### 10.3 和 FORK_SUBAGENT 的取舍

这两个功能解决的问题有重叠但策略不同：

| 维度 | COORDINATOR_MODE | FORK_SUBAGENT |
|------|-----------------|---------------|
| 拓扑 | 星型（一个中心协调多个 worker） | 树型（子 agent 可以继续 fork） |
| 上下文 | Worker 只拿到任务描述，不继承上下文 | 子 agent 继承完整父上下文 |
| 适用场景 | 大任务拆解，多个独立子任务并行 | 需要上下文连续性的探索 |
| 成本 | 更可控（worker 上下文小） | 更高（完整上下文复制） |
| 互斥 | ✅ 不能同时开启 | ✅ 不能同时开启 |

代码注释明确说两者互斥——选择哪个取决于任务特性：需要并行拆解用 Coordinator，需要上下文继承用 Fork。

---

## 十一、剩余 Flag 深度分析

### 11.1 `TEAMMEM` — 团队协作成员（51 次引用）

引用量排第三的 flag，已经深度集成到记忆系统、消息展示和记忆提取三个子系统里。

**记忆路径层**（`memdir/memdir.ts`）：

```typescript
if (feature('TEAMMEM')) {
  if (teamMemPaths!.isTeamMemoryEnabled()) {
    const autoDir = getAutoMemPath()
    const teamDir = teamMemPaths!.getTeamMemPath()
    await ensureMemoryDirExists(teamDir)
    // ...
  }
}
```

TEAMMEM 在自动记忆目录下创建一个 `team/` 子目录。关键细节：注释里明确说 KAIROS daily-log 模式优先于 TEAMMEM——append-only 日志范式和团队共享 MEMORY.md 不兼容，所以两者互斥。这说明 Anthropic 在认真思考"AI 自主模式"和"团队协作模式"怎么共存。

**消息展示层**（`components/messages/`）：

```typescript
// CollapsedReadSearchContent.tsx
const hasTeamMemoryOps = feature('TEAMMEM')
  ? teamMemCollapsed!.checkHasTeamMemOps(message) : false
// SystemTextMessage.tsx
t1 = feature("TEAMMEM") ? teamMemSaved.teamMemSavedPart(message) : null
```

TEAMMEM 有专门的消息渲染组件——`teamMemCollapsed.tsx` 和 `teamMemSaved.ts`。这些不是 stub，是完整的 UI 组件，会在消息流里展示团队记忆的保存/读取状态。

**记忆提取层**（`services/extractMemories/extractMemories.ts`）：

```typescript
const teamMemoryEnabled = feature('TEAMMEM')
// ...
if (feature('TEAMMEM') && teamMemoryEnabled) {
  // 团队记忆提取逻辑
}
```

记忆提取系统在 TEAMMEM 开启时会同时处理个人记忆和团队记忆——把对话中有价值的信息提取到团队共享的 MEMORY.md 里。

**判断**：51 次引用 + 3 个子系统的实际集成 + 专门的 UI 组件 = 这个功能已经接近 GA 级别的成熟度。只差公开文档和用户引导。

### 11.2 `BASH_CLASSIFIER` — Bash 命令安全分级（45 次引用）

和 TRANSCRIPT_CLASSIFIER 配对工作。后者管"这个对话该不该自动审批"，前者管"这个 shell 命令该不该自动执行"。从代码看，它已经深度嵌入权限处理的每一个层级。

**权限对话层**（`BashPermissionRequest.tsx`）——11 个引用点：

```typescript
// classifierCheckInProgress 控制"正在检查"的 loading 状态
const [classifierWasChecking] = useState(
  feature('BASH_CLASSIFIER')
    ? !!toolUseConfirm.classifierCheckInProgress : false)

// classifierAutoApproved 决定是否跳过用户确认
isActive: feature('BASH_CLASSIFIER')
  ? !!toolUseConfirm.classifierAutoApproved : false

// 自动审批时，选项变灰、dim 显示
isDisabled={feature('BASH_CLASSIFIER')
  ? toolUseConfirm.classifierAutoApproved : false}
```

分类器判定安全时（`classifierAutoApproved = true`），权限对话框进入特殊状态——选项变灰、自动勾选 `yes-classifier-reviewed`。用户不需要确认，但能看到"AI 已审查过这条命令"的提示。

**结果展示层**（`UserToolSuccessMessage.tsx`）：命令执行成功后，旁边显示分类器的判定依据——让用户知道为什么这条命令被放行或拦截。

**结构化 IO 层**（`cli/structuredIO.ts`）：`BASH_CLASSIFIER || TRANSCRIPT_CLASSIFIER` 共享同一个结构化输出通道——说明两个分类器是统一设计的，不是两套独立系统。

**子 agent 也继承**：coordinator handler、swarm worker handler、interactive handler 都检查 BASH_CLASSIFIER——说明安全分级不限于主 agent，是全局生效的。

**判断**：45 次引用遍布权限对话、结果展示、结构化输出、多处理器——安全分级不是附加功能，是整个工具执行管线的安全基座。Auto 模式完全依赖它来决定哪些命令可以自动执行。

### 11.3 `WEB_BROWSER_TOOL` — 内置 Web 浏览器（4 次引用）

引用少不代表不重要——浏览器工具本身功能很重，flag 只控制是否暴露入口。从 `web_browser` 工具的实现来看，它是一个完整的 headless 浏览器集成，支持页面导航、元素点击、表单填写、截图。

这和 OpenClaw 的 browser skill 类似，但内建在 Claude Code 里意味着它可以和代码操作深度结合——比如自动登录文档网站抓 API reference，或者在 CI 失败时自动打开构建日志页面分析错误。

### 11.4 `DIRECT_CONNECT` — 直连模式（5 次引用）

允许 Claude Code 不经过 Anthropic API 代理，直连模型端点。这在以下场景有用：
- 企业内网部署（自建推理服务）
- 使用第三方模型 provider
- 减少延迟（跳过中间层）

5 次引用说明它是一个基础设施级功能，不需要在业务逻辑中频繁判断——一次判断后，整个连接路径就确定了。

### 11.5 `NATIVE_CLIENT_ATTESTATION` — 原生客户端证明（1 次引用）

这是安全基础设施。客户端证明（client attestation）是一种验证"请求确实来自合法客户端"的机制——防止有人用脚本直接调 API 冒充 Claude Code。

结合 `ANTI_DISTILLATION_CC`（注入假工具定义）来看，Anthropic 在 API 层面构建了一套反滥用体系：
1. 验证客户端身份（NATIVE_CLIENT_ATTESTATION）
2. 防止输出被蒸馏（ANTI_DISTILLATION_CC）
3. 命令安全分级（BASH_CLASSIFIER + TRANSCRIPT_CLASSIFIER）

这三道防线覆盖了"谁在调用"、"数据怎么保护"、"操作怎么管控"三个维度。

### 11.6 `CONTEXT_COLLAPSE` 详细机制

前面提了 90%/95% 阈值，补充关键设计：

CONTEXT_COLLAPSE 和普通的上下文压缩（compact）不同。普通 compact 是"被动压缩"——上下文满了再压缩。CONTEXT_COLLAPSE 是"主动管理"——它持续监控上下文使用率，在到达临界点前就开始做增量压缩。

`marble_origami` 条件判断很有趣——这似乎是某个特定的请求来源标记，说明 CONTEXT_COLLAPSE 对不同类型的请求有不同的策略。某些来源的请求可能不适合被压缩（比如需要完整历史的长对话）。

代码里的 "90% commit / 95% blocking-spawn flow" 描述了一种两级背压机制：
- 90% 时开始压缩（commit 压缩 = 把旧的对话轮次压缩成摘要）
- 95% 时阻塞新的子 agent 创建（防止在即将溢出时还开新任务）

### 11.7 `REACTIVE_COMPACT` — 响应式压缩（仅内部，6 次引用）

标注了 "ant-only"，是 Anthropic 内部实验的另一种上下文管理策略。核心思路完全不同：不主动压缩，等 API 返回 prompt-too-long 错误时再响应式压缩。

**懒加载 import**（`query.ts`）：

```typescript
const reactiveCompact = feature('REACTIVE_COMPACT')
  ? require('./services/compact/reactiveCompact.js') : null
const contextCollapse = feature('CONTEXT_COLLAPSE')
  ? require('./services/contextCollapse/index.js') : null
```

注意：REACTIVE_COMPACT 和 CONTEXT_COLLAPSE 是**并列的懒加载**——代码同时导入两个模块，说明它们可以共存，不是互斥关系。

**和主动压缩的互斥逻辑**（`autoCompact.ts`）：

```typescript
// Reactive-only mode: suppress proactive autocompact, let reactive compact
// catch the API's prompt-too-long.
if (feature('REACTIVE_COMPACT')) {
  if (getFeatureValue_CACHED_MAY_BE_STALE('tengu_cobalt_raccoon', false)) {
    return false  // 抑制主动 autocompact
  }
}
```

当 REACTIVE_COMPACT 开启时，主动压缩（autoCompact）会被抑制。策略是：不提前压缩，等 API 返回 prompt-too-long 错误时再响应式压缩。优点是不影响正常对话流程，缺点是有一次请求失败的代价。

**分析器也感知**（`analyzeContext.ts`）：

```typescript
if (feature('REACTIVE_COMPACT')) {
  if (getFeatureValue_CACHED_MAY_BE_STALE('tengu_cobalt_raccoon', false)) {
    skipReservedBuffer = true  // 不预留 token 缓冲区
  }
}
```

上下文分析器在 REACTIVE_COMPACT 开启时会跳过 token 预留缓冲区——因为不需要提前为压缩留空间，响应式压缩会在溢出时处理。

**判断**：这种"懒策略"和 CONTEXT_COLLAPSE 的"激进策略"形成对比——一个是提前管理（90%/95% 阈值），一个是事后补救。两者同时存在说明 Anthropic 还在探索哪种上下文管理范式更好。`tengu_cobalt_raccoon` 的命名（cobalt 浣熊）延续了宝石/动物的 GrowthBook 命名惯例。

### 11.8 `VOICE_MODE` 补充分析

语音模式依赖 Anthropic OAuth 而非 API key，这是因为 `voice_stream` 端点是 claude.ai 独有的——它走的是实时流式语音合成，不是标准的 text-to-text API。

GrowthBook kill-switch `tengu_amber_quartz_disabled` 的命名说明 Anthropic 用宝石命名 kill-switch（amber quartz = 琥珀石英），这是一个有趣的内部命名惯例。

keychain token 读取 20-50ms 的冷启动成本在语音场景下是有意义的——语音交互对延迟敏感，任何卡顿都会被用户感知。

---

## 十二、架构层分析

从 flag 分布可以推断 Claude Code 的代码架构至少分五层：

```
┌─────────────────────────────────────────┐
│  Layer 5: 体验层                         │
│  BUDDY, AUTO_THEME, MESSAGE_ACTIONS     │
├─────────────────────────────────────────┤
│  Layer 4: 编排层                         │
│  COORDINATOR_MODE, FORK_SUBAGENT,       │
│  BG_SESSIONS, VERIFICATION_AGENT        │
├─────────────────────────────────────────┤
│  Layer 3: 自主层                         │
│  KAIROS, PROACTIVE, AGENT_TRIGGERS,     │
│  KAIROS_DREAM, KAIROS_CHANNELS          │
├─────────────────────────────────────────┤
│  Layer 2: 安全层                         │
│  TRANSCRIPT_CLASSIFIER, BASH_CLASSIFIER,│
│  ANTI_DISTILLATION_CC,                  │
│  NATIVE_CLIENT_ATTESTATION              │
├─────────────────────────────────────────┤
│  Layer 1: 基础设施层                     │
│  CONTEXT_COLLAPSE, HISTORY_SNIP,        │
│  CACHED_MICROCOMPACT, TOKEN_BUDGET,     │
│  PROMPT_CACHE_BREAK_DETECTION,          │
│  DIRECT_CONNECT, UDS_INBOX              │
└─────────────────────────────────────────┘
```

每一层都依赖下层，但层内功能可以独立开关。这是典型的 feature flag 架构——新功能通过 flag 灰度发布，不需要改核心流程。

Layer 1 是最基础的——没有上下文管理和 token 控制，上面什么都跑不起来。Layer 2 是安全门——任何自动化操作都必须经过安全检查。Layer 3 是 KAIROS 自主能力。Layer 4 是多 agent 编排。Layer 5 是用户体验。

这个分层说明 Claude Code 的代码架构相当成熟——不是所有功能堆在一起，而是有清晰的职责边界。

---

## 十三、竞品对比：用 feature flag 视角看差异化

### 13.1 功能矩阵

| 能力 | Claude Code (flag) | Cursor | Windsurf | GitHub Copilot |
|------|-------------------|--------|----------|----------------|
| 自主运行 | KAIROS (154 引用) | 无 | Cascade (有限) | 无 |
| 多 Agent 编排 | COORDINATOR_MODE (32) + FORK_SUBAGENT (4) | 无 | 无 | Copilot Workspace (早期) |
| 语音交互 | VOICE_MODE (46) | 无 | 无 | 无 |
| 虚拟宠物 | BUDDY (16) | 无 | 无 | 无 |
| 设备桥接 | BRIDGE_MODE (28) | 无 | 无 | 无 |
| 反蒸馏 | ANTI_DISTILLATION_CC | 无 | 无 | 无 |
| 命令安全分级 | BASH_CLASSIFIER (45) + TRANSCRIPT_CLASSIFIER (107) | 基础规则 | 无 | 无 |
| 记忆系统 | KAIROS_DREAM (1) + EXTRACT_MEMORIES (7) | Rules (手动) | Memories (简单) | 无 |
| 定时任务 | AGENT_TRIGGERS (11) | 无 | 无 | 无 |
| 团队协作 | TEAMMEM (51) | 无 | 无 | Copilot Org |
| 上下文管理 | CONTEXT_COLLAPSE (20) + REACTIVE_COMPACT (4) + CACHED_MICROCOMPACT (12) | 自动索引 | 自动索引 | 有限 |
| 远程规划 | ULTRAPLAN (10) | 无 | 无 | 无 |
| Token 预算 | TOKEN_BUDGET (9) | 无 | 无 | 无 |
| Web 浏览器 | WEB_BROWSER_TOOL (4) | 无 | 内置 | 无 |
| 快速搜索 | QUICK_SEARCH (5) | Cmd+K | 无 | 无 |

### 13.2 用 feature flag 数量做结构化对比

| 维度 | Claude Code | Cursor | Windsurf | Copilot |
|------|------------|--------|----------|---------|
| Feature flag 总数 | **75**（源码确认） | ~10（公开猜测） | ~5（极少公开） | ~15（VS Code 插件标准） |
| 自主能力 flag 数 | 6 (KAIROS 系列) | 0 | 1 (Cascade) | 0 |
| 安全相关 flag 数 | 4 (BASH/TRANSCRIPT/ANTI_DISTILL/ATTESTATION) | 1 | 0 | 0 |
| 体验层 flag 数 | 3 (BUDDY/AUTO_THEME/MESSAGE_ACTIONS) | 0 | 0 | 0 |

75 个 flag 是什么概念？这意味着 Claude Code 的每一个大功能——自主运行、多 agent 编排、语音、宠物、安全分级、记忆系统——都用编译时 flag 做了独立门控。竞品几乎没有这个级别的功能粒度控制。

### 13.3 Claude Code 能做但竞品做不了的事

**1. 编译时功能裁剪**。Claude Code 用 `bun:bundle` 的 `feature()` 做死代码消除——没开的 flag，相关代码直接从产物里移除。这意味着内部版和公开版可以是完全不同的二进制，但共享同一份源码。Cursor 和 Copilot 是 Electron/VS Code 插件，做不到这个粒度。

**2. 安全分类器内建在工具执行路径里**。BASH_CLASSIFIER 在 11 个权限处理器中有引用——不只是在工具调用前检查一次，而是嵌入了权限对话、结果展示、结构化输出等全链路。竞品的安全是外挂的（规则列表），Claude Code 的安全是内建的。

**3. KAIROS 的 tick 循环**。没有任何竞品有类似的"AI 空闲时自己找事做"的机制。Cursor 的 Agent 模式是用户触发的，Windsurf 的 Cascade 也是交互式的。KAIROS 的 `<tick>` + Sleep 工具是真正的自主运行——你下班了，AI 还在帮你跑 CI、修 lint、整理文档。

**4. BUDDY 无竞品**。没有其他工具在 CLI 里做虚拟宠物。这听起来像个笑话，但它代表的产品哲学是认真的：工具可以有情感连接。在 AI 工具同质化到"换个 logo 都分不清"的市场里，BUDDY 是真正的差异化。

### 13.4 竞品做得到但 Claude Code 做不到的事

公平起见也要说：

- **Cursor 的 IDE 集成更深**。它不是一个 CLI 工具，它直接替代你的编辑器。代码补全、inline diff、多文件编辑的 UX 远比终端体验好。
- **Windsurf 的 Cascade 有更流畅的 UI 交互**。视觉化的 agent 工作流展示比终端里的文字输出直观得多。
- **Copilot 的生态覆盖面最广**。VS Code、JetBrains、Neovim、Web——哪里都能用。Claude Code 目前只有终端。
- **Devin 的全自主模式更成熟**。毕竟是一个独立产品，从第一天就围绕自主模式设计的。Claude Code 的 KAIROS 还在从"工具"往"员工"的转型中。

**核心判断**：Claude Code 的 75 个 flag 不是在做"功能扩展"，是在构建一个 AI 工作平台。和 Devin 的定位有重叠，但路径完全不同——Devin 是"替代程序员"，Claude Code 是"让程序员变成 AI 团队管理者"。从 feature flag 的分布看，后者的野心更大。

---

## 十四、安全体系专题

前面分散在各处的安全特性值得单独拉通看：

### 14.1 三层安全架构

**第一层：身份验证（NATIVE_CLIENT_ATTESTATION）**
- 验证请求确实来自合法的 Claude Code 客户端
- 防止 API 被脚本直接调用滥用

**第二层：数据保护（ANTI_DISTILLATION_CC）**
- 注入假工具定义，防止输出被用来训练竞品模型
- 仅在 CLI 入口 + first-party beta headers 时触发

**第三层：操作管控（BASH_CLASSIFIER + TRANSCRIPT_CLASSIFIER）**
- Bash 命令安全分级：低风险自动放行，高风险拦截
- 对话内容分类：判断是否适合自动审批

这三层覆盖了完整的安全链路：谁在调用 → 数据怎么保护 → 操作怎么管控。

### 14.2 GrowthBook Kill-Switch 体系

多个功能通过 GrowthBook feature flag 做远程控制：
- `tengu_amber_quartz_disabled` — Voice Mode kill-switch
- `tengu_cobalt_raccoon` — Reactive Compact 灰度
- `tengu_kairos_cron` — Cron 功能开关
- `tengu_ultraplan_model` — Ultraplan 模型选择
- `tengu_anti_distill_fake_tool_injection` — 反蒸馏开关

命名规律：`tengu_` 前缀 + 宝石/动物名（amber quartz、cobalt raccoon）。Tengu 是日本神话中的天狗——这可能是 Anthropic 内部的项目代号体系。

这些 flag 的默认值设计很有意思：Voice Mode 的 kill-switch 默认关闭（= 可用），需要时才打开（= 禁用）。这是一种"默认信任，紧急回退"的策略——比"默认禁用，需要时打开"更激进，说明 Anthropic 对这些功能的稳定性有信心。

### 14.3 安全模型的演化趋势

从 flag 分布看，安全从"附加层"变成了"基础设施"。TRANSCRIPT_CLASSIFIER 引用 107 次、BASH_CLASSIFIER 引用 45 次——这意味着安全检查已经深度嵌入到几乎所有工具执行路径中。

这和 AI safety 的行业趋势一致：从"事后审查"走向"内建安全"（safety by design）。Anthropic 作为 AI safety 领域的领导者，这种架构选择不意外。

---

## 十五、扩展功能成熟度矩阵

在第七节的基础上，补充更多 flag 的成熟度评估：

| 功能 | 成熟度 | 引用量 | 可见性 | 推荐动作 |
|------|--------|--------|--------|---------|
| KAIROS 核心 | ★★★★☆ | 154 | 隐藏 | GA 候选，需 UX 设计 |
| KAIROS_BRIEF | ★★★★☆ | 39 | 隐藏 | 随 KAIROS 一起 GA |
| KAIROS_CHANNELS | ★★★☆☆ | 19 | 隐藏 | 需要更多渠道集成 |
| KAIROS_PUSH_NOTIFICATION | ★★☆☆☆ | 4 | 隐藏 | 早期，等 KAIROS 先 GA |
| KAIROS_GITHUB_WEBHOOKS | ★★☆☆☆ | 3 | 隐藏 | 早期，场景明确但集成不足 |
| KAIROS_DREAM | ★★☆☆☆ | 1 | 隐藏 | 实验阶段，观察中 |
| BUDDY | ★★★★☆ | 16 | 隐藏 | 立即 GA，社交传播潜力大 |
| COORDINATOR_MODE | ★★★☆☆ | 32 | 隐藏 | 高级用户预览版 |
| FORK_SUBAGENT | ★★★☆☆ | 4 | 隐藏 | 和 Coordinator 二选一 |
| VOICE_MODE | ★★★★☆ | 46 | 部分可见 | 扩展 auth 方式 |
| AGENT_TRIGGERS | ★★★★★ | 11 | 已 GA | 已发布，继续迭代 |
| BASH_CLASSIFIER | ★★★★☆ | 45 | 内部 | Auto 模式核心，不需要单独公开 |
| TRANSCRIPT_CLASSIFIER | ★★★★☆ | 107 | 部分可见 | Auto 模式底层，不需要单独公开 |
| CONTEXT_COLLAPSE | ★★★☆☆ | 20 | 隐藏 | 和其他方案收敛 |
| REACTIVE_COMPACT | ★★☆☆☆ | 4 | 仅内部 | 实验中，可能被 CONTEXT_COLLAPSE 取代 |
| BRIDGE_MODE | ★★★★☆ | 28 | 可见 | 已有 /remote-control，继续迭代 |
| TEAMMEM | ★★★☆☆ | 51 | 隐藏 | 团队功能核心，需更多集成 |
| ANTI_DISTILLATION_CC | ★★★☆☆ | 1 | 完全隐藏 | 需要提高透明度 |
| NATIVE_CLIENT_ATTESTATION | ★★☆☆☆ | 1 | 完全隐藏 | 安全基础设施，不需要公开 |
| WEB_BROWSER_TOOL | ★★★☆☆ | 4 | 隐藏 | 和代码操作深度集成 |
| DIRECT_CONNECT | ★★★☆☆ | 5 | 隐藏 | 企业场景必备 |
| ULTRAPLAN | ★★★☆☆ | 10 | 隐藏 | 远程高级功能 |
| UDS_INBOX | ★★☆☆☆ | 17 | 隐藏 | 本地进程通信基础设施 |
| CHICAGO_MCP | ★★☆☆☆ | 16 | 隐藏 | MCP 扩展，代号阶段 |
| TOKEN_BUDGET | ★★★☆☆ | 9 | 隐藏 | 成本控制关键功能 |
| EXTRACT_MEMORIES | ★★☆☆☆ | 7 | 隐藏 | 记忆管线早期 |
| WORKFLOW_SCRIPTS | ★★☆☆☆ | 10 | 隐藏 | 自动化能力扩展 |
| EXPERIMENTAL_SKILL_SEARCH | ★★☆☆☆ | 21 | 隐藏 | 技能发现机制 |
| SHOT_STATS | ★★★☆☆ | 10 | 隐藏 | 产品数据基础设施 |
| CACHED_MICROCOMPACT | ★★★☆☆ | 12 | 隐藏 | prompt cache 优化 |

---

## 十六、开源策略推断

源码中的一致模式暗示了 Anthropic 的开源/闭源策略：

**开源的**：CLI 框架、工具接口、协议规范（MCP）
**闭源的**：安全分类器（TRANSCRIPT_CLASSIFIER、BASH_CLASSIFIER）、反蒸馏逻辑（ANTI_DISTILLATION_CC）、远程服务端点（voice_stream、CCR）

KAIROS 的 tick 循环和 Sleep 工具的设计可能是开源的——它更多是架构选择而非模型能力。但 KAIROS_DREAM 的记忆整合 prompt 可能是闭源的——这涉及具体的提示词工程。

BUDDY 的确定性生成算法是开源的好选择——它不依赖模型能力，纯粹是工程实现。开源 BUDDY 可以快速建立社区。

---

## 十七、技术债与风险点

### 17.1 Flag 爆炸：75 个分支路径的维护地狱

75 个 feature flag 不是个小数字。每个 flag 至少产生两条代码路径（开/关），理论上测试矩阵是 2^75 种组合——当然没人测全部组合，但这就是问题所在：**没有人真正知道 flag 之间的交互会产生什么边界情况。**

具体风险点：

**隐式依赖**：KAIROS 关了但 KAIROS_DREAM 开了会怎样？autoDream.ts 里有 `if (getKairosActive()) return false` 的显式检查，但其他 flag 对之间呢？比如 TEAMMEM 和 KAIROS 的互斥是通过注释说明的，不是通过代码强制的：

```typescript
// KAIROS daily-log mode takes precedence over TEAMMEM: the append-only
// log paradigm does not compose with team sync
if (feature('KAIROS') && autoEnabled && getKairosActive()) {
  return buildAssistantDailyLogPrompt(skipIndex)
}
if (feature('TEAMMEM')) {
  if (teamMemPaths!.isTeamMemoryEnabled()) { ... }
}
```

这里 TEAMMEM 分支在 KAIROS 分支之后，依赖"KAIROS 分支先 return"来实现互斥。如果有人调整了分支顺序，TEAMMEM 和 KAIROS daily-log 就会同时生效——而这个 bug 不会触发编译错误，只会在运行时产生诡异的记忆同步问题。

**REACTIVE_COMPACT 和 CONTEXT_COLLAPSE 的共存风险**：从 query.ts 的代码看，两者是并列加载的。autoCompact.ts 里 REACTIVE_COMPACT 开启时会抑制主动压缩。但如果 CONTEXT_COLLAPSE 也同时开启呢？analyzeContext.ts 里两者都设置了 `skipReservedBuffer = true`——行为一致，但逻辑是分散在不同文件里的。未来改动其中一个，另一个不会自动适配。

**Bun dead code elimination 的盲区**：编译时 flag 确实能消除未开启的代码，但它不能消除 flag 之间的逻辑依赖。如果 `feature('BUDDY')` 为 false，BUDDY 相关的代码会被移除——但如果另一个 flag 的代码引用了 BUDDY 的某个类型或常量呢？Bun 不会报错（类型擦除），运行时才会出问题。

### 17.2 Stub 命令：死代码幻觉

`backfillSessions`、`bughunter`、`autofix-pr`、`goodClaude`——这些 stub 命令保留了 import 链但移除了实现，统一格式是：

```typescript
{ isEnabled: () => false, isHidden: true, name: 'stub' }
```

短期方便（随时可以加回实现），但长期有三个问题：

1. **新人困惑**：看到 `INTERNAL_ONLY_COMMANDS` 数组里有 20+ 个命令，其中 4 个是 stub，新人无法分辨哪些是活跃功能、哪些是历史残留
2. **Import 链开销**：虽然实现被移除了，但 import 链还在。每次启动时这些模块都会被解析和评估——对 CLI 工具来说，启动时间是用户体验的关键指标
3. **安全审计负担**：安全审查时需要确认 stub 命令确实没有实现，而不是被遗漏了

### 17.3 内外代码分裂：ant vs public 的鸿沟

`USER_TYPE === 'ant'` 产生的内外分裂比表面看起来严重。

从源码看，内部版有 28 个独占命令（`/commit`、`/summary`、`/ctx_viz`、`/ultraplan` 等），外部用户一个都用不了。问题不只是"功能不公开"，而是：

**开发方向脱节**：内部员工每天用的功能（`/commit-push-pr` 一键提交+推送+创建 PR）和外部用户能用的功能完全不同。内部团队可能会觉得"提交流程已经很顺了"，但外部用户还在手动跑 `git add && git commit && git push && gh pr create`。

**QA 覆盖偏移**：内部测试覆盖的是有 28 个额外命令的完整版本。当代码通过 feature gate 裁剪后发布给外部用户时，裁剪后的版本实际上没有被独立测试过。

**API endpoint 分裂**：VOICE_MODE 走 `voice_stream`（claude.ai 独有），ULTRAPLAN 走 CCR（Claude Code Remote），这些内部端点外部用户完全不知道存在。如果外部版本的 API 请求路径和内部版有任何差异，这种分裂会放大。

### 17.4 安全分类器的级联风险

BASH_CLASSIFIER（45 次引用）和 TRANSCRIPT_CLASSIFIER（107 次引用）是 Auto 模式的安全门。这两个数字本身就是风险指标：

**152 次引用意味着改一个分类逻辑可能影响 152 个代码路径。** 从 BASH_CLASSIFIER 的代码证据看，它已经嵌入了：
- 权限对话框的 11 个引用点（`BashPermissionRequest.tsx`）
- 3 个不同 handler 的权限检查（interactive、coordinator、swarm worker）
- 结构化 IO 输出
- 工具结果展示

这不是"核心依赖"——这是**基础设施依赖**。如果分类器的某个判定规则需要修改（比如把 `curl | bash` 从"高危"改为"中危"），这个修改的影响面是全局的，而且没有自动化测试能覆盖全部 45 个引用点。

**更隐蔽的风险**：BASH_CLASSIFIER 和 TRANSCRIPT_CLASSIFIER 共享结构化输出通道（`cli/structuredIO.ts` 里是 `BASH_CLASSIFIER || TRANSCRIPT_CLASSIFIER`）。如果两个分类器的输出格式有微妙差异，共用的通道可能会产生格式不一致的问题。

### 17.5 GrowthBook 依赖的运营风险

多个核心功能依赖 GrowthBook 远程配置：
- `tengu_onyx_plover` — Dream 开关
- `tengu_amber_quartz_disabled` — Voice kill-switch
- `tengu_cobalt_raccoon` — Reactive Compact 灰度
- `tengu_kairos_cron` — Cron 功能
- `tengu_ultraplan_model` — Ultraplan 模型

如果 GrowthBook 服务不可用，这些功能的行为取决于缓存策略——`CACHED_MAY_BE_STALE` 和 `CACHED_WITH_REFRESH` 的语义不同。stale cache 意味着功能可能在 GrowthBook 恢复后的一段时间内保持旧状态，refresh cache 意味着服务不可用时功能可能直接失效。

命名规律（`tengu_` 前缀 + 宝石/动物名）暗示了 GrowthBook 在 Anthropic 内部的使用规模。如果 gate 数量继续增长到 50+，运营负担会显著增加。

---

## 十八、给 Anthropic 产品团队的 10 条具体建议

1. **BUDDY 先行**。发布成本最低，社交传播价值最高。做成 GA 后收集用户数据，为其他功能的发布策略提供参考。

2. **KAIROS 分三阶段发布**。第一阶段：Sleep 工具 + tick 循环（用户可以看到 AI "醒了"在做什么）。第二阶段：加 KAIROS_BRIEF（压缩通知，避免信息过载）。第三阶段：全自主模式 + 渠道推送。

3. **把 `/summary` 和 `/ctx_viz` 公开**。这两个命令实现已经很完善，对所有用户都有价值。不需要等其他内部命令。

4. **统一上下文管理方案**。CONTEXT_COLLAPSE、REACTIVE_COMPACT、CACHED_MICROCOMPACT、HISTORY_SNIP 四个方案需要收敛。建议以 CONTEXT_COLLAPSE 为主（最成熟），REACTIVE_COMPACT 作为 fallback。

5. **VOICE_MODE 支持 API key**。当前限制 OAuth 把大量 API key 用户排除在外。可以考虑支持 API key 走 OpenAI 兼容的 TTS 端点作为 fallback。

6. **Coordinator Mode 做公开预览**。32 次引用说明它已经比较成熟，但用户体验还不完善。可以作为"实验功能"公开，收集反馈后再打磨。

7. **ANTI_DISTILLATION 更透明**。在文档中明确说明"为保护模型知识产权，API 返回可能包含混淆内容"。提前说比被发现好。

8. **TEAMMEM 尽快定义清楚**。51 次引用但几乎没有公开信息，这会让开发者困惑。至少在 roadmap 中提一下方向。

9. **发布 Feature Flag 文档**。不需要公开所有 flag，但可以把"已 GA"和"实验中"的 flag 列出来，让用户知道哪些功能可以期待。

10. **开源 BUDDY 和部分 KAIROS 架构**。BUDDY 的确定性生成算法和 KAIROS 的 tick 循环设计不涉及模型能力，开源可以快速建立社区和信任。

---

## 十九、结论（更新版）

重新审视整份分析，核心判断不变：**Claude Code 的源码揭示了一个远超公开版本的产品野心。**

但补充三个发现：

第一，**安全是基础设施，不是功能**。TRANSCRIPT_CLASSIFIER（107 次）和 BASH_CLASSIFIER（45 次）的引用量说明安全检查已经嵌入到几乎所有执行路径。这在 AI 工具里极为罕见——大部分竞品的安全是后加的，Claude Code 的安全是内建的。

第二，**BUDDY 是有策略的冒险**。在 CLI 工具里加虚拟宠物看起来像是工程师的恶搞，但代码质量（完整的动画系统、确定性生成、观察者角色）说明这是一个认真的产品决策。它解决的是 AI 工具"冷冰冰"的品牌问题。

第三，**KAIROS 生态的完整性做得不错**。自主运行（tick 循环）→ 定时触发（cron）→ 多渠道通知（channels）→ 外部事件响应（webhooks）→ 离线记忆整理（dream）——这不是在做功能，这是在搭平台。引用 154 次确认了它的核心地位。

最后，75 个 flag 带来的技术债不容忽视。Flag 爆炸是每个快速迭代的产品都会遇到的问题——关键是在正确的时间收敛到正确的子集。

---

*分析基于 Claude Code v2.1.42 源码。2026 年 4 月更新。部分功能的状态可能与当前发布版本有差异。*
*标注"待确认"的内容缺乏足够代码证据。所有产品判断均为分析推测，不代表 Anthropic 官方立场。*

## 二十、未公开 Slash 指令完整列表

以下是代码中发现的所有未公开 slash 指令，按功能分类：

### 主动 Agent 类（KAIROS 生态）
| 指令 | 功能 | Feature Flag |
|------|------|-------------|
| `/proactive` | 切换主动模式 | PROACTIVE/KAIROS |
| `/brief` | 生成项目简报 | KAIROS/KAIROS_BRIEF |
| `/assistant` | 进入 Kairos 助理模式 | KAIROS |
| `/subscribe-pr` | 订阅 GitHub PR 更新 | KAIROS_GITHUB_WEBHOOKS |

### 子 Agent 与任务类
| 指令 | 功能 | Feature Flag |
|------|------|-------------|
| `/fork` | 分叉子 Agent 处理独立任务 | FORK_SUBAGENT |
| `/ultraplan` | 生成超详细执行计划 | ULTRAPLAN |
| `/torch` | 分布式任务执行 | TORCH |

### 会话管理类
| 指令 | 功能 | Feature Flag |
|------|------|-------------|
| `/bridge` | 启动 IDE 桥接服务 | BRIDGE_MODE |
| `/remote-control-server` | 启动远程控制服务器 | DAEMON+BRIDGE_MODE |
| `/web` | 远程环境配置和管理 | CCR_REMOTE_SETUP |
| `/peers` | 管理对等 Agent 实例 | UDS_INBOX |
| `/workflows` | 管理工作流脚本 | WORKFLOW_SCRIPTS |

### 交互增强类
| 指令 | 功能 | Feature Flag |
|------|------|-------------|
| `/buddy` | 启用 AI 伙伴桌面精灵 | BUDDY |
| `/voice` | 语音输入模式 | VOICE_MODE |
| `/force-snip` | 强制裁剪历史对话 | HISTORY_SNIP |
| `/force-compact` | 强制压缩上下文 | REACTIVE_COMPACT |

### 内部调试类（仅 ant 用户）
| 指令 | 功能 |
|------|------|
| `/ctx-viz` | 上下文可视化 |
| `/break-cache` | 清除所有缓存 |
| `/bridge-kick` | 强制断开 IDE 桥接 |
| `/ant-trace` | 开启详细遥测追踪 |
| `/perf-issue` | 生成性能分析报告 |
| `/heapdump` | 导出内存堆快照 |
| `/mock-limits` | 模拟 API 限制 |