作者：裘昕(日近)

01 前言：回望第一篇 —— PostgreSQL 作为 Agent 的数据底座

上一篇《当 80% 的数据库由 AI 自动创建，我们需要一个什么样的 PostgreSQL？》讨论了一个基础问题：AI Agent 时代的数据底座，究竟应该长什么样。

我们的回答可以概括成三条主线。

• 多模态——普通表承载业务对象与状态，jsonb 承接 prompt、工具参数、trace metadata 等结构不固定的输入输出，pgvector 保存 embedding、构建 Agent 的语义感知能力，AGE 图插件管理实体与关系、编织 Agent 的逻辑推理能力，一个 PG 实例即可覆盖 Agent 数据环境的绝大多数模态。
  
• 事务保障——关系数据库根基提供的 ACID、约束、WAL 与 PITR，让常规行存数据成为 Agent 可信赖的事实基准，避免“半成功”、状态漂移、重复触发。
  
• 云上增强——从 database per tenant 隔离增强、PgBouncer、SQL 限流，到基于云盘写时复制的秒级数据分支，再到内核级向量与图能力的深度优化，RDS PG 把开源 PG 的红利落到了生产可用的水位线之上。
  

但如第一篇结尾所写，数据底座不是终点。一个能跑的 Agent 系统，除了数据库，还需要：一套让 Agent 直接调用而非硬写 SQL 的数据接口、一个能沉淀企业知识与业务语义的认知中枢、一个能安全执行代码的运行时。这三件事如果各自选型、各自运维、各自打通鉴权，工程复杂度会迅速失控。

于是，我们把这三件事做成了一体化的 Agent 三件套：Supabase + 知识图谱 + In-DB Agent Runtime，全部构建在同一个 RDS PostgreSQL 之上，对外通过同一个 Kong 网关暴露。本篇即是对这套能力的完整拆解。

02 One Gateway, One Database：三件套的接入总纲

Agent 在真实生产里需要什么？它要访问业务表、要检索知识与记忆、要跑 Python 分析、要在事件触发时执行一段轻量逻辑。传统架构下，这四件事分别对应一套服务、一套认证、一套 SDK、一套限流策略，Agent 端要为每一路对接单独维护凭据。

我们选择的路径是 One Gateway, One Database——

• 最底层，只有一个数据库：RDS PostgreSQL，承载所有结构化 / 半结构化 / 向量 / 图 / 文件元数据，同时借助 Extension 生态覆盖检索、AI 调用、消息队列、API 暴露等场景。数据不搬家、SQL 方言不切换、心智模型不漂移。
  
• 最上层，只有一个网关：基于 Kong 的统一 HTTP 入口，向 Agent 暴露一个稳定的地址与一把 API Key。REST / GraphQL、Auth、Storage、Realtime、RAG、Sandbox、Edge Function 全部通过它路由，Agent 无需感知后端是几套服务。
  
• 中间层，是可灵活组合的三件套：Supabase 是 Agent 的数据界面与 Vibe Coding 的应用后端；知识图谱是 Agent 的大脑与长期记忆，通过 Ontology 为企业数据构建业务语义层；In-DB Agent Runtime 是 Agent 的双手，负责安全代码执行与事件驱动的轻量函数。
  

三件套并不是三个各自独立、只能“分别使用”的模块，而是相互依赖、相互赋能的关系。三者共用一个 PG 实例、共享一份权限、共走一条网关，也正是这套底座上“1+1+1 > 3”的来源。具体的协同路径会在第 06 节展开。

这样落地下来，Agent 只需要对接一个网关地址与一把 API Key，就能拿到三件套的全部能力。

03 Supabase：Agent 的数据界面 × Vibe Coding 的应用后端

RDS Supabase 完整继承了开源 Supabase 的能力栈——自动生成的 REST 与 GraphQL API、Auth 认证、Storage 对象存储、Realtime 实时订阅、Edge Function、Studio 可视化控制台——并把底层换装为 RDS PG，把对象存储对接到 OSS，把 AI 能力对接到百炼，把认证方式扩展了微信 / 支付宝 / 阿里云 SMS 等本土化通道，全链路运行在阿里云 VPC 内。

在 Agent 平台里，它同时承担两个角色。

角色一：Agent 的数据界面

对 Agent 来说，最可靠的操作数据的方式不是让它临场拼一条 SQL，而是给它一组自描述、带边界、可以直接当作工具调用的接口。这正是 Supabase 作为数据界面的价值：它把一个 PG 库自动映射成一层结构化接口，恰好落在 LLM 最擅长的 tool-calling 范式上。

