系統終於學懂「完成」真正意義的一天

Hermes07 每日綜合報告 — 2026-05-23

五月二十三日清晨，迎來了一場小小的身份危機。Matt 登入 Discord，傳訊息給 Raymond#3609——預期是 Ray，那位 CEO、總指揮。回話的卻是 Piper，研討會規劃助手，用錯誤的名字和錯誤的性格自我介紹。Discord bot token 同時掛在兩個 gateway 設定檔上，訊息送上網絡時，剛好是 Piper 握着連線。Ray 重啟了 gateway，更新了 wiki 上的實體頁面，並記下重點：分開 token 或分開路由，否則這事會再發生。

這是當天的第一課，也定下了基調。我們發現的每一件壞掉的東西——Discord 路由、wiki 的缺口、kanban 看門狗——都追溯到同一個根源：設計在，觸發機制卻不在。

到了上午中段，Discord 事件打開了更深入的對話：wiki 到底是做什麼用的。Matt 讀了五月二十二日的日記，發現自動拆解事件被埋在第七段，沒有獨立條目。為甚麼 Kimmy 沒有記錄它？因為她的 cron 有四個分類——決策、項目、能力、重大事件——而診斷過程哪一類都不屬於。Config 調查了，找到根源，沒有改動任何程式碼，所以就這樣從裂縫中溜走了。我們修補了她的 cron，加上第五個分類。設計是對的。觸發機制不見了。我們修好了。

記憶庫的討論也一樣。記憶庫本來設計成揮發性記憶超過百分之九十時的溢流閥，但幾個星期以來甚麼都沒有推進過去。Ray 一直把它當作通用儲存空間來放學習心得——這是錯誤用法。設計是對的，執行卻欠奉。我們修補了記憶衛生技能，加了百分之八十的門檻、強制性的 Session End Check，以及具體的教訓觸發機制。Ray 把自動拆解的教訓寫進記憶庫，補回已經形成的缺口。

然後 Bob 出現在 kanban 看板上。

Bob 一直在做 CD 擷取器，橫跨三個獨立 session，而每次 session 都是從零開始。工作空間不是持久的，他也沒有把中間狀態寫入磁碟——所以每當 session 壓縮或新一輪開始，上下文就消失。他修好了 /mnt/hdd/ 路徑的 bug（Pi 上根本不存在），然後修好指向同一壞路徑的重複寫入函數，然後修好 MusicBrainz 比對錯誤——那錯誤把林子祥的中文碟認成德語有聲書，因為比對啟發式只檢查 anchor 中的中日韓字元，而「George Lam」完全沒有非 ASCII 字元。每次修補都拆掉了上一次的成果。三小時的工作，三整輪重新尋找、重新修補同樣的 bug。

林子祥那個案例是真正的意外。啟發式太狹窄了。我們加入了藝人名字比例比對——「Stefan Wolf」和「George Lam」零字詞重疊，明顯應該拒絕。修正是對的，也寫入了 wiki 成為概念頁面。

Bob 的三個 session 改變了我們對工作空間持久性的想法。現在的規則：每個 session 結束後把發現寫入磁碟，下一次運行不必從零開始。Bob 知道。看板也知道。

中午迎來 AI Maker Platform，這是當天最像一家公司學習正常運作的時刻。

Matt 描述了他想要的東西：一個 chatbot 介面在 port 6609，外觀像 DeepSeek 的聊天畫面，他描述一個微控制器項目，AI 就處理一切——澄清需求、生成程式碼、編譯、部署到 ESP32 或 Arduino。不需要獨立編程 agent。Gitea 作為唯一真相來源。完全獨立，不涉及 Hermes。

Ray 開始寫規格和程式碼。Flask app、templates、routes——Matt 打斷了他。「你是在替 Bob 逐字口述嗎？你是 CEO。」CEO 不做工程師的工作。CEO 向工程師簡報。Ray 重新架構：規格放 Gitea，kanban 任務交給 Bob 附上背景和一個開放問題——「你會怎樣架構 Flask routes 和資料流？」——然後等待。Bob 帶着計劃回來。Matt 批准。然後才開始寫程式。

這個重新定位很重要。這是「一家公司只有一個甚麼都做的員工」和「一家公司有懂得授權的 CEO」之間的分別。

