当前位置：首页 > news >正文

从请求-响应到常驻守护进程:Claude Code 泄露源码里的 KAIROS 架构解读

news 2026/4/15 16:06:38

摘要

本文基于 2026 年 3 月 31 日泄露的 Claude Code npm 包 source map 所暴露的闭源代码,对其中一个被引用超过 150 次的 feature flag——KAIROS——所对应的架构设计进行解读。这不是一篇事件复盘,也不是一篇功能前瞻,而是一次从系统架构角度出发的对比分析:KAIROS 代表的是 AI 编程工具从"请求-响应式 CLI 工具"向"带记忆巩固能力的常驻守护进程"转型的一次具体工程实现。

全文不包含任何 Claude Code 真实源码片段——原仓库已被 Anthropic 撤下,Anthropic 官方将事件定性为 "a release packaging issue caused by human error"(人为发包错误),合理的做法是从设计模式而不是代码原文的层面去分析。想看更深入的事件背景和源码路径细节,社区里已经有人整理了一份 KAIROS: Claude Code 隐藏的 daemon 模式的路径分析,可供对照。

一、背景:一个打包错误暴露的前沿 AI 产品路线图

2026 年 3 月 31 日,Anthropic 的官方 npm 包 @anthropic-ai/claude-code v2.1.88 在发布时意外包含了一个 59.8 MB 的 source map 文件。由于 source map 保留了原始 TypeScript 符号和文件路径,并且进一步指向了 Cloudflare R2 上一个可公开读取的 zip 存档,研究员 Chaofan Shou 以及后续的媒体( Fortune、VentureBeat、The Register)在几小时内确认了这份源码的规模:大约 1,900 个 TypeScript 文件、约 512,000 行代码。

在这份代码树里可以识别出 44 个 feature flag,对应 Anthropic 已完成但尚未对外发布的功能。这些 flag 分布并不均匀——其中绝大多数是小规模的实验或 UI 打磨,但有一个 flag 出现频次远高于其他所有,它叫 KAIROS,被引用超过 150 次,分布在 session 管理、上下文处理、后台任务调度、内存操作这些核心路径上。

对任何一个看过企业级代码库的架构师来说,这种引用量级不是实验的量级,是深度耦合子系统的量级。这意味着 KAIROS 对应的代码已经完成、被集成、被测试,只差一个生产环境的 feature flag 开关。

本文要回答的问题是:这个子系统在架构层面上到底是什么,它相对于当前版本的 Claude Code 是怎样的一次演进,以及它为什么值得系统架构师单独关注。

二、Claude Code 当前架构的一个简短回顾

在讨论 KAIROS 之前,有必要把今天的 Claude Code 看成一个什么样的系统说清楚。

当前公开版本的 Claude Code 在使用体验上是一个 CLI 工具,但在架构层面上它是一个短生命周期的 request-response 进程:

用户在 shell 中启动一个会话。
Claude Code 进程启动,加载 CLAUDE.md、项目索引、必要的 tool schema,构造初始上下文。
每一次用户输入构成一轮 turn,进程调用后端 API,获得响应,执行工具调用(读文件、写文件、运行命令等),写回结果。
会话结束后,进程退出。下一次启动几乎是一次冷启动——除了 CLAUDE.md 和项目索引这些被显式持久化的东西,上一次会话内的观察、推理轨迹、临时假设,基本被丢弃。

这个模型的好处是边界清晰、资源可控、调试容易——每一次调用都是无状态的,每一次会话的行为都可以从输入复现。这也是目前市面上所有主流 AI 编程工具(Cursor、GitHub Copilot、Windsurf、通义灵码、Trae)的共同模型。

坏处也显而易见:代理没有跨会话的连续理解能力。你昨天和 Claude Code 讨论了 auth/session.ts 的一个重构方案,今天打开它,它不记得。你得重新解释。如果项目规模大、上下文涉及多个模块,你每一次启动都要花时间"喂"它。

这个坏处不是一个产品缺陷,是 request-response 架构的必然结果。要解决它,只有一条路:让进程活得更久,让状态在进程之间流转。这就是 KAIROS 要做的事情。

