# 第23章：未发布功能管线 -- 89 个 Feature Flag 背后的路线图
> **定位**：本章分析 Claude Code 源码中 89 个 Feature Flag 门控的未发布功能管线及其实现深度。前置依赖：无，可独立阅读。适用场景：想了解 CC 如何通过 89 个 Feature Flag 管理未发布功能管线的读者，或想在自己的产品中实施特性标志系统的开发者。
## 为什么这很重要
在前面的 22 章中，我们分析的是 Claude Code 已发布的公开功能。但源码中还隐藏着另一个维度：**89 个 Feature Flag 门控着尚未向所有用户开放的功能**。这些 flag 通过 Bun 的构建时 `feature()` 函数实现——编译器在不同构建配置下将 `feature('FLAG_NAME')` 求值为 `true` 或 `false`，配合 dead code elimination 将未启用的代码分支完整移除。
这意味着源码中 `feature('KAIROS')` 门控的代码在公开构建中根本不存在——它只出现在内部构建（`USER_TYPE === 'ant'`）或实验分支中。但在我们还原的源码里，所有 flag 的两个分支都被保留了下来，为我们提供了一个独特的视角来审视 Claude Code 的功能演进方向。
本章将这 89 个 flag 按功能域分为五大类，分析核心未发布功能的实现深度和相互关系。需要强调的是：**本章的分析基于源码中可观测的实现状态，不猜测商业策略，不预测发布时间。** flag 的存在不等同于功能即将发布——许多 flag 可能是实验性的原型、A/B 测试配置、或已废弃的探索方向。
---
## 23.1 Feature Flag 机制
### 构建时求值
Claude Code 使用 Bun 的 `bun:bundle` 模块提供的 `feature()` 函数：
```typescript
import { feature } from 'bun:bundle'
if (feature('KAIROS')) {
const { registerDreamSkill } = require('./dream.js')
registerDreamSkill()
}
```
`feature()` 在构建时被替换为字面量 `true` 或 `false`。当结果为 `false` 时，整个 `if` 块在 tree-shaking 阶段被移除。这解释了为什么门控代码使用 `require()` 而非 `import()`——`require()` 是表达式，可以出现在 `if` 块内部，从而被 dead code elimination 连同其模块依赖一起消除。
### 引用计数与成熟度推断
通过统计每个 flag 在源码中的引用次数，可以粗略推断其实现深度：
| 引用次数范围 | 含义 | 典型 flag |
|-------------|------|-----------|
| 100+ | 深度集成，触及多个核心子系统 | KAIROS (154), TRANSCRIPT_CLASSIFIER (107) |
| 30-99 | 功能完整，已在多个模块中织入 | TEAMMEM (51), VOICE_MODE (46), PROACTIVE (37) |
| 10-29 | 功能较完整，涉及特定子系统 | CONTEXT_COLLAPSE (20), CHICAGO_MCP (16) |
| 3-9 | 初步实现或范围有限 | TOKEN_BUDGET (9), WEB_BROWSER_TOOL (4) |
| 1-2 | 原型/探索阶段或纯开关性质 | ULTRATHINK (1), ABLATION_BASELINE (1) |
**表 23-1：Feature Flag 引用次数与成熟度推断**
引用次数高不一定意味着"即将发布"——KAIROS 的 154 处引用可能恰恰说明它是一个长期演进的复杂系统，需要大量的渐进式集成。
---
## 23.2 全部 89 个 Flag 分类表
根据功能域，89 个 flag 可以分为五大类：
```mermaid
graph TD
ROOT["89 个 Feature Flag"] --> A["自主 Agent 与后台运行\n18 个 flag"]
ROOT --> B["远程控制与分布式执行\n14 个 flag"]
ROOT --> C["上下文管理与性能优化\n17 个 flag"]
ROOT --> D["记忆与知识管理\n9 个 flag"]
ROOT --> E["UI/UX 与平台能力\n31 个 flag"]
A --> A1["KAIROS (154)"]
A --> A2["COORDINATOR_MODE (32)"]
A --> A3["PROACTIVE (37)"]
B --> B1["BRIDGE_MODE (28)"]
B --> B2["UDS_INBOX (17)"]
C --> C1["TRANSCRIPT_CLASSIFIER (107)"]
C --> C2["BASH_CLASSIFIER (45)"]
D --> D1["TEAMMEM (51)"]
D --> D2["EXPERIMENTAL_SKILL_SEARCH (21)"]
E --> E1["VOICE_MODE (46)"]
E --> E2["CHICAGO_MCP (16)"]
style ROOT fill:#f9f,stroke:#333,stroke-width:2px
style A fill:#e3f2fd
style B fill:#e8f5e9
style C fill:#fff3e0
style D fill:#fce4ec
style E fill:#f3e5f5
```
### 表 23-2：自主 Agent 与后台运行（18 个）
| Flag | 引用数 | 功能描述 |
|------|--------|----------|
| `KAIROS` | 154 | 助手模式核心：后台自主 agent、tick 唤醒机制 |
| `PROACTIVE` | 37 | 自主工作模式：终端焦点感知、主动行动 |
| `KAIROS_BRIEF` | 39 | 简报模式：向用户发送进度消息 |
| `KAIROS_CHANNELS` | 19 | 频道系统：多通道通信 |
| `KAIROS_DREAM` | 1 | autoDream 记忆整理触发 |
| `KAIROS_PUSH_NOTIFICATION` | 4 | 推送通知：向用户推送状态更新 |
| `KAIROS_GITHUB_WEBHOOKS` | 3 | GitHub Webhook 订阅：PR 事件触发 |
| `AGENT_TRIGGERS` | 11 | 定时触发器（本地 cron） |
| `AGENT_TRIGGERS_REMOTE` | 2 | 远程定时触发器（云端 cron） |
| `BG_SESSIONS` | 11 | 后台会话管理（ps/logs/attach/kill） |
| `COORDINATOR_MODE` | 32 | 协调器模式：跨 agent 任务协调 |
| `BUDDY` | 15 | 伴侣模式：浮动 UI 气泡 |
| `ULTRAPLAN` | 10 | 超级计划：结构化任务分解 UI |
| `VERIFICATION_AGENT` | 4 | 验证 agent：自动验证任务完成状态 |
| `BUILTIN_EXPLORE_PLAN_AGENTS` | 1 | 内置探索/计划 agent 类型 |
| `FORK_SUBAGENT` | 4 | 子 agent fork 执行模式 |
| `MONITOR_TOOL` | 13 | 监控工具：后台进程监控 |
| `TORCH` | 1 | Torch 命令（功能不明） |
### 表 23-3：远程控制与分布式执行（14 个）
| Flag | 引用数 | 功能描述 |
|------|--------|----------|
| `BRIDGE_MODE` | 28 | 桥接模式核心：远程控制协议 |
| `DAEMON` | 3 | 守护进程模式：后台运行 daemon worker |
| `SSH_REMOTE` | 4 | SSH 远程连接 |
| `DIRECT_CONNECT` | 5 | 直连模式 |
| `CCR_AUTO_CONNECT` | 3 | Claude Code Remote 自动连接 |
| `CCR_MIRROR` | 4 | CCR 镜像模式：只读远程镜像 |
| `CCR_REMOTE_SETUP` | 1 | CCR 远程设置命令 |
| `SELF_HOSTED_RUNNER` | 1 | 自托管运行器 |
| `BYOC_ENVIRONMENT_RUNNER` | 1 | 自带计算环境运行器 |
| `UDS_INBOX` | 17 | Unix Domain Socket 收件箱：进程间通信 |
| `LODESTONE` | 6 | 协议注册（lodestone:// handler） |
| `CONNECTOR_TEXT` | 7 | 连接器文本块处理 |
| `DOWNLOAD_USER_SETTINGS` | 5 | 从云端下载用户配置 |
| `UPLOAD_USER_SETTINGS` | 2 | 上传用户配置到云端 |
### 表 23-4：上下文管理与性能优化（17 个）
| Flag | 引用数 | 功能描述 |
|------|--------|----------|
| `CONTEXT_COLLAPSE` | 20 | 上下文折叠：精细化上下文管理 |
| `REACTIVE_COMPACT` | 4 | 响应式压缩：按需触发 compact |
| `CACHED_MICROCOMPACT` | 12 | 缓存微压缩策略 |
| `COMPACTION_REMINDERS` | 1 | 压缩提醒机制 |
| `TOKEN_BUDGET` | 9 | Token 预算追踪 UI 和预算控制 |
| `PROMPT_CACHE_BREAK_DETECTION` | 9 | Prompt Cache 断裂检测 |
| `HISTORY_SNIP` | 15 | 历史截断命令 |
| `BREAK_CACHE_COMMAND` | 2 | 强制打断缓存命令 |
| `ULTRATHINK` | 1 | 超级思考模式 |
| `TREE_SITTER_BASH` | 3 | Tree-sitter Bash 解析器 |
| `TREE_SITTER_BASH_SHADOW` | 5 | Tree-sitter Bash 影子模式（A/B 测试） |
| `BASH_CLASSIFIER` | 45 | Bash 命令分类器 |
| `TRANSCRIPT_CLASSIFIER` | 107 | 会话记录分类器（auto 模式） |
| `STREAMLINED_OUTPUT` | 1 | 精简输出模式 |
| `ABLATION_BASELINE` | 1 | 消融实验基线 |
| `FILE_PERSISTENCE` | 3 | 文件持久化计时 |
| `OVERFLOW_TEST_TOOL` | 2 | 溢出测试工具 |
### 表 23-5：记忆与知识管理（9 个）
| Flag | 引用数 | 功能描述 |
|------|--------|----------|
| `TEAMMEM` | 51 | 团队记忆同步 |
| `EXTRACT_MEMORIES` | 7 | 自动记忆提取 |
| `AGENT_MEMORY_SNAPSHOT` | 2 | Agent 记忆快照 |
| `AWAY_SUMMARY` | 2 | 离开摘要：用户离开时生成进度摘要 |
| `MEMORY_SHAPE_TELEMETRY` | 3 | 记忆结构遥测 |
| `SKILL_IMPROVEMENT` | 1 | 技能自动改进（后采样钩子） |
| `RUN_SKILL_GENERATOR` | 1 | 技能生成器 |
| `EXPERIMENTAL_SKILL_SEARCH` | 21 | 实验性远程技能搜索 |
| `MCP_SKILLS` | 9 | MCP 服务器技能发现 |
### 表 23-6：UI/UX 与平台能力（31 个）
| Flag | 引用数 | 功能描述 |
|------|--------|----------|
| `VOICE_MODE` | 46 | 语音模式：流式语音转文字 |
| `WEB_BROWSER_TOOL` | 4 | Web 浏览器工具（Bun WebView） |
| `TERMINAL_PANEL` | 4 | 终端面板 |
| `HISTORY_PICKER` | 4 | 历史选择器 UI |
| `MESSAGE_ACTIONS` | 5 | 消息操作（复制/编辑快捷键） |
| `QUICK_SEARCH` | 5 | 快速搜索 UI |
| `AUTO_THEME` | 2 | 自动主题切换 |
| `NATIVE_CLIPBOARD_IMAGE` | 2 | 原生剪贴板图片支持 |
| `NATIVE_CLIENT_ATTESTATION` | 1 | 原生客户端认证 |
| `POWERSHELL_AUTO_MODE` | 2 | PowerShell 自动模式 |
| `CHICAGO_MCP` | 16 | Computer Use MCP 集成 |
| `MCP_RICH_OUTPUT` | 3 | MCP 富文本输出 |
| `TEMPLATES` | 6 | 任务模板/分类 |
| `WORKFLOW_SCRIPTS` | 10 | 工作流脚本 |
| `REVIEW_ARTIFACT` | 4 | 审查工件 |
| `BUILDING_CLAUDE_APPS` | 1 | 构建 Claude Apps 技能 |
| `COMMIT_ATTRIBUTION` | 12 | Git 提交归属追踪 |
| `HOOK_PROMPTS` | 1 | 钩子提示词 |
| `NEW_INIT` | 2 | 新版初始化流程 |
| `HARD_FAIL` | 2 | 硬失败模式 |
| `SHOT_STATS` | 10 | 工具调用统计分布 |
| `ANTI_DISTILLATION_CC` | 1 | 反蒸馏保护 |
| `COWORKER_TYPE_TELEMETRY` | 2 | 协作者类型遥测 |
| `ENHANCED_TELEMETRY_BETA` | 2 | 增强遥测 Beta |
| `PERFETTO_TRACING` | 1 | Perfetto 性能追踪 |
| `SLOW_OPERATION_LOGGING` | 1 | 慢操作日志 |
| `DUMP_SYSTEM_PROMPT` | 1 | 导出系统提示词 |
| `ALLOW_TEST_VERSIONS` | 2 | 允许测试版本 |
| `UNATTENDED_RETRY` | 1 | 无人值守重试 |
| `IS_LIBC_GLIBC` | 1 | glibc 运行时检测 |
| `IS_LIBC_MUSL` | 1 | musl 运行时检测 |
---
## 23.3 核心未发布功能深度分析
### KAIROS：后台自主助手
KAIROS 是引用次数最多的 flag（154 处），其代码痕迹触及了 Claude Code 几乎所有核心子系统。从源码分析可以还原出以下架构：
```mermaid
graph TD
AM["Assistant Module"] --> GATE["Gate Module\n(kairosGate)"]
GATE --> ACTIVATE["Activation Path"]
AM --> MODE["Assistant Mode\n独立会话模式"]
AM --> TICK["Tick Wakeup\n定时唤醒"]
AM --> BRIEF["Brief Tool\n简报/进度标记"]
AM --> CH["Channels\n多通道通信"]
AM --> DREAM["Dream\n空闲记忆整理"]
AM --> PUSH["Push Notification\n状态推送"]
AM --> GH["GitHub Webhooks\nPR 事件订阅"]
TICK --> PRO["Proactive Module"]
PRO --> CHECK{"terminalFocus?"}
CHECK -->|"用户不在看终端"| AUTO["Agent 自主执行"]
CHECK -->|"用户在看终端"| WAIT["等待用户输入"]
style AM fill:#e1f5fe,stroke:#333,stroke-width:2px
style PRO fill:#fff3e0
style AUTO fill:#c8e6c9
```
**图 23-1：KAIROS 助手模式架构图**
KAIROS 的核心理念可以从以下代码模式中推断：
**入口点**（`main.tsx:80-81`）：
```typescript
const assistantModule = feature('KAIROS')
? require('./assistant/index.js') as typeof import('./assistant/index.js')
: null
const kairosGate = feature('KAIROS')
? require('./assistant/gate.js') as typeof import('./assistant/gate.js')
: null
```
**Tick 唤醒机制**（`REPL.tsx:2115, 2605, 2634, 2738`）：KAIROS 在多个 REPL 生命周期点检查是否应该"唤醒"——包括消息处理后、输入空闲时、以及终端焦点变化时。当用户离开终端时（`!terminalFocusRef.current`），系统可以自主执行等待中的任务。
**Brief Tool 集成**（`main.tsx:2201`）：
```typescript
const briefVisibility = feature('KAIROS') || feature('KAIROS_BRIEF')
? isBriefEnabled()
? 'Call SendUserMessage at checkpoints to mark where things stand.'
: 'The user will see any text you output.'
: 'The user will see any text you output.'
```
当 Brief 模式启用时，系统提示词指导模型使用 `SendUserMessage` 在关键检查点向用户报告进度——而不是输出所有中间文本。这是为后台自主执行设计的通信模式。
**Team Context**（`main.tsx:3035`）：
```typescript
teamContext: feature('KAIROS')
? assistantTeamContext ?? computeInitialTeamContext?.()
: computeInitialTeamContext?.()
```
KAIROS 引入了"团队上下文"概念——当 agent 作为助手模式运行时，它需要理解自己在更大协作图中的位置。
### PROACTIVE 模式
PROACTIVE（37 处引用）与 KAIROS 高度耦合——在源码中，两者几乎总是以 `feature('PROACTIVE') || feature('KAIROS')` 的形式出现（`REPL.tsx:194, 2115, 2605` 等）。这暗示 PROACTIVE 是 KAIROS 的一个子功能或前身——当 KAIROS 的完整助手模式不可用时，PROACTIVE 提供了一个较轻量的"主动工作"能力。
关键行为差异在 `REPL.tsx:2776`：
```typescript
...((feature('PROACTIVE') || feature('KAIROS'))
&& proactiveModule?.isProactiveActive()
&& !terminalFocusRef.current
? { /* 自主执行配置 */ }
: {})
```
条件组合 `isProactiveActive() && !terminalFocusRef.current` 揭示了核心机制：**当用户不在看终端，且 proactive 模式已激活时，agent 获得自主执行权限**。这是一个基于物理注意力信号的权限升级——用户的终端焦点状态成为了 agent 自主性的门控条件。
### VOICE_MODE：流式语音转文字
VOICE_MODE（46 处引用）的实现触及了输入、配置、快捷键和服务层：
**语音 STT 服务**（`services/voiceStreamSTT.ts:3`）：
```typescript
// Only reachable in ant builds (gated by feature('VOICE_MODE') in useVoice.ts import).
```
**快捷键绑定**（`keybindings/defaultBindings.ts:96`）：
```typescript
...(feature('VOICE_MODE') ? { space: 'voice:pushToTalk' } : {})
```
空格键被绑定为 push-to-talk——这是语音输入的标准交互模式。语音集成涉及 `useVoiceIntegration.tsx` 中的多个 hook：`useVoiceEnabled`, `useVoiceState`, `useVoiceInterimTranscript`，以及 `startVoice`/`stopVoice`/`toggleVoice` 控制函数。
**配置集成**（`tools/ConfigTool/supportedSettings.ts:144`）：voice 作为可配置的设置项注册，支持通过 `/config set voiceEnabled true` 启用。
### WEB_BROWSER_TOOL：Bun WebView
WEB_BROWSER_TOOL（4 处引用）的实现痕迹虽少但关键：
```typescript
// main.tsx:1571
const hint = feature('WEB_BROWSER_TOOL')
&& typeof Bun !== 'undefined' && 'WebView' in Bun
? CLAUDE_IN_CHROME_SKILL_HINT_WITH_WEBBROWSER
: CLAUDE_IN_CHROME_SKILL_HINT
```
这行代码揭示了技术选型：web 浏览器工具基于 **Bun 内置的 WebView**，而非 Playwright 或 Puppeteer 这样的外部浏览器自动化工具。`typeof Bun !== 'undefined' && 'WebView' in Bun` 的运行时检测说明这依赖于 Bun 尚未稳定的 WebView API。
在 REPL 中（`REPL.tsx:272, 4585`），WebBrowserTool 有自己的面板组件 `WebBrowserPanel`，可以在全屏模式下与主对话并排显示。
### BRIDGE_MODE + DAEMON：远程控制
BRIDGE_MODE（28 处引用）和 DAEMON（3 处引用）构成了远程控制的基础设施：
**入口点**（`entrypoints/cli.tsx:100-165`）：
```typescript
if (feature('DAEMON') && args[0] === '--daemon-worker') {
// 启动守护进程 worker
}
if (feature('BRIDGE_MODE') && (args[0] === 'remote-control' || args[0] === 'rc'
|| args[0] === 'remote' || args[0] === 'sync' || args[0] === 'bridge')) {
// 启动远程控制/桥接
}
if (feature('DAEMON') && args[0] === 'daemon') {
// 启动 daemon 进程
}
```
DAEMON 提供了 `--daemon-worker` 后台工作进程和 `daemon` 管理命令。BRIDGE_MODE 提供了多个子命令别名（`remote-control`、`rc`、`remote`、`sync`、`bridge`）——这种别名丰富度暗示团队仍在探索最佳的用户界面命名。
桥接核心在 `bridge/bridgeEnabled.ts` 中，提供了多个检查函数：
```typescript
// bridge/bridgeEnabled.ts:32
return feature('BRIDGE_MODE') // isBridgeEnabled
// bridge/bridgeEnabled.ts:51
return feature('BRIDGE_MODE') // isBridgeOutboundEnabled
// bridge/bridgeEnabled.ts:127
return feature('BRIDGE_MODE') // isRemoteControlEnabled
```
CCR_MIRROR（4 处引用）是 BRIDGE_MODE 的一个子模式——只读镜像，允许远程观察而不控制。
### TRANSCRIPT_CLASSIFIER：auto 模式
TRANSCRIPT_CLASSIFIER（107 处引用）是引用数第二多的 flag，它实现了一个全新的权限模式——`auto`：
```typescript
// types/permissions.ts:35
...(feature('TRANSCRIPT_CLASSIFIER') ? (['auto'] as const) : ([] as const))
```
在现有的 `plan`（需确认每个工具调用）和 `auto-accept`（自动接受所有）之间，`auto` 模式引入了一个基于**会话记录分类**的中间地带。系统使用分类器分析会话内容来动态决定是否需要用户确认。
`checkAndDisableAutoModeIfNeeded`（`REPL.tsx:2772`）暗示 auto 模式有安全降级机制——当分类器检测到风险操作时，可以自动退出 auto 模式回到需要确认的状态。
BASH_CLASSIFIER（45 处引用）是 TRANSCRIPT_CLASSIFIER 的一个相关组件，专门用于 Bash 命令的分类和安全评估。
### CONTEXT_COLLAPSE：精细化上下文管理
CONTEXT_COLLAPSE（20 处引用）深度集成在 compact 子系统中：
```typescript
// services/compact/autoCompact.ts:179
if (feature('CONTEXT_COLLAPSE')) { ... }
// services/compact/autoCompact.ts:215
if (feature('CONTEXT_COLLAPSE')) { ... }
```
从集成点来看，CONTEXT_COLLAPSE 在 autoCompact、postCompactCleanup、sessionRestore 和 query 引擎中都有存在。它引入了一个 `CtxInspectTool`（`tools.ts:110`），允许模型主动检查和管理上下文窗口的状态。与当前的全量压缩不同，CONTEXT_COLLAPSE 可能实现了更精细的"折叠"语义——可以选择性地折叠某些工具调用的结果，而保留其他关键上下文。
REACTIVE_COMPACT（4 处引用）是另一个压缩实验——响应式触发，而非基于 token 阈值的定时触发。
### TEAMMEM：团队记忆同步
TEAMMEM（51 处引用）实现了跨会话的团队知识同步：
```typescript
// services/teamMemorySync/watcher.ts:253
if (!feature('TEAMMEM')) { return }
```
团队记忆系统包含三个核心组件：
1. **watcher**（`teamMemorySync/watcher.ts`）：监视团队记忆文件的变化
2. **secretGuard**（`teamMemSecretGuard.ts`）：防止敏感信息泄漏到团队记忆中
3. **memdir 集成**（`memdir/memdir.ts`）：将团队记忆层纳入 memdir 路径系统
从引用模式来看，TEAMMEM 的实现相当成熟——51 处引用覆盖了记忆读写、提示词构建、secret 扫描和文件同步等完整流程。
---
## 23.4 从 Flag 集群推断系统演进方向
### 集群一：自主 Agent 生态
KAIROS + PROACTIVE + KAIROS_BRIEF + KAIROS_CHANNELS + KAIROS_DREAM + KAIROS_PUSH_NOTIFICATION + KAIROS_GITHUB_WEBHOOKS + AGENT_TRIGGERS + AGENT_TRIGGERS_REMOTE + BG_SESSIONS + COORDINATOR_MODE + BUDDY + ULTRAPLAN + VERIFICATION_AGENT + MONITOR_TOOL
这是最大的 flag 集群（15+ 个），其逻辑关系可以还原为：
```
KAIROS (核心)
│
┌─────────────┼──────────────┐
│ │ │
PROACTIVE KAIROS_BRIEF KAIROS_DREAM
(自主执行权) (简报通信) (空闲记忆整理)
│ │
│ ┌────┴────┐
│ │ │
│ CHANNELS PUSH_NOTIFICATION
│ (多通道) (状态推送)
│
┌────┴────┐
│ │
BG_SESSIONS AGENT_TRIGGERS
(后台会话) (定时触发)
│ │
│ AGENT_TRIGGERS_REMOTE
│ (远程触发)
│
COORDINATOR_MODE ── ULTRAPLAN
(跨 agent 协调) (结构化计划)
│
│
BUDDY VERIFICATION_AGENT
(伴侣 UI) (自动验证)
│
MONITOR_TOOL
(进程监控)
```
**图 23-2：自主 Agent Flag 集群关系图**
这个集群描绘了一个从"被动响应用户输入"到"主动在后台持续工作"的演进路径。KAIROS 是核心引擎，PROACTIVE 提供焦点感知的自主权，AGENT_TRIGGERS 提供定时唤醒，BG_SESSIONS 提供后台持久化，COORDINATOR_MODE 提供多 agent 编排。
### 集群二：远程/分布式能力
BRIDGE_MODE + DAEMON + SSH_REMOTE + DIRECT_CONNECT + CCR_AUTO_CONNECT + CCR_MIRROR + CCR_REMOTE_SETUP + SELF_HOSTED_RUNNER + BYOC_ENVIRONMENT_RUNNER + LODESTONE
这个集群围绕"在用户之外的环境中运行 Claude Code"展开：
| 能力层 | Flag | 说明 |
|--------|------|------|
| 协议层 | LODESTONE | 注册 `lodestone://` 协议处理器 |
| 传输层 | BRIDGE_MODE, UDS_INBOX | WebSocket 桥接 + Unix Socket IPC |
| 连接层 | SSH_REMOTE, DIRECT_CONNECT | SSH 和直连两种接入方式 |
| 管理层 | CCR_AUTO_CONNECT, CCR_MIRROR | 自动连接、只读镜像 |
| 执行层 | DAEMON, SELF_HOSTED_RUNNER, BYOC | 守护进程、自托管、BYOC 运行器 |
| 同步层 | DOWNLOAD/UPLOAD_USER_SETTINGS | 配置云同步 |
**表 23-7：远程/分布式能力分层**
### 集群三：上下文智能
CONTEXT_COLLAPSE + REACTIVE_COMPACT + CACHED_MICROCOMPACT + COMPACTION_REMINDERS + TOKEN_BUDGET + PROMPT_CACHE_BREAK_DETECTION + HISTORY_SNIP
这些 flag 描述了对上下文管理的持续优化。与第9-12章分析的现有 compact 机制相比，这些 flag 代表了下一代上下文管理：
- **从定时压缩到响应式压缩**（REACTIVE_COMPACT）
- **从全量压缩到选择性折叠**（CONTEXT_COLLAPSE）
- **从被动到主动的缓存管理**（PROMPT_CACHE_BREAK_DETECTION）
- **从隐式到显式的预算控制**（TOKEN_BUDGET）
### 集群四：安全分类与权限
TRANSCRIPT_CLASSIFIER + BASH_CLASSIFIER + ANTI_DISTILLATION_CC + NATIVE_CLIENT_ATTESTATION + HARD_FAIL
这个集群围绕"更精细的安全控制"展开。TRANSCRIPT_CLASSIFIER 的 `auto` 模式是一个重要的方向——它代表了从"二元权限"（全部确认或全部接受）到"智能权限"（基于内容分析动态决策）的转变。ANTI_DISTILLATION_CC 则暗示了对模型输出的知识产权保护机制。
---
## 23.5 Flag 成熟度光谱
将 89 个 flag 按引用次数绘制成光谱，可以观察到几个有趣的分布特征：
```
引用数 Flag 数量 成熟度阶段
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
100+ 2 深度集成期 ██
30-99 6 全面织入期 ██████
10-29 12 模块集成期 ████████████
3-9 27 初步实现期 ███████████████████████████
1-2 42 原型探索期 ██████████████████████████████████████████
```
**图 23-3：89 个 Flag 的成熟度分布**
分布呈现明显的**长尾特征**：47% 的 flag（42 个）只有 1-2 处引用，处于原型或纯开关阶段。只有 2 个 flag 达到了 100+ 引用的深度集成状态。这符合软件产品的典型功能漏斗——大量探索性实验中，只有少数最终成为核心功能。
值得注意的是引用数与**跨模块分布**之间的区别。KAIROS 的 154 处引用分布在 `main.tsx`、`REPL.tsx`、`commands.ts`、`prompts.ts`、`print.ts`、`sessionStorage.ts` 等至少 15 个文件中——这种广泛的集成意味着启用 KAIROS 需要触及系统的多个切面。相比之下，TEAMMEM 虽然有 51 处引用，但主要集中在 `memdir/`、`teamMemorySync/` 和 `services/mcp/` 中——这种局部化的集成更容易被独立启用和测试。
---
## 23.6 构建配置推断
从 flag 的门控模式，可以推断出至少三种构建配置：
### 公开构建（Public Build）
绝大多数 flag 为 `false`。已知公开启用的功能（如基础技能系统、工具链）不需要 flag 门控——它们是源码的"默认路径"。
### 内部构建（Ant Build）
`USER_TYPE === 'ant'` 检查出现在多个技能的注册逻辑中（`verify.ts:13`、`remember.ts:5`、`stuck.ts` 等）。内部构建启用了更多的实验性功能，包括 EXPERIMENTAL_SKILL_SEARCH、SKILL_IMPROVEMENT 等。
### 实验构建（Experiment Build）
某些 flag 组合可能代表 A/B 测试配置——TREE_SITTER_BASH 和 TREE_SITTER_BASH_SHADOW 的命名模式暗示了一个"影子模式"实验：新的 Bash 解析器在后台运行并比较结果，但不影响用户可见的行为。类似地，ABLATION_BASELINE 明确标识了消融实验的基线配置。
---
## 23.7 未发布功能间的依赖关系
某些 flag 之间存在隐式依赖，可以从代码中的 `&&` 组合推断：
```typescript
// commands.ts:77
feature('DAEMON') && feature('BRIDGE_MODE') // daemon 依赖 bridge
// skills/bundled/index.ts:35
feature('KAIROS') || feature('KAIROS_DREAM') // dream 可独立于完整 KAIROS
// main.tsx:1728
(feature('KAIROS') || feature('KAIROS_BRIEF')) && baseTools.length > 0
// main.tsx:2184
(feature('KAIROS') || feature('KAIROS_BRIEF'))
&& !getIsNonInteractiveSession()
&& !getUserMsgOptIn()
&& getInitialSettings().defaultView === 'chat'
```
关键依赖关系：
| 依赖方 | 被依赖方 | 关系 |
|--------|----------|------|
| DAEMON | BRIDGE_MODE | 必须同时启用 |
| KAIROS_DREAM | KAIROS | 可独立，但通常共存 |
| KAIROS_BRIEF | KAIROS | 可独立启用 |
| KAIROS_CHANNELS | KAIROS | 通常共存 |
| CCR_MIRROR | BRIDGE_MODE | CCR_MIRROR 是 BRIDGE 的子模式 |
| CCR_AUTO_CONNECT | BRIDGE_MODE | 需要 Bridge 基础设施 |
| AGENT_TRIGGERS_REMOTE | AGENT_TRIGGERS | 远程是本地的扩展 |
| MCP_SKILLS | MCP 基础设施 | 扩展现有 MCP 客户端 |
**表 23-8：Flag 间主要依赖关系**
---
## 23.8 对现有架构的影响
这 89 个 flag 对现有架构的影响可以从几个层面理解：
### 上下文管理层
CONTEXT_COLLAPSE 和 REACTIVE_COMPACT 将改变我们在第9-11章分析的压缩机制。当前的 autoCompact 基于 token 阈值的定时检查可能被替换为更精细的响应式策略——在工具调用返回大量结果时立即触发局部折叠，而不是等到整体 token 数超过阈值。
### 权限层
TRANSCRIPT_CLASSIFIER 的 auto 模式代表了权限系统的一次范式转变。当前的二元模型（plan vs auto-accept）可能演进为三元模型，其中 auto 模式使用 ML 分类器实时评估每个操作的风险等级。
### 工具层
WEB_BROWSER_TOOL、TERMINAL_PANEL、MONITOR_TOOL 等新工具扩展了 agent 的感知和行动能力。特别是 WEB_BROWSER_TOOL 对 Bun WebView 的依赖，意味着浏览器能力将是原生集成的，而非通过外部进程（如 Playwright）实现。
### 执行模型层
KAIROS + DAEMON + BRIDGE_MODE 共同指向一个"后台持续运行"的执行模型——Claude Code 不再仅仅是一个交互式 REPL，而是可以作为守护进程在后台持续工作，通过 Bridge 远程控制，通过 Push Notification 报告进度。
---
## 模式提炼
从 Feature Flag 系统的设计中，可以提取以下可复用的模式：
**模式一：构建时 Dead Code Elimination**
- **解决的问题**：实验性代码不应出现在生产构建中
- **模式**：`feature('FLAG')` 在编译期被替换为字面量 `true`/`false`，`if (false) { require(...) }` 整个分支及其依赖被 tree-shaking 移除
- **前置条件**：构建工具支持编译期常量替换和 dead code elimination
**模式二：引用计数推断成熟度**
- **解决的问题**：在大型代码库中评估实验性功能的集成深度
- **模式**：统计 flag 在源码中的引用次数和跨模块分布——100+ 引用意味着深度集成，1-2 引用意味着原型阶段
- **前置条件**：flag 命名一致且通过统一 API 访问
**模式三：Flag 集群依赖管理**
- **解决的问题**：相关功能之间的启用顺序和依赖关系
- **模式**：通过 `feature('A') && feature('B')` 表达硬依赖，通过 `feature('A') || feature('B')` 表达软关联；子功能可独立于父功能启用（如 `KAIROS_DREAM` 可独立于完整 `KAIROS`）
- **前置条件**：功能之间存在层次化的依赖关系
---
## 用户能做什么
**理解 Feature Flag 以更好地使用 Claude Code：**
1. **检查可用的实验性功能**。部分 flag 通过环境变量暴露给用户——如 `CLAUDE_CODE_COORDINATOR_MODE` 控制协调者模式。查阅官方文档了解哪些实验性功能可以通过环境变量启用。
2. **理解构建版本的差异**。公开构建、内部构建（`USER_TYPE=ant`）和实验构建有不同的功能集。如果你在使用企业版或内部版本，可能有更多功能可用（如 `verify`、`remember`、`stuck` 等技能）。
3. **关注 KAIROS 相关的助手模式**。KAIROS 是引用最多的 flag（154 处），代表了 Claude Code 向"后台自主 agent"演进的方向。当这些功能逐步公开时，理解其终端焦点感知、定时唤醒、简报通信等机制有助于更好地利用它们。
4. **注意 auto 权限模式的出现**。TRANSCRIPT_CLASSIFIER 引入的 `auto` 权限模式是介于 `plan`（全部确认）和 `auto-accept`（全部接受）之间的智能中间地带。当它公开可用时，它可能是大多数用户的最佳默认选择。
5. **理解 Flag 的存在不等于功能承诺**。89 个 flag 中 47% 只有 1-2 处引用，处于原型阶段。不要基于源码中的 flag 存在来预期功能发布——flag 的本质是让团队安全地探索和实验。
---
## 23.9 小结
89 个 Feature Flag 揭示了 Claude Code 远超当前公开功能的工程深度。按功能域分类：
- **自主 Agent 生态**（18 个 flag）：以 KAIROS 为核心，构建后台自主执行、定时触发、多 agent 协调的完整能力栈
- **远程/分布式执行**（14 个 flag）：Bridge + Daemon + SSH/Direct Connect，实现跨机器的远程控制和分布式运行
- **上下文管理优化**（17 个 flag）：从定时全量压缩到响应式选择性折叠的演进
- **记忆与知识管理**（9 个 flag）：团队记忆同步、自动记忆提取、技能自我改进
- **UI/UX 与平台能力**（31 个 flag）：语音输入、浏览器集成、终端面板等新交互模态
从成熟度分布来看，KAIROS（154 引用）和 TRANSCRIPT_CLASSIFIER（107 引用）是最深度集成的两个系统——它们的代码痕迹已经深入 Claude Code 的核心架构。而 42 个只有 1-2 处引用的 flag 则代表了大量的探索性实验，其中大部分可能永远不会成为公开功能。
这些 flag 共同描绘了 Claude Code 从"交互式编码助手"向"后台自主开发 agent"演进的工程准备。不过，源码中的存在不等同于产品计划——feature flag 的本质是让团队能够安全地探索和实验，而不必承诺每个实验都将成为产品。
---
## 23.x Feature Flags 的生命周期
89 个 Feature Flag 不是静态列表——它们有明确的生命周期阶段。从 v2.1.88 到 v2.1.91 的版本对比可以观察到这个过程：
### 四阶段生命周期
```mermaid
graph LR
A[实验
tengu_xxx 创建] --> B[灰度
GrowthBook 配比]
B --> C[全量
代码硬编码 true]
C --> D[废弃
flag 移除]
```
| 阶段 | 特征 | v2.1.88→v2.1.91 实例 |
|------|------|---------------------|
| **实验** | `feature('FLAG_NAME')` 在代码中守卫功能块 | `TREE_SITTER_BASH_SHADOW`（影子测试 AST 解析） |
| **灰度** | GrowthBook 服务端控制开启比例 | `ULTRAPLAN`（远程规划，按订阅级别开放） |
| **全量** | `feature()` 调用被 DCE 消除或硬编码为 true | `TRANSCRIPT_CLASSIFIER`（v2.1.91 auto mode 公开化暗示已全量） |
| **废弃** | flag 和相关代码一起移除 | `TREE_SITTER_BASH`（v2.1.91 移除 tree-sitter） |
### GrowthBook 动态评估机制
Feature Flags 通过 GrowthBook SDK 在运行时评估（`restored-src/src/utils/growthbook.ts`）：
```typescript
// 两种读取模式
feature('FLAG_NAME') // 同步，使用本地缓存
getFeatureValue_CACHED_MAY_BE_STALE( // 异步，明确标注可能过期
'tengu_config_name', defaultValue
)
```
`_CACHED_MAY_BE_STALE` 后缀是刻意的命名设计——提醒调用者这个值可能不是最新的，不应用于需要强一致性的决策。CC 在 Ultraplan 的模型选择（`getUltraplanModel()`）和事件采样率（`shouldSampleEvent()`）中都使用了这种模式。
### v2.1.91 变化对照
| Flag | v2.1.88 状态 | v2.1.91 状态 | 阶段变化 |
|------|-------------|-------------|---------|
| `TREE_SITTER_BASH` | 实验（feature gate） | 移除 | 实验 → 废弃 |
| `TREE_SITTER_BASH_SHADOW` | 灰度（影子测试） | 移除 | 灰度 → 废弃 |
| `ULTRAPLAN` | 实验/灰度 | 灰度（+5 个新遥测事件） | 持续灰度 |
| `TRANSCRIPT_CLASSIFIER` | 灰度 | 可能全量（auto mode 公开化） | 灰度 → 全量？ |
| `TEAMMEM` | 灰度 | 灰度（`TENGU_HERRING_CLOCK`） | 持续灰度 |
### 版本追踪方法
无 source map 时，通过 `scripts/extract-signals.sh` 提取 GrowthBook 配置名变化可以间接推断 flag 生命周期——新增配置名 = 新实验，配置名消失 = 实验结束。详见附录 E 和 `docs/reverse-engineering-guide.md`。