AI Agent Arxiv Digest — 2026-10-04

🌏 English version

今日總覽

今天三篇論文,從三個不同位置戳破「Agent 表現如你所見」這個假設。APEX 證明 Agent Skill 之間的交接記錄可以被偷換成一句假的使用者核准,讓 Agent 在原始任務驗證分數幾乎不變的情況下,悄悄做出你沒同意的事。Agents Are Systems, Not Models 用 8,640 次重複執行證明,同一組設定跑出來的分數裡,將近一半是噪音,不是設定本身的效果——這代表你平常看到的「單次跑分」可能什麼都說明不了。Mem++ 則是從記憶系統設計的角度,示範「在寫入時就用 LLM 把文件壓縮成事實」這個主流做法本身就有代價,把文件原封不動存起來、讓讀取時的檢索決定答案,反而在組織記憶場景裡贏過好幾個既有系統。三篇合起來說的是同一件事:你以為看得到的 Agent 表現——驗證分數、benchmark 分數、記憶系統的「智慧」——中間都藏著沒被講清楚的假設,拆開來看才知道能不能信。

讀這篇前該知道的詞

詞	白話解釋
Agent Skill	讓 Agent 讀取並遵循的一包可重複使用的任務指引(如 SKILL.md),可以公開分享、組合使用,類似外掛的任務說明書
攻擊成功率(ASR)	攻擊讓 Agent 做出攻擊者想要的行為的比例;ASR 74.2% 代表每十次嘗試有七到八次得手
鷹架(Harness)	包著模型的執行迴圈與基礎設施,負責呼叫工具、管理上下文——模型只是鷹架裡的一個零件
寫時蒸餾 vs 讀時選擇	寫時蒸餾是文件存進記憶系統那一刻就用 LLM 壓縮成事實或摘要;讀時選擇是文件原封不動存好,等有人問問題時才決定要用哪一份
校準誤差(Calibration Error)	Agent 自己預測的分數跟實際分數的落差;正值代表 Agent 高估了自己做得多好
加權排序融合(RRF)	把多個檢索結果的排名(而非原始分數)依權重合併成一個排名的方法,不需要把不同系統的分數校準到同一個尺度

---

論文一｜技能鏈怎麼把 Agent 的「已完成」偷換成「已核准」

Chaining Skills to Hijack LLM Agents Tian Dong, Zixuan Ma, Haodong Zhao et al.(香港大學,另有山東大學、上海交通大學、東南大學共同掛名)　·　arxiv: 2610.01564

連結: arxiv · alphaxiv

TL;DR

APEX 讓上游技能誘導 Agent 寫下一筆「任務已完成且已獲核准」的記錄,下游技能再依這筆記錄執行攻擊者選定的動作;在 SkillsBench 上橫跨六個模型的 24 種組合,攻擊成功率都超過 50%,GPT-5.4 上整條鏈達 84.3%,而原始任務的驗證分數平均只變動 2.6 個百分點。

編輯判斷

