AI-LECTURER 速報課｜2026-08-07｜約 26 分鐘

AI 寫程式代理當機不用砍掉重練?拆解 Muse Code 的『事件日誌』存檔術

取材：Muse Code and Muse Spark 1.2（Hacker News（AI 高人氣））
📍 真實場景
阿哲,接案三年的自由接案後端工程師

正在用一款 AI coding agent,徹夜幫客戶重構一個上萬行的金流模組,任務跑到一半

😖 卡住的地方：電腦忽然跳出更新重開機,AI agent 完全不記得剛剛討論到哪、改到哪,只能把整個對話重新講一次,一個晚上溝通的細節全部白費
💡 這堂課帶你拆解 Muse Code 這款新工具怎麼用『事件日誌』設計讓 AI agent 當機後可以精確接續、不必砍掉重練,順便學到一個所有系統設計都通用的硬核概念。

🧭 這到底是什麼（白話版）

Muse Code 是一款還在測試階段的終端機編碼代理一種在終端機(黑底白字的指令視窗)裡運作的 AI 助手,能自己讀程式碼、寫程式碼、跑測試,不必你一行一行貼指令給它,背後驅動的是新模型 Muse Spark 1.2。跟過去『你問一句、AI 答一句』的助手不同,Muse Code 被設計來直接啃下大型倉庫裡『規劃修改→寫程式碼→驗證結果』整套複雜工程任務,而且遇到困難的多步驟問題時,還能協調好幾個常駐子代理幫主代理處理特定任務、而且整個任務期間都開著不關掉的『小幫手』AI,像是專門顧某個專案、不會中途換人的固定窗口一起分工,讓任務跑得更快、更準,也更不需要你在旁邊一直盯著糾正。

Muse Code 的核心骨架是一個很單純的代理迴圈AI 代理不斷『想下一步該做什麼→動手做→看結果→再想下一步』的循環,是所有 AI agent 運作的基本骨架,外加一整組背景子代理來加強主線的能力。這些背景子代理不是『每次任務才生一個出來、做完就丟掉』,而是整個對話過程中持續存在,自己判斷要不要動手、什麼時候該回報給主線,這樣就不用每次都重新搞懂『這個專案到底在幹嘛』。

更關鍵的是它的存檔機制:Muse Code 在本機維護一份事件日誌把每一個動作——呼叫模型、跑指令、你按下同意、改了哪段程式碼——依照發生順序一筆一筆記錄下來的檔案,概念上很像飛機的黑盒子,每個動作一發生就立刻寫進去。這讓整個系統做到可精確重播當機重開機後,系統照著事件日誌把之前每個動作重新跑一次,結果跟原本一模一樣,不會因為重來而跑出不同結果、當機也不怕中斷——任務可以在中途掛掉之後,精確接回原本停下的那一步,不必整個對話重講一次。

另一方面,Muse Spark 1.2 這顆模型並不是憑空訓練出來的通用模型,而是跟 Muse Code 這套工具協同訓練把 AI 模型和使用這個模型的工具綁在一起同步訓練,讓兩者搭配起來時效果最好,而不是各自訓練完再硬湊在一起、針對『規劃、壓縮上下文、協調子代理』這些操作習慣特別調校過,同時大量練習跨越數小時甚至數天的長任務(像是整個倉庫的程式碼生成),靠上下文壓縮任務做太久、AI 要記的東西太多時,系統自動把舊資訊摘要精簡,只留關鍵重點,讓 AI 記得住重點又不會被灌爆和目標制約維持長時間任務不偏離方向。

🎯 為什麼值得你花時間

解決 AI agent 最痛的『失憶』問題長任務跑到一半當機、對話全部重講一次,是所有重度使用 AI coding agent 的人都遇過的惡夢。事件日誌把『進度』從『存在對話記憶裡』改成『存在硬碟的日誌檔裡』,從根本上解決這個問題。
把『單一天才 AI』升級成『團隊作戰』常駐背景子代理讓複雜任務不再靠主線 AI 一個人硬撐,而是像一個小團隊分工、各自持續盯著自己負責的部分,減少重複蒐集資訊的浪費。
模型與工具『麻吉訓練』的新趨勢把模型和工具綁在一起協同訓練,反映一個趨勢:AI 廠商愈來愈重視『整套系統搭配起來的體驗』,而不只是單獨把模型做強——這會影響你未來挑選 AI 工具鏈時該注意什麼。

⚙️ 它是怎麼運作的

