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

AI代理當機不用砍掉重練：拆解Muse Code的事件日誌與常駐子代理設計

取材：Muse Code and Muse Spark 1.2（Hacker News（AI 高人氣））
📍 真實場景
阿凱，一間中小企業的資深後端工程師，公司要他導入AI編碼代理來重構一套跑了八年的訂單系統

他把一個橫跨40幾個檔案的大型重構任務丟給AI代理，想說這次應該能省下不少時間

😖 卡住的地方：代理跑到一半，公司網路忽然斷線、電腦被IT重開機，他登入後發現AI完全忘記剛剛做到哪，只好把需求重講一次，前面20分鐘的功全部白費
💡 這堂課會告訴阿凱，Muse Code怎麼用一本『事件日誌』設計，讓AI代理當機後能精準接續、不必砍掉重練——這套設計思路，他自己以後寫長時間跑的程式也用得上

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

Muse Code是Meta最新推出的一款終端編碼代理(terminal coding agent)一個直接在你電腦的命令列（黑底白字那種視窗）裡工作的AI助手，可以自己讀程式、寫程式、跑測試，不需要你手把手一行一行教它，背後由最新模型Muse Spark 1.2驅動。它鎖定的不是『幫你補完一行程式碼』這種小忙，而是敢接下橫跨整個專案、要規劃、要動手改、還要驗證結果的大型軟體工程任務。

這篇文章最值得工程師學的，是它的『系統設計』而不只是模型多聰明。Muse Code採用『一個主代理＋一群背景子代理(background subagent)整個工作階段都常駐待命的AI助手，不用每次任務都重新自我介紹、重新蒐集資訊，能直接接手做事』的架構：這些子代理不是每次要用才臨時叫出來，而是從session一開始就常駐在線，自己判斷什麼時候該回報進度給主代理，藉此減少重複溝通、加快處理困難的多步驟任務。

更關鍵的是它怎麼『扛得住當機』：每一次模型呼叫、工具執行、人類核准、程式碼編輯，都會被寫進本機一本事件日誌(event log)把每個動作依照時間順序寫進去的流水帳，存在硬碟上，即使程式當機或電腦重開機也不會消失。這本日誌是整個系統唯一可信的紀錄，讓runtime可以做到斷點續跑(replay-exact/restart-safe)當機或中斷之後不用從頭開始，而是根據完整的操作紀錄，精準回到中斷的那一步接著做——就算任務跑到一半斷線，重開之後也能接著做，不會前功盡棄。

🎯 為什麼值得你花時間

當機不再打掉重練對於要跑很久、橫跨很多檔案的大型任務來說，過去只要斷線或當機，前面的進度往往就等於白做。Muse Code靠事件日誌把這個風險降到最低，這對任何需要長時間執行的自動化系統都是值得參考的設計。
常駐子代理省下重複溝通的時間成本傳統『每次呼叫都要重新解釋情境』的AI助手，某種程度上很像每次都找新人幫忙，得重新交接。常駐背景子代理更像『固定班底』，已經知道上下文，可以直接接手，對複雜多步驟任務特別有感。
模型與工具『成套訓練』會是接下來的趨勢Muse Spark 1.2是特地跟Muse Code這套工具搭配訓練的，而不是先訓練好模型再硬套工具。之後挑選AI開發工具時，『模型與介面是不是原廠成套』可能會變成跟『模型能力分數』一樣重要的判斷標準。

⚙️ 它是怎麼運作的

