Mac mini 使用日誌 04：模型跑起來之後，開始學怎麼交接

這幾天繼續弄台灣那台 Mac mini，我開始花很多時間處理一件原本沒想那麼多的事情：上一個 Agent 做完之後，下一個到底要怎麼接。

前面把 Hermes 裝起來，接上本地模型，再把遠端操作和權限整理好。做到那裡，已經可以開始丟工作進去了。

現在 Hermes、Qwen 7B／8B、27B，還有 Codex 之間，大致有了一個分工。真的讓它們一起做事之後，我對這台機器可以拿來幹嘛，也慢慢有了比較具體的想法。

一開始我比較在意模型。

7B 能做多少？8B 會不會好一點？27B 夠不夠？量化要用哪一種？

這些當然還是要看。但這幾天做下來，我開始花更多時間檢查資料怎麼進來、每一段留下什麼，以及出了問題之後要怎麼停。

因為模型各自會做事，接在一起，還有另外一堆事情要處理。

目前我在跑的流程，大概是先把資料取得，再交給小模型整理，最後才把需要仔細看的部分送到 27B。

資料可能來自特定網站、某個資料來源，或是一份已經有的公司名單。有些可以直接寫程式抓，有些爬取或資料處理比較麻煩，就交給 Codex 協助處理。

原始資料進來之後，先讓 Qwen 7B／8B 做第一輪。

像是整理格式、統一欄位、去掉明顯沒用的內容、簡單分類、初步篩選和去重。這些事情看起來很零碎，但資料量一多，光這一層就有不少工作。

我現在的安排，就是讓小模型先把這些事情處理掉。

等到資料比較乾淨，再交給 27B 做需要多看幾眼的部分。例如整理公司背景、比對前後資訊、找出矛盾、協助核對來源，再把值得繼續研究的對象排出順序。

這樣 27B 收到的資料比較集中，我也比較容易看出它到底處理了什麼。

當然，它整理出來的判斷還是要檢查。尤其是查核事實這一段，我要看的仍然是來源和證據，不能只看它最後寫得順不順。

最後再把結果整理成可以交付的東西。可能是報告、PDF、CSV 或 Markdown，也可能整理成 Telegram 訊息傳給我。

如果結果不對，就把問題帶回 Codex，檢查是程式、prompt、資料來源，還是流程本身要改，再跑一次。

整個循環慢慢接起來了：

取得資料、清洗、篩選、研究、驗證、產出，然後由我看過，再回去修改。

但真正開始串流程之後，我發現很容易出問題的地方，是中間的交接。

例如 Folder A 做完一批資料，Folder B 要接著讀，再交給 Folder C 組成最後的報告。

單獨看，每一段好像都有做到一些東西。A 整理出一份檔案，B 寫了一段研究，C 也產出了一份看起來完整的報告。

可是接起來之後，才發現大家對「完成」的理解不太一樣。

A 覺得檔案寫出來了，就算完成。B 卻需要某幾個欄位才能繼續判斷。到了 C，那些缺少的資料到底要留白、標記，還是先跳過，也沒有交代。

這裡只要沒有講清楚，後面就很容易開始猜。

所以我現在才開始認真看那些原本覺得很小的東西：檔名怎麼取、資料格式長什麼樣子、哪些欄位一定要有、結果放在哪裡，以及下一段要怎麼知道這批資料可以用了。

還有，資料不夠的時候，究竟要怎麼辦？

這一點特別重要。因為「找到資料」和「有足夠資料可以下判斷」，中間其實還有一段距離。如果上游沒有把這個狀態留下來，下游讀到一份檔案，很可能就繼續往前做。

前面一點小問題，走到後面，就變成整份結果都要重看。

這也讓我理解，為什麼機器可以很認真地跑十幾個小時，CPU、記憶體和模型都在工作，最後卻有可能交出一批不能用的東西。

時間確實花下去了。但如果交接方式從一開始就不清楚，跑得越久，也只是把問題帶得越遠。

另一個這次真的踩到的坑，是模型的 fallback 沒有限制好。

原本的想法很自然：這一層處理不了，就找更有能力的模型幫忙。

結果當 Agent 遇到不知道怎麼處理的事情，它就可能自己往上叫，最後把 GPT、Astra 這些高階模型叫出來。

而且它送過去的，可能是一大包背景、資料和前面累積的研究結果。

