人点几十次，Agent 发几万次：数据库架构的四个改写

大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

上个月帮一个团队看库，碰到件怪事。这套系统稳定跑了三年，一直没出大问题。上个月接入了 AI Agent，做智能客服和运维助手。上线才一周，告警就没停过。连接数天天打满，慢查询数量翻了一倍。最离谱的是一个检索需求，Agent 要跨两个库拼数据，延迟从几十毫秒飙到两秒多。DBA抱怨："这库以前好好的，怎么接了 Agent 就崩？"

我盯着监控看了半天，问题不在 Agent，在这套库本身。它是按"人"的使用习惯设计的。人一天点几十次，Agent 一小时能发几万次请求。用户变了，架构没跟着变。人用库，慢一点、偶尔卡一下，忍忍也就过去了。Agent 不行。它一次任务要连着调几十次，任何延迟和抖动都会被放大。这套按人设计的库，扛不住 Agent 的用法。下面这四个地方，得重新想一遍。

一、负载模型：从低频交互，到高频细碎

人用数据库是什么样？打开页面，点一下，看一眼结果。一次请求带走一批数据，事务拉得长，并发也不高，几百个连接就够用。Agent 不是这个节奏，它干一件事，要拆成几十次工具调用：查一次表结构，读一次数据，再写一次结果。每次都是独立的短请求，间隔以毫秒计，并发量一下子被拉高几个数量级。

这套节奏打到架构上，最先绷不住的是连接。按人数估的连接池，撑不住 Agent 的请求密度。连接得能复用，扛得住瞬时高峰。会话管理也得重想，Agent 的调用大多无状态，没必要为每次请求挂一个重会话。

事务粒度同样要重新划。人习惯一次做完一件事，长事务很常见。Agent 的请求碎，事务也得切碎，否则锁一挂，后面全堵住。MCP 最近的调整也印证了这个方向，2026 年 7 月发布的规范修订版，把协议核心改成了无状态，让服务端能弹性扩展，扛住 Agent 的调用量。

二、接口与权限模型：从"人写 SQL"，到"Agent 调工具"

人访问数据库，靠写 SQL，或者点工具生成 SQL。权限模型也顺着这个来，按"人加角色"授权，审计记的是谁改了哪一行。Agent 进来的方式不一样，它不写 SQL，它调工具。数据库得把取数能力封装成一个一个工具，让 Agent 按意图调用。这一步，把权限模型整个改了。

授权对象变了，不再只是人，还有 Agent。要给每个 Agent 一个独立身份，只开放它该用的工具，只给它该读的表和行。审计的颗粒度也变了。以前记的是谁改了数据，现在要记哪个 Agent、在哪个任务里、调了哪个工具、拿到了什么，出了事这条链要能完整还原。还有一层，是让库对机器更友好。表要有清晰的注释，字段要有语义说明，Agent 才不容易取错数据。这些以前是给人看的文档，现在成了给机器用的接口。落到做法上，给 Agent 的账号只给只读，用不到的权限一律不开，这是最基本的底线。

三、存储模型：从"一库一模型"，到多模融合

前两条改的是怎么连、怎么管。第三条改的是库本身，也是我觉得最要命的一条。人用库，数据类型简单，业务表多数是结构和文本，一个关系库基本够用。AI 业务一来，数据类型就爆炸了。Agent 要有记忆，得存向量；系统要有日志，得存文档；设备要有读数，得存时序。

很多团队的处理方式是每种数据配一个库，向量库单独部署，业务数据放关系库。人用的时候这样也行，Agent 用起来就出问题了。Agent 要取一条知识，往往得同时做三件事：语义检索找相似的，按权限和状态过滤，再关联业务数据补全信息。分成两个库，它得先查向量库拿 Top-K，再回关系库拼权限，应用层把结果拼起来。至少两次网络往返，延迟翻倍，代码也翻倍。还有一层在数据一致性，两边的权限一同步不及时，Agent 就可能吐出越权的内容。

出路是把这些数据模型收进一个内核，也就是多模融合。向量和关系数据在同一个库里，一条 SQL 就能同时完成语义检索、标量过滤和业务关联。我接触到的方案里，金仓 KES V9 走的就是这条路：关系、时序、GIS、文档、向量五类数据收进一个引擎，共用一套 SQL 接口。举个我刚碰到的场景，电网调度里，Agent 要同时看分钟级的负荷时序、设备的台账关系、供电区域的 GIS。三样放在一套库里，一条 SQL 就能关联出来；分成三个库，光数据准备就得写一堆胶水代码。

变化很清楚，数据不用搬了。Agent 要的结果，一次查询就能拿到。开头那个两秒延迟的检索需求，换成这套架构，压根不用跨库。

