模型管你能做多少，規則管你會不會亂寫：V2EX 那篇 Agent 分享，把紀律講成了硬體

先把背景補上。這幾天 V2EX 的「分享創造」板出現一篇貼文，標題直接下了一句結論式的話：AI Agent 的能力上限由模型決定，行為的可靠性與一致性由規則體系決定。發文者 tntin 除了分享自己在用 Agent 開發專案過程中累積的理解，也順手推薦了自己開發的知識庫工具 knloop。貼文刊出約八小時，累積近三百次瀏覽，目前還沒有留言，但在開發者社羣裡，這類「把經驗整理成一張對照表」的長文，向來是被收藏轉發的類型。

一句話拆成兩層看

這篇貼文的核心是一張二維對照。模型層決定的是理解、推理、創作與工具呼叫的能力邊界；規則層決定的是目標拆解、工具白名單、權限審批與可驗證性。用發文者自己的比喻來說：沒有模型，Agent 沒有能力；沒有規則，Agent 沒有紀律。

兩層的失敗模式也不同。模型層出問題時，通常是「能做但太貴太慢」；規則層出問題時，則是「寫了卻跳過」「自由發揮導致亂寫」。後者正是多數人實際用 Agent 時最常撞到的牆：提示詞裡寫得清清楚楚，模型偏偏繞過去。

規則從「建議」變成「強制」

貼文裡最有操作價值的一段，是把「必須」「禁止」這類約束，從提示詞裡的文字復述，升級成程式的必經節點。換句話說，規則不能只靠模型「記得」，要在流程上設計成跳不過去的關卡。這也是發文者對 Agent 規則文件的定位：一份權重極高的長期持久提示詞，接近系統提示詞，在長任務的每一步持續約束判斷，與解決單次互動的臨時 prompt 本質不同。

至於怎麼分辨好規則與壞規則，發文者給了一個很直覺的判準：壞規則寫價值觀，好規則寫動作與驗收。「回答要有審美」「方案要高級」這類抽象形容詞，Agent 無法落地判斷；從日常反覆踩坑的真實問題出發，寫清楚遇到這類問題時下一步執行什麼動作、結果怎麼驗收，才是可校驗的好規則。一份完整的規範，在他看來應該涵蓋角色、場景、輸入輸出、可做與不可做、工具邊界、人工確認、失敗處理與驗收標準。

這種把「能跑」與「能上線」之間的落差攤開來討論的取向，和先前被開發者轉瘋的那篇從 while(true) 到生產級迴圈其實是同一條思路：demo 容易，紀律難。

順手推薦的工具：knloop

貼文後半段是發文者自己的工具 knloop，一個 Agent 原生的知識庫。定位是讓規範、SOP、QA 與復盤寫成持久化的 .md 文件，Agent 透過 MCP 讀取後按規範執行，產出再寫回同一個庫，全程可審計、可回滾。發文者的說法是，你定義動作與驗收標準，Agent 在每一步對照執行。

需要說明的是，這段屬於作者的自我推薦，工具實際表現如何，目前貼文下方尚無留言與第三方使用回饋可以佐證。

為什麼這類文章總有人看

把幾件事並排放在一起看，味道就出來了。開發者社羣這半年對 Agent 的討論，早就從「模型能做什麼」轉向「怎麼讓它每次都做對」。從 Agent 開發面經裡對框架與規則設計的追問，到各種把規則文件、知識庫接進工作流的做法，關注的焦點都在同一處：模型的能力每年都在跳，但行為的一致性，最終是工程問題，不是許願問題。

這篇貼文的價值不在於提出了全新觀點，而在於把已經是社羣共識的體感，整理成一張能直接拿去用的對照表，外加一套寫規則的判準。至於 knloop 會不會被撿去用，就看接下來有沒有人真的把它接進自己的 Agent 流程了。