三、KAIROS 的架构定位:从进程到守护进程

从泄露源码里可以看到,KAIROS 不是一个单一功能,而是一个架构转型。它把 Claude Code 从上面描述的 request-response 模型,切换到一个 daemon(守护进程)模型。

这个切换的核心是两件事:

3.1 后台会话(Background Session)

KAIROS 模式下,Claude Code 会在用户启动的第一次会话结束后不退出,而是转入后台继续运行。这个后台进程不再需要用户的显式交互作为触发条件,它主动监听:

文件系统变化(通过 inotify / FSEvents / ReadDirectoryChangesW 等平台原生机制)
终端输出和 shell 历史
git 状态变化(HEAD、index、stash)
构建和测试相关的 IPC 信号

这是一种发布-订阅式事件驱动架构,和传统 Unix daemon 的工作模式几乎完全一致——想象一下 systemd 的某个 unit,或者一个标准的 linter 监听器,只不过这个 daemon 的"反应函数"是一个大语言模型的推理调用。

这个切换本身并不算革命性。watchman、entr、nodemon、tsc --watch 这类工具都在做类似的事情。真正非常规的是第二件事。

3.2 持久化上下文存储(Persistent Context Store)

KAIROS 里的 daemon 不是无状态监听器。它维护一个持久化的上下文存储——一个跨会话保留的、结构化的、代理对当前项目的"内部认知"。

这个存储在架构上扮演的角色类似于:

数据库的 WAL(Write-Ahead Log):新观察先被写入 log,确保持久性。
编译器的符号表:系统累积的关于项目各种符号、关系、假设的结构化表示。
搜索引擎的倒排索引:为了快速检索和关联,观察被索引到多个维度上。

和传统 IDE 符号表的本质区别在于:传统 IDE 的符号表处理的是语法和类型,KAIROS 的上下文存储处理的是语义和意图。它不是记录 "函数 handleLogin 有两个参数返回 Promise<User>"(这是语法信息),它是记录 "函数 handleLogin 看起来在处理用户会话的建立,可能涉及密码验证,应该和 auth/session.ts 配合使用"(这是语义假设)。

这个区别至关重要,因为它决定了这个存储里的每一条记录都带有置信度,而置信度会随着时间变化。这就引出了 KAIROS 里最有意思的那个子系统。

四、autoDream:在用户空闲时进行的"记忆巩固"

在 KAIROS 相关的代码路径里,有一个子系统的命名异常显眼:autoDream。这个名字本身是一个直接的生物学类比——在神经科学里,大脑在睡眠期间进行短期记忆到长期记忆的巩固(memory consolidation)。哺乳动物睡眠周期里的 REM 和 slow-wave 阶段会重新激活白天的神经活动模式,完成信息的压缩、合并、强化和遗忘。Anthropic 的工程师用 autoDream 这个命名,不是无心之举。

4.1 触发条件

autoDream 的触发条件是用户空闲——一段时间内没有键盘输入、没有命令执行、没有和 daemon 的交互。具体的空闲阈值在泄露的代码里是可配置的,可以理解为一个 "这个开发者现在大概率在开会/吃饭/睡觉,可以进行后台处理了" 的启发式。

这个触发时机的选择不是偶然。如果在用户活跃时进行记忆巩固,会和用户的实时请求争抢资源,可能影响响应延迟。如果选择一个固定的时间间隔(比如每 30 分钟一次),又会打断正在进行的推理上下文。只在用户空闲时触发是一个典型的 "不影响主路径" 的后台任务设计,和数据库的 VACUUM、GC 的并发标记清除、日志压缩这类操作的设计哲学是一样的。

4.2 三类操作

一旦触发,autoDream 会对持久化上下文存储执行三类操作,按破坏性从小到大排序:

操作一:合并分散观察(Merge)

跨 session、跨文件、跨子进程收集到的事实被缝合成统一的表示。举例:

