为什么你的 AI 应用做不成 Agent
一句话改库：为什么你的 AI 应用做不成 Agent
我想做的很简单：用户说一句话，系统生成 SQL，在生产库上执行增删改查，把活干完。
不是「帮我把上月销售额画个图」，不是「分析一下流失用户」——那些 BI、ChatBI、智能报表早就玩得转。我要的是改状态、插记录、批量更新、走业务流程，是 Text-to-SQL 加上自动 CRUD。
折腾一圈之后得出的结论很扫兴：这条路现在走不通，也不是你实现得不够好，是方向本身就不该无人值守。
下面把原因和唯一能上线的做法说清楚。
智能体很火，但真正跑起来的不是「全能员工」
先把营销滤镜摘掉。2025、2026 年真能规模化、愿意付费的场景，基本就三类：
- AI 编程—— 写代码、改配置、查问题，错了有 Git、有 diff、能回滚。
- 智能客服—— 答咨询、填工单，最坏情况是答错话，很少直接动账。
- 智能报表 / 问数—— 自然语言查数据，只读，查错了重新跑一条 SQL。
它们的共同点是：边界清楚、容错高、不碰核心写库。很多人总说「企业级智能体很难落地、有点扯」——大方向没错。难的不是模型笨，是数据脏、系统老、流程全是例外、出事没人背锅。
但这还不是最要命的。最要命的是：行业吹的「Agent 替你干活」，落到数据库上，几乎清一色停在「查」——没人敢让模型随便「改」。
我要的是「会改」，市场给的是「会查」
很多文章把 Text-to-SQL 和 Agent 绑在一起讲，仿佛自然语言生成 SQL 就是智能体的终极形态。
对开发者来说，需求其实更土、更具体：
用户：把订单 12345 改成已发货 系统：UPDATE orders SET status = 'shipped' WHERE id = 12345 AND ... → 执行 → 返回成功这就是Text-to-SQL + 写操作自动执行。Demo 里五秒钟能跑通，一上生产就崩。
大模型是概率系统，不是定理证明器。表一多、关联一复杂，它就会：
- 编错表名、字段名
JOIN漏条件WHERE丢了，更新变扫表- 搞错枚举、租户、软删条件
报表 SQL 错了，刷新一下。客服错了，改回复。生产写库错了，是事故。
所以不是「准确率能不能到 95%」——剩下那几个百分点，够你赔到离职。自由生成 SQL、无人审核、自动执行INSERT/UPDATE/DELETE，现阶段不该进生产，也进不了生产。
这不是你 alone 的困境。你想把业务系统做成「真 Agent」，卡在 Text-to-SQL 的幻觉上——说明你看对了问题，不是你没跟上潮流。
行业也在回避：查数可以吹，改库必须怂
各家 BI、云数据库 Copilot、企业助手，表面都叫 NL2SQL、都叫 Agent，拆开看套路几乎一样：
| 环节 | 常见做法 |
|---|---|
| 探索性查询 | 模型生成 SQL → 只读库 / 副本执行 → 能自动 |
| 写入、删除、改核心状态 | 预置接口、工作流、或人眼看 SQL 再点执行 |
| 宣传口径 | 「近 100% 问数准确」——说的是SELECT，不是UPDATE |
榜单上 Oracle、Snowflake、腾讯、阿里、蚂蚁在 Spider 2.0、BIRD 上分数很高，那是给定元数据、固定题库下的能力上限。Spider 2.0 这种企业级 benchmark 里，顶尖也就六七十分档；换你家十年堆出来的库表，没有文档、没有标准字段名，体验只会更差。
没有哪家敢承诺：任意自然语言 → 任意写 SQL → 生产库无人值守执行。敢这么干的，不是骗子，就是还没上过线。
那还能做 AI 操作数据库吗？能，但别让它「写」
「自由 Text-to-SQL + 自动 CRUD」是死路。能上线的架构只有一种逻辑：查询可以交给模型想，写入必须交给系统定。
1. 写操作：动作注册表（唯一值得全自动的写法）
不要让模型拼UPDATE。你提前定义业务动作，每个动作绑定测过的SQL 或 API：
动作：ship_order 参数：order_id SQL：UPDATE orders SET status = ? WHERE id = ? AND tenant_id = ?模型只干两件事：识别用户想触发哪个动作、抽出参数。SQL 文本不出模型，幻觉顶多是「12345 听成 12354」，不会变成「整张表被更新」。
这才是今天能在生产跑、能审计、能回滚的「AI 改库」。
2. 临时查询：Text-to-SQL，但只读
复杂分析、adhoc 查数，可以上 Text-to-SQL。账号只给SELECT，走从库或只读副本，错了重查。这里模型发挥空间大，风险也可控。
3. 绕不过去的写：人审 SQL
低频、规则说不清的操作：模型出 SQL → 界面展示 →人确认→ 再执行。灵活，但不是全自动 Agent，是 Copilot。
权限隔离（禁DROP、强制LIMIT、低权账号、事务回滚）能降风险，消不掉幻觉，只能当安全带，不能当方向盘。
架构就一张图，别搞复杂
用户自然语言 │ ▼ LLM：意图 + 参数抽取 │ ┌───────────────┴───────────────┐ ▼ ▼ 只读查询 写操作 Text-to-SQL Action Registry 只读库 / 从库 预置 SQL / 内部 API 可自动执行 可自动执行 + 审计 │ │ └───────────────┬───────────────┘ ▼ 高风险 / 非标准写 → 展示 SQL → 人工确认别在产品名里硬贴「Agent」三个字。对外可以说智能助手；对内要认清：Agent 不是会聊天的数据库客户端，而是「听懂人话的操作台」，真正动手的是你批准过的那几把扳手。
写在最后
智能体叙事里，最忽悠人的一句话是：「大模型已经能理解你的业务，可以直接操作数据完成任务。」
对查数，离这句话不算远。对改生产数据，还差一整条安全与责任链。
所以：
- 做不成「一句话随便改库」的 Agent 应用 ——正常。
- 继续死磕「模型自由生成写 SQL 并自动执行」——浪费。
- 先把业务里的写操作枚举成动作，让 AI 填参数 ——这才是现在能交付的东西。
AI 负责听懂；你的系统负责执行；危险操作永远握在人或规则手里。这不是向幻觉妥协，是在概率模型和生产库之间，划一条该划的线。