在 Claude Code 的代码中，如果只算 KAIROS 出现的次数，其出现了 154 次；如果算上以其为前缀的变量啥的，其出现了 365 次。

KAIROS 是什么？

简单来说，KAIROS 是 Claude Code 未来的 AI 形态，一个在恰当时机出现的，一直在线的协同工作伙伴。

KAIROS (καιρός) 源自古希腊语，意为「正确的、关键的或合宜的时刻」，代表定性的、超越时序的「时机」或「关键瞬间」。

KAIROS 这件事，重点从来不在于它多了几个工具开关，也不在于文档里写了多少「常驻助手」「主动工作」这种产品话术。它真正改变的，是 Claude Code 的运行范式：从「终端里的同步问答器」，切到「长期在线、异步协作、跨渠道接入、能自己维持工作节奏的常驻代理」。

这个变化很大。大到我不太愿意把它叫成一次功能升级。它更像一次产品类别切换。

如果这个方向跑通，Claude Code 的竞争对象会变。它不再只是和一批 coding assistant CLI 去比「补全快不快、命令懂不懂、上下文长不长」。它会开始进入另一条赛道：谁更像一个持续在线的工程协作者，谁能承接跨时间、跨终端、跨系统的工作责任。

问题也在这里。KAIROS 现在的仓库状态，远没有到「产品封版」的程度。外围能力已经长出不少，主闭环还没彻底打穿。Bridge、Brief、频道消息、每日记忆日志、后台任务基础设施，这些都不是 PPT。assistant 主入口、gate、proactive 状态、session discovery 这些地方，又明显还是 stub。方向很清楚，骨架也搭起来了，真正决定产品能不能稳定落地的那几条主链路，还差最后一截硬骨头。

这篇文章我们不按功能清单来复述一遍。那样太浅，也没工程价值。回答三个关键的问题：

1. KAIROS 在 Claude Code 里到底重新定义了什么
2. 它已经落地了哪些关键能力，哪些地方还没闭环
3. 为什么它必须改写记忆系统、交互渠道和执行模型

KAIROS 改写的不是功能，是运行模型

普通 CLI 的交互模型很简单。

用户打开终端。输入一条指令。模型分析上下文。调用工具。给出回答。进程结束，或者这一轮逻辑结束。下一次再来，虽然可能还能靠项目文件、历史记录、memory 文件接上一部分语境，但本质上还是新一轮同步请求-响应。

这个模式有一个天然上限：AI 只在用户看着终端的时候存在。用户不在，系统就不工作。外部事件来了，也接不住。长任务只能靠用户盯着。跨设备继续工作这件事，基本也无从谈起。

KAIROS 想改掉的，就是这个上限。

它想要的模型是另一种结构：

• 会话可以长期存在
• 进程重启后还能接回原来的会话
• 外部系统可以把消息推到这个会话里
• 用户没有新输入时，Agent 也能继续推进任务
• 工作状态通过记忆、日志和摘要维持
• 输出形态适配异步消费，而不是只适配终端前的一次性阅读

这不是「更主动一点」。这是一整套运行时假设变了。

我一直觉得，很多人看这类能力时容易掉进一个误区：看见 SleepTool、push notification、channels，就以为这只是「给 CLI 加点自动化」。这个理解有点太保守。真正的变化是，系统开始假设自己是一个持续值班的实体，而不是一个按回车键才苏醒的函数调用。

一旦假设变了，后面的东西都会跟着变。会话管理会变。记忆策略会变。输出格式会变。安全边界会变。成本模型会变。产品定位也会变。

从代码现状看，KAIROS 已经是一组能力家族

从文档和源码状态看，KAIROS 不是单点 feature flag，它更像一个能力总开关，把若干子系统串成一个共同叙事。

已有的子功能包括：

• KAIROS_BRIEF
• KAIROS_CHANNELS
• KAIROS_PUSH_NOTIFICATION
• KAIROS_GITHUB_WEBHOOKS
• KAIROS_DREAM

