Agent 的評測：任務完成率怎麼量

單次問答可以比對標準答案，Agent 不行——完成同一個任務有很多條合法路徑。評測必須改成看最終狀態，而不是看過程。

核心概念：為每個測試任務定義「成功的可驗證條件」，讓程式判斷任務是否真的完成。

任務定義格式

{
  "id": "t_refund_01",
  "setup": {"fixtures": ["orders_seed.sql"], "user": "u_1001"},
  "task": "幫我取消訂單 ORD1000000123 並確認退款金額",
  "success": [
    {"type": "db",   "check": "SELECT status FROM orders WHERE no='ORD1000000123'",
     "expect": "cancelled"},
    {"type": "text", "contains_any": ["1,280", "1280"]},
    {"type": "no_side_effect", "tables": ["payments"]}
  ],
  "limits": {"max_steps": 8, "max_cost_usd": 0.05}
}

三類成功條件

狀態條件：資料庫、檔案系統、外部系統的最終狀態。最可靠。
輸出條件：回覆中是否包含關鍵資訊。次可靠，用寬鬆比對。
負面條件：不該發生的事沒有發生——沒有多刪一筆、沒有寄出信。這一類最常被遺漏，卻最重要。

環境隔離

Agent 評測會真的改變狀態，所以每個測試任務都要在乾淨的環境跑。實務做法是每次測試前重建資料庫（用 fixture）並使用假的外部服務。

@contextmanager
def sandbox(fixtures):
    db = create_temp_db()
    load_fixtures(db, fixtures)
    mocks = start_mock_services()      # 假的訂單 API、寄信服務
    try:
        yield Ctx(db=db, services=mocks)
    finally:
        mocks.stop(); db.drop()

要記錄的指標

完成率：全部成功條件都通過的比例。主要指標。
部分完成率：通過一部分條件，反映「差一點就成功」。
平均步數與平均成本：效率指標。
副作用違規率：負面條件被違反的比例。這一項應該是 0。
危險操作攔截率：需要確認的操作有沒有真的停下來等確認。

非決定性的處理

同一個任務跑三次可能有三種結果。單次執行的結果沒有意義，要跑多次取比例。實務上每個任務跑 3 到 5 次，用完成率而非「有沒有成功」來評估。

def eval_task(task, n=5):
    runs = [run_once(task) for _ in range(n)]
    return {
        'task': task['id'],
        'success_rate': sum(r.ok for r in runs) / n,
        'avg_steps': mean(r.steps for r in runs),
        'avg_cost': mean(r.cost for r in runs),
        'violations': sum(r.violations for r in runs),
    }