在软件开发中，Feature Flag 是一种常见的发布策略。开发者把新功能的代码写好但不激活，通过一个布尔开关控制其是否生效。这让团队可以把未完成的功能安全地合并到主分支，等时机成熟再打开。
3 月源码快照中包含 82 个 Feature Flag，通过 feature('FLAG_NAME') 函数控制。外部构建中的全 false 行为和分类都属于该快照，不是当前功能清单。截至 2.1.227，自动记忆默认开启，支持的模型可使用 1M 上下文，语音交互也已经发布。
这意味着我们可以通过阅读这些快照代码，窥见 Anthropic 曾经考虑过的方向。有些功能可能仍在测试或已经放弃，另一些则已经发布。下面的 Feature Flag 表仍然是 3 月快照的分类。
相关 Flag： KAIROS、KAIROS_BRIEF、KAIROS_CHANNELS、KAIROS_DREAM、KAIROS_GITHUB_WEBHOOKS、KAIROS_PUSH_NOTIFICATION
Kairos 是一整套自主运行框架，由 6 个 Feature Flag 组成。在所有 82 个 Flag 中，这是覆盖面最广、最能反映 Anthropic 野心的一组。
KAIROS 是核心 Flag，启用后 Agent 可以脱离人类的逐步驱动，进入自主循环执行模式。目前的 Claude Code 是"你给一个指令，它执行一次"的模式。Kairos 要做的是"你给一个目标，它持续工作直到完成"。
KAIROS_BRIEF 启用简报模式。Agent 在自主工作的过程中，定期向用户汇报进展。这解决了一个关键的用户信任问题：如果 Agent 在后台默默工作半小时，用户完全不知道它在干什么，会很不安。定期简报让用户保持知情权，同时不打断 Agent 的工作流。
KAIROS_CHANNELS 支持多渠道接入。从 Flag 名称和代码引用推断，这可能意味着 Agent 不仅可以通过终端交互，还能接入 Slack、Discord、Teams 等消息平台。想象一下：你在 Slack 里给 Claude Code 发一条消息"帮我修复这个 bug"，它自动拉取代码、分析问题、提交修复、发起 PR，然后在 Slack 里通知你结果。
KAIROS_DREAM 可能是最有想象力的一个功能。从名称推断，这是让 Agent 在空闲时做后台思考和规划。类似于人类在不工作时也会思考明天要做什么，Agent 在没有收到用户指令时，可以利用空闲时间做代码库分析、预加载上下文、提前规划可能的任务。
KAIROS_GITHUB_WEBHOOKS 让 Agent 监听 GitHub 事件并自动触发任务。比如有人提了一个 Issue，Agent 自动开始分析和修复。有人提了一个 PR，Agent 自动做 Code Review。这让 Agent 成为了一个真正的团队成员，而非一个被动工具。
KAIROS_PUSH_NOTIFICATION 启用推送通知，在移动设备或桌面上通知用户 Agent 的工作进展。
如果 Kairos 完整发布，Claude Code 的定位将发生根本性变化。 它将从一个"你问它答"的交互式工具，变成一个"你不问它也在干活"的自主 Agent。这和整个 AI Agent 行业的发展方向一致：2024 年的 Devin 号称"第一个 AI 软件工程师"，强调的就是这种自主工作能力。但从 Claude Code 的代码成熟度来看，Anthropic 的实现可能更加系统化。
相关 Flag： CONTEXT_COLLAPSE
当前 Claude Code 使用 autocompact 机制管理上下文：当上下文接近容量上限时，触发压缩，把对话历史总结成更短的版本。这种方案简单有效，但有明显的局限性。压缩是一个有损操作，关键细节可能在压缩过程中丢失，而且压缩的时机完全取决于上下文使用率这个单一指标。
Context Collapse 是一套全新的上下文生命周期管理系统，设计思路与 autocompact 完全不同。从代码注释推断：
- 在 90% 上下文用量时触发 commit：保存当前工作状态的快照，类似 Git commit，创建一个可恢复的检查点
- 在 95% 上下文用量时触发 blocking-spawn：阻塞当前工作，启动一个全新的上下文继续执行，同时保持对之前上下文快照的引用
- 与 autocompact 互斥，不能同时启用
这个设计的精妙之处在于把上下文管理从"被动压缩"变成了"主动管理"。autocompact 像是房间满了就把东西压缩塞进柜子，Context Collapse 则像是房间满了就搬进一个新房间，同时保留旧房间的钥匙。
对于需要长时间运行的复杂任务来说，Context Collapse 可能是一个质的飞跃。 目前使用 Claude Code 做大型重构时，最大的痛点就是上下文压缩后丢失关键细节。Context Collapse 通过快照机制保留了完整的历史状态，即使在新上下文中工作，也能在需要时回溯。
相关 Flag： COORDINATOR_MODE
当一个任务足够复杂时，单个 Agent 可能力不从心。Coordinator Mode 让 Claude Code 充当多个 Agent 的协调者，将大任务分解为子任务，分配给不同的子 Agent 并行执行，最后汇总结果。
这和当前已有的 AgentTool 子 Agent 机制有什么区别？AgentTool 是主 Agent 手动 fork 子 Agent，每次只能委派一个具体的小任务。Coordinator Mode 是在更高的层面做编排：理解整个任务的全局结构，规划子任务之间的依赖关系，管理并行执行和结果合并。
类似的思路在行业中已有先例。微软的 AutoGen 框架支持多 Agent 对话。CrewAI 让多个 Agent 组成团队协作。OpenAI 的 Swarm 框架提供了轻量级的多 Agent 编排。但 Claude Code 的 Coordinator Mode 直接集成在 Agent 内部的 QueryEngine 中，和工具系统、权限系统、上下文管理深度耦合，可能比独立的多 Agent 框架更加高效。
相关 Flag： VOICE_MODE
当前 2.1.x 版本已经支持语音交互和听写，因此它不再只是未来功能。下面的 VOICE_MODE flag 属于快照遗留名称。
这看起来像一个 nice-to-have 的功能，但结合 Kairos 自主模式来看，意义就大了。当 Agent 在后台自主工作时，语音是一种非常自然的通知和交互方式。 你在喝咖啡，Agent 通过语音告诉你"PR 已经提了，测试全部通过，等你 Review"。你语音回复"把日志级别改成 debug 重新跑一遍"。这比打开终端敲键盘自然得多。
相关 Flag： VERIFICATION_AGENT
执行完任务后，自动启动一个独立的验证 Agent，检查结果是否正确。这相当于在 Agent 内部实现了一套 Agent-to-Agent 的 Review 机制。
为什么需要一个独立的 Agent 来验证？因为同一个 Agent 检查自己的输出存在"自我一致性偏差"：它会倾向于认为自己的工作是正确的。使用一个独立的 Agent，带着新鲜的上下文，从零开始审视结果，更容易发现问题。
这和人类工程团队的 Code Review 流程本质相同：写代码的人不应该是唯一审查代码的人。
相关 Flag： WORKFLOW_SCRIPTS
让用户定义自动化工作流脚本。Agent 按照预定义的步骤执行任务，而非每次都依赖 LLM 现场规划。
这解决了一个实际问题：LLM 的每次执行路径可能不同。 同一个任务，今天可能先读文件再搜索，明天可能先搜索再读文件。对于需要严格可复现性的任务，比如发布流程、安全审计、合规检查，这种不确定性是不可接受的。
Workflow Scripts 让用户把经过验证的工作流固化下来：第一步做什么，第二步做什么，每一步用什么工具，失败了怎么处理。Agent 仍然负责每一步的具体执行，但步骤的编排由人来决定。
PROACTIVE： Agent 主动发起任务。压缩后的恢复逻辑里有专门的判断：如果处于 Proactive 模式，压缩后直接继续工作，不打招呼，不问用户。这暗示了一种全新的使用模式：Agent 在用户不知情的情况下主动做事，比如自动修复新发现的 lint 错误，自动更新过期的依赖。
ULTRATHINK： 超级思考模式。从名称推断，这可能是给模型更多的"思考时间"或"思考 token"，让它在复杂问题上做更深入的推理。这和 OpenAI 的 o1/o3 模型的 chain-of-thought 思路一致。
TEAMMATES： 团队协作记忆。可能允许多个开发者共享 Agent 的记忆和经验，比如一个团队成员教会 Agent 的操作技巧，其他成员也能受益。
FAST_MODE： 快速模式，可能使用低延迟但能力稍弱的模型来处理简单任务，在速度和质量之间做权衡。
CONTEXT_1M： 当前 2.1.x 版本已为支持的模型提供百万 token 上下文。具体可用性和限制仍取决于模型与账户。
| Flag | 推测功能 |
|---|---|
| PROACTIVE | 主动执行模式 |
| KAIROS | 自主运行框架 |
| KAIROS_BRIEF | 定期简报 |
| KAIROS_CHANNELS | 多渠道接入 |
| KAIROS_DREAM | 空闲时后台思考 |
| KAIROS_GITHUB_WEBHOOKS | GitHub 事件触发 |
| KAIROS_PUSH_NOTIFICATION | 推送通知 |
| AGENT_TRIGGERS | Agent 触发器 |
| AGENT_TRIGGERS_REMOTE | 远程触发器 |
| WORKFLOW_SCRIPTS | 工作流脚本 |
| FORK_SUBAGENT | 子 Agent fork |
| COORDINATOR_MODE | 协调者模式 |
| VERIFICATION_AGENT | 验证 Agent |
| BUILTIN_EXPLORE_PLAN_AGENTS | 内置探索/计划 Agent |
| AGENT_MEMORY_SNAPSHOT | Agent 记忆快照 |
| Flag | 推测功能 |
|---|---|
| TRANSCRIPT_CLASSIFIER | 基于对话记录的权限分类 |
| BASH_CLASSIFIER | Bash 命令安全分类器 |
| POWERSHELL_AUTO_MODE | PowerShell 自动模式 |
| Flag | 推测功能 |
|---|---|
| CONTEXT_COLLAPSE | 上下文折叠 |
| EXTRACT_MEMORIES | 自动提取记忆 |
| MEMORY_SHAPE_TELEMETRY | 记忆形态遥测 |
| TEAMMATES | 团队协作记忆 |
| ULTRATHINK | 超级思考模式 |
| Flag | 推测功能 |
|---|---|
| PROMPT_CACHE_BREAK_DETECTION | 缓存命中率监控 |
| FAST_MODE | 快速模式，使用低延迟模型 |
| AFK_MODE | 离开模式 |
| TOKEN_BUDGET | Token 预算管理 |
| UNATTENDED_RETRY | 无人值守重试 |
| REACTIVE_COMPACT | 响应式压缩 |
| CACHED_MICROCOMPACT | 缓存编辑式微压缩 |
| EFFORT | 努力程度控制 |
| CONTEXT_1M | 百万 token 上下文 |
| STRUCTURED_OUTPUTS | 结构化输出 |
| TASK_BUDGETS | 任务预算 |
| REDACT_THINKING | 隐藏思考过程 |
| CONTEXT_MANAGEMENT | 上下文管理 |
| Flag | 推测功能 |
|---|---|
| STREAMLINED_OUTPUT | 精简输出模式 |
| HISTORY_SNIP | 历史裁剪 |
| HISTORY_PICKER | 历史选择器 |
| REVIEW_ARTIFACT | 审查产物 |
| AUTO_THEME | 自动主题 |
| TERMINAL_PANEL | 终端面板 |
| MESSAGE_ACTIONS | 消息操作 |
| NATIVE_CLIPBOARD_IMAGE | 原生剪贴板图片 |
| WEB_BROWSER_TOOL | 网页浏览器工具 |
| Flag | 推测功能 |
|---|---|
| BRIDGE_MODE | 桥接模式 |
| DAEMON | 守护进程 |
| CCR_REMOTE_SETUP | 远程设置 |
| CCR_AUTO_CONNECT | 自动连接 |
| CCR_MIRROR | 镜像 |
| VOICE_MODE | 语音模式 |
| MCP_SKILLS | MCP Skill 集成 |
| CHICAGO_MCP | Chicago MCP 服务 |
| UDS_INBOX | Unix Domain Socket 收件箱 |
| BUDDY | 伙伴模式 |
代码中散布着以 BQ 开头的生产教训注释。这些注释记录了真实的线上事故，每一条都是用真金白银的教训换来的工程经验。
| 日期 | 问题 | 影响 | 教训 |
|---|---|---|---|
| BQ 2026-03-22 | 工具 description 嵌入动态列表导致 cache break | 77% 的工具 cache break 来源于此 | system prompt 中的任何动态内容都会破坏 prompt cache。工具描述必须是静态的 |
| BQ 2026-03-12 | Bridge 连接失败模式 | 每周 147K 404 错误 + 22K WebSocket 关闭事件 | 网络层的失败必须有优雅降级策略，不能让失败的连接持续重试浪费资源 |
| BQ 2026-03-10 | 自动压缩死循环 | 1,279 个 session 连续失败 3,272 次，日均浪费 25 万 API 调用 | 任何自动化流程都需要断路器机制，防止失败无限循环 |
| BQ 2026-03-01 | 压缩后 cache baseline 未重置 | 20% cache break 事件是误报 | 状态重置必须和状态变更同步，漏掉任何一个重置点都会导致级联错误 |
这些注释本身就是极有价值的工程经验。 它们展示了在大规模 AI Agent 系统中，哪些看似不起眼的设计细节会导致严重的线上问题。特别是 2026-03-10 的自动压缩死循环事故，日均浪费 25 万 API 调用，如果按照 Claude API 的计费标准，这意味着每天数千美元的无效开销。
对于正在构建 AI Agent 系统的工程师来说，这些生产教训比任何设计模式书籍都更有实践价值。