1
主代理接收任務，先用 /plan 訂出計畫使用者丟出任務後，主代理不會馬上動手改程式，而是先透過/plan技能把任務拆解成一份『待核准的計畫』，讓人可以先看過再放行。
▼
2
用 /grill 對計畫做壓力測試計畫訂出來後不是直接執行，而是先用/grill這個技能反覆挑戰、質疑這份計畫，確認它經得起考驗，才不會做到一半才發現方向錯了。
▼
3
指派常駐的背景子代理分頭盯著子任務主代理把子任務交給整個工作階段都常駐在線的背景子代理，它們自己決定何時該回報進度給主代理，減少不必要的來回溝通。
▼
4
每一步操作都寫進事件日誌不管是模型呼叫、工具執行、人類核准，還是程式碼編輯，通通會被寫進本機的一本事件日誌，成為整個系統唯一可信的紀錄。
▼
5
當機後讀日誌，精準接續中斷的那一步因為每一步都有留底，重啟後系統可以照著日誌把之前的操作『重播』一次，精準知道上次做到哪、接下來該做什麼，不用重新解釋需求。
▼
6
用 /goal 持續朝目標推進，搭配脈絡壓縮(context compaction)當AI要記住的資訊太多、快塞不下時，把舊的資訊摘要濃縮，保留重點，騰出空間繼續往前做維持方向整個過程中/goal技能負責盯著『有沒有偏離原本目標』，而Muse Spark 1.2則靠脈絡壓縮技巧，在長任務中持續保留關鍵資訊，不會因為資訊塞爆而迷失方向。
傳統『每次重新呼叫』的AI助手 vs Muse Code的常駐背景子代理設計
比較面向傳統單次呼叫式AI助手Muse Code常駐子代理
當機或中斷後怎麼辦進度多半消失，得重新輸入需求、重新蒐集資訊讀事件日誌，精準接續到中斷的那一步
多步驟任務中的助手角色每次呼叫都要重新自我介紹情境背景子代理全程常駐，直接接手不用重講一次
模型與操作工具的關係模型與工具各自訓練，再湊在一起用模型與工具共同訓練(co-training)把AI模型和操作它的工具綁在一起訓練，讓兩者搭配使用時發揮最好效果，而不是各自訓練好之後才勉強湊在一起，搭配效果最佳化

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

這段程式碼示範Muse Code文章裡講的『事件日誌』設計精神：不是用一個資料庫欄位記錄『目前進度』，而是把每個動作都append（附加）進一份日誌，當機重啟後靠『重新讀一次日誌』來精準知道自己做到哪、接下來該做什麼。

●import json, os
💬 先叫進來兩個Python內建工具：json負責把資料轉成文字存檔，os負責檢查檔案在不在。
●LOG_FILE = 'events.log'
💬 定義事件日誌要存在哪個檔案，這個檔案就是文章講的『single source of truth』。
●def append_event(event):
💬 定義一個函式，專門負責『把一個動作寫進日誌』，對應文章說的每一次模型呼叫、工具執行、核准、編輯都會被append。
● with open(LOG_FILE, 'a', encoding='utf-8') as f:
💬 用『附加(a)』模式打開檔案，舊的紀錄不會被覆蓋掉，新事件永遠加在檔案最後面。
● f.write(json.dumps(event, ensure_ascii=False) + '\n')
💬 把這個事件轉成一行文字寫進檔案，每個事件佔一行，方便之後一行一行讀回來。
●def replay_events():
💬 定義『回放』函式：重啟程式時，靠這個函式把整本日誌讀回來，重建目前進度。
● if not os.path.exists(LOG_FILE):
💬 如果連日誌檔案都不存在，代表這是全新的任務，還沒有任何紀錄。
● return []
💬 沒有日誌就回傳空清單，代表『目前進度是0』。
● with open(LOG_FILE, 'r', encoding='utf-8') as f:
💬 有日誌的話就打開來讀。
● return [json.loads(line) for line in f]
💬 把每一行文字轉回原本的事件資料，重建出一份完整的『做過哪些事』清單。
●def resume_task():
💬 這就是當機重啟後真正會被呼叫的函式，對應文章說的當機後代理可以精準回到中斷的地方。
● events = replay_events()
💬 先把日誌讀回來。
● last_step = events[-1]['step'] if events else 0
💬 看日誌裡最後一筆紀錄是第幾步，如果日誌是空的就代表要從頭開始。
● print('從第 ' + str(last_step) + ' 步接續，不用從頭開始')
💬 印出接續的位置，這就是『精準接續』而不是整個砍掉重練的關鍵所在。
● return last_step
💬 把接續的步數回傳出去，讓主程式知道下一步該做第幾步。

🛠️ 動手做：當機模擬器：讀事件日誌 vs 沒有日誌

  1. 先點幾次「執行下一步」，讓AI代理一步步完成訂單系統重構任務的5個步驟
  2. 任務做到一半時，點下「模擬當機」，看看記憶體內的進度發生什麼事
  3. 點「重新啟動（讀事件日誌接續）」，看AI代理怎麼從日誌接回中斷的地方，不用重做前面的步驟
  4. 重新整理頁面回到初始狀態，再走一次流程，這次改點「重新啟動（假設沒有日誌，從頭來）」，比較兩種情境的差別
  5. 留意事件日誌面板（黑底綠字）裡的紀錄，那就是文章講的『single source of truth』
