Agent Native 实测：如何用 SQL 数据库搭建跨平台 AI 应用？

我们来研究一下 Agent Native。如果你正在找一个能真正让 AI Agent 操作业务数据的方案，而不是只在聊天框里“假装”干活，它可能是你目前能接触到的最接近“一等公民”设计的框架。但如果你只是想做个简单的 RAG 问答，用它就是杀鸡用牛刀，维护成本远超收益。

适合这三类人

  1. 全栈/SaaS 独立开发者：你想做类似 Notion AI 或 GitHub Copilot Workspace 的产品，Agent 需要理解当前页面上下文并直接修改内容，而不是让用户复制粘贴代码。
  2. 企业级应用重构团队：现有系统基于 SQL 数据库，希望在不迁移到向量数据库的前提下，让 Agent 安全地读写业务数据。
  3. AI 工作流工具开发者：你在研究 Cursor 很慢怎么办 这类问题时，发现瓶颈在于 IDE 与后端状态割裂，想探索一种 Agent 与 UI 深度绑定的新范式。

这两类人请绕道

  • 纯算法/模型研究者：这里没有训练脚本，只有工程架构。
  • 轻量级脚本玩家：如果你的需求是“读 PDF 总结摘要”，LangChain 或 LlamaIndex 的入门门槛更低，Agent Native 的 SQL + Nitro 栈对你来说太重了。

它到底解决什么痛点

大多数 Agent 框架的设计思路是“LLM + Tools”，UI 只是个附属品。这导致了一个致命缺陷：Agent 改了数据，用户刷新页面前看不到变化；用户在 UI 上点了按钮，Agent 不知道发生了什么。

Agent Native 的核心主张是 “Agent and UI are equal citizens”（Agent 与 UI 平等）。根据官方 README 和架构文档，它通过以下机制解决割裂感：

  1. 单一事实来源（Single Source of Truth）：Agent 的记忆、技能、任务状态全部存储在标准 SQL 数据库中（支持 Drizzle ORM 兼容的所有库）。这意味着你可以用熟悉的 SQL 工具审计 Agent 的行为，而不是去翻黑盒般的向量日志。
  2. 双向实时同步：利用 CRDT（冲突无关数据类型）技术，人类和 Agent 可以同时编辑同一个文档或状态。Agent 不再是后台异步跑完才返回结果的“批处理程序”，而是像协作者一样实时存在。
  3. 上下文感知（Context Aware）：Agent 知道用户当前选中的文本、所在的页面。这不是靠 Prompt 硬塞，而是框架层级的原生支持。这一点在 OpenClaw 深度解析 中也被提及为下一代 Agent 的关键特征——自主权依赖于对环境的精确感知。

真正值得试的能力

抛开营销术语，这三个能力在工程落地中最具价值：

1. Action 即契约，而非 Prompt

在传统方案中，UI 调用 API 和 Agent 调用 Tool 往往是两套逻辑。Agent Native 强制要求定义 defineAction。这个 Action 既是 HTTP 端点，也是 MCP 工具，还是 CLI 命令。

  • 场景：你写了一个“创建订单”的 Action。前端按钮点击触发它，Agent 在对话中也能调用它，甚至外部 MCP 客户端也能发现并执行它。一处定义，多端复用，且权限校验逻辑统一。

2. Per-User Workspace 隔离

很多开源 Agent 演示都是全局共享记忆，这在生产环境是不可接受的。Agent Native 原生支持基于 SQL 的用户级隔离。

  • 场景：每个用户有自己的 Skills、Memory 和 Sub-agents。这些数据存在关系型数据库的行记录里，而不是混在一个巨大的 Vector Store 中。这对于 SaaS 产品的合规性和数据安全性至关重要。

3. 三种产品形态无缝切换

这是我最欣赏的设计哲学。同一个 Agent 代码库，可以部署为：

  • Headless：纯 API/MCP Server，供其他系统集成。
  • Rich Chat：带原生渲染器（表格、图表、审批流）的聊天组件。
  • Whole App：完整的 SaaS 界面，Chat 只是侧边栏或模态框，与主应用状态完全打通。

