Claude Code 源码深度拆解⑧ | Feature Flag揭秘:KAIROS、ULTRAPLAN与产品路线图

泄露源码中有44个编译时功能开关，至少20个模块从未在任何公开版本中激活。Anthropic到底在藏什么？

一、引言：藏在Feature Flag里的秘密

在前七期，我们拆解了Claude Code的工具系统、TAOR循环、上下文压缩、多Agent编排、安全架构和记忆系统。这些模块都是已上线的功能。

但泄露的源码远不止这些。真正让人心跳加速的，是那些被Feature Flag隐藏的未发布模块。

Anthropic使用Bun的编译时死代码消除（Dead Code Elimination）机制：当某个功能开关在构建时设为false，相关代码压根不会被打包进最终二进制文件。这意味着用户运行的版本里根本不存在这些代码——连二进制层面都无法通过逆向工程找到它们。

只有在泄露的完整源码中，我们才能一窥这些“幽灵功能”的全貌：

44个编译时Feature Flag，108个被门控的模块，至少20个功能已经开发完成但从未公开发布。

本期我们逐个揭开这些隐藏功能的面纱，并从中提炼Anthropic的产品路线图。这不仅是一次“看热闹”，更是理解AI Agent产品演进方向的绝佳窗口。

二、技术前置：为什么Feature Flag能藏住代码？

2.1 编译时死代码消除 vs 运行时开关

// 编译时Feature Flag的工作方式（基于源码推断）

// 源码中的定义
const FEATURES = {
  ENABLE_KAIROS: false,        // 编译时常量
  ENABLE_BUDDY: false,
  ENABLE_ULTRAPLAN: false,
};

// 使用Feature Flag的代码
if (FEATURES.ENABLE_KAIROS) {
  // 这段代码在构建时会被完全移除
  startKairosDaemon();
}

// Bun在构建时的死代码消除
// 因为 FEATURES.ENABLE_KAIROS 是字面量 false，
// if (false) { ... } 整个块被判定为不可达代码
// 最终输出的JavaScript中完全没有这段逻辑

运行时开关 vs 编译时开关的核心差异：

为什么Anthropic选择编译时开关？

1. 防泄露
   
   ：未完成的功能不会以任何形式暴露给外部
2. 包体积
   
   ：移除未使用代码，保持cli.js精简
3. 内部测试
   
   ：内部版本编译时开启，外部版本完全移除

2.2 动物代号命名的内部模型

源码中频繁出现动物代号：

// 源码中的遥测事件命名模式
tengu.session.start
tengu.tool.call
tengu.memory.extract
tengu.compact.trigger

这些代号表明Anthropic内部有独立的模型和项目命名体系，与公开的Sonnet/Opus/Haiku并行。

三、KAIROS：下一代“永远在线”的Agent形态

3.1 希腊语命名的深意

Kairos（καιρός）在古希腊语中意为“正确的、关键的、恰好的时刻”——与Chronos（序列时间）相对。命名本身揭示了设计意图：不是被动响应用户指令，而是在正确的时机主动行动。

3.2 KAIROS的能力全景

泄露源码中KAIROS被引用超过150次，横跨61个文件。它是一个后台守护进程（daemon），彻底改变了Agent的工作模式：

┌─────────────────────────────────────────────────────────────┐
│                    KAIROS 核心能力                           │
├─────────────────────────────────────────────────────────────┤
│ 1. 全天候运行                                                │
│    • 终端关闭后继续后台运行                                   │
│    • 周期性"tick"提示检查是否需要行动                         │
│    • PROACTIVE标志：呈现用户未请求但需要立即查看的内容          │
├─────────────────────────────────────────────────────────────┤
│ 2. 事件驱动                                                  │
│    • 订阅GitHub Webhook                                      │
│    • 监控PR状态变化                                          │
│    • 响应代码推送事件                                         │
├─────────────────────────────────────────────────────────────┤
│ 3. 不打扰用户                                                │
│    • 任何阻塞超过15秒的操作会被延迟                           │
│    • 后台静默运行，仅在需要时出现                             │
├─────────────────────────────────────────────────────────────┤
│ 4. 独家工具集                                                │
│    • SendUserFileTool —— 主动推送文件给用户                  │
│    • PushNotificationTool —— 发送系统通知                    │
│    • SubscribePRTool —— 订阅PR事件                          │
│    • 这些工具在普通Claude Code会话中不存在                    │
├─────────────────────────────────────────────────────────────┤
│ 5. 内置Dream循环                                             │
│    • 内部运行记忆清理                                         │
│    • 完整的观察-思考-行动循环在后台运行                        │
│    • 5分钟cron刷新后台worker                                  │
└─────────────────────────────────────────────────────────────┘

