章节导航第 20 章 / 共 23 章

第 20 章第六部分：专题研究

专题：KAIROS 与梦境模式——当 AI 开始主动行动

始终在线的后台代理、四阶段记忆整合、定时任务调度——Claude Code 从工具进化为同事的技术蓝图

最后更新：2026年10月1日 Claude Code KAIROS 梦境模式主动 Agent 记忆整合专题研究

为什么关注 KAIROS

KAIROS 在 Claude Code 源码中被引用 150+ 次。它不是一个边角功能——它代表了 AI Agent 的下一个演化方向：从”你发起，它响应”变为”它主动发现，主动行动”。

名字来自古希腊语 kairos（καιρός），意为”恰当的时机”——与计时的 chronos 不同，kairos 指的是行动的最佳时刻。这个命名暗示了设计意图：AI 不是按固定时间表行动，而是判断何时是行动的最佳时机。

根据 Claw Decode 和社区分析，KAIROS 是完整开发但仍在 Feature Flag 后待发布的系统。

KAIROS 的核心架构

运行模型：Tick 驱动

传统的 Claude Code 是事件驱动的——用户输入触发处理。KAIROS 引入了 Tick 驱动模型：

┌─────────────────────────────────────┐
│ KAIROS 后台进程                       │
│                                     │
│  ┌───┐    ┌───┐    ┌───┐    ┌───┐  │
│  │tick│ →  │tick│ →  │tick│ →  │tick│ │
│  └───┘    └───┘    └───┘    └───┘  │
│    ↓                  ↓             │
│  (无需行动)        (发现问题,          │
│                    主动通知用户)       │
└─────────────────────────────────────┘

AI 周期性地接收 <tick> 提示，每次 tick 它自主决定：

检查是否有需要关注的变化
决定是否行动
如果行动，选择合适的工具

15 秒阻塞预算：每次 tick 的执行时间不超过 15 秒，防止后台代理垄断系统资源。

一条公开的术语呼应（中置信，仅供参照）。An Architecture for Long-Horizon Agents: Levels, Ticks and Cascaded Intelligence（arXiv:2609.19519，2026-09-17）用同一组术语——Levels / Ticks / Cascaded Intelligence——提出了一套长程 Agent 架构。

⚠️ 术语同名不等于同一机制。本轮只核验了这篇论文的标题与提交日，未逐段核对其与 KAIROS tick 模型的可比性，因此它在这里的角色只是：提供一个独立于 Claude Code 逆向证据的、公开的「Tick 分层」架构参照系，用来检验本章把 tick 当作调度基本单位这一判断是否只是 Claude Code 的局部实现。它不构成对 KAIROS 的任何验证，读者不应读成「该论文验证了 KAIROS」。

官方对应约束：连续 8 次阻断后强制结束。15 秒是社区来源的时长约束；官方 hooks.md 对 Stop hook 另有一条次数约束，且更具体：stop_hook_active 为 true 时表示 Claude Code 已因 stop hook 而继续，官方建议检查该值或处理 transcript，以避免阻塞在一个永远不会解决的条件上——Claude Code 会在连续 8 次阻断后覆盖 hook 并结束该轮。

这条对本节的直接意义在于：官方明确 /goal 是”a built-in shortcut for a session-scoped prompt-based Stop hook”——/goal 的底层就是 Stop hook，那 8 次上限就是 /goal 的硬边界。把两个约束并列看，KAIROS 类自主循环的治理有两个正交维度：时长限制单次开销（15 秒），次数限制总开销（8 次）。前者来自社区分析，后者是官方规格，来源强度不同，读者引用时应分开标注。

三个独占工具

KAIROS 拥有三个普通模式下不可用的工具：

工具	功能	意义
SendUserMessage	主动向用户推送消息	打破”用户先说话”的范式
BriefTool	发送 KAIROS 格式的简报	格式化通知
ScheduleCron	定时任务调度	自主规划未来行动

`session_crons`：定时唤醒的官方规格

本章此前对 ScheduleCron 只有一行表格描述。官方 hooks.md 现已正式记载其规格——这不是社区逆向分析，是 Anthropic 自己的规格说明。session_crons 数组中每个条目描述一次会话级定时唤醒（session-scoped scheduled wakeup），来源有三个入口：CronCreate 工具、ScheduleWakeup 工具、/loop 命令。

字段	说明
`id`	Cron 任务标识符
`schedule`	Cron 表达式，例如 `0 9 * * 1-5`
`recurring`	`false` 为一次性唤醒（schedule 编码单一触发时刻），`true` 为每次匹配都重新触发
`prompt`	cron 触发时提交的提示，上限 1000 字符，超出以 `… [+N chars]` 标记截断

