AI Agent Arxiv Digest — 2026-09-07

🌏 English version

今日總覽

今天三篇論文分別鎖定 Agent 系統三個容易被忽視的信任邊界。OBPE 處理「誰能存取什麼」——讓 Agent 借用人類憑證後，審查邏輯搬到推理之外的獨立邊界，3,621 次試驗把 trace failure 從 57.6% 壓到 0.2%。Polished but Unresolved 處理「什麼時候該停止」——用線性探針證實 Agent 有一種可被偵測、可被干預的「想早點交卷」內部狀態，調校它就能提升長程任務的達成率。Control-Data Flow Separation 處理「什麼可以被自動優化」——用 TextGrad 之類工具自動改寫多 Agent 系統的 prompt 時，一不小心會把執行協定也改壞，分離控制流與資料流後可以維持 100% 協定有效性。三篇合起來說的是同一件事：Agent 系統的可靠性，越來越取決於這些容易被忽略的邊界有沒有守住。

讀這篇前該知道的詞

詞	白話解釋
Out-of-Band Policy Enforcement（帶外策略執行）	把「這次呼叫該不該放行」的判斷，搬到 Agent 推理迴圈之外的獨立邊界，不讓同一個容易被騙的模型球員兼裁判
致命三要素（Lethal Trifecta）	私有資料存取、不可信內容、對外通訊三者同時出現時，Agent 最容易被誘導洩漏資料或濫用權限
線性探針（Linear Probe）	訓練一個簡單的線性分類器，直接從模型的隱藏層狀態讀出它現在是否處於某種內部狀態
激活轉向（Activation Steering）	推理時直接對隱藏層向量加減一個方向，改變模型的行為傾向，不需要重新訓練
Prompt Optimization（提示詞優化）	用 TextGrad、DSPy、GEPA 等工具，讓演算法自動改寫、迭代 Agent 的 prompt 以提升表現
控制-資料流分離（Control-Data Flow Separation）	把 Agent 輸出拆成「程式讀的結構化欄位」和「給人或其他 Agent 讀的自由文字」，避免優化把執行協定改壞

---

論文一｜OBPE：把「你能存取什麼」的判斷，搬到 Agent 推理之外

If Agents Were Angels, No Governance Would Be Necessary: Out-of-Band Policy Enforcement at a Trusted Tool Boundary Marc Millstone, Tyler Akidau, Johannes Brüderl et al.（Redpanda Data）　·　arxiv: 2608.27646

連結: arxiv · alphaxiv

TL;DR

在 3,621 次對照試驗中，把政策檢查搬到 Agent 推理之外的獨立邊界後，trace failure 率從 57.6% 降到 0.2%（cluster-weighted 減少 41.2 個百分點，95% CI [27.7, 54.9]），同時安全且有用的完成率從 22.0% 升到 58.9%。

編輯判斷

面向	判斷
Venue	arXiv preprint（未經同行審查）
引用速度	發布約 11 天，Semantic Scholar 0 citations
機構	Redpanda Data（產業界；作者揭露其生產系統已有對應的 Agentic Data Plane 產品）
社群反應	未見於 HF Daily Papers 或 Papers with Code
可信度	通過 — 4 個模型、3,621 次試驗、20 個回應自適應紅隊任務，並附順序無關性與單調收窄的形式證明
證據成熟度	較完整 — 主效應、無 prompt 規則的穩健性、消融階梯、與輸出審查基準的比較四路齊全，且對缺失試驗做敏感度分析
可復現性	部分產物 — 釋出簡化版 HTTP proxy 原型與 Cedar policy schema、conformance tests，但未見獨立公開的完整程式碼倉庫連結
為什麼選這篇	直接 — 這是 Agent 借用人類憑證後的存取邊界問題，直接影響任何企業 Agent 部署
方向新意	實質增量 — 首次形式化證明帶外策略執行的順序無關性與兩層策略模型，並用大規模對照試驗量化效果
今日重要性	高 — 企業 Agent 正大量接上 Jira、ServiceNow 等內部系統，存取邊界是最迫切卻最少被量化的一塊
實務連結	明確 — 任何用 credential 驅動的企業 Agent 都可直接參考此兩層策略架構
編輯信心	高 — 對照試驗設計嚴謹，且誠實揭露殘餘的洩漏管道
閱讀建議	必讀 — Agent 平台工程師、企業安全與治理團隊
主要限制	評測環境是受控的 Jira/ServiceNow mock，其中 116 次試驗受一個查詢求值器缺陷影響；仍有 4 個答案透過推理重建出從未進入 context 的精確值

領域背景

