Agentbase 协议：记忆、任务与系统重构的三部曲

Meta AI 助手月活已经突破 7 亿，已经占到 Meta 平台总用户的 1/10。扎克伯格预测 2025 年 AI 助手用户数将突破 10 亿，届时将占总用户的 1/3！

按照这个速度，不出几年，Meta 平台的交互方式可能不再以信息流为主，而是 AI Agent 主导的 Chat 的任务完成！

Meta 平台数据将从“人类评分”转向“Agent 行动记录”：

从 Feed → 行动脚本

从 点赞/点击 → 任务链条

从 静态标签 → 多轮交互反馈

那么，整个服务于 Meta 信息流推荐系统的数据基建，必须转向服务于 AI Agent：从过去信息流推荐你喜欢的，到 AI Agent 基于聊天和任务完成数据，给你 exactly 你想要的。

这是质的跨越，说其是 Super Intelligence, 绝不为过。于是，就有了小扎给硅谷的华人 AI 俊杰们开出天价薪酬的故事。。。

要理解这个巨大的趋势变化，首先要理解的是 AI Agent 的行为链（下面部分内容直接摘自前文）。

举个真实例子，假设我请 ChatGPT “写一篇 scale 被 meta 投资的分析文章”。

这背后其实可以结构化成如下的一个“意图 → 多轮交互 → agent 行动链 → 用户反馈 → 结果归档” 的完整行为数据结构体。

这类数据无法直接落在传统 RDBMS 或 OLAP 系统中。它们需要以下“新型数据系统特性”：

但再往前走两年，AI agent native 的方式，一定是把传统“数据表”变成“语义对象池”或“行为型 API”，直接构建 “Plan-native” 数据表示，而不是 rigid schema。

这里的 “数据” 不是以“字段”存在的，而是以“任务元素”存在的：agent 的选择、失败、记忆的路径等。

也许未来的数据平台，不叫 database，而叫 Agentbase；不是记录交易流水，而是记录智能如何成长。

Agentbase 会抽象出自己的语义存储机制，它未必是 SQL，也未必是文档库，而是一个“任务状态驱动的 memory store”。

它长啥样，还没行业标准，但我相信行业级 Agentbase 协议将会被定义出来，而且很有可能是从 Meta 这里。

Agentbase 是为 AI Agent 而生的智能系统范式。

Agentbase 不是给 AI 一个“查数据的通道”，而是给 AI 一个“干成事的记忆系统”。 

它不只是 data retrieval，而是 task intelligence.

它不是一个产品，也不是一个框架，而是一套新系统的结构原则：

• 用户不发 query，而是发任务

• 系统不返回结果，而是完成目标

• 交互单位不再是字段和表，而是 Plan、Memory、Tool、Trace

• 语义的中心，从数据结构变为任务结构

它的核心协议，是你在任务执行过程中：

• 如何调度已有工具？

• 如何选择合适的数据源？

• 如何追踪、复用、优化行为路径？

从外部看，Agentbase 要能完成一个行为链。

还是拿前面的 Meta 的 AI 助手为例，当其演进成为 AI Agent 主导的基于聊天的任务完成，给你 exactly 你想要的，在用户视角下的行为流程图就是：

而 Agentbase 的内部协议范式，需要描述 Agent 在执行上述流程中，如何智能地选择并调度资源：

两者的关系是：

什么才是任务的 Plan, Memory, Tool routing, Trace 这些内部机制呢？

再来复习一下：Agentbase 的 “数据” 不是以“字段”存在的，而是以“任务元素”存在的：Agent 的选择、失败、记忆的路径等。

Agentbase 最终会抽象出自己的语义存储机制，它未必是 SQL，也未必是文档库，而是一个：任务状态驱动的 Memory store。

所以，核心是记忆 Memory，也就是：AI Agent native 的任务存储机制。

它不同于，模型基础设施中用到的存储需求

• 对象存储 如 OSS / S3，存大模型权重、训练数据等

• 缓存，Redis / Memcached：做中间推理加速

它是 AI agent native 的“任务智能系统”的存储需求, 但 在 Agentbase 更进一步，要求：

• 存储每次交互的 plan / memory / tool 调用记录；

• 构建基于任务状态演化的「记忆图谱」；

• 实现任务状态-记忆 routing；

这类需求无法通过传统的 KV 缓存 + OSS 实现。

这正是 Agentbase 的落地门槛。

Agentbase 不再用“数据库字段”存信息，而是用“任务的生命周期”来组织 Memory —— 这就需要一种以任务状态为中心的新型 Memory 存储协议，而不是传统的 DB schema。

我们从 “任务状态驱动 Memory” 这件事本身拆解，它意味着三层变化：

一、从 Query → Task：Memory 不再是 Data 的 cache，而是 Agent 的行为轨迹

传统数据库（SQL / KV / 向量库）是为精确查找数据设计的。但 Agentbase 的场景是：我要做一件事，而不是查一个东西。

比如：

• 请帮我规划下周的出差行程 → 包含多个子任务、记忆上下文、计划调整

• 监控用户运营数据并每天生成总结 → 是持续任务，需要 Memory 的动态更新与路由

所以 Memory 不再只是 RAG，而是：

📍记录 Agent 的行为 trace（路径、失败、修正）

📍支持多轮 Memory 强度控制（forget / reinforce / link）

📍让 memory 成为 task 的一部分，而不是外部辅助