面向	判斷
Venue	arXiv preprint(cs.CR 交叉 cs.AI,未經同行審查)
引用速度	發布 3 天,Semantic Scholar API 本輪持續回傳 429(rate limit),無法取得引用數
機構	香港大學(主要作者)、山東大學、上海交通大學、東南大學
社群反應	未見於 HuggingFace Daily Papers;論文內文僅提及內部補充腳本,未見公開 GitHub repo
可信度	通過 — 六個模型、四種定向攻擊家族加一種資源耗用攻擊、690 次嘗試,附正式的交接資訊理論分析與消融實驗
證據成熟度	較完整 — 多模型多家族實驗加形式化證明與防禦評估,但仍是 SkillsBench 模擬環境,不是真實事件
可復現性	部分產物 — 論文宣稱有補充資料與重現腳本,但未見公開連結
為什麼選這篇	直接 — 直指 Agent Skill 供應鏈(如 Claude Skills、各類技能市集)快速擴張下最容易被忽略的交接漏洞
方向新意	實質增量 — 把「任務進度記錄」本身設計成可以偷渡假核准的載體,並給出交接資訊不足以判斷核准與否的正式邊界證明
今日重要性	高 — Agent Skill 生態正快速成長,這類攻擊面幾乎沒有人在系統性檢查
實務連結	明確 — 任何允許 Agent 載入第三方技能、讓技能之間透過檔案或記錄交接資訊的系統都適用
編輯信心	高 — 足以支持「在此威脅模型與測試環境下,技能鏈可以在原生驗證分數幾乎不變的情況下誘發高比例的非預期動作」這個限定主張
閱讀建議	必讀 — 正在建置或接入 Agent Skill 生態的團隊
主要限制	論文按實驗條件而非逐次執行回報結果,因此高原生效用分數不保證每一次攻擊成功時任務本身仍有用(附錄 A 原文自承)

領域背景

Agent Skill 讓使用者和開發者把重複性的任務指引打包成可分享、可組合的說明書,一個任務常常會依序呼叫好幾個技能,前一個技能寫下的東西會變成下一個技能讀到的上下文。過去的研究(ColluSkill、CompoSkill、SCR-Bench)已經注意到多技能組合可能繞過單一技能的安全掃描,但這些研究都沒有問一個更實際的問題:當技能鏈真的被攻擊時,Agent 在使用者眼裡原本要做的那件事,到底還完成了多少。

中階導讀

• 問題:想像你請 Agent「幫我把這份報告整理成摘要,但保留原始檔案」。一個惡意技能可以引導 Agent 在做完摘要後,順手寫一筆記錄說「摘要已完成,原始檔案已核准可以清理」——這筆記錄看起來就是任務進度的正常副產品,下一個技能讀到它,就依記錄把原始檔案刪了。使用者收到了摘要,卻也違反了「保留原始檔案」的指示。
• 方法:APEX 分成生成與驗證兩階段。生成階段先找出 Agent 能完成的真實工作,再設計上游指示讓 Agent 把這份工作、連同攻擊者想要的下一步,一起寫進一筆記錄;下游指示則引導 Agent 依這筆記錄去執行攻擊者選定的動作。每個候選鏈都在隔離環境裡實際跑過,系統會區分「鏈根本沒接上」跟「接上了但 Agent 不聽」兩種失敗,據此只修正該修的那一段指示。論文還給出兩個正式結果:一是當「核准」與「禁止」兩種情境在 Agent 看到的本地資訊裡長得一樣,任何只靠這份資訊做判斷的規則,假核准與假拒絕的機率加起來一定逼近百分之百;二是针对會讓 Agent 反覆回頭做更多工作的攻擊,用有限狀態模型算出重複造訪某個節點對整體 token 成本的邊際影響。
• 為什麼重要:這代表「原始任務的驗證分數沒有明顯下降」這個訊號,完全沒辦法用來確認 Agent 沒被劫持——攻擊者可以讓 Agent 又完成摘要、又執行了你不想要的刪除動作。對任何允許載入第三方技能的系統,這是一個目前幾乎沒人在系統性檢查的攻擊面。

深入要點