給 Agent 一組人類的憑證，它就繼承了這個人能存取的全部範圍，卻沒有繼承這個人「該不該這麼做」的判斷。OAuth scope、token exchange 能限縮憑證，但假設授權當下就知道這次任務該給多少權限——實務上往往不知道。現有做法靠 prompt 要求 Agent 自律，等於讓同一個容易被騙的推理者，同時扮演執行者和規則執行者。

中階導讀

• 問題：你請 Agent 彙整一個工程專案的 issue，它的服務憑證卻能讀到十幾個專案。若某個 issue 描述裡藏著一段指令，Agent 讀進 context 後可能被牽著走去執行不該做的操作——而且每次呼叫，憑證都合法有效。
• 方法：OBPE 在 Agent 的工具用戶端和後端系統之間插入獨立邊界。資料擁有者設定「最大授權範圍」，Agent 政策只能收窄不能擴大。每次呼叫先審查、縮小查詢範圍，回應回來後再過濾欄位、遮蔽敏感值；部分呼叫會被暫時擋下等外部核准。作者證明這套多階段合成在數學上「順序無關」。
• 為什麼重要：這證明「用 prompt 要 Agent 自律」和「在推理之外設一道真正擋得住的邊界」是不同等級的防護。Prompt 只能讓答案看起來比較收斂，擋不住資料一開始就進了 context、也擋不住後端動作真的被執行。

深入要點

• 3,621 次試驗：加裝 OBPE 後 trace failure 率從 57.6% 降到 0.2%，cluster-weighted 減少 41.2 個百分點 [95% CI: 27.7, 54.9]
• 只靠 prompt 規則：exact disclosure 從 27.5% 降到 3.7%，但 context exposure 幾乎沒變（55.1% → 52.1%）——答案更含蓄，資料卻早就進了 context
• 20 個回應自適應紅隊任務：prompt-only 有 74.9% 觸發 trace failure，OBPE 只有 0.9%
• 仍有 4 個最終答案重建出從未進入 context 的精確值 ⚠️（Redpanda Data 自測，未見外部複現）——作者誠實列為未解的洩漏管道
• 落地門檻：需先把後端操作對應成型別化的 Cedar policy schema，適合已有 API gateway/proxy 層的企業環境

Reviewer 一句話評

用大規模對照試驗量化邊界防護與 prompt 防護的差距，且誠實揭露殘餘洩漏管道，是最紮實之處；待觀察的是評測只在受控 mock 環境進行，正式環境效果仍待驗證。

給你的 take-away

• 幫企業 Agent 接 Jira、ServiceNow 等內部系統：別只靠 system prompt 規則，參考 OBPE 的兩層政策模型，把稽核邏輯搬到推理之外
• 設計 Agent 安全評測：把「資料有沒有進 context」和「答案有沒有洩漏」分開測——只測後者會嚴重低估風險

---

論文二｜Polished but Unresolved：Agent 想收工的念頭，藏在隱藏層裡

Polished but Unresolved: Identifying Late-Stage Pressure States in Long-Horizon Tool-Use Agents Haoyang Chen, Yi Liu, Jian-Zhi Shao et al.　·　arxiv: 2609.00823

連結: arxiv · alphaxiv

TL;DR

訓練一個線性探針就能從 Qwen3-14B 的隱藏狀態預測 Agent「快要提早交卷」的傾向；用這個訊號做激活轉向加狀態整理，PSPR 讓 Qwen3-32B 上 ReAct 的 Composite Score 從 29.3 提升到 33.2。

編輯判斷

面向	判斷
Venue	EMNLP 2026（作者於 arXiv Comments 欄位自報已獲接受；Semantic Scholar 尚未同步索引）
引用速度	發布 6 天，Semantic Scholar 0 citations
機構	論文未標示明確機構（作者信箱為個人信箱）
社群反應	未見於 HF Daily Papers 或 Papers with Code
可信度	通過 — 3 個模型骨幹、3 種 agent 架構、3 個 benchmark，並用隨機/固定觸發控制組排除「隨便介入都有效」的混淆
證據成熟度	較完整 — 探測、干預、緩解因素到 PSPR 全鏈路皆有量化實驗，並用二折保留評估避免探針過擬合
可復現性	部分產物 — 方法與超參數（a=0.4, b=0.65）完整揭露，但未見公開程式碼倉庫連結
為什麼選這篇	直接 — 這是「Agent 什麼時候該停」的內部決策邊界問題，直接影響任何長程工具使用 Agent 的可靠性
方向新意	實質增量 — 首次證明提早交卷傾向是隱藏空間中可線性分離、可被激活干預的內部狀態，而非只是事後才看得出的行為模式
今日重要性	高 — 對長程任務普遍存在的「看起來做完但沒真的做完」問題，提供了第一個可監控的內部訊號
實務連結	明確 — 用 ReAct/Reflexion 類 scaffold 且任務有明確硬性限制的團隊可直接測試這套方法
編輯信心	高 — 因果鏈條完整，且有對照組排除混淆
閱讀建議	必讀 — 長程 Agent 平台工程師、可靠性研究者
主要限制	驗證場景集中在旅行/購物規劃這類有明確可驗證限制的任務；白盒探針方法需要存取隱藏狀態，API-only 商用模型無法直接套用

