請工程師列出他們 Agent 的失敗模式，您會聽到幻覺、錯誤的工具呼叫，以及不良的 JSON。談到時間時，您得到的卻是聳聳肩。然而，生產環境中的 Agent 發生錯誤時，最常見的情況並非大聲失敗——而是它只是花了太長時間。它迴圈、重試不穩定的工具，或等待永遠不會串流第一個 token 的模型呼叫。而您的評估套件在事後針對最終出現的輸出進行評分，卻給它打了綠燈。

這就是盲點：我們將延遲視為 SRE 儀表板關注的問題，與正確性分開討論。但對 Agent 而言，超過期限就是正確性失敗。摘要晚了 90 秒到達通常比沒有摘要更糟——使用者已經離開，下游作業已經逾時，重試已經重複向他們收費。時間應納入您的評估，且應放在堆疊的最底部。

時間是一級證據

如果您遵循 agent-eval 背後的層級原則，您會知道證據在獨立性軸上進行排名——從 Agent 無法偽造的證據，到它共享基板的意見——而非成本軸。三個層級：

  • 一級——Agent 無法偽造的外部可觀察證明：有效的 JSON、檔案存在、程式碼已編譯、測試通過、它在期限內完成、輸出非空。
  • 二級——針對 Agent 未撰寫的基線的統計訊號：與任務的嵌入相似度、長度和重複性、差異是否實際改變了任何內容。
  • 三級——模型作為評判者：共享基板的意見。一個訊號，而非判決。

注意「在超時內完成」的位置。它是一級證據，與「有效的 JSON」並列。這不是偶然。實時期限是最獨立的訊號——Agent 無法與碼表爭論，無法透過推理繞過它，無法偽造它。物理定律對此進行評分。在您的整個評估套件中，沒有比「時鐘已跑完」更不可腐蝕的基礎事實了。

至關重要的是，一級+二級是您的即時閘道：確定性、成本約 $0、足夠快以至於可以位於熱路徑中並阻擋執行。超時檢查是這種情況的最純粹表現——它本身就位於熱路徑中。三級（評判者）則相反：按量計費、緩慢、非確定性、僅離線。您永遠不會將模型作為評判者放在關鍵路徑上來決定回應是否足夠快。評判者甚至看不到時鐘。

「評為綠燈」實際看起來如何

這就是陷阱。大多數評估工具接收 (input, output) 並對輸出進行評分。output 是 Agent 最終返回的任何內容——因此根據建構，時序資訊在評分開始前就已被丟棄。評估實際上無法看到執行超過了期限，因為它只在執行結束後才存在。

您必須對執行進行評分，而非返回值：

type RunResult<T> =
  | { status: "ok"; value: T; elapsedMs: number }
  | { status: "timeout"; elapsedMs: number; deadlineMs: number }
  | { status: "error"; elapsedMs: number; error: string };

async function withDeadline<T>(
  work: (signal: AbortSignal) => Promise<T>,
  deadlineMs: number,
): Promise<RunResult<T>> {
  const ctrl = new AbortController();
  const started = Date.now();
  const timer = setTimeout(() => ctrl.abort(), deadlineMs);
  try {
    const value = await work(ctrl.signal);
    return { status: "ok", value, elapsedMs: Date.now() - started };
  } catch (err) {
    const elapsedMs = Date.now() - started;
    if (ctrl.signal.aborted) {
      return { status: "timeout", elapsedMs, deadlineMs };
    }
    return { status: "error", elapsedMs, error: String(err) };
  } finally {
    clearTimeout(timer);
  }
}

Enter fullscreen mode Exit fullscreen mode

現在評估閘道變得簡單且確定——一個以微秒為單位執行的一級檢查：

function tier1TimingGate(run: RunResult<unknown>): { pass: boolean; reason?: string } {
  if (run.status === "timeout") {
    return { pass: false, reason: `deadline miss: ${run.elapsedMs}ms > ${run.deadlineMs}ms` };
  }
  if (run.status === "error") {
    return { pass: false, reason: `crashed after ${run.elapsedMs}ms` };
  }
  return { pass: true };
}

Enter fullscreen mode Exit fullscreen mode

超時的執行永遠不會到達二級或三級。沒有東西可以嵌入，沒有東西可以評判——太晚到達的正確答案不是正確答案。您短路、阻擋執行、回退。不需要詢問模型的意見，因為不需要意見。

期限是依預算而定，而非依 Agent 而定

我接下來看到的錯誤是單一全域超時。期限是情境性的：背景重新索引作業可能需要十分鐘；互動式聊天回合在使用者感知到停頓前可能只有三秒。期限是呼叫站點的屬性，而非 Agent 的屬性。將其作為任務合約的一部分進行執行緒化，並讓每個工具步驟繼承並遞減共享預算——因此，消耗 80% 預算的工具會讓模型沒有空間實際回應，而這也是一個可評分的事件。

您無法評分未記錄的時間

所有這些都假設您實際擷取了每個步驟的經過時間——而這就是評估故事的一半需要另一半的地方。agent-eval 對輸出進行評分和閘道；它只有在某物記錄了時序的情況下才能強制執行一級時序閘道。這就是追蹤擷取的工作。AgentLens 對 Agent 的軌跡進行檢測——每個模型呼叫和工具步驟，包含已解析的輸入、原始輸出，以及開始/停止時間戳——因此「在期限內完成」是一個您可以從 Agent 無法撰寫的不可偽造追蹤中讀取的事實，而非您希望某人記錄的數字。

這種配對就是重點。追蹤是一級+二級評分所依據的基板：因為 AgentLens 獨立於 Agent聲稱它做了什麼，記錄了每個步驟的開始和停止時間，您的時序閘道具有真實的基礎事實。Agent 可以幻覺它「快速回應」。它無法編輯它未撰寫的追蹤中的時間戳。這就是能夠在一級+二級確定性地捕獲 80% 無聊失敗（過時、當機、空值、太慢）的評估，與安靜地隱藏每個晚一分鐘跨過終點線的執行的綠色勾選儀表板之間的差異。

將評判者保留給主觀的 20%——語氣、幫助性、「這是否實際回答了問題」——並將其標記為意見，而非證據。但碼表呢？那是證據。將它放在第一位。