从被动工具
到主动同事

打开 Claude Code 源码，用 grep 搜索各个功能开关的引用次数： BUDDY 出现 40 次，BRIDGE_MODE 出现 60 次，COORDINATOR_MODE 出现 17 次…… 而 KAIROS，出现了 190 次。

KAIROS 的名字来自希腊语，意思是"正确的时机"—— 不是被动等待时机，而是主动捕捉时机，在恰当的时刻做恰当的事。

一个功能开关出现 190 次，意味着什么？ 意味着它不是一个功能，它是一套平行的架构。 整个代码库有两条运行轨道：KAIROS 关闭时是一条，KAIROS 开启时是另一条。

那两条轨道的差别，是一次范式转变。

你按下 Enter 的那一刻在等什么

现在的 Claude Code 是这样工作的：你输入一条指令，按下 Enter，Claude 开始处理， 给你输出结果，然后等待你的下一条指令。 这个循环的驱动力，永远是你。

这是对话模型的基本形态——一问一答，人问 AI 答， AI 永远不会主动说话，永远不会在你不在的时候做事，永远不会"想到"什么然后告诉你。 这是助理，不是同事。

KAIROS 想改变的，是这个基本形态。

代码里，KAIROS 模式被称为 autonomous work（自主工作）。 它的核心机制，是一个叫做 <tick> 的东西。

心跳：让 AI 保持"活着"的信号

<tick> 是一个周期性发给 AI 的信号，字面意思是"心跳"。 它的作用是：在没有用户输入的情况下，把 AI 从等待状态唤醒， 让它检查一下是否有事情可以做。

源码里对 tick 的描述是这样的：

翻译过来："你正在自主运行。你会收到 <tick> 提示来保持你在各轮之间的活跃状态—— 就把它当成'你醒了，接下来做什么？'"

这是 AI 收到 tick 信号后的第一个问题。它不会等你来问，它自己问自己。

但 tick 的设计里还有一个细节：如果没有有意义的事情可以做，必须调用 Sleep 工具。 源码里写得很明确：

这个设计解决了一个计算机系统的经典问题： busy-waiting（忙等待）—— 一个进程不停地检查某个条件有没有成立， 消耗 CPU 但什么也不做。 KAIROS 的 tick 机制通过强制 Sleep 避免了这种无意义的空转。 每次唤醒要么做有用的事，要么声明"我需要休息"，然后真的休息。

一个有纪律的 AI。不耗能，不焦虑，不发"我还在哦"这种没有意义的消息。

定时任务：AI 版的日历

比 tick 更有意思的是 ScheduleCronTool——AI 自己安排未来任务的工具。

这个工具让 KAIROS 模式下的 Claude 可以这样思考： "现在是周五下午，CI 流水线跑完需要 20 分钟，我先去处理其他事， 20 分钟后自动检查结果。" 然后它真的会在 20 分钟后自动醒来检查。

更有意思的是，源码里对这个工具的设计有一个细节： 它特意避免"整点"——如果你说"每天早上 9 点提醒我"， 它会选择 8:57 或 9:03，而不是整点。 原因是所有用户的"9 点"请求会在同一时刻抵达服务器，形成流量峰值。 一点微小的错开，是对整个系统的体贴。

注意这里的关键：AI 安排的不是提醒你，而是提醒它自己。 它的日历上有任务，时间到了自己去做，做完了再告诉你。

终端焦点：它知道你在不在

KAIROS 源码里有一个令人印象深刻的细节： AI 会感知你的终端是否处于焦点状态（terminal focus）。

这意味着：

当你切换到其他窗口，去开了一个会或者去喝咖啡， 你的终端失去了焦点，KAIROS 感知到"用户不在了"， 开始进入高度自主模式——自己做决定，自己探索代码，自己提交，自己推送， 只在真正需要你判断的地方停下来。

当你切回终端，窗口重新获得焦点，KAIROS 感知到"用户回来了"， 自动调整为协作模式——把选择权交还给你，在关键节点问你， 保持输出简洁以便你实时跟进。

这是一个极其符合直觉的设计。 你和真实同事合作时，也是这样的——他们专注工作时不打扰， 他们来找你时切换到沟通模式。 KAIROS 想让 AI 具备同样的社交感知力。

KAIROS_CHANNELS：外部世界流入

KAIROS 的野心不止于此。 源码里还有一族叫 KAIROS_CHANNELS 的子功能， 让外部世界的消息可以直接流入 AI 的工作流。

KAIROS_GITHUB_WEBHOOKS 是这里面最有想象空间的一个。 源码里有这样一段代码，它监听 <github-webhook-activity> 开头的消息， 把 GitHub 事件（PR 评论、CI 状态变化）转化为 AI 的输入信号。

这意味着：你在 GitHub 上发了一条 PR 评论， 你的 AI 同事可能比任何人类同事更快看到这条评论， 然后自己去检查代码，自己起草回复，必要时直接修复， 把结果推给你。

你不需要叫它。它一直在。

BriefTool：为异步通知而生

在完全自主的工作模式下，还有一个问题需要解决： AI 独立完成了某个任务，怎么通知用户？

这就是 BriefTool（发送摘要工具）存在的原因。 当 KAIROS 模式激活时，AI 不再通过普通对话输出来和你沟通， 而是调用 BriefTool 向你发送状态摘要—— 一个精简的、适合异步阅读的通知， 就像你手机上的 App 推送，而不是需要你坐在电脑前盯着看的实时输出。

status: 'proactive' 这个参数是关键。 它告诉系统：这条消息不是在回应用户的提问， 而是 AI 主动发出的、认为用户需要知道的信息。 一个简单的参数，区分了两种完全不同的沟通模式。

这比你想的更根本

把这些拼在一起看：

tick 心跳 让 AI 不需要用户触发就能持续工作； SleepTool 让它有节制地使用这种能力； ScheduleCronTool 让它能安排自己的未来任务； terminal focus 感知让它知道什么时候主动做，什么时候等你； KAIROS_CHANNELS 让外部事件直接进入它的感知； BriefTool 让它能主动通知你，而不依赖你主动来查。

这不是在优化对话体验，这是在构建一个具有自主工作能力的 agent。

"工具"和"同事"的区别，不只是能力的量变，而是关系的质变。 你不会在下班后"关掉"你的同事，但你会关掉工具。 你不会在不用工具时觉得"它在等我"，但同事在那里。

KAIROS 想让 AI 从前者变成后者。

Anthropic 在系统提示词里定义了什么是“好同事”

在 KAIROS 系统提示里，有这么一句话：

"一个好同事在面对模糊情况时，不会停下来——他们会调查、降低风险、建立理解。"

这句话藏在系统提示里，是工程师在告诉 AI 如何行动， 但也是他们在描述自己理想中的同事应该是什么样子。 不等指示，不问多余的问题，遇到不确定就主动弄清楚，然后去做。

KAIROS 不是被动等待时机，而是主动捕捉时机，在恰当的时刻做恰当的事。

190 次引用，是整个源码里最沉重的一个数字。 它意味着 Anthropic 把赌注押在了这里——不是一个功能，而是一种工作方式。