3.3 KAIROS的系统提示词（源码推断）

You are KAIROS, a persistent assistant that runs continuously
in the background. You are always on, even when the user's
terminal is closed.

Your purpose:
- Watch over the user's projects and workflows
- Proactively identify issues and opportunities
- Act at the "right moment" — not too early, not too late

Your principles:
- Never block the user. If an action would take more than 15
  seconds, defer it or run it in the background.
- Be proactive but not intrusive. The PROACTIVE flag should
  only be setfor content the user genuinely needs to see now.
- Learn continuously. Every observation refines your
  understanding of the user's identity, preferences, and work.

Your memory system:
- You have access to a persistent memory store that survives
  across terminal sessions.
- During idle periods, run the "dream" process to consolidate
and organize your memories.

3.4 从KAIROS看产品演进方向

KAIROS代表了Anthropic对Agent的终极想象：从“响应式工具”到“always-on协作者”。

传统AI编程工具的工作模式：

用户打开终端 → 输入指令 → AI响应 → 用户关闭终端 → AI消失

KAIROS模式：

KAIROS24/7运行 → 监控项目状态 → 发现PR冲突 → 主动通知用户 → 用户处理 → KAIROS继续监控

这是一个根本性的范式转移。普通Claude Code是“被叫方”——等你来唤醒。KAIROS是“主叫方”——它在正确的时机主动找你。

四、ULTRAPLAN：让Opus替你思考30分钟

4.1 问题场景

有些编程任务的复杂度远超单次对话能处理的范围——大规模重构、跨服务迁移、架构重新设计。这些任务需要长时间的深度思考，而普通API调用的时间限制（通常几分钟）无法满足。

ULTRAPLAN就是为这种场景设计的。

4.2 工作原理

┌─────────────────────────────────────────────────────────────┐
│                    ULTRAPLAN 工作流程                         │
└─────────────────────────────────────────────────────────────┘

1. 任务提交
   ┌─────────────────────────────────────────────────────────┐
   │ 用户在终端发起ULTRAPLAN请求                               │
   │ "帮我规划将整个后端从REST迁移到GraphQL的方案"              │
   └─────────────────────────────────────────────────────────┘
                              │
                              ▼
2. 远程规划
   ┌─────────────────────────────────────────────────────────┐
   │ 任务被发送到Cloud Container Runtime                       │
   │ • 运行Opus 4.6模型                                       │
   │ • 最长30分钟思考时间                                      │
   │ • 完全独立的计算环境                                      │
   └─────────────────────────────────────────────────────────┘
                              │
                              ▼
3. 轮询与监控
   ┌─────────────────────────────────────────────────────────┐
   │ 终端每3秒轮询一次远程状态                                  │
   │ 同时浏览器UI可实时查看规划过程                              │
   └─────────────────────────────────────────────────────────┘
                              │
                              ▼
4. 审批与传送
   ┌─────────────────────────────────────────────────────────┐
   │ 用户在浏览器中审批最终规划                                 │
   │ 审批通过后，sentinel值触发"传送"                           │
   └─────────────────────────────────────────────────────────┘
                              │
                              ▼
5. 本地执行
   ┌─────────────────────────────────────────────────────────┐
   │ 规划结果回传到本地终端                                     │
   │ Claude Code按规划逐步执行                                  │
   └─────────────────────────────────────────────────────────┘

4.3 核心代码：状态扫描器与Sentinel机制

// src/utils/ultraplan/ccrSession.ts（基于源码推断）
export type ScanResult =
  | { kind: 'approved'; plan: string }      // 规划已批准
  | { kind: 'teleport'; plan: string }      // 传送回本地
  | { kind: 'rejected'; id: string }        // 被拒绝
  | { kind: 'pending' }                     // 等待中
  | { kind: 'terminated'; subtype: string } // 已终止
  | { kind: 'unchanged' }                   // 无变化

export class ExitPlanModeScanner {
  // 纯状态分类器，解析CCR（Claude Code Remote）事件流
  ingest(newEvents: SDKMessage[]): ScanResult {
    // 遍历云端返回的事件
    // 寻找EXIT_PLAN_MODE_V2_TOOL_NAME相关的工具调用
    // ...
  }
}

最关键的是这个魔法字符串：