• 四個定向動作家族加一個資源耗用家族(Work Loop),橫跨六個模型的 24 種組合,攻擊成功率全數超過 50%,範圍在 54.8%–90.3%(整體 512/690,74.2%)
• GPT-5.4 上整條鏈達 84.3% 攻擊成功率,相比之下把攻擊目標直接寫進單一技能的「直接注入」只有 3.5%,把整個工作流程合併成一個技能的「單一技能」版本只有 17.4%
• 原始任務驗證分數變動幅度小:GPT-5.4 全部四個家族平均只變動 2.6 個百分點,Output Tampering 家族甚至從 90.4% 只掉到 89.6%,ASR 卻高達 90.3%
• Work Loop 資源耗用攻擊讓每任務平均 token 用量來到原生基準的 2.20 倍到 36.39 倍,Claude Sonnet 5 上 21.33 倍的 token 用量伴隨效用從 78.8% 掉到 42.5%,但 Kimi K2.6 上 36.39 倍的 token 用量卻只掉了一點效用,顯示資源耗用跟效用下降不是同一件事
• 作者評估的「request-checking」提示式防禦,把 GPT-5.4 上的攻擊成功率從 84.3% 壓到 59.1%,但同時讓 72 個良性原生技能任務的驗證通過率從 86.7% 掉到 56.3%
• Limitation(附錄 A 原文):結果按實驗條件而非逐次執行回報,無法從條件層級的高效用分數推論每一次成功攻擊都保留了有用工作;同一任務可能同時出現在多個攻擊家族裡,各家族的評估不應視為獨立觀察

Reviewer 一句話評

威脅模型與正式分析做得紮實,「交接資訊不足以判斷核准」這個邊界證明是這篇最站得住的貢獻;但評估按條件彙總而非逐次對照,讀者要留意「效用分數沒掉」不等於「這次攻擊沒有破壞任何東西」,而且目前只驗證了作者自己設計的威脅模型,沒有測試會針對這個防禦調整策略的攻擊者。

給你的 take-away

• 如果你在建置允許載入第三方 Agent Skill 的系統:不要只用原始任務的驗證分數判斷系統是否安全,要單獨檢查技能之間交接的檔案或記錄是否被用來冒充使用者核准——這是驗證分數完全看不出來的攻擊面
• 如果你在設計跨技能的狀態交接機制:這篇的正式結果給了一個檢驗標準——如果你的核准判斷只看得到技能交接時的本地資訊,而核准與禁止的情境在那份資訊裡看起來一樣,這個判斷機制理論上就擋不住這類攻擊,需要讓判斷邏輯接觸到原始使用者請求本身

---

論文二｜Agent 是一套系統,不是一個模型:同一組設定重複跑,一半的分數差異是噪音

Agents Are Systems, Not Models: Rethinking Agentic Evaluation Luis Wiedmann, Leander Girrbach, Cordelia Schmid, Zeynep Akata(慕尼黑工業大學 / MCML / Helmholtz Munich,另有 Inria、巴黎高等師範學院、CNRS、PSL 研究大學共同掛名)　·　arxiv: 2610.01618

連結: arxiv · alphaxiv

TL;DR

在四個需要操作專家模型的科學任務上,跑了 432 種設定組合、每種重複 5 次、總計 8,640 次執行後發現,光是重複跑同一組設定,分數的變異裡就有約 54% 是噪音;而五個可調的設定維度裡,「給 Agent 多少資訊」的影響力超過模型大小與時間預算。

編輯判斷