这意味着你不需要为了“加个聊天功能”而重写整个后端。

上手要付出什么

别被“Serverless”和“Any Database”迷惑，上手仍有硬性成本。

快速体验命令

# 克隆仓库
git clone https://github.com/BuilderIO/agent-native.git
cd agent-native

# 安装依赖 (推荐使用 pnpm)
pnpm install

# 启动开发服务器 (默认使用 SQLite，无需额外配置)
pnpm dev

# 若需连接生产数据库，请在 .env 中配置 DATABASE_URL
# 支持 PostgreSQL, MySQL, SQLite 等 Drizzle 兼容库

隐藏成本预警

  1. Drizzle ORM 学习曲线：如果你习惯 Prisma 或 TypeORM，切换到 Drizzle 需要适应期。虽然 Drizzle 性能更好且更贴近 SQL，但它的 Schema 定义方式不同。
  2. Nitro 运行时约束：后端基于 Nitro（Nuxt 的底层引擎），这保证了跨平台部署（Vercel, Cloudflare, Node.js），但也意味着你不能随意使用某些 Node.js 专有 API。务必先查阅 Nitro 的兼容性列表。
  3. CRDT 复杂度：实时协作听起来美好，但调试 CRDT 合并冲突是噩梦级的。如果你的业务场景不需要多人+多 Agent 并发编辑同一字段，建议先关闭此特性，仅用普通 SQL 同步。
  4. 生态成熟度：相比 LangChain，它的插件生态还很年轻。遇到冷门集成（如特定地区的支付网关或非主流云服务），你可能需要自己手写 Adapter。

对比表：什么时候该用，什么时候别用

维度 Agent Native LangChain / LlamaIndex 传统 Web 框架 + AI SDK
核心定位 Agent-First 全栈应用框架 AI 编排与数据处理库 通用 Web 开发，AI 为附加功能
状态存储 SQL (Drizzle) 原生支持 向量数据库为主，SQL 为辅 任意，需手动对接 AI 状态
UI 集成度 极高 (双向同步, Context Aware) 低 (通常仅提供 Chat Widget) 中 (需自行实现 WebSocket/SSE)
部署灵活性 Nitro (Serverless/Edge/Node) Python/JS 运行时，较重 取决于框架本身
上手难度 中高 (需懂全栈 + Drizzle) 中 (Python/JS 生态丰富) 低 (沿用现有技术栈)
最佳场景 SaaS, 协作工具, 复杂业务流 RAG, 数据分析, 原型验证 简单 Chatbot, 现有系统微调
不适合 纯数据管道, 简单问答 强 UI 交互, 复杂事务状态 需要深度 Agent 自主性的产品

下一步验证路径

如果你决定试试，我建议按这个顺序验证，避免一上来就搞大项目：

  1. Day 1：跑通官方 Demo，用 SQLite 本地启动，体验“选中文字 -> Cmd+I -> Agent 修改”的完整链路。确认这种交互模式是否符合你的产品直觉。
  2. Day 2：尝试定义一个自定义 Action，并在 Headless 模式和 Chat 模式下分别调用。验证“一次定义，多处可用”是否真的省心。
  3. Day 3：将数据库切换为你实际使用的 PostgreSQL/MySQL，测试 Drizzle 迁移脚本。这一步最容易踩坑，提前暴露比上线前暴露好。
  4. 安全审计：检查 Action 的权限校验机制。Agent 能调用的 Action 必须经过严格鉴权，防止 Prompt Injection 导致越权操作。这点在 Shannon 渗透测试实测 中有过血泪教训，务必重视。

Agent Native 代表了 AI 应用开发的一个务实转向：从“让模型更聪明”回归到“让软件更好用”。它不承诺 AGI，但承诺你的 Agent 能像一个真正的软件组件一样被管理、被审计、被集成。如果你的下一个项目需要这种确定性，它就是目前最值得押注的开源选项之一。

参考链接：

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。