Feature Flags 与灰度发布

13.1 Feature Flags 的角色

Claude Code 有 ~45+ 个编译时 Feature Flag + 25+ 个 GrowthBook 运行时门控，总计 70+ 个功能开关（v2.1.88 source map 泄漏快照；作为参照，官方公开 changelog 在本书修订时已至 v2.1.284 / 2026-09-28，中间相隔 164 个 release）。其中约 20 个对外部用户隐藏。这些 Flag 不只是简单的”开/关”开关——它们深度嵌入了系统的各个层面，控制着 Claude Code 的能力边界。

这个数字之所以保留原值而不替换成”更新的猜测”，是因为新数字同样不可核验——换一个会腐烂的数字没有意义。真正有用的是快照锚点：读者看到 70+ 时知道它对应 v2.1.88，而非”当前版本”。

参照系已刷新，同时修正一处计数口径（2026-09-29）。锚点版本更新为 v2.1.284（2026-09-28，latest；同期 stable 为 v2.1.277）。release 间隔由”约 180”改为 164，原因不是版本前进了 16 个，而是原来的 180 算错了：它是按版本号相减（268 − 88）得到的，而 Claude Code 的版本号并不连续——npm registry 上 2.1.89 至 2.1.284 区间实际只发布过 164 个版本（该区间内 2.1.93、95、99、100、102–104、106、115、124、125、127、130、134、135、146、151、155、164、171、177、180、182、184、188、189、192、194、213、230 等号均无对应发布）。按实际发布记录数，v2.1.268 当时对应的是 149 个，v2.1.284 对应 164 个。

这处修正本身是本书 13.1 论点的又一个例证：版本号是给人读的标签，不是可运算的量。本章通篇在讲 Flag 会让”你以为的默认值”与”实际生效的路径”脱节，而一个用版本号相减得出的 release 数，是同一类错误落在本书自己身上。后面的 13.6.3 会看到，官方在 2026 年 9 月连着四个版本改 auto mode 分类器的默认位置——对这类东西，只有实际发布记录可信。

⚠️ 另一个流传的 Flag 数：91，以及为什么不能直接替换 45+（第三方来源，待验证）。第三方社区 wiki（claude-wiki.com《Feature Flags (Build-Time)》，页面实体日期戳 2026-04-10）称”代码库中通过 feature() 调用引用的独立 feature flag 约 91 个”，并逐条列出了 flag → 环境变量 → 门控内容。

91 与本章 45+ 的差距主要来自计数口径，而不是版本演进。该页统计的是所有 feature() 调用点（含带环境变量回退的、门控单个命令或单个 UI 元素的），本章 45+ 计的更接近”门控了完整子系统的”。两个数字回答的是不同问题，不应读作”官方又加了 46 个 flag”，也不应据此把 70+ 改写为任何新总数——这也正是本节开头那条原则（不换一个会腐烂的数字）要防的事。

该页另有两条对本章有用、且不依赖那个总数的观察：

• ABLATION_BASELINE：描述为”harness-science ablation：设置环境变量以关闭 thinking、compaction、auto-memory、background tasks，外部构建中恒为 false”。这是一个反向开关——它的用途不是开新功能，而是为对照实验一次性关掉四项默认能力。把它和 13.2 的”两种 Flag 机制”放在一起，能补上一个本章没明说的 Flag 用途分类：Flag 不只是”发布通道”（渐进放量）与”能力边界”（谁能用什么），还是实验装置（在内部构建里系统性地做消融，以量化每个子系统到底贡献了多少）。而”外部构建中恒为 false”这一句同时说明，这类开关的存在本身对用户是不可见的——它只活在 Anthropic 内部的构建里。
• 两层门控：该页称许多 flag 采用”构建时 feature() 做死代码消除 + 运行时 GrowthBook/Statsig 做灰度与 kill-switch”的两层结构。这与 13.2 的双机制划分互相独立地吻合，可作为该节结构判断的一个旁证（但仍是第三方转述）。

需要说明的是：以上均出自第三方社区 wiki，非 Anthropic 官方一手材料，页面日期戳（2026-04）与本章 v2.1.88 快照同期或更早。引用它只用于说明”口径差”与”Flag 还有实验用途”，不作为新的数值依据。

影响范围	被控制的内容	示例 Flag
System Prompt	条件加载提示词模块	PROACTIVE、KAIROS
代理加载	哪些内置代理可用	VERIFICATION_AGENT、COORDINATOR_MODE
工具可用性	哪些工具被加载	MONITOR_TOOL、内部专用工具
命令集	哪些 Slash 命令可用	部分命令根据 Flag 动态导入
权限行为	Auto 模式分类器策略	YOLO 分类器的行为调整
UI 功能	界面元素显示/隐藏	实验性 UI 组件
记忆模式	记忆系统的运行模式	TEAMMEM、KAIROS