向量这一块，我是自己跑过的。KES 的向量检索不是外挂插件，是内核里的能力，用 VECTOR_DISTANCE 函数算相似度，一条 SQL 就能把向量检索和标量过滤一起做掉。难的地方在事务，标量数据的更新和向量索引的构建在同一个事务里，故障时不丢数据。金融、政务这类场景很吃这一点。

测试环境里我拿真实数据跑过一轮。4 核 8G 的机器，SIFT-1M 数据集，100 万条 128 维向量，HNSW 索引参数 M=16、ef_construction=200。召回率超过 95%，查询响应稳定在 50 毫秒以内。空表跑出来的数字不算数，真实数据加上过滤条件，才是能上生产的水准。

四、成本与治理模型：从"事后监控"，到内建限流

Agent 的请求量，可能是人的百倍。这话不夸张。人一天点几十次，Agent 一次任务就能发上千次。带宽、CPU、存储成本，都会跟着涨。按过去事后看监控的方式管，早就超支了。

治理要往前提，落到架构里。每个 Agent 要有独立的配额，用到多少算得清。阈值到了要限流，别让一个失控的 Agent 把整库打满。异常时要能自动熔断，切断请求，等人来处理。这些以前靠人盯，现在得靠系统自己扛。数据库如果能原生提供这些能力，治理和访问就能在同一层完成，不用再挂一套外挂。多插一件东西，就多一处会出故障的地方。

举个具体的。一个巡检 Agent 要是没配额，半夜跑飞了，可能把全库扫一遍，第二天的账单能吓人一跳。配额和熔断不是锦上添花，是给 Agent 划的边界。

五、一个真实案例：智能客服的检索困局

讲个具体的。一个智能客服的知识库场景。Agent 要回答用户问题，得从知识库里检索文档，同时判断会员等级、过滤已下架内容、按权限返回不同的结果。用分库方案，这套逻辑得写在应用层，先查向量库拿相似的文档，再回业务库查会员等级和权限，最后在代码里拼一遍。写起来麻烦，跑起来更麻烦，一次问答至少两次跨库往返。

换成KES Vector，一条 SQL 就完了。

-- 向量检索 + 标量过滤 + 权限关联，一次完成
SELECT d.doc_id, d.title, d.content,
       VECTOR_DISTANCE(d.embedding, :query_vec, COSINE) AS similarity
FROM knowledge_docs d
JOIN user_permissions u ON d.doc_id = u.doc_id
WHERE u.user_id = :current_user
  AND d.status = 'published'
  AND d.member_level <= :user_level
ORDER BY similarity
LIMIT 10;

这条 SQL 的意义，在于把检索和管控放在了一起。Agent 拿到的结果，天然是过滤过的，不会再出现越权的情况。少了应用层那段拼接代码，也少了一处容易出错的地方。

六、给决策者的四问框架

把前面几条收一收，我压成一个四问框架。要给 Agent 改造数据库，带着这四个问题去验。

四格都过，这套库才算为 Agent 准备好了。只做了第一格就上手，后面三格都会变成坑。

七、避坑清单

最后列几条我踩过、也见别人踩过的坑。

第一条，别按人数估连接池。Agent 的调用密度和人不是一个量级。上线前先压测，把瞬时并发拉满看看，连接撑不撑得住。我见过一个团队，上线当天连接数就打满，服务直接不可用。

第二条，别让 Agent 跨库拼数据。跨库查询看着简单，延迟和一致性都会出问题。能在一个库内完成的，就别拆到两个库。

第三条，向量检索一定要带真实过滤条件测。纯向量跑得再快，加了权限和状态过滤未必稳。空表、干净数据集跑出来的数字，别拿来选型。

最后一条我自己踩过。给 Agent 的账号，一开始图省事用了共用的管理员账号。后来审计对不上，排查了半天不知道是谁调的。给 Agent 单独建账号，从第一天就做，别等出事再补。

写在最后

这波变化说到底，是数据库的用户变了。人用库，求的是稳和够用；Agent 用库，求的是高频、确定、能管控。按人设计的库，接上 Agent 就会处处别扭。四件事要一起改：负载模型、权限接口、存储模型、治理模型。其中最容易被低估的是存储，Agent 要的检索和管控，尽量在一个事务里完成，多模融合这条路，正好接住了这个需求。

跑能源、轨交的项目，KES 见得比较多。它的思路就是把关系、时序、GIS、文档、向量收进一个内核，向量检索和业务数据同库同事务。至于对不对得上你们的需求，拿真实数据跑一遍 POC 最实在。

你所在的团队，数据库主力用户还是人，还是已经有 Agent 在跑了？架构上遇到最大的别扭是什么？评论区聊聊，咱们互相避坑。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