Schema 即接口，接口即文档。REST / GraphQL API 由表结构自动生成，附带 OpenAPI 描述与类型化 SDK。Agent 无需理解底层表结构，直接把这些自描述接口当作 tools 加载，字段类型、参数范围、可访问表一目了然，输出空间被 Schema 明确框定——从“基于自然语言猜 SQL”转为“基于接口定义调 API”。

RLS 行级安全在数据库层兜底。越权拦截下沉到 PG，多租户 / 多 Agent 的隔离由数据库统一负责，应用层零代码。

复杂业务逻辑通过 Database Function 暴露成 RPC。Agent 按签名调用即可，无需理解 SQL，也不必把复杂逻辑塞进 prompt。

这层接口带来的收益不止于此，它在安全维度同样堵住了一条高危链路。业界针对 LLM 应用的安全反模式清单早已指出，“LLM 输出直喂 SQL / Shell”风险极高：LLM 输出中掺杂的自然语言极易被下游 SQL 层解析为可执行指令，Prompt-to-SQL 注入与数据投毒在真实生产应用中已被反复复现，攻击门槛并不高。当 Agent 只面对一组由 Schema 框定、由 RLS 兜底的接口时，注入面被显著收窄——安全性由结构与权限保障，而不是交给模型自觉。

角色二：Vibe Coding 平台的一站式 BaaS

Database / Auth / Storage / Edge Function / Realtime 五件套一站打齐，AI 生成的全栈应用可以“生成即上线”，无需再自建数据接入层。把开源 Supabase 带到阿里云、换装为 RDS PG + OSS + 百炼 + 本土化认证，用户既保留开源能力的完整心智模型，又获得云原生的稳定性、性能与合规。

这两个角色在底层完全同源——同一套 API、同一个 PG 内核、同一份权限模型。一套 RDS Supabase，同时支撑“Agent 数据接口”与“Vibe Coding 应用后端”两条增长曲线。

04 知识图谱：Agent 的大脑与长上下文记忆

如果说 Supabase 让 Agent “能取数”，那么知识图谱让 Agent “能理解、能记住、能推理”。

构建 Agent 记忆的范式，正在从碎片化存取（把记忆拆成 key-value 或 embedding 片段，检索靠向量相似度，片段一多反而越检索越噪）迁移到结构化认知（记忆以文件为载体，以 Ontology 本体为语义索引，以 RAG 为检索入口）。业界主流的知识管理工具与 AI Coding Agent 已经用“项目级规则文件 + 记忆目录 + 语义图谱”的本地方案，在小范围上验证了这条路径。知识图谱的差异化，是在其之上提供企业级云端能力——多租户隔离、细粒度权限、多版本管理、跨 Agent 共享，并与业务数据共用同一个 PG。

它由三个子能力组成，恰好对应人类记忆的三分法。

① 知识库 RAG —— Agent 的情景记忆

它不只是一个 RAG 检索管道，更是 Agent 的私密知识文件柜 + 版本化记忆存储层。企业核心文档、Agent 的结构化记忆（Markdown / JSON）统一托管，租户级隔离叠加细粒度权限；多模态解析引擎覆盖 PDF / Word / PPT / 图片 / 音视频 / 代码仓库；文件上传即自动触发解析、分块、Embedding、入库；检索侧融合向量语义、BM25 关键词、结构化过滤三路召回，再叠加 Rerank 精排；文件多版本管理让 Agent 的记忆能像 git 一样回到某个历史版本，用于回滚、A/B 或审计。

一个关键工程细节：文件元数据、向量、全文索引、结构化标签全部落在同一个 PG 实例里——一条 SQL 即可完成“向量相似度 + 关键词匹配 + 权限过滤”的混合查询，无需跨系统拼接；借助 RLS，多租户 / 多 Agent 的权限隔离下沉到数据库，应用层无需重复实现。

② Ontology 本体建模 —— Agent 的语义记忆

RAG 让 Agent “找到相关文档”，Ontology 让 Agent 理解数据之间的关系——可以把它理解为企业数据的语义地图。原始数据库里只有表和字段（“客户表”“订单表”），Ontology 在其之上定义了实体、属性、关系、规则的完整语义网络。数据库是图书馆的书架，Ontology 是分类系统 + 索引卡 + 借阅规则——有了它，Agent 才能“导航”业务，而不是一张张表翻。

Ontology 提供三重价值：

• 共识 —— 消除语义歧义。“客户”在销售系统里是“潜在线索”、在财务系统里是“付费账户”、在客服系统里是“工单发起人”，Ontology 定义一次、全局对齐；企业里大量隐性知识（业务规则、审批链、指标口径）从“老员工脑袋”里落到机器可读的显式定义；多个 Agent 协作时基于同一套本体，上下游对同一实体的理解不会各说各话。
  