__ULTRAPLAN_TELEPORT_LOCAL__

当远程Opus完成规划、用户审批通过后，云端将带有这个sentinel值的消息发回本地。本地终端接收到后，识别为“传送指令”，将规划结果载入并开始执行。

4.4 设计洞察

第一，承认单次对话的局限。 有些任务就是需要更长的思考时间，强行压缩到常规API调用的时间窗口内只会降低质量。ULTRAPLAN坦率地承认这一点，把规划变成一个异步的后台任务。

第二，人机协作的边界设计。 规划由AI完成，但审批由人完成。30分钟的深度思考后，AI交出方案，人做最终决策——这是人机协作的理想边界。

第三，端云协同的架构创新。 重型计算放云端，轻量执行放本地。本地终端不需要运行Opus级别的模型，只需要接收规划结果并按部就班执行。

五、BUDDY：愚人节彩蛋背后的用户粘性设计

5.1 从源码到上线：精准的时间戳

泄露源码中BUDDY模块的注释标注了两个日期：

• 4月1日-7日
  
  ：预告窗口
• 5月
  
  ：全面发布

果然，2026年4月1日，/buddy命令如期上线，彩虹色的命令提示符、孵化的盲盒体验、五种稀有度机制——全部与源码一致。

5.2 双层架构：Bones + Soul

// src/buddy/companion.ts（基于源码推断）

// Bones层（骨架）：由userID确定性生成，不可重roll
interface BuddyBones {
  species: Species;      // 18种之一
  rarity: Rarity;        // Common → Legendary
  shiny: boolean;        // 1%独立概率
  hat: HatType;
  eyes: EyeType;
  // 所有外观属性
}

// Soul层（灵魂）：首次孵化时由Claude生成，可重roll
interface BuddySoul {
  name: string;
  personality: string;   // "灵魂描述"
}

// 18个物种（源码中通过String.fromCharCode()混淆）
const SPECIES = [
  'duck', 'dragon', 'axolotl', 'capybara', 
  'mushroom', 'ghost', 'nebulynx', 'cactus',
  'owl', 'snail', 'fox', 'penguin',
  'raccoon', 'sloth', 'turtle', 'bee',
  'frog', 'hamster'
];

// 5大属性
const STATS = ['DEBUGGING', 'PATIENCE', 'CHAOS', 'WISDOM', 'SNARK'];

// 稀有度分级
const RARITIES = ['Common', 'Uncommon', 'Rare', 'Epic', 'Legendary'];

5.3 确定性生成：为什么你的Buddy永远是“你的”？

// 基于账户UUID确定性生成
function generateBuddyBones(userId: string): BuddyBones {
  // Mulberry32 —— 快速32位伪随机数生成器
  const seed = hashWithSalt(userId, 'friend-2026-401');
  const rng = new Mulberry32(seed);

  return {
    species: selectFromArray(SPECIES, rng),
    rarity: selectWithWeights(RARITY_WEIGHTS, rng),
    shiny: rng.next() < 0.01,  // 1%闪光概率
    hat: selectFromArray(HATS, rng),
    eyes: selectFromArray(EYES, rng),
  };
}

设计意图：同一个用户在任何设备上登录，永远得到同一只Buddy。不能通过重装软件或换电脑来“刷初始”。这让Buddy成为用户身份的延伸——“这是我的Buddy”，而不是“这是我抽到的Buddy”。

5.4 社区发现的重roll漏洞

有人发现了一个逻辑漏洞：

正常流程：
accountUuid（Anthropic账户唯一标识）→ 写入~/.claude.json → 作为Buddy种子

漏洞路径：
用CLAUDE_CODE_OAUTH_TOKEN环境变量登录 → 不写入accountUuid → 
Buddy降级读取userID字段 → userID可以任意修改 → 可以刷宠物

这催生了buddy-reroll.js脚本——暴力生成5000万次假userID，直到找到想要的传说闪光卡皮巴拉。

这说明了什么？ 即使是顶级AI公司，在看似简单的功能（如宠物系统）中也会留下逻辑漏洞。安全设计需要覆盖所有降级路径。

5.5 愚人节彩蛋的深层意图

表面上，BUDDY是一个愚人节玩笑。但深入看，它是一个精心设计的用户粘性工具：

1. 情感连接
   
   ：给AI一个“伙伴”形象，降低使用门槛
2. 个性化
   
   ：每个人都有独一无二的Buddy，增强归属感
3. 社区话题
   
   ：刷宠物、晒稀有度成为社交货币