👇 下面是活的，直接操作

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

🔭 為什麼要犧牲『簡單』，特地維護一份事件日誌，而不是單純用資料庫存目前狀態就好？
只存『目前狀態』的資料庫，一旦在寫入的瞬間當機，資料可能寫到一半就損毀，而且你只看得到結果、看不到『怎麼走到這一步』的過程，除錯時完全沒有線索。事件日誌是append-only（只增不改）的設計，代價是多花儲存空間、多一層複雜度，換來的是可回溯、可除錯、可斷點續跑的韌性——這是資深工程師在設計長時間執行的系統時常見的取捨，跟資料庫界『event sourcing』的思路一致。
🔭 常駐背景子代理雖然省去重複溝通，但要付出什麼代價？
常駐代表即使暫時沒事做，也要一直佔用運算資源、維持上下文，這是『用資源換時間』的取捨。任務越長、越複雜，常駐子代理越划算；但如果是一次性的簡單小任務，常駐的開銷可能完全划不來，這也是為什麼Muse Code把它設計成『整個session常駐』而不是『整個系統永遠常駐』。
🔭 把模型和工具『共同訓練』是不是把自己綁死在單一生態系？
共同訓練能讓模型與工具搭配的效果最佳化，像是量身訂做的西裝，但也代表如果之後想換別家AI模型來搭配Muse Code的工具，效果可能打折扣。這是『最佳化單一組合的效能』跟『維持開放、可替換性』之間的取捨，跟很多雲端服務用自家生態系鎖定客戶的商業考量邏輯很像。
🔭 /plan → /grill → /goal 這種『先計畫、先找碴、再執行』的流程，對工程師的意義是什麼？
這其實是把『謹慎的資深工程師會做的事』——先想清楚、找人幫忙抓漏洞、動手時目標明確不偏題——直接寫進工具的系統設計裡，而不是寄望每個使用者自己記得要謹慎。這是『把好習慣變成系統流程』而非『依賴人的自律』的思路，值得工程師在設計自己團隊的開發流程或工具時借鏡。

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

Q1. Muse Code的『背景子代理』和一般每次都要重新呼叫、重新解釋情境的AI助手，最大差別是什麼？
✅ 文中提到這些背景子代理『remain active throughout each session, rather than being spawned for individual tasks』，常駐才能避免重複蒐集資訊、降低延遲，並減少對主代理的『steering』需求。
Q2. Muse Code當機後能『精準接續』而不是從頭重來，關鍵設計是什麼？
✅ 文中明確說明：每一次模型呼叫、工具執行、核准、編輯，都會被寫進一本本地事件日誌，讓runtime『replay-exact and restart-safe』，當機後能精準回到中斷處。
Q3. 文中提到Muse Spark 1.2與Muse Code『共同訓練（co-training）』，這句話的意思最接近下列哪一項？
✅ 文中說明co-training包含把Muse Code的工具集整合進訓練過程，是為了讓兩者搭配時有最好的表現與相容性，不是各自獨立訓練後硬湊在一起。
Q4. /grill這個Muse Code內建技能的作用是？
✅ 文中寫道：『/grill stress-tests that plan until it holds up』，就是在計畫定案前先找漏洞、反覆挑戰，確保方向正確。
Q5. 下列哪一項『不是』append-only事件日誌設計的主要目的？
✅ 文中完全沒有提到日誌具有加密功能，它的重點在於當作single source of truth，支援replay-exact與restart-safe，而不是資料安全防護。

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

事件日誌（event log）點我翻面
把每個模型呼叫、工具執行、核准、編輯依序寫進一本流水帳，寫在硬碟上，當機也不會消失，可以照著回放
背景子代理（background subagent）點我翻面
整個工作階段（session）都常駐待命的助手，不用每次任務重新蒐集資訊，能自己決定何時回報主代理
/plan、/grill、/goal點我翻面
Muse Code內建三個技能：/plan把任務變成待核准的計畫、/grill對計畫做壓力測試、/goal持續朝目標推進
共同訓練（co-training）點我翻面
把AI模型和操作它的工具綁在一起訓練，讓兩者搭配使用時發揮最好效果，但也可能較難跟其他工具混搭
replay-exact / restart-safe點我翻面
系統可以精準重放過去的每一步，並在當機重啟後安全地從中斷點接續，不會做錯或漏做

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

0%