面向	判斷
Venue	arXiv preprint(cs.AI,未經同行審查)
引用速度	發布 3 天,Semantic Scholar API 本輪持續回傳 429(rate limit),無法取得引用數
機構	慕尼黑工業大學 / MCML / Helmholtz Munich(主要作者),Inria、巴黎高等師範學院、CNRS、PSL 研究大學(Cordelia Schmid)
社群反應	未見於 HuggingFace Daily Papers;GitHub repo 已建立但目前僅有 README,作者承諾釋出程式碼與 18,240 筆執行軌跡
可信度	通過 — 432 種設定組合 ×5 次重複 ×4 個任務的完整因子設計,附跨模型家族、開源與封閉模型的消融實驗
證據成熟度	較完整 — 大規模重複實驗專門用來量化變異,而非只看單點分數;但只涵蓋天文與基因體學兩個科學領域的四個任務,作者自己也點出排除了記憶與多 Agent 協作這兩個設定維度
可復現性	部分產物 — 作者承諾釋出程式碼、benchmark 與 18,240 筆執行軌跡,GitHub repo 已建立但撰稿時尚未放上程式碼
為什麼選這篇	直接 — 直接挑戰「單次跑分可以代表 Agent 表現」這個幾乎所有 benchmark 報告都在做的假設
方向新意	實質增量 — 用完整因子設計系統性拆解五個設定維度的效果與交互作用,並建立對應的大型執行軌跡資料集與行為分類體系
今日重要性	高 — 直接改變讀者該怎麼解讀自己每天看到的其他 Agent benchmark 分數
實務連結	明確 — 給出可直接套用的優先順序建議(先給資訊,再加預算,再換更大模型),並指出自我驗證這種行為更該做在系統裡而不是提示詞裡
編輯信心	高 — 54% 噪音這個核心數字直接來自重複執行設計本身,是這類主張能拿到的最直接證據
閱讀建議	必讀 — 任何在建置或評估 Agent 系統的人
主要限制	只涵蓋天文與基因體學兩個科學領域的四個任務;「系統設計比提示詞更能改變行為」這個結論只在自我驗證這一個行為維度上驗證過,作者明確說還不能當作通用原則

領域背景

近來的 Agent 評測研究已經開始主張不能只看單一成功率,要同時報告成本、一致性與穩健性,但這些研究通常把 Agent 本身當成固定不變的東西來評。實際上一個 Agent 是模型加上鷹架組成的系統,使用者可以決定給它多少資訊、要不要保留推理過程、要不要要求它自我驗證、給多少時間、用哪個骨幹模型——每一個選擇都可能改變表現與可靠度,但過去很少有研究系統性拆解這些選擇各自的效果與彼此的交互作用。

中階導讀

• 問題:想像你讀到一篇 benchmark 報告說「我們的 Agent 在這個任務上拿到 70 分」。這個分數有多可信?如果同一個團隊、同一組設定,換一天重新跑一次,會不會變成 50 分或 85 分?如果會差這麼多,那「70 分」這個數字本身能告訴你多少事?
• 方法:研究團隊設計了四個需要操作天文學與基因體學專家模型的科學任務,系統性調整五個設定維度——給多少資訊、是否保留推理過程、要求多強的自我驗證、給多少時間預算、用多強的骨幹模型——組成 432 種設定,每種重複跑 5 次,總共 8,640 次執行。他們把分數的變異拆成「設定造成的差異」跟「同一設定重複跑的噪音」兩部分,並進一步分析哪個維度影響最大、維度之間會不會互相影響。
• 為什麼重要:如果連在完全固定的設定下重複執行,分數都有一半的變異是噪音,那麼任何沒有報告重複次數與變異程度的單次 benchmark 分數,讀者都該打上問號。而「給 Agent 更多資訊」這個維度不只分數更高,還同時降低成本、縮短執行時間、讓 Agent 對自己表現的預估更準——這是少見的「沒有取捨」的改善方向,值得優先投入。

深入要點

