最近我在做数据库 AI 助手时，一直在反复思考一个问题：Agent 系统到底应该怎么设计？

一种常见路线是 multi-agent。把复杂任务拆成多个角色：规划、检索、执行、校验、总结。每个 agent 负责一个阶段，外层系统负责调度、汇总和失败恢复。

另一种路线是 single-agent tool loop。一个主 agent 持续观察当前上下文，根据任务状态决定下一步调用什么工具。工具返回结果后，agent 再继续判断，直到完成任务、发现风险，或者需要向用户澄清。

一开始，multi-agent 很容易让人觉得更工程化。它有清晰分工，有阶段边界，有调度流程，看起来像一个“AI 团队”。

但做完 AskDB 和 DBAide 之后，我现在更倾向于另一个判断：

对于数据库查询这类探索式任务，随着模型能力增强，single-agent tool loop 更自然，也更接近真实用户操作数据库的方式。Multi-agent 不是不能用，但它经常把一个连续的操作过程切碎，然后再用大量上下文管理和状态恢复把碎片重新粘起来。

一、Multi-Agent 的问题：它经常把连续操作拆成内部协作

Multi-agent 最大的问题，不是 agent 数量多，而是它会制造边界。

一个原本连续的任务，本来可以这样完成：

这是 tool loop。

但如果把这个过程拆成 multi-agent，就会变成：

这个结构看起来更完整，但它引入了额外成本：

每个 agent 应该拿到多少上下文？
上一个 agent 的结论是事实，还是推测？
某个阶段失败以后，应该回到哪个 agent？
用户补充信息以后，应该从哪个 checkpoint 恢复？
多个 agent 的判断冲突时，谁最终负责？
最终答案如何保证没有遗漏中间失败？

这些问题不是实现细节，而是 multi-agent 架构的核心成本。

所以 multi-agent 很容易出现一种“组织架构幻觉”：系统看起来像一个团队，但大量复杂度消耗在内部传话、状态同步和失败恢复上，而不是直接解决用户问题。

二、数据库查询更像一个人使用工具，而不是一群 agent 开会

数据库查询不是纯生成任务，而是探索任务。

如果用户问：

“最近 7 天付费用户最多的城市是什么？”

真正难的通常不是写出 GROUP BY city，而是这些问题：

哪个表表示用户？
哪个表表示订单或支付？
城市字段在哪里？
付费成功状态是什么？
退款要不要排除？
时间字段按创建时间、支付时间，还是完成时间？
用户和订单怎么关联？
一个用户多笔订单时要不要去重？

这些信息不应该由模型猜，也很难靠一次性 prompt 解决。

真实的人类操作数据库时，通常是这样做的：

这不是一个固定流水线，而是持续观察、持续决策、持续修正。

single-agent tool loop 正好对应这个过程。

它的核心不是“只有一个 agent”，而是“一个 agent 保留连续上下文”。它知道刚才为什么查这张表，为什么这个字段可疑，为什么这个 join 需要验证，为什么这条 SQL 需要重新生成。

如果把这些动作拆成多个 agent，每个 agent 只能看到被裁剪过的上下文，反而容易丢掉连续判断。

三、Multi-Agent 仍然有价值，但不适合被滥用

我不是否定 multi-agent。

当任务天然存在长期分工时，multi-agent 是合理的。比如软件工程中，一个 agent 写代码，一个 agent 跑测试，一个 agent 做 review；或者研究任务中，一个 agent 检索资料，一个 agent 阅读论文，一个 agent 做交叉验证。

这些任务里的角色边界是真实存在的。

但很多数据库查询场景不是这样。

数据库查询更像一个人坐在数据库客户端前，边看、边查、边写、边验证、边修正。它的关键能力不是“多角色协作”，而是“连续上下文里的工具使用”。

这也是我做完 AskDB 和 DBAide 后，对 agent 设计判断发生变化的原因。

四、AskDB：把 Text-to-SQL 做成强流程工作流

AskDB 是我对复杂 Text-to-SQL 工程化的一次完整探索。

它的核心思路是：不要相信模型一次性完成复杂查询，而是把任务拆开，用工程流程托住模型。

一个用户问题进来后，AskDB 会先判断它是不是包含多个查询目标。如果包含多个目标，就拆成多个子意图，并判断这些子意图之间是否存在依赖关系。

比如用户问：

“找出最近一个月购买金额最高的用户，并分析他们主要购买了哪些品类。”

这类问题天然可能拆成两个步骤：

先找出高消费用户；
再基于这些用户分析品类分布。

AskDB 会把这种依赖组织成 DAG。上游意图先执行，下游意图拿到上游结果后再继续。

在每个子意图内部，AskDB 也不是直接生成 SQL，而是走一套强约束流程：

这个设计的优点很明确：