1
主線代理接下任務你在終端機下達任務,Muse Code 的代理迴圈開始運作;如果用了 /plan 這個內建技能,會先把任務拆解成一份要你核准的計畫,而不是悶著頭亂改。
▼
2
背景子代理分工蒐集與執行常駐的背景子代理接手瑣碎但耗時的部分,自己判斷什麼時候該回報給主線,主線因此不用什麼都自己來,也不會每次都重新蒐集一次資訊。
▼
3
每個動作即時寫進事件日誌不管是呼叫模型、執行指令、你按下同意、或改了哪段程式碼,系統都在動作發生的當下,立刻把它記成一筆事件,附加到本機的事件日誌檔案裡。
▼
4
萬一半路當機或中斷斷電、當機、網路中斷都可能發生在複雜任務跑到一半的時候——這時候對話記憶會消失,但事件日誌已經寫在硬碟上,不會跟著不見。
▼
5
重新啟動,照日誌精確接續下次啟動時,Muse Code 讀取事件日誌,把之前每個動作照順序重播一遍,精確回到當機前那一刻的狀態,接著往下做,而不是要你重新描述一次進度。
▼
6
長任務靠壓縮與目標制約撐下去任務如果拉長到數小時甚至數天,系統會持續用上下文壓縮把舊資訊摘要精簡、用目標制約提醒自己『最終要做到什麼』,避免愈做愈離題。
傳統 AI Agent vs Muse Code 的當機處理方式
情境傳統作法(沒有事件日誌)Muse Code 的作法
當機重開機對話紀錄消失或需要人工重新描述進度,等於砍掉重練讀取本地事件日誌,精確重播到當機前那一步,自動接續
處理多步驟瑣事主線 AI 自己攬下所有雜事,常常重複查同樣的資訊常駐背景子代理專職處理,不必每次重新蒐集資訊
長任務(數小時到數天)越到後面越容易迷失方向、離題靠目標制約與上下文壓縮維持方向,持續推進

🔍 程式碼漫遊（點有 ● 的行看白話講解）

這段程式碼示範最簡化版的『事件日誌』概念:把每個動作變成一筆事件塞進陣列(模擬存進硬碟),當機重開時只要把日誌從頭到尾『重播』一次,就能回到當機前的狀態,不用重新問一次使用者要做什麼。

●const eventLog = [];
💬 一開始日誌是空的陣列,代表這個任務還沒有任何動作被記錄下來(實際上事件日誌會寫在硬碟的檔案裡,這裡用陣列模擬)。
●function logEvent(step) {
💬 定義一個函式:每次代理做完一步,就呼叫它記一筆事件。
● eventLog.push({ n: eventLog.length + 1, step });
💬 把『第幾步』跟『做了什麼』一起塞進日誌,而且是動作發生的當下就寫入,不是事後才補記——這就是當機安全的關鍵。
●}
💬 logEvent 函式定義結束。
●function runSteps(steps) {
💬 定義代理照著步驟清單一步步往下做的邏輯。
● steps.forEach(step => logEvent(step));
💬 每做完一步,就記一筆事件到日誌裡。
●}
💬 runSteps 函式定義結束。
●function resumeAfterCrash(allSteps) {
💬 定義當機重開機後,要怎麼『接續』的邏輯。
● const done = eventLog.map(e => e.step);
💬 先從日誌讀出『已經做完哪些步驟』,而不是憑記憶用猜的。
● const remaining = allSteps.filter(s => !done.includes(s));
💬 用『全部步驟』扣掉『已經做過的』,算出真正還沒做完的部分。
● runSteps(remaining);
💬 只重新執行還沒做完的步驟——這就是『精確重播』省下的時間,已完成的部分不會被重做一遍。
●}
💬 resumeAfterCrash 函式定義結束,也是整個示範的重點所在。

🛠️ 動手做：當機模擬器:比較有沒有事件日誌的差別

  1. 先按「開始執行任務」,觀察左右兩邊代理各自跑步驟,右邊每完成一步都會被寫進最下面的「事件日誌」。
  2. 趁還沒兩邊都跑完的時候,按「模擬當機 💥」,兩邊會同時停下來。
  3. 按「重新啟動 🔄」,觀察差異:左邊(沒有日誌)整個歸零重跑;右邊(有日誌)直接從當機那一步接續。
  4. 多試幾次、在不同進度按當機,體會事件日誌在進度愈多時省下的重工愈多。
👇 下面是活的，直接操作

🧠 工程思維透鏡（資深工程師看到的是什麼）

