我花了好幾個月的時間，建立了一個與模型無關的框架，用來和程式碼 Agent 一起完成真正的軟體工作。到頭來，那些功能特性遠比我想像的來得不重要。真正重要的，其實是一連串改變了我如何思考「與 Agent 一起建構」這件事的想法，而不只是單純地對它們下指令。
以下是這些想法中，最具份量的幾個。前三個徹底改變了我的思維模式。其餘的則是你可以立刻派上用場的實務方法。
1. 在 Agent 開始之前，就先凍結驗收標準
而且要把標準放在它無法修改的地方。
這大概是我最大的轉變。事後看來這似乎理所當然，但在我親眼見證它的效果之前，我並沒有真正體會到它有多重要。
如果驗收標準可以在工作完成後還能更改，那麼它們就會慢慢偏向於實際產出的結果。Agent 並非不誠實，它只是在針對一個還能移動的目標來評斷自己的工作。如果目標是可以移動的，那麼它們最終就會移動。
這不是一個提示詞的問題，而是結構性的問題，所以解決方案也必須是結構性的。
先把驗收標準寫下來。把它們儲存在 Agent 無法編輯的工作區之外，並自動阻止任何試圖編輯它們的行為。現在，Agent 是在為一個它無法重新協商的合約而工作。任務的完成與否，不是因為 Agent 說它完成了，而是因為它滿足了最初的合約。
2. 沒有人應該評判自己的工作
寫出程式碼的模型，是判斷程式碼是否正確的最差人選。當它完成工作時，它已經說服自己解決方案是合理的。
所以，把責任分開。
讓確定性的腳本來驗證所有機械性的部分。一個腳本無法憑空創造出一個成功的退出碼。把寫程式碼的模型當作工程師，而不是審查者。然後，把結果交給一個使用全新上下文的審查者，一個從未看過程式碼是如何被寫出來的審查者，來評判其設計、意圖和整體品質。
這個簡單的分工，捕捉到的問題遠比我預期的要多，而且執行起來出乎意料地便宜。
3. 強制執行容易，校準才是困難的部分
這個體悟改變了我對整個框架的看法。
大多數的 Agent 系統，包括我早期的版本，都對所有任務一視同仁。一個一行字的打字錯誤修正，和一個主要的架構重新設計，走的是同樣的流程。這不是浪費時間，就是風險太高。
關鍵在於按比例投入心力。
首先，要對工作進行分類。這是一個微小、不影響其他部分的變更，還是所有東西都依賴的核心基礎架構？這是商業邏輯，還是通用的工具程式碼？
然後，讓這個分類來決定它需要多少審查、該由哪個模型處理，以及允許它有多少自主權。
建立強制執行機制很容易。但要讓投入的心力能夠匹配，才是價值真正開始倍增的地方。
實務層面
在那些更宏大的想法就定位之後，幾個較小的實務做法立刻帶來了回報。
- 把規則放在框架裡，而不是放在提示詞中。 一個寫著「不要在主儲存庫中進行編輯」的提示詞，只是個建議。同樣的規則，如果被強制為一個被封鎖的工具呼叫，就變得無法忽視。重要的規則不應該依賴模型選擇表現良好。
- 把狀態保持在對話之外，並為每個任務使用全新的 Worker。 在外部儲存任務記錄，使用隔離的工作目錄，並透過合併佇列來處理變更。一旦狀態存在於對話之外，上下文長度限制就不再是你最大的限制。任務變得可以並行、可以恢復，並且更容易推理。
- 跨供應商審查勝過同供應商審查。 模型對自己工作的包容度，可能比對別人的工作更高。使用來自不同供應商的模型，是減少這種偏見的一個簡單而有效的方法。
為什麼這些原則有效
這些想法都不依賴於特定的模型。它們關乎的是框架工程：協定、驗證、審查流程，以及責任分離。
基準測試排行榜上頂尖的模型會不斷改變。
但這些原則很可能不會改變。
持久的價值不在於模型，也不在於功能特性。而是在於你圍繞著它們所建立的支撐結構。