工具注册层能看到对应工具：

• SleepTool
• SendUserFileTool
• PushNotificationTool
• SubscribePRTool

从这些就可能看到背后对应的产品动作：

• 控制执行节奏和保活
• 主动把结果回传给用户
• 在终端外做异步通知
• 订阅外部事件，反向驱动内部执行

这里最值得注意的是其产品动作的形态已经变了。

传统 CLI 工具的动作集合通常是：

• 读文件
• 写文件
• 执行命令
• 输出结果

KAIROS 的动作集合变成：

• 等待
• 监听
• 回传
• 唤醒
• 跨渠道接入
• 持续维持上下文

这说明它的定位已经不再是单纯的「本地操作器」。它正往「工作流中枢」走。

Bridge 是 KAIROS 最关键的基础设施之一

KAIROS 能不能成立，第一件事不是主动性，而是连续性。

如果会话不能连续存在，所谓常驻助手就是假的。它最多是一个本地守护进程。用户侧体验还是断裂的。今天在一个终端开的事情，明天换个终端、换个设备、换个入口，就接不上了。那这个产品心智根本立不起来。

Bridge 正是在补这个问题。

从现有设计看，Bridge 的数据流：远端入口收到用户消息，通过 bridge 拉取工作，创建或恢复 REPL，会话继续执行，再把结果回传。这个思路解决的是「用户感知到的是不是同一个持续存在的助手」。

代码里关键点在 useReplBridge。assistant 模式下会启用 perpetual bridge session，目的是让远端看到的是同一条持续会话，而不是每次 CLI 启动都开一条新的 session。

没有 perpetual session，用户面对的是很多段相似但断裂的对话。每次恢复都像重新认识一次项目。上下文可能靠 memory 拼回来一点，但主观体验一定是断的。

有了 perpetual session，用户会开始把这个东西当成「同一个一直在线的协作者」。这就是范式变化真正落地的第一步。

但真实闭环卡住的地方，不在 Bridge 本身

Bridge 骨架基本有了，assistant 产品主链路还没闭环。

很多团队做 Agent 系统时，最容易陷入一种错觉：底层传输能通，远程会话能恢复，消息能送达，就以为产品主路径已经打通。其实不是。通道打通，只代表系统能传递状态。离「一个稳定可用的常驻助手产品」还差几个关键层：

• 身份判定
• gate 放行
• 会话发现
• assistant 专属上下文初始化
• assistant 专属系统提示
• 持续工作状态机
• 长期记忆蒸馏

当前源码里，这些都还没有。

assistant 主入口还是 stub

assistant 主模块里，isAssistantMode() 返回 false，初始化函数是空的，assistant 专属 prompt addendum 也是空的。

这意味着什么？

意味着一大堆外围逻辑虽然预留了 assistant 分支，但真正运行时根本进不去。Bridge 想按 assistant 模式走 perpetual session，要靠 isAssistantMode()。主程序想按 assistant 模式切换运行逻辑，也要靠它。远端 worker 类型的区分，还是要靠它。

入口判定没实现，后面这条链就全断了。

KAIROS gate 还是 stub

isKairosEnabled() 直接返回 false，这表示：产品级放行逻辑还没接上。

这不是个小洞。因为常驻助手和普通 CLI 完全不是一个风险等级的东西。它能后台执行、接外部消息、长期持有上下文、主动做事。没有真实 gate，这种能力根本不适合大面积开。

所以从工程视角看，gate 现在是缺实现。从产品视角看，这代表「产品入口控制逻辑还停留在骨架层」。

session discovery 还是 stub

如果用户执行 assistant viewer 路径，系统理论上应该能发现已有常驻会话，然后接回去。现在 discovery 返回空数组，这条体验链路就断了。

这直接伤到产品最核心的承诺之一：会话连续性。

你都号称是常驻助手了，结果用户回来时找不到自己之前那条会话，这个心智会瞬间塌掉。