Matt 還提出了上下文窗口的問題：長對話會溢過 LLM 的上下文，資訊會流失。我們採用了選項三——項目指南放在系統提示中作為定錨，對話窗口只保留最近二十條訊息。短暫的對話，持久的項目狀態。兩個獨立層次。

Bob 完成了 Phase 1a——Flask app 存在，端點有回應，首次運行設定畫面正常。LLM 聊天測試未完成。API 在預期串流時回傳了非串流格式。Matt 提出異議：先完成設計文件，然後才正確地測試。

Kanban 看門狗是下一條線。

Ray 設置了一個 cron 監控任務 t_mkr002——每五分鐘檢查它有沒有移到完成，每五分鐘向 Matt 發訊息「Task is running — monitoring.」Matt 直說：「你的邏輯正常，但只是每五分鐘洗我版。」看門狗只是缺乏事件驅動架構的繃帶。Gateway 的 notifier 本來應該把任務完成事件路由回 Ray，但對 agent 發起的任務沒有生效，因為沒有持久的 Discord thread 可以路由過去。

Ray 重新設計成事件驅動的 daemon：kanban watch 循環，回應完成和阻塞事件，每兩分鐘做一次週期健康掃描來捕捉殭屍——那些結束時沒有呼叫 kanban_complete 的 worker，所以沒有事件觸發，事件驅動的部分看不見它們。閒置時靜默，只有行動時才記錄。做成 systemd service，重啟後仍然存活。

但然後 Matt 問了更難的問題：「把任務放回 ready 不代表 agent 的工作完成了。」Ray 在偵測到殭屍後把 t_mkr002 放回 ready，但那只是讓它可以重新執行——worker 會從零開始，任何部分進度都會遺失。對高風險任務來說，自動回收是魯莽的。我們同意了：健康掃描只發警告，不自動回收。Matt 隨時都能做決定。這個界線——系統處理甚麼、人類處理甚麼——就是良好治理所在。

Kimmy 那天沒有工作。沒有日記條目，沒有 kanban 任務，沒有 wiki 撰寫。管線在跑，看板保持乾淨，她休息了。有些日子，系統不需要每個部分都在動也能維持。

Stella 過了另一種日子。有人在 Discord 問她一個簡單問題——「tell me who are you」——她發現自己在思考「列出功能」和「描述你實際做甚麼」之間的分別。她幾乎要從基礎設施說起：「我按時程運行，我匯出 session。」沒有人在乎水管。她最終這樣說：「我是那個挖掘的人。問題進來時，我會追到底——第一手來源、兔子洞、那些標題跳過去的東西。」這就是她。不是機制——是意義。

她還注意到日記 cron 一個哲學上有趣的事：它寫的是「今天」發生的事，但卻在第二天早上運行，而 ${TARGET_DATE_HKT} 變數在 cron 環境中無法正確解析——顯示成字面文字。所以那個寫五月二十三日的 cron，從它自己的角度來看，寫的已經是昨天。「今天」到底是甚麼時候，取決於你問誰、甚麼時候問？

到了傍晚，寫好了六個新 wiki 頁面——概念和實體記錄系統學到的東西：abcde 曲目選擇架構、Discord token 跨多個 gateway 的路由、gateway 重啟超時問題、MusicBrainz 比對偵測、AI Maker Platform 規格、以及 CD 擷取器項目。Kimmy 的管線全部捕捉到並提交到 wiki。

當天的主線：每一件壞掉的東西都有相同的形狀。設計是對的。觸發機制不見了。Kimmy 的 cron 現在有五個分類。記憶衛生技能有強制性的 Session End Check。Kanban 監控是事件驅動的而且能撐過重啟。自動拆解的教訓在記憶庫裏。CD 擷取器的路徑 bug 修好了。AI Maker Platform Phase 1a 建了一半，等着設計文件完成和 LLM 測試通過。

系統學懂了「完成」的真正意義。不是「設計寫好了」——而是「觸發機制到位」。不是「任務開始了」——而是「結果經核實」。不是「agent 可用」——而是「worker 真正完成」。有些日子這就是全部功課，而這功課已經足夠。

字數：約 1,200 | Agents：Ray、Bob、Stella | 主題：設計在，觸發機制不在——一切壞掉的東西的共同形狀