官方给出的 Stop 输入样例（含一个 in-flight shell 任务与一个 recurring cron）：

{
  "hook_event_name": "Stop",
  "stop_hook_active": true,
  "background_tasks": [
    { "id": "task-001", "type": "shell", "status": "running",
      "description": "tail logs", "command": "tail -f /var/log/syslog" }
  ],
  "session_crons": [
    { "id": "cron-001", "schedule": "0 9 * * 1-5",
      "recurring": true, "prompt": "check the build" }
  ]
}

两条设计含义值得点出。其一，prompt 有 1000 字符硬上限，意味着定时唤醒的意图表达能力是被刻意限制的——它与本章的「15 秒阻塞预算」「仅追加日志」同属一套”能力给了，但额度不给”的治理哲学。其二，background_tasks 与 session_crons 两个数组的官方用途是”让 hook 能区分会话结束与会话暂停、等待后台工作把它唤醒”——这正是本章 Tick 驱动模型中”无需行动”与”发现问题”两种 tick 结果的官方实现。一个只能靠源码推测的架构假设，现在有了可观测的官方字段。

SendUserMessage 的公开落地：notify_when_idle（v2.1.236，2026-08-19）。状态表此前把 SendUserMessage 标为已发布，证据只有 Agent View 通知机制。官方 changelog 给出了更直接的一条：跨会话 SendMessage 新增 notify_when_idle——可以请求同一台机器上的另一个 Claude Code 会话，在它下次空闲时发来一次通知，opt-in、一次性、无轮询（macOS 与 Linux）。

这是一次保守实现，其三个约束值得逐条对照本章的设计哲学：一次性而非持续订阅、事件驱动而非轮询、需显式 opt-in。三者与本章的「15 秒阻塞预算」「仅追加日志」属于同一套思路——主动性必须用保守约束换取信任。它也印证了本章「启示 1：主动性需要信任机制」与「启示 2：从被动响应到主动服务的渐进路径」：官方走的正是”先低风险（一次性通知），再高风险（周期任务）“的路线，与本章推断的发布策略一致。

Coordinator Mode：KAIROS 的多代理协调层

Coordinator Mode（CLAUDE_CODE_COORDINATOR_MODE=1）是 KAIROS 从”单 Agent 主动行动”到”多 Agent 协调执行”的关键扩展。完整架构为四阶段：

阶段	名称	操作
Phase 1	Decomposition	将用户任务分解为可并行的子任务
Phase 2	Parallel Research	多 Worker 并行探索，各自独立研究子任务
Phase 3	Planning	汇总研究结果，生成统一执行计划
Phase 4	Implementation & Verification	按计划执行并验证结果

Worker 通过 mailbox 结构化消息传递与 Coordinator 通信，而非共享状态——每个 Worker 有独立的消息队列，Coordinator 通过发送消息分配任务和接收结果。这与 KAIROS 的 SendUserMessage/BriefTool 一脉相承——消息驱动而非状态共享。

Coordinator Mode 是 KAIROS “主动发现”能力的多代理实现层：单 Agent 的 tick 驱动模型扩展为多 Agent 的协调执行模型，两者共享同样的安全约束（15 秒预算、仅追加日志、用户可审计）。

公开命名的对应能力（与 Coordinator Mode 是两回事）。本轮核查仍未找到 CLAUDE_CODE_COORDINATOR_MODE 的任何官方记载，上面「未获 Anthropic 官方确认」的限定语应当保留。

2026-10-01 复核（表述已加强）：Coordinator 关键词在官方 changelog 全量 408 个版本块（909,322 字节）中命中数为 0。这不是「没搜到」，而是官方从未在 changelog 里写过这个词——后一种表述的证据强度更高，因为它把「我找不到」和「它不存在」区分开了。截至 v2.1.286（2026-09-30） 仍为 0 命中，上面「未获 Anthropic 官方确认」的限定语继续保留，不得弱化。但同期官方已公开了一组命名不同、能力重叠的基础设施：teammate / in-process teammate / Workflow。相关官方条目包括：v2.1.269 起 Workflow 单轮并发 agent 上限可通过 CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS 调到 1–256；v2.1.268 修复 respawn 的 in-process teammate 从未受信任目录下的同名 agent 文件拾取工具或系统提示（说明 teammate 有信任边界）；v2.1.267 修复 Workflow agent() 的大输出 schema 在 auto mode 下被直接拒绝而非交由安全分类器检查。

正确读法是：Coordinator Mode 四阶段所需的基础设施已公开落地，但这不等于 Coordinator Mode 已发布。前者是官方命名下的一批能力，后者仍是一个来自社区源码分析的架构假设。两者不能互相印证。