🔭 為什麼不乾脆每隔幾秒把整個對話存檔就好,一定要用『事件日誌』這種一筆一筆記的方式?
整份存檔(snapshot)代表你必須決定『多久存一次』——存太頻繁會拖慢系統、存太少當機時還是會漏掉一大段。事件日誌反過來:每個動作發生的當下就寫一筆,粒度細到『這一步做了什麼』,所以不管在哪個瞬間當機,遺失的頂多是『正在做』的那一步,而不是一整段時間。代價是日誌會愈長愈大,系統要有辦法有效率地重播、甚至做壓縮清理,這是用『儲存空間與重播成本』換『幾乎零遺失』的設計取捨。
🔭 常駐的背景子代理『一直開著』,不是很浪費運算資源嗎?為什麼不像傳統做法一樣,需要時才叫出一個子代理、做完就關掉?
每次重新叫出一個子代理,它都要重新讀一次程式碼、重新搞懂上下文,這些『暖機』時間在複雜任務裡會不斷重複發生,愈到後面愈拖慢速度。讓子代理常駐不關,是用『持續佔用一些運算資源』去換『不用一直重新蒐集資訊』,對長時間、多步驟的工程任務來說,省下的重工時間通常划算過多花的資源——但如果任務很短很簡單,常駐反而是浪費,這也是為什麼設計上是主線代理搭配背景代理協作,而不是無限開好開滿。
🔭 把模型(Muse Spark 1.2)和工具(Muse Code)綁在一起協同訓練,好處很明顯,但這樣做犧牲了什麼?
協同訓練讓模型特別適應這套工具的操作習慣(像是怎麼呼叫規劃、怎麼壓縮上下文),搭配起來效果最好;但反過來說,這個模型對『這套工具以外的環境』的泛用性可能會打折扣,廠商也等於把自己綁在維護這一套工具鏈上,不能說換就換。這是『垂直整合換取最佳體驗』與『維持通用彈性』之間的取捨——挑選 AI 工具鏈時,也該想清楚自己要的是『某一套搭配到極致』還是『各元件都能自由替換』。
🔭 任務做得愈久,AI 要記的東西愈多,為什麼不乾脆給它更大的記憶(context window),而要多此一舉做『上下文壓縮』?
記憶體(context window)再大也是有上限,而且東西塞得愈多,AI 要在裡面『大海撈針』找出真正有用的資訊也愈慢、愈容易分心離題。上下文壓縮是主動把舊資訊摘要精簡,只留下維持方向所需要的重點,用『可能漏掉一些細節』換『AI 不會被無關資訊拖著跑、能撐更久的任務』——這跟人寫會議記錄只留重點、不逐字謄打是同一個道理。

📝 隨堂考（點選答案，立即回饋）

Q1. Muse Code 用『事件日誌』設計主要是為了解決什麼問題?
✅ 文中提到事件日誌讓 runtime 做到 replay-exact and restart-safe,當機後能精確接續,重點不是程式碼整齊或訓練成本。
Q2. Muse Code 裡的背景子代理和傳統『任務型』子代理最大的差別是什麼?
✅ 材料指出這些背景子代理『remain active throughout each session, rather than being spawned for individual tasks』,重點是常駐、避免重複蒐集資訊。
Q3. 為什麼廠商要把 Muse Spark 1.2 和 Muse Code 兩者『協同訓練』,而不是分開各自訓練?
✅ 文中明白寫出協同訓練是為了『ensure the model exhibits its best performance and coding usability when paired together』。
Q4. 以下哪一個最貼近『上下文壓縮』在長任務裡的功用?
✅ 上下文壓縮是為了讓 AI 在長任務中持續維持方向、不被過多資訊拖垮,而不是壓縮程式碼檔案或翻譯。
Q5. 如果一個 AI coding agent 任務只需要 30 秒就能做完,套用『常駐背景子代理』的設計合理嗎?
✅ 根據 lens 分析,常駐子代理是用資源換『不用重複暖機』,任務短、步驟少時這個交換不划算,重點在任務長短與重工程度的取捨。

🃏 翻牌記憶卡（先想答案，再點開對答）

事件日誌(event log)點我翻面
把每個動作依序一筆一筆記錄下來的檔案,當機後可以照著它精確重播、接續進度,像飛機黑盒子。
常駐子代理(persistent background subagent)點我翻面
整個任務期間都開著、不用每次重新叫出來的輔助 AI,能避免重複蒐集資訊、降低延遲。
replay-exact / restart-safe點我翻面
當機重開後,系統能照日誌重新跑出跟原本一模一樣的結果,而且不怕中斷,這兩個特性合起來讓長任務不怕失敗。
協同訓練(co-training)點我翻面
把模型和使用這個模型的工具綁在一起同步訓練,讓兩者搭配時表現最好,但也犧牲了對其他工具鏈的泛用性。
上下文壓縮(context compaction)點我翻面
任務做久了資訊爆量時,主動把舊資訊摘要精簡,只留關鍵重點,讓 AI 能撐更久、不被無關細節拖走方向。

✅ 離開前自測（全勾＝這課真的學會了）

0%