#数据库成为智能体记忆底座#

HaishanDB（海山数据库）为移动云智能体数据底座，提供长期记忆、向量检索、DBAI推理引擎

一、引言：AI落地的"最后一公里"难题

过去两年，大模型的进化速度令人目眩。但当我们把视线从技术前沿转向产业落地，会发现一个尴尬的现实：模型越来越强，企业用起来却越来越难。GPT-4、Claude、Gemini 轮番登场，能力排行榜上的数字不断刷新——可真正把这些模型嵌入企业核心业务并跑通的案例，远比我们期望的少。

原因并不复杂。每个企业都有自己的数据"方言"、流程"暗礁"和合规"红线"。标准化 API 解决了"接得上"的问题，却解决不了"用得好"的问题。这就好比给每家企业发了一把万能钥匙，却发现锁芯各不相同。数据分散在十几个系统里，业务规则藏在老员工的经验里，安全合规的要求写在法务部门的备忘录里——这些东西，没有任何一个通用模型能直接"学会"。

于是，一个从Palantir 走出来的角色开始被整个行业追捧——前沿部署工程师（Forward Deployed Engineer, FDE）。他们不是传统意义上的驻场开发，也不是技术售前。他们带着产品进场，在客户现场写代码，把模糊的业务需求翻译成可运行的智能体系统。Palantir 靠这套模式构建了千亿美金市值，国内的 AI 公司们正在快速跟进。

然而，聚光灯打在FDE 身上的时候，有一个更底层的问题被忽略了：FDE 在现场可能用的是 OpenClaw 这样的轻量工具，最终交付可能运行在企业级平台上——无论上层工具怎么变，底层都需要一个能"托住"所有 Agent 资产的数据底座。这个底座不仅要能存数据，还要能管记忆、编知识、跑 Agent、守安全。可以说，它是 AI 落地的"地基"——地基不牢，地动山摇。

二、Agent 时代，数据底座面临的五大挑战

传统数据底座的命题很明确：存得下、查得快、不丢数据。但在FDE 交付场景中，这些只是及格线。Agent 的引入带来了一批全新的挑战——它们不是未来才会出现的远期烦恼，而是 FDE 第一天进场就会撞上的现实问题。

2.1 数据多、杂、散：Agent 的"输入焦虑"

企业的真实数据世界，从来不是"一张表走天下"。FDE 进场后看到的典型画面是：客户信息在 MySQL 里，合同文档在文件系统中，产品图片在对象存储里，操作日志在 Kafka 里，业务指标在时序数据库里，而客服对话记录散落在企业微信和邮件系统中。一个真正有用的 Agent，需要同时"看懂"所有这些数据——但传统底座只能做关系型查询，对文档"视而不见"，对图片"无能为力"。如果为每种数据都引入一套独立组件，FDE 团队大部分时间不是在调 Agent，而是在做数据搬运工。

2.2 知识藏在人脑里：Agent 的"失忆症"

一位有多年驻场交付经验的工程师说过一句话：95% 的企业 AI 导入失败，不是因为技术不行，而是因为"不知道流程到底是什么"。想想也是——企业的核心知识往往不在文档里，而在老员工的脑子里。哪个客户偏好邮件沟通、哪条产线周三下午必须检修、哪个审批环节十有八九会卡壳——这些"只可意会"的隐性知识，恰恰是 Agent 发挥价值的金矿。可传统的表结构根本装不下这些东西。更棘手的是，FDE 花三周时间好不容易萃取出来的业务知识，如果换一套系统就要从零开始，那所谓的"快速交付"不过是"快速外包"。Agent 需要的不是更多表字段，而是一个能理解业务实体之间关系的"统一语义层"，让知识可以积累、可以共享、可以迁移。

2.3 Agent 越用越"傻"：记忆系统的缺位

你大概有过这样的体验：和AI 聊了半天，关掉窗口再打开，它完全不记得你是谁。日常使用中这不过是有点烦，但在 FDE 场景中，这是致命的。一个帮客户处理售后问题的 Agent，需要记住这个客户偏好什么沟通方式、上次投诉是怎么解决的、哪个客户经理和他打过交道——甚至还需要和其他 Agent 共享这些信息。一个每次执行任务都"失忆"的 Agent，永远比不上一个熟悉业务的人类老手。而记忆系统远比"存聊天记录"复杂：它需要分层（哪些是临时的、哪些是永久的），需要权限控制（谁能看到什么），需要跨 Agent 共享，还需要支持"找到和张三相关的所有历史交互"这样的实体关联检索。