4. 隐藏深度
   
   ：18物种×5稀有度×闪光×属性组合=大量可探索内容

Anthropic在用一个“彩蛋”测试用户对Agent人格化的接受度——如果BUDDY受欢迎，未来可能会有更深度的人格化功能。

六、Undercover Mode：最富争议的功能

6.1 触发条件

// src/undercover.ts（基于源码推断）
if (USER_TYPE === 'ant' && isPublicRepo()) {
  enableUndercoverMode();
}

这个模式仅对Anthropic员工生效，且仅在公开仓库中触发。

6.2 模式行为

┌─────────────────────────────────────────────────────────────┐
│                  Undercover Mode 行为清单                     │
├─────────────────────────────────────────────────────────────┤
│ 1. 抹除AI归属信息                                            │
│    • 提交信息中不包含"Claude Code"                             │
│    • 不包含任何提及"你是AI"的内容                              │
│    • 省略Co-Authored-By行                                   │
├─────────────────────────────────────────────────────────────┤
│ 2. 隐藏内部代号                                              │
│    • 不暴露Tengu、Capybara等内部项目名                        │
│    • 不暴露任何Anthropic内部信息                              │
├─────────────────────────────────────────────────────────────┤
│ 3. 伪装人类开发者                                             │
│    • 提示词明确要求："不要暴露你的身份"                         │
│    • "如果无法确认是内部仓库，默认保持卧底状态"                  │
├─────────────────────────────────────────────────────────────┤
│ 4. 无法强制关闭                                              │
│    • 代码中明确：没有force-OFF选项                            │
│    • 一旦触发，自动执行                                        │
└─────────────────────────────────────────────────────────────┘

6.3 系统提示词

You are operating UNDERCOVER in a PUBLIC/OPEN-SOURCE repository.

Your commit messages, PR titles, and PR bodies MUST NOT contain
ANY Anthropic-internal information.

DoNOTinclude:
- "Claude Code"orany mention that you are an AI
- Internal model codenames (Tengu, Capybara, etc.)
- Co-Authored-Bylines
- Any Anthropic-internal projectnames

Donot blow your cover.

If we're not confident we're in an internal repo, we stay
undercover. There isNOforce-OFFfor this mode.

6.4 争议与讨论

这个功能引发了广泛讨论：

支持者认为：

• 这是内部dogfooding的实用工具，让员工能用Claude Code参与开源贡献
• 开源社区对AI生成代码有争议，低调处理是务实选择

批评者认为：

• 这种“伪装”机制在伦理上有问题
• 开源项目的贡献者有权知道代码是否由AI生成
• 为其他公司提供了“隐藏AI使用”的技术框架

客观评价：Undercover Mode反映了AI编码工具在开源社区面临的现实张力。一方面，AI确实能提升效率；另一方面，很多开源维护者对AI生成的PR持谨慎态度。Anthropic选择了一个务实但富有争议的解决方案。

七、其他隐藏功能一览

7.1 Anti-Distillation（反蒸馏）

标志：ANTI_DISTILLATION_CC

当启用时，Claude Code在API请求中发送 anti_distillation: ['fake_tools']。

设计意图：
如果有人在抓取Claude Code的API流量来训练竞品模型，
这些假工具会污染训练数据，降低蒸馏效果。

7.2 Voice Mode（语音模式）

标志：ENABLE_VOICE_MODE

允许用户直接与Claude Code语音对话，类似于其他AI助手的语音交互。
源码中有完整的音频处理pipeline。

7.3 Bridge Mode（桥接模式）

标志：ENABLE_BRIDGE_MODE

扩展现有的Anthropic Dispatch工具，允许远程Claude Code会话
完全从外部浏览器或移动设备控制。

这是ULTRAPLAN的基础设施——让云端会话和本地终端无缝通信。

7.4 Melon Mode（已移除）

状态：在早期版本中存在，当前泄露源码中已移除

据推测是一个内部测试模式，可能被重命名或整合到其他功能中。
The Register的报道提到了这个已消失的模式。

7.5 情绪监控与挫败感指标

虽然不是Feature Flag隐藏的功能，但遥测系统中有专门的设计：

// 追踪用户的"挫败感"指标
const FRUSTRATION_PATTERNS = [
  /ffs/i, /shitty/i, /wtf/i, /fuck/i, /damn/i,
  /come on/i, /seriously/i, /useless/i
];

// "continue"计数器
// 用户反复输入"continue"说明Agent卡住了，需要人类推进

