GOAT 2.0：采用主动分层记忆的 AI 代理

GOAT 2.0 是一个基于 Telegram 的开源 AI 代理，其最核心的设计主张是「主动式（proactive）」分层记忆：与常见 RAG 方案由模型「按需回忆」不同，GOAT 2.0 在每一轮对话生成回答之前，就会并行触发记忆检索，并将结果直接拼入提示词，模型本身无需判断「我是否记得这件事」。即使是一条模糊的单词消息，也会触发对历史会话的语义检索。

核心差异：检索先于生成

传统 RAG 往往依赖模型判断「是否需要外部知识」，而 GOAT 2.0 把这个判断从模型层下沉到了系统层。其编排器 Orchestrator.run 在每轮启动时最先执行的是 _prefetch_daemon，与 L0/L1/L2 拉取并行运行，而非串行等待。唯一阻断检索的因素是超时，没有置信度门槛。

这种设计的直接后果是：记忆检索变成了「基础设施」而非「工具调用」，模型拿到的提示词里已经包含结构相关的历史信息，回复风格与上下文一致性因此更稳定。

三后端、五层逻辑记忆

GOAT 2.0 把记忆拆成三种物理后端和五层逻辑视图。物理层面：

• Working（工作记忆）：使用 Redis 存储当前会话完整消息与 L2.5 缓存
• Episodic（情节记忆）：使用 ChromaDB 本地持久化集合做长期语义检索
• Permanent（永久记忆）：通过 Letta HTTP API 写入事实块（core-memory facts）

逻辑层面则在统一外观 MemoryLayers 下暴露五个层级：

• L0 — 身份：基础人设，每次必带
• L1 — 事实：Letta 中的键值事实，每次必带
• L2 — 工作记忆：当前会话完整历史（带上限），每次必带
• L2.5 — 会话缓存：L3 检索结果与工具输出的 TTL 缓存
• L3 — 情节记忆：语义长期记忆，按相关性条件注入

所有后端均采用「懒连接」，单个后端（如 Letta）故障只会让对应层级为空，不会中断整轮对话。

预取守护进程的检索机制

守护进程对每条查询做三种独立分类，命中分数大于零即触发对应检索，三种机制之间没有门控：

• 时序机制：通过语法解析提取过去日期范围（而非关键词匹配），调用 search_episodic(after, before) 做过滤后的语义检索；today 因日区间尚未结束而被排除，避免误触发
• 主题机制：固定信号值 1.0，无条件触发带缓存的语义检索
• 特定键机制：检测 UUID、agent-{uuid}、词+数字、turn_/goat: 等结构化键，调用 find_by_keys 做精确匹配（score=0.0）

整个过程使用 AITS（Adaptive Intent & Time Signal）在预取期间并行做意图分类，控制上下文预算。L3 相关性过滤采用基于分数分布的比例阈值，避免固定阈值在不同语义空间下的失灵。

完整保真与无压缩存储

与许多「记忆系统」会先做摘要或抽取再存储不同，GOAT 2.0 对每一轮对话都做完整原文归档（_archive_turn），不做任何压缩或抽取。任何历史会话的全文都可以通过单次语义检索召回，原文与模型之间没有摘要层。这种做法提高了检索保真度，但代价是存储开销与检索时延同步增长。

服务注册表 ServiceRegistry 采用「按调用方传递的实例」而非模块级单例，符合项目自身的「零单例」规则，所有后端在首次属性访问时才构建，进一步降低启动期依赖。

GOAT 2.0 并不来自主流厂商，也未提供第三方基准成绩，它更适合作为关注 Agent 长期记忆设计的开发者的参考实现，而非可直接投产的产品方案。