二、从 Schema → Plan：Memory 不再绑定字段，而是绑定计划结构

传统 DB 的数据结构像这样：

这种结构说明：Memory 是 plan 的一部分，而非某个字段的附加信息。 

所以 Agentbase 的 Memory store 是一个 Task Plan Store + Memory Routing Layer。

三、从 Static → Dynamic：Memory 必须支持上下文权重衰减 + 多轮引用

传统数据库要“保真”：不修改、不删除、不遗忘；但 Agent 的 Memory 正好相反：要遗忘、要强化、要抽象、要压缩

比如：

• 最近 3 次失败 → 应该强化记忆，触发 trace warning

• 半年前成功但无复用 → 可以压缩成语义图谱

• 某个任务曾调用失败 → 不应再重复尝试

所以 Memory store 要：

📌 支持 记忆 decay 模型（like cache eviction but task-aware）

📌 支持 记忆热度/引用频次 评分

📌 支持 上下文距离 加权机制

其组件、功能、对标项目如下：

所以，Database vs. Agentbase 如下

传统系统只处理一轮 query 的上下文（short context），但 Agent 需要记住历史目标、执行路径、用户偏好等长期信息（long memory），以实现行为一致性与自我演化。

可以理解为：

• Short context = 当前这轮对话或操作的背景；

• Long memory = 你所有行为、习惯、失败/成功路径的累计认知。

Agentbase 正是把两者拉通、动态协同的系统范式。

而如何应对 Long-memory 场景，仍旧有很大的挑战：

• Session / 时序：Agentbase Memory 不是一次性，而是跨 session 的任务状态轨迹。例如“多轮规划一次旅行”、“持续优化产品推荐”等；

• RAG：虽然现在 RAG 多数用于一次性知识查找，但在 Agentbase 中，memory routing 会让 agent 判断是否重新调用某知识块，而不是始终从头找。这种“选择性回忆”是未来 memory routing 的关键。

• 图谱：Agentbase memory 不是扁平数据，而是图结构（任务 - 工具 - 状态 - 记忆强度）交织。

• 信息压缩：传统 memory 不考虑容量，但 Agent 要“遗忘不重要的”，所以需要 memory 的自动摘要、抽象、embedding 化。这就是 “记忆衰减机制”（decay）。

传统 DB 是给程序员写 SQL 用的，强调 schema、字段、索引、事务。

Agentbase DB 则是面向 LLM，“Memory 是 agent 可以理解、可以问、可以操控的对象”，所以它需要是语义驱动 / 任务驱动的。

Agentbase 的 Memory store 未来很可能具有这三点特性：

• 多模态（Multimodal）：不只是文本记忆，还要支持图像、语音、甚至视频行为链（比如教育场景中 AI 教练对学员的长期反馈）

• 自编排（Self-orchestrated）：Agent 会动态选择：哪些 memory 激活、哪些工具调用、哪些路径最优（plan routing） → 这需要 memory store 提供状态感知和调度接口

• 自治（Autonomous）：系统能根据 memory 反馈自己优化 agent 的行为（比如强化成功路径、屏蔽失败路径）

这就是为什么我们说它不是传统数据库的延续，而是新的系统范式。

当下的短期过渡方案是将现有 SQL / Mongo / Elastic 等 DB 提供 NL2SQL 接口，允许 LLM 查询已有业务数据。

但长期来看，落地 Agentbase 将传统数据抽象成“Agent可理解的语义 API”，并与 Agent 的任务计划机制打通（Plan → Tool → Data Interface）。

也就是说，这种“面向 LLM 的老数据访问”只是过渡，最终会转向 Plan-native / Tool-native 的数据结构。

而 db+nl2sql+catalog+MCP 目前仍旧是存量db面向llm升级的演进路径，也是“存量系统 Agent 化”的务实路线，我们可以把它理解为“Agent 化接入层”：适用于连接老系统，但不等于 Agentbase，因为它仍然没有 memory routing 和任务状态感知机制

如果 AI Agent 真的能将所有 IT 系统用任务链路重做一遍，那 Agentbase 协议一定是其前奏，也是圣杯。 

但我们只是触碰到了冰山一角。我们聊了这么多，其实尚未触及 plan/memory/tool 的 Routing 协议细节，比如任务状态的衰减、演化机制如何编码与调度，也没有提到现有系统的优劣与演化方向。

但有一点可以肯定：新的需求会带来新的工种！

伴随 Agentbase，会诞生：

• Agent 架构师：设计 Agent 的记忆模块、工具库和行为逻辑

• 意图设计师：定义人 → 任务 → Agent 的 prompt / context

• 数据智能调度员：负责 routing、token 优化、链路解释

一方面是旧的角色，比如 BI 报表、分析师手动拉数、ETL pipeline 开发，逐渐走向自动化或融合。

另一方面，是新的稀缺物种的崛起。

Agentbase 协议要落地，离不开 Agent 时代的“Memory infra 工程师”和他们的稀缺技能：

• 能理解任务状态如何演化（session memory）；

• 会设计 routing 与衰减机制；

• 能支持 multimodal 与 plan-native 的语义结构；

• 熟悉向量索引 / 多模态 embedding 存储 / LLM-friendly query。

这些远远超越传统 DBA 或引擎研发的 scope，薪资 +稀缺度都会上升。

实在的都说了，最后我想说，当下，是时代馈赠给每个人的礼物。让我用 Dead poet society 电影中的那句经典结尾：