• 核心發現:即使只看「真的有認真嘗試」的執行(排除明顯擺爛的),同一組設定重複跑出來的分數變異裡,約 54% 是純粹的執行間噪音;若把所有執行都算進去(不排除擺爛的),噪音佔比更高,設定造成的差異只能解釋 39.4% 的變異(相對於排除擺爛執行後的 46.1%)
• 五個設定維度依效果大小排序:「給多少資訊」在四個任務上都排第一,且在至少 99% 的 bootstrap 重抽樣裡維持第一;平均而言「是否保留推理過程」排第二,「時間預算」第三,「自我驗證要求」敬陪末座
• 維度會互相影響:對小型與中型模型,加長時間預算會提高完成率卻拉低分數;對大型模型,加長時間預算同時提高完成率與分數——代表多給時間只有在 Agent 已經知道該做什麼或模型夠強時才有用
• 「給多少資訊」同時改善三件事,沒有取捨:分數更高、成本更低、校準誤差更小,其中資訊給到最完整的「協定」層級時,校準誤差的平均值與離散程度都明顯下降
• 用提示詞要求 Agent 自我驗證,幾乎不影響它實際的驗證行為(從「無要求」到「強制要求」,採用參照答案驗證的比例只從 19% 升到 22%,約四分之三的執行仍只檢查格式);但給 Agent 一個可以直接查分的工具(oracle),採用參照答案驗證的比例在每個提示詞層級下大約三倍,顯示這類行為更該由系統提供,而不是靠提示詞要求
• 在專家模型其實已經弱於骨幹模型的任務(mmlu-astronomy)上,99.8% 的執行仍然選擇使用這個較弱的專家模型,即使給了可以直接查分的 oracle 工具,表現也沒有明顯提升
• Limitation(第 6 節原文):分析涵蓋超過 18,000 筆執行軌跡,但僅限於兩個科學領域的四個任務;排除了記憶與多 Agent 協作這些額外的系統組成部分;「系統設計比提示詞更能改變行為」只在自我驗證這一個維度上驗證過,尚不能當作通用原則

Reviewer 一句話評

用完整因子設計加重複執行來專門量化噪音,是這篇最扎實也最少見的設計——大部分 Agent 評測論文連「重複跑同一組設定會差多少」都沒有報告;但範圍限定在兩個科學領域的四個任務,而且核心的「系統設計 > 提示詞」結論目前只在自我驗證這一個行為上驗證,離通用原則還有一段距離,作者自己也這樣提醒。

給你的 take-away

• 如果你在讀任何一份 Agent benchmark 報告(包括這個系列過去寫過的單次跑分比較):先問它有沒有報告重複執行的次數與變異程度;沒有的話,這個分數的可信度就該打上問號,因為同一組設定重複跑出來的差異可能跟設定本身的效果一樣大
• 如果你在設計 Agent 系統的優先順序:先確保給 Agent 足夠的任務資訊(如何操作工具、該用什麼協定),再考慮加大時間預算,最後才是換更強的骨幹模型——而像「自我驗證」這類你希望 Agent 做到的行為,直接做成系統裡的工具(例如一個可查分的驗證介面),比寫在提示詞裡要求更有效

---

論文三｜組織記憶不該在寫入時就把文件壓扁

Mem++: Non-Destructive Memory for Long-Term Organizational LLM Agents Ahmad Yehia, Aly O. Abdelkareem, Islam Ahmed et al.(德州大學奧斯汀分校,另有 AIDAChip Inc. 共同掛名)　·　arxiv: 2610.02002

連結: arxiv · alphaxiv

TL;DR

Mem++ 把文件原封不動存起來,寫入時不呼叫任何 LLM,等到有人提問時才用加權排序融合從完整記錄裡選出答案;在組織記憶 benchmark OrgMemBench 上,這個設計比最強的既有記憶系統基線高 8.0–13.1 分,但在「矛盾辨識」與「跨時間推理」兩個類別上仍輸給傳統 RAG。

編輯判斷