/goal 命令可视为 KAIROS 自主行动能力的公开版本——它将”AI 自主决定何时行动”的判断权从 AI 转移为用户设定的目标条件，降低了自主行动的风险。Agent View 的 Supervisor 进程则是 KAIROS Daemon 模式的轻量实现——同样支持后台持续运行、磁盘状态持久化、会话生命周期与终端解耦，但比完整 KAIROS 的 Tick 驱动模型更保守（不主动行动，只响应目标条件）。

外部集成

RemoteTrigger：远程 API 触发器——外部系统（CI/CD、监控告警）可以触发 KAIROS 行动
GitHub Webhook 订阅：自主监控仓库变化——PR 合入、Issue 创建、CI 失败等
PR 订阅：关注特定 Pull Request 的状态变化

审计安全

KAIROS 的日志系统采用仅追加（append-only）模式——代理无法自行删除日志。这意味着：

所有 KAIROS 的行动都有完整审计追踪
如果 AI 做了不恰当的事，记录不可篡改
用户随时可以回溯 AI 做了什么以及为什么

梦境模式（Auto-Dream）

设计灵感

人类在睡眠时整理白天的记忆——海马体与新皮层之间的信息转移，碎片化记忆被整合、错误关联被修剪。Claude Code 的梦境模式做同样的事。

三重触发门控

梦境模式不是随时运行的。来自 claudefa.st 的分析，它需要同时满足三个条件：

距上次梦境循环 ≥ 24 小时
自上次整合后完成 ≥ 5 个会话
整合锁空闲（防止并发整合）

四阶段整合循环

来自 Claw Decode 的分析：

阶段	名称	操作
Phase 1	Orient（定位）	ls 记忆目录，读索引文件（ENTRYPOINT.md），浏览现有主题文件避免重复
Phase 2	Gather（采集）	检查每日日志，有针对性地 grep JSONL 转录文件——不穷举阅读，只寻找”已经怀疑重要的东西”
Phase 3	Consolidate（整合）	合并新旧内容，将相对日期（“昨天”）转为绝对日期，删除矛盾事实
Phase 4	Prune（修剪）	保持索引 < 25KB，移除过时指针，解决文件间矛盾

源码中的关键提示词：

“你正在执行一场梦境——对记忆文件的反思性遍历。不要穷举阅读转录文件。只寻找你已经怀疑重要的东西。“

记忆分类体系

梦境模式维护四种类型的记忆（来自 Claw Decode）：

类型	内容	示例
user	角色、目标、偏好	”用户偏好 TypeScript，讨厌 ORM”
feedback	纠正和反馈	”不要在 commit message 中加 emoji”
project	进行中的工作和决策	”正在重构支付模块，使用策略模式”
reference	外部系统指针	”Linear 看板：ENG-1234”

对 Agent 产品设计的启示

1. 主动性需要信任机制

KAIROS 的仅追加日志 + 15 秒预算 + 用户可审计——这些不是限制，是建立信任的基础。如果你要让 AI 主动行动，用户必须能：

看到 AI 做了什么（日志）
控制 AI 能做什么（预算）
回溯 AI 为什么这么做（审计）

这三条是设计原则。已落地的系统给出的清单要长得多。 只看 2026-09 下旬官方修掉的这批 routine 可靠性问题，就能看出主动式系统真正会坏的地方不是「没跑」，而是「状态显示与真实状态不一致」：

类别	具体缺陷	官方修复
假成功	云端会话从未启动的 routine 运行，在 Runs 面板、routine 页面与侧栏显示为 Succeeded	v2.1.286
	Run now 在运行被拒绝前显示内部错误文本，而非与 routine 失败通知一致的解释	v2.1.285
时间谎言	新建 routine 计划默认改为整点过几分钟，官方并注明「整点设置的 routine 可能晚几分钟才开始」	v2.1.283
	半小时偏移时区（如印度）的每小时 routine，其 next run time 差 30 分钟	v2.1.282
	计划运行已迟到且未启动时，页面显示过去的 next run time（改为显示 “Due” 加计划时间）	v2.1.286
版本谎言	恢复既有会话的 routine，若在计划运行开始前刚被编辑，会用旧的 prompt 与旧名字运行	v2.1.280
	编辑 routine 偶尔使其触发两次，或重新启用刚被暂停的 routine	v2.1.274
	owner 的 GitHub 连接缺失时，routine 跳过该次运行并重试最多 72 小时，而不是首次检查失败就关闭	v2.1.274
