Claude Code源码分析-- Kairos自动助手和OpenClaw Heartbeat与普通 Proactive 区别

Claude Code Kairos vs OpenClaw Heartbeat 深度分析日期2026-04-08结论先行如果只问一句“Kairos和OpenClaw heartbeat是不是一回事”答案是否定的。OpenClaw heartbeat更像“定时触发一次主会话 agent turn 的调度机制”。Kairos更像“长期在线自动助手模式”它把门控、系统提示、主动消息、持续会话、长期记忆、后台任务、调度能力拼成了一整套 runtime。Claude Code 里和 OpenClaw heartbeat 最接近的其实不是Kairos整体而是Proactive/Kairos共用的tick机制加上一部分调度能力。再往下拆OpenClaw heartbeat解决的是“多久自动醒一次、醒了往哪发、没事时怎么安静地 ack”。Kairos解决的是“被唤醒以后作为一个长期助手应该如何持续工作、记忆、协调、通知、恢复上下文”。所以两者不是同层概念heartbeat是调度触发层。Kairos是自治助手运行模式层。分析边界与可信度这份仓库里的Kairos不是完整源码。构建脚本把相关 feature 全部关掉了KAIROS: falseKAIROS_BRIEF: falseKAIROS_CHANNELS: falseKAIROS_DREAM: falseKAIROS_GITHUB_WEBHOOKS: falseKAIROS_PUSH_NOTIFICATION: false证据见claude-code-source/build.ts这意味着真正最核心的assistant/index.js、assistant/gate.js、commands/assistant/*在这份外部构建里已经被 dead-code elimination 干掉了。因此下面关于Kairos的分析是“基于可见调用点、注释、外围模块行为”的高可信架构重建而不是完整源码逐行复原。OpenClaw Heartbeat 是什么根据 OpenClaw 官方文档heartbeat 的定义非常明确它会“周期性地在主会话里运行 agent turn”默认间隔通常是30m它可以选择是否把结果投递到last、指定 channel或根本不外发它有明确的HEARTBEAT_OK应答约定用来在“没事发生”时避免打扰用户它支持lightContext、isolatedSession、activeHours、includeReasoning这说明 OpenClaw heartbeat 的设计重点是定时唤醒控制上下文成本控制对外投递控制“无事发生”时的安静确认官方文档原意可以概括成一句话heartbeat 是“scheduled main-session turn”不是 detached background task 记录系统。也就是说Heartbeat 不是后台任务引擎本体而是主线程上的周期性检查点。Claude Code 里真正与“heartbeat”同层的东西Claude Code 里至少有三种容易混淆的“心跳/唤醒”概念。1. Proactive/Kairos 的tick这是自治行为层的“唤醒提示”。在print.ts里scheduleProactiveTick()会用setTimeout(0)注入tick当前本地时间/tick然后把这个 meta prompt 重新塞回消息队列让模型继续“醒着”工作。证据claude-code-source/src/cli/print.ts:1831claude-code-source/src/constants/prompts.ts:860这个机制非常像 heartbeat 的“周期性唤醒”但它更偏向模型工作循环内部而不是 OpenClaw 那种带外投递、ACK 契约、目标路由都很明确的产品化调度层。2. CCR/Bridge 的 transport heartbeatClaude Code 还存在真正意义上的基础设施心跳。ccrClient.ts里写得很直接默认 heartbeat 间隔20s用于 worker liveness detection证据claude-code-source/src/cli/transports/ccrClient.ts:32这个 heartbeat 才是“进程/worker 存活上报”那类传统 heartbeat和 Kairos 的自治行为不是一个概念。3. Kairos 模式下的长期自治Kairos 自己不是 heartbeat而是“被激活之后的一整套长期助手运行模型”。Kairos 是如何被激活的Kairos 的激活是多层门控不是简单开一个 flag。从main.tsx可见至少有这些条件编译时feature(KAIROS)为真.claude/settings.json或 CLI 进入 assistant mode当前目录必须 trusted再通过kairosGate.isKairosEnabled()之类的运行时 gate激活后强制开启brief设置setKairosActive(true)初始化 assistant team证据claude-code-source/src/main.tsx:1033claude-code-source/src/bootstrap/state.ts:72claude-code-source/src/bootstrap/state.ts:1086这说明 Kairos 的目标不是“让普通会话偶尔自动跑一下”而是“切换进入一类特殊的长期助手工作模式”。Kairos 的模块调用链下面这张调用链图是根据当前仓库里可见调用点重建出来的。用户/配置 - .claude/settings.json assistant:true 或 --assistant - main.tsx - trust gate: checkHasTrustDialogAccepted() - runtime gate: kairosGate.isKairosEnabled() - setKairosActive(true) - force brief on - assistantModule.initializeAssistantTeam() - append assistant system prompt addendum - 进入 REPL / run loop - Proactive/Kairos tick loop - scheduleProactiveTick() - enqueue tick.../tick - model 决定继续工作 / Sleep / 发 Brief - BriefTool - SendUserMessage 给用户 - BashTool - assistant mode 下阻塞命令超预算自动后台化 - ScheduleCronTool - 未来触发/周期任务 - Memory layer - append to daily log - nightly dream consolidation - Bridge layer - assistant worker_type claude_code_assistant - perpetual session continuity - Session history - /v1/sessions/{id}/events 分页恢复上下文Kairos 用了哪些技术方法1. 编译期开关 Dead Code EliminationKairos整条模块图是被feature(KAIROS)包起来的构建时可整块消除。这不是普通运行时 if 判断而是“产品功能切片”的发布方式。证据claude-code-source/build.ts:53claude-code-source/src/commands.ts:622. 运行时门控从代码注释能看出它有 GrowthBook gate 和 entitlement 检查。例如Brief 用tengu_kairos_briefcron 用tengu_kairos_cron证据claude-code-source/src/tools/BriefTool/BriefTool.ts:67claude-code-source/src/tools/ScheduleCronTool/prompt.ts:12这意味着 Kairos 不是“硬编码给所有人开”的而是“编译时可裁掉、运行时还可灰度”的双层门控。3. System Prompt 编排main.tsx会在 proactive 模式下追加一段统一的自治说明并且在 Kairos 激活时再追加 assistant addendum。证据claude-code-source/src/main.tsx:2197claude-code-source/src/main.tsx:2206这说明 Kairos 的核心技术不是传统 workflow engine而是“prompt orchestration tool runtime”。4. Tick 驱动的自治循环scheduleProactiveTick()会把tick作为 meta prompt 重新注入队列模型由此继续运行。证据claude-code-source/src/cli/print.ts:1831这和 OpenClaw heartbeat 相似的地方在于都是“定时/周期性唤醒”。但差别在于OpenClaw heartbeat 更像外部调度制度Claude Code tick 更像会话内部的自治续航机制5. BriefTool 作为用户可见输出通道BriefTool的注释写得非常明确它是“primary visible output channel”。证据claude-code-source/src/tools/BriefTool/BriefTool.ts:136这意味着 Kairos 并不只是“默默在后台想”而是有专门的用户通知工具层。6. Bash 自动后台化在 assistant 模式下如果主线程上的 shell 命令运行过久会自动 background避免主 agent 被阻塞。证据claude-code-source/src/tools/BashTool/BashTool.tsx:973这是一种很典型的“自治 agent runtime 工程化”设计不是只靠模型提示而是从工具执行层保障持续响应。7. 长期记忆daily log dream consolidationKairos 模式不会一直 live rewriteMEMORY.md而是先 append 到按日期命名的 daily log再由 nightly/dream整理成 topic files MEMORY.md证据claude-code-source/src/memdir/memdir.ts:318claude-code-source/src/memdir/paths.ts:237claude-code-source/src/services/autoDream/autoDream.ts:95这说明 Kairos 的记忆策略是热路径追加写日志冷路径后台归档整合这比普通单文件记忆更适合“长期在线助手”。8. 持续会话与桥接Kairos 模式下worker type 会变成claude_code_assistantperpetual session continuity 会强制某些 bridge 路径走 v1/env-based 方案会通过 session history API 恢复历史事件证据claude-code-source/src/bridge/initReplBridge.ts:473claude-code-source/src/commands/bridge/bridge.tsx:482claude-code-source/src/assistant/sessionHistory.ts:30这说明 Kairos 从产品定位上就是“长期在线、会记住、会续上一次状态”的助手。普通 Proactive 模式是什么普通Proactive模式的核心比较纯粹打开自治 prompt允许收到周期性tick没事时调用Sleep有事就继续行动它强调的是主动探索少确认多行动tick 到来时别闲聊没事就 sleep证据claude-code-source/src/constants/prompts.ts:860从 prompt 文案看普通 Proactive 更像“自治工作模式”但还不是“具备长期助手身份、长期记忆、专用通知通道、专用桥接策略的 assistant product mode”。Kairos 和普通 Proactive 模式到底差在哪这是最关键的对比。1. 产品定位不同Proactive给当前会话增加主动性重点是“别等用户每一步都来指挥”Kairos把会话升级成长期在线助手重点是“持续存在、持续记忆、持续汇报、持续协调”2. 激活方式不同Proactive更像一个会话内行为模式开关Kairos需要 assistant mode需要 trust gate需要运行时 gate激活后会改写更多系统行为3. Prompt 层级不同Proactive主要追加一段自治 promptKairos既继承 proactive prompt又会追加 assistant 专属 system prompt addendum这意味着 Kairos 不是 Proactive 的同义词而是“在 Proactive 之上叠一层 assistant-specific contract”。4. 用户可见输出机制不同Proactive用户通常看到普通文本输出Kairos强依赖BriefToolBrief 在 assistant mode 下是被强制打开的这让 Kairos 更像“会主动汇报进度的助手”而不是“偶尔自己做点事的会话”。5. 工具运行策略不同Proactive会主动做事但并没有明显证据表明它会对 shell 阻塞做 assistant 专属运行时治理Kairos明确对 Bash 长阻塞做自动后台化这类差别很工程化也很关键因为长期助手如果不能保持响应就很难真的长期在线。6. 记忆层不同Proactive没看到它强制切到 daily-log memory 模式Kairos明确切到 daily log append-only并依赖 dream consolidation这说明 Proactive 是“会主动工作”Kairos 是“会长期积累记忆并周期整理”。7. 会话连续性不同Proactive还是偏当前会话增强Kairos明确和 assistant session continuity、bridge worker type、session history 恢复挂钩8. 生态扩展面不同从 feature flag 命名可以看出Kairos 还预留或关联了KAIROS_CHANNELSKAIROS_DREAMKAIROS_GITHUB_WEBHOOKSKAIROS_PUSH_NOTIFICATION这类能力明显已经超出“普通 proactive mode”。Kairos 与 OpenClaw Heartbeat 的本质区别1. 抽象层不同OpenClaw heartbeat调度机制重点是“多久触发一次主会话 turn”Kairos助手运行模式重点是“被触发后如何作为长期助手持续工作”2. 消息契约不同OpenClaw heartbeat有显式HEARTBEAT_OKack contract有ackMaxChars有showOk/showAlerts/useIndicatorKairos没看到类似HEARTBEAT_OK这种产品级 ack 契约更依赖Sleep、BriefTool、普通输出和工具行为3. 投递/路由能力不同OpenClaw heartbeattarget: last | none | channeltoaccountIddirectPolicy这是一个明确面向外部消息渠道的调度设计。Kairos当前可见源码更偏本地 REPL/bridge/runtime虽然存在 channels / push / webhook feature flag 痕迹但这一构建里主体代码不可见4. 成本控制手段不同OpenClaw heartbeat官方直接提供lightContextisolatedSession可选更便宜模型Kairos当前可见设计更多是靠 prompt cache、sleep、后台任务、memory consolidation 去降低长期运行负担没看到和 heartbeat 同级别的“每次定时 turn 明确瘦身”的对外配置界面5. 没事时的默认行为不同OpenClaw heartbeat倾向HEARTBEAT_OK并通过规则 suppress 掉无意义 ack避免打扰Kairos/Proactive倾向调用Sleep没事时不应该输出“still waiting”之类的文本两者本质上都在解决“无事发生时如何安静”但机制不同OpenClaw 用 ACK tokenClaude Code 用 Sleep tool tick loop如果硬要找“对位关系”最接近的对位关系其实是这样OpenClaw heartbeat对位Claude Code Proactive/Kairos tick Sleep Brief 的组合而不是OpenClaw heartbeat对位Kairos 整体因为Kairos比 heartbeat 大一层。一张对比表维度OpenClaw HeartbeatClaude Code ProactiveClaude Code Kairos核心定位定时主会话 turn 调度当前会话自治模式长期在线自动助手模式触发机制配置化定时 heartbeattick注入继承tick再叠加 assistant runtime无事时行为HEARTBEAT_OKack强制Sleep强制Sleep或通过 Brief/assistant 规则收敛用户通知目标路由、channel 投递普通输出为主BriefTool是主用户可见通道长期记忆依赖 OpenClaw 自身 session/task 设计无明显专属长期记忆层daily log dream consolidation会话连续性可选择 main session / isolated session会话级自治assistant continuity session history工程治理activeHours、lightContext、isolatedSession、ack contracttick sleeptick brief auto-background memory bridge适合场景周期巡检、提醒、外部通知当前任务自己往前推进长期驻留、主动汇报、连续协作对你最有价值的实操判断如果你以后自己设计一个“自动助手”系统可以借鉴两边不同的优点更像 OpenClaw 的部分适合拿来做稳定的定时巡检外部渠道通知明确的“没事就别吵我”产品契约上下文成本可控的定时 agent turn更像 Kairos 的部分适合拿来做长期在线 coding assistant有持续记忆的项目助手会自己协调、汇报、安排后台任务的 agent带长期 session continuity 的伴随式助手最终判断一句话版本OpenClaw heartbeat是“定时叫醒 agent 看看有没有事”Kairos是“把 agent 变成一个长期在线、会记忆、会汇报、会协调的助手人格和运行时”。更准确一点的判断如果你关心“调度机制”看 OpenClaw heartbeat。如果你关心“长期自治助手 runtime”看 Kairos。如果你关心“Claude Code 里最像 heartbeat 的东西”看Proactive/Kairos共享的tick循环而不是 Kairos 全体。参考证据本地源码claude-code-source/build.tsclaude-code-source/src/main.tsxclaude-code-source/src/commands.tsclaude-code-source/src/cli/print.tsclaude-code-source/src/constants/prompts.tsclaude-code-source/src/tools/BriefTool/BriefTool.tsclaude-code-source/src/tools/BashTool/BashTool.tsxclaude-code-source/src/tools/ScheduleCronTool/prompt.tsclaude-code-source/src/memdir/memdir.tsclaude-code-source/src/memdir/paths.tsclaude-code-source/src/services/autoDream/autoDream.tsclaude-code-source/src/bridge/initReplBridge.tsclaude-code-source/src/commands/bridge/bridge.tsxclaude-code-source/src/assistant/sessionHistory.tsclaude-code-source/src/cli/transports/ccrClient.ts外部官方资料OpenClaw Heartbeat:https://docs.openclaw.ai/heartbeathttps://docs.openclaw.ai/gateway/heartbeat附一句工程视角总结OpenClaw heartbeat 更像“scheduler routing ACK policy”而 Kairos 更像“assistant operating system”。