企业官网建设流程全解析

这两年做数据基础设施的人，应该都有一个很直观的感受：来自业务方的需求变味了。以前提的是“报表跑得慢”“接口超时”，现在开口就是“我们要给Agent开数据库权限”“Agent跑批的时候把生产库打满了”。我自己手上好几个项目，都在被同一个问题反复折腾——当AI Agent开始直接跟数据库打交道，原来那套为人设计的架构，从负载到权限，从存储到治理，几乎每一层都要重新捋一遍。这篇文章就把我在改造过程中踩过的坑、最终落地的方案，以及一些还在迭代中的思路，完整记录下来。

1. AI Agent 是怎么把数据库“打爆”的：负载冲击拆解

先说一个最容易忽略的问题：负载模型彻底变了。传统业务系统的负载是“人触发”的——一个用户点一下按钮，发一两个请求，我们预估QPS、规划连接池的时候，心里是有谱的。但AI Agent不是这样工作的，它是一个会“循环思考”的程序，一次任务执行下来，可能先在LLM侧推理好几轮，然后每一轮都要查数据、写中间结果、对比历史记录。我在一个项目里见过最夸张的情况：一个Agent任务在十分钟内发出了接近三千条SQL，其中一半是重复查询同样的热点数据。

更麻烦的是并发形态。以前双十一大促那种流量高峰，虽然QPS高，但请求类型单一，都是短平快的读操作。AI Agent的负载是“多路并发 + 长周期任务 + 读写混合”。比如业务方同时起了20个Agent实例，每个Agent内部又并行处理三个子任务，那同一时刻可能有60条协同SQL打到数据库上。如果其中几个是慢查询，比如一个没走索引的模糊搜索，直接能把连接池拖死，然后其余所有正常请求全部排队超时。我见过一次生产事故，就是Agent调用的一个联表查询因为数据量涨了，执行时间从200毫秒飙升到8秒，连接池被这几十个慢查询完全占满，整个后台系统跟着瘫痪。

1.1 为什么传统的连接池参数不再适用

很多人以为把连接池调大就行，这个想法在Agent场景下很危险。连接数不是越大越好，每个连接背后都有内存占用、线程开销，而且数据库侧对并发连接有硬限制。传统场景下我们通常把HikariCP的maximumPoolSize设为CPU核数的两倍再多一点，这个经验值我现在基本不敢直接套用了。

原因在于Agent的查询模式不均匀。传统业务是“一个请求过来，快速执行，释放连接”，连接在池子里的周转率很高。而Agent的查询是突发式的——Agent在思考的间隙突然发起一批查询，然后又去处理推理结果，这段时间连接是空闲占用的；下一个循环又突然来一批。结果就是连接池的“瞬时水位”忽高忽低，平均利用率不高，但峰值时刻很容易打满。

我现在的做法是两层：一层是数据库连接池本身，动态扩缩容，最小连接数保持5个，最大视数据库规格调整，但配合第二层——Agent调度层的令牌桶限流。每个Agent任务在请求数据库之前，必须先通过一个令牌桶获取配额，桶的容量和恢复速率根据数据库压测结果设定。这样一来，即使有几十个Agent在跑，真正打到数据库的并发查询也是可控的。

1.2 读写分离与查询路由改造

另一个有效手段是强制读写分离。Agent很多操作其实是读多写少，比如知识库检索、历史记录对比、上下文拼装，这些都是读操作。以前业务系统读多写少靠主从分离就够用，但Agent场景下，读的形态更加复杂：有些是短查询，有些是长分析查询，有些是向量相似度检索。

我的建议是，在数据库前面加一个查询路由层，根据SQL类型自动分发。短查询走主库或者从库都行，长分析查询强制走分析型副本，向量检索走独立的向量存储。同时要特别注意，Agent生成的自然语言SQL是不可信的，路由层必须做语法解析和分类，不能简单地把Agent的输出直接拼进SQL。

1.3 慢查询治理的“Agent 化”思路