• 边界 —— 约束 Agent 行为。Ontology 定义了“合法关系的全集”，LLM 无法凭空编造出诸如“实习生审批 CEO 报销”的越界关系；Agent 只能访问和修改本体中为其角色允许的实体与字段——这是比 RLS 更上层的语义级权限；每一步操作都可映射到本体规则，形成完整的“决策路径 → 规则依据”审计链。
  
• 确定性 —— 替代概率性推理。知道“张三→部门经理”且“部门经理→有审批权”，就能确定性推导“张三有审批权”，不需要问 LLM、无概率偏差、无 token 消耗；让 LLM 在长关系链上做多跳推理，跳数一多就容易“编关系”——凭语言相关性脑补出并不存在的连接；而 Ontology 的图查询是沿真实存在的边精确游走，天然支持任意深度多跳，不会无中生有。Agent 先用 Ontology 消化所有可确定推理的问题，只把真正需要创造性判断的部分交给 LLM，从而显著降低 LLM 调用成本。
  

这套确定性推理在复杂数据分析场景下尤为关键。业界权威的 Text-to-SQL 评测 BIRD（在近百个真实业务数据库上做端到端评估）显示：人类专家的执行准确率为 92.96%，而榜单最强模型也只到 81.95%，通用大模型 GPT-4 的 baseline 更是只有 54.89%——而且查询越复杂、嵌套与关联越多，一次性把 SQL 写对的概率越低。Ontology 的思路不是去赌那条复杂 SQL 能不能写对，而是把一个复杂分析问题拆解成若干小而确定的语义化原子计算：沿本体中真实存在的实体与关系逐跳游走、按规则做确定性推导，每一步都简单、可校验、可复用。从“生成一条复杂 SQL”到“编排一组原子计算”，准确性不再依赖模型运气，token 消耗也随之下降。

技术实现层面，Ontology 基于 Apache AGE extension 实现 PG 内原生图存储与 Cypher 查询，本体 Schema、实例数据、推理规则全部存在 PG 中。上一篇提到过，RDS PG 团队对 AGE 做了内核级增强——图查询与 DML 热点路径的工程优化，在兼容 openCypher 前提下带来百倍查询与 10 倍 DML 的性能提升，并把优化持续贡献回社区。图能力已在智能驾驶数据挖掘、财务经营分析、零售业务诊断、地产数据治理、智能运维故障诊断等场景落地。

③ Skill Hub —— Agent 的程序记忆

企业里最难沉淀的往往不是数据，而是“老师傅怎么做这件事”。Skill Hub 把原子分析模板、运维操作手册、行业最佳实践以结构化 Skill 的形式存储，配合语义召回、相似推荐、多版本管理，让新的 Agent 开箱即会做事，而不是每次从零推理。协议层兼容业界主流的 Skill 定义方式，已有生态积累的技能可以低成本迁入。

三个子能力为Agent串成一条清晰的认知链路：知道什么（RAG 检索）→ 理解为什么（Ontology 推理）→ 知道怎么做（Skill Hub 沉淀与调用）。

05 In-DB Agent Runtime：贴近数据的执行双手

Agent 的第三件套是运行时，要做的事情很朴素——安全地跑代码。但在 Agent 场景下，这件朴素的事情多了几条新要求：秒级并发拉起（一个会话就要拉起一个沙箱）、贴近数据（避免大数据在 Agent ↔ Agent Runtime ↔ DB 之间来回搬）、强隔离（Agent 生成的代码不可信）、多语言（Python / TypeScript / Bash / Java 都要覆盖）、生命周期与对话绑定（对话结束沙箱自动回收，也可以 7×24 长驻）。

In-DB Agent Runtime 的核心特征即“贴数据”——与 PG 数据模块无缝协同，减少跨服务的数据搬运。底层基于阿里云安全容器实现强隔离，上层通过 Kong 网关同时暴露两套接口：

• Sandbox（长时运行）：面向复杂数据处理、代码执行、工作流编排。沙箱与 PG 数据模块在同一 VPC 内直连，大数据处理无需在 Agent 与数据库之间来回搬运，天然贴近数据。File System 提供 Read / Write / Upload / Download / Watch 全套能力；Templates 覆盖 AI 编码、Compute Use、Browser Use、脚本运行、数据处理等常用模板，同时开放用户自定义镜像；Lifecycle 层面支持秒级并发拉起、自动休眠、Checkpoint 恢复。
  
• Edge Function（轻量触发）：面向事件驱动的轻量函数，与主流 Edge Function 开发体验一致，支持 HTTP / WebSocket / 数据库函数触发；TypeScript / JavaScript 编写，秒级部署。底层与 Sandbox 共用同一套隔离与调度实现——不同的只是生命周期与触发方式。
  

