大量企业的核心数据躺在 SQL 数据库里，但把 AI Agent 接进去通常意味着数据迁移、ETL 改造或另建向量库，成本高、风险大、周期长。RavenDB 推出的 Quill 主打「不迁移也能让 Agent 用上企业 SQL 系统」。
底层机制通俗拆解
Quill 在现有 SQL 系统之上架一层「语义接入层」——它理解数据库 schema 与业务语义，把 Agent 的自然语言意图翻译成受约束的查询与操作，并在执行前做权限与范围校验，而不是把整库导出给模型。换言之，Agent 看到的是「被授权、可解释的视图」，而非裸数据。
本次核心优化点
关键在于「零迁移」——保留企业既有的 SQL 作为系统事实源，Agent 通过 Quill 的语义层读写，避免数据副本带来的不一致与合规风险；同时把权限控制前移到查询生成阶段。
技术取舍与固有局限
一是语义层的质量决定 Agent 的可用性，schema 复杂或注释缺失时翻译准确率会下降；二是它更擅长结构化查询类任务，对需要跨系统编排、长链路工作流的复杂 Agent 仍需配合其他工具；三是权限模型需要企业事先梳理，Quill 不替你定义「谁能看什么」。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
同类方案对比
与另建 RAG + 向量库路线相比，Quill 的卖点是「就地接入」而非「搬运数据」；与「组织级记忆图」「工具调用前拦截」等方案相比，Quill 解决的是「Agent 如何安全读企业结构化数据」这一具体工程堵点。
开发者落地适配建议与踩坑提醒
若企业核心数据在 SQL 且不愿做大规模迁移，Quill 这类「语义接入层」值得试点；落地前先把 schema 注释、字段权责、行级权限梳理清楚，否则语义层会放大既有的数据治理问题。不要指望它替代完整的 Agent 编排框架，它解决的是「数据入口」而非「任务闭环」。