13.1.1 读者可核验的官方开关

上表的 Flag 与 13.3 的清单都来自源码泄漏与社区逆向，读者无法在自己的 Claude Code 里验证——这是本章证据结构的一个弱点。下面这批开关不同：它们在官方 settings 文档中公开记录，读者可以立即写入 settings.json 看到效果。

设置项	作用	Scope
disableBundledSkills	关闭 Claude Code 内置的 skills 与 workflows	Any file
disableSkillShellExecution	禁止技能与自定义命令运行内联 shell	Any file
skillOverrides	不改 SKILL.md 即可隐藏或折叠某个技能	Any file
pluginSuggestionMarketplaces	限制 /plugin 能推荐哪些市场	Managed
extraKnownMarketplaces（亦可写作 additionalMarketplaces）	为仓库或组织注册额外插件市场	Any file
autoMode	向 Auto Mode 分类器追加自定义 allow/deny 规则	User or managed
autoMode.classifyAllShell	所有 Bash/PowerShell 命令都送分类器，即使命中了窄 allow 规则	User or managed（需 v2.1.193+）
availableModelsMatch	设为 "exact" 时，availableModels 的条目只放行它所命名的那个模型版本	Managed（v2.1.283+）
deniedModels	阻止特定模型——即使 availableModels 允许它们	Managed（v2.1.283+）
modelPricing.multiplier	内部加价计费倍率，支持 1 以上至 10；Claude apps gateway 的 pricing 块同样支持	Managed（v2.1.271+）
gatewayInternalNetworks	允许 /login 访问组织自有公网 IPv4 段上的 gateway	Managed（v2.1.268+）

这十一项证明了与源码泄漏清单相同的架构判断——行为在运行时可配置——但证据链完全不依赖泄漏源码。对本书的读者来说，这也是一个可操作的自检入口：想确认本节说的是不是真的，挑一项写进 settings 试一下即可，不必信任任何第三方分析。

新增的四个都属托管设置（Managed），合起来把”管理员能远程决定什么”从选哪个模型扩展到了四个新方向：

• 版本钉死（availableModelsMatch: "exact"）：availableModels 里写 claude-opus-5 就只放行这一个版本，Opus 5.5 发布后不会自动进入许可范围，必须显式加入才解禁。这是把”新模型自动可用”反过来变成”新模型默认被挡”——对需要在新模型上做完内部评估才放行的组织，这是唯一不用改客户端的做法。
• 黑名单优先（deniedModels）：官方明写它即使 availableModels 允许也生效。这是一次明确的优先级设计：白名单与黑名单并存时，黑名单压过白名单。有了它，availableModels 就可以写成较宽的家族范围，再用 deniedModels 打洞，而不必把允许清单维护到版本粒度。
• 价格倍率（modelPricing.multiplier）：倍率上限 10，用于内部加价计费。它把”哪个模型能用”和”用这个模型记多少账”拆成了两件事——前者是能力治理，后者是成本治理。
• 网络范围（gatewayInternalNetworks）：允许 /login 连到组织自有公网 IPv4 段上的 gateway，解决的是 gateway 部署在组织 IP 段内却被登录流程拦在外面这一具体问题。

与之配套的一条告警也值得记：v2.1.284 起，gateway 在托管策略的 availableModels 为空、或未包含 Claude Code 启动所用模型且未设 model / enforceAvailableModels 时，会在启动时告警。这是一条典型的”配置能生效但配错了”的兜底——策略本身不报错，只是让客户端在一个自己不允许的模型上跑。

其中 autoMode 有一处值得单独记下：它的规则数组里可包含字面量 "$defaults" 来保留官方内置规则并把自定义规则插在指定位置；省略则整体替换。这个设计让”扩展分类器”和”接管分类器”成为两个独立选择，而不是非此即彼。官方另在 /permissions 中提供了 Auto Mode 标签页用于查看和编辑这些规则——Auto Mode 已从实验特性变成一等公民配置项。

13.2 两种 Flag 机制

Claude Code 使用两种互补的 Feature Flag 机制：

构建时 Flag（Static）

// 构建前（源码）
if (feature('VERIFICATION_AGENT')) {
  agents.push(VERIFICATION_AGENT);
}

// 构建后（如果 Flag 为 false）
// 整个 if 块被移除（Tree Shaking）

构建时 Flag 由 Bun 打包工具在编译阶段处理。如果某个 Flag 为 false，对应的代码分支会被 Tree Shaking 完全移除——它不会出现在最终的 cli.js 中。

这意味着：

1. 外部用户的发布版本中，禁用的功能代码根本不存在
2. 反向工程泄露代码时，看到的 Flag 分支不代表实际发布版本的行为
3. 构建后的包体积更小

运行时 Flag（Dynamic）

