数据库是企业级 agent 的最后一道防线

Kay Malcolm 上台先开了个自嘲的玩笑,说自己是”退休嘻哈舞蹈教练”,全场笑场之后才进入正题。她是 Oracle AI Database 产品管理副总裁,带着一个横跨荷兰和美国两地的团队,亲身踩过”AI 让个体变快、团队却没变快”的坑。这场是 AI Engineer World’s Fair 第四天(会议内部编号 Day 3)Harness Engineering 分会场主舞台的第 13 场,官方排期 2:50pm-3:10pm。

原视频：https://www.youtube.com/watch?v=I2cbIws9j10（约 06:00:55 开始）

凌晨提交的代码,没带上下文

她团队一部分人在荷兰,一部分在美国。荷兰同事凌晨四点提交完代码下班,用的是 Oracle 内部的 Codex,但提交时只带走了代码,没把 Codex 里积累的上下文一起存下来。美国同事早上醒来拿到代码,对着一堆没有背景信息的改动发懵。

“我们用 AI 解决了一个 AI 造出来的问题。”她这么形容当时的处境。个体确实变快了,团队整体的产出却没跟上,因为 Git 只记录代码变成了什么样子,不记录人当时为什么这么改。代码创建本身不再是瓶颈,真正卡住团队的是协作层:怎么追踪进度和下一步、怎么还原 agent 某个决定背后的依据、怎么处理分歧。

一个真正的企业级 agent 长什么样

多数人以为 agent 等于模型加工作流,Kay 现场问了一圈,举手认同的人寥寥无几。她的拆解是四块:工具(怎么把事情做出来)、上下文(prompt 里塞了什么)、记忆、护栏。

她用一个类比讲清楚这几块怎么拼在一起:模型是泡在玻璃罐里的一颗小脑袋,harness 是身体,负责让这颗脑袋真正把事情做完;记忆则是中枢神经系统,连接大脑和身体的四肢,负责把上下文一路带过去。她团队踩的坑,正是这根”神经”没接上。荷兰团队的上下文,一步都没传到美国团队手上。

只需要记住的五种记忆

她把常见的记忆类型收窄到五种,反复强调”这五个记住就够”:短期记忆对应一次会话(不管是 Claude、ChatGPT 还是 Codex,session 内的记忆都算这一种);长期记忆是跨会话保留下来的东西;情景记忆回答”上次跟某个对象交互发生了什么”;程序记忆记录做过哪些步骤、走过哪条路径;语义记忆则是企业级 agent 特有的、需要理解概念关系的那部分。

这五种记忆听起来是模型层面的抽象概念,但 Kay 真正想问的是一个基础设施问题:这些记忆物理上存在哪里。

从调 SQL 到多开四场会

她讲了自己在电力公司 Southern Company 做 DBA 时的经历。那时候的数据世界很简单,数据就是行和列,她能把一条 SQL 查询调到极致。直到有天一个开发者跑来说要存非结构化数据。她同意之后,代价是每套数据库系统都要按公司规定参加安全会和补丁会,一套系统两场——非结构化数据库装完,开会次数从两场变成四场。

紧接着团队又要解决另一个需求:把巡线工人手持设备上报的信号(是否真断电、是否误报)跟周边线路关联起来判断真假警报。她写了一条五层嵌套 UNION ALL 的 SQL 查询解决了这事,算是图查询流行之前的土办法。团队后来装了 Neo4j,开会次数又变成六场。她原话是”这是个问题”,随后就辞职去了 Oracle。

这段经历撑起了整场演讲的论据:关系型、非结构化、图、向量,每加一种专用数据库,企业就要多背一套运维和合规成本。数据库选型不只是技术决策,组织开销会随数据库种类往上堆。

数据分散在四个地方,agent 只能猜

到了 Oracle,她碰到另一个真实问题:agent 要访问的数据分散在关系型数据库、JSON 文档库、图数据库、向量数据库四个地方,谁是唯一真相来源?她的回答是,多数时候 agent 猜不对,猜错了就是白烧 token。

她现场找了四位志愿者分别代表这四种数据库,让他们不出声地把一句话(“The cow jumped over the moon”)传递并存下来,还提醒观众说话太大声等于多付 5 倍 token。结果自然是传歪了。这个小实验想说明的是,当记忆分散在互不通气的几套系统里,协调一个简单事实都会失真,更别提复杂的企业数据。

她给出的解法是把这几种数据形态收进一个数据库:Oracle 的 AI Database(她称之为 26AI)支持在同一张表、同一个分区里原生存放 JSON、图、向量、关系数据,甚至不可篡改的区块链记录。她的说法是”这是个营销问题”,技术已经具备,只是没多少人知道。

记忆代理 Py,把上下文重新接上

回到团队协作的问题,她们的解法是引入一个叫 Py 的记忆代理,底层用 Oracle Agent Memory SDK(pip install oracle-agent-memory),把对话、事实和该保留的信息统一存进一个 Oracle 自治数据库,LLM 可以自选,也可以走 Oracle 私有 AI 服务容器跑本地模型。

效果是,一个人的上下文窗口里如果带着程序记忆、情景记忆、长期记忆信息,Py 会把这些一并同步给团队里其他人。开发者仍然掌握决策权,Py 只负责把上下文、fork、branch、commit 的对应关系理清楚。用她的话总结:AI 让个体更快,共享在同一个数据库上的记忆让团队更快。

这场在当天议程里的位置

Harness Engineering 分会场当天前面几场大多在讲编排、工具协议、权限和沙箱执行,这一场把”记忆放在哪、状态怎么持久化”提到了跟工具和权限同等重要的位置。官方简介里她还提到一个组织信号:AI 应用开发正在从一个岗位拆成三个——agent 工程师、记忆工程师、平台工程师,企业客户要的治理与规模,和独立开发者想要的轻量组合原语,理论上可以用同一套 harness 服务两边。

这跟本地知识库里已经收录的一条判断吻合。有综述把 harness 拆成七层,明确说模型再强,可验证性和治理这两层都不会因为模型进步而贬值。Kay 说数据库承担的审计、回滚、持久状态这三件事,本质就是把这两层落到了具体产品上。我读到这里的感觉是,这不算什么新论点,只是老论点换了一身企业产品的外套。冯诺依曼那句”外部数据库就是磁盘”的类比,以前只是个比喻,在这场演讲里变成了实打实的产品卖点。

值得补一句平衡的判断:不是所有场景都需要这套统一数据库。Claude Code 这类单 agent 工具反而靠纯文件(JSONL、git commit)做检查点跑得很好。差别在于规模,Kay 反复用的说法是”scale past one”——一旦记忆要跨团队、跨会话、跨审计要求共享,文件系统式的 memory.md 就顶不住了。选数据库还是选文件,不是信仰问题,是看你的记忆需不需要被别人验证。