今日總覽
今天三篇論文,從三個不同切面檢視同一件事:Agent 系統的瓶頸,常常不在模型本身,而在你怎麼設計它的規劃流程、執行排程,以及 Agent 之間的互動介面。DAGent 處理的是「深度研究 Agent 該怎麼規劃」——與其一次把任務圖畫好再邊做邊補,不如邊做邊長,這篇已經通過 NeurIPS 2026 的同行審查。TomasuLLM 處理的是「coding agent 為什麼老是在等」——借用處理器亂序執行的老點子,讓 Agent 在工具還沒跑完時就先把後面的步驟準備好。Prompted Identity 則給所有想做跨供應商多 Agent 系統的人一個提醒:只要讓 Agent 知道彼此是哪個模型家族,合作效率就會明顯下降——即使任務完全沒有誘因要他們分邊站。三篇合起來說的是:效能與可靠度的下一步增益,可能不在換更強的模型,而在規劃、排程、互動介面這幾個容易被忽略的設計細節裡。
讀這篇前該知道的詞
| 詞 | 白話解釋 |
|---|---|
| Agent（智能代理） | 可以自己規劃步驟、呼叫工具、迭代執行的 AI 系統,不是一問一答的聊天機器人 |
| 深度研究 Agent（Deep Research Agent） | 需要在大量資料來源間檢索、綜合證據、邊做邊調整計畫的 Agent,例如自動化文獻研究或市場調查 |
| DAG 多 Agent 系統 | 用有向無環圖（Directed Acyclic Graph）描述子任務之間的依賴關係,讓可以平行做的子任務同時跑,彼此之間保持獨立的脈絡 |
| 投機執行（Speculative Execution） | 在還不確定某個結果是否會被用到之前,先猜測並提前執行,等結果確定後再決定要不要採用——CPU 亂序執行用的就是這個點子 |
| 陣營化（Factionalism） | 論文定義的現象:當 Agent 知道彼此的身份標籤（如模型家族）,即使任務沒有要求,也會自動形成「自己人優先」的小圈圈 |
| GRPO | 一種強化學習演算法,讓模型在同一個問題上產生多個回答互相比較,再依相對表現調整權重,近期常用於訓練 Agent 的多步驟推理 |
論文一｜DAGent:深度研究 Agent 的規劃,不該一次賭定
DAGent: Evaluate-then-Grow Planning for Deep Research Agents Hanwen Liu, Yuanfu Sun, Qiaoyu Tan（紐約大學上海校區） · arxiv: 2609.39154
TL;DR
與其先把整個任務圖規劃好、出錯再修補,DAGent 讓一個 Orchestrator 根據已完成節點的信心與不確定性訊號,一批一批地「長出」任務圖;在 BrowseComp-Plus、GAIA、xbench-DeepSearch 三個 benchmark 上,於 Qwen3-235B-A22B 規模下超越最強開源基線 5.3 / 5.8 / 2.0 個百分點,已獲 NeurIPS 2026 收錄。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | NeurIPS 2026(已收錄,論文頁面 Comments 欄位明確標註) |
| 引用速度 | 發布 2 天,Semantic Scholar API 本輪持續回傳 429(rate limit),多次重試後仍無法取得引用數 |
| 機構 | New York University(紐約大學上海校區) |
| 社群反應 | HuggingFace Daily Papers 2 個讚;官方 GitHub repo 已公開（1 星,發布僅 2 天） |
| 可信度 | 通過 — 五種基準 Agent 對照（ReAct、Summary、Fold、Flash-Searcher、FlowSearch）、三個 benchmark、四種開源骨幹模型加 GPT-5 延伸驗證,附完整 Pass@1 表格 |
| 證據成熟度 | 較完整 — 多基準多骨幹的主結果表齊全,但 RL 部分只在單一骨幹（Qwen3-8B）小規模驗證 |
| 可復現性 | 部分產物 — 官方程式碼已公開,但 RL 訓練僅 3 個種子、21 步更新,外部要重現大規模訓練結果仍需自行擴充 |
| 為什麼選這篇 | 直接 — 直接處理深度研究 Agent 最核心的「怎麼規劃」問題,並提出可檢驗的替代方案 |
| 方向新意 | 實質增量 — 把「先規劃後修補」的既有 DAG 多 Agent 範式,換成「邊做邊長」的增量規劃,並設計對應的拓撲感知強化學習訊號 |
| 今日重要性 | 高 — 深度研究類產品正快速增加,規劃策略的選擇直接影響準確率與計算成本 |
| 實務連結 | 明確 — 對任何在做 DAG 式多 Agent 編排（如自動化市場調查、文獻綜述工具）的團隊,提供可直接比較的替代規劃策略 |
| 編輯信心 | 高 — 足以支持「在測試的三個檢索密集型 benchmark 上,增量規劃優於既有的 Plan-then-Patch 範式」這個限定主張 |
| 閱讀建議 | 必讀 — 正在設計或評估深度研究類 Agent 架構的團隊 |
| 主要限制 | RL 訓練僅在 Qwen3-8B 用 LoRA 跑 21 步、3 個種子,結構合規性與準確率的關聯是相關性而非因果,論文自己也這樣註明 |
領域背景
深度研究任務需要 Agent 在大量資訊來源間穿梭,綜合證據,並隨著發現調整計畫。DAG（有向無環圖）式多 Agent 系統很適合這種場景,因為可以平行執行、把每個子任務隔離在獨立的依賴脈絡裡。但既有做法多半是「Plan-then-Patch」:先把整個任務圖規劃好才開始執行,出錯或缺證據才回頭修補。問題是深度研究一開始證據最薄弱,這時候卻要做出最篤定的規劃決策,後續的修補往往也只是在補救原本就不該規劃的分支。
中階導讀
- 問題:想像你在做一份市場調查,一開始資料很少,你卻被要求先把整份報告的大綱、每個章節要查哪些資料都定案,之後發現方向不對只能回頭改——改的成本比一開始就邊查邊調整高得多。
- 方法:DAGent 讓一個 Orchestrator 角色每次只長出一批新的任務節點,依據已經完成的節點傳回的信心與不確定性訊號決定下一批要查什麼,而不是一次規劃到底。為了讓長任務脈絡不爆掉,系統預設只傳遞精簡過的 QueryDocs 摘要,但保留完整執行紀錄供需要時調閱。論文還設計了 DAGRPO——一種感知任務圖拓撲的強化學習訊號,讓執行者的學習訊號會參考它在圖中的位置,規劃者的訓練也加入結構合規的正則化。
- 為什麼重要:對任何在做自動化研究、市場調查、文獻綜述這類需要多步驟檢索綜合的產品,規劃策略的選擇直接影響準確率與算力消耗。DAGent 顯示「晚一點、但根據更多證據再做規劃決策」這個方向,在三個獨立 benchmark 上都比既有做法好。
深入要點
- 以 Qwen3-8B 骨幹為例(官方公開數據表):BrowseComp-Plus 平均 Pass@1 40.0% vs 最強基線 Flash-Searcher 34.7%;GAIA 平均 46.6% vs 38.8%;xbench-DeepSearch 60.0% vs 55.0%
- 論文摘要標註的主結果是在 Qwen3-235B-A22B 規模下,DAGent 超越最強開源基線 5.3 / 5.8 / 2.0 個百分點(分別對應三個 benchmark),且這個領先幅度在四種開源骨幹上都能重現,延伸到 GPT-5(327K 上下文)也一樣
- 在 Qwen3-8B 規模,DAGRPO 比同樣訓練預算下只看結果的 outcome-only GRPO 基線平均高出 3.0 個 Pass@1 百分點
- 同架構對照顯示:採用證據條件式規劃(evidence-conditioned planning)在相同 per-task token、工具呼叫數與步驟數下,準確率高於 Plan-then-Patch 版本——不是靠燒更多資源換來的
- 對照基準包括兩個同屬 DAG 式的既有系統 Flash-Searcher 與 FlowSearch(後者用作者釋出的官方實作複現,但受限於程式碼釋出時間只在 Qwen3-32B 測過)
- Limitation(論文附錄 F 原文):DAGent 是純文字系統,多模態附件需先轉文字才能規劃;「結構合規性與準確率的關聯」是相關性而非因果;RL 只在單一骨幹小規模訓練,更大規模是否成立未驗證
Reviewer 一句話評
把「先規劃後修補」換成「邊做邊長」是個直覺上合理、但過去少有人把拓撲感知的強化學習訊號做到這麼細的設計,五種基準對照加四種骨幹模型的重現性也做得扎實;但 RL 部分只在一個小骨幹用很少的訓練步數驗證,結構合規與準確率之間的因果關係論文自己也只敢說是相關性,這塊還需要更多訓練規模的驗證。
給你的 take-away
- 如果你在做 DAG 式多 Agent 編排(自動化研究、市場調查、文獻綜述工具):評估讓 Orchestrator 根據已完成節點的信心訊號動態長出任務圖,而不是一次規劃到底,尤其在證據一開始就很薄弱的任務上
- 如果你在設計多步驟 Agent 的強化學習訓練訊號:DAGRPO 把任務圖的拓撲結構也算進信用分配(credit assignment),這個做法值得在你自己的 DAG 式系統上先用小規模驗證再決定是否投入更大訓練預算
論文二｜TomasuLLM:借硬體亂序執行的老點子,讓 coding agent 不再乾等
TomasuLLM: Out-of-Order Speculative Execution for LLM Agents Jiangnan Yu, Ceyu Xu, Mengming Li et al.（香港科技大學,另有南京大學、阿卜杜拉國王科技大學、之江實驗室共同掛名） · arxiv: 2609.38201
TL;DR
把 CPU 亂序執行的設計搬進 coding agent 的執行層:在工具呼叫還沒跑完前,先猜測並提前執行後續步驟,事後再驗證是否可信,在三個橫跨秒級到分鐘級工具延遲的 benchmark 上分別加速 1.31x、1.35x、1.27x,4,010 筆稽核紀錄裡零誤判。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(尚未經同行審查) |
| 引用速度 | 發布 10 天,Semantic Scholar API 本輪持續回傳 429(rate limit),多次重試後仍無法取得引用數 |
| 機構 | 香港科技大學(多數作者);另有南京大學、阿卜杜拉國王科技大學、之江實驗室共同掛名 |
| 社群反應 | 未見於 HuggingFace Daily Papers 或 Papers with Code,社群訊號暫不明顯 |
| 可信度 | 通過 — 三個獨立 benchmark、4,010 筆稽核紀錄的正確性驗證、明確區分「實測」與「trace replay 估計」兩種數字 |
| 證據成熟度 | 較完整 — 多 benchmark 加敏感度分析,但樣本數不大(100/28/18 個任務),且部分 sandbox 並行度設定只是回放估計而非實測 |
| 可復現性 | 未提供 — 系統建構在開源 coding-agent 鷹架 Pi(v0.84.2)之上,但論文中未見 TomasuLLM 自身執行環境的程式碼釋出連結 |
| 為什麼選這篇 | 直接 — 直接處理 coding agent 實際部署時最常見的痛點:等待編譯、測試這類長時間工具呼叫 |
| 方向新意 | 實質增量 — 把處理器架構裡成熟的亂序執行概念,系統性地搬到 LLM Agent 的工具呼叫排程上,並設計對應的正確性驗證機制 |
| 今日重要性 | 中 — 對所有跑長時間工具鏈的 coding agent 都有感,但目前驗證規模偏小,還不到「馬上該採用」的程度 |
| 實務連結 | 明確 — 針對編譯、測試、repo 指令這類秒級到分鐘級延遲的工具呼叫,提供可量化的加速路線 |
| 編輯信心 | 中 — 足以支持「在測試的三個 benchmark 與有限樣本下,亂序投機執行能帶來可量測的加速且不犧牲正確性」這個限定主張,但樣本規模限制了外推信心 |
| 閱讀建議 | 略讀 — 對正在優化 coding agent 執行效率的工程團隊有參考價值,一般讀者抓核心機制即可 |
| 主要限制 | SWE-bench Verified 僅取 100 題、Terminal-Bench 2.0 28 題、SWE-Marathon 18 場,樣本數不大;部分 sandbox 並行度(16、32 slots)的加速數字是 trace replay 估計值,並非實際重跑測得 |
領域背景
Coding agent 的延遲常常不是卡在 LLM 生成本身,而是卡在等編譯器、測試套件、repo 指令跑完——這些工具呼叫可能要幾秒到幾分鐘,Agent 在這段時間完全閒置。這跟早期單核心處理器面對的問題很像:循序介面把可以提前做的工作都藏起來了。處理器設計後來靠亂序執行解決了這個問題,但要把同樣的點子搬到 Agent 身上,關鍵難題在於:投機執行的結果要怎麼驗證它沒有破壞任務的正確性。
中階導讀
- 問題:想像一個 coding agent 修完一個 bug 後要跑測試,測試要跑 2 分鐘。過去的做法是模型整個停在那裡等結果出來才決定下一步。但其實很多後續步驟(比如檢查另一個檔案、準備下一個修改)跟這次測試結果未必有關,完全可以先做。
- 方法:TomasuLLM 有兩個「猜測」步驟:Action Drafter 先猜下一步要呼叫什麼工具,不等它真的跑完,Observation Drafter 就接著猜這個工具會回傳什麼樣的結果,猜出來的結果當作下一輪猜測的暫時依據,讓好幾步可以連著先猜下去。每個猜測都在獨立的 copy-on-write 沙盒裡執行,系統用「運算元規則」判斷:一個工具呼叫如果它要讀的東西都已經確定存在,就可以立刻搶跑;如果要讀的東西還在等別的猜測步驟確定,就先準備好但等那個步驟真正落定才執行。最後所有結果按照原本的執行順序一一驗證、確認沒有踩到過時狀態,才正式提交——驗證沒過就整段重跑,不會讓錯的結果被採用。
- 為什麼重要:這代表 coding agent 不需要重新設計整個決策邏輯,只要在執行層加一層排程,就能把本來乾等的時間拿來做有用的提前工作,對所有長工具鏈的 Agent 系統都有參考價值。
深入要點
- 三個 benchmark 的加速倍率(對比循序執行的基準版本):100 題 SWE-bench Verified 任務 1.31x、28 個 Terminal-Bench 2.0 任務 1.35x、18 場 SWE-Marathon 連續會話 1.27x(以匹配進度衡量)
- 正確性驗證:4,010 筆經過稽核的 commit 驗證紀錄裡,零誤判(zero false accepts)——投機執行的安全性完全來自事後的驗證機制,不是靠猜得準
- 論文明確區分「實測」與「估計」兩種數字:在論文實際採用的設定(猜測鏈深度 K=6、8 個 sandbox 並行槽)下,SWE-Marathon 的敏感度分析實測加速達 2.05x;而 16、32 個並行槽位的數字是用錄下的依賴圖做 trace replay 估計出來的,作者坦白寫明「只有 8 個 slot 的點是真的跑出來的,其餘是估計」,原因是其 E2B 帳號上限就是 8 個並行沙盒
- 系統建構在開源 coding-agent 鷹架 Pi(v0.84.2)之上,把猜測鏈深度設為 0 時就是論文裡的「Serial Pi」基準版本,方便做公平對照
- 哪些動作會變成「投機障礙」(必須循序執行,不能搶跑)有明確定義:檔案編輯這類結果依賴於還沒讀到的內容的動作、服務重啟、checkpoint、最終提交
- Limitation:三個 benchmark 的任務數都偏小(100/28/18),作者也坦承部分並行度設定的加速數字只是依賴圖的回放估計,不是實際重跑測出來的
Reviewer 一句話評
把「猜測」與「驗證」拆得很乾淨,正確性完全綁在事後驗證而不是投機的準確度上,這個安全邊界設計得紮實;但三個 benchmark 的樣本數都不大,而且作者自己承認部分加速數字是依賴圖的回放估計而非實測,外推到更大規模部署前最好先看有沒有更大樣本的後續驗證。
給你的 take-away
- 如果你在優化 coding agent 的執行延遲:先盤點你的工具鏈裡有哪些是「秒級到分鐘級」的長延遲呼叫(編譯、測試、repo 指令),這類場景理論加速空間最大;TomasuLLM 的「運算元規則」(讀取已確定的東西才搶跑)是個可以直接參考的排程邏輯
- 如果你在設計投機執行類的系統:這篇示範了一個關鍵原則——投機結果不能本身就是正確性的證據,必須靠獨立的事後驗證機制(這裡是 Trace IR 驗證)才能保證安全,這個邊界劃分值得抄
論文三｜暴露模型身份,反而讓多 Agent 合作變差
Prompted Identity Degrades Cooperation in Multi-Agent LLM Systems Xavier Del Giudice, Alessio Palma, Matteo Migliarini et al.（羅馬大學 Sapienza） · arxiv: 2609.35928
TL;DR
讓多 Agent 系統裡的 Agent 知道彼此是哪個模型家族,即使任務完全沒有誘因要他們分邊站,群體還是會自動形成「自己人優先」的小圈圈;在純合作任務裡,知道身份的群組平均多花 30% 回合、55% token,成功率從 96% 掉到 81%。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(尚未經同行審查) |
| 引用速度 | 發布 4 天,Semantic Scholar API 本輪持續回傳 429(rate limit),多次重試後仍無法取得引用數 |
| 機構 | Sapienza University of Rome(羅馬大學) |
| 社群反應 | 未見於 HuggingFace Daily Papers 或 Papers with Code,社群訊號暫不明顯 |
| 可信度 | 通過 — 有未標記的排列基準(permutation baseline)、洗牌/錯誤標籤的因果控制組、跨任務與跨模型家族的重複驗證,每個配置跑 50 次並附 95% bootstrap 信賴區間 |
| 證據成熟度 | 較完整 — 兩個自設計合作賽局加一個有標準答案的推理 benchmark(GPQA-Diamond)交叉驗證,並用廣義線性模型排除賽局規模等干擾因素 |
| 可復現性 | 未提供 — 論文中未見程式碼或資料集釋出連結 |
| 為什麼選這篇 | 直接 — 直接處理跨供應商、混用多個模型家族的多 Agent 系統設計時會踩到的實際問題 |
| 方向新意 | 實質增量 — 首次系統性量化「身份標籤本身」(而非底層模型能力差異)如何獨立造成多 Agent 系統的協作成本 |
| 今日重要性 | 高 — 混用不同供應商模型的多 Agent 架構正快速普及,這個發現直接影響一個常見的設計選擇:要不要讓 Agent 看到彼此的身份metadata |
| 實務連結 | 明確 — 論文直接給出的緩解方法(不要把模型身份暴露進 Agent 互動的 context)可以立刻套用到正在設計的多 Agent 系統上 |
| 編輯信心 | 高 — 足以支持「在測試的合作賽局與推理 benchmark 下,暴露身份標籤本身會獨立於模型能力造成協作成本」這個限定主張 |
| 閱讀建議 | 必讀 — 所有在設計混用多供應商模型的多 Agent 編排系統的團隊 |
| 主要限制 | 只在最多 5 個開源模型家族、純文字、研究團隊自行設計的合作賽局中驗證;更大規模 roster、封閉模型與真實世界的 agentic workflow 是否重現同樣效果仍未測試 |
領域背景
隨著多 Agent 系統越來越常混用不同供應商的模型(例如一個協調者用某家模型,執行者用另一家開源模型),大家通常只關心「底層模型能力夠不夠強」,很少有人認真檢視「讓 Agent 知道彼此是哪個模型」這個看似無關緊要的 metadata 設計選擇,本身會不會帶來額外成本。社會學裡早就有「物以類聚」(homophily)的概念,描述人會更傾向跟跟自己相似的人互動,但這個現象是否會在純文字、沒有身份認同動機的 LLM Agent 群體裡自動出現,過去沒有受控實驗驗證過。
中階導讀
- 問題:想像你組了一個九到二十五人的 Agent 團隊,來自五種不同的開源模型家族,目標是合作完成一個任務,獎勵完全是團體共享的,沒有任何個人誘因。如果你讓每個 Agent 在互動時都看得到隊友的模型家族標籤,會發生什麼事?
- 方法:研究團隊設計了兩個純合作賽局和一個有標準答案的推理 benchmark,系統性地操弄 Agent 能不能看到彼此的身份標籤:完全不給標籤(控制組)、給真實標籤、把標籤打亂或換成跟真實架構無關的任意標籤。他們用「調整後互信息」(AMI)量化 Agent 實際互動形成的小圈圈,跟標籤分組的吻合程度有多高,並用統計模型比較三種條件下的回合數、token 消耗與成功率。
- 為什麼重要:結果顯示,只要 Agent 看得到身份標籤——即使是打亂過、跟真實模型架構完全對不上的任意標籤——小圈圈還是會照著標籤形成,拿掉標籤之後這個現象就消失了。這證明造成協作成本的是「標籤本身」,不是模型能力的真實差異,對任何打算混用多供應商模型的多 Agent 系統設計,這是一個可以直接避開的成本。
深入要點
- 核心統計量 AMI(調整後互信息,衡量實際互動小圈圈跟標籤分組的吻合程度,0 代表無關、1 代表完全吻合):完全不給標籤的 12 個實驗組,AMI 都落在 0.02–0.08 之間,接近隨機;給真實標籤的 24 個實驗組全數顯著,Exclusion 賽局 AMI 介於 0.55–0.76,Leader Election 賽局介於 0.24–0.53
- 關鍵因果證據:把標籤打亂、換成跟真實模型架構對不上的任意標籤後,小圈圈依然顯著跟著「打亂後的標籤」走(Leader Election AMI 0.18–0.35,Exclusion 0.55–0.69),證明是標籤本身而非底層能力差異在驅動分群
- 成本量化:在純合作任務裡,知道身份的群組平均多花 30% 回合、55% token 才能做出決策;具體到 Leader Election 賽局,回合數是未標記版本的 1.4 倍、token 消耗是 1.8 倍
- 成功率影響:純合作賽局的成功率從未標記版本的 96% 掉到標記版本的 81%
- 平衡與不平衡的模型家族人數配置下,陣營化效應強度相近,說明「數量上占多數」不是驅動陣營化的主因
- 用有標準答案的 GPQA-Diamond 推理 benchmark(搭配 Leader Election 互動協定)交叉驗證,同樣觀察到標籤誘發的協調成本,顯示這個現象不只侷限在研究團隊自己設計的賽局裡
- Limitation(論文第 5 節原文):研究範圍限定在最多 5 個開源模型家族、純文字、研究團隊自行設計的合作賽局(因為沒有現成 benchmark 同時滿足「無個人誘因」與可控評測這兩個條件);更大規模的團隊、封閉模型、不同解碼設定與更豐富的真實 agentic workflow 是否重現同樣效果仍未測試
Reviewer 一句話評
用「打亂標籤仍然誘發分群、拿掉標籤分群就消失」這個因果操弄排除了「其實是底層模型能力差異在作祟」的替代解釋,是這篇在因果推論上最紮實的地方;但研究範圍限定在開源模型、純文字、自行設計的合作賽局,距離「這在所有真實多 Agent 產品裡都成立」還有一段距離,作者自己對此也很誠實。
給你的 take-away
- 如果你在設計混用多供應商模型的多 Agent 系統:檢查一下你現在的 prompt 或系統架構有沒有把模型供應商、模型名稱這類身份 metadata 暴露進 Agent 彼此看得到的互動 context——論文的建議很直接:這類 metadata 可以留給上層的協調器用來路由與稽核,但不必讓 Agent 之間互相看到
- 如果你在評估多 Agent 系統的效能瓶頸:除了檢查個別模型的能力,也該檢查一下系統裡會不會有其他「看似無關的 metadata」在悄悄拖慢協作效率,這篇提供了一個可以直接套用的檢驗方法(拿掉某個 metadata,看協作成本有沒有下降)
今日收穫
之前以為多 Agent 系統效能差,多半是模型能力不夠強或 prompt 設計不夠好;今天這篇 Sapienza 的研究讓我意識到,連「要不要讓 Agent 看到彼此是哪個模型家族」這種看起來跟任務完全無關的 metadata 設計選擇,都可能悄悄決定合作成敗——而 DAGent 跟 TomasuLLM 從另外兩個角度補上同一個教訓:規劃該邊做邊長而不是一次賭定,執行該在等待時間裡偷跑有用的工作,這些效能與可靠度的增益,往往不在換更強的模型,而在你怎麼設計 Agent 之間、Agent 與工具之間的這些介面細節裡。
參考資料
- DAGent: Evaluate-then-Grow Planning for Deep Research Agents
- DAGent — alphaxiv
- DAGent — 官方程式碼
- TomasuLLM: Out-of-Order Speculative Execution for LLM Agents
- TomasuLLM — alphaxiv
- Prompted Identity Degrades Cooperation in Multi-Agent LLM Systems
- Prompted Identity Degrades Cooperation — alphaxiv
- HuggingFace Daily Papers
Loading...