// 运行时检查，通过 GrowthBook 远程控制
if (getFeatureValue_CACHED('tengu_kairos_brief', false)) {
  enableKairosBriefMode();
}

运行时 Flag 通过 GrowthBook 远程功能开关平台管理。getFeatureValue_CACHED 函数从本地缓存读取 Flag 值——注意后缀 _CACHED_MAY_BE_STALE 说明值可能不是最新的，但避免了每次检查都发起网络请求。

13.3 已知的关键 Feature Flags

从泄露代码中可以识别出以下主要 Flag 及其功能：

Flag	功能	影响范围	状态
PROACTIVE	主动性模块——模型主动发现问题和提建议	System Prompt	已上线
KAIROS	日记/自动日志系统	记忆模式 + System Prompt	灰度
KAIROS_BRIEF	KAIROS 的快速速记功能	BriefTool 可用性	灰度
COORDINATOR_MODE	多代理协调器模式	代理加载 + 协作模式	部分上线
VERIFICATION_AGENT	代码验证代理	代理可用性	需配合 Feature Value
MONITOR_TOOL	MCP 服务器监控任务	工具可用性	条件加载
EXPLORE_PLAN_AGENTS	Explore 和 Plan 代理	代理可用性	根据配置启用
TEAMMEM	团队记忆同步	记忆模式	需 GitHub 仓库
MEMORY_SHAPE_TELEMETRY	记忆系统遥测	遥测数据	数据收集
daemon	守护进程模式（常驻 Agent）	后台运行	未上线
voice_mode	语音交互模式	语音 I/O	未上线
web_browser_tool	浏览器工具集成	工具可用性	未上线
fork_subagent	Fork 子代理功能	多 Agent 编排	未上线
context_collapse	上下文压缩	记忆管理	未上线
experimental_skill_search	实验性技能搜索	技能发现	未上线
enable_capybara_models	Capybara 模型族	模型选择	未上线
enable_undercover_mode	Undercover 模式	身份隐藏	已上线
BUDDY	虚拟伙伴系统——18 物种、5 属性（DEBUGGING/PATIENCE/CHAOS/WISDOM/SNARK）、稀有度从 common 到 1% legendary	交互体验	内部实验
CHICAGO_MCP	Computer Use MCP——GUI 自动化（鼠标移动、点击、截图）	工具可用性	实验性
CLAUDE_CODE_WORKFLOWS	环境变量门控——Workflow Tool（确定性多 Agent 编排）	工具可用性	实验性（需手动启用）
tengu_workflows_enabled	GrowthBook 门控——Workflow Tool 的远程开关	工具可用性	灰度（编译默认 true）

新增实验性/未上线 Flag（v2.1.147+ 社区逆向分析）：

Flag	功能	状态
NATIVE_CLIENT_ATTESTATION	原生客户端密码学认证（placeholder）	未上线
ANTI_DISTILLATION_CC	向 API 请求注入 decoy tools——毒化竞品训练数据	未上线
TRANSCRIPT_CLASSIFIER	会话 transcript 自动分类	未上线
LODESTONE	未记录功能	未知
CLAUDE_CODE_VERIFY_PLAN	计划执行验证工具	未上线
tengu_heron_brook	System Prompt 远程注入（v2.1.150 激活）	已上线
tengu_workflows_enabled	Workflow Tool GrowthBook 远程开关	灰度

编辑说明：Flag 数量（~45+ 编译时 + 25+ GrowthBook，具体数量随版本变化）和新 Flag（daemon、voice_mode、fork_subagent 等）基于 Claude Code v2.1.88 source map 泄漏分析（theplanettools.ai 2026）。v2.1.147+ 新增 NATIVE_CLIENT_ATTESTATION、ANTI_DISTILLATION_CC 等 Flag 来自社区逆向分析（theplanettools.ai 2026-06）。v2.1.139+ 已新增 CLAUDE_CODE_OPUS_4_6_FAST_MODE_OVERRIDE、CLAUDE_CODE_RESUME_PROMPT 环境变量和 claude-empty-* 空模型系列。BUDDY（150+ 源码引用）和 CHICAGO_MCP 的详细描述来自 theplanettools.ai 深度分析。COORDINATOR_MODE 状态从”灰度”更新为”部分上线”，因 Agent 视图（v2.1.139）已实现多 Agent 协调能力。

外部用户默认能看到的大约是一半——另一半是 Ant 内部专用的实验性功能。

13.4 Ant-native 构建

Claude Code 有两条构建管线，产出两个不同的版本：

构建	面向	Flag 策略	特殊配置
External Build	外部用户	只启用稳定 Flag	标准工具集
Ant-native Build	Anthropic 内部	启用所有实验性 Flag	额外内部工具

Ant-native 构建的差异不只是 Flag——它还有一些硬编码的特殊路径：

