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 实例、共享一份权限、共走一条网关也正是这套底座上“111 3”的来源。具体的协同路径会在第 06 节展开。这样落地下来Agent 只需要对接一个网关地址与一把 API Key就能拿到三件套的全部能力。03 SupabaseAgent 的数据界面 × 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 平台的一站式 BaaSDatabase / 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 管代码执行与事件响应。让整套体系产生复利的不只是它们各自的能力还有它们之间灵活组合、任意串联的架构。把两两之间的赋能路径整理一下能力方向从 Supabase 获得从知识图谱获得从 Agent Runtime 获得Supabase—Ontology 让 RPC / Function 具备语义可寻址性Skill Hub 沉淀 BaaS 最佳实践Edge Function 的底层执行引擎Vibe Coding 应用的代码运行时知识图谱Storage 承载知识库文件Auth 与 RLS 提供权限Realtime 把 PG 数据变更实时投喂给 Ontology—Sandbox 执行 Skill 与分析脚本Edge Function 承载知识库自动更新的回调Agent RuntimeAuth 与 JWT 提供身份RLS 兜底权限Storage 提供文件读写Database 提供业务数据Ontology 提供语义地图Skill Hub 提供可复用的执行模板RAG 提供上下文与知识—从这张表可以看到任何两件套之间都存在相互赋能的路径。当三者编排到一起时能力空间不再是三个模块的并集而是三者组合出的场景空间。以下是几个已经落地的组合例子SaaS 化的 Agent 平台每租户一个数据库database per tenantAuth 决定“你是谁”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 如何替代数据团队排期数周的报表。三件套不再是架构图上的三个方块而是能自己干活的一套系统——我们下一篇见。 欢迎点击文末「阿里云登录 - 欢迎登录阿里云安全稳定的云计算服务平台」前往阿里云控制台体验 RDS PG Agent 开发能力。 欢迎钉钉搜索「103525002795」加入RDS PG 技术交流群与我们探讨 AI Agent 时代的数据底座建设。阿里云登录 - 欢迎登录阿里云安全稳定的云计算服务平台
)
)