proactive 状态模块还是 stub

KAIROS 的 prompt 层已经开始定义 autonomous work 的行为协议了，比如：

• 没有事做时必须 sleep
• 用户不在终端前时偏向自主推进
• 用户正在看终端时偏向协作和简洁输出

行为协议有了，状态机没落地。

KAIROS 最大的区别，不是工具多，而是 prompt 协议变了

对于 Agent 系统，prompt 在很多时候就是运行协议的一部分。

普通模式下，模型更像一个执行器。收到请求，完成任务，给出答复。

KAIROS 模式下，prompt 在定义另一种工作方式：

• 什么时候该自己推进
• 什么时候该停下来等待
• 什么时候该用 Brief 压缩输出
• 什么时候该把结果异步推给用户
• 用户是否在终端前，会影响表达风格和协作策略
• 没有明确工作时不能空转，必须 sleep

这本质上是在给模型灌输一套「值班协作者协议」。

因为常驻助手和一次性问答器的差别，很大一部分在于它是否具备稳定的工作节奏。节奏不稳，再强的工具集也会把系统拖进两个极端：

• 一直唤醒，疯狂消耗 token 和 API 调用
• 一直沉睡，错过事件和推进时机

所以 SleepTool 这种东西，表面看是个小工具，本质上是在为 Agent 增加时间维度。普通 CLI 处理的是空间里的资源：文件、命令、输出。KAIROS 开始处理时间里的资源：等待、唤醒、周期、空闲、值班。

这一步一旦做出来，产品形态就变了。

KAIROS 为什么必须改写记忆系统

这里必须要聊一下。

在长任务中，我们不能拿短会话的记忆模型去硬撑长时间在线系统。写放大、污染、冲突、检索噪音、摘要失真，很快全出来。

KAIROS 在这件事上切到了 daily log 模式。

普通模式下，长期记忆更接近「主题文件 + 索引」：

• 新信息被整理成相对成型的 topic files
• MEMORY.md 维护索引
• 模型下次需要时按主题读回

这个模式适合短周期会话。信息密度高，整理成本还能接受。

KAIROS 场景不一样。它面对的是：

• 长时间持续执行
• 高频事件流输入
• 用户不一定实时盯着
• 外部渠道消息可能随时插入
• 同一天内工作状态会不断变化
• 大量信息是过程态，不适合立刻主题化

如果还按普通模式那种「一有信息就整理成 topic file」去写，工程上会出三个明显问题。

第一，写放大会很严重

频繁改 topic files，会导致目录不断抖动。MEMORY.md 也会被频繁重写。对于常驻系统，这种写入模式很不稳。量一上来就开始恶心人。

第二，过程信息会过早结构化

很多工作过程在当下并不适合写成结论。比如一条外部消息、一次等待中的验证、一个还没确认的假设、某项任务中间状态。这些东西如果过早塞进长期记忆，很容易污染后续上下文。

第三，恢复和追溯会变差

当你把所有信息即时揉进主题文件里，原始事件流会逐渐丢失。系统后面做蒸馏、回溯、纠错时，材料反而不够。

daily log 方案就是为了解这些问题。

它的核心思想很简单：

• 白天先 append-only 记录到当日日志
• 不急着重组和提炼
• 后续再把成熟信息蒸馏成长期 memory

这是典型的事件流优先设计。先保留工作轨迹，再做结构化提炼。对常驻助手来说，这个方向很稳。

普通模式里的 memory 是模型的记忆补丁，KAIROS 里的 memory 是产品连续性的基础设施。

这两者不是一个级别的东西。

transcript 被纳入记忆蒸馏

KAIROS 还想做一件更重要的事：把 session transcript 也纳入记忆蒸馏输入。

这意味着长期记忆的来源，不再只靠模型「当前轮总结出的信息」，而是开始吸收完整工作轨迹。

你可以把这理解成两种 memory 策略的差异：

普通模式

长期记忆主要存「结论」

KAIROS 模式