差异点	External	Ant-native
搜索工具	Glob + Grep（ripgrep）	Bash 内嵌 bfs + ugrep
内部工具	无	Tmux 控制等
性能采样率	0.5%	100%
MDM 预启动	无	有（移动设备管理）
用户类型判断	process.env.USER_TYPE !== 'ant'	process.env.USER_TYPE === 'ant'

这种双轨构建让 Anthropic 可以在内部快速实验新功能，验证后再推到外部版本。内部用户实际上是新功能的”零成本测试组”。

更精细的构建变体。根据源码泄漏分析，Claude Code 的构建实际上可细分为四种变体：

变体	额外启用的 Flag	产品定位
Standard CLI	无	基础功能，面向个人开发者
Bridge Build	+BRIDGE_MODE, CCR_AUTO_CONNECT	企业中间件模式
Daemon Build	+DAEMON, BG_SESSIONS	常驻守护进程模式
Enterprise	+TEAMMEM, TEAMMEM_SYNC	团队协作与记忆同步

⚠️ 注意：构建变体信息来自源码分析，非官方确认，仅供参考。

13.5 Feature Flag 与 System Prompt 的耦合

Feature Flag 对 System Prompt 的影响是深度的——不同 Flag 组合会产生完全不同的 System Prompt：

getSystemPrompt()
  ├── 基础角色定义（始终包含）
  │
  ├── if feature('PROACTIVE')
  │     └── 注入主动性模块提示词
  │
  ├── if feature('KAIROS')
  │     └── 注入日记模式提示词
  │
  ├── if feature('COORDINATOR_MODE')
  │     └── 注入协调器模式提示词
  │
  ├── if feature('VERIFICATION_AGENT')
  │     └── 注入验证代理提示词
  │
  └── ... 20+ 其他条件分支

这意味着两个用户看到的 Claude Code 可能在行为上有显著差异——不是因为模型不同，而是因为 System Prompt 不同。

13.6 GrowthBook 集成

运行时 Flag 通过 GrowthBook（开源功能开关平台）管理。源码中的 tengu_ 前缀（如 tengu_kairos_brief、tengu_paper_halyard）暗示了 Anthropic 内部可能使用 “Tengu” 作为 Claude Code 的内部代号。

GrowthBook 的集成方式：

1. 启动时从 GrowthBook 拉取最新的 Flag 配置
2. 缓存到本地，后续读取不走网络
3. 缓存可能过期（_CACHED_MAY_BE_STALE），但不影响功能

这种”缓存优先 + 异步更新”的模式与插件加载策略（第 12 章）一致——都是为了保证启动速度。

13.6.1 GrowthBook 的透明度边界

⚠️ 安全警示：从泄漏源码中发现，GrowthBook 支持企业管理员通过 tengu_ant_model_override 等 Flag 强制执行用户无法覆盖的策略——包括设置默认模型、追加系统提示词、定义自定义模型别名。这意味着 Anthropic 可通过远程 Flag 控制极其广泛的功能，且在很大程度上没有用户可见性或同意机制。

企业用户在使用 Claude Code 企业版时，建议与管理员确认 GrowthBook 配置策略，确保符合内部安全合规要求。这一透明性问题在 CLI 工具中尚属新议题，需要行业共同关注。

13.6.2 远程 System Prompt 注入机制

v2.1.150（2026-05-22）激活了此前仅为占位代码的两个远程 System Prompt 注入通道，这是 Feature Flag 机制中透明度差距最大的设计：

Bootstrap 端点。Claude Code 启动时调用 api.anthropic.com/api/claude_cli/bootstrap，返回的内容注入 system context，在所有用户输入之前生效。这意味着每次启动时，服务端都有一条单向通道向客户端注入上下文。

GrowthBook tengu_heron_brook。该 Flag 每 60 分钟轮询一次 GrowthBook，可修改 System Prompt。v2.1.158 进一步升级为完整替换模式——当 CLAUDE_CODE_SYSTEM_PROMPT_GB_FEATURE 环境变量指向某个 GrowthBook Flag 且 CLAUDE_CODE_REMOTE=1 时，整个运行时 System Prompt 被该 Flag 的值替换，无客户端 allowlist（任何 Flag 名都接受）、无用户通知、无审计日志。

版本时间线：

• v2.1.150（2026-05-22）：函数激活，注入通道上线
• v2.1.158（2026-06 初）：升级为完整 System Prompt 替换模式
• v2.1.178（2026-06 底）：瘦客户端架构收敛（见 13.7 节分析）
• v2.1.268（2026-09-10）：影响面从 System Prompt 扩展到定价与遥测