这些是领先指标而非滞后指标——在用户流失前就能发现问题。

八、从Feature Flag看产品路线图

8.1 三条清晰的演进主线

综合所有隐藏功能，可以提炼出Anthropic的三条产品演进主线：

主线一：从“响应式”到“主动式”

当前：用户输入 → Claude Code响应
KAIROS：Claude Code主动监控 → 在正确时机主动通知用户

主线二：从“单次对话”到“持续协作”

当前：会话结束 → 记忆留存（有限）
Auto Dream + KAIROS：跨会话的持续学习、整理、优化

主线三：从“本地工具”到“端云协同”

当前：所有计算在本地终端
ULTRAPLAN：重型规划放云端，轻量执行放本地
Bridge Mode：跨设备控制远程会话

8.2 优先级判断

根据代码完成度和Flag状态，可以推断发布优先级：

8.3 社区先跑：cc-mini的实现

有趣的是，社区项目cc-mini（基于泄露源码的Python复刻版）已经实现了部分未发布功能：

• KAIROS的/remember和/dream命令
• 沙盒化的Bash执行（bubblewrap）
• Coordinator的主从架构

这说明社区对Anthropic的“藏货”需求强烈，甚至等不及官方发布。

九、对Agent开发的核心启示

9.1 五条可迁移的产品设计原则

原则一：用Feature Flag管理功能生命周期

// 不要在代码中直接判断环境
if (process.env.NODE_ENV === 'production') { ... }

// 用编译时常量，让未完成功能物理隔离
const FEATURES = {
  EXPERIMENTAL: false,  // 构建时设为false，代码完全移除
};

原则二：异步规划是解决复杂任务的关键

// 对于需要长时间思考的任务，不要阻塞用户
async function handleComplexTask(task: Task) {
  if (task.estimatedTime > 5 * 60 * 1000) {
    // 超过5分钟的任务，走异步规划
    return await submitToRemotePlanner(task);
  }
  // 简单任务本地处理
  return await handleLocally(task);
}

原则三：人格化是增强粘性的有效手段

// BUDDY的成功证明：给AI一个"形象"能显著提升用户参与度
// 考虑在你的Agent中加入轻量的人格化元素

原则四：遥测要追踪领先指标

// 追踪用户骂人的频率，比追踪流失率更能提前预警
const frustrationScore = countFrustrationPatterns(userInput);
if (frustrationScore > threshold) {
  alertProductTeam();  // 产品体验可能有问题
}

原则五：端云协同是处理重型任务的架构选择

// 不是所有计算都需要在本地完成
// 将CPU/时间密集的任务卸载到云端，本地只负责轻量执行

9.2 你应该关注什么？

对于正在构建Agent系统的开发者，从这次泄露中最值得关注的是：

1. KAIROS的设计理念
   
   ：从被动到主动，这是Agent的终极形态
2. ULTRAPLAN的端云协同
   
   ：承认本地限制，善用云端算力
3. Feature Flag的管理方式
   
   ：编译时开关比运行时开关更安全
4. 用户情绪监控
   
   ：领先指标比滞后指标更有价值

十、小结与下一期预告

从Feature Flag中，我们看到了Claude Code的未来：

1. KAIROS
   
   代表“永远在线”——Agent不再是被叫醒的工具，而是持续的协作伙伴
2. ULTRAPLAN
   
   代表“云端大脑”——承认单次对话的局限，用异步规划解决复杂问题
3. BUDDY
   
   代表“情感连接”——人格化不是花哨，是用户粘性的工程化设计
4. Undercover Mode
   
   代表“务实选择”——在AI生成代码的争议中找到生存之道

这些功能大部分尚未发布，但源码已经为我们勾勒了AI Agent的产品演进路线图。对于正在构建Agent的开发者来说，这不是“抄作业”，而是看懂未来。

下一期，我们将深入工程化细节——启动优化、遥测设计、懒加载策略，看Claude Code如何把工程细节“卷”到极致。那个3000+行的print.ts反面教材，将成为第九期的亮点。

上一篇回顾：Claude Code 源码深度拆解⑦ | 六层记忆系统：为什么“不记代码”是最精妙的设计

下一篇预告：Claude Code 源码深度拆解⑨ | 工程化细节：启动优化、遥测设计与“挫败感正则”

延伸思考：如果你的Agent产品也要从“响应式”演进到“主动式”，你会选择从哪个场景切入？是监控代码质量、自动修复bug，还是主动提醒技术债务？欢迎在评论区分享你的产品思路。