領域背景

長程 tool-use agent 的評測長期關注「有沒有把任務做完」，較少關注「Agent 自己覺得可以交卷了」背後發生了什麼。先前研究已從行為層面指出 Agent 會誤把部分進度當成任務完成，但沒有人問過：這種提早收工的傾向，是不是模型內部一個可以被偵測、被介入的狀態，而不只是事後才看得出的行為模式。

中階導讀

• 問題：Agent 幫你排一趟旅行規劃，跑了十幾輪工具呼叫後交出一份格式漂亮的行程，但其中一條硬性預算限制其實沒被滿足。你只看得到成品，看不出它是不是「差不多就好」交出來的。
• 方法：作者先訓練一個線性探針，從決策節點的隱藏狀態讀出「現在有多想收工」的分數，證實這訊號跟真正行為（繼續查證 vs 提早交卷）有因果關係。接著發現兩個能緩解壓力的因素：把「哪些限制還沒滿足」講清楚（constraint clarity），以及把未滿足項目對應到具體下一步（action mapping）。PSPR 把這些發現包成線上控制器：壓力中等時做輕量激活轉向，壓力升高時才觸發完整狀態整理。
• 為什麼重要：這把「Agent 什麼時候該停」從只能靠更好 prompt 去猜的問題，變成有內部訊號可即時監控、介入的工程問題。

深入要點

• DeepPlanning-Travel 主測試（pass@3）：Qwen3-32B 上 ReAct 的 Composite Score 從 29.3 提升到 33.2、CoT 從 25.2 提升到 28.1，三種 agent 架構、三個模型骨幹全面提升
• 消融對照組：把探針觸發換成「隨機觸發」或「每 3 步固定觸發」，CP 分別只有 18.4、20.8，遠低於 PSPR 的 22.6——說明有效的不是「多介入一次」，而是探針抓對了時機
• 加上 constraint clarity + action mapping 後，PresC-risk 節點的壓力分數從 0.62 降到 0.13，直接處理未滿足限制的比例從 8% 升到 85%
• 泛化到 DeepPlanning-Shop、TravelPlanner 仍然有效，但 TravelPlanner 的嚴格 Final 分數沒有變動，只有較軟的品質指標進步

Reviewer 一句話評

從探測、干預到緩解因素、控制器一路走下來因果鏈條完整，加上隨機/固定觸發對照組排除了「隨便介入都有效」的疑慮；待觀察的是白盒探針能不能遷移到商用 API 模型。

給你的 take-away

• 做長程 tool-use agent 且能存取開源模型隱藏狀態：PSPR 的探針加分級介入設計，是目前最具體的偵測並緩解方案
• 只能用 API 模型：至少借用它的發現——在 context 明確列出「還沒滿足的限制」加「對應的下一步」，就能降低提早交卷機率

---

論文三｜Control-Data Flow Separation：優化 Agent 的 prompt，別把協定也改壞了

Control-Data Flow Separation: Stable Prompt Optimization in Multi-Agent LLMs Wentao Zhang, Syed Shariyar Murtaza, Junaid Bhatti et al.（University of Waterloo + Manulife）　·　arxiv: 2609.00621

連結: arxiv · alphaxiv

TL;DR

把多 Agent 系統的輸出拆成「程式讀的控制通道」和「可被優化的資料通道」後，在審稿生成任務上維持 100% eventual protocol validity（naive TextGrad 崩潰到 0%），同時 Jaccard 分數從 31.0 提升到 44.4，勝過 DSPy 的 BootstrapFewShot 與 MIPROv2。

編輯判斷

