AI代理的崩潰方式與傳統(tǒng)軟件完全不同——沒有堆棧跟蹤，沒有報(bào)錯(cuò)彈窗。它們悄無聲息地失效：返回殘缺答案、卡在慢API里無限等待、或者瘋狂重復(fù)調(diào)用同一工具燒光token預(yù)算。表面一切正常，輸出卻錯(cuò)了、晚了、貴了。

AWS團(tuán)隊(duì)最近開源了一套診斷方案，用可運(yùn)行的代碼演示三種最隱蔽的故障模式。每個(gè)demo都帶前后對(duì)比數(shù)據(jù)，代碼地址：github.com/aws-samples/sample-why-agents-fail。

技術(shù)?；赟trands Agents + GPT-4o-mini，但設(shè)計(jì)模式通用——LangGraph、AutoGen、CrewAI任何支持工具調(diào)用和生命周期鉤子的框架都能復(fù)用。

第一種故障：上下文窗口溢出。當(dāng)工具返回的數(shù)據(jù)量超過LLM處理能力時(shí)——服務(wù)器日志、數(shù)據(jù)庫查詢結(jié)果、大文件內(nèi)容——代理不會(huì)報(bào)錯(cuò)，而是靜默降級(jí)：截?cái)鄶?shù)據(jù)、丟失上下文、輸出殘缺。IBM一項(xiàng)材料科學(xué)研究為此付出了慘痛代價(jià)：同一工作流裸跑消耗2000萬token后失敗，改用內(nèi)存指針方案后僅用1234token成功。

解法叫"內(nèi)存指針模式"：大數(shù)據(jù)存進(jìn)agent.state，只返回短指針給上下文。后續(xù)工具解析指針獲取完整數(shù)據(jù)。AWS的代碼示例很直觀——fetch_application_logs檢測到日志超20KB時(shí)，生成指針"logs-payment-service"（52字節(jié)），而非把200KB原始數(shù)據(jù)塞進(jìn)LLM視野。analyze_error_patterns再通過指針調(diào)取，LLM全程只看見那52字節(jié)。

Strands Agents的ToolContext API在這里關(guān)鍵：agent.state是原生鍵值存儲(chǔ)，作用域隔離到單個(gè)代理，無需全局字典或外部基礎(chǔ)設(shè)施。多代理場景下，invocation_state支持Swarm內(nèi)跨代理共享，API完全一致。

完整demo已開源。這1234token vs 2000萬token的差距，本質(zhì)是"讓LLM指揮，別讓LLM搬運(yùn)"的設(shè)計(jì)哲學(xué)。