为什么你的 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 SQLUPDATE 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 负责听懂你的系统负责执行危险操作永远握在人或规则手里。这不是向幻觉妥协是在概率模型和生产库之间划一条该划的线。