比提示詞更重要的事：為什麼 AI 需要一套「安全帶」？

導讀
當 AI 只要回一句話，提示詞常常夠用。但只要它開始讀檔、改稿、跑流程，你真正需要的就不是一句 prompt，而是一套能踩煞車、留紀錄、會驗證的外部系統。那套系統，就是 Harness Engineering。

你知道嗎？同一個 AI，前 10 步像神隊友，到第 50 步卻開始忘東忘西，這種崩法很常不是模型突然變笨。它就像被你推進戰情室的聰明實習生：腦袋很好，反應很快，卻沒有白板、沒有檔案櫃、也沒有值班表。

於是前半段很亮眼。後半段開始打瞌睡。
你看到的是模型失控。真正缺的，常常是工作現場。

Harness Engineering 到底在補什麼？

Harness Engineering 補的不是模型智商，而是讓長任務能穩定落地的外部制度。

Prompt Engineering 在管你怎麼問。Context Engineering 在管你餵什麼資料。Harness Engineering 再往前一步，開始管整個任務現場：規則怎麼寫、工具怎麼排、風險怎麼擋、錯了怎麼回頭查。

所以它比較像作業系統，也像總機。模型負責想下一步；harness 負責決定這一步能不能做、做完要不要驗、出了事怎麼停。沒有這一層，Agent 就像只有大腦、沒有神經和煞車的車，前面衝得很快，後面卻很難穩。

圖說：把硬體、LLM API、Agent Harness 與應用層分開看，就更容易理解：harness 是模型外、卻管整體穩定度的那一層。

一套像樣的 harness，至少會管 6 件事

一套像樣的 harness，會把規則、記憶、工具、安全與監控拆開來管。

最常見的六個元件，大概是這些：

1. 規則管理：先把角色、禁區、輸出格式寫清楚。沒有這一層，模型很快就會變懶，看到新情境就自己改口。
2. 外部記憶：把提綱、決策理由、待辦與中間產物寫到檔案。否則它像口袋破洞一樣，邊走邊掉東西。
3. 工具調度：不是把所有工具都丟進去就好，而是規定先後順序與失敗回退。工具一多，它就像站在雜物間裡發號施令的領班一樣，卻摸不到正確扳手。
4. 生命週期控制：限制步數、時間與 no-progress。這就是避免原地打轉的煞車踏板。
5. 安全護欄：刪除、覆蓋、對外送出這類高風險操作，要先停一下。慢這一下，通常比事後補漆便宜。
6. 可觀測性：不只記錄結果，也記錄它為什麼這樣做。出了錯，你才追得到第一個歪掉的節點。

圖說：Prompt、記憶、工具、安全、生命週期與可觀測性，像六個器官一起撐住 Agent 的工作現場。

長任務為什麼特別容易出事？

長任務會走鐘，通常不是因為模型突然變笨，而是管理成本一路堆積。

最常見的坑有四個。

第一個是上下文疲乏。前面講過的限制、命名規則與中間決策，會被後面大量新資訊一路往後擠。某些多 Agent 軌跡分析甚至把失敗率拉到 41%–87%，問題常常不是不會做，而是忘了前面說過什麼。

第二個是失控迴圈。沒有停止條件時，Agent 會在相似方法裡一直重試，看起來很忙，實際上只是堆積更多錯誤。這就像車輪陷進泥巴一樣，油門越大，坑只會越深。

第三個是複合幻覺。第一步編錯一個函式名，後面每一步都往那個假前提上加料，最後整條流程一起歪掉。

第四個是誤動作。你本來要它查資料，它卻碰了不該碰的檔案；你要它整理草稿，它卻順手改掉正式版本。這類事故不是玄學，就是安全邊界沒有被明確管著。

同一個模型，換一套 harness 為什麼差這麼多？

很多 Agent 問題屬於系統工程，所以同腦不同環境，結果真的會差很多。

你真的只要換更強模型就好了嗎？很多時候不是。最直觀的例子，就是同一個模型只換外圍制度，某些 benchmark 的表現就能從 52.8% 拉到 66.5%。差的不是腦容量，而是流程有沒有被整理好。

另一個常被拿來談的案例，是大型團隊用 AI 產生 pull request。像 Stripe 這類工程案例，一週可以處理 1300 個 AI PR；真正讓流程撐住的，不是模型爆衝，而是測試、style check、安全掃描與人工審批點一起上。

還有一個很反直覺的發現：工具不是越多越好。有些團隊把可用工具縮到 15-20 個，反而比一次放上百個工具更穩。因為選項一多，岔路就變多，錯誤也會一路堆積。

不過，這些數字多半來自工程 benchmark、內部報告與團隊案例，尚未被大規模驗證；不同公司、不同模型、不同工具鍊之間，效果差很大。另一方面，它們已經很夠用來提醒你：如果總把問題都怪在模型太笨，通常會錯過真正能改善穩定度的槓桿。

你現在就能先加的 4 條安全帶

你不用先蓋完整平台，先補四條安全帶，穩定度通常就會明顯改善。

第一，先把固定規則寫成一頁。角色、禁忌、輸出格式、優先順序，都不要靠口頭補充。

第二，讓任務有外部記錄。提綱、待辦、修改理由、查證結果，全部留在檔案，不要全塞進聊天視窗。

第三，高風險操作前加停損點。覆蓋原文、大量刪改、對外送出，這些地方先確認一次。

第四，讓生成與審查分開。不要讓同一個流程又寫又判，至少留一個獨立 reviewer，哪怕是同模型換角色，也比完全自評穩。

不是所有任務都值得上全套 harness

不是每個任務都要重裝甲；短任務與低風險工作，太厚的 harness 反而拖慢速度。

如果你只是要它改一句標題、整理一段摘要，過多的規則、審批點與記錄機制，可能像穿著雨衣洗手一樣，麻煩多過收益。然而，一旦流程碰到外部工具、多人協作或不可逆動作，安全邊界就不能省。

所以真正的重點不是「有沒有 harness」，而是「厚度對不對」。輕任務用輕制度，重任務上重護欄，這樣才不會把速度和穩定度一起打壞。

小結：AI 要先學會穩，才談得上強

模型會決定它能想到多遠，harness 會決定它能不能穩穩走完全程。

如果你最近常覺得同一個 AI 有時像神隊友，有時像散兵遊勇，先別急著只怪模型。你更該回頭看的是：它有沒有規則、記錄、煞車、審查與回溯能力。

因為很多時候，AI 真正缺的不是更大的腦，而是一個像樣的工作現場。

References

1. Anthropic Engineering (2025). Harness Design for Long-Running Application Development.
2. UC Berkeley (2025). Multi-Agent Trace Analysis Across 7 Frameworks.
3. Stripe Engineering (2025). Minions System — 1300 AI PRs per Week.
4. Agent Infrastructure Evaluation Study (2025). Collaboration Pattern Benchmarks.
5. OpenAI (2024). Codex Internal Report — 3 Engineers, 5 Months, 1M Lines.