面向	判斷
Venue	arXiv preprint(cs.CL 交叉 cs.AI,未經同行審查)
引用速度	發布 3 天,Semantic Scholar API 本輪持續回傳 429(rate limit),無法取得引用數
機構	德州大學奧斯汀分校、AIDAChip Inc.(新創公司)
社群反應	未見於 HuggingFace Daily Papers;官方 GitHub repo 已公開,附完整架構說明與使用方式
可信度	通過 — 正式架構定義、七個基線、三個 benchmark、兩種回答模型,附消融實驗與「哪裡輸了」的透明揭露
證據成熟度	初步 — 方法與消融說明清楚,但組織記憶這個核心主張只靠 73 道題目、一個虛構機構的 benchmark 支撐,整體分數也只比 RAG 高 2.6 分,且在矛盾與跨時間推理兩類上輸給 RAG
可復現性	部分產物 — benchmark 評估程式碼已公開,完整系統宣稱「發表後釋出」,撰稿時尚待確認
為什麼選這篇	直接 — 直接給出一個組織記憶系統的架構選擇:要不要在寫入時就用 LLM 把文件壓縮
方向新意	應用改寫偏實質增量 — 把「記憶系統該在寫入還是讀取時做判斷」重新定義為一個明確的架構選擇,並用消融實驗證明寫入時的 LLM 呼叫對結果沒有穩定貢獻
今日重要性	中 — 對正在建置長期或多作者記憶系統的團隊有直接意義,但驗證規模偏小,還不到「這就是最佳架構」的程度
實務連結	明確 — 給出可直接套用的設計原則(不要在寫入時用 LLM 壓縮,原封不動存好,讀取時留幾個名額給最新文件)
編輯信心	中 — 足以支持「在測試的組織與對話 benchmark 上,保留原文並延後到讀取時選擇,優於既有的寫時蒸餾方法」這個有保留的主張,但 73 題的小型合成 benchmark 加上部分類別輸給 RAG,語氣需要收斂
閱讀建議	略讀 — 一般讀者;必讀 — 正在建置多作者組織記憶系統的團隊
主要限制	組織記憶這個核心評測只靠 73 道題目、一個虛構組織撐起來,作者自己在結論裡承認這點,並表示未來要蒐集更多元的真實組織記錄

領域背景

現有的 Agent 記憶系統大多是為「對話記憶」設計的:一個人跟 Agent 聊天,後面說的話是對前面說的話的更新,所以把舊的事實覆蓋掉是合理的。但組織記憶不一樣——決策是由很多不同的人,透過信件、工單、會議紀錄分別寫下的,而且一個決定被修改時,通常是多一份新文件,不是去編輯舊文件。既有系統(Mem0 靠覆蓋解決衝突、Zep 用帶日期的知識圖譜但只存抽取出來的事實)都在寫入文件的那一刻就做了結構化的選擇,這代表「這個問題能不能被回答」在任何問題被問出來之前就已經被決定了。

中階導讀

• 問題:想像一個組織裡,三月定了一個政策,六月修改過,九月又推翻了——三份文件都還留著,因為沒有人會回頭把舊文件刪掉。現在有人問「六月的修改版本當時的理由是什麼」,記憶系統要怎麼回答?如果寫入時就把每份文件蒸餾成幾條事實,六月版本的理由、條件、核准過程這些細節很可能在蒸餾過程裡就不見了。
• 方法:Mem++ 把每份文件整份原封不動存起來,附上日期跟作者,寫入時不呼叫任何生成模型。回答問題時,系統先依問題裡的「截止日期」篩出在那個時間點之前有效的文件,再用三個索引(字面比對、作者標籤、語意向量)各自排序候選文件,最後用加權排序融合把三份排名合併,其中留幾個名額保留給日期最新、確實匹配的文件。選版本這件事完全留給最後讀到這些文件的回答模型,系統本身不做任何推論。
• 為什麼重要:這代表「記憶系統要在寫入時就想辦法結構化」這個幾乎所有既有系統(Mem0、Zep、HippoRAG、GraphRAG)共同的假設,在組織記憶這個場景裡不一定成立。保留原文、把判斷延後到讀取時,反而讓系統能回答「這個決定取代了什麼」「誰核准的」這類需要原始脈絡的問題。

深入要點