长期记忆想从「事件流」中提取结论

因为一个持续在线的协作者，真正有价值的上下文往往不只在最后结果里，还在过程里：

• 谁在什么时候发来过什么消息
• 某项任务等待了多久
• 哪个验证步骤失败过
• 某个方向为什么被放弃
• 同一项目在不同日期里怎么演化的

如果记忆系统拿不到这些过程信息，系统就只能越活越像一个失忆的执行器：只记结论，不记来路。

当前仓库里这条链还没补齐，session transcript 相关实现还是 stub。当把普通 auto-dream 关闭，改走 KAIROS 专属 dream 路径，那就必须有足够材料来做蒸馏。daily logs 和 transcript 就是这个材料池。

没有材料池，dream 只是概念。
没有蒸馏，daily log 只是堆积。
没有长期记忆收敛，常驻助手就只剩「一直在线」，没有「越用越像同一个协作者」。

Brief 不是 UI 花活

它是异步协作场景里的输出压缩层

我很喜欢 KAIROS 里对 Brief 的定位，因为这个点很多产品会忽略。

一旦系统进入长期运行、跨终端、跨渠道、还带移动端通知的场景，传统那种长篇回复会迅速失效。不是模型写不出来，而是用户根本没法消费。

你想象一下：

• 一个后台任务跑了两小时
• 外部 webhook 触发了一轮检查
• Slack 里推来一条状态更新
• 用户此时在手机上看通知

这时候如果系统还按终端里的详细答复风格，甩一大段解释文字出去，体验会很差。信息密度低，确认成本高，真正关键的状态反而埋住了。

Brief 的价值就在这里。它是异步工作场景的输出压缩层。

它解决的不是「怎么更优雅地显示」，而是「在不同消费界面里，用最低认知成本传递足够状态」。这是一个工程问题，不是文案问题。

所以我会把 Brief 看成 KAIROS 的必要配套，而不是锦上添花。没有它，常驻助手很容易被自己的输出拖死。

channels 让 Claude Code 开始脱离终端边界

KAIROS 另一条很重要的线，是频道消息系统，也是一个很让人期待的逻辑，虽然当前有一些方法已经可以实现。

当前设计已经允许外部消息通过 channel notification 之类的机制进入会话，被包装成结构化消息再投递给模型处理。这意味着：

• Claude Code 不再只属于一个本地终端
• 用户可以在终端外部和同一条工作流继续互动
• AI 可以成为跨渠道的工作代理

这个变化一旦做成，产品就会从 Developer Tool 往 Agent Platform 滑过去。

再直白一点。

终端工具的边界，是「你必须来到我的界面里，我才能帮你做事」。
工作流代理的边界，是「我能在你的工作流里持续存在，你在哪个入口出现，我都能接上」。

这是两种完全不同的产品位置。

这样，channels 就很重要了，但不该排在最前面的优先级。因为它解决的是入口扩展问题，不是主闭环问题。一个内部还没站稳的系统，入口接得越多，事故面越大。没有 assistant 激活链、记忆蒸馏链和 proactive 状态机托底，channels 只会让问题更快暴露。

后台执行是一等能力，不是附属能力

KAIROS 把后台执行推成一等能力。

这是常驻助手能否成立的另一条底线。

如果 Agent 像同事一样持续工作，它就不能被单次命令执行周期绑死。用户离开终端，任务还得继续跑。长任务不能把主线程挂住。等待回调、监听事件、轮询状态这些行为，不能都靠用户盯着终端来维持。

很多 coding assistant 在 demo 阶段看起来很聪明，一到真实项目就暴露上限：用户一旦离开终端，整个系统的价值密度就迅速下降。长任务没人接。回调没人等。状态没人维持。所谓 Agent，最后还是个问答器。

KAIROS 显然想突破这个上限。

后台执行一旦变成一等能力，系统复杂度会明显上升。你要处理：