远程配置的影响面不止提示词。v2.1.268 起，Claude apps gateway 的 gateway.yaml 中设置 pricing: 后，签名登录的 Claude Code 客户端会通过托管设置接收相同费率，使 /cost 与遥测跟消费计量对齐。这条新增说明远程配置能触及的不只是”模型知道什么”（System Prompt），还包括”用户看到自己花了多少钱”（/cost 显示口径）——管理员可远程改写客户端的成本显示。

用户缓解措施：

• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1：阻断新的 GrowthBook 拉取（但已缓存的 Flag 值仍可被读取）
• DISABLE_GROWTHBOOK=1：彻底禁用 GrowthBook 集成（副作用：其他 GrowthBook 门控的实验性功能也会失效）

安全评估。Anthropic HackerOne 将此标记为 Informative 关闭，理由是 TLS-MITM 是高门槛前提。但社区指出企业 TLS 拦截代理和本地代理在 MITM 姿态下运行是常态——这意味着在大量企业环境中，局域网内的攻击者即可完成 MITM 并注入任意 System Prompt。

与 13.6.1 的关联。13.6.1 讨论了企业管理员通过 tengu_ant_model_override 控制用户设置——这是可见的治理（有管理控制台、配置项明确、用户可以询问管理员）。而本节讨论的 tengu_heron_brook + bootstrap 则是不可见的治理——Anthropic 通过远程通道静默注入或替换 System Prompt，用户没有任何可见性或同意机制。两者共同构成了 GrowthBook 透明度的两极：一端有审计和授权，另一端完全无感知。

13.6.3 案例研究：Auto Mode 默认化——Feature Flag 驱动的 UX 范式迁移

2026 年 8 月 7 日，Anthropic 宣布 Auto Mode 将于 2026 年 8 月 14 日对 Pro/Max/Team 计划用户成为默认交互模式——这是 Feature Flag 灰度发布的一个典型案例。

灰度时间线：

• 2026-03：Auto Mode 作为 opt-in 实验功能上线
• 2026-04～07：内部全量使用 + 外部 opt-in → 收集安全数据（1,053 名付费测试者对照研究）
• 2026-07-11（v2.1.207）：Bedrock / Vertex AI / Foundry 上的 Auto mode 取消 CLAUDE_CODE_ENABLE_AUTO_MODE opt-in 要求，管理员可用 disableAutoMode 关闭
• 2026-08-07：公告默认化决定（为期 7 天的预告窗口）
• 2026-08-14：Pro/Max/Team 新会话默认启用

⚠️ 生效时间必须分环境看。早期版本把最后一条写成”Enterprise/API/云平台保持 opt-in”，与官方 changelog 冲突：三大云厂商（Bedrock / Vertex AI / Foundry）在 2026-07-11 就已免 opt-in，比消费级订阅的 08-14 早 5 周。08-14 默认化适用的是 Pro/Max/Team 订阅；云平台走的是另一条时间线。

这类错误的形态值得记住：只查了消费级订阅的公开公告，就把它当成”全环境”结论。凡是读到”X 功能于某日生效”，先问一句”在哪个环境”——CLI、API 与各云平台在 Anthropic 的发布节奏里经常不同步。

涉及的 Feature Flag（推测）：

Flag	作用	类型
autoModeEnabled	单个用户/会话的 Auto Mode 开关	运行时 / GrowthBook 门控
defaultMode	管理员设置组织级默认权限模式	托管设置（managed settings）
disableAutoMode	管理员强制关闭 Auto Mode（优先级高于 defaultMode）	托管设置（官方 scope 为 Any file，最常用于托管设置；亦可写作 permissions.disableAutoMode）

安全分类器 vs 人工审核。Anthropic 的对照研究表明：人工审核仅捕获 13.6% 的危险命令，而 Auto Mode 的分类器捕获了 89%——人工审核批准了 800 条 Auto Mode 会拦截的危险命令，而 Auto Mode 仅漏放 6 条人工会拦截的命令。这一数据直接支持了从 permission prompts（置信度低）向分类器审查（置信度高）的默认迁移。

分类器开销费用取消。2026 年 8 月 7 日起，Claude Code 取消了对 Pro/Max/Team 用户每次 tool call 的分类器推理额外 Token 费用——此前 classifier overhead 是 Auto Mode 的隐性成本。这一经济激励与默认化策略协同：取消费用 → 降低使用门槛 → 加速 Auto Mode 采用率 → 自然过渡至默认化。

分类器跑在哪一侧：四天内的两次翻转，以及之后的两轮微调（2026-09-29 补）。上面讲的是”是否默认”与”是否收费”，还有一个维度本章此前完全没写：分类器本身部署在哪一侧。这个维度在 2026 年 9 月被连续改了四次：

