不只是 AI 问答，DBLens 把 Agent 真正带进 PostgreSQL 工作流

很多产品已经开始谈 AI，但在数据库工具里，AI 常常还停留在一个熟悉的位置：右边一个聊天框，用户提问，模型回答，偶尔帮你写几句 SQL。

这当然有用，但还不够。

数据库工作本来就不是一个“纯聊天”的过程。它需要上下文，需要对象结构，需要对当前库、当前 Schema、当前表有明确感知，需要知道什么时候应该先看 DDL，什么时候应该先查数据，什么时候又必须停下来，请用户确认风险。

这正是 DBLens for PostgreSQL 这次把 Agent 一起带上线的原因。

Agent 和普通 AI 助手，差别到底在哪

普通 AI 助手擅长回答问题。

Agent 的目标则是进入任务。

在 DBLens for PostgreSQL 里，Agent 并不是从一张白纸开始猜。它可以带着当前数据库上下文进入会话，包括：

• 当前连接
• 当前数据库
• 当前 Schema
• 当前选中的表、视图、函数或过程

这一步看起来不显眼，但意义很大。因为数据库问题一旦脱离上下文，AI 很容易答得“像那么回事”，却不够准；而一旦上下文明确，Agent 才有机会真的围绕当前 PostgreSQL 工作现场展开动作。

这次 Agent 已经具备的核心能力

围绕 PostgreSQL 场景，DBLens for PostgreSQL 当前已经搭建了第一阶段的 Agent 工具体系。

• 结构检索：先在当前 Schema 中检索表、视图、函数、过程，快速定位最相关对象。
• 结构摘要：读取指定对象的列、索引、外键、参数等摘要信息。
• DDL 获取：需要完整建表语句、视图定义、函数定义时，可以直接读取真实 DDL。
• 只读 SQL 查询：当任务本质上是查数据、做统计、看结果集时，Agent 可以进入只读查询流程。

这几类能力组合起来，Agent 才不再只是“会说”，而是开始具备“先找对象，再看结构，再做判断，再给答案”的工作链路。

更重要的是，它不是盲目行动

真正能落地的 Agent，不是会自动做更多事，而是知道什么时候该做，什么时候该停。

DBLens for PostgreSQL 在这次实现里，把几个关键约束前置了。

• 如果用户的意图明显是“看当前表有多少条数据”“先看前几条”，服务端会优先走确定性 SQL 路由，而不是把所有事都丢给模型猜。
• 如果模型工具选择错了，服务端会做一次硬路由纠偏，把明显应该查数据的请求改写到只读 SQL 查询工具。
• 如果命中了多个可能对象，Agent 不会瞎选，而是停下来让用户判断。
• 如果动作涉及文件覆盖、危险命令等高风险行为，系统会要求确认，不会默认直接执行。

换句话说，我们并不想做一个“看上去很智能、实际上不太稳”的数据库 Agent。我们更想做一个进入工作流之后，依然能让人放心的 Agent。

这对 PostgreSQL 用户意味着什么

对 PostgreSQL 用户来说，很多高频问题其实都很典型。

• 这个字段到底在哪张表里。
• 这个函数的参数和返回值是什么。
• 这个对象的 DDL 应该怎么拿。
• 先看一下当前表前 10 条数据。
• 帮我统计一下某个 Schema 下面有多少张表。

这些问题如果都只靠人手切页面、点对象、翻 DDL、敲 SQL，会非常碎。

Agent 的价值就在这里。它不是替代数据库工具，而是把数据库工具中本来已经存在的结构能力、查询能力、上下文能力重新串联起来，变成一条更自然的 PostgreSQL 工作路径。

数据库工具的 AI，正在从 Assistant 走向 Agent

这一两年，数据库工具已经普遍开始进入 AI 时代，但真正把 Agent 当成工作流能力来建设的产品，仍然非常少。

DBLens for PostgreSQL 这次选择把 Agent 直接带入正式版本，不是为了追一个概念，而是因为我们越来越明确地看到：下一代数据库工具，不该只是多一个 AI 入口，而应该重新定义人与数据库之间的协作方式。

我们希望 DBLens 在 PostgreSQL 这件事上，先往前走一步。

如果你已经厌倦了“数据库 AI 只能陪聊”的阶段，那么 DBLens for PostgreSQL 这次的 Agent 版本，值得你认真看一眼。

下载体验：访问 DBLens 官网