构建一个能自动调整缓存的智能体
优化大语言模型 (LLM) 应用的挑战通常是一个不断试错的过程。开发者通常根据直觉设置生存时间 (TTL) 值和缓存策略，然后通过监控日志来观察其效果。然而，手动配置与实际使用模式之间的差距往往很大，从而在成本和延迟方面造成低效。
在最近的一个项目中，BetterDB 的创建者为基于 Valkey/Redis/Dragonfly 文档构建的 RAG (检索增强生成) 应用开发了一个智能体缓存系统。其目标是通过允许智能体监控自身的性能并实时建议配置更改，来真正地对他们的缓存库进行“狗食测试” (dogfood)。
多层缓存架构
为了最大限度地提高效率，该系统采用了旨在处理不同类型用户交互的两层缓存策略：
1. 精确匹配工具缓存
该层位于 SDK 和工具之间。每一次调用都会被规范化并检查是否存在精确匹配。这对于预定义的问题、重复的复制粘贴查询或用户多次检查相同的技术细节非常理想。如果发生命中，系统会立即返回结果，完全绕过 LLM。
2. 语义缓存
由于人类很少会以完全相同的方式措辞问题，系统利用了语义缓存。这一层会对提示词进行嵌入 (embedding)，并通过 valkey-search 执行 K-最近邻 (KNN) 搜索。如果新提示词与缓存提示词之间的余弦距离足够接近，系统就会流式传输缓存的响应。
当两个层级都发生缓存未命中时，系统会记录提示词嵌入、所使用的模型以及来自 OpenAI 使用报告的输入/输出 token。这使得系统能够追踪通过后续命中所节省的准确美元金额。
闭环：自我调整与监控
该项目的真正创新在于从静态配置转向智能体循环。系统将元数据存储在 Valkey/Redis 实例中，然后由监控进程进行分析。
该监控循环运行如下：
- 分析： 监控工具读取缓存元数据并分析使用模式。
- 建议： 系统通过 MCP (Model Context Protocol) 服务器建议改进措施（例如 TTL 更改）。
- 执行： 在此演示环境中，智能体被允许批准并应用其自身的建议。由于库直接从 Valkey 实例读取配置，更改会立即生效，无需重启服务器。
经验教训：配置 vs. 代码
在测试期间，开发者观察到了一个有趣的趋势。在三次运行中，工具调用次数从 15 次下降到 13 次，最后下降到 8 次。虽然智能体建议了几次 TTL 更改，但开发者注意到一个关键的局限性：TTL 通常不是正确的控制点。
例如，用户可能会问“How fast is XADD?” 和“XADD performance”。这两者在语义上是相同的，但在字符串上是不同的。TTL 的更改无法解决这两个查询未命中精确匹配缓存的事实。唯一的真正解决方法是架构层面的更改——将这些特定的工具从精确匹配层移动到语义缓存检查中。
这一认识为 LLM 开发者提供了一个关键洞察：并非所有的优化都可以通过配置来解决。 一些低效之处在于路由逻辑本身，需要通过代码更改而非参数微调来解决。
未来方向
为了进一步完善系统，开发者正在研究如何使路由逻辑本身变得可配置。这将允许智能体在无需重新部署的情况下，在精确匹配层和语义层之间移动工具，从而实现更快的迭代循环和优化假设的验证。