传统的慢查询治理是事后看慢日志、优化索引、改写SQL。但Agent场景下，慢查询是常态，而且很难提前优化，因为Agent生成的SQL千奇百怪。我现在的思路是“双轨制”：第一，对Agent可能访问的核心表，预先建立覆盖索引，尽量减少全表扫描；第二，在数据库前面加一个查询规划器（Query Planner），对Agent发来的SQL先做代价估算，如果估算扫描行数超过阈值，直接拒绝执行，提示Agent改写查询。

这里有一个很实际的坑：Agent遇到“查询被拒绝”之后，往往会换个方式重试，有时候会用更差的写法再试一次。所以规划器的拒绝信息一定要结构化，最好是JSON格式，告诉Agent为什么拒绝、建议用什么方式查询，否则你会看到Agent在那里反复横跳，数据库被打得更狠。

2. 权限体系的重新设计：给 AI Agent 划定“行为边界”

权限这块，是改造中争议最多、也最容易翻车的部分。原因很简单：传统权限模型是为人设计的，人的操作有边界、有主观判断力，而Agent没有。给Agent开了一个“普通查询账号”，它可能真的会去查所有能查的表；给它开了写权限，它可能真的会把数据改了。

我见过一个真实事故：某个团队为了省事，给一个内部Agent分配了数据库管理员权限的只读账号，听上去只读没什么风险对吧？结果Agent在推理过程中“觉得”某个数据不对，尝试用UPDATE去修正——虽然最终因为只读权限失败，但日志里出现了一堆尝试性写操作，把安全团队吓得不轻。这个案例告诉我们，给Agent的权限不仅要“最小化”，还要区分“查询权限”和“操作权限”，而且最好是白名单模式，而不是黑名单。

2.1 从“人”到“机器”的权限模型转变

人的权限管理核心是“角色”：你是运营，你能看运营数据；你是管理员，你能看所有数据。但Agent不一样，Agent是一个程序，它没有“岗位职责”，只有“任务目标”。所以权限模型要从“角色”转向“任务”——每次任务发起时，Agent获取一个临时凭证，凭证里绑定这个任务所需的数据范围、操作类型和有效期。

我在项目中落地过一个方案：Agent在执行任务前，先向内部的权限服务申请一个短时凭证（比如有效期15分钟），凭证用JWT封装，包含允许访问的数据域（比如只允许华东区的数据）、允许执行的操作（SELECT和只读函数）、允许访问的表清单。数据库侧通过解析JWT的claims，配合行级安全策略，动态控制可见数据范围。任务结束凭证自动失效，不留长期有效的“Agent 账号”。

这样做的另一个好处是审计变得清晰。每个凭证对应一个任务ID，数据库日志里记录的每条查询都能关联到具体是哪个Agent的哪个任务发起的，出问题可以快速追溯。而不是像以前那样，一个共用的“agent_readonly”账号，查了什么都归到这个账号头上，根本分不清是哪条任务线。

2.2 行级权限与列级脱敏的落地

很多数据其实是“可以查，但不能全查”。比如一个客服质检Agent，它可以查用户的对话记录，但不应该看到用户的手机号、身份证号；一个区域运营助手，它可以查华东区的销售数据，但不该看到华南区。

行级权限在PostgreSQL里可以直接用行安全策略（Row Level Security）实现。我贴一段实际配置：

-- 创建用于Agent访问的数据库用户 CREATE ROLE agent_app; ALTER ROLE agent_app SET row_security = on; -- 在销售数据表上启用行级安全 ALTER TABLE sales_data ENABLE ROW LEVEL SECURITY; -- 创建策略：只允许访问 region = current_setting('app.current_region') 的行 CREATE POLICY agent_region_policy ON sales_data FOR SELECT TO agent_app USING (region = current_setting('app.current_region')); -- 示例：设置当前区域后查询 SET app.current_region = 'east_china'; SELECT * FROM sales_data LIMIT 10; -- 只会返回华东区数据

列级脱敏我用的是视图+函数的方式：定义脱敏视图，把手机号、邮箱等敏感字段用掩码函数处理，Agent只能访问这个视图而不能访问底表。注意，这里的关键是“Agent只能访问视图”这一条，必须在权限层就限制住，不能依赖Agent自己自觉。