“贴数据”还有一层网络拓扑层面的含义。Agent Runtime 实例与 PG 实例、OSS 存储部署在客户同一个 VPC 内，Sandbox 和 Edge Function 在读写 PG 数据时走 VPC 内网直连，无需为数据库开放公网入口，链路全程不经公网出口。对于金融、政企、医疗等对数据主权敏感的行业，敏感业务数据在 Agent 执行代码期间始终留在企业自己的网络边界内，数据不出域、审计留痕、合规准入等硬性要求由底层网络架构天然满足。

06 协同：三件套如何 1 + 1 + 1 > 3

前面三节梳理了三件套各自的定位：Supabase 管数据接口与应用后端，知识图谱管语义、记忆与技能沉淀，Agent Runtime 管代码执行与事件响应。让整套体系产生复利的，不只是它们各自的能力，还有它们之间灵活组合、任意串联的架构。

把两两之间的赋能路径整理一下：

从这张表可以看到，任何两件套之间都存在相互赋能的路径。当三者编排到一起时，能力空间不再是三个模块的并集，而是三者组合出的场景空间。

以下是几个已经落地的组合例子：

• SaaS 化的 Agent 平台：每租户一个数据库（database per tenant），Auth 决定“你是谁”，RLS 决定“你能看到哪些行”，Ontology 决定“你能对哪些实体做什么”，Agent Runtime 拿着 Agent 的 JWT 执行代码就自动获得端到端隔离——跨租户越权在数据库层就被拦截，应用层零代码。
  
• Agent 自主数据分析：Ontology 拆解业务指标 → Skill Hub 提供分析模板 → Sandbox 执行原子计算 → Supabase 存储与推送结果，业务人员的一个 Prompt 就能完成过去数据团队排期数周的分析。
  
• Vibe Coding 平台：LLM 根据用户描述生成前后端代码 → 前端跑在浏览器 / 静态托管，后端直接跑在 Supabase 五件套上，Edge Function 落到 Agent Runtime 承载，多版本迭代由 RDS PG 的秒级数据分支支撑——生成即可上线。
  

这三个例子背后是同一套底层——一个 RDS PG 实例、一个 Kong 网关、三件套。而 Agent 对接的时候不需要感知这层结构：一个 Endpoint、一把 Key、若干条 REST 路径，就够了。

07 结语：从能力到落地

整个系列的脉络到这里可以先做一次串联。第一篇讲数据底座——为什么 PostgreSQL 是 AI Agent 时代的核心数据底座，以及 RDS PG 在多租户、数据分支、多模态检索三个方向的内核增强。这一篇讲能力——以 Supabase + 知识图谱 + In-DB Agent Runtime 组成的 Agent 三件套，如何在同一个 Kong 网关、同一个 RDS PG 之上，为 Agent 提供数据界面、大脑与双手，并通过相互赋能构成一套完整的开发平台。

能力的骨架搭到这里，接下来更值得看的是它在真实场景中的样子。下一篇是实践篇，我们会围绕一个完整的智能营销分析场景，把三件套端到端串起来——它由分析与展示两条线组成，却是同一个应用的一体两面：

分析线：Agent 自主完成建模与分析。Agent 运行在 In-DB Agent Runtime 的 Sandbox 中，基于知识图谱和Ontology本体完成业务建模、数据导入与分析，自主产出客户画像、流失预警、归因分析，业务人员用一个 Prompt 就能替代过去数据团队排期数周的报表开发。分析结果分两类落库——结构化结论写回 PG，图表等非结构化产物存入 Supabase。

展示线：Vibe Coding 出一个结果展示应用。这个展示应用无需手写数据接入层——它在 Edge Function 中直接调用 Supabase 自动生成的 SDK，查询上一步沉淀在 PG 与 Supabase 里的数据和图表并渲染出来，生成即上线。

两条线共用同一个 RDS PG、同一份权限、同一个 Kong 网关——分析与展示不再是两个割裂的 demo，而是同一个营销分析应用从"算出结论"到"看见结论"的完整闭环。从数据底座，到开发平台，再到真实业务的落地——这个系列会走完这条完整的路径。

如果说第一篇回答了“Agent 需要什么样的数据底座”、这一篇回答了“这套底座还差什么才能真正跑起来”，那么实践篇要回答的，就是它真正跑起来之后的样子：一个 Prompt 如何替代数据团队排期数周的报表。

三件套不再是架构图上的三个方块，而是能自己干活的一套系统——我们下一篇见。

👇 欢迎点击文末「https://rdsnext.console.aliyun.com/rdsSupabase/cn-hangzhou」前往阿里云控制台体验 RDS PG Agent 开发能力。

👇 欢迎钉钉扫描下方二维码加入「RDS PG 技术交流群」，与我们探讨 AI Agent 时代的数据底座建设。