一條 append-only 日誌撐起全部信任：Muse Code 事件日誌的重播與斷點續跑

一條日誌，什麼都在裡面

這個設計簡單到近乎偏執：Muse Code 把每一次模型呼叫、每一次工具執行、每一次核准、每一筆編輯，全部附加寫進本機的事件日誌。不是聊天逐字稿，也不是摘要——而是實際的操作序列，按順序、存在你自己的機器上。Meta 稱它為 runtime 的唯一事實來源（single source of truth），這句話是字面意義：不管你想知道 agent 做了什麼，答案都住在這條日誌裡。

斷點續跑：當機不再昂貴

因為日誌記錄了失敗瞬間之前的一切，當機並不會讓 session 歸零——agent 會從停下的那一點精確接續，不必重跑先前的步驟。對五分鐘的小任務來說，這只是個貼心設計。但對 Muse Code 瞄準的長時程工作而言，這是產品能不能用的分界線：Meta 的核心最佳化案例研究跑了超過 1,000 次工具呼叫、耗時最長達 24 小時。沒有人敢把一個 24 小時的工作，交給一個第 23 小時可能人間蒸發的 runtime。

精確重播：一步一步稽核

讓重啟安全的同一個特性，也讓 session 變得可以審閱。muse replay 會把一場已記錄的 session 逐步走一遍——每一次 subagent 的生成、每一次指揮修正、每一次取消，全按實際發生的順序。當 agent 做了一個你看不懂的決定，你不必質問它；你重播一遍，親眼看它怎麼走的。

完整的軌跡也能匯出。這讓一場 agent session 變成一件可以交給同事審查、或附進合規紀錄的東西——外部的人不必重跑任何步驟，就有足夠的脈絡評估 agent 的推理。對那些（有理由地）用懷疑眼光看待 AI 產出變更的團隊來說，他們拿到的是針對過程的 code review 產物，而不只是那份 diff。

為什麼多 agent 之下這件事更重要

單一 agent 的歷史，往終端機的回捲紀錄裡瞄一眼就夠了。但 Muse Code 跑的是常駐背景 agent，還會把工作分派給平行的子 agent——這些活動在設計上就不是要你即時盯著的。「完全可稽核」正是讓「預設即多代理」變得可以接受的那顆秤砣：那些 agent 在你沒看著的時候做的每一件事，事後都是透明、可追溯、可重播的。自主性和可稽核性是成對送達的，不是二選一的取捨。

更大的圖景

事件溯源（event sourcing）——從一條只附加寫入的事實日誌推導出狀態——是分散式系統界幾十年的老概念，而它正悄悄成為 agent 可靠性問題的標準答案。Muse Code 示範的是：單一一個基礎元件能撐起多大的產品表面積——當機復原、逐步除錯、session 交接、合規匯出，全是同一條日誌戴著不同的帽子。先從一個小任務開始，然後重播它——快速上手大約只要五分鐘。