安全匣優先（Harness First）
模型就像引擎。大多數的「模型問題」其實是安全匣缺失所造成的：沒有定義什麼是正確的輸出、沒有檢查變更、沒有成本上限、資料缺乏公認的定義、動作沒有核准、而且沒有任何追蹤紀錄可以找到出錯的呼叫。在動模型之前，先稽核這些項目。
1. 根據證據複現症狀，而不是憑感覺
- 閱讀症狀所涉及的代理程式碼：迴圈、工具定義、提示組合、資料存取、產生副作用的工具。
- 閱讀所有存在的日誌/追蹤/對話記錄。將它們彙整（按對話、按工具、按錯誤分類）：誰花費了 Token、哪些呼叫失敗、哪些答案是錯的。通常少數幾個離群值就占了大部分問題。
- 將根本原因描述為一個有證據支持的機制（檔案:行數、日誌 ID、你計算出的數字）。「模型不好」並不是一個機制。
常見機制：
- Token 燃燒： 沒有最大迭代次數的迴圈、在確定性錯誤上重試、每次回合都重新發送完整歷史記錄或龐大的工具結果、沒有快取穩定的上下文。
- 「幻覺」： 代理忠實地使用了一個含糊不清或錯誤的來源（兩個名稱相同但意義不同的表格/欄位、過時的文件）。請自己重新計算兩邊的數據來證明。
- 脆弱性： 提示變更在沒有回歸測試集的情況下就發布；行為只有作者手動檢查過。
2. 評估六個安全匣元件
針對每一項，根據你找到的證據標記為 有 / 部分有 / 沒有：
| 元件 | 「有」的定義 |
|---|---|
| 黃金測試集 | 約 20 個以上的案例，包含預期答案或限制條件，取自真實流量、事故和邊界情況 |
| 評判機制 | 首先是確定性檢查（數字、政策規則、禁止內容），只有程式碼無法檢查的部分才使用 LLM 評分；在每次提示/模型/工具變更時執行 |
| 成本治理 | 每個使用者和每個工作流程都有硬性的 Token/成本上限、每次執行的最大迭代次數、以優雅訊息停止 |
| 資料層 | 讀取使用唯讀憑證、一份資料字典定義代理可能使用的每個指標/欄位 |
| 動作安全 | 不可逆或對外部有影響的動作（發送、付款、刪除、寫入、退款）是可逆的，或需經人工核准 |
| 追蹤 | 每次模型和工具呼叫都記錄了對話 ID、工作流程、輸入、輸出、Token、成本、延遲、錯誤 |
3. 在開始建構之前先決定
- 絕對不要在沒有評估證據的情況下推薦更換模型。 如果有人問「我們應該切換模型嗎？」，答案是：先修復機制，然後在兩個模型上執行黃金測試集，比較品質和成本。用你的數據說明單單修復機制預計能節省多少。
- 絕對不要在沒有執行黃金測試集的情況下批准發布提示/代理變更。 如果存在記錄的輸出，請自行根據預期答案對它們進行評分，並按案例 ID 報告失敗情況。
- 安全漏洞（未經閘門控制的副作用、讀取路徑上的寫入權限、洩漏內部資料）是阻斷性問題，即使沒有人問到它們。
4. 建立最小的安全匣，按此順序
- 停止失血： 設定最大迭代次數、不要在非暫時性錯誤上重試、截斷/摘要大型工具輸出、設定每次執行的硬性成本上限。
- 閘門效應： 為不可逆工具設定核准步驟或草稿模式；為查詢工具設定唯讀連線。
- 黃金測試集檔案（例如
evals/golden.jsonl）：包含輸入、預期答案或限制條件、來源（日誌 ID / 事故 / 政策條款）。包含剛剛失敗的案例。 - 評判腳本，執行黃金測試集並輸出每個案例的通過/失敗以及總計。先進行確定性檢查，再使用 LLM 評分。
- 資料字典，針對代理報告的每個指標（定義、來源表格/欄位、排除條件）。
- 追蹤，如果缺少上述欄位，則加上。
寫出實際的檔案，而不是檔案的描述。執行可以執行的部分，並報告結果。
5. 報告
- 對實際提出的問題給出一行解答（例如：「先別換模型：3 次執行卡在重試迴圈中，花費了 71% 的 Token」）。
- 附上證據和數字的根本原因。
- 安全匣評分卡（六個元件）。
- 你修改或建立了什麼，以及你執行了什麼。
- 阻斷性風險，然後是一份簡短的優先級後續步驟清單。
致謝
此技能遵循的方法來自 Mark Ajzenstadt (@mardehaym) 的一篇公開文章：https://x.com/mardehaym/status/2099562230647804152。論點是他的；此處的程序、措辭和評估則是 Edge 自己的，作者並未審閱它們。