上下文谎言	远程会话中的 scheduled routine 与 notification turn，在第一次工具调用之前收不到 turn-start 通知（新可用工具、MCP 变更、日期、todos）	v2.1.281

这四类合起来给出本章独有的一句结论：主动式系统的失败模式是「状态谎言」，不是「不运行」。上表没有任何一条是「routine 没跑」——它们全是「跑了但用的是旧版本」「没跑但显示成功」「说好的时间不是那个时间」「跑的时候缺了上下文」。

所以「信任」在本章应当被重新定义：

信任 ≠ 相信它会跑，而是能验证它跑了、跑的是哪个版本、以什么身份跑的。

这个定义也解释了为什么本章开头那三条原则（日志 / 预算 / 审计）不够用——它们保证的是「有记录」，而这里要求的是「记录与事实一致」。前者防的是作恶，后者防的是谎报，而对一个主动行动的 Agent 来说，后者才是主要风险。

2. 从”被动响应”到”主动服务”的渐进路径

KAIROS 的发布策略很谨慎——先 KAIROS_BRIEF（仅 SendUserMessage），再完整 KAIROS。这意味着：

先让 AI 能主动发消息（低风险）
再让 AI 能主动执行操作（高风险）
渐进式建立用户信任

3. 记忆维护是长期运行的前提

没有梦境模式的记忆整合，KAIROS 运行几周后记忆就会膨胀、矛盾、过时。主动性 Agent 必须有自动记忆维护——这不是可选功能。

上面四阶段整合循环与记忆分类体系是设计假设。已落地的系统里，这个假设被两条官方修复证实是必要的，而且两侧都真出过事：

写入侧（v2.1.280）：Cowork 会话中的记忆写入冲突，对超过约 10,800 字符的记忆文件只给 Claude 看开头与结尾，导致冲突重试的写入丢掉了中间部分。

这条的价值在于它把 Prune 阶段的设计意图量化了。本章 Phase 4 写的是「保持索引 < 25KB」，那是一个设计取值；而 10,800 字符是真实系统里触发静默损坏的阈值。也就是说：记忆文件体积不是「大了慢一点」的性能问题，而是超过某个点之后维护动作本身会破坏数据。注意失效形态——不是报错，是静默丢中间。

读取侧（v2.1.284）：auto-memory 加载时，MEMORY.md 与召回的记忆笔记中的不可见字符，以及仿冒 Claude Code 自身标记的 tag，在进入 Claude 之前被中和。

这条说明 MEMORY.md 是一个真实的注入面。而记忆自动维护的架构——Agent 自己写、自己读——恰好放大了这个面：写入侧的内容来源包含模型输出与外部内容，读取侧又把它直接放进上下文，中间没有人工环节。上面「### 审计安全」一节讲的仅追加日志保证的是「行动不可篡改」，而这里暴露的是另一件事：记忆系统是双向的攻击面，只做单向的不可篡改保护是不够的。

4. 人类睡眠是好的隐喻

四阶段整合循环（定位→采集→整合→修剪）几乎就是人类睡眠中记忆处理过程的工程化翻译。这个隐喻还可以继续延伸——比如”遗忘”（有选择性地丢弃不重要的信息）也是记忆系统必须支持的操作。

延伸阅读：Claw Decode 的 KAIROS 分析，以及社区对 8 个隐藏功能的盘点。

KAIROS 的渐进式落地

截至 2026 年 5 月，KAIROS 已不再是”完全在 Feature Flag 后待发布”的系统。其核心架构已通过两条路径部分释放：

Agent View + /goal（v2.1.139, 2026.05.12）

v2.1.139 引入了两个 KAIROS 核心能力的公开落地：

Agent View（claude agents）：由独立 Supervisor 进程托管后台会话，会话生命周期与终端解耦。每个后台会话自动隔离到独立 git worktree（.claude/worktrees/ 下），避免多会话并行时的文件冲突。空闲约 1 小时后 Supervisor 自动停止进程释放资源，attach/peek 时从磁盘状态无缝重启。
/goal 命令：引入”目标状态收敛”执行模型——设定完成条件后 Claude 跨 turn 自主迭代直到达成。这是 KAIROS “自主决定何时行动”判断权的用户侧版本——将自主行动的风险从 AI 判断转移为用户设定的目标条件。

/goal 从「能用」到「能在长会话里持续可用」。v2.1.274 一次修掉了三条 /goal 的可靠性缺口，它们共同指向本章的核心命题——长期运行的 Agent 必须自己维护状态，而维护动作本身会破坏状态：