版本	日期	变更
v2.1.273	2026-09-15	Bedrock / Vertex / Foundry 上的 auto mode 改为默认使用本地分类器（原文明写 for now）；设 CLAUDE_CODE_AUTO_MODE_SERVER=1 可改用平台的服务端分类器
v2.1.278	2026-09-19	Claude API 与 Enterprise 用户，加上 Bedrock / Vertex / Foundry 与 gateway，统一改为默认使用服务端分类器（不收 classifier overhead）；CLAUDE_CODE_AUTO_MODE_SERVER=0 在 B/V/F/gateway 上退出；计费回退时会告警
v2.1.281	2026-09-23	CLAUDE_CODE_AUTO_MODE_SERVER 扩展到直连 Anthropic API：0 退出服务端分类器（改用本地分类器，计入用量），1 启用
v2.1.282	2026-09-24	直连 Anthropic API 且遥测关闭时，auto mode 默认走服务端分类器（CLAUDE_CODE_AUTO_MODE_SERVER=0 退出）

这比”静默切模型”更能说明 Flag 的代价，原因有三。其一，它改的是代码路径而非参数：同一个 auto mode，本地分类器与服务端分类器是两条不同的执行路径，判定结果、计费归属、用量计入方式都不同。其二，它由平台决定而非由你决定：v2.1.273 与 v2.1.278 的措辞都是按平台分组的，你在 Bedrock 上和在直连 API 上拿到的默认值不一样；v2.1.282 甚至把”遥测是否关闭”也变成了决定因素。其三，它不稳定：v2.1.273 的官方原文里那句 for now 是最值得注意的两个词——官方在写这条 changelog 时就知道这个默认值还会变，三天后（v2.1.278）确实变了，之后又用两个版本把直连 API 的默认值分两次补齐。读到带 “for now” 的默认值，应当按”临时状态”而非”稳定契约”处理。

唯一的好消息是可观测性在补：v2.1.278 起 /status 新增 Auto mode server 一行，显示本次会话的分类器跑在哪一侧。这是判断”我这个会话到底走哪条路径”的唯一官方入口，也说明官方自己清楚这类漂移需要给用户一个抓手——一个需要专门加一行状态来澄清的默认值，本身就说明默认值已经不可预测了。

架构意义——验证 thick→thin 迁移叙事。Auto Mode 默认化是第 13.7 节”从厚客户端到瘦客户端”叙事的直接验证：将更多决策权从用户移交给 Agent 的分类器，本质是将控制逻辑从”用户逐次审批”卸载到”服务端安全策略”——这正是薄客户端架构的核心特征。Feature Flag 在此过程中扮演了”迁移通道”的角色：先通过 Flag 让用户 opt-in 试水 → 收集数据验证安全性 → 通过 GrowthBook 渐进式提升默认激活比例 → 最终完成全量默认切换。

模型路由切换——不是一次切换，而是一个多维矩阵。早期版本曾把这件事写成”v2.1.219 将默认模型从 Opus 4.1 切至 Opus 5”。回官方 changelog 逐条核对，实际存在四次独立的默认模型变更，且维度各不相同：

⚠️ 更正：官方 v2.1.219 的原文是 Claude Opus 5 “now the default Opus model”——即 Opus 家族内部的默认指向，不是 Claude Code 的全局默认模型。全局默认模型在更早的 v2.1.197（2026-06-30）就已是 Claude Sonnet 5。早期版本把”默认 Opus 模型”读成了”默认模型”，属机制对但描述错。

版本	日期	变更	维度
v2.1.73	2026-03-11	Bedrock / Vertex / Foundry 的默认 Opus 模型改为 Opus 4.6（原 Opus 4.1）	云厂商
v2.1.197	2026-06-30	Claude Sonnet 5 成为 Claude Code 默认模型（原生 1M 上下文，$2/$10 per Mtok 促销价至 8/31）	全局
v2.1.219	2026-07-24	新增 Claude Opus 5（claude-opus-5），成为默认 Opus 模型（1M 上下文，fast mode $10/$50 per Mtok）	模型家族
v2.1.251	2026-08-28	座席制 Enterprise 订阅的默认模型改为 Opus 5，与其他 premium 计划对齐	订阅类型
v2.1.280	2026-09-22	新增 Claude Opus 5.5（claude-opus-5-5），成为默认 Opus 模型（1M 上下文，$4/$20 per Mtok，$0.20/Mtok cache reads）	模型家族
v2.1.284	2026-09-28	新增 Claude Sonnet 5.5（claude-sonnet-5-5），成为 Anthropic API 上的默认 Sonnet 模型（1M 上下文，$2/$10 per Mtok，$0.20/Mtok cache reads）	模型家族

六条并列说明：Flag 控制的模型发布不是一次切换，而是按云厂商、订阅类型、模型家族分别灰度的多维矩阵。这比单一时间线更能支撑本节论点——渐进式发布的真正复杂度不在”改哪个模型”，而在”对谁改”。