2.4 工具接不上、Agent 聊不通：协议碎片化

很多人以为搭一个Agent 就是"模型 + 数据库"的事。真实情况远比这复杂。Agent 要调用企业内部的各种工具（ERP 接口、邮件系统、审批流程），要和其他 Agent 协作（主 Agent 分配子任务给专项 Agent），还要和前端客户端通信（状态推送、进度同步）。这三层通信如果各搞一套私有协议，FDE 团队每换一个客户就得重新"接线"一遍。MCP、A2A 等开放标准正在快速成熟，但各家的采用进度参差不齐——数据底座如果不主动适配这些协议，FDE 就只能一遍又一遍地重复造轮子。

2.5 从 demo 到生产：Agent 放大了安全攻击面

传统应用的安全边界是一条清晰的线：用户输入→ 后端校验 → 数据库写入。每一步都在掌控之中。但 Agent 打破了这条线——它可以自主决定调用哪些工具、访问哪些数据、甚至主动与其他系统交互。这种"自主性"是 Agent 的核心价值，却也是安全噩梦的起点。想象一下：一条被精心构造的恶意记忆，悄悄混入 Agent 的知识库，然后在某次对话中被注入系统提示词——Agent 可能在"忠心耿耿"地执行"老板的要求"，而这个"老板"其实是攻击者。多租户场景下问题更加突出：不同客户的 Agent 共享同一套基础设施，一旦隔离失守，后果不堪设想。安全不能建立在"Agent 的行为总是可预测的"这个乐观假设上——因为大模型的本质就是概率性的，不可完全预测。

三、一个底座，两套工具：为什么数据底座是关键枢纽

FDE 交付的典型路径分两个阶段：先在现场用轻量工具快速验证场景，再迁移到企业级平台正式部署。这两个阶段的上层工具可以完全不同——FDE 阶段用 SQLite 跑 demo 就够了，企业部署时换成 PostgreSQL 集群；现场用 OpenClaw 快速搭建 Agent，上线后接入企业 Agent Runtime。上层怎么变都行，但底层的根基不能变——数据底座必须是"同一个根"。

问题出在哪？如果两套系统的数据模型、记忆格式、知识定义、协议规范不兼容，所谓的"迁移"实质上就是推倒重来。而推倒重来的代价，往往比从头开发还高——更要命的是，客户会觉得"这个系统和当时 demo 的时候完全不一样"，信任瞬间崩塌。

Palantir 为什么没有这个问题？因为他们的FDE 在客户现场用的就是自家产品（Gotham/Foundry 的实例），沉淀的数据、Pipeline、Ontology 直接就是交付物，从来不存在"两套系统"。大部分 AI 公司做不到"一套系统走天下"——FDE 阶段要轻量，企业部署要重量级，两者在技术复杂度上差了好几个数量级。所以真正的解法不是消灭两套工具，而是让两套工具之间零摩擦——"一套资产契约贯穿始终"，这才是数据底座的核心使命。

四、面向 FDE 场景的数据底座五大核心能力

接下来要谈的五大能力，不是精心编排的功能清单，而是从上述五个挑战中直接推导出的刚需。一个关键洞察是：无论你用OpenClaw 这样的轻量工具还是完整的企业级平台，只要 Agent 要在真实业务场景中跑起来，底座就必须具备这些能力——差别只在于轻量工具用 SQLite 实现，企业平台用分布式集群实现。能力的需求不变，实现的规模不同。

4.1 多模态混合检索：让 Agent 同时"看"到所有数据

设想一个FDE 在现场经常被问到的需求："帮我查一下上个月和张三相关的所有信息——通话记录、合同变更、投诉邮件，还有他在系统里的操作日志。"看似简单的一个问题，背后涉及四种截然不同的数据类型：通话记录是结构化数据，合同变更是文档，投诉邮件需要语义理解，操作日志是时序数据。如果底座只能做其中一种查询，Agent 就只能回答四分之一的信息。