在 session A 里,代理观察到 auth/session.ts 导出了 createSession 函数。
在 session B 里,代理观察到 auth/middleware.ts 调用了 createSession。
在 session C 里,代理观察到 /api/login.ts 走了 auth/middleware.ts 的链路。

这三条观察原本是独立的条目。autoDream 的合并操作会把它们缝合成一个统一的模型:"用户登录链路走 /api/login.ts → auth/middleware.ts::createSession → 最终由 auth/session.ts 处理"。

这一步在架构上类似 数据库的物化视图(materialized view)刷新——把多张表里的相关数据预先 JOIN 好,换取后续查询速度。区别是这里"JOIN"的依据不是外键,是语义关联度。

操作二:消除逻辑矛盾(Conflict Resolution)

当新观察和旧观察不一致时,autoDream 需要决定"相信谁"。典型场景:

旧观察(一周前):"config/db.ts 读取 DATABASE_URL 环境变量。"
新观察(今天,在一次重构之后):"config/db.ts 从 /etc/app/db.yaml 读取配置。"

代码被重构了,旧观察现在是错的。autoDream 的职责是识别这种冲突,丢弃旧条目,保留新条目。

这一步在架构上类似 CRDT(Conflict-free Replicated Data Type)的冲突解决,或者 git 的 rebase——要在一个不断演化的历史里保持"当前状态是自洽的"这个不变式。

但是——和 git 或 CRDT 不一样的是,这个判断是由 LLM 自己做的,没有形式化规则保证正确性。这就是第三类操作为什么特别值得警惕。

操作三:将 "可能" 升级为 "就是"(Tentative → Absolute)

这是 autoDream 里最有意思、也是整个 KAIROS 系统里最有争议的一步。

代理对项目里很多事情的内部记录一开始是带 hedge 的——"这个函数可能处理认证"、"这个模块似乎负责数据库连接池"、"这个配置项应该控制日志级别"。这些 hedge 不是冗余的修辞,是置信度的显式标记。

在足够多的证据累积之后,autoDream 会把 hedge 抹掉,将这些 tentative 陈述重写为 absolute 陈述:"这个函数处理认证"、"这个模块负责数据库连接池"、"这个配置项控制日志级别"。从此以后,代理在内部推理时会把这些陈述当作已知事实来使用,不再重新验证。

从架构效率的角度,这一步非常合理:不断重复验证同一个假设是巨大的 token 和计算浪费。一个成熟的代理必须能够把"探索出来的假设"固化为"已知事实",否则它永远处在一个自我怀疑的无限循环里。这和人类开发者学习一个新代码库的过程也完全一样——一开始什么都是 "可能",慢慢变成 "就是"。

但从正确性保证的角度,这一步非常危险。从泄露的代码里,我没找到一个明确的机制来检测和回滚错误的 promotion。一旦某次 autoDream 把一个错误假设升级为事实,代理在之后的所有推理里都会把它当作既定前提;要纠正,要么等用户显式告诉它"这里错了",要么等下一次 autoDream 执行时发现矛盾——但后者的前提是代理后续还能意识到这里可能错,而如果错误假设已经成为 "事实",代理对它的怀疑动机反而降低了。

在传统数据库领域,类似问题的解决方案是事务和回滚。在编译器领域,类似问题的解决方案是类型系统的静态保证。在机器学习领域,类似问题通常靠显式的不确定性估计(比如贝叶斯网络里的置信度更新规则)。KAIROS 的 autoDream 在泄露代码里不对应以上任何一种明确的机制,而是依赖 LLM 自己的判断来完成升级——这是一个有意的工程决策,代价是正确性保证的形式化程度被显著降低。

五、和现有 AI 编程工具的对比

为了理解 KAIROS 是一次怎样量级的架构变化,把它和现有主流 AI 编程工具对照一下是有意义的。