MySQL的话，原生不支持行级安全策略，我的做法是在数据库前面加一个“语义网关”，所有Agent查询必须经过网关，网关根据任务上下文自动改写SQL，在WHERE条件里拼接上数据权限过滤条件。这个方案听着简单，做起来细节很多：要处理子查询、JOIN、聚合函数里的数据域字段，还要防止Agent通过带外查询绕过，比如用UNION、子查询嵌套等手法。

2.3 Agent 操作审计与熔断机制

权限不只是“能不能”，还有“操作是否符合预期”。Agent行为的不可预测性决定了我们不能只靠权限静态管控，必须加动态监控和熔断。

我在数据库层面做了三件事：第一，开启全量审计日志，记录所有Agent相关会话的SQL语句、执行时间、影响行数；第二，设置动态告警规则，比如一分钟内同一Agent任务执行了超过200条写操作，或者影响行数超过1万，立即触发告警；第三，熔断器——连续触发告警后，自动吊销该任务对应的临时凭证，强制Agent进入“降级模式”，只能查缓存或只读副本。

有一次线上出问题就是熔断器救场。一个测试Agent不小心陷入死循环，连续在订单表上执行UPDATE，虽然单条影响行数不大，但频率极高，如果没熔断，很快就会拖垮主库。告警触发后，我设置了“同一任务写操作超过100次/分钟即熔断”的规则，系统自动把这个Agent的凭证吊销了。事后排查，果然是代码逻辑里少了一个终止条件。

3. 存储架构升级：向量、对象与冷热分层

AI Agent带来的存储压力，很多人第一反应是“加硬盘”，但实际上面临的是存储形态的变化。Agent应用典型的数据结构有三种：业务关系数据（订单、用户、配置）、向量数据（Embedding向量、语义索引）、非结构化数据（对话记录、文档切片、图片）。这三种数据的存储需求和访问模式完全不同，混在一个库或者一种存储里，后果就是哪个都做不好。

我接手的一个项目就是典型例子。他们一开始把所有东西都塞PostgreSQL：业务表、对话记录、甚至Embedding向量都用JSON字段存。结果业务表越来越大，向量检索用的是内存里全量扫描，对话记录只能按月翻手工查。后来我帮他们拆成三套存储，性能立刻上了一个台阶。

3.1 向量存储选型与设计

向量存储是Agent应用绕不开的环节。选型上我给一个比较务实的建议：如果你的向量数据量在几十万量级以内，直接上PostgreSQL + pgvector扩展就够了，不用单独部署向量数据库。原因很简单：多一套系统就多一份运维成本，而且业务数据和向量数据放在一个数据库里，可以方便地做联合查询——比如“找到语义相似的内容，同时满足业务条件”。

-- 创建向量扩展 CREATE EXTENSION IF NOT EXISTS vector; -- 创建带向量的文档表 CREATE TABLE document_embeddings ( id BIGSERIAL PRIMARY KEY, doc_id BIGINT NOT NULL, content TEXT, embedding vector(1536) ); -- 查询与给定语义最相似的10条记录 SELECT id, content, embedding <=> $1 AS distance FROM document_embeddings ORDER BY embedding <=> $1 LIMIT 10;

但如果你预估向量数据会很快突破千万级，或者查询并发很高，建议还是单独用Milvus或Qdrant这类专用向量库。我自己的体会是：向量库在百万级以下是杀鸡用牛刀，在千万级以上就是刚需。还有一个容易忽略的点是向量数据的分区策略——如果Agent是一个多租户应用，每个租户的向量数据最好按租户ID分区，检索时先过滤租户再查向量索引，否则并发一高，向量库的检索效率会明显劣化。

另外强烈建议把向量数据的“原数据”和“向量”分开存储。向量表只存Embedding和文档ID，文档详情、业务标签放关系型数据库。这样矢量化表可以频繁重建，不影响业务数据完整性；也方便做冷热分离，把旧向量归档到对象存储。

3.2 冷热分层与存储成本治理

说完选型，再说存储成本。AI Agent会产生海量中间数据：推理过程的缓存、任务快照、日志、临时的Embedding计算中间结果。这些数据有个特点：越新的越热，越旧的越冷。我们统计过，一个Agent平台运行三个月后，超过80%的历史数据几乎不被访问。