所以数据底座需要原生的多模态混合检索能力——将向量检索、全文搜索、结构化查询、时序处理融合为一等公民，而不是东拼西凑的"缝合怪"。Supabase 选择 PostgreSQL 作为统一核心，通过 pgvector 实现向量检索，关系数据、向量嵌入、JSON 文档全在同一个库里，一条 SQL 就能完成混合查询——这种"数据共置"的设计让向量结果可以直接和业务数据 JOIN，独立向量数据库做不到这一点。Apache Doris 4.1、阿里云 Lindorm、OceanBase 也在走类似路线。核心逻辑都一样：让 Agent 用一个入口"看到"所有数据，而不是沦为数据搬运工。

4.2 本体建模与统一语义层：让 Agent "听懂"业务

如果说混合检索解决的是"看到"的问题，那本体建模（Ontology）解决的就是"听懂"的问题。传统数据库用表结构描述世界，但真实业务不是按表运转的——"客户张三通过客户经理李四提交了大额订单，因信用额度不足被风控拦截，后由主管王五审批放行"，短短一句话涉及六七个实体和多条关系，散落在不同的表甚至不同的系统中。Agent 如果只看表结构，永远拼不出这个完整的故事。

这正是Palantir 最核心的壁垒。它的 FDE 团队在客户现场做的最重要的事不是写代码，而是和业务专家一起构建 Ontology——一套统一描述业务实体、属性、关系和动作的语义模型。当 FDE 把客户的业务逻辑通过 Ontology 固化之后，企业的运作方式就被"刻"进了系统——这才是"做重"建立起来的真正护城河。从技术实现看，不一定需要专门的图数据库：PostgreSQL 的 JSONB 配合递归 CTE 就能表达实体关系，叠加 pgvector 做语义检索，FDE 用 SQL 就能逐步迭代出业务本体——这和 Palantir "先铺碎石路，再修高速公路"的理念一脉相承。

4.3 Agent 原生记忆体系：让 Agent 越用越"聪明"

LangChain 创始人 Harrison Chase 说过一句话："没有记忆，你的 Agent 可以被任何拥有相同工具的人复制。"模型在商品化，开源工具人人可用，唯有记忆是 Agent 在持续交互中积累的专有数据——不可复制、不可替代、越用越值钱。但记忆系统的复杂度远超多数人的想象。

首先是分层。Agent 的记忆可以类比人类的三类长期记忆：语义记忆（"客户偏好邮件沟通"）、情景记忆（"上次投诉通过方案 B 解决"）、程序记忆（"处理退货先安抚再查订单"）。叠加生命周期维度（会话级、用户级、组织级），就形成了一个多维矩阵。底座需要原生支持这种分层结构，而非用一张"记忆表"应付所有场景。

其次是权限和共享。基层员工最爱问Agent的是："我领导月薪多少？"——这条数据信息显然不该对他可见。底座需要为记忆设置分级可见性：会话记忆仅当前对话可见，组织记忆按角色控制访问范围。同时多个Agent 协作时需要共享记忆空间，底座要支持共享记忆池和记忆订阅推送。

最后是关联检索和跨平台迁移。Agent 需要的记忆检索是沿着实体关系的多跳查询——从张三出发关联到部门、历史投诉、上次处理的客户经理。而当 FDE 从轻量工具迁移到企业平台时，记忆必须原封不动地跟着走：统一资产契约、文件优先的可移植格式、向量与元数据同步迁移。记忆丢了，Agent 就"失忆"了。

4.4 开放协议与资产可移植：让 FDE 的沉淀"跟着走"

数据底座处于"承上启下"的位置——往上承接各种 Agent 框架（LangChain、OpenClaw、Dify 等），往下适配各类协议标准（MCP 让 Agent 调用工具、A2A 让 Agent 之间对话、Agent Protocol 让客户端通信）。不同客户的技术栈千差万别，如果底座对每种框架都要单独写适配器，FDE 团队一半时间都在"接线"而不是"造 Agent"。

