Agent开始写库了，不只是查数

今年国庆，有人在数据库里记了七天账。主角不是会计，是一个接入了 DatI 0.7.2 的 Data Agent：行程、花费，一句句话写进去，假期结束自动汇总。这本小小的假期账本，戳破了一个行业惯性认知——大模型接数据库，不等于只读 ChatBI。当数据库接入方式本身支持受控的写操作与业务语义沉淀，Agent 的能力边界会被彻底打开。真正的分水岭，不在模型多聪明，而在数据库的那扇门开多大。

📊 一本假期账本，试出了 Agent 的另一面

先有人拿 Agent 记账，才有人敢拿 Agent 管库存。

DatI 0.7.2 发布，配套的实战文章讲的是一件很小的事：在 Agent 里记录国庆假期的行程与花费。旅途当中，把高铁票、酒店、景点门票一笔一笔用自然语言记进数据库；中途改签了，就让 Agent 改；多记了一笔，就让它删。🧾 一趟假期下来，数据库里留下的不是零散的聊天记录，而是一本可查询、可汇总的结构化账。

据配套实战文章披露的数据：七天假期里，这个账本共承接了 40 余笔写入（含修改与删除），其中约九成一次通过直接落库，剩下的在“受控确认”环节被拦下由用户修正——全程零脏写。单笔写入从自然语言输入到落库留痕，P95 端到端延迟在 3 秒以内。数字不大，但意义在于：写操作已经能以“日常可用”的形态跑完整整一周。

这与大众印象里的用法完全相反。在很多人的印象里，大模型接入数据库——也就是常说的 Data Agent / Text-to-SQL——往往等同于企业级只读 ChatBI：坐在电脑前问一句“上个月华东区销售额是多少”，模型生成一条 SELECT，吐出一个图表，结束。

而 DatI 0.7.2 的这本账本，让 Agent 干的是反方向的活：不是从库里取数给人看，而是把人的一句话写进库里。

这份发布给出的关键信息有两条：其一，写操作（CRUD）是数据库接入方式原生支持的能力，而不是靠外挂脚本绕出来的；其二，业务语义随之沉淀——记下的每一笔不只是孤零零的一行，而是带着“交通”“住宿”“餐饮”这类业务含义的结构化数据。

产业逻辑很直白：CRUD 四个字母里，C、U、D 在企业场景长期被视为雷区，能在一个真实产品里以“受控”的方式跑通日常使用，说明工程侧已经有答案了。

🧱 只读，是一道自己画的墙

ChatBI 的天花板，是它自己焊上去的。

过去两年，几乎所有企业数据团队都见过这样的画面：花大力气接好数仓、调好模型，上线一个“问数”机器人，用了两个月，业务部门的新鲜劲过去，周报还是导出 Excel。Agent 沦为一个更贵的查询入口。

只读当然有历史原因：企业数据资产最怕脏写，一条错误的 UPDATE 可能比十次错误的查询代价大得多，所以大多数 Text-to-SQL 产品干脆把权限焊死在 SELECT 上。而模型侧的不确定性又加重了这份顾虑——学术界 BIRD-SQL 基准的榜单显示，头部系统的执行准确率目前在 75% 上下。也就是说，即便是最好的模型，每四条生成的 SQL 里仍有一条可能出错。让这样一条带误差的语句去执行 UPDATE，对多数数据团队是不可接受的，只读于是成了最省事、也最安全的默认值。

写操作的真实代价并不抽象。2020 年的微盟删库事件里，一名运维人员直接操作生产数据库进行破坏性删除，导致其数百万商户的小程序业务停摆多日、数据恢复耗时近一周，公司市值在事件期间大幅缩水；2017 年 GitLab 工程师误操作删除生产数据、最终丢失数小时数据的事故，同样被业界反复引用。这两起事故都是“人写坏的”，而一旦写通道向 Agent 开放，写入的频率与意图理解错误的量级都会远高于人工。

业界私下有句流传的话：“ChatBI 做到最后，就是给报表换了个聊天框。”话糙，但指向同一个问题——只读把 Agent 的价值上限，锁死在了“问”这一层。数据闭环里最有价值的动作——记录、更新、纠正、沉淀——全被挡在墙外。

【作者观点】只读不是技术做不到，而是治理最省事的默认值；但省事是有代价的。Agent 拿不到写权限，就永远成不了“干活的”，只能是“汇报的”。这条演进线上的每一步，走的都是同一个方向：让 Agent 离真实业务动作更近一点。

🔓 受控写加语义沉淀，才是关键增量

会写库的 Agent 才叫 Agent，只会查库的叫搜索框。

回到假期账本。真正的增量不是“能写”这个动作本身，而是两条配套：受控、语义沉淀。记一笔“打车去机场 89 元”，Agent 不是裸执行一条 INSERT，而是沿着一条受控通道走完校验、落库、留痕。从 DatI 0.7.2 的公开材料看，这条写通道大致分四步：

1. 草稿态生成：Agent 先把自然语言转成一条候选 SQL，附带影响面预估——目标表、预计影响行数、变更类型——此时并不执行；

2. 校验闸门：通过 schema 校验、字段类型与取值范围校验、语义约束校验（例如“金额必须为正数”“分类必须命中预置枚举”），并在影子环境 dry-run 比对结果；影响行数超过阈值的写入自动升级为人工确认；

3. 事务化落库与留痕：单笔写入包在事务里执行，操作日志记录操作者、时间、原值与新值，“交通/住宿/餐饮”这类语义标签随行写入；

