「要不要換成更貴的模型？」
這個問題我問了自己很多次。
MINI 跑了快一年，換過模型、調過 prompt、試過不同的參數組合。最後發現，我一直在問錯問題。
有一篇文章讓我讀完愣了一下。
作者整理了 Agent 工程的底層原理，把決定 AI 系統好不好用的那個「環境」稱為 Harness——驗收基線、執行邊界、反饋信號、回退手段。
然後說了一句讓我在螢幕前點頭點很用力的話：
「更貴的模型帶來的提升，往往沒有想像中大。Harness 的品質，才是真正影響成功率的地方。」
讀到這裡，我突然想到月島廚房每天早上六點的開店前準備。
那段時間，你做的事情跟「做甜點」本身沒什麼直接關係： 擦桌面、確認食材庫存、調好冷藏溫度、把工具排在手邊能拿到的位置。
這些，是廚房的 Harness。
少了這些，就算主廚技術再好，當天的出品也會不穩定——做到一半才發現少材料、溫度沒到就動手、工具找不到。每一個沒布置好的細節，都讓成品品質變成賭注。
AI Agent 的道理是一樣的。
模型是主廚，Harness 是廚房。廚房沒布置好，換再厲害的主廚也沒用。
甚至，厲害的主廚進了混亂的廚房，第一件事是整理環境，而不是開始做甜點。
MINI 現在的架構，說白了就是在幫 Claude 建廚房。
目前大概有七層：
控制流 — Claude Code 本身就是 Agent Loop。每個任務有清楚的進入條件和完成定義。
Harness 文件 — CLAUDE.md 寫清楚行為邊界（哪些事不能做）。rules/ 資料夾是踩坑的累積紀錄，每次出包就 append 一行，不刪除。
延遲加載 — ToolSearch 讓工具 schema 按需求載入，不一次塞滿 context 窗口。上下文管理不是靠更大的窗口，是靠不塞東西進去。
記憶系統 — 四種型態：user（認識這個人）、feedback（如何和他工作）、project（正在做什麼）、reference（去哪裡找資訊）。跨 session 的記憶不靠 AI 自己記，靠結構。
多 Agent 協作 — 根據任務性質派給合適的 subagent，有隔離邊界，幻覺不容易在 agent 之間放大。
背景長任務 — TaskCreate 加上 CronCreate，讓需要時間的事在背後跑，不阻塞主流程。
Prompt Caching — system-reminder 是 cache anchor，五分鐘的 TTL 內重複呼叫不重新計算 token。
說起來，這七層裡有六層跟「選哪個模型」完全沒有關係。
但老實說，還有缺口。
可觀測性——每個決策點發生了什麼、為什麼這樣決策，現在還是靠人工確認，沒有事件流的追蹤。
狀態外化——長任務的進度靠 _HANDOFF/LOG.md 手寫，還沒自動化進去。
這兩件事，那篇文章都有提到，而且說得很清楚為什麼重要。
有缺口，我知道，在補。
寫到這裡，有一個感受想說：
建這套東西的過程，大概有一半時間，我都在寫文件。
不是程式——是文件。寫清楚「這個 AI 不可以做什麼」、「上次出錯是因為什麼」、「這個任務怎麼算完成」。
一開始覺得無聊，都在寫規則，不在做功能。後來才慢慢理解：這些規則就是 Harness，Harness 建好了，後面的事情才能穩定發生。
就像廚房備好料，主廚才能專心做甜點。
FAQ
Harness 是什麼？跟 system prompt 一樣嗎？ 不完全一樣。System prompt 是給模型的指令，Harness 更廣——包括驗收基線（什麼叫做做對？）、執行邊界（哪些事不能做？）、反饋信號（出錯怎麼告訴模型？）、回退手段（出錯之後怎麼辦？）。System prompt 是其中一部分，不是全部。
不懂寫程式也能建這套東西嗎？
老實說，最難的部分不是寫程式，是把你想要 AI 幫你做的事說清楚。CLAUDE.md 本質上是一份文件——寫清楚規則比寫程式容易，但要寫到夠清楚，需要你先很清楚自己想要什麼。這件事比程式難。
要用很貴的模型嗎？ 如果 Harness 做得好，不需要。MINI 的主要工作流用 Sonnet 跑，只有真正需要複雜推理的任務才用 Opus。Harness 建好了，便宜一點的模型也能穩定出活。
從哪裡開始建比較好？
從你最痛的那一層開始。我是從 CLAUDE.md 的邊界規則開始，因為 AI 做了不該做的事，比 AI 做得慢還麻煩。邊界清楚了，其他層慢慢疊上去。不需要一開始就想好七層。