2 篇博文 含有标签「databases」

大多数 Agent 内存都是一个无差别的存储库。循环在每一步开始时从中读取以组装上下文，并在每次动作后向其写入 —— 新的观察结果、运行摘要、暂存器编辑。同样的存储，同样的访问路径，没有分离。它在演示中运行良好，但一旦 Agent 运行时间足够长、存储库变大，它就开始腐烂。

它腐烂的原因对于任何扩展过数据库的人来说都很熟悉。一个同时提供读写服务的单一存储库就像是一个没有副本的单主数据库，它继承了该拓扑结构在负载下的每一个问题：写入与读取竞争，更新中途读取到写了一半的记录，且易失性工作集与持久记录之间没有隔离。几十年前，我们就通过读写分离解决了数据库的这个问题。Agent 内存也理应得到同样的对待。

解决方法不是更大的向量索引或更智能的嵌入模型。这是一个架构上的解决方法 —— 认识到 “内存” 是冠以同一名称的两种不同工作负载，并为每种负载提供其真正需要的存储规约。

GPT-4o 在 Spider 基准测试中获得了 86.6% 的分数。将其部署到你的实际数据仓库中，你可能只能得到 10%。这种差距不是舍入误差——它正是问题的核心。构成缺失的 76% 的查询在执行时没有错误，返回的行符合正确的架构（schema），但结果完全错误。

Text-to-SQL 不是语法问题。每一个严肃的生产环境部署都会发现同一个令人不安的真相：最棘手的失败是无声的。一个扫描 10TB Snowflake 表、由于重复连接（join）导致返回的营收数据偏高 30%、或者悄悄绕过行级安全设置的查询，从外部看与正确的查询完全一样。它运行结束，返回数据，没有人会标记它。

本文涵盖了在生产环境中真正困扰团队的失效模式，以及防止这些模式的层级架构。