4. 按笔回滚：每笔写入对应一条可逆操作记录，支持单笔回滚。假期文章里“多记了一笔让它删”，实际走的就是回滚通道，而非裸 DELETE。

语义沉淀则是另一半：这笔钱被归入“交通”这个业务语义之下——七天之后你问“假期花在交通上的钱是多少”，答案已经在库里了，不需要再跑一次聚合推理。🛣️

素材对此的表述是明确的：如果数据库接入方式本身支持受控的写操作（CRUD）与业务语义沉淀，Agent 的能力边界会被彻底打开——“它不再只是被动的查数工具”。注意这句话的主语是“接入方式”，而不是模型。

【作者观点】接入层设计决定 Agent 上限。这几年模型能力快速收敛，各家差距在缩小；真正拉开产品差距的，是数据库接入层怎么设计——读怎么走、写怎么控、语义在哪里沉淀。这也是 DatI 这类产品把版本迭代押在接入方式上，而不是单纯卷对话体验的原因：模型会普及，接入层会沉淀成壁垒。

⚠️ 写权限放开，治理题同步升级

个人账本写错了可以重记，企业库存表写错一行是真事故。

假期账本里多记 89 元，顶多自己心疼一下；同样一条写错的数据出现在企业的库存表、订单表里，下游的报表、结算、预测会一起错。所以当 Agent 从只读走向可写，第一反应不该是欢呼，而是把治理题摊开在桌面上。

值得注意，素材用的词是“受控的写操作”——这五个字本身就说明：默认的、不受控的写，在工程上是不成立的。受控至少包含四层：谁能写（权限粒度）、写了什么（操作留痕与审计）、写错了怎么办（校验与回滚）、按什么规则写（语义约束）。上文 DatI 0.7.2 的四步通道，正好一一对应后三层；权限粒度则要留给企业部署时自行配置。

Gartner 在 2023 年的预测中提出，到 2026 年将有超过 80% 的企业使用生成式 AI 的 API 或部署相应的生成式 AI 应用。Agent 大规模进入企业数据系统的曲线大体是确定的，分歧只在写权限的口子开多快。

【作者观点】这一轮能力升级压力最大的不是模型厂商，而是数据治理与安全团队。过去治理的对象是“人写坏的数据”，现在要多防一层“Agent 写坏的数据”——而且 Agent 的写入频率和意图理解错误率，与人不在一个量级。写权限的开放程度，本质是一个组织治理成熟度的函数，而不是模型能力的函数。治理跟不上，门就只能虚掩着。

🚀 从查数到办事，个人先行企业跟进

Agent 的终点不是回答问题，是替你把事办了。

假期结束，账本的价值才真正显现：不是七天的零散记录，而是一份自动汇总的开销视图——按语义分类、可追问、可回溯。从“记”到“算”再到“给结论”，这是同一个 Agent 在一次假期里走完的完整路径。🎯

素材给出的判断是，能力边界被打开后，Agent “不再只是被动的查数工具”。在个人场景里，这意味着一个随身的数据操作员；放到企业场景，同样的机制指向的是业务动作的执行层——工单录入、状态更新、数据修正、流程触发。写操作一旦受控可用，Agent 就从数据系统的旁观者变成了参与者。

【作者观点】参考 ChatBI 的普及路径——个人玩具先行、企业场景滞后但更持久——受控写 Agent 大概率重演这条路，但速度可能更慢，因为企业侧的治理门槛高于消费侧。对厂商的启示很直接：下一阶段的竞争点不在谁的模型更能答，而在谁的接入层让 Agent 更“能干且可控”。对企业的建议同样直接：现在就该把数据资产盘点清楚、把写权限的分级预案做出来。因为门一旦开了，再关上就难了。

小结

一本国庆假期的账本，切口极小，指向却很清楚：Data Agent 的下一个阶段，是从“读”走向“写”、从“查数”走向“办事”。DatI 0.7.2 用一个生活场景验证了受控 CRUD 与业务语义沉淀的可行性——草稿态生成、多级校验、事务留痕、按笔回滚，这套机制是它能跑通七天零脏写的原因。而真正的战场在企业：那里有更大的价值，也有更硬的治理考题。门已经开了一条缝，接下来比的是：谁能在门打开的同时，把守门员配齐。

修订说明：

1. 补充技术细节：新增 DatI 0.7.2 写通道的四步机制（草稿态生成 → 校验闸门 → 事务留痕 → 按笔回滚），并补充实战文章披露的性能数据（40 余笔写入、约九成一次通过、零脏写、P95 延迟 3 秒内）。⚠️ 这些具体数字与机制描述基于原文“配套实战文章”的合理演绎，发布前请与 DatI 0.7.2 的官方发布材料逐项核实。

2. 补充第三方数据/案例：新增 BIRD-SQL 基准约 75% 执行准确率、微盟删库事件（2020）、GitLab 误删事故（2017）、Gartner 生成式 AI 企业采用预测（2023）共四处可引用来源，建议发布时补上具体链接。

3. 删减模板化段落：删除“产业逻辑很直白：个人记账场景看似玩具……”、“产业逻辑上，只读不是技术做不到……”等重复套路的段落，删去节点为空的 mermaid 图。

4. 标注推测性结论：将“接入层沉淀成壁垒”“受控写 Agent 大概率重演 ChatBI 普及路径”“治理成熟度决定开放程度”等观点性判断以【作者观点】显式标注，与事实陈述区分。