【2026 最新】Attention Interface 是什麼？用中斷矩陣與 Trace Replay 管理多 Agent（新手實作篇）

Attention Interface 是一套把「多 Agent 什麼時候能自己繼續、什麼時候才能打擾人」寫成可測政策的方法。它不是多加一個確認視窗，而是先評估可逆性、影響範圍、金額、敏感資料與等待成本，再輸出 continue、queue、ask-now 或 deny。

2026 年 8 月 22 日，Dan McAteer 在 Latent Space 的〈The Attention Interface〉中，把 agent harness 描述成模型連到人類注意力的介面。本文沿用這個 practitioner framing，但把它視為待驗證的設計假說：真正要交付的不是新名詞，而是一份能故障注入、能回放、能量化驗收的中斷政策。

如果你還不熟悉 harness，可以先讀 AI Agent Harness 是什麼；想直接搭一套執行骨架，則可搭配 AI Agent Harness 實作教學。這篇只專注一件事：如何讓多 Agent 正確使用你的注意力。

先說結論：Attention Interface 是什麼？先把注意力當成有限資源

一句話定義：Attention Interface ＝ 風險判斷＋等待成本 → 四種中斷路由。

這個問題其實比生成式 AI 更早。Microsoft Research 的Attention-Sensitive Alerting把通知決策拆成「現在知道的價值」「打斷當下工作的成本」與「延後查看的成本」。多 Agent 系統只是把通知來源，從郵件與行事曆換成會讀檔、呼叫工具、部署甚至付款的軟體代理。

因此，Attention Interface 的輸出不該只有「准／不准」：

• continue：風險低、可逆、範圍受限，Agent 可以繼續並留下 trace。
• queue：需要人判斷，但等待成本低；暫停相依分支，放進下一批審核，其餘獨立工作可繼續。
• ask-now：等待本身會放大風險，或動作涉及金額、客戶、公開環境，現在就中斷指定 owner。
• deny：即使有人很忙也不能先做，例如把密鑰送往未核准目的地，或在沒有已驗證回復路徑時做破壞性變更。

為什麼「每次都問」和「全自動」都會失靈？

每次有副作用就詢問，看似安全，實際上會把低風險測試、隔離分支修改、報告輸出全部變成人工排隊。提示一多，人會開始快速按允許；真正重要的付款或公開寄信，反而淹沒在普通問題裡。

相反地，把所有決策交給模型也不等於授權控制。OWASP 的 Excessive Agency 指南建議限制功能、權限與自主程度，對高影響動作保留人類核准，並由下游系統執行授權，而不是信任 LLM 自己判斷。換句話說，模型可以提出理由，但硬閘門必須在模型之外。

多 Agent 還多了一層 ownership：研究 Agent 發現問題、實作 Agent 想修、部署 Agent 準備上線，但誰能核准？如果事件沒有 owner、期限與交接資訊，「稍後問」就會變成無限等待。可先用 AGENTS.md 規則與 Gate寫清楚邊界，再由 Attention Interface 統一做即時路由。

第一步：用五個欄位建立中斷矩陣

不要先從工具名稱分類，先為每個「準備執行的動作」補齊以下五個欄位。NIST AI RMF Playbook 的 MAP 與 MEASURE 建議也把人類監督角色、風險的可能性與影響，以及可重複的測試與量測放進治理流程；這裡把同一精神縮成工程團隊可落地的事件格式。

1. 可逆性：失敗後能否在明確時間內回復？「理論上可回滾」不算，必須有已驗證的 rollback。
2. Blast radius：只碰 sandbox、單一專案，還是會影響客戶與公開環境？
3. 金額：是否建立付款、下單、提高雲端用量或產生不可忽略的費用？
4. 敏感資料：是否接觸密鑰、個資、客戶內容或未公開資料？目的地是否核准？
5. 等待成本：等到下一批審核只會慢一點，還是會造成事故擴大、期限錯過或其他 Agent 全面阻塞？

接著把矩陣寫成由高到低的優先規則。順序很重要：deny 必須先於 ask-now，ask-now 再先於 queue 與 continue。只要必要欄位缺失、型別不對或出現未知範圍，教學版政策一律 deny；成熟系統也可將部分未知事件導向 ask-now，但不能默認放行。

version: attention-v1
unknown_event: deny

deny:
  - secret_to_unapproved_destination
  - destructive_without_verified_rollback

ask_now:
  - money_or_purchase
  - blast_radius_in: [customer, public]
  - high_wait_cost

queue:
  - needs_owner: true
    wait_cost: low

continue:
  - reversible: true
    blast_radius_in: [local, sandbox]
    secret: false

第二步：設定 approval budget，但永遠不要把它當自動放行額度

Approval budget 是本文用來操作化 Attention Interface 的設計欄位：它代表團隊每天能合理處理多少次即時打擾，不代表 Agent 累積到額度就能自動批准。你可以先設定「每天 6 次軟性 ask-now、12:30 與 17:30 各處理一次 queue」作為假設，再用實際 trace 調整；6 不是通用答案。

