很多人给 Agent 加缓存第一反应是缓存用户问题→最终回答但工具调用这一层的缓存更值钱也更容易踩坑。我这篇只聊一件事工具结果要不要缓存、缓存键该用什么拼——这玩意儿设错了要么命中率低得没意义要么直接给用户返回了别人的数据。先分清哪些工具结果能缓存不是所有工具都该缓存。我按两个维度过一遍工具类型例子能缓存吗纯查询、结果稳定查城市天气编码、查商品规格能TTL 长查询但会变查实时库存、查物流状态能TTL 短带副作用下单、发券、改数据绝对不能跟用户身份强相关查我的订单能但键必须带用户带副作用的工具缓存了就是事故——我见过有人把创建工单也缓存了同一句话进来两次直接命中第二次没真建单用户以为提交了其实没有。核心缓存键拼什么键的本质是什么相同才算同一次调用。我的拼法是import hashlib, json def cache_key(tool_name, args, user_scopeNone): # 1. 参数要规范化排序键、去掉无关字段、统一大小写/空格 norm {k: v for k, v in sorted(args.items()) if k not in IGNORE_KEYS} # 2. 涉及用户私有数据的工具键里必须掺 user_scope否则串户 parts [tool_name, json.dumps(norm, ensure_asciiFalse, sort_keysTrue)] if user_scope: parts.append(user_scope) # 比如 user_id 或租户 id raw |.join(parts) return tool: hashlib.md5(raw.encode()).hexdigest()几条踩过血的规矩参数必须规范化再拼。模型生成的参数顺序、空格、大小写不固定{city:合肥}和{ city: 合肥 }不归一化就是两个键命中率直接砍半。私有数据的键一定要掺 user_scope。这是红线。我早期查我的订单只拿tool_name args当键结果 A 用户的订单缓存被 B 用户命中——args 都是空的订单从 token 里取键就撞了。那次差点出大事。把不影响结果的参数踢出键。比如request_id、timestamp这种每次都变的留着等于永远不命中。TTL 别一刀切我按工具配不同 TTL放配置里天气编码这种缓一天实时库存缓 30 秒物流状态缓 2 分钟。配置化之后调起来不用改代码。TTL {query_weather_code: 86400, query_stock: 30, query_express: 120}说点不好的工具缓存最大的暗坑是数据新鲜度。库存缓了 30 秒这 30 秒里卖空了用户拿到的就是脏数据。该不该缓、缓多久本质是拿一点点过时换省调用、提速度得业务方一起拍。还有就是带 user_scope 的键会让缓存条目暴涨每个用户一份内存得盯着我加了 LRU 上限别让它无限长。模型这边我用讯飞星辰 MaaS 现成 API工具结果缓存这层完全在我自己业务侧做跟模型解耦换模型也不影响这套缓存逻辑。你们工具结果缓存的键是怎么拼的有没有踩过串户的坑评论区说说。