它不把复杂问题直接压给模型。
它通过意图拆分降低单次推理难度。
它通过 DAG 处理多步骤依赖。
它通过 schema linking 控制模型看到的数据库范围。
它通过中间计划减少直接生成 SQL 的不稳定性。
它通过 SQL 校验和错误路由做失败恢复。
它通过用户澄清机制避免在业务口径不清时强行猜测。

从工程角度看，AskDB 是一个很完整的 multi-stage NL2SQL workflow。

它真正解决的是：当模型不够稳定时，如何用流程、状态机和校验器把模型包起来，让复杂查询尽量可控。

五、AskDB 的代价：流程越强，上下文管理越重

AskDB 的问题不是设计错误，而是这种路线天然很重。

因为一旦系统把连续查询过程拆成多个子意图、多个阶段、多个 agent，就必须维护大量中间状态。

比如：

当前用户问题被拆成了哪些子目标；
这些子目标之间有什么依赖；
每个子目标执行到哪个阶段；
当前阶段看到的是哪些 schema；
上一次生成的查询计划是什么；
SQL 校验失败的原因是什么；
应该回到 schema 选择、计划生成，还是 SQL 渲染；
用户澄清以后应该恢复到哪个位置；
最终汇总时哪些子任务已经完成，哪些没有完成。

这些状态都必须被保存、传递、恢复和解释。

也就是说，AskDB 的复杂度并不只在“模型调用多”，而在于它需要维护一个完整的 workflow runtime。

这让我意识到一个问题：

如果一个任务原本更像人类连续使用工具，那么把它拆成多阶段 workflow 之后，系统就必须额外维护很多“阶段之间的胶水”。

这些胶水包括状态协议、错误路由、上下文裁剪、checkpoint、resume、跨意图依赖和最终合成。

这些东西有价值，但它们不是免费的。

当模型能力较弱时，这种成本是值得的。因为系统需要替模型做规划和约束。

但当模型能力增强后，问题就变了：

如果模型已经能在一个连续上下文里判断下一步该查什么、该验证什么、什么时候需要问用户，那么是否还需要把这个过程拆成这么多阶段？

这就是 DBAide 选择另一条路线的原因。

六、DBAide：把流程控制交还给一个主 Agent

DBAide 没有把自然语言查询拆成一组长期 agent，也没有强制用户问题必须经过一条固定流水线。

它的核心是一个 single-agent tool loop。

这里的关键区别是：DBAide 不是 workflow 决定下一步，而是 agent 根据当前上下文决定下一步。

如果问题里表名明确，agent 可以直接查看对应表结构。
如果表名不明确，agent 可以先发现 schema。
如果 join 不确定，agent 可以检索关系。
如果 SQL 已经生成，agent 可以先校验。
如果校验失败，agent 可以根据错误修正。
如果业务口径不清，agent 可以暂停并询问用户。
如果 SQL 风险高，系统会要求用户确认。

这种设计更接近人类操作数据库的方式。

DBAide 并没有取消工程约束，而是把工程约束放在工具和安全边界里。

模型负责决定下一步。
工具负责提供确定性能力。
系统负责限制危险行为。
trace 负责让用户看到全过程。

这是我现在更认可的 agent 分工。

七、DBAide 的关键设计：不是简单，而是把复杂度放对位置

DBAide 的 single-agent loop 并不意味着系统更“简陋”。

相反，它保留了数据库 AI 助手真正需要的复杂度：

渐进式 schema 发现；
join context 检索；
SQL 生成；
SQL 校验；
Explain；
只读执行；
风险确认；
用户澄清；
会话内业务口径记忆；
agent trace；
Workbench 手工接管。

区别在于，DBAide 没有把这些能力做成多个独立 agent，而是做成主 agent 可以按需调用的工具。

这带来一个很重要的好处：上下文是连续的。

在数据库查询里，连续上下文非常重要。

比如 agent 先发现 orders.status 可能表示订单状态，但不知道哪个值代表支付成功。它询问用户，用户确认 status = 2 是已支付。后续 agent 再生成 SQL 时，这个确认就是当前会话里的事实，而不是某个阶段的临时输出。

再比如 agent 发现 users.city 可以直接用，但执行后结果明显为空。它可以回头检查过滤条件、时间字段或 join，而不是被固定阶段限制住。

这就是 tool loop 的优势：每一步结果都会改变下一步决策。

八、AskDB 和 DBAide 的本质差异

AskDB 和 DBAide 都在解决真实数据库查询问题，但它们的设计哲学不同。

AskDB 的核心是：

先把问题拆清楚；
再构建依赖；
再按阶段执行；
每个阶段有明确输入输出；
失败时根据状态机回退修复；
信息不足时暂停澄清；
最终汇总多个子结果。

DBAide 的核心是：