• 阻塞任务后台化
• 任务状态跟踪
• 唤醒与恢复
• 错误回传
• 与记忆系统的状态对齐
• 与通知节奏的协调

这些东西没有一项是白送的。做不好，后台任务会变成后台事故。

KAIROS 的产品价值，核心在五个地方

如果从产品结果看，我会把它的价值拆成五个方面。

一，留存会显著提升

一次性问答工具的留存天然一般。因为每轮交互都相对独立，用户用完就走。上下文积累浅，切换成本低。

常驻会话、跨重启续接、长期记忆、异步回传这些东西组合起来，用户会开始把 Claude Code 当成「当前项目的长期协作体」。一旦心智变成这样，迁移成本就会明显上升。

二，任务完成度会提升

很多高价值任务不是一轮 prompt 能做完的。它们需要等待、重试、监听、回调、验证、持续推进。普通模式下，这类任务经常会在用户离开终端时中断。

KAIROS 提供的后台执行、sleep 唤醒、外部事件驱动，正好在补这个缺口。产品会从「答题器」往「任务执行器」走。

三，渠道覆盖会扩大

有了 channels、push、bridge、webhook，Claude Code 的触点会明显增加。对产品运营和组织传播来说，这个价值非常直接。一个只能在终端里使用的工具，天然局限在一小撮高频命令行用户。一个能进入 Slack、移动通知、远程 viewer 的系统，扩散面会大得多。

四，粘性会增强

session continuity、daily logs、structured brief、跨渠道接续，这几样东西叠在一起，会形成很强的黏着效应。用户会越来越依赖它手里的上下文。上下文越深，替换成本越高。

五，产品想象空间会被抬高

做到这里，Claude Code 的竞争对象就不再只是其它 coding assistant。它会开始接近「开发团队的操作层代理」：监听、执行、回报、沉淀记忆、跨渠道协作。

KAIROS 的代价非常重

讲到这里如果只谈价值，那就是宣传稿了。工程里没有这么轻松的事。

KAIROS 的代价主要有四类。

第一，系统复杂度暴涨

从一次性 CLI 进入常驻模式后，系统要处理的东西会指数级增加：

• 长生命周期会话
• bridge 重连
• 会话恢复
• 远端消息幂等
• 外部事件接入
• 后台任务状态
• 唤醒节奏
• 记忆蒸馏
• 多渠道权限边界
• 通知频率控制

这些全都会增加测试成本、排障成本、回归成本。

传统 CLI 很多问题是可复现、可局部调试的。常驻 Agent 的问题常常是跨时间、跨系统、跨状态累积的。定位难度完全不是一个量级。

第二，成本模型会变差

tick + sleep 这套机制，本质上是在用更多调用换取持续在线行为。架构会更顺，产品体验会更强，API 成本也会上去。

如果没有很严格的唤醒控制、任务优先级控制和输出压缩策略，系统会非常烧钱。尤其当常驻会话一多，哪怕每个会话只是周期性地「看一眼有没有事」，成本都可能迅速放大。

很多团队做 Agent 产品，死得最早的往往不是能力不够，是成本失控。KAIROS 这条路如果真要产品化，成本治理必须和功能迭代同步推进，不能等做大了再补。

第三，安全与信任门槛会更高

一个普通 CLI 助手，最多是「用户下命令，它帮你执行」。
一个 KAIROS 式常驻助手，是「它持续持有上下文，接外部消息，可能在后台自主执行」。

这两个系统的风险等级完全不同。

assistant 模式下先检查 trusted directory，再检查 KAIROS gate，这个设计信号已经很明确：作者知道风险在上升。问题是现在 gate 还是 stub，主链路还没完全接上，说明这块还在建设中。

产品能不能卖进团队、卖进企业，很多时候就看这里。因为企业不会只问「它能做什么」，他们会问得更直接：

• 它什么时候能自己执行
• 谁能给它发消息
• 它能看到哪些目录
• 它会把什么记下来
• 它错了怎么停
• 它怎么审计