• 額度用完時，只有低等待成本的軟性問題能轉入 queue。
• 付款、公開發布、客戶影響等高風險 ask-now，仍然立刻中斷，不吃掉就能消失。
• deny 永遠不因 budget、趕工或 owner 離線而降級。
• 每個 queue 項目要有到期時間；逾期後升級給備援 owner，而不是靜默放行。

這樣的 budget 比單純計算 prompt 次數更有用，因為它量的是「人被迫切換上下文的次數」。如果每天 20 次中斷有 18 次都被批准，問題通常不是人審得不夠快，而是政策把太多低風險事件送進 ask-now。

第三步：把 Attention Interface 放在模型與工具之間

政策函式只做分類，不直接執行工具；執行器收到決策後，才決定繼續、保存 checkpoint、呼叫人類核准流程或拒絕。這個分層能讓同一批事件安全地重播，也能防止模型用自然語言繞過規則。

type Route = "continue" | "queue" | "ask-now" | "deny";

function decide(event: ActionEvent): Route {
  if (!schemaIsValid(event)) return "deny";
  if (event.secret && !event.approvedDestination) return "deny";
  if (event.destructive && !event.rollbackVerified) return "deny";
  if (event.money || ["customer", "public"].includes(event.blastRadius)) {
    return "ask-now";
  }
  if (event.needsOwner && event.waitCost === "low") return "queue";
  if (event.reversible && ["local", "sandbox"].includes(event.blastRadius)) {
    return "continue";
  }
  return "ask-now";
}

// executor(route, event) 位於另一層；decide() 不呼叫任何工具。

不同框架只需要做薄薄的 adapter。截至 2026 年 8 月 29 日，OpenAI Agents SDK 的human-in-the-loop 文件可用 needsApproval 暫停執行、取得 interruptions，並序列化 run state 以便稍後恢復；LangGraph 的interrupt 流程則依賴 checkpoint。Claude Code 的 PreToolUse hook目前提供 allow、deny、ask 與 defer 決策。這些是承載政策的機制，不等於它們替你定義了風險矩陣。

若你選 Claude Code，可先參考 Claude Code Hooks 教學的 lifecycle gate；Attention Interface 再加上跨專案 owner、等待成本、budget 與 replay 驗收。無論用哪個框架，付款 API、密鑰代理與 production 權限都應在下游服務再次驗證，而不是只相信 hook 回傳值。

第四步：每次打擾都附上一張可行動的中斷卡

「可以嗎？」幾乎一定會製造第二輪追問。ask-now 與 queue 至少要攜帶事件 ID、Agent／專案、準備執行的動作、命中規則、可能後果、證據、回復計畫、owner、期限、policy version 與 idempotency key。中斷卡只放判斷所需摘要；密鑰與完整客戶資料留在受控系統，不要複製進通知或 trace。

{
  "trace_id": "tr_demo_042",
  "event_id": "deploy_017",
  "policy_version": "attention-v1",
  "route": "ask-now",
  "requested_action": "deploy production",
  "reason": "blast_radius=public",
  "rollback": "verified release checkpoint r_016",
  "owner": "release-on-call",
  "expires_at": "2026-08-29T18:00:00+08:00",
  "idempotency_key": "deploy_017:v1"
}

idempotency key 能避免同一事件被多個 Agent 重複詢問或重複執行；policy version 則確保隔天恢復 checkpoint 時，能知道當初是用哪一版規則做決策。跨 session 的交接細節，可再搭配 Agent 可觀測性教學建立 trace 與 owner 視角。

第五步：用 Trace Replay 驗證中斷政策，而不是憑感覺上線

先記錄「事件的結構化欄位＋最後的人類標籤」，再把完全相同的事件送進舊政策與新政策的純函式。不要直接重跑 production tool call：LangGraph 的time travel 文件提醒，從 checkpoint 重播時，後續節點及其中的 API 呼叫、LLM 呼叫與 interrupt 仍會再次執行。政策 A/B 應在無副作用的 replay runner 或 sandbox 中完成。

本文保留的 10 筆合成 fixture 涵蓋讀公開文件、sandbox 測試、隔離分支修改、文案歧義、客戶郵件、production 部署、付款、密鑰外傳與無備份刪庫。簡單 baseline 得到 8 次 ask-now、2 次 continue，且漏掉 2 個應硬拒絕的事件；attention-v1 得到 4 次 continue、1 次 queue、3 次 ask-now、2 次 deny，與這組預先標記的期望一致。因為標籤本來就依同一份政策設計，這只證明程式有照規則路由，不能推論真實團隊也會得到相同改善。

正式驗收至少追蹤以下指標；若你還沒有 eval 基礎，可先讀 AI Evals 新手教學：