缺口	官方修复
活跃的 `/goal` 在 resume（`--continue` / `--resume`）一个已压缩过的会话时丢失	v2.1.274
hook 驱动的会话（官方举例即含活跃的 `/goal`）在响应式压缩后上下文再次溢出时以 “Prompt is too long” 结束，而不是继续压缩	v2.1.274
`/schedule` 在按「列取 routines 返回的形状」写 routine 时保存的 prompt 丢失 message role	v2.1.274

第二条尤其关键，而且它带来一个归类上的官方背书：官方原文把活跃的 /goal 直接称作 “hook-driven sessions (such as an active /goal)“——官方措辞本身就把 /goal 归入了 hook 驱动的会话族。这为本章前面「/goal 的底层就是 Stop hook」这一推断提供了官方侧的说法，也让「相关的隐藏功能」（Daemon / UDS Inbox / Teleport）一节与 /goal 的关联论述有了出处。

第一条则是一个具体的反例：本章「梦境模式」四阶段整合循环与「记忆维护是长期运行的前提」都在论证长期运行 Agent 必须自我维护，而这条说明压缩这个维护动作本身会丢掉目标状态。

后续版本还给出了一组配套修复，值得与上表合读：/goal 在 API 错误、网络中断或触及 token 上限后静默停滞的问题（现在按退避重试，或暂停并说明原因）、空闲会话的重复 check-in 从「每 30 分钟一次」改为退避（30 分钟 → 1 小时 → 每 2 小时）、以及从 claude --resume 选择器恢复会话时现在会一并恢复其活跃的 goal。最后一条正是上表第一行的修复侧对应物——同一处缺陷，先修「丢了不告诉你」，再修「干脆不丢」。

Routines（“Code with Claude” 大会, 2026.05.07）

2026 年 5 月 7 日 Anthropic 召开”Code with Claude”全球开发者大会，发布 Routines——24 小时不间断工作的云端自动化例程。与 SpaceX 达成独家算力合作，API 调用速率最高提升 16 倍。Claude Code 定位从”个人辅助助手”转变为”工程团队异步自动化基础设施”。

Routines 是 KAIROS “始终在线”愿景的云端实现路径之一——将 Daemon 模式从本地终端扩展到云端，不依赖本地终端运行（另一条路径是上面已结案的 Cowork，两条并列）。

两处产品化变化（2026-09 下旬）。其一，v2.1.271 把 claude.ai/code 上的 Routines 页面改版：改为 Yours / Templates 两个 tab，双列卡片直接显示运行状态，并移除了日历视图。日历视图的移除值得记一笔——它意味着官方放弃了「用日历隐喻呈现定时例程」，转向「用运行状态呈现」。对本章的隐喻体系来说，这是一个与人类睡眠隐喻方向相反的产品选择：不强调「什么时候做」，而强调「做成没有」。

其二，v2.1.275 让 routine 运行写入 artifact，且无需询问即可重新发布其页面（public artifacts、首次发布、删除仍需询问）；同时移除了「自上次会话以来有一次一次性计划 routine 已运行」的启动通知。前者是把自主程度往前推了一格（重新发布不再打断用户），后者是减少打扰——两者合起来是同一个方向：降低 routine 的存在感，同时扩大它的实际权限。这与本章「渐进建立信任」的路径并不矛盾，但它提醒读者：渐进不等于权限不变。

三路触发器：Routines 已从”Code with Claude”大会的初步发布演进为完整的三路触发体系：

定时触发（Scheduled）：按 cron 表达式定期执行，适用场景：每晚 triage Issue、每周扫文档与 API 一致性
API Webhook 触发：每个 Routine 分配独立 HTTP 端点 + Bearer Token，任何能发 HTTP 请求的系统（Datadog/Sentry/CI/CD）都能触发 Claude Code 会话。POST body 中的 text 字段作为追加 prompt，接口返回 session URL 实时监控
GitHub Webhook 触发：支持 pull_request.opened、push、issues 等事件订阅，一 PR 一 session 长期跟进——后续 commit、评论、CI 失败日志全部 feed 回同一会话

这三路触发器直接对应源码中 KAIROS 的 ScheduleCron、RemoteTrigger、GitHub Webhook 订阅三个核心能力——是 KAIROS 核心架构的完整产品化落地。

✅ 已结案（2026-10-01）：云端定时路径不止 Routines 一条——Cowork 是独立产品线。 上一轮留下的 TODO 原本只能确认「两者都出现在官方 changelog」，本轮补齐了判定依据。官方 changelog 中 Cowork 与 claude.ai cloud sessions、Claude Desktop 是被并列提及的，不是从属关系：