所以底座需要在协议层提供广泛的适配能力——原生支持主流标准，为常见框架提供开箱即用的集成接口，同时定义统一的资产契约（Asset Contract），覆盖协议、Schema、Skill、记忆、工具五层。FDE 工具和企业平台都遵循同一个契约，迁移就是"导出 → 导入"。OpenClaw 的实践验证了这个方向：所有持久化信息存为 Markdown 文件，天然可读、可版本控制、可跨系统传输。协议适配做好了，资产自然就能"跟着走"。

4.5 Agent 原生安全治理：给 Agent 装"护栏"

传统应用的安全模型清晰可控：用户输入、后端校验、数据库写入。Agent 打破了这个模型——它拥有"自主权"，可以自己决定调用哪些工具、访问哪些数据。这种自主性是核心价值，却也打开了潘多拉的盒子。

最隐蔽的威胁来自记忆注入：恶意内容混入记忆库后，在未来某次对话中被注入系统提示词，悄无声息地改变Agent 行为。Hermes Agent 的应对思路值得参考：记忆入库前必须扫描注入和泄露模式——"这条内容会被注入 prompt，需要和用户输入接受同等安全审查"。工具权限同样关键：底座需要 deny → ask → allow 的策略模型，高危操作必须进审批队列。

多租户隔离必须下沉到数据库层强制执行——通过数据库自带的行级权限机制，在每次查询时自动过滤越权数据，比依赖应用层逐条校验可靠得多。权限在查询那一刻就生效，而不是出了事再翻日志追责；敏感信息写入前自动脱敏，从源头堵住泄露风险。Agent 的行为不可完全预测，安全不能建立在乐观假设上。

五、AI 原生数据底座的设计原则

走过前面的挑战和能力分析，可以提炼出六条设计原则：

原则一：资产契约优先——从第一天就定义统一的资产契约（协议/Schema/Skill/记忆/工具），FDE 工具和企业底座都实现同一个契约，迁移就是"导出 → 导入"。

原则二：语义统一，不只是格式统一——协议兼容解决"能通信"，本体建模解决"能理解"，底座需要提供语义层让不同系统对核心业务概念有相同理解。

原则三：记忆是核心资产，不是附属品——分层存储、权限管控、跨Agent 共享、实体关联检索、无损迁移，这些是 Agent 场景的基线要求。

原则四：知识编译而非实时搬运——把零散知识提前编译成结构化制品，Agent 查询时直接拿到带引用的答案，而非每次从原始数据翻找。

原则五：开放协议，不造墙——能接标准的就接标准，即使自建也要保持可导出，封闭协议短期是壁垒、长期只锁定自己。

原则六：安全下沉到数据库层——记忆注入防护、工具权限管控、多租户隔离、查询时权限执行，安全必须沉到数据库层强制执行。

针对FDE 场景的需求，移动云海山数据库（HaishanDB）正在探索和构建相应的技术能力：

构建多模态融合检索能力，一条SQL 实现向量、全文、结构化数据的混合检索；构建分层记忆与权限管控能力，实现 Agent 记忆的多级沉淀与安全共享；构建基于本体建模的语义层能力，让 FDE 用 SQL 定义业务实体与关系；构建知识工程全链路能力，将零散知识自动编译为可复用资产；构建开放协议集成能力，打通 Agent 与工具、Agent 与 Agent 的通信链路；构建原生安全体系，依托行级安全和细粒度权限保障多租户隔离。

这些能力构筑指向同一个目标：让HaishanDB 不仅是一个"存数据的数据库"，而是真正面向 Agent 时代的 AI 原生数据底座。

六、结论

混合检索让Agent "看到"所有数据，本体建模让 Agent "听懂"业务，记忆体系让 Agent 越用越聪明，开放协议让资产"跟着走"，安全治理给 Agent 装好护栏——这五大能力是 Agent 在真实业务场景中跑起来的刚需，不是远期规划。

数据底座的真正竞争力，不是QPS 有多高、召回率有多好，而是让 FDE 在现场沉淀的每一份隐性知识，都能无损地变成可复用、可迁移的显性资产。这是从 demo 到交付的桥梁，也是从项目到产品的引擎。

---

附录：调研参考链接与核心观点

A. FDE 模式与交付实践

1. Palantir 创始工程师 Bob McGrew 深度分享

链接：https://news.qq.com/rain/a/20251014A07P1700

来源：海外独角兽

2. Wisely Chen: 为何 95% 企业 AI Agent 导入失败