我现在的存储治理思路是“热→温→冷”三层。热数据放在SSD或者本地NVMe盘，提供毫秒级访问；温数据放普通机械盘或云盘，保留几周到几个月；冷数据放到对象存储（比如MinIO或云上的OSS/S3），做生命周期归档。

对象存储这一层，很多人有一个误区：以为只有备份数据才进对象存储。实际上Agent场景下，对象存储是最适合存“非结构化、低访问频率”数据的地方。我把Agent的任务执行快照、历史会话记录、文档切片原始文件全部丢对象存储，关系库只保留索引和元数据。需要查询时先查元数据，再按需从对象存储拉取对应文件。

# MinIO 生命周期规则示例：30天后自动转为冷存储，90天后自动删除过期快照 POST http://minio-server:9000 # 通过 S3 API 设置生命周期规则 { "Rules": [ { "ID": "agent-snapshot-archive", "Status": "Enabled", "Filter": {"Prefix": "agent/snapshots/"}, "Transitions": [ {"Days": 30, "StorageClass": "COLD"} ], "Expiration": {"Days": 90} } ] }

这里有个运维细节要注意：生命周期策略的“天”是按对象最后修改时间计算的，所以Agent任务的快照文件命名最好带上任务开始时间，别用随机UUID，否则排查和处理过期数据都很难受。

3.3 数据生命周期与一致性管理

数据生命周期管理不只是“删旧数据”，还要考虑Agent的长期依赖关系。Agent在规划一个任务时，可能会参考它之前几周执行过的相似任务的数据和结果。如果这些历史数据被清理掉，Agent的“短期记忆”就断了。

我的做法是为关键任务建立“数据血缘摘要”。每条任务完成后，提取关键指标、结论摘要、涉及的数据表主键范围，存到一个小型的血缘元数据库。任务原始快照可以到期删除，但血缘摘要保留很长时间，这样Agent在后续任务中需要一个历史参考时，可以先查血缘摘要，必要时再从对象存储拉原始快照。既控制了存储成本，又保住了Agent的上下文连续性。

4. 数据治理新常态：从“被动救火”到“主动运营”

最后一个维度是数据治理。AI Agent时代的治理，难点在于“数据生产者从人变成了机器”。以前数据问题多数是人为的操作失误，现在Agent可能批量生产错误数据、重复写入相同内容、或者无意识地绕过既定流程，而且速度极快——一个Agent跑一小时产生的数据量，可能顶得上一个运营团队干一周。

我们团队在项目中踩过坑之后，确立了一条原则：Agent生产的数据，必须经过“治理检查点”才能进入正式的数据域。所谓治理检查点，就是一个Pipeline中的校验节点，Agent产出的数据先写到临时区，校验通过后再同步到正式区，而不是让Agent直接写正式表。

4.1 数据血缘与 Agent 行为追踪

数据血缘以前是数据仓库团队常提的概念，做指标溯源用。但在Agent场景下，血缘追踪变成了“安全追踪”——我需要知道一条数据是谁生成的、通过哪个Agent任务、用了哪些原始数据。传统的血缘工具大多适用于ETL流程，对Agent这种动态生成SQL的行为很难完全覆盖，所以我在实践中是“半自动血缘”：数据库层面开启审计日志记录SQL，Agent平台层记录每个任务的处理逻辑和数据源清单，两边按任务ID做关联。

-- 在数据库中创建一张血缘映射表，记录 Agent 任务与数据表的关联 CREATE TABLE agent_data_lineage ( task_id VARCHAR(64), agent_name VARCHAR(128), accessed_table VARCHAR(255), operation_type VARCHAR(16), -- SELECT / INSERT / UPDATE / DELETE row_count_estimate BIGINT, access_time TIMESTAMP WITH TIME ZONE DEFAULT now() ); -- 查询某个 Agent 最近一小时操作了哪些表 SELECT accessed_table, operation_type, COUNT(*) FROM agent_data_lineage WHERE access_time > now() - interval '1 hour' GROUP BY accessed_table, operation_type ORDER BY COUNT(*) DESC;

这里有个细节，别指望Agent自己会老老实实登记血缘信息，所有血缘数据必须由数据库代理层或API网关自动采集。凡是需要Agent主动上报的，最后都会因为遗漏而不可信。我自己的方案是用数据库的pgAudit扩展或MySQL审计插件，采集到血缘映射表，Agent平台侧不需要额外开发上报逻辑。