保留一个主 agent；
让它持续观察上下文；
把 schema、join、SQL、校验、执行、澄清都变成工具；
需要什么就调用什么；
不确定就问；
有风险就拦；
每一步都记录 trace。

可以用一张图概括：

AskDB 的复杂度主要在 workflow orchestration。
DBAide 的复杂度主要在 tool design、guardrail、run state 和 product experience。

AskDB 更适合验证一个强流程 Text-to-SQL 系统如何组织。
DBAide 更适合做成用户每天使用的数据库 AI 助手。

这也是我从 AskDB 走到 DBAide 后，对 agent 架构判断发生变化的原因。

我不再优先相信“更多 agent = 更强系统”。
我更相信“一个强 agent + 好工具 + 好边界 + 好 trace”。

九、为什么模型能力越强，Single-Agent Tool Loop 越合理

Agent 架构不应该脱离模型能力讨论。

弱模型时代，multi-agent / multi-stage 是一种合理补偿。因为模型难以稳定完成长链路任务，所以系统需要替它拆任务、定阶段、做校验、管状态。

但强模型时代，系统应该把更多动态决策权交还给模型。

不是让模型随便发挥，而是让模型在安全工具边界里行动。

这意味着：

系统不再预设所有步骤；
模型可以根据工具反馈调整路线；
上下文不再被多个 agent 切碎；
业务澄清可以自然进入当前 loop；
失败修正可以直接基于完整历史进行；
用户看到的是一条连续 trace，而不是多个内部 agent 的拼接结果。

数据库查询特别适合这种模式。

因为它本质上是探索、验证、修正，而不是一次性生成。

十、DBAide：一个本地优先的 AI Database Assistant

最后介绍一下 DBAide。

项目地址：https://github.com/W1412X/dbaide

DBAide 是一个 local-first AI database assistant。它支持 SQLite、MySQL/MariaDB、PostgreSQL，提供 CLI 和桌面端，并且 CLI 和桌面端共享同一个核心能力。

它不是一个简单的 SQL 生成器，而是一个能实际接入数据库、渐进式理解 schema、生成只读 SQL、校验 SQL、执行查询、解释结果的数据库助手。

DBAide 的核心能力包括：

自然语言查询数据库；
渐进式 schema discovery；
join context 检索；
只读 SQL 生成和执行；
SQL guardrail；
Explain 和风险确认；
不确定业务口径时主动澄清；
会话内记忆用户确认过的业务事实；
完整 agent trace；
CLI 和桌面端；
无 LLM 时退化为本地 inspection / profiling / guardrail 工具。

桌面端不是单纯聊天框，而是 Assistant + Workbench。

Assistant 用来和数据库对话，看 agent 每一步如何发现 schema、生成 SQL、校验、执行和解释。

Workbench 则更像一个只读安全版数据库客户端。用户可以查看 schema tree、浏览表数据、写 SQL、运行查询、Explain、格式化 SQL、查看 DDL、导出结果，并把 AI 生成的 SQL 接过去继续手工编辑。

这点很重要。

真实的数据工作流不是“问一句，拿一个答案”就结束。很多时候，用户需要在 AI 生成、人工修改、再次执行、继续追问之间来回切换。DBAide 的产品形态就是围绕这个真实流程设计的。

十一、Release 版本已经可用

DBAide 已经有 release 版本，可以直接下载桌面安装包使用，不需要从源码启动。

下载地址:https://github.com/W1412X/dbaide/releases/latest

支持：

macOS Apple Silicon：下载 DMG。
Windows：下载 MSI。
Linux：下载 x86_64 tar.gz。

也可以从源码安装：

git clone https://github.com/W1412X/dbaide.git
cd dbaide

# 桌面端 + CLI
pip install -e ".[gui]"

# 仅 CLI
pip install -e .

CLI 示例：

dbaide connect add local --type sqlite --path ./app.db
dbaide ask "Which cities have the most paying users?" --conn local
dbaide chat --conn local
dbaide inspect users --conn local
dbaide profile users --conn local
dbaide sql "select * from users limit 10" --conn local --execute

如果你正在做 Text-to-SQL、数据库 AI 助手，或者正在思考 multi-agent 和 single-agent tool loop 的架构取舍，可以看看 DBAide。

AskDB 是我对 multi-stage Text-to-SQL workflow 的一次完整探索。
DBAide 是我现在更认可的方向：一个主 agent，在安全工具边界里持续观察、调用工具、验证结果、询问用户，并把每一步都留在 trace 里。

未来的数据库 agent，不应该优先长得像一张组织架构图。它更应该像一个会使用数据库工具的人：知道先看什么，什么时候验证，什么时候执行，什么时候停下来问用户，并且每一步都可追踪、可恢复、可审计。

这就是 DBAide 想做的事。