链接：https://ai-coding.wiselychen.com/fde-ai-agent-luo-di-xin-mo-shi-ju-ran-shi-chuan-tong-de-zhu-chang-gong-cheng-shi-part-1/

来源：Wisely Chen（前 Google 云端顾问）

3. 深度拆解 Palantir 的 FDE 模式

链接：https://gyznsw.cn/2026/04/24/palantir-fde-model-services-as-software-20260424/

来源：工业智能算网

4. FDE 正在改变世界：中国 AI 交付团队该如何布局

链接：https://news.qq.com/rain/a/20260704A032Z800

来源：幕云社

5. FDE + 本体建模：2026 企业 AI Agent 私有化部署指南

链接：https://www.sohu.com/a/1027675676_122547685

来源：搜狐科技

6. OpenFDE 前线部署工程师开源社区

链接：https://open-fde.com/

来源：OpenFDE 社区

7. FDE 模式深度分析：从"交付"到"沉淀"

链接：https://www.capital-peak.com/news/4092

来源：Capital Peak

B. 数据底座与 Agent 平台架构

8. 阿里云 Lindorm 多模一站式支撑实践

链接：https://www.cnblogs.com/Aliyun12/articles/20847994

来源：阿里云/ 博客园

9. Apache Doris 4.1：面向 Agent 三分归一统

链接：https://cloud.tencent.com/developer/article/2667654

来源：腾讯云开发者社区

10. OceanBase AI Data Infra 解决方案

链接：https://www.oceanbase.com/whitepaper/ai-solution

来源：OceanBase 官方

11. TiDB 以一体化数据库架构应对企业 AI 数据挑战

链接：https://cloud.tencent.com/developer/article/2676048

来源：腾讯云开发者社区

12. 构建 Agent 与数据库自循环飞轮

链接：https://cloud.tencent.com/developer/article/2686327

来源：腾讯云

核心观点：

13. AI 正在批量"创建"数据库

链接：https://www.infoq.cn/article/RfSRGoUcwyuxHJKkgLzo

来源：InfoQ

14. 2025 中国 Data&AI 数据基础设施白皮书

链接：https://www.sohu.com/a/945014429_121819701

来源：搜狐科技

15. Supabase 架构设计原则

链接：https://supabase.com/docs/guides/getting-started/architecture

来源：Supabase 官方文档

16. Supabase Vector：pgvector 集成 AI

链接：https://supabase.com/vector

来源：Supabase 官方文档

17. Pinecone：知识引擎架构

链接：https://www.pinecone.io/learn/how-knowledge-engines-work/

来源：Pinecone

C. Agent 记忆、协议与可移植性

18. LangChain: Your Harness, Your Memory

链接：https://blog.langchain.com/your-harness-your-memory/

来源：Harrison Chase

19. LangChain: Wiki Memory 模式

链接：https://blog.langchain.com/wiki-memory/

来源：Harrison Chase

20. Mem0: Agent 记忆类型与分层

链接：https://docs.mem0.ai/core-concepts/memory-types

来源：Mem0 官方文档

21. OpenClaw Memory Wiki 技术文档

链接：https://blog.devtang.com/2026/04/08/openclaw-memory-wiki-technical-guide/

来源：唐巧

22. Hermes Agent 持久记忆系统

链接：https://hermesagent.org.cn/docs/user-guide/features/memory

来源：Hermes Agent

23. MCP 架构与设计

链接：https://modelcontextprotocol.io/docs/learn/architecture

来源：Anthropic

24. A2A 协议

链接：https://a2a-protocol.org/latest/

来源：Google / Linux Foundation

25. Agent 协议互操作性比较

链接：https://agentprotocol.ai/mcp-vs-a2a-vs-agent-protocol/

来源：AgentProtocol.ai

26. AI 干活的三件套：CLI、MCP 和 Skill

链接：https://blog.devtang.com/2026/04/03/cli-mcp-skill/

来源：唐巧

27. 基于云原生架构构建以数据为中心的 AI Agent 实践

链接：https://developer.aliyun.com/article/1658834

来源：阿里云开发者社区

#HaishanDB #海山数据库 #中国移动HaishanDB #中国移动海山数据库 #He3DB

本文作者：陶捷（HaishanDB）