版本官方原文要点判定价值
v2.1.274 ”Fixed Cowork and claude.ai cloud sessions with network access on treating reads of a teammate’s artifact as if network access were off” Cowork 与 claude.ai 云会话被并列为两种不同的环境
v2.1.274 ”Added enduser.sub, the IdP subject, to the telemetry Claude Desktop and Cowork send through a Claude apps gateway” Cowork 与 Claude Desktop 并列，同为客户端/产品面
v2.1.285 ”[Claude Tag] Added direct messages with Claude for members on an Enterprise plan Standard or Usage-Based Chat seat who also have Cowork; a seat that includes Claude Code is no longer required” Cowork 是一种独立的席位权益，且与「含 Claude Code 的席位」可分离
v2.1.280 ”Fixed memory write conflicts in Cowork sessions…” Cowork 有自己的会话类型
v2.1.277 ”Fixed WebFetch and WebSearch in Cowork cloud sessions not telling Claude why a request was refused…” Cowork 会话有独立的网络访问策略与预算

两条路径的归属由此分开：

Routines = Claude Code on the web（claude.ai/code）上的定时例程功能，changelog 中一律标 [Cloud sessions] / [Claude Code on the web]

Cowork = 一条独立的云端产品线，有独立席位权益、独立会话类型（Cowork sessions / Cowork cloud sessions）、独立的网络与遥测策略

因此本节「Routines 是 KAIROS 始终在线愿景的云端实现」的单一归因应改为并列归因：始终在线这条线上，官方实际跑着两条互相独立的产品路径。

版本	官方原文要点	判定价值
v2.1.274	”Fixed Cowork and claude.ai cloud sessions* with network access on treating reads of a teammate’s artifact as if network access were off”*	Cowork 与 claude.ai 云会话被并列为两种不同的环境
v2.1.274	”Added `enduser.sub`, the IdP subject, to the telemetry Claude Desktop and Cowork* send through a Claude apps gateway”*	Cowork 与 Claude Desktop 并列，同为客户端/产品面
v2.1.285	”[Claude Tag] Added direct messages with Claude for members on an Enterprise plan Standard or Usage-Based Chat seat who also have Cowork; a seat that includes Claude Code is no longer required”	Cowork 是一种独立的席位权益，且与「含 Claude Code 的席位」可分离
v2.1.280	”Fixed memory write conflicts in Cowork sessions…”	Cowork 有自己的会话类型
v2.1.277	”Fixed WebFetch and WebSearch in Cowork cloud sessions* not telling Claude why a request was refused…”*	Cowork 会话有独立的网络访问策略与预算

⚠️ 写入边界：官方 changelog 中确实出现了 Cowork scheduled tasks in the cloud（v2.1.267 修复其在「managed settings 要求沙箱化」的组织下启动失败），可确认 Cowork 确有云端定时任务这一事实；但其规格（间隔下限、每日次数上限等）本轮未从一手源核验，故此处不写任何具体参数。回源前不要引用任何传闻规格。

Routines 社区实践（材料截至 2026-08，未经持续复核）：Routines 已从预告阶段进入活跃使用——社区涌现大量生产级例程案例，如”夜班 Agent 模式”（定时自动执行代码审查与安全扫描）、“座位计数自动更新”（webhook 触发数据同步）等。这些案例直接验证了三路触发器架构的生产可行性，证明 KAIROS 的设计假设——“AI 不应被动等待指令”——在实际工程中是成立的。

⚠️ 上段案例的采集时点是 2026-08，本轮未重新核验其现状。官方侧同期（2026-09 下旬）修掉的那批 routine 可靠性问题见前文「主动性需要信任机制」一节的清单——读这段社区实践时应与那份清单合看：社区案例证明的是架构可行，官方修复清单说明的是这套架构在状态一致性上有系统性欠账。两者不冲突，但只引前者会得出过于乐观的结论。

实际里程碑（已实现 + 预测，截至 2026-09）

日期	版本/事件	对应 KAIROS 维度	已实现/待实现
2026-05-07	Routines 发布（“Code with Claude”）	始终在线（云端实现）	✅
2026-05-12	v2.1.139 Agent View + /goal	后台会话 + 目标驱动	✅
2026-06-10	v2.1.172 嵌套子Agent（5 层递归）	多层协调（Coordinator Mode 雏形）	✅
2026-06-18	Artifacts Beta	从终端到 Web（展示层突破）	✅
2026-07-02	Dynamic Workflows GA（Pro 计划）	编排基础（pipeline/parallel/agent 三原语）	✅
2026-07-03	v2.1.200/201 Manual 权限默认	安全自主（权限边界探索）	✅
待定	Coordinator Mode 完整发布	多 Agent 协调执行	⏳
待定	Dream Mode 离线整合	记忆自动维护 + 主动发现问题	⏳
2026-08-13	v2.1.232 子代理 fork 默认开启 + 非 teammate spawn 默认后台运行	编排能力下沉（从”显式定义”到”自主并行”）	✅
2026-08-14	Auto Mode 默认启用	后台 Agent 编排从”可选”→“默认”	✅
待定	定时唤醒（有触发条件）	会话级 `session_crons`，三入口 + cron 表达式	✅
待定	无触发条件的自主 tick	全自主行动	⏳