4.2 缓存治理：Agent 场景下的缓存穿透与一致性

缓存治理在Agent场景下特别容易出问题。核心原因还是Agent的“重试+循环”模式。传统用户查询如果没有命中缓存，大不了再查一次数据库，顶多慢一点。但Agent遇到缓存穿透，会在短时间内发起多次重试，直接放大流量；如果存在热点数据，多个Agent并发查询同一个key，就会形成缓存击穿。

我在一个知识库问答项目中，就因为这个吃了大亏。Agent的核心流程是“先查缓存，没有就查向量库，再做语义匹配”。结果关于某热点产品的问题，同时有几十个Agent实例在问同一个问题，缓存一开始没有，全部穿透到向量库，向量库瞬间过载，查询延迟从300ms涨到5秒，然后Agent开始自动重试，雪上加霜。

后来我们做了三件事：第一，热点key设置逻辑过期时间，不设物理过期——所谓逻辑过期，就是缓存里存的数据带一个过期时间戳字段，查询时如果发现逻辑过期不直接删key，而是先返回旧值，再用后台线程去刷新缓存，这样即使缓存过期，也不会造成穿透。第二，在数据库与缓存之间加了布隆过滤器，过滤掉那些明显不存在的查询key，避免把无效查询压力传导到数据库。第三，对Agent层做“缓存优先 + 失败退避”的策略，禁止Agent在缓存未命中后立即重试同一个查询，必须间隔至少200毫秒或者走随机退避。

Redis缓存治理还有一个常见问题——缓存一致性。Agent负责写数据时，经常是先写数据库再删缓存更新。我们用的是经典的Cache Aside + 延迟双删模式，但要特别注意删除的延迟时间必须大于慢查询的持续时间，否则一个Agent的旧读会把新数据又覆盖掉。

4.3 数据质量与合规审计

Agent产生数据的质量问题，比传统场景更隐蔽。传统数据质量关注“字段是否为空、格式是否正确”，Agent的数据质量问题是“内容是否合理、是否被污染”。比如Agent在推理过程中引用了不准确的历史数据，产出的新数据就会带着“污染”扩散。

我在治理检查点里增加了三类自动化校验脚本：

• 格式与完整性校验：必填字段不为空、数值范围合法、时间格式统一；
• 逻辑一致性校验：比如指标A应该等于指标B加指标C，如果不等式成立比例超过阈值就告警；
• 引用有效性校验：Agent写入的数据引用的外键、主键必须真实存在，避免产生孤儿数据。

合规审计我的做法是“拉链审计表”方案。主表数据允许Agent修改，但每次修改都把旧版本记录到审计表，保留完整变更历史。这样做有两个好处：一是出问题时可以快速回滚到指定时间点；二是审计人员需要查Agent改过什么时，有完整的证据链。表结构大致是：变更ID、任务ID、原值JSON、新值JSON、变更时间、变更操作人（Agent名）。数据量会涨，但审计表只追加不更新，压缩率很高，性价比完全值得。

写在最后：给正在改造的团队几个实在建议

说几个我自己踩坑后总结的经验。第一，所有给Agent的权限和凭证，都要默认“最小可用 + 临时有效”，不要因为嫌麻烦就开长期账号，线上近半的数据安全事故都出在“图方便”这三个字上。第二，连接池、限流、熔断这三样东西，必须在Agent上线前就配置好，不要等出了事故再补，Agent的流量暴冲速度比你想象的快得多。第三，存储冷热分层越早做越好，等存储满了再迁移，代价至少翻三倍。

最后分享一个我们内部现在还在优化的功能——把数据治理指标本身也接入Agent的运行时上下文。也就是说，Agent在决策之前，可以先感知当前数据库的健康状况（连接池水位、慢查询数量、缓存命中率），如果系统处于高负载状态，Agent会自动放慢节奏、降低并发。这条路走通之后，Agent跟数据库之间就不再是“一个猛冲、一个硬扛”的关系了。这个方向推荐大家持续关注，未来一定会有更多成熟实践涌现。