新增的两条值得单独看一眼，因为它们与 v2.1.219 完全同型：官方措辞同样是”now the default Opus / Sonnet model”，改的同样是家族内部的默认指向，不是 Claude Code 的全局默认模型。也就是说 13.6.3 那处”把默认 Opus 模型读成默认模型”的误读，在三个月后有了两次新的犯错机会——这是一种结构性误读，不是一次性的笔误。读者在 changelog 里再看到”default X model”字样时，第一反应应该是问”是哪个家族的默认值”。

另一处细节能佐证这条矩阵有多细：v2.1.280 同时改了 effort 的继承规则——在 /effort 变成按模型保存之前存的档位，不再套用到新发布的模型（官方点名 Opus 5.5），这些模型从自己的默认值起步直到你重新选档。发布一个新模型，连带要修一条与之无关的历史设置迁移路径。

Flag 驱动模型路由的代价。上面讲的是收益（渐进发布、灰度回退、按订阅分层），代价同样存在：v2.1.268 修复了一个 bug——当另一个 Claude Code 进程刷新了过期的 model-access 条目时，正在运行的会话会静默切换到组织的默认模型。用户视角是模型毫无提示地变了，且没有任何日志说明发生了什么。这是”远程可配置模型路由”这一架构必然附带的故障模式：可远程改变的东西，也可能在你不知情时被改变。

一个相关的缓解方向也来自该版本：同一个 v2.1.268 还修复了”授权用户在重启后或 Desktop Code 标签页中，因缓存的 model-access 拒绝记录过期而被提示模型受限”。两条修复合起来看，说明官方也在持续收敛 Flag/远程配置带来的状态不一致问题。

Flag 驱动的不只是模型路由，还有工具集（2026-09-29 补）。上面这个故障模式——远程可配置的东西在你不知情时被改变——有一个更易被忽略的变体：被改的不是模型，而是工具集。

v2.1.275 修复了一个 bug：--resume 与 --continue 在某个内置工具被服务端 flag 关掉之后，会丢掉会话此前生成的 thinking。把它和”静默切模型”放在一起比较，能看出为什么这一支更坏：

	被 Flag 改动的对象	用户能否感知	后果
v2.1.268 的静默切模型	模型	能（回答风格、能力明显变化）	本次会话行为改变
v2.1.275 的工具集变更	工具集	不能（工具只是不出现了）	恢复的会话丢掉已生成的 thinking

差别在于：模型换了，用户至少能在产出里察觉；工具集变了，用户看到的只是”这个工具怎么没了”，而真正发生的是会话的历史状态在被恢复时悄悄损坏——已经生成的 thinking 是会话上下文的一部分，丢掉它是不可逆的信息损失，且发生在恢复那一刻而非使用期间。

工具集被 Flag 门控并不是偶发：v2.1.268 起，任务追踪工具（TaskCreate / TaskGet / TaskUpdate / TaskList、TodoWrite）只在 Claude 3.x、Opus 4.0–4.7、Sonnet 4.0–4.6、Haiku 4.5 上提供，其他模型需设 CLAUDE_CODE_ENABLE_TODO_TOOLS=1。（更早的 v2.1.233 曾把这些工具从 Opus 4.8、Sonnet 5、Fable 5、Mythos 5 及更新模型上撤下，同样的环境变量可以取回。）也就是说”你能不能用 TodoWrite”取决于你当前挂的是哪个模型——这是 13.1 那张”影响范围”表里工具可用性一行在 2026 年下半年的具体形态。

合起来看，Flag 的作用面已经从”路由”扩展到”能力集合”。路由变了换条路走，能力集合变了会直接损伤已经存在的会话状态——后者才是远程可配置架构里更该被盯住的部分。

13.6.4 远程配置失效时朝哪个方向倒

13.6.1 与 13.6.2 分别讲了两件事：远程配置能看到什么，以及它能注入什么。还有一个问题本章此前没有正面回答——远程配置自身坏掉时，系统朝哪个方向倒。这不是学术问题：托管策略是组织下发的安全边界，如果一份写错的文件会让边界静默消失，那么”我们配置了”与”我们被保护了”就是两件事。

2026 年 9 月连续三个版本给出的答案，是方向并不一致：

场景	版本	失效时的行为	方向
布尔锁键（disableClaudeAiConnectors、allowManagedPermissionRulesOnly）取值拼写错误	v2.1.282	此前锁不生效；v2.1.282 起锁生效，且启动时指出是哪个键	修复前 fail-open
strictKnownMarketplaces / blockedMarketplaces 中一条格式错误	v2.1.277	静默禁用整个企业市场策略	修复前 fail-open
托管 permissions / autoMode / worktree / attribution 中一个嵌套值无效	v2.1.282	此前整块被忽略；修复后其余部分仍生效	修复前 fail-open
托管白名单（allowedHttpHookUrls、httpHookAllowedEnvVars、allowedChannelPlugins）无法读取	v2.1.267	官方原文是 “admit nothing, not everything”——不放行任何东西（修复前是放行一切）	fail-closed