• 在 OrgMemBench(443 份文件、157 條討論串、跨 18 個月、73 道題目)上,Mem++ 用 gpt-4.1-mini 回答時整體得分 57.6,比最強基線 RAG 的 55.0 高 2.6 分,比 A-Mem 高 13.1 分;用 gpt-4o-mini 回答時,帶知識圖譜的 Memg++ 變體以 44.4 分第一,Mem++ 以 44.2 分第二,都領先 RAG 的 43.4 分
• 「版本取代」(Supersession)題型上,Mem++ 兩種回答模型都拿下最高分(67.7 與 57.0),作者認為這是因為每份原始文件連同日期都還留在儲存裡,相對地 Mem0 靠覆蓋解決衝突,在這個題型上只拿到 40.8 與 32.3 分
• Mem++ 並非全面領先:在「矛盾辨識」題型上,RAG 比 Mem++ 高 27.4–28.2 分;在「跨時間推理」題型上,gpt-4.1-mini 回答時 RAG 也比 Mem++ 高 16.7 分;所有方法在「因果鏈追溯」題型上都低於 23 分
• 消融實驗顯示,拿掉寫入時的「整併」步驟或「抽取事實卡」步驟,分數幾乎不變,證明 Mem++ 的表現不靠寫入時的 LLM 呼叫;拿掉語意向量這個檢索通道,在 OrgMemBench 上掉 35.7 分、在 LongMemEval_S 上掉 76.0 分,是三個檢索通道裡影響最大的
• 在對話記憶 benchmark LoCoMo 上,Mem++ 用 gpt-4.1-mini 達到平均 81.5 分,比既有方法 Nemori 高 2.1 分;在「跨時間推理」子項目上贏 Nemori 3.8–5.9 分,作者認為是因為保留了幾個名額給最新日期的文件
• Limitation(結論原文):組織記憶這個核心評測只靠 OrgMemBench 中層規模的 73 道題目撐起來,目前公開的組織記憶 benchmark 本就不多;作者表示未來要收集更多元的真實組織記錄來驗證

Reviewer 一句話評

「寫入時不做任何結構化,把判斷留到讀取時」這個設計原則講得清楚,消融實驗也誠實地指出圖譜擴充帶來的增益不穩定、矛盾辨識輸給 RAG;但組織記憶這個核心場景只驗證在 73 題的單一合成 benchmark 上,2.6 分的領先margin也不算大,距離「這就是組織記憶該用的架構」還需要更多元的真實資料驗證。

給你的 take-away

• 如果你在建置多作者、長期累積的組織記憶系統(例如跨部門決策紀錄、客服歷史記錄):先問自己「寫入時有沒有呼叫 LLM 把文件壓縮成事實或摘要」,如果有,考慮改成原封不動存好、讀取時再依問題的時間範圍篩選——這篇的消融實驗顯示寫入時的 LLM 呼叫未必帶來穩定的額外準確率
• 如果你在評估現有記憶系統:特別檢查「版本取代」「稽核回放」這類需要知道「這個決定取代了什麼、誰核准的」的題型,而不只是看整體分數——這是寫時蒸餾類系統最容易丟失資訊的地方,也是最能看出架構差異的地方

---

今日收穫

之前以為 Agent 系統的風險主要在模型本身夠不夠聰明、記憶系統夠不夠智慧;今天這三篇讓我意識到,更根本的風險常常藏在「你以為可以信任的訊號」裡——驗證分數可能在 Agent 被劫持時完全沒反應,單次跑出來的 benchmark 分數裡一半可能是噪音,而「記憶系統在寫入時就幫你想好一切」這個聽起來很貼心的設計,反而可能在你最需要原始脈絡的時候讓答案消失。三篇要讀者做的事其實是同一件:把「看起來正常」的分數跟系統行為拆開來看,才知道哪些是真訊號。

參考資料

• Chaining Skills to Hijack LLM Agents
• Chaining Skills to Hijack LLM Agents — alphaxiv
• Agents Are Systems, Not Models: Rethinking Agentic Evaluation
• Agents Are Systems, Not Models — alphaxiv
• Agents Are Systems, Not Models — 官方程式碼與執行軌跡
• Mem++: Non-Destructive Memory for Long-Term Organizational LLM Agents
• Mem++ — alphaxiv
• Mem++ — 官方程式碼
• arXiv cs.MA 2026-10-02 公告批次