《Agent记忆错误的100个案例手册》第 61–65 案例
本辑为《Agent记忆错误的100个案例手册》连载内容。
案例 61：工具使用中的记忆错误｜tool-result-caching-stale-data-usage
场景
Agent调用天气API获取当前天气，结果缓存30分钟。用户在缓存期间询问”根据现在的天气，我应该带伞吗？“，Agent使用了缓存中的”晴天”结果。但实际情况是30分钟前天气已转为暴雨。
错误表现
Agent建议”不需要带伞”，用户出门后被雨淋湿。用户质疑”你不是说晴天吗？”
解决方案
- 对工具结果设置”语义化TTL”：天气预报缓存15分钟，股票价格缓存5分钟，用户信息缓存1小时
- 在回答中标注数据时效性：“根据30分钟前的天气数据…”
- 对时效性强的工具实施”实时优先”策略：用户查询时优先实时调用，后台异步更新缓存
原理
缓存通过牺牲时效性换取性能。但对时效性敏感的场景（天气、股价、库存），过期缓存会导致决策错误。语义化TTL根据数据类型动态调整缓存策略。
案例 62：工具使用中的记忆错误｜tool-parameter-memory-type-confusion
场景
Agent之前调用某API时，参数user_id为整型12345。后来该API升级，要求user_id为字符串型`“12345""。Agent记忆中存储了历史调用的参数模板，在新调用时直接复用，未检查类型要求。
错误表现
API返回400错误”user_id must be a string”，Agent无法完成任务，反复重试导致API限流。
解决方案
- 工具参数记忆应存储”参数模式”（JSON Schema）而非具体值，调用时根据当前API schema进行类型校验
- 在工具定义更新时，触发”参数记忆失效”：清除与该工具相关的历史参数记忆
- 实施”防御性调用”：在调用前进行参数预校验（Pre-validation），类型不匹配时自动转换或报错
原理
API的参数类型和约束可能随版本变化。将历史调用的具体值作为模板复用，忽视了API的演化。基于Schema的调用比基于实例的调用更具鲁棒性。
案例 63：工具使用中的记忆错误｜tool-chain-intermediate-result-loss
场景
Agent执行一个3步工具链：T1查询用户ID → T2查询用户订单 → T3取消订单。T1的结果（user_id）被存储在短期记忆中，但在调用T2前，由于上下文压缩，user_id被截断丢失。T2调用时缺少user_id参数。
错误表现
T2返回”缺少user_id”，Agent工具链中断，用户任务未完成。Agent尝试重新从T1开始，陷入循环。
解决方案
- 为工具链中的”传递参数”设置”管道锁定”：关键传递参数在工具链完成前不可被上下文压缩清除
- 使用外部状态机管理工具链：中间结果存储在外部状态存储（如Redis）中，不依赖LLM上下文
- 实现工具链的”断点续传”：工具调用失败时，检查缺失参数并尝试重新获取，而非从头开始
原理
工具链（Tool Chain）的执行依赖中间结果的传递。LLM上下文的不可靠性使得”基于上下文的管道”容易断裂。外部状态机能提供更可靠的中间结果持久化。
案例 64：工具使用中的记忆错误｜tool-selection-bias-recent-usage
场景
Agent有5个搜索工具（Google、Bing、DuckDuckGo、内部Wiki、学术数据库）。由于Agent记忆中”最近成功调用的工具”是Google，在后续查询中Agent频繁选择Google，即使查询更适合用学术数据库（如”Transformer架构的注意力机制数学原理”）。
错误表现
Agent用Google搜索学术内容，返回的结果质量低（博客文章而非论文），导致回答的准确性和深度不足。
解决方案
- 工具选择基于”查询-工具匹配度”而非”使用频率”：为每个工具定义能力描述，用embedding计算查询与工具描述的相似度
- 实施”工具探索机制”：强制Agent定期尝试不常用的工具，防止选择固化
- 对工具选择进行”事后评估”：记录工具选择-结果质量的映射，用于优化选择策略
原理
工具选择的偏差类似于人类的习惯性思维。如果Agent总是选择”顺手”的工具而非”最合适”的工具，其能力边界会被收缩，无法发挥多工具集成的优势。
案例 65：工具使用中的记忆错误｜api-rate-limit-memory-exhaustion
场景
Agent调用外部API时遭遇429限流（Rate Limit），应在1分钟后重试。但Agent的”限流状态记忆”未能正确更新，每次重试间隔仍是固定10秒。Agent连续触发限流，API提供商暂时封禁了IP。
错误表现
Agent的所有API调用失败，无法完成任何依赖该API的任务。用户看到”服务暂时不可用”的错误。
解决方案
- 解析API响应头中的
Retry-After字段，将精确的重试时间存入记忆 - 实施”指数退避+抖动”（Exponential Backoff + Jitter）策略：限流后等待时间指数增长并添加随机抖动
- 使用”断路器”模式（Circuit Breaker）：连续失败后暂停调用该API，改为返回降级响应
原理
API限流是服务保护的必要机制。不尊重限流信号的客户端会被视为”攻击者”而受到更严厉的封禁。正确的限流记忆和退避策略是可靠集成的基本要求。
来源：Agent Search