在 Claude Code 洩漏的 512,000 行原始碼裡，有一個字出現超過 150 次：KAIROS。
它不是一個函數名稱，不是一個變數，而是一個設計哲學的代號。而理解這個代號，你就能看清 Anthropic 打算把 AI coding assistant 推到什麼位置——遠遠超出你目前對「AI 幫手」的想像。
KAIROS 是什麼？——從古希臘哲學到 AI 自主性
古希臘的兩種時間
古希臘人對「時間」有一組精彩的區分，而且不只是語言上的差異，是完全不同的哲學觀：
- Chronos（χρόνος）：線性、量化的時間，一秒一秒往前走。你手上的碼錶、伺服器的 system clock、cron job 的排程表——這些都是 Chronos 的產物。它冷冰冰的，不管你準備好了沒有，時間就是會到。
- Kairos（καιρός）：「最恰當的那個時刻」，是質的時間，是行動的時機。在修辭學裡，Kairos 指的是演說者看準聽眾情緒、抓住轉折瞬間出手的能力。在射箭裡，它指箭離弦的那個完美瞬間——不早不晚。
亞里斯多德在《尼各馬可倫理學》裡把 Kairos 跟「實踐智慧」（phronesis）綁在一起：光知道「該做什麼」不夠，你還要知道「什麼時候做」。一個好醫生不只知道藥方，他知道什麼時候該開刀、什麼時候該再觀察。
Anthropic 把這個字放進 Claude Code 的背景代理系統，這個命名選擇本身就是一個宣言：AI 不應該只是被動等待指令，它應該有能力自己判斷介入的時機。
從 on-demand 到 always-on 的哲學轉變
目前 AI coding assistant 的主流設計——不管是 Claude Code、Cursor 還是 GitHub Copilot——都是 on-demand 模型：你叫它，它才動。你打開編輯器、選一段程式碼、輸入 prompt，它回應。關掉視窗，它就不存在了。
這像是古希臘的 Chronos 觀點：AI 存在於你分配給它的那段時間裡，不多不少。
KAIROS 要做的事完全不同。它代表的是一個根本性的架構轉變：Claude Code 從一個「工具」升級成一個「daemon」——一個常駐在你開發環境裡、持續感知周圍狀態、自主判斷行動時機的背景程序。
如果你熟悉 Plan Mode 和 Agent Mode，可以這樣理解它們的區別：
- Plan Mode：你提出問題，Claude 先規劃再執行。主導權完全在你。
- Agent Mode：你給一個目標，Claude 自己拆解步驟、呼叫工具、迭代修正。但啟動的觸發點還是你。
- KAIROS Mode：沒有人觸發。Claude 自己觀察環境、自己決定是否行動、自己選擇行動方式。你可能在睡覺，它在幫你 review PR。
這不是漸進式的功能升級，是 AI 自主性的一個量級跳躍。
15 秒決策週期的技術細節
核心的 polling loop
KAIROS 的核心是一個 15 秒輪詢循環（polling loop）。
每 15 秒，它做一次環境狀態評估，決定是否需要觸發行動。你可以把它想像成這樣的虛擬碼：
while (daemon_running) {
state = assess_environment() // 讀取 repo 狀態、PR 變化、使用者活動
decision = evaluate(state) // 判斷是否需要行動
if (decision.should_act) {
execute(decision.action) // 執行行動
}
sleep(15_000) // 等 15 秒
}
為什麼是 15 秒？
這個數字不是隨便選的。它是多方權衡下的結果：
太短（例如 1-3 秒）的問題：
- 每次評估都需要載入環境狀態，這有 I/O 成本
- 如果觸發了 LLM 推理，API 呼叫本身可能就要 2-5 秒
- 在多個 KAIROS 實例同時運作的場景下，過於頻繁的 polling 會產生競爭條件（race condition）
- CPU 和 API 費用會爆炸性成長
太長（例如 60 秒或更久）的問題：
- 對 GitHub webhook 事件的反應速度太慢——有人 push 了一個 commit，你等一分鐘才回應，體驗像是在跟 1990 年代的 email bot 溝通
- 錯過短暫的行動窗口（Kairos 的核心精神就是抓住時機）
- 使用者會覺得 AI 反應遲鈍
15 秒的平衡點：
- 足夠快，讓 webhook 事件在合理時間內被處理
- 足夠慢，不會造成明顯的 idle CPU 消耗
- 跟人類「掃一眼 Slack 訊息」的頻率接近——大約就是你偶爾瞄一下通知列的節奏
blocking budget 的意義
每次決策有一個 15 秒的 blocking budget——如果在這個時間窗口內無法做出決策，就放棄這次機會，等下一個週期。
這個設計是為了解決 daemon 開發中最經典的問題：hang。如果 AI 的一次評估因為某個 API timeout、檔案鎖、或者 LLM 回應延遲而卡住，沒有 blocking budget 的話，整個 daemon 就死在那裡了。15 秒輪詢 + 15 秒決策上限，確保就算某個判斷失敗，最多也只延遲 30 秒就回到正軌。
這跟你寫 HTTP server 時設 request timeout 是一樣的道理——你不會讓一個慢查詢拖垮整個服務。
跟傳統 cron job 的根本差異
你可能會想：「這不就是 cron job 嗎？每 15 秒跑一次？」
表面上看很像，但有兩個根本差異：
第一，cron job 是無狀態的。 每次執行都是一個全新的 process，不知道上一次做了什麼。KAIROS 的 polling loop 是有狀態的——它持續維護一個環境模型（mental model），知道上次評估的結果、目前追蹤中的事項、正在等待的事件。
第二，cron job 的行動是預先定義的。 你在 crontab 寫死了要執行什麼 script。KAIROS 的行動是即時推理決定的——它不是跑一個固定腳本，而是根據當下的環境狀態，用 LLM 推理來決定「我現在應該做什麼」。
這比較像是 Kubernetes 的 control loop：持續觀察實際狀態、跟期望狀態比對、決定是否需要修正。只不過 KAIROS 的「控制器」是一個語言模型。
5 分鐘排程重整
除了 15 秒的核心 loop，KAIROS 還有一個每 5 分鐘的排程重整（scheduled reorientation），用來做更深層的環境感知更新。
15 秒的 loop 像是「快速掃一眼」——檢查有沒有新事件需要回應。5 分鐘的重整像是「坐下來重新盤點」——重新載入專案結構、更新依賴狀態、刷新對工作脈絡的理解。這兩層頻率搭配，讓 KAIROS 既能快速反應，又能維持對全局的掌握。
5 個 KAIROS 專屬工具——每個都是一個新能力維度
一般使用者的 Claude Code 有 19 個沙箱工具（讀檔、寫檔、跑指令、搜尋等）。KAIROS 模式在這之上多了 5 個，而這 5 個工具每一個都代表了 AI agent 能力的一個新維度：
1. Push Notification（主動推播通知）
用途： KAIROS 可以主動推送通知到你的裝置——手機、桌面、甚至是 Slack channel。
使用場景舉例：
- KAIROS 偵測到你的 production build 失敗了，凌晨 2 點推一則通知給你：「main branch 的 build 在 step
npm run test失敗，看起來是UserService.test.ts的 mock 過期了。我已經開了一個 fix PR #287，你起床後 review 一下。」 - 一個重要的 dependency 發佈了安全更新，KAIROS 判斷你的專案受影響，推送通知建議你升級。
潛在影響： 這把 AI 從「你去找它」變成「它來找你」。好處是不會漏掉重要事件；風險是如果判斷標準沒調好，你會被通知轟炸。
2. 定期檔案投遞（Scheduled File Delivery）
用途： 設定排程，自動產出並交付報告或檔案。
使用場景舉例：
- 每週一早上 9 點，自動產出一份上週的 commit 統計、PR 合併速度、未關閉 issue 清單，以 Markdown 格式放到你的 repo 裡。
- 每天下班前，產出當天的工作摘要，包括你修了什麼、還有什麼 TODO 沒完成。
潛在影響： 這讓 AI 從被動的問答工具，變成一個會主動產出「交付物」的團隊成員。
3. PR 訂閱監聽（PR Subscription）
用途： 監控指定的 Pull Request 狀態變化，在 PR 有更新時觸發對應行動。
使用場景舉例：
- 你開了一個 PR 等同事 review，KAIROS 訂閱了這個 PR。當同事留了 comment 要求修改，KAIROS 讀取 comment、分析修改建議、自動推一個 fix commit 到同一個 branch（當然需要你先授權這個行為）。
- PR 的 CI 過了，KAIROS 主動通知你可以 merge 了。
潛在影響： 大幅縮短 PR review 的來回時間。不用每小時去 GitHub 看有沒有新 comment。
4. GitHub Webhook（自動接收 repo 事件）
用途： 不需要使用者觸發，KAIROS 自動接收 repo 的所有事件——push、PR 開關、issue 變更、release 發佈等。
這是 KAIROS 五個工具裡最具顛覆性的一個。我們來看一個具體場景：
凌晨 3 點，你的同事在美國那邊 push 了一個 bug fix PR。KAIROS 的 webhook 收到事件，自動醒來。它讀取 PR 的 diff，發現修正了一個 null pointer exception，但同時注意到 PR 裡有一個 edge case 沒覆蓋到——如果
user.profile是undefined（不只是null），同樣的 crash 會再發生。KAIROS 在 PR 上留了一則 comment，附上建議的修正程式碼和對應的 test case。你的同事隔天上班看到，加上 fix，merge。你早上起床的時候，這個 bug 已經修好了。
整個過程沒有人類主動觸發 AI——KAIROS 是被 GitHub 事件叫醒的。
潛在影響： 如果這個功能成熟，「AI reviewer」就不再是一個行銷 buzzword，而是一個 24/7 真正在運作的角色。但同時也帶來信任問題——你願意讓 AI 在你睡覺的時候對你的 repo 做事嗎？
5. 排程重整（Scheduled Reorientation）
用途： 每 5 分鐘主動更新環境狀態理解。
使用場景舉例：
- 你在一個 monorepo 裡工作，KAIROS 每 5 分鐘掃一次有沒有新的 package 被加進來、有沒有 dependency 衝突、有沒有 lockfile 不一致的問題。
- 專案的
.env.example被更新了，KAIROS 注意到你的本地.env少了新的環境變數，推一則提醒。
潛在影響： 這是 KAIROS 維持「Kairos 感知」的基礎——如果它對環境的理解過時了，它的所有判斷都會不準。
autoDream：三閘門觸發機制的設計邏輯
KAIROS 包含一個子系統叫 autoDream，設計用途是在你閒置的時候，自動整理 Claude Code 的長期記憶。
它不是隨時都跑的，必須同時滿足三個條件才會啟動：
條件一：距離上次整合超過 24 小時
條件二：累積了 5 個以上完整 session
條件三：成功取得整合鎖（consolidation lock）
為什麼需要三個條件，而不是一個就夠？
這是一個經典的多重保險設計模式。讓我們逐一拆解每個條件存在的理由：
條件一（24 小時冷卻期）防的是「過度整合」。 記憶整合不是免費的——它需要 LLM 推理，消耗 API quota 和 CPU。如果每次有新 session 結束就跑整合，成本會非常高。更重要的是，過於頻繁的整合可能會「過度壓縮」記憶，在資訊還沒沉澱之前就急著歸納，反而丟失有價值的細節。這跟人類的睡眠記憶整合是同一個道理——你不會每工作 10 分鐘就去睡一覺來鞏固記憶。
條件二（5 個 session 門檻）防的是「無料整合」。 如果你一天只跟 Claude 聊了一次，那次對話的內容大概率已經被直接寫進記憶了，沒有什麼需要「整合」的。5 個 session 是一個合理的下限——代表你已經在多個不同的脈絡下跟 Claude 互動過，可能產生了矛盾的資訊、重複的片段、需要合併的知識塊。
條件三（consolidation lock）防的是「並行衝突」。 這是最關鍵的工程保護機制。
consolidation lock 的實作推測
根據洩漏的原始碼線索，consolidation lock 很可能是以下兩種實作之一：
方案 A：File lock
在 ~/.claude/ 目錄下建立一個 lock file（例如 .consolidation.lock），用 flock 或類似的 OS-level file locking 機制。優點是實作簡單、跨 process 可靠；缺點是如果 process 意外被 kill，lock file 可能殘留（stale lock）。
方案 B：Process lock + PID check lock file 裡面寫入持有鎖的 process ID，每次嘗試取鎖時先檢查該 PID 是否還活著。如果 process 已死，就清除 stale lock 並取得新鎖。
不管是哪種方案，都會有一個問題：如果鎖被卡住怎麼辦？
合理的推測是 autoDream 有一個鎖的 TTL（Time To Live）。例如，consolidation lock 超過 30 分鐘沒有被釋放，就自動視為 stale 並強制清除。這解決了 process crash 後 lock 殘留的問題，同時 30 分鐘也足夠讓正常的整合流程跑完。
如果你對 lock 機制有經驗，你會知道這其實是分散式系統裡 lease-based locking 的簡化版——跟 Redis 的 SETNX + EXPIRE 思路一模一樣，只是 autoDream 跑在單機上，用 file system 就夠了。
四個執行階段深挖
autoDream 的執行分成四個明確的階段，每個階段都有具體的操作邏輯：
階段一：Orient（定向）
掃描現有記憶庫，找出需要處理的問題。具體來說，Orient 階段會偵測三類異常：
矛盾偵測： 假設你上週跟 Claude 說「我們的 API 用 REST」，但這週的 session 裡你一直在寫 GraphQL resolver——Orient 階段就會標記這個矛盾：「使用者的 API 風格偏好可能已經改變」。
重複偵測： 你在五個不同的 session 裡都提過「deploy 要先跑 npm run build」，Orient 會標記這五條記憶為「可合併」——它們可以被壓縮成一條。
過期偵測： 記憶裡記著「payment-service 有一個已知的 race condition bug」，但最近的 session 顯示那個 PR 已經 merge 並部署了。Orient 標記這條記憶為「可能過期」。
階段二：Gather Signal（收集訊號）
從近期的 session log 抽取有意義的資訊，評估哪些值得長期保留。
評估的核心問題是：這個資訊在未來的 session 裡還會有用嗎？
例如，如果你一直在做某個專案，相關的決策和脈絡就值得保留：「使用者選擇 Drizzle ORM 而不是 Prisma，原因是 Drizzle 的 type inference 更好」——這條資訊在未來每次討論 DB 操作時都有用。
相反的，如果只是一次性的查詢——「幫我把這段 Python 翻成 TypeScript」——這種記憶的長期價值就很低。
Gather Signal 還有一個重要任務：偵測行為模式。不是記住個別事件，而是歸納出趨勢。例如，Claude 可能會注意到「使用者最近三個 session 都在處理效能問題」，這個 pattern 本身就值得記住，因為下次對話時 Claude 可以主動從效能角度思考。
階段三：Consolidate（整合）
將近似的記憶合併，解決矛盾，把碎片整理成結構化的知識塊。
這是最耗計算資源的階段——它需要 LLM 做大量的「理解 + 重寫」工作。具體操作包括：
- 合併： 把「使用者偏好 Tailwind CSS」和「使用者用 Tailwind v4，不用 config file」和「使用者的 Tailwind 主題定義在 globals.css」合併成一條完整的記憶。
- 解衝突： 判斷矛盾的記憶中哪一個是最新的、哪一個應該被保留。通常越新的資訊優先權越高，但也有例外——例如使用者明確表達的「永久偏好」應該覆蓋時序上更新的「一次性選擇」。
- 結構化： 把散落的記憶片段組織成有邏輯的知識區塊。例如，把所有跟部署流程相關的記憶歸到一起，形成一個「部署」主題。
階段四：Prune/Index（修剪與索引）
刪除低價值記憶，同時更新索引確保剩下的記憶能被快速找到。
最重要的硬限制：MEMORY.md 必須控制在 25KB 以下。
這個上限是刻意設計的——MEMORY.md 是每個 session 都會載入的主索引，太大會拖慢每次的啟動時間，也會佔用更多 context window。Prune 階段的工作就是確保在這個預算內，保留價值最高的記憶。
被刪除的記憶不是真的消失——它們只是從第一層（主索引）降級到第二層（主題知識庫）或第三層（對話片段）。如果未來某次對話需要這些記憶，語義搜尋還是能把它們撈回來。
三層記憶架構——AI 版的人類記憶系統
autoDream 整理的，是 Claude Code 三層記憶系統的頂層。這個三層設計跟認知科學裡的人類記憶模型有驚人的對應關係：
第一層：MEMORY.md 主索引 ≈ 人類的工作記憶
每條記憶約 150 字，固定載入到工作記憶。上限 25KB。
這對應到人類的工作記憶（working memory）——你在任何時刻能主動「想著」的資訊。心理學家 George Miller 在 1956 年提出的「神奇數字 7±2」說的就是工作記憶的容量限制。MEMORY.md 的 25KB 上限就是 Claude 的「7±2」。
為什麼 25KB 是合理的？ 25KB 的純文字大約是 12,000-15,000 個中文字，或 6,000-8,000 個英文單字。以每條記憶 150 字計算，大約能放 80-100 條摘要。這足以涵蓋一個開發者的核心偏好、主要專案的架構決策、常用的工作流程——但不會多到讓 Claude 每次啟動都要花大量的 context window 去讀索引。
對照 Claude 的 context window（目前約 200K tokens），25KB 的 MEMORY.md 大約佔用 8,000-10,000 tokens——剩下 190K 給實際對話使用。這是一個精心計算過的比例。
第二層：主題知識庫 ≈ 人類的長期記憶
分散在各主題檔案（專案慣例、常見 bug 類型、個人偏好），按需要才載入，不是每次全部讀進來。
這對應到人類的長期記憶（long-term memory）——你知道的所有事情，但不是每一秒都在想的。當有人問你「Python 的 list comprehension 語法是什麼」，你的大腦從長期記憶裡提取這段知識到工作記憶。Claude 的主題知識庫也是同樣的機制——需要的時候才載入。
第三層：對話片段 ≈ 人類的情節記憶
過去完整的對話紀錄，透過語義搜尋提取相關片段。
這對應到人類的情節記憶（episodic memory）——你記得的具體事件和經歷。「上個月那次 deploy 出錯，最後發現是環境變數沒設」——這是一個情節記憶。Claude 的對話片段就是它的情節記憶庫，語義搜尋就是它「回想」的機制。
autoDream 的工作是保持第一層精簡、第二層有條理、第三層可被搜尋。就像人類睡覺時大腦做的事——把白天的經歷整理歸檔，重要的鞏固、不重要的淡忘。
KAIROS vs. Cursor vs. GitHub Copilot——always-on 與 on-demand 的取捨
KAIROS 代表的 always-on 設計，跟目前主流工具的 on-demand 設計，是兩種完全不同的哲學。各有什麼優缺點？
Cursor / GitHub Copilot：on-demand 模型
優點：
- 零閒置成本。 你不用的時候，它不消耗任何資源。
- 可預測性高。 AI 只在你明確要求時行動，不會出現「我不知道它在背後做了什麼」的情況。
- 隱私控制明確。 你清楚知道什麼資料被送給 AI——就是你當下選中的那段程式碼和 prompt。
- 啟動快。 不需要維護狀態，不需要預載記憶，打開就用。
缺點：
- 反應式，不是預防式。 你要先注意到問題，才能請 AI 幫忙。如果問題發生在你不在電腦前的時候，就錯過了。
- 沒有持續的環境感知。 每次對話都是從零開始理解你的專案——就算有 context 機制，也不如一個持續觀察的 daemon。
- 無法跨時區協作。 你的 AI 幫手跟你一起下班。
KAIROS：always-on 模型
優點：
- 預防式行動。 不只是修 bug，更能在 bug 被 merge 之前就攔截。
- 跨時區無縫。 你在睡覺，KAIROS 還在 review 美國同事的 PR。
- 累積式學習。 持續觀察你的工作模式，時間越長越了解你。
- 真正的自動化。 不是你設好的 script，而是 AI 即時判斷該做什麼。
缺點：
- 持續的資源消耗。 就算什麼都不做，polling loop 也在跑。
- 不可預測性。 「AI 在我睡覺時做了什麼？」這個問題會讓有些人不安。
- 信任門檻高。 你需要極度信任 AI 的判斷力，才會讓它在無人監督的情況下對你的 repo 做事。
- debug 困難。 如果 KAIROS 在深夜做了一個錯誤的決策，你隔天要花時間追溯「它為什麼這樣做」。
最終，這不是「誰比較好」的問題
而是你的工作場景需要哪種模式。個人 side project？on-demand 就夠了。多人協作、跨時區團隊、需要 24/7 監控的 production 環境？KAIROS 的 always-on 設計才能發揮價值。
對 VPS 資源的具體影響
KAIROS 還沒有正式上線，但根據它的架構設計，我們可以合理推估它對伺服器資源的影響：
CPU 消耗預估
Idle 狀態（只跑 polling loop，不觸發行動）：
- 每 15 秒一次的環境評估，主要是讀取檔案系統狀態和 git status。預估持續佔用 1-3% 的單核 CPU。
- 這聽起來很低，但如果你的 VPS 只有 1 核心，3% 的持續佔用長期下來還是會出現在帳單上。
Active 狀態（webhook 觸發行動）：
- 每次行動需要 LLM 推理，推理期間會佔用較高的 CPU（處理 API 回應、解析結果、執行工具呼叫）。預估單次行動的 CPU spike 在 15-40% 單核，持續 5-30 秒。
- 如果是做 code review 這種複雜任務，可能需要多輪推理，CPU spike 會延長。
記憶體消耗預估
常駐記憶體：
- KAIROS daemon 本身（Node.js process）：80-150 MB
- 環境狀態快取（repo metadata、PR 追蹤列表）：20-50 MB
- 記憶索引（MEMORY.md 載入 + 主題知識庫索引）：10-30 MB
- 總計常駐：約 110-230 MB
autoDream 觸發時的峰值：
- Consolidate 階段需要載入多個 session log 進行比對和重寫，記憶體會暫時額外增加 50-150 MB。
- 峰值總計：約 160-380 MB
autoDream 觸發時的 Load 預估
整合階段（Consolidate）是最耗資源的。它需要：
- 載入所有待整合的 session log（I/O bound）
- 用 LLM 做多輪推理來合併記憶（API call + CPU）
- 寫入更新後的記憶檔案（I/O bound）
預估一次完整的 autoDream 執行時間是 3-10 分鐘，期間 CPU 使用率可能維持在 20-50% 單核。好消息是它最多每 24 小時跑一次，而且通常在你閒置的時候——所以不會跟你的正常工作搶資源。
建議的最低 VPS 規格
| 使用場景 | 建議規格 | 對應方案 |
|---|---|---|
| 單人開發 + KAIROS 基本監控 | 2 核 / 2 GB RAM | 侃瑞科技 S 方案 |
| 團隊開發 + 多 repo 監控 | 2 核 / 4 GB RAM | 侃瑞科技 M 方案 |
| Production + KAIROS + 其他服務共存 | 4 核 / 8 GB RAM | 侃瑞科技 L 方案 |
核心原則：不要把 AI Agent 的伺服器資源算到剛好。 KAIROS 這類 daemon 的存在，代表你需要替「空閒時的持續消耗」和「autoDream 觸發時的峰值」都預留緩衝——建議至少保留 20-30% 的資源餘裕。
如果你現在就在 VPS 上跑 Claude Code，可以用 htop 觀察一下 idle 狀態下的 CPU 使用率和記憶體佔用，作為未來規劃的基線。
→ 回到 44 個隱藏功能完整清單 → Undercover Mode 與反蒸餾的倫理爭議
在自己的 VPS 上掌握 AI Agent 的完整資源控制權。查看侃瑞科技 VPS 方案 →
參考來源：