• 打擾量：每人每日 ask-now 次數、queue 批次數、budget 超標次數。
• 安全漏報：應 ask-now／deny 卻被 continue 的 dangerous continue，以及應 deny 卻未 deny 的 hard-deny miss；兩者門檻先設為 0。
• 無效打擾：人類標成可 continue，政策卻 ask-now 的事件比例。
• 等待：queue dwell time、p95 決策延遲、逾期升級數。
• 產出：相同工作量下的完成率與被阻塞分支數；不能只追求更少通知。
• 覆蓋：未知欄位、未知工具、無 owner 與舊 policy version 的事件數。

第六步：故障注入，專門測那些「不該順利」的情況

一般 happy path 很容易全綠，真正有價值的是刻意破壞輸入。每次改政策，都固定回放至少以下案例：

• 刪掉 amount、owner 或 rollback proof：不得 continue。
• 把 secret 的目的地改成未知網域：必須 deny。
• 把本地預覽改成公開部署：必須從 continue 升為 ask-now。
• 瞬間送入 20 個低等待成本的歧義問題：應批次 queue，不能形成 20 次即時打擾。
• 重送相同 event ID：只能出現一個待核准項目，執行器也只能接受一次 idempotency key。
• 在 checkpoint 等待期間更新 policy：恢復時先比對版本，不能靜默套用另一版語義。
• 主要 owner 離線：到期後升級備援 owner，不得自動批准。

OpenAI Agents SDK 的tracing 文件會把 generations、tool calls、handoffs、guardrails 與自訂事件組成 trace，同時也提醒 trace 可能包含敏感資料。實務上只保留 replay 必需欄位、對內容做遮罩、限制保存期與查閱權限；可測性不需要以蒐集全部原文為代價。

給新手的 7 個重點：30 分鐘最小可行版本

1. 列出目前 Agent 能呼叫的所有有副作用工具。
2. 為每個工具填入五個風險欄位，缺值先 deny。
3. 寫出四種路由與優先順序，先硬編碼也沒關係。
4. 指定每個專案的主要與備援 owner。
5. 設定一個可被推翻的 soft approval budget 與兩個 queue 時段。
6. 從歷史 trace 去識別化抽 20 筆，再補 7 種故障注入。
7. 比較舊／新政策的漏報、無效打擾、等待與完成率；過 gate 才先在一個低風險專案啟用。

等這個版本穩定後，再把政策抽成共用服務，讓不同 agent runtime 共用同一個 decision API。想把規則、checkpoint、觀測與 eval 串成完整架構，也可從 AlphaLab 的 AI 課程地圖挑下一個實作主題。

常見失敗：中斷政策最容易在哪裡變形？

• 把 queue 當成晚點自動放行：queue 只是延後人類決策，未核准就不能執行。
• 用 Agent 自評信心當唯一風險：信心不是權限；風險欄位要由工具、環境與下游服務提供。
• 只量少了幾次打擾：若完成率下降或 hard-deny miss 上升，安靜只是把問題藏起來。
• 把所有工作一起暫停：queue 應只卡住相依分支，否則一個文案問題會凍結整個專案。
• 沒有 policy version：你會無法解釋同一事件昨天與今天為何得到不同路由。
• 把 trace 變成敏感資料倉庫：只存政策判斷所需的最少欄位，內容與密鑰分開控管。

Attention Interface 常見問題

1. Attention Interface 是正式標準嗎？

本文把它當作 practitioner 提出的設計語彙與可測假說，不用「標準」身分說服團隊。是否值得採用，要由你的 replay、故障注入與上線指標回答。

2. Approval budget 用完後，Agent 能自動批准嗎？

不能。它只限制軟性即時打擾的容量；低等待成本事件可轉 queue，高風險 ask-now 仍立刻中斷，deny 永不降級。

3. queue 和 ask-now 的差別是什麼？

兩者都尚未核准。queue 適合等待成本低的問題，等下一批由 owner 處理；ask-now 則代表延遲本身會增加風險或阻塞關鍵路徑。

4. 什麼情況一定要 deny？

教學版至少包含兩類：密鑰或敏感資料送往未核准目的地，以及破壞性動作沒有已驗證的 rollback。必要欄位缺失時也先 deny，再由人補齊資料。

5. 沒有多 Agent 框架也能實作嗎？

可以。先把 policy 寫成不執行工具的純函式，放在任務佇列或工具代理之前；之後才分別接 OpenAI Agents SDK、LangGraph、Claude Code hooks 或自家 runtime。

6. Trace replay 會不會重做付款或部署？

安全的政策 replay 不會。它只把已記錄、已去識別化的事件欄位送入 decision function；不要在 production workflow 中直接重跑後續節點，外部工具改用 mock 或 sandbox。

7. 怎麼知道 Attention Interface 真的變好？

同時比較 dangerous continue、hard-deny miss、無效打擾、queue 等待、完成率與未知事件覆蓋。只看通知變少，無法判斷安全或產出是否改善。

8. 團隊應該先從哪個專案開始？

從低風險、事件量足夠、owner 明確且有 sandbox 的單一專案開始。先 shadow mode 只記錄建議路由，不改執行，再通過 replay gate 後逐步啟用 continue 與 queue。