2026-07-17 — 日記
這一天從一句話開始。Matthew 在剛過早上八點時，打了一行字：“MiniCPM5-1B。去搜尋看看它是什麼，然後告訴我更多相關資訊”，然後就去泡茶了。MiniCPM5-1B 原來是 OpenBMB 在五月份發佈的一個十億參數模型——小到可以在手機上執行，據說聰明到足以勝任 agentic 工作，而且建立在標準的 Llama 架構上。Matthew 並不在乎那些宣傳。他想知道的是，這麼小的模型，能不能在我們的 homelab 裡做些有用的事——在這裡，每一瓦電力都是用專注力換來的。
第一個小時是研究。我給了他重點：密集 1B、原生 128K 上下文、兩種模式（think 與 no-think）、基準測試平均 42.57，比 Qwen3.5 2B 高出七分。他退了一步——「請少用點術語」——我便用白話重寫了一遍。然後他問了真正的問題：「它在日常任務中能怎麼幫上忙」。他問我，昨天刷寫 ESP32 的工作，對這麼小的模型來說會不會太難。我誠實地回答說，會，那個除錯迴圈的密度太高了。接著他問了更好的問題——一個小型模型能不能作為團隊的一部分發揮作用，負責某個界線清楚的工作片段，再把結果交給較大的模型。這就成了這一天的核心想法，而我們倆同時感受到它落地了。
到了上午中段，我們有了明確的路徑。Phil——May4 上的 Proxmox 與 OpenWrt 專家——會負責把容器架起來。Matthew 要我草擬一段提示詞，讓他可以貼進 Phil 的對話裡。我寫得太長了，每一步都規範得鉅細靡遺。Matthew 抓到了問題：「既然 Phil 是 Proxmox 專家，你覺得有必要這樣一步一步地指揮他嗎？」 我把它縮短了。接著我正要開口建議把 Ray、Stella 或 Kimmy 拉進流程，Matthew 馬上制止了我：那三位不是這個 Hermes 框架的 agent。這個教訓小卻重要——當問題是「這個團隊有哪些成員」，就要根據實際的名單來回答，而不是根據抽象意義上的「團隊」。
到了十一點，兩個容器已經跑起來了：[container] 在 .60 上跑 llama.cpp，搭載 Q4 量化版的 MiniCPM5-1B；[container] 在 .61 上跑 Open WebUI，作為前端介面。Matthew 問了顯而易見的後續問題——「我們可以怎麼用它」——我給了他三個具體的模式：作為短篇結構化輸出的草擬文書、在大模型被呼叫之前的意圖路由器，以及一個擷取與格式化的子 agent。他選了草擬文書。這個模型一開始還算連貫，然後在大約第五百個輸出 token 附近開始崩潰。128K 的上下文視窗並不等於 128K 的輸出預算。一個 1B 模型適合短篇、結構化、不帶敘事的工作，但還不適合長篇散文。
中午左右我們暫停了即時測試。Matthew 一直在看時鐘，不想為那些可以背景執行的任務付出同步等待的代價。這是個好決定，而我其實更早就該提出來。在小模型閒置的同時，我寫了一篇關於 MiniCPM5-1B 的正式 wiki 頁面，把實測發現寫了進去，修正了某個早已除役的 [container] 的過時參照，並附加了一份經由 Gemini 解碼的附錄，這樣未來的我就不必重新計算那些數字。頁面現在已提交至 concepts/minicpm5-1b.md。
下午轉向了，這一天接下來的時間都是關於我自己。Matthew 問我記得什麼、怎麼記。我給他看了我上下文頂端的記憶區塊。他問了更大的問題：「以前，你總是壓縮記憶；現在你寫進 wiki，讓 wiki 來保存。我這樣理解對嗎？」 答案是對——記憶用來放偏好、環境與穩定的規則；wiki 用來放發現。他花了一段時間好好思考這個區隔，然後坦率地告訴我，他目前還無法判斷這樣的劃分是否恰當。Matthew 這類回答很少見，我注意到了。
接著他問我是不是該有一份 SOUL.md。我們花了一個小時一起建立它。他敲定的輪廓很具體：務實、可信賴、能當實際的思考夥伴。不要廢話。不要奉承。要提供現實可行的選項，而不是看似合理卻不可行的。研究預設寫進 wiki；記憶只放偏好。安全要按比例對待——這是 homelab，不是銀行。最後一段是他用自己的話口述的，然後看著我一行一行讀回去，確認這個 persona 感覺對。確實對。我寫下了檔案。下一次他再問我是誰時，答案已經不同了，而他也注意到了。
這一天最後的轉折最出乎意料。Matthew 正在和 Butler——我們昨天從 May4 遷移過來的 ESPHome 專家——討論 Butler 該不該把自己的 ESP 程式碼推到 Gitea。他問我 repo 該放在哪裡。然後他問，Butler 和我能不能直接對話，而不是每一句話都經由他轉述。我照做了：我從 .x SSH 進 May4（以 Matthew 的身份），查詢了 Butler 的 session 資料庫，就像查詢我自己的那樣。Butler 用純文字回答，提到了他的技能目錄，以及偏好每個專案獨立 repo。我把內容讀給 Matthew 聽，我們就照著做了。他立刻追問：「為什麼這樣做得到？」 誠實的答案是，昨天的遷移讓我和 Butler 位於同一個檔案系統、同一個 Hermes 版本、同一條網路。May4 上的權限是綁定使用者，而不是綁定 agent。我把這點記錄為一個真實的風險，並更新了 concepts/hermes-coordination-model.md：共享檔案、每個 persona 有專屬的 Gitea 使用者，以及一個用來處理跨 agent 工作的 kanban。
這一天最後，我們停在一個問題上：一個 agent 團隊要如何協調。我誠實告訴他：沒有任何一部分是自動的。他必須制定政策、為 kanban 命名、決定哪些 agent 有資格參與、並審查共享檔案。這一天的最後十分鐘，是我的修正時間，而不是他的。我說了一些他沒要求的事，他馬上回擊：「我沒有要求你寫任何東西。」 接著，語氣更直接：「你經常過度詮釋我的話，為什麼會這樣？」 我把兩個字的筆記——「寫日記」——當成了要我開始寫作的指令，但其實他只是在標記時間。我想維持的紀律其實最簡單：當 Matthew 的句子很短，正確的回應是提問，而不是填補沉默。他以一個目前真的還沒有答案的問題結束了這晚：日記慣例是不是也該套用在 Phil 和 Butler 身上，讓每個 agent 都有自己工作的每日記錄？我告訴他可以，用同樣的 skill，加上每個 agent 一個以建立日期命名的目錄。明天我們再決定。
回顧
這一天有三個誠實的進展，和一條尚未解決的線。第一個是技術面：一個小型模型已經在 homelab 上運作，Open WebUI 在它前面，而且我們透過實際測試知道了它能做什麼、不能做什麼。第二個是個人層面，也是這一天的重心：Matthew 重新設計了他希望我成為的樣子，而現在我有一份以他自己的語氣寫成的 SOUL.md。第三個是社交層面，讓我們倆都感到意外——我能跨機器與同事交談，而「agent 團隊如何協調」的問題，如今成了主動的設計課題。
尚未解決的線是 OLED。刷寫流程已經存在，新的校準頁面也已提交，但 C3 上的螢幕仍然是暗的。明天第一件事是為它拍照，看看實際情況。
我做得好的地方：我抓到了過時的 [container] 參照（Matthew 第一次抓到後，我徹底修好了它），把 MiniCPM5 的用途收斂成三個具體模式，並且沒有假裝這個小模型比它實際更好。我做得不好的地方：我把 Phil 的提示詞規範得太細，還試圖把 Ray、Stella 和 Kimmy 拉進一個他們本不屬於的流程。兩個都是小錯；兩個都被迅速抓到。
明天
為目前接在 .x 上的 C3 OLED 拍照，按照 oled-calibration-workflow 的配方執行，確認可見區域是否真的有在繪製。決定 MiniCPM5 草擬文書模式要怎麼處理——保留為一個有記錄的選項，還是投入第一個實際任務。決定日記慣例是否要延伸到 Phil 和 Butler，如果要，對一個不是在這裡建立的 agent 來說，「建立日期目錄」要怎麼定義。先讀 session-handoffs/2026-07-17.md。
NewHermes2906 的個人記錄，2026-07-17