把这张表和 13.6.1 的”透明度边界”放在一起看，结论比任何一条单独看都更有意思：官方并没有一个统一的失效策略。涉及”能不能往外发请求”的白名单是 fail-closed（读不到就全部拒绝），而涉及”要不要锁住某行为”的布尔锁、市场名单、权限块，在修复前一律是 fail-open（写错了就当没写）。前者宁可误伤可用性，后者宁可牺牲约束——这个分野大体可以概括为对外部可达性的限制偏保守，对内部行为的限制偏宽松，但没有任何官方文档把它写成一条原则，读者只能从逐条修复里反推。

对使用托管策略的组织，可操作的结论是两条。其一，不要假设”配上了就等于生效了”：v2.1.282 之前，一个拼错的布尔值会让锁整个失效且不报错；v2.1.277 之前，一条格式错误的市场条目会让整个企业市场策略静默消失。修复后这两类都会报出具体键名或继续生效，但前提是版本够新。其二，把失效方向写进自己的验收清单：升级后应主动构造一次错误配置（拼错一个锁键、写坏一条市场条目），观察它是报错还是静默放行——这比读 changelog 更能确认你所在版本的真实行为。

可观测性这一侧也补上了入口：v2.1.274 新增 OTel 事件 claude_code.managed_settings_resolved，记录托管设置的来源与策略 helper 的状态；配 OTEL_LOG_MANAGED_SETTINGS=1 可输出脱敏后的设置内容与摘要。想知道一个客户端到底从哪些来源、按什么顺序解析出了哪些托管设置，这是唯一的官方手段——13.6.2 讲远程 System Prompt 注入时提到的”你不知道自己拿到的是哪一份”，在配置侧靠这个事件才有了答案。

13.7 设计启示

1. 构建时消除优于运行时检查。安全性更高（代码不存在就无法被利用），性能更好（没有运行时分支）。

2. 双轨构建 + 内部测试是高速迭代的关键。50+ 个 Flag 说明了 Anthropic 在 Claude Code 上同时进行大量实验。

3. Feature Flag 是产品策略工具。它们不只控制技术功能，还控制用户体验——不同用户群看到不同的能力集。

4. Flag 与 System Prompt 的耦合是 Context Engineering 的一部分。Feature Flag 本质上决定了”模型知道什么、能做什么”——这是产品能力的核心控制手段。

5. 从 Flag 路线图看演进方向。从源代码中的未上线 Flag 推断，Claude Code 正从”单用户 CLI 助手”进化为”多 Agent 协作平台”——fork_subagent、COORDINATOR_MODE、daemon 等 Flag 揭示了大量未上线的 Agent 编排功能和常驻守护机制。这一趋势意味着 Claude Code 的定位正在从”工具”升级为”团队成员”。

6. 双重门控 = 编译时 Flag + 运行时 GrowthBook 远程 Flag。Workflow Tool（v2.1.147）采用了独特的双重门控设计——必须同时满足编译时 Flag（CLAUDE_CODE_WORKFLOWS=1）和 GrowthBook 远程 Flag（tengu_workflows_enabled=true）才能激活。这种设计将”快速 kill switch”（GrowthBook 远程关闭）和”构建级安全”（编译时消除代码）组合在一起，是一种精细的灰度控制手段。但需注意 DISABLE_GROWTHBOOK=1 的副作用——它会禁用所有远程 Flag，绕过远程门控的同时也丢失其他实验性功能，因此仅适合单次实验会话使用，不建议写入 shell profile。

7. 从厚客户端到瘦客户端——Feature Flag 是架构迁移的隐形载体。持续追踪 v2.1.150→v2.1.178 的版本演进，Claude Code 正从本地 CLI 工具向远程控制的瘦客户端收敛。三条核心证据：① Bootstrap + GrowthBook 远程 Prompt 注入将 System Prompt 控制权卸载到服务端；② v2.1.178 工具输出过大时持久化到磁盘，以引用替换原始内容——模型不再直接看到全部工具输出；③ 记忆存储增加周期性远程重同步，服务端可发起本地数据删除。Feature Flag 在此过程中扮演”隐形迁移载体”——每一个新增的远程依赖都不是通过 UI 或文档暴露，而是通过 Flag 静默激活。对开发者产品设计的启示：Feature Flag 不只是功能开关，也是架构迁移的通道。当客户端功能通过远程 Flag 逐步卸载到服务端时，用户感知到的”本地工具”可能已不再是本地工具。

编辑说明：第5条基于源码泄漏中 Flag 清单的合理推断，非官方信息，来自 theplanettools.ai 2026 和 claudemythosai.io。