IBM去年測過一個材料科學(xué)工作流：工具輸出200萬條數(shù)據(jù)，傳統(tǒng)方法燒了2082萬token直接崩掉。同一套流程換成內(nèi)存指針，只用了1234token。這不是優(yōu)化，是16000倍的差距。

AI代理的上下文窗口溢出，正在以靜默的方式殺死你的任務(wù)。代理不會報錯，它只是悄悄截斷數(shù)據(jù)、丟失上下文、給你一份殘缺的答案。等你發(fā)現(xiàn)時，token已經(jīng)燒完了，時間也浪費了。

問題：大工具輸出正在撐爆LLM的"短期記憶"

想象你讓代理分析一份200KB的服務(wù)器日志。工具返回完整數(shù)據(jù)，塞進對話歷史，LLM的上下文窗口瞬間填滿。更麻煩的是，為了塞進這些數(shù)據(jù)，代理必須把更早的上下文——包括你最初的問題——擠出去。

結(jié)果就是：LLM手里拿著日志，卻忘了你要它找什么?；蛘咚緵]拿到完整日志，只看到被截斷的片段。IBM的研究人員把這叫"靜默降級"：代理看起來在跑，產(chǎn)出卻是錯的。

社區(qū)里有個說法很扎心：團隊都是"以艱難的方式"發(fā)現(xiàn)這個限制的。Airbyte今年的觀察報告指出，這種錯誤不會拋異常，只會讓你拿到不完整或錯誤的結(jié)果，排查起來像大海撈針。

解法一：單代理的ToolContext，把數(shù)據(jù)存在"抽屜"里

Strands Agents提供了一個原生方案：agent.state。這是一個鍵值存儲，每個代理實例獨享。工具把大數(shù)據(jù)寫進去，返回的只是一個輕量指針。

具體怎么跑？代理調(diào)用日志分析工具，工具把200KB日志塞進state，返回"日志已存儲，ID: log_001"。LLM看到的只有這一行，上下文窗口壓力驟減。需要具體分析時，另一個工具再憑ID去state里取對應(yīng)片段。

這相當(dāng)于給LLM配了一個外部抽屜。它不用把所有文件攤在桌面上，只需要知道"第3個抽屜里有我要的東西"。

但單代理有個天花板：復(fù)雜任務(wù)需要多個角色協(xié)作，一個代理的state成了孤島。

解法二：多代理的Swarm模式，指針在代理間流通

Amazon 2024年的研究驗證了更激進的思路。他們在多代理協(xié)作中引入"payload referencing"——代理之間不傳原始數(shù)據(jù)，只傳指針。代碼密集型任務(wù)性能提升23%，企業(yè)基準(zhǔn)測試?yán)锒说蕉四繕?biāo)成功率沖到90%。

Strands的Swarm模式把這個落地了。多個代理共享一個分布式狀態(tài)層，每個代理都能讀寫。數(shù)據(jù)分析師代理把清洗后的數(shù)據(jù)集寫進去，返回指針；可視化代理拿這個指針直接畫圖，全程不碰原始數(shù)據(jù)。

IBM那個16000倍的案例，核心就在這里：145KB的數(shù)據(jù)從未進入任何LLM的上下文窗口。代理們只是在傳遞一個地址，像快遞柜的取件碼。

為什么現(xiàn)在才流行？指針模式有個隱性成本

這個模式不是新發(fā)明，但以前用的人少。原因很簡單：它增加了系統(tǒng)復(fù)雜度。你需要狀態(tài)管理層、指針生命周期管理、代理間的協(xié)調(diào)協(xié)議。小團隊寧愿燒token，也不愿維護這套基礎(chǔ)設(shè)施。

現(xiàn)在的變化是，agent框架開始原生支持。Strands的state和Swarm、LangGraph的持久化層、AutoGen的上下文管理——這些把"造輪子"的成本打下來了。框架幫你處理了指針失效、并發(fā)寫入、狀態(tài)隔離這些臟活。

另一個推手是token經(jīng)濟學(xué)的殘酷。Claude 3.5 Sonnet的200K上下文窗口聽起來很大，但真塞200KB原始日志進去，推理成本和時間都扛不住。指針模式把"能處理"變成"能高效處理"，差距就在賬單上。

代碼已經(jīng)開源在AWS Samples倉庫。演示用的是Strands，但模式本身框架無關(guān)。LangGraph的checkpoint、AutoGen的GroupChat都能復(fù)現(xiàn)這個思路。

IBM研究人員在論文里埋了一個細節(jié)：他們用指針模式跑通的那個材料科學(xué)工作流，之前用傳統(tǒng)方法連完整跑完都做不到。不是慢，是根本不可能。這個邊界案例暴露了上下文窗口溢出的真實代價——它不只是貴，它讓某些任務(wù)徹底無解。