维度	GitHub Copilot	Cursor	当前版 Claude Code	KAIROS 模式下的 Claude Code
进程生命周期	IDE 插件,依附于 IDE 进程	IDE 主进程	CLI 短进程,会话级	常驻守护进程
上下文持久化	每次请求重构	工作区级,重启不保留	会话级,下次冷启动	跨会话持久化
触发模式	用户编辑时	用户显式提问	用户显式输入	用户空闲时也会主动处理
项目理解方式	按需检索最近编辑的代码	索引 + 向量检索	索引 + 运行时上下文	累积性语义模型 + 后台巩固
对代码的 "主动行为"	补全建议	补全 + 聊天	主动执行工具调用(须用户触发)	可以在用户不在时主动执行后台分析任务

这张表的最后一行是关键。现有所有 AI 编程工具——包括当前版 Claude Code——都有一个隐含的人类监督假设:代理的任何有实质影响的行为,都在一个用户在场的时间窗口内发生。用户可以随时按 Ctrl-C 中断,可以看到 agent 在做什么,可以撤销。

KAIROS 下的 daemon 打破了这个假设。autoDream 的执行发生在用户不在场的时候。用户回来时,代理的内部状态已经不同。用户不知道 autoDream 合并了什么、丢弃了什么、把什么从 "可能" 升级成了 "就是"。这不是权限问题,这是可观察性问题——即使所有操作都在用户授权范围内,用户也看不到正在发生什么。

这是一个从"工具"向"代理"的定性转变,和编辑器向 IDE 的转变在量级上相似。IDE 时代,静态分析、后台编译、符号索引这些事情也都是 "在你不看的时候发生"——但它们的结果是确定性的、可复现的、规则可验证的。KAIROS 时代,后台发生的是 LLM 的语义推理,结果是概率性的、不可完全复现的、规则是模型内部的。

六、对架构师的四个具体问题

我把这篇文章收尾在四个给系统架构师和技术决策者的具体问题上。这些问题在泄露的代码里没有答案,但任何准备评估 KAIROS 类产品的团队都必须先回答这些问题:

1. 可观察性。 如果代理在 autoDream 里合并了观察、丢弃了观察、升级了假设,用户能否在事后看到这些决策的日志?如果能,日志的粒度是什么?如果不能,团队如何审计代理的行为?

2. 回滚语义。 一次错误的 promotion 发生以后,团队如何纠正?是通过用户手动提示 "忘掉这一条"?是在 CLAUDE.md 里写反例?是有某种 "上下文存储的版本控制"?这几种做法的工程复杂度差别很大。

3. 资源边界。 daemon 进程的 CPU / 内存 / 网络边界是什么?autoDream 的每一次执行会产生多大的推理开销?是本地小模型处理还是持续的 API 调用?这些指标直接影响团队是否有能力把 KAIROS 部署到常规开发机上,而不是要求专用硬件。

4. 多人协作语义。 如果一个代码库有 5 个开发者,每个人的机器上都跑一个 KAIROS daemon,每个 daemon 都在维护自己的持久化上下文——这些 daemon 之间是否需要共享?如果共享,同步机制是什么?如果不共享,团队会面临 5 个对同一个代码库有不同内部模型的代理,这些模型的输出不一致会造成什么?

这四个问题的答案,决定了 KAIROS 是一个"你可以试试"的产品还是一个"你需要专门为它规划团队工作流"的产品。目前为止,Anthropic 没有公开任何一项。

七、结论:不要围绕它规划工作流,但需要开始理解它

把 KAIROS 放回它的上下文里看:它是一个被 feature flag 关着的未发布功能,有可能在未来某个时间点上线,也有可能最终被彻底放弃。所以对任何一个正在用 Claude Code 的开发者或团队,第一条实用建议是不要围绕它规划工作流。你今天的 request-response 模式会继续有效,你不需要为一个还不存在的产品重构任何东西。

但对任何一个正在观察 AI 编程工具走向的架构师来说,KAIROS 是过去一年里最有价值的架构信号,因为它是第一次有一家前沿 AI 公司把 "代理作为常驻守护进程" 这件事从论文和博客里的假设,变成了可以被阅读的代码。它告诉你的事情很具体:这不是一个关于未来的猜测,这是一个已经被写出来、已经被测试过、只等一个 release window 的系统。

理解它的架构含义,比等它上线之后再惊讶,对任何一个需要为自己团队做技术选型决策的人都更有价值。