本文研究窗口是 2026-05-04 到 2026-05-10。這週研究線最清楚的變化是：AI Agent 評測不再只問「答案對不對」，而是開始問「這條路是怎麼走到答案的」。

如果新聞線在講 Agent 進入金融、語音、企業治理，那研究線就在補另一個問題：我們到底怎麼訓練、觀察、評估一個會分工、會調工具、會平行探索、會停下來的系統？

1. Multi-agent RL 的單位從 action 變成 orchestration trace

5 月 4 日提交的 Reinforcement Learning for LLM-based Multi-Agent Systems through Orchestration Traces 是這週最貼近「Agent 變成作業層」的一篇。它的重點不是再做一個 agent benchmark，而是提出一個觀察單位：orchestration trace。

傳統 RL for agents 常常把重心放在單個 agent 的動作：下一個 tool call 是什麼、下一句話怎麼寫、什麼時候回覆。但多 agent 系統真正困難的地方不是單一步驟，而是團隊怎麼運作：何時 spawn sub-agent、把什麼任務 delegate 給誰、訊息怎麼傳、結果怎麼聚合、什麼時候停止。

作者把這些事件放進一條 temporal interaction graph，並整理出 reward design、credit assignment、orchestration learning 三條技術軸。最值得記的是那個空白：在它截至 2026-05-04 的 84 篇 paper pool 裡，沒有找到明確針對「何時停止」這個 orchestration decision 的 RL training method。

這個缺口很真。真實 agent 失敗常常不是因為它完全不會做，而是因為它不知道什麼時候該停、該問人、該合併、該重跑。停止不是小細節，是 agent 成本、可靠性和使用者信任的控制閥。

2. 工具使用評測正在從 final answer 走向 trajectory diagnostics

OpenReview 上的 ICLR 2026 poster TRAJECT-Bench 把同一個問題推到 tool-use 評測。它批評既有評測太常只看 final answer，忽略工具是否選對、參數是否填對、順序是否正確。

TRAJECT-Bench 的做法是用高保真、可執行工具和 production-style API 任務，合成有 breadth 和 depth 的 tool-use trajectory。除了 final accuracy，它還看 tool selection、argument correctness、dependency/order satisfaction。這比「模型最後答對了嗎」更接近工程現場，因為 production agent 的事故常常發生在中間步驟：查錯 API、把相似工具混淆、參數瞎填、順序顛倒。

這篇給 builder 的提醒很直接：如果你的 eval 只看最後答案，你可能根本不知道 agent 是靠正確流程完成任務，還是靠運氣撞到結果。

3. Web agent 的 tool use 不一定是免費午餐

Microsoft Research 4 月的 The Tool Illusion: Rethinking Tool Use in Web Agents 不是 5 月新論文，但這週在 agent 評測脈絡裡很值得放進來。它問了一個容易被 demo 掩蓋的問題：工具真的穩定提升 web agent 嗎？

它的摘要說明，過去很多 tool-use 結論來自有限規模或不可比較設定，因此重新用更受控的實驗跨 tool sources、backbone models、tool-use frameworks 和 benchmarks 檢查。重點不是「工具沒用」，而是工具設計本身會改變行為，甚至引入副作用。

這件事對產品很重要。現在很多 agent framework 的預設語氣是「多接一個 tool，多一分能力」。研究線正在提醒我們：工具也是 action space，也是 error surface。工具越多，agent 可能越強，也可能更容易迷路。

4. Long-horizon agent 的 scaling 走向 parallel rollout + aggregation

Agentic Aggregation for Parallel Scaling of Long-Horizon Agentic Tasks 研究的是另一條路：既然長任務一次跑到底很容易卡住，那能不能平行跑多條 trajectory，再讓另一個 agent 聚合？

它提出 AggAgent，把多條 agentic trajectory 當成一個 environment，讓 aggregation agent 用輕量工具去檢查候選答案、搜尋 trajectory、按需合成資訊。作者報告在六個 benchmark、三個 model family 上，AggAgent 相比既有聚合方法平均最高提升 5.3 個百分點，在兩個 deep research tasks 上提升 10.3 個百分點，而且聚合成本被限制在單次 agentic rollout 等級。

我會把這篇和 orchestration trace 放在一起看：前者說多 agent 或多 rollout 系統要被記錄成可學習的軌跡；後者說這些軌跡不要只拿最後答案投票，而要讓系統能回頭讀路徑。

5. 這週研究線的共同結論

這週的共同結論不是「某個 Agent 已經通用可靠」。剛好相反，研究正在承認 Agent 不可靠的地方比以前更細。

以前我們說 agent 失敗，通常只說模型不夠強。現在問題拆得更清楚：

• 它會不會把任務拆給正確的 sub-agent？
• 它會不會選對工具、填對參數、照正確順序調用？
• 它跑多條路徑時，會不會知道哪條值得相信？
• 它是否知道何時停止？
• 我們的 benchmark 是否能看見中間錯誤，而不是只看最後答案？

這對工程師其實是好事。問題被拆細，才有機會被修。

下週我會盯什麼

第一，看是否有更多 paper 把 agent eval 從 answer-level 推向 trace-level。這會直接影響企業 agent 的測試方法。

第二，看 orchestration learning 是否開始出現真正可重放的 training traces，而不是只做 survey 或 schema。

第三，看 web/computer-use agent 的工具設計是否能沉澱成可復用規則：什麼工具粒度最穩、什麼 action space 最容易讓 agent 混淆、什麼時候該回到原子瀏覽器操作。

References

• Chenchen Zhang, Reinforcement Learning for LLM-based Multi-Agent Systems through Orchestration Traces, 2026-05-04
• Pengfei He et al., TRAJECT-Bench: A Trajectory-Aware Benchmark for Evaluating Agentic Tool Use, ICLR 2026 poster
• Renze Lou et al., The Tool Illusion: Rethinking Tool Use in Web Agents, Microsoft Research / arXiv, 2026-04
• Yoonsang Lee et al., Agentic Aggregation for Parallel Scaling of Long-Horizon Agentic Tasks, 2026-04-13