回顾 → 问题引出

1. DeepRearchSystem 0x00：初识
2. DeepRearchSystem 0x01：Agent 基础
3. DeepRearchSystem 0x02：Graph 建立
4. DeepRearchSystem 0x03：HITL
5. DeepRearchSystem 0x04：MAS 进阶
6. DeepRearchSystem 0x06：LLM as Judge

前面经过几轮改造，DeepRearchSystem 已经算是一个接近生产级的深度搜索研报 Agent。但当同一使用者或不同使用者多次查询相同问题时：

• 触发 * N 次 WebSearch，LLM 调用 + 次；整体成本成倍，还会产生延迟。

痛点的观点是。

• 成本暴涨: 每一次查询都要走外部 API，费用累积。
• 响应时间拉长: 多次网络请求导致平均延迟上升。
• 资源浪费: 同一条信息被多次重复抓取与处理。

如何通过缓存机制解决上述痛点？可以考虑设置一个高效、可 的缓存程序。

兵来将挡 – 缓存设计思路

借鉴 SDWebImage 的二级缓存策略

P0: 内存缓存 至于P1，磁盘缓存 两层无则直接发起网络请求。

存储方式：

- key: image_url 或其 md5 - value: NSData

research_cache – 服务端架构化缓存方案

This cache is a server‑side architecture;can we reuse SDWebImage’s design?话说回来，

-->
• P0: Redis — 优先访问 • Redis 本身就是“磁盘+内存”组合 • 在高并发下能避免磁盘瞬间爆满 • 虽然内存更快。但 Redis 多实例共享能提高吞吐量与一致性。
• P1: In‑Memory dict + threading.Lock — 当 Redis 不可用时作为兜底容灾。
• 键值映射： - key： → MD5 哈希后固定 Redis Key - value：search_result JSON 序列化对象。
• 双写双读： - 主方法：使用 setex 设置 TTL；不过，get 并检查 ttl。- 降级方法：Redis ping 异常时自动切换；本地 dict 保存过期时间戳与结果。双向同步保证数据在两端保持一致，即使 Redis 暂时不可用也能继续提供最新结果。
• Ttl 生命周期： 隔离；cache_stats 用于可观测性监控。
• 回填机制 ：
  1. {read} Redis> 获取 result_redis 与 timestamp_redis。
  2. {read} In‑Memory> 获取 result_local 与 remaining_local。
  3. {决策} 若 remaining_local> remaining_redis → 表示在 Redis 宕机期间本地更新更晚，则立即把 local 写回到 Redis。记录 WARN 日志标记“数据回填”。否则直接返回 Redis 数据。
• Ttl ： 在回写时使用 min，防止因容灾导致过期时间被放宽。适用于搜索等非强一致性场景；对于价格、库存等实时敏感业务需采用严格 TTL 保证数据时效性。
• # 可观测性指标：\
  • 缓存命中率 • 降级成功率 • 内存泄露监控

  Coding – 实现细节概览

  基础配置

  # ── configuration ─────────────────────────────────────────────────────DEFAULT_TTL = # 秒TRUNCATE_LEN = # 日志中截断 query / title 时的最大字符数REDIS_KEY_PREFIX = "search_cache"REDIS_URL = os.getenv# ── Redis 连 ... `

  get_cached

  def get_cached -> Optional]:` ...

  至于主要思路说明，

  • - 尝试读取 Redis；若命中则检查 TTL 并根据回填规则决定是否更新本地或写回远端。

    • 若 Redis 不可用或读取失败，则落入 In‑Memory 方法；如果本地已过期则返回 None，否则直接返回本地数据。

    • 所有操作均记录日志。包括命中、未命中、回填、异常等，以便后续排查。

    回填机制细节演示

    以下示例演示了在不同时间点下的数据状态变迁与对应操作：

    时间点 T	Redis 状态/TTL / 操作说明
    0s	首次写入，TTL_local=100s，TTL_redis=100s
    50s	Redis 宕机。local 有剩余 TTL=50s
    60s	Redis 恢复 → 回填 local 到 redis，重新设定 TTL_redis=100s
    70s	local 已过期但 redis 未过期，此时不再触发回填，仅返回 redis 数据
    120s	both 已过期 → 缓存失效，需要重新搜索

    如果对时效敏感，可改为在回写时传递 min。这样即使出现短暂宕机，也不会把旧数据暴露太久。对于价格/库存之类业务，应进一步限制 max。

    # setcached – 写入流程概述 🔧 🔒 ⚡️ 💾 📦 setcached 的实现与 get_cached 对比，有几点关键差异。① 总是先把结果写进本地内存——无论后续是否成功写到远端，都保证当前实例随时可读到最新结果。② 再尝试将数据持久化到 Redis——若失败仅记录警告，不影响主流程。③ 所以，即使全局网路不通，也能从单实例内部获得快速响应。下面给出完整实现代码，并注释每一步骤背后的设计动机。” ---

    python def set_cached -> None: \"\"\" \t\t将搜索结果存入缓存。\t\t\"\"\" key = _make_key # 第一步先：始终先写本地内存 with _fallback_lock: \t _fallback_cache = + DEFAULT_TTL,\u200Bresult) \t logger.info} items,TTL={DEFAULT_TTL}s)→ 内存\") # 接下来：尝试写 Redux r = _get_redis if r is not None: \t try: r.setex) logger.info} items。TTL={DEFAULT_TTL}s)→ Redis\") except Exception as exc: logger.warning.__name__}): {exc}')\t \t

    # cleancached – 清空所有缓存条目 📤💨 🧹 💔 uctionally for testing purposes. cachestats - 用于监控和调优 🔎💡 📈 different scenarios such as cache avalanche prevention. laterly next section will talk about how to integrate this cache into WebSearchAgent. and rest of article continues with more details about integration and usage.