从编排到自主的关键跨越：Dynamic Workflows GA 的三原语（pipeline/parallel/agent）提供了编排层的现实锚点——Bun 96 万行移植案例展示了”声明式编排 → Agent 自主执行”的可行性，这正是 KAIROS 的核心假设。但关键差异仍然存在：Dynamic Workflows 是”人定义工作流”，KAIROS 的野心是”Agent 自主生成工作流”。v2.1.172 的嵌套子 Agent（5 层递归）向这个方向迈出了第一步——递归嵌套是”Agent 自主分解任务”的架构基础。

版本验证：v2.1.270 ~ v2.1.286（2026-09-12 ~ 2026-09-30）

本轮覆盖 17 个版本（一手源：code.claude.com/docs/en/changelog.md，全量 408 个版本块）。与本章相关的条目及落点：

版本	与本章相关的条目	本章落点
v2.1.271	Routines 页面改版（Yours / Templates 双 tab、双列卡片、移除日历视图）	Routines 产品化变化
v2.1.274	Cowork 与 `claude.ai cloud sessions` 并列；Claude Desktop 与 Cowork 并列（遥测 `enduser.sub`）；活跃的 `/goal` 在 resume 已压缩会话时丢失；hook 驱动会话以 “Prompt is too long” 结束；`/schedule` 保存 prompt 丢失 message role；编辑 routine 触发两次 / 72 小时重试	Cowork 并列归因；`/goal` 可靠性；信任清单（版本谎言）
v2.1.275	routine 运行写入 artifact 且无需询问即重新发布页面；移除一次性 routine 启动通知	Routines 产品化变化
v2.1.277	WebFetch / WebSearch 在 Cowork cloud sessions 中不说明拒绝原因（独立 fetch 预算与管理策略）	Cowork 并列归因
v2.1.280	Cowork 会话记忆写入冲突：>10,800 字符只看首尾，重试写入丢中间；Cowork sessions 会话类型；恢复既有会话的 routine 用旧 prompt 与旧名字运行	记忆写入侧；Cowork 并列归因；信任清单（版本谎言）
v2.1.281	远程会话的 scheduled routine 在首次工具调用前收不到 turn-start 通知	信任清单（上下文谎言）
v2.1.282	半小时偏移时区的每小时 routine，next run time 差 30 分钟	信任清单（时间谎言）
v2.1.283	新建 routine 默认整点过几分钟，并注明整点设置会晚几分钟	信任清单（时间谎言）
v2.1.284	auto-memory 加载时中和 `MEMORY.md` 与召回笔记中的不可见字符与仿冒 tag	记忆读取侧（注入面）
v2.1.285	Enterprise Standard / Usage-Based Chat 席位中「同时拥有 Cowork」的成员可用 DM，不再要求含 Claude Code 的席位	Cowork 独立席位权益
v2.1.286	云端会话从未启动的 routine 显示 Succeeded；迟到的计划运行显示过去的 next run time（改为 “Due”）	信任清单（假成功 / 时间谎言）

三项负面发现（状态维持不变，已写入状态表）：Coordinator 全量 changelog 命中 0；session_crons / CronCreate / ScheduleWakeup 在 delta 期命中 0（规格未变动）；KAIROS / dream 全量命中 0。

本轮最重要的单项是 Cowork 与 Routines 的并列归因——它结掉了本章 2026-09-12 留下的常设 TODO，把「始终在线」从一条云端路径改为两条。

当前状态

