Day 20｜動手蓋一個最小可行的 Harness

這幾天分享了為什麼需要 Harness Engineering、有哪些元件，以及怎麼判斷算不算Harness。今天是 Part 4 的最後一天，要來分享我自己蓋最小可行 harness 的思路。真的不用一開始就追求完美，先求日常開發有感就好。

我通常會走的起步三步驟

• 第一步：抓一個真的踩過的雷
  我覺得 Harness Engineering 最舒服的起點，從來不是坐在那裡通盤假設「agent 可能會怎麼搞砸」，而是「真的出包了」。根據自己遇到的經驗，把出錯的情境記錄下來，這種真實抓到現場的壞行為，是最值得動手改造環境的契機。

拿 Day 16 的 compare_temperature 來舉例，在實際跑一陣子後，發現模型偶爾會把 temp_a 跟 temp_b 傳反（比如台北塞進 temp_b、東京塞進 temp_a），比出來的結論直接全錯，這就是很好動手解決的問題。

• 第二步：先隨手補一條規則試試水溫

最低成本的做法，就是直接把這個情境補進 prompt 或 system instructions 裡：

## 呼叫 compare_temperature 時
- temp_a 對應「先前查詢的第一個城市」，temp_b 對應「第二個城市」
- 呼叫前務必確認參數順序跟原始問題裡提到的城市順序一致

改個文字檔不到三十秒，而且有時候還能順便防到類似的順序問題。不過大家也知道，這終究是在「拜託」模型自己遵守，沒有硬性約束力。

• 第三步：重複發生的話，就交給程式碼做檢查
  如果發現它還是會出現一樣的錯誤，這時我就會往下一層走，在程式邏輯上設下限制：

def compare_temperature_checked(temp_a, temp_b, city_a_name, city_b_name):
    # 擋掉顯而易見的鬼數據或傳參錯位
    if not (-50 <= temp_a <= 60) or not (-50 <= temp_b <= 60):
        return f"參數異常：temp_a={temp_a}, temp_b={temp_b}，請確認是否傳錯欄位"

    result = "第一個" if temp_a > temp_b else "第二個"
    return f"{result}比較高（{city_a_name if result == '第一個' else city_b_name}）"

這一版能擋掉的是溫度離譜到不合理的情況；如果哪天發現兩個城市的溫度剛好都落在合理範圍、只是順序對調，這種檢查其實還是會放行——真要完全封死「傳反」這個問題，理想做法會是讓函式自己根據城市名稱去查溫度，而不是讓呼叫端手動把數值跟名稱配對好再傳進來，這樣「配對錯誤」這件事從一開始就沒有發生的空間。這算是我自己在補這道牆的過程中，還在持續往下一層調整的地方。但即使只是現在這樣，也已經從原本純粹的「口頭提醒」，跨到了「靠機制防禦」。

真的一點都不用急著一次蓋齊

harness並不是可以一夕之間完成的成果，先上指令檔案，發現指令壓不住、頻繁出包的地方，才補防禦程式碼，一步一步建立起系統的邊界與底線。

先求有一條規則、一兩個常出事的關鍵工具有驗證機制，跑起來順手了再慢慢往上堆疊。跟著真實的痛點滾動式調整，寫起來踏實很多，也最符合 Harness Engineering 的本意。

聊聊 Part 4 的小心得

到這邊 Part 4 告一段落了。

回頭看這 20 天，分享了三種LLM開發策略：

• Prompt Engineering：一次呼叫中，把指令描述的精準
• Context Engineering：一次呼叫中，該端什麼資料給模型看
• Harness Engineering：不指望 agent 這次一定判斷正確，而是在系統邊界上，確保它就算判斷錯了，後果也不會真的發生

如果能把這三塊拼在一起融入開發過程，也能有更多的信心將agent放入生產環境。

明天開始進入 Part 5了，前面分享的都是操控LLM時可以採用的策略。最後一部分會跟大家簡單分享之前開發過的LLM Router核心概念，順便記錄我的vibe coding系統開發過程與遇到的問題，也是本系列的最後章節!