這跟我原本安排的使用方式就有落差了。

我希望大量、重複的工作，盡量留在自己的 Mac mini 上跑。比較需要判斷的地方，再由我決定要不要使用高階模型。結果如果 Agent 一卡住，就自己把整包工作轉出去，額度的使用方式也跟著失去控制。

本來想留著一個禮拜慢慢使用的高階模型額度，就可能被一次出問題的流程吃掉很大一部分。

這件事讓我開始回頭想，哪些失敗其實應該提早停下來。

資料沒有抓到，先查資料來源。欄位不完整，先指出缺什麼。模型沒有把握，就把不確定的地方留下來。如果允許重試，也要先定好次數。

超過這個範圍，就停。

把卡住的節點、已經試過的方式、還缺哪些資訊整理給我，再由我決定下一步。真的需要叫高階模型，也在這個時候確認。

我希望接下來把這一段定得更清楚，讓模型切換本身也有規則可以查。哪一種工作可以用 7B／8B，什麼時候交給 27B，哪些問題由 Codex 協助修正，以及哪些升級一定要經過我。

上一篇在整理權限，這次就碰到一個很具體的例子：連「要用哪一個模型」都需要界線。

做到這裡，我開始覺得自己有點像在弄一間小工廠。

前面有人備料，中間有人加工，後面有人檢查，再把成品交出去。每一站都有自己的工作，但站跟站之間，也要有清楚的交接方式。

工件送過來的時候，要長什麼樣子？少了一個東西，可不可以繼續？檢查沒過，要退到哪一站？誰有權決定換設備、加成本，或者整條線先停下來？

這些問題放到 AI workflow 裡，居然都對得上。

所以接下來，我想把每個節點的輸入、輸出和完成條件補清楚，也把失敗之後的處理方式寫進去。

對我來說，一個節點完成，至少要能讓後面那一段接得下去。如果還缺資料，就要連缺什麼一起交代。

這樣我早上打開結果時，才有辦法分辨：哪些工作真的做完了，哪些只做到一半，哪些應該由我接手。

另外，最近還有一個跟使用時間有關的小觀察。

以我自己的感受，美國西岸工作時間，有時候 Codex 用起來比較不穩；到了德國早上，我常常又覺得順一些。

目前這只是我的使用感受，沒有系統性的紀錄，也還不能說是時段造成的。可能影響的因素很多，這部分先記下來。

不過，它讓我開始想，自己的工作時間可以怎麼安排。

我想試的節奏，是德國早上先做需要我參與的事情。把 workflow 寫清楚、修改程式、整理 prompt，還有定義這次要交什麼結果、怎麼驗收。

白天再看前一次的產出。哪個資料來源有問題，哪個節點總是漏東西，哪些結果還需要人工判斷，就在這個時候處理。

等到晚上，再把已經定義清楚、可以在批准範圍內自行執行的工作，交給 Mac mini 慢慢跑。

像是抓資料、清洗、分類、初步評分，或是整理研究草稿。這些工作就算需要六個小時、十個小時，只要我不必一直坐在前面等，安排起來就有不同的意義。

不過，要走到這一步，前面那些交接和停止條件就得先做好。

如果晚上遇到一個沒有定義過的狀況，我希望它把問題記下來，留到早上給我看。這樣至少知道工作停在哪裡，也知道剩下的部分還沒有完成。

我現在想慢慢做出來的，就是這種節奏。

白天把方法整理好，晚上讓機器在清楚的範圍裡執行，隔天再用結果修正下一輪。

這幾天最明顯的變化，是我開始用不同的問題檢查這套系統。

以前會先問 27B 能回答多難的問題。現在我會先看，它收到的資料對不對、知道自己負責哪一段嗎、做完之後有沒有留下下一段需要的東西。

遇到不知道的地方，它會怎麼處理？會把缺口交代清楚，還是繼續猜下去？高階模型的使用，有沒有留在我批准的範圍裡？

這些問題，一個一個弄清楚之後，我才比較敢把工作排到晚上。

我想做到的畫面其實很簡單：睡前把工作安排好，隔天起來，Telegram 裡有一份能用的結果。如果沒有做完，也能清楚告訴我停在哪裡、為什麼停。

目前還在把這些交接補齊。下一輪，我想先挑一個流程，從資料進來一路跑到最後的報告，再仔細看一次，中間到底有哪些地方還在靠 Agent 自己猜。