KAIROS 助手模式
Claude Code 的持久化 AI 助手模式 — 持续运行、主动行动、精简交互、自动做梦
KAIROS 概述
Always-on 的持久化 AI 助手
KAIROS 是 Claude Code 的持久化 AI 助手模式。与传统的"请求-响应"式交互不同， KAIROS 以 Always-on 方式持续运行，监控环境变化并主动采取行动。它就像一个始终在线的开发伙伴， 在你编写代码的同时默默守护项目健康。
KAIROS 的核心设计理念包含三个关键特性：持久化会话保持跨终端的状态连续性； 环境监控能力使其能主动发现问题；而 简要模式（Brief Mode） 则通过超简洁响应减少认知负担，让持久上下文中的交互更加高效。
KAIROS 助手架构
会话管理
跨终端会话的状态持久化
KAIROS 的会话管理是其持久化能力的核心。通过 持久化会话 机制，KAIROS 能够跨越终端会话保持完整的状态信息。即使你关闭了终端窗口， 下次启动时 KAIROS 可以自动恢复之前的上下文，继续未完成的工作。
会话历史记录了完整的交互过程，包括对话消息、文件操作、命令执行等， 使得 KAIROS 能够在任意时间点准确理解项目的当前状态和历史变更。
KAIROS 会话数据结构
会话生命周期管理
主动行动
环境监控与智能响应
KAIROS 最强大的特性之一是其主动行动能力。它持续监控开发环境的各种变化， 包括文件修改、Git 状态变更、测试结果等，并在检测到潜在问题时自动提供建议或执行修复。
环境监控
持续追踪文件变化、Git 状态、测试结果等开发环境指标
通过文件系统监听和 Git 钩子，KAIROS 实时感知项目中的每一次变更，构建完整的变更上下文。
主动建议
检测到问题时自动分析并提供建议方案
利用代码分析和模式匹配，KAIROS 在问题扩大前就能发现潜在风险，并主动向开发者报告。
自动修复
在用户授权的情况下自动执行修复操作
对于常见问题（如 lint 错误、格式问题），KAIROS 可以在获得授权后自动修复，减少手动干预。
主动行动引擎流程
简要模式 (Brief Mode)
超简洁响应，提升持续交互效率
简要模式是 KAIROS 针对持久化上下文场景专门优化的响应风格。在长时间运行中， 过多的输出会造成信息过载。简要模式通过 精简输出 大幅减少响应长度，只保留最关键的信息，显著提高持续交互的效率。
我已经仔细检查了你的代码，发现 src/app.ts 文件第42行有一个未处理的错误。 建议添加 try-catch 块来捕获可能的异常。这里是修复代码...
src/app.ts:42 - 缺少 try-catch，建议添加错误处理
简要模式配置选项
与标准模式的区别
KAIROS 模式 vs 标准模式全方位对比
KAIROS 模式与 Claude Code 的标准模式在多个维度上存在根本性差异。 标准模式适合执行单次任务，而 KAIROS 模式则设计为持续的长期开发伙伴。 以下是两者的详细对比：
KAIROS 模式配置总览
KAIROS 状态机
从空闲到做梦的完整生命周期
KAIROS 助手并非始终处于"对话"状态。它有完整的生命周期状态机： 从空闲开始，经过对话、离线， 最终进入最关键的做梦阶段。 做梦完成后，整合的记忆写入存储，助手恢复就绪。
KAIROS 状态机 — 空闲 → 对话 → 离线 → 做梦 → 恢复
空闲 / 对话
正常交互，用户与助手实时通信
离线
终端关闭，但会话数据已持久化到磁盘
做梦
后台子代理扫描记忆、整合信号、更新索引
恢复
下次启动时加载整合后的记忆，无缝继续
AutoDream — 自动做梦服务
离线时的记忆整合引擎
AutoDream 是 KAIROS 模式的核心创新之一。当助手离线后，系统会自动触发一个分叉子代理（Forked Agent）， 以只读方式扫描记忆目录和会话记录，将新信号整合到持久化记忆中。这个过程就像人类在 睡眠中整理白天的记忆——因此得名"做梦"。
做梦过程由严格的三重门控保护，确保不会在不必要时频繁触发，也不会在另一个进程 正在整合时产生冲突。
🔐 三重门控机制
1// 检查启2isAutoDreamEnabled()检查启
AutoDream 架构
📋 DreamTask — 做梦任务状态
做梦四阶段
Orient → Gather → Consolidate → Prune
做梦过程分为四个明确的阶段，由 consolidationPrompt 构建的提示词驱动。 子代理以只读权限运行， 限制 Bash 为只读命令（ls、grep、cat 等），但可以自由写入记忆目录。
1# Phase 1 — Orient2# 读取记忆目录结构和 MEMORY.md 索引3ls ~/.claude/projects/<slug>/memory/4cat ~/.claude/projects/<slug>/memory/MEMORY.md定位与索引
记忆系统与整合
四类型记忆 + 自动去重 + 上下文优化
KAIROS 的记忆系统采用封闭的四种类型分类法：user（用户画像）、feedback（行为指导）、project（项目上下文）、reference（外部指针）。 每种记忆都排除可从代码状态推导的信息（架构、Git 历史、文件结构）。
👤 User
私有用户角色、偏好、知识背景
💬 Feedback
私有/团队用户纠正与确认的行为指导
📁 Project
私有/团队项目上下文、目标、决策
🔗 Reference
通常团队外部系统指针（Linear、Slack等）
📝 记忆文件格式（Frontmatter）
---
name: testing-preferences
description: 用户对测试方式的行为偏好——集成测试优先，禁用 mock
type: feedback
---
**规则**: 集成测试必须连接真实数据库，不使用 mock
**Why**: 上季度 mock 测试通过但生产迁移失败，教训深刻
**How to apply**: 编写测试时选择集成测试套件；审查他人 PR 时
对 mock 使用提出质疑🔄 记忆整合前后对比
记忆检索与上下文优化
findRelevantMemories — 智能记忆召回
当用户发起新对话时，系统不会加载全部记忆（可能上百个文件）。 相反，findRelevantMemories 先扫描所有记忆文件的 Frontmatter（标题 + 描述），然后用 Sonnet 模型选择最多 5 条最相关的记忆注入上下文。
每条召回的记忆还附带新鲜度提示： 超过 1 天的记忆会显示"N 天前"警告，提醒模型在引用前验证当前代码状态。
记忆检索流程
// findRelevantMemories 核心逻辑
async function findRelevantMemories(query, memoryDir, signal) {
// 1. 扫描记忆目录，读取每个 .md 的 Frontmatter（≤30行）
const memories = await scanMemoryFiles(memoryDir, signal);
// 2. 用 Sonnet 从清单中选择 ≤5 条最相关的
const selected = await selectRelevantMemories(query, memories, signal);
// 3. 返回路径 + mtime（用于新鲜度警告）
return selected.map(m => ({ path: m.filePath, mtimeMs: m.mtimeMs }));
}锁机制与容错
.consolidate-lock — 基于 PID + mtime 的分布式锁
做梦过程的锁文件.consolidate-lock 存放在记忆目录内， 其 mtime 就是上次整合的时间戳（lastConsolidatedAt）， 文件内容是持有者的 PID。这种巧妙的设计让锁和时间门控共用一个文件。
获取锁
写入 PID → mtime = now，返回先前 mtime（用于回滚）
竞争检测
双重验证：PID 必须匹配 + 持有时间 < 1小时（防 PID 复用）
失败回滚
回滚 mtime 到先前值，下次时间门控重新触发
崩溃恢复
死 PID 自动回收，新进程接管并重新开始整合