这些都是 KAIROS 必须正面回答的问题。

第四，产品承诺和实现闭环还没完全对齐

这是当前最现实的问题。

外围能力铺得已经不少，主入口和主状态层仍然有 stub。这个状态很典型：战略方向先行，支撑设施先铺，真正的产品主通路还在补。

这种状态有机会，也有风险。

机会在于，一旦主入口补齐，成长速度可能很快，因为外围都在等它。
风险在于，如果主闭环补得太慢，外围越多，系统越像「展台很大，地基不稳」。

为什么我认为 KAIROS 是整个项目里最重要的方向

因为它决定的不是某个 feature，而是产品类别。

没有 KAIROS，Claude Code 依然可以是一个很强的 coding assistant CLI。
有了 KAIROS，而且真做成了，它会变成一个持续在线、能跨渠道、能长期记忆、能异步执行的工程助手。

这两者在商业形态上不是一个东西。
在用户心智上不是一个东西。
在组织采购逻辑上也不是一个东西。

对个人开发者，这意味着「我下班以后，它还能继续跑」。
对团队协作，这意味着「我们多了一个持续在线的 AI teammate」。
对企业管理者，这意味着「AI 被接入的是工作流，不是单次问答」。

这三层价值如果连起来，产品天花板会明显抬高。

我甚至会说，KAIROS 成不成，决定了 Claude Code 最终是一个强工具，还是一个强平台。

当前仓库里，KAIROS 的真实成熟度如何？

大概是四点：

• 产品意图非常清楚： 因为从文档、prompt、memory 策略、bridge 设计、channels、brief，到后台任务工具，整个方向是一致的。不是东一块西一块拼起来的。它们都在服务同一个产品叙事：把 Claude Code 推成常驻助手。
• 框架布线已经做了很多： 工具层、提示词层、bridge 层、memory prompt 分叉、channel notification、部分 viewer 路径，这些都已经不是空想。它们证明团队不是在写概念文档，而是在提前铺路。
• 关键外围能力有真实实现：Bridge perpetual session、频道消息接入、Brief 规则、daily-log memory prompt，这些都具备产品骨架。哪怕主入口还没封口，外围支撑已经能看出最终形态。
• 主入口和核心状态闭环仍有明显缺口：assistant 主模块、gate、session discovery、proactive 状态、session transcript 等地方的 stub，说明核心闭环还没完全长实。这个阶段我会把它定义为：接近产品化的战略子系统，而不是一个完整封版的功能包。

KAIROS 的本质，是把 Claude Code 从「提效工具」推向「责任承接者」

文章写到这里，其实主已经很清楚了。

KAIROS 真正改变的，是 Claude Code 的「存在方式」。

普通 Claude Code 的存在方式是：用户打开终端，它出现；终端关闭，这轮交互的主价值结束。
KAIROS 的存在方式是：用户不在场时，它仍然能持有状态、接收事件、维持节奏、积累记忆、回传结果。

它在把 Claude Code 从前台交互工具，推向后台协作代理。

一旦这个方向跑通，产品的护城河也会变。将来真正难被替代的，不只是模型回答质量，而会落在这些更重的东西上：

• 上下文沉淀深度
• 渠道接入深度
• 工作流嵌入程度
• 组织内协同能力
• 长期责任承接能力

这才是 KAIROS 值得持续投入的原因。

小结

KAIROS 已经完成了产品方向的自洽，完成了相当一部分外围基础设施铺设，正在卡在主入口、记忆蒸馏和自主循环这三条上。只要这三条主链补齐，它很快就会从「战略子系统」变成「真正定义 Claude Code 下一阶段的核心产品」。

这件事一旦做成，Claude Code 的故事就不再是「一个更强的 coding assistant CLI」。

它会变成另一个东西。

• 一个持续在线的工程协作者。
• 一个能接进团队工作流的后台代理。
• 一个真正开始承接持续工作责任的 AI 系统。

这才是 KAIROS 的星辰大海。

以上。