北京
AI代理的崩溃方式与传统软件完全不同——没有堆栈跟踪，没有报错弹窗。它们悄无声息地失效：返回残缺答案、卡在慢API里无限等待、或者疯狂重复调用同一工具烧光token预算。表面一切正常，输出却错了、晚了、贵了。
AWS团队最近开源了一套诊断方案，用可运行的代码演示三种最隐蔽的故障模式。每个demo都带前后对比数据，代码地址：github.com/aws-samples/sample-why-agents-fail。
技术栈基于Strands Agents + GPT-4o-mini，但设计模式通用——LangGraph、AutoGen、CrewAI任何支持工具调用和生命周期钩子的框架都能复用。
第一种故障：上下文窗口溢出。当工具返回的数据量超过LLM处理能力时——服务器日志、数据库查询结果、大文件内容——代理不会报错，而是静默降级：截断数据、丢失上下文、输出残缺。IBM一项材料科学研究为此付出了惨痛代价：同一工作流裸跑消耗2000万token后失败，改用内存指针方案后仅用1234token成功。
解法叫"内存指针模式"：大数据存进agent.state，只返回短指针给上下文。后续工具解析指针获取完整数据。AWS的代码示例很直观——fetch_application_logs检测到日志超20KB时，生成指针"logs-payment-service"（52字节），而非把200KB原始数据塞进LLM视野。analyze_error_patterns再通过指针调取，LLM全程只看见那52字节。
Strands Agents的ToolContext API在这里关键：agent.state是原生键值存储，作用域隔离到单个代理，无需全局字典或外部基础设施。多代理场景下，invocation_state支持Swarm内跨代理共享，API完全一致。
完整demo已开源。这1234token vs 2000万token的差距，本质是"让LLM指挥，别让LLM搬运"的设计哲学。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
