KAIROS：永不关机的 Agent
本章摘要：
KAIROS 是 Agent 从"工具"到"队友"的范式切换——让 Agent 在你不在时继续推进任务。tick 机制让 Agent 自己决定休眠节奏，更接近"有经验的同事"的节奏。
你在终端里让 Claude Code 重构一个模块，它开始了——读文件、分析依赖、逐个修改、跑测试。然后你合上电脑下班了。
第二天早上打开终端，发现它不仅完成了重构，还修好了跑测试时发现的两个边界 bug，把重构的决策理由写进了每日日志，甚至在你睡觉的时候"做了一个梦"——把这次重构的经验整理成了一条持久记忆。
这就是 KAIROS 想要做的事：让 Agent 从"你敲回车才动一下的工具"变成"一直在线的协作队友"。
从"一问一答"到"常驻协作"
普通 Agent Loop 的本质是一个循环——模型思考、行动、观察，不断循环直到任务完成。但它有一个隐含前提：每次循环都由用户的输入启动。用户不说话，Agent 就安静地等着。
KAIROS 打破了这个前提。它让 Agent Loop 不再依赖用户输入驱动，而是通过独立的机制持续运转：
| 普通 Agent Loop | KAIROS | |
|---|---|---|
| 驱动方式 | 用户输入 | 空闲 tick + 事件触发 |
| 生命周期 | 一次会话 | 跨会话持久运行 |
| 记忆方式 | 即时提取 | 每日日志 + Dream 批量整合 |
| 工作节奏 | 被动响应 | 主动推进 |
| 终端关系 | 终端关则停 | 终端关了还在跑 |
这不是功能升级，而是范式切换——从"工具"到"队友"。工具在你需要时才拿起，队友在你不在时也在推进工作。
KAIROS 这个名字来自希腊语 καιρός，意为"恰当的时机"。它不是让 Agent 漫无目的地乱跑，而是在恰当的时机自主行动。
主动模式：没人说话时，Agent 自己找活干
KAIROS 激活后，Agent 进入主动模式。核心的运行模式转变在于——Agent 不再等待用户输入，而是在空闲时通过系统注入的 tick 消息保持活跃。
三个核心状态
主动模式维护三个状态标志：
- 是否激活——整个主动模式的总开关
- 是否暂停——用户按 Esc 时暂停，下次输入自动恢复
- 是否阻塞——API 错误时阻塞 tick，防止 tick-error-tick 死循环
暂停和阻塞都是临时保护，不会永久关闭主动模式。
tick 机制
每当 Agent Loop 完成一轮迭代，系统检查消息队列是否为空——如果队列为空且主动模式激活，就注入一条 tick 消息，标记为系统元消息（用户不可见），优先级低于用户真正的输入。
收到 tick 后，Agent 自主判断：是继续推进之前的任务，还是进入休眠等待下次唤醒。tick 不由固定间隔的定时器驱动——下次 tick 何时到来，取决于 Agent 自己决定休眠多久。
Agent 知道收到 tick 该做什么，靠的是主动模式激活后追加的系统提示：
- 节奏控制：用 Sleep 工具控制等待时长——闲时多睡、忙时少睡；无事可做时必须调用 Sleep，不要发"还在等"的状态消息浪费 token
- 首次唤醒：新会话的第一次 tick 简短问候用户并询问方向，不擅自开始探索
- 后续唤醒该做什么：主动找活干——调查、降低风险、建立理解；不重复询问、不叙述意图
- 保持响应：与用户交流时频繁检查回复，优先响应用户消息而非后台工作
- 倾向行动：读文件、改文档、跑验证不用问；不确定时选一个方案先走
- 保持简洁：文字输出聚焦决策、里程碑、阻塞；不叙述每一步
- 用户写作：用户未聚焦时大幅自主、聚焦时倾向于写作
这套提示告诉模型"你是一个主动的同事，不要等指令，自己发现问题并解决"——用行为准则塑造模型倾向，没有专门的算法或任务队列。
跨会话持久运行
普通模式下，关掉终端就等于杀死整个 Agent 进程，对话历史随着进程消失。KAIROS 需要让 Agent 跨越进程的生命周期——上次做到一半的重构，下次打开终端时能接上。
会话恢复
会话历史持久化在磁盘上。Agent 重启时从磁盘重建上下文。但这里有一个问题：KAIROS 模式下 Agent 可能因为网络断开、进程崩溃、或用户手动关闭而中断，而不是正常结束。系统需要区分"正常完成的轮次"和"被中断的轮次"——被中断的轮次可能包含未完成的工作，Agent 恢复后需要知道哪些事还没做完。
对于被中断的轮次，系统会注入一条合成的续接消息，让 Agent 自动继续未完成的工作。
每日日志
KAIROS 模式下，Main Agent 自身就会跟随系统提示词， 把工作过程中"值得记住的事"追加写入每日日志。日志按日期组织，追加写入（append-only），不重写或重组。系统提示中明确列出了该记什么：
- 用户纠正和偏好
- 关于用户的事实（角色、目标）
- 无法从项目文件中推导的上下文（截止日期、事故、决策及其理由）
- 外部系统的指针（看板等）
- 用户明确要求记住的任何内容
这种"按时间追加日志"的设计哲学和日记本很像——今天发生了什么、明天追加上去。结构化整理是后续的步骤（Dream），而日志本身是"事实流"。
Dream：睡眠时整理记忆
本节复用了 AutoDream 的整合引擎——相同的四阶段流程、相同的锁机制、相同的权限约束。KAIROS 模式下，把触发方式从"会话结束"改为"定时任务"。
Dream 把日志中的事实流提炼为结构化记忆——这是"事实流 → 知识体系"的转化步骤。如果只有日志不整理，记忆会越来越长、越来越难搜索；如果立刻整理，又会打断工作流。Dream 在"积累够了"和"下次会话前"之间找一个平衡点。
KAIROS 模式下，三种记忆机制共同协作：
每日日志优先，若未曾写入日志，则会回到普通模式下的记忆提取（参考记忆系统章节）进行兜底。
| 记忆提取 | 每日日志 | 批量整合（Dream） | |
|---|---|---|---|
| 触发 | 每轮对话结束后 | 模型自主判断 | 积累足够素材后 |
| 谁执行 | 子 Agent | 主 Agent 自己 | 子 Agent |
| 写到哪 | 主题文件 + 索引 | 按日期的日志文件 | 日志 → 主题文件 + 索引 |
| 适用 | 普通模式 | KAIROS 长期运行 | KAIROS 长期运行 |
后台任务调度
KAIROS 的持续运行需要一个可靠的任务调度系统：
- 需要支持 Agent 的定时任务
- 需要避免 Agent 长时间宕机不工作
- 需要能够调度多个 Agent，避免对同一任务的竞争
系统通过文件轮询的方式检测定时任务：调度器定期检查任务文件，到执行时间就触发。锁机制防止多个 Agent 实例重复触发同一任务，锁持有者崩溃时其他实例会探测到锁失效并自动接管。
KAIROS 会用定时器来定义任务，可以控制是否一次执行完毕，还是循环执行，甚至是永久执行。KAIROS 也可以通过将任务落盘到文件系统中来保证该任务可以跨会话延续。
KAIROS 依赖三种永久任务来维持运转：
- catch-up：恢复中断的工作
- morning-checkin：每日早间签到，总结昨天的工作
- dream：触发记忆整合
这种分布式系统中常见的一个问题是"雷群效应"：如果 1000 个 Agent 都设置了同一时间签到，它们会在同一秒内全部发送请求，瞬间打垮后端。通过人为添加随机延迟（jitter）来分散请求，是这类系统的标准做法。
代价与限制
KAIROS 听起来很美好，但不是免费的午餐。
仍在开发中。KAIROS 的核心主闭环尚未完全打通，目前看到的更多是精心设计的骨架，而非完整可用的产品。
额外的资源消耗。后台持续运行意味着持续的 API 调用和计算消耗。Dream 机制尤其昂贵——需要启动子 Agent，读取多个会话的完整记录，执行四阶段的整合流程。
安全边界。KAIROS 赋予了 Agent 在用户不在场时继续行动的能力，这对安全提出了更高要求。五层门控、目录信任检查、权限受限的子 Agent——这些防御机制的存在本身就说明：让 Agent 自主行动是一件需要极其谨慎的事。
KAIROS 描绘的未来图景：从工具到队友
KAIROS 代表的不只是一个功能，而是一种愿景——Agent 不再只是你拿起又放下的工具，而是一个始终在线、自主推进、能记住上下文的协作队友。它在你不在时默默工作，在你回来时汇报进展。
从 Agent Loop 的"一问一答"，到主动模式的"自己找活干"，到 Dream 的"睡眠时整理记忆"，再到跨会话的"永不关机"——KAIROS 正在一步步走向这个愿景。
当然，离完全实现还有距离。但骨架已经搭好，门控已经就位，机制已经设计完成。剩下的，是让每个子系统真正跑通，让主闭环顺畅运转。
通往 AGI 的路上，"自主行动"是必过的门槛——不是因为技术酷，而是因为现实任务本就是异步的、跨会话的、需要持续关注的。KAIROS 是这个方向上的一次系统性探索。