KAIROS 能力	状态	落地形式
后台会话托管	✅ 已发布	Agent View（Supervisor 进程），v2.1.140-145 持续改进：/json 脚本化接口、terminalSequence 钩子、目录范围会话过滤、插件依赖管理
自主行动判断	⚠️ 部分释放	/goal（用户设定目标条件替代 AI 判断），v2.1.140 改进反馈循环
始终在线运行	✅ 已发布	两条并列路径：Routines（Claude Code on the web 的云端定时例程）+ Cowork（独立云端产品线）
多层任务分解	✅ 已发布	v2.1.172 嵌套子Agent（最多 5 层递归，2026-06-10）
编排基础	✅ 已发布	Dynamic Workflows GA（pipeline/parallel/agent 三原语，2026-07-02）
SendUserMessage	✅ 已发布	Agent View 通知机制
ScheduleCron	✅ 已发布	会话级定时唤醒 `session_crons`——三入口（`CronCreate` 工具 / `ScheduleWakeup` 工具 / `/loop` 命令），标准 cron 表达式、`recurring` 周期开关、prompt 载荷上限 1000 字符；已作为 Stop hook 输入字段公开
GitHub Webhook 订阅	❌ 未公开	仍在 Feature Flag 后。
梦境模式整合	❌ 未公开	仍在 Feature Flag 后。截至 v2.1.286 复核未变：`dream` 在官方 changelog 全量 408 个版本块中命中数为 0——梦境模式至今毫无官方记载。
Coordinator Mode	❌ 未公开	`CLAUDE_CODE_COORDINATOR_MODE=1`，四阶段多代理协调。截至 v2.1.286 复核未变：`Coordinator` 全量 changelog 命中数为 0。

另外两项经复核仍然准确、本轮无需修改：session_crons 规格（session_crons / CronCreate / ScheduleWakeup 三个关键词在 delta 期命中数均为 0，即规格未变动）、以及 notify_when_idle（v2.1.236 记载未被推翻，全量命中 1）。

补充更新：Fast mode 模型从 Opus 4.6 升级至 Opus 4.7（v2.1.142）。v2.1.108 的 /branch 命令可作为 KAIROS Fork 操作策略的公开实现——在独立 git worktree 中创建分支，与原会话共享前缀缓存。

Anthropic 采取了与本章”从 KAIROS_BRIEF 到完整 KAIROS”一致的渐进发布策略——先释放低风险能力（后台会话、目标驱动执行），再逐步开放高风险能力（完全自主行动、定时任务调度）。

行业呼应：CMA 平台能力升级（2026-08）：Anthropic CMA 平台于 2026 年 8 月大幅升级——技能上限从 20 扩展到 500、引入五级思考力度调速（low/medium/high/xhigh/max）、子 Agent 实时流下探到线程级。这些变化虽然不是 KAIROS 的直接功能，但验证了一个趋势：Agent 编排正在从”单 Agent 响应”向”多 Agent 协调”演进——这正是 KAIROS Coordinator Mode 预期的方向。CMA 的 500 技能上限意味着 Anthropic 正在从工程层面为”大规模 Agent 编排”做准备。

专题：KAIROS 与梦境模式——当 AI 开始主动行动

为什么关注 KAIROS

KAIROS 的核心架构

运行模型：Tick 驱动

三个独占工具

`session_crons`：定时唤醒的官方规格

Coordinator Mode：KAIROS 的多代理协调层

外部集成

审计安全

梦境模式（Auto-Dream）

设计灵感

三重触发门控

四阶段整合循环

记忆分类体系

相关的隐藏功能

Daemon 模式

UDS Inbox（Unix Domain Socket 收件箱）

Teleport（跨机器传送）

对 Agent 产品设计的启示

1. 主动性需要信任机制

2. 从”被动响应”到”主动服务”的渐进路径

3. 记忆维护是长期运行的前提

4. 人类睡眠是好的隐喻

KAIROS 的渐进式落地

Agent View + /goal（v2.1.139, 2026.05.12）

Routines（“Code with Claude” 大会, 2026.05.07）

实际里程碑（已实现 + 预测，截至 2026-09）

版本验证：v2.1.270 ~ v2.1.286（2026-09-12 ~ 2026-09-30）

当前状态

为什么关注 KAIROS

KAIROS 的核心架构

运行模型：Tick 驱动

三个独占工具

session_crons：定时唤醒的官方规格

Coordinator Mode：KAIROS 的多代理协调层

外部集成

审计安全

梦境模式（Auto-Dream）

设计灵感

三重触发门控

四阶段整合循环

记忆分类体系

相关的隐藏功能

Daemon 模式

UDS Inbox（Unix Domain Socket 收件箱）

Teleport（跨机器传送）

对 Agent 产品设计的启示

1. 主动性需要信任机制

2. 从”被动响应”到”主动服务”的渐进路径

3. 记忆维护是长期运行的前提

4. 人类睡眠是好的隐喻

KAIROS 的渐进式落地

Agent View + /goal（v2.1.139, 2026.05.12）

Routines（“Code with Claude” 大会, 2026.05.07）

实际里程碑（已实现 + 预测，截至 2026-09）

版本验证：v2.1.270 ~ v2.1.286（2026-09-12 ~ 2026-09-30）

当前状态

`session_crons`：定时唤醒的官方规格