面向	判斷
Venue	EMNLP 2026 Findings（arXiv Journal reference 欄位已登錄，信心層級高於自報）
引用速度	發布 6 天，Semantic Scholar API 今日 rate-limited，未能確認引用數
機構	University of Waterloo + Manulife（保險核保流程有產業實測版本）
社群反應	未見於 HF Daily Papers 或 Papers with Code，但程式碼已公開（github.com/yuntian-group/cdsep）
可信度	通過 — 4 個評測情境（含產業驗證保險核保）、3 個 LLM 家族穩健性測試、完整消融拆解各組件貢獻
證據成熟度	較完整 — 主效應、消融、跨模型穩健性、真實產業場景四路齊全
可復現性	完整產物 — 公開程式碼倉庫，號稱 40 行內 Python 可跑完整 pipeline
為什麼選這篇	直接 — 這是「什麼可以被自動優化」的協定邊界問題，任何用 TextGrad/DSPy/GEPA 做 prompt optimization 的多 Agent 系統都適用
方向新意	實質增量 — 首次把控制/資料分離原則系統化套用到多 Agent prompt optimization，並用真實產業場景驗證
今日重要性	高 — Prompt optimization 工具正快速普及，協定崩潰是目前最少被討論的失效模式
實務連結	明確 — 用 prompt optimizer 自動調多 Agent 系統的團隊可直接套用 cdsep library
編輯信心	高 — 消融乾淨、跨模型穩健、程式碼公開
閱讀建議	必讀 — 多 Agent 系統工程師、用 prompt optimization 工具的團隊
主要限制	保證的是協定不會壞，不保證輸出語意正確；作者明確寫出「協定有效的 pipeline 仍可能產出錯誤或低品質結果」

領域背景

Prompt optimization（用 TextGrad、DSPy、GEPA 這類工具自動改寫、迭代 agent 的 prompt）已是改善多 Agent 系統表現的標準做法。但多 Agent 系統裡 prompt 常身兼兩職：一邊要寫出好內容，一邊內嵌著程式依賴的執行協定（下一個該輪到誰、輸出格式、什麼時候該停）。優化器只看任務表現調整文字，不知道哪些字是「內容」、哪些其實是「協定」。

中階導讀

• 問題：一個多 Agent 審稿系統裡，leader agent 被要求輸出一段 JSON，裡面有 action 和 target_agent 兩個欄位，Python controller 讀這段 JSON 決定接下來換誰做事。Prompt optimizer 為了讓內容寫得更好把指示改寫了——結果 JSON 格式跑掉，controller 解析失敗，pipeline 當場崩潰。
• 方法：作者把每個 Agent 的輸出拆成兩條通道：「控制通道」是型別化、會被 runtime 驗證的程式物件，只給 controller 讀，優化器動不了；「資料通道」是給人、給其他 Agent、也給優化器改的自由文字。協定本身被凍結在獨立、不可編輯的欄位裡。
• 為什麼重要：這讓「可以被自動優化」和「不能被自動優化」之間畫出清楚的線，不用犧牲效能提升，也不用賭優化器永遠不會手滑改壞協定。

深入要點

• 4 個評測情境（BBH、MARG 多 Agent 審稿生成、合成版與產業驗證版的保險核保流程）：本方法全程維持 100% eventual protocol validity，naive TextGrad 在審稿任務上崩潰到 0%
• 審稿任務 Jaccard 分數：naive 0.0%（協定全毀）、schema-only 26.8%、完整版 38.0%；消融顯示「每個範例的回饋訊號」才是拉高分數的主因，schema 分離主要負責穩定性
• 3 個模型家族穩健性測試（OpenAI/Anthropic/Google）：naive TextGrad 三家都是 0% 穩定性，本方法三家都維持 100%
• Prompt 編輯分析：naive optimizer 有 16.6% 的編輯行數觸碰協定相關字詞，本方法只有 4.2%，且多半只是巧合字詞重疊
• Limitation：作者明確寫出「協定有效的 pipeline 仍可能產出錯誤或低品質結果」——協定穩定不等於答案正確 ⚠️（作者自陳邊界）

Reviewer 一句話評

用產業驗證的保險核保流程搭配三個模型家族的穩健性測試，證據紮實且誠實劃清「穩定」與「正確」的界線；待觀察的是框架能不能推廣到協定本身需要頻繁演化的系統。

給你的 take-away

• 用 TextGrad、DSPy 或 GEPA 幫多 Agent 系統做 prompt optimization：把路由、格式、終止訊號獨立成型別化凍結欄位，不讓優化器碰，可參考 cdsep 的作法
• 設計新的多 Agent 框架：一開始就把「程式讀的結構化欄位」和「Agent 溝通的自由文字」分開設計，不要等優化器混在一起後才解開

---

今日收穫

之前以為 Agent 系統要顧的安全問題主要是「別讓它做壞事」，今天發現真正常被忽略的是三道更基礎的邊界：誰能存取什麼、什麼時候該收手、什麼東西可以被自動改。這三篇分別把每一道邊界的失守成本量化了出來——不是抽象的風險，是具體到百分點的數字。

參考資料

• If Agents Were Angels, No Governance Would Be Necessary: Out-of-Band Policy Enforcement at a Trusted Tool Boundary
• Polished but Unresolved: Identifying Late-Stage Pressure States in Long-Horizon Tool-Use Agents
• Control-Data Flow Separation: Stable Prompt Optimization in Multi-Agent LLMs
• Control-Data Flow Separation GitHub repo (cdsep)
• Redpanda Agentic Data Plane (production system referenced by OBPE)