企业 AI 的核心矛盾不是有没有大模型，而是数据能不能被 Agent 安全、实时、低成本、可治理地调用
你的 AI Agent 在 Demo 里表现完美。它能回答客户问题，能检索知识库，能生成格式漂亮的报告。然后你把它接入了真实业务系统。
你的 AI Agent 在 Demo 里表现完美。它能回答客户问题，能检索知识库，能生成格式漂亮的报告。然后你把它接入了真实业务系统。
第一天，它根据昨天的库存数据，给客户退了一个已经下架的商品。第二天，它忘了上午刚审批过的流程，又重复提交了一遍。第三天，安全团队发现它读取了不该看的客户信息，没有留下任何操作记录。
模型很聪明。问题出在别处。
PingCAP TiDB APAC AI Business & Product Leader 李粒（Lux Li）给了一个更精确的判断：「企业 AI 的核心矛盾不是有没有大模型，而是企业的数据能不能被 Agent 安全、实时、低成本、可治理地调用。」
我和李粒聊了将近两个小时。他反复提到一个词：State Layer（状态层）。他认为 AI 应用从 Demo 走向生产的真正瓶颈，不在模型参数，不在推理速度，而在于没有人给 Agent 准备一个可靠的数据状态层。
AI 成功之后，问题才真正开始
李粒分享了三个他在客户中反复看到的场景。
场景一：AI 产品爆发以后，数据层先扛不住。
一家 AI-native 公司的产品上线后用户快速增长。一开始，团队最关注模型推理能力和用户体验。但规模上来以后，真正吃紧的不是模型，而是用户状态、会话记录、上下文、任务历史和分析需求带来的持续数据压力。
「很多系统可以靠分库分表、缓存、离线分析撑住早期，」李粒说，「但规模继续放大，数据链路会越来越复杂：交易数据在一处，分析数据在一处，日志在一处，用户状态又在另一处。短期能跑，长期就是运维噩梦。」
场景二：Agent 自己创建数据库，人类跟不上。
另一类 AI 应用的趋势更激进。Agent 不再只是查询数据库，而是自己创建应用、生成 Schema、读写数据。 当 AI 从「使用工具」变成「创建工具」，数据库面临的要求完全不一样了。
它要足够简单，让 Agent 容易调用。要足够弹性，支持大量短生命周期的工作空间快速启动。要有隔离能力，不同 Agent 和应用之间不能互相影响。还要成本够低，因为很多 Agent 创建的数据库可能只存活几小时。
场景三：上下文被拆碎了。
还有一类 AI 硬件和生产力工具公司。一个录音设备背后，可能同时存在音频文件、转写文本、会议摘要、任务项、用户标签、团队知识库和分享权限。很多团队把这些东西分别放在对象存储、向量数据库、业务数据库、搜索引擎和数据仓库里。
「这在早期很自然，但当 Agent 需要回答'这次会议提到的客户风险和上次相比有什么变化'时，它就卡住了，」李粒说。「这不是纯向量检索问题，也不是纯 SQL 问题。它需要同时理解文件、文本、结构化业务数据、历史记忆和实时状态。」
三个故事指向同一个结论：AI Demo 进入生产环境以后，最常见的卡点不是模型不够强，而是缺少一个统一、实时、可治理的状态层。
数据库不再是仓库
传统应用里，数据库的角色相对清晰：服务交易，支撑分析。用户点击按钮，应用写入订单、库存、支付、日志。流程确定，路径固定。
Agent 不一样。它不是执行固定流程，而是在不断理解、计划、调用工具、写入状态、修正计划。李粒认为，Agent 时代数据库至少多了六个角色：
运行状态中心。 Agent 的任务、步骤、计划、重试、失败、恢复，都要持久化。断线不能意味着丢失整条任务链。
长期记忆系统。 用户偏好、历史对话、操作习惯、业务事实，需要沉淀成可检索、可更新的记忆。
上下文组装平台。 Agent 每次行动前，要从结构化数据、文本、文件、日志、历史任务里组合出完整的上下文。
工作空间。 Agent 不只是聊天。它会生成代码、报告、表格、配置文件，这些都需要持久存储和版本管理。
权限和审计层。 Agent 代表人执行动作，每一步访问、写入、调用都要可追踪。
实时分析和反馈层。 企业要知道 Agent 做得怎么样、成本多少、哪些任务失败、哪些流程可以优化。
「所以 Agent 时代的数据库，本质上从后台存储变成了 Agent 的状态操作系统，」李粒说。
如无需要，勿增实体
判断的另一面是：很多企业在做 AI 应用时，数据系统越拆越多。
业务状态在 MySQL，文档在对象存储，向量在 Pinecone 或 Milvus，搜索在 Elasticsearch，分析在 Snowflake，任务状态在 Redis 或 Postgres。Agent 每完成一个任务，就要跨很多系统拼上下文。
李粒用了一句奥卡姆剃刀来概括这个问题：「如无需要，勿增实体。」
他列出了数据碎片化带来的五个代价：数据复制复杂，一致性变差，权限难统一，成本失控，工程复杂度指数上升。「Demo 阶段可以拼组件，生产阶段每条链路都要监控、重试、审计、恢复。系统越多，链路越多，越难管。」
意思像不像 × 事实准不准
在检索这件事上，李粒提出了一个很实用的区分。
向量搜索适合找「意思相近」的内容。用户问「退款规则」，系统能找到「退货政策」「售后条款」。但企业场景里还有大量内容必须精确匹配：订单号、合同编号、SKU、设备 ID、错误码、版本号、法律条款编号。语义相似度在这里帮不了忙。
「向量搜索解决'意思像不像'，全文搜索解决'事实准不准'，混合搜索解决企业 AI 能不能真正可信。」
TiDB 的混合搜索工作流是同时使用全文搜索和向量搜索，再通过 reranker 合并结果。这不是技术细节，而是企业 AI 从「能回答」到「可信赖」的关键一步。
从 RAG 到 Agent State Layer
很多企业 AI 的演进路径是类似的。
第一阶段做 Chatbot，关注回答是否流畅，界面是否好用。第二阶段做知识库和 RAG，开始发现检索质量、文档更新、权限隔离、知识过期是问题。第三阶段让 Agent 执行业务任务，后端数据架构问题才会真正暴露。
「当 AI 从'回答问题'走向'完成任务'时，企业就会意识到真正的问题在数据架构，」 李粒说。
RAG 可以帮 Agent 找到相关文档。但 Agent 要完成一个业务任务，它还需要查实时订单状态、根据用户权限读取数据、写入 CRM 或工单系统、保存任务中间状态、记住用户偏好、管理生成的文件和产物、失败后恢复。
这些都不是 RAG 能解决的问题。
不是万能数据库，是状态层的核心入口
李粒提出的 TiDB Agent State Layer 不是一个「万能数据库」的新包装。理解它需要分三层来看。
第一层是 TiDB 已经具备的底座能力。 分布式 SQL、事务一致性、HTAP（混合事务和分析处理）、向量搜索、全文搜索、混合搜索。这是数据库本身可以直接交付的硬能力。
第二层是面向 Agent 的架构范式。 Metadata 管理 Agent、任务、步骤、运行状态、审计记录；AgentDB 是每个 Agent 自己的长期数据空间；Memory 负责长期记忆、偏好、历史行为和事实抽取。这些更多是「如何用 TiDB 承载 Agent 状态」的组织方式，是一套架构方法论。
第三层是需要集成的外围系统。 文件原文、大对象存储、模型服务、embedding 服务、reranker、工作流编排、企业现有权限系统。这些不是 TiDB 要替代的，而是要与之协同的。
李粒自己也反复强调这个边界：「我们不是在说 TiDB 要替代所有系统，而是要成为 Agent State Layer 的核心与集成入口。」
TiDB 真正想争夺的是 Agent 生产化之后最核心的那一层：状态、记忆、上下文、任务记录、权限边界和实时分析的统一入口。文件、模型、工作流、对象存储仍然存在，但 Agent 每一步「知道什么、做了什么、能不能恢复、能不能审计」，需要一个稳定的数据状态层来承接。
以 Dify 这类 AI 应用开发平台的场景为例。知识库检索不只是「把文档向量化再做相似度召回」。真实业务里，开发者需要先按租户、应用、知识库、权限、标签、更新时间等结构化条件过滤，再做语义检索。TiDB 的价值不只是存向量，而是把 SQL 条件过滤和向量检索放到同一个数据层里，减少多系统拼接的复杂度。
对企业来说，最直接的收益不是某个单点性能提升，而是让 AI 应用更容易进入生产环境。Agent 可以在同一个状态层里查业务状态（用 SQL）、查上下文和记忆（用向量、全文、混合搜索）、做实时分析和决策（用 HTAP 分析能力）。三类能力放在一起，Agent 才能从「会回答问题」变成「能理解业务、执行任务、持续优化」。
当访问系统的不再是人
李粒反复提到一个概念：Agentic Scale。
过去访问系统的主要是人。人的点击频率有限，行为路径相对固定。未来访问系统的会是大量 Agent。一个用户背后可能有多个 Agent，每个 Agent 又有多轮推理和工具调用。
「这会带来完全不同的数据库压力，」李粒说。请求频率更高，状态写入更多，数据形态更复杂。结构化数据、向量、全文、文件、日志、记忆会混在一起。隔离性要求更强，成本模型也在变化。
「以前按用户访问量估算资源，现在要按 Agent 活跃时间、任务复杂度、状态写入量、上下文检索量来估算。」
这也是他认为「one agent, one database」有意义的原因：每个 Agent 应该拥有独立的数据边界和演化空间，而不是所有 Agent 共用一个巨大的全局状态池。
数据治理：从管人到管 Agent
AI Agent 越深入业务，数据治理的复杂度越高。
传统数据治理主要管人：谁能看什么表，谁能导出什么数据。Agent 时代，治理对象变成了「人 + Agent + 工具 + 动作」的组合。
企业需要回答一串新问题。这个 Agent 代表谁？能访问哪些数据？能不能写入生产系统？哪些动作需要人类确认？每一步操作能不能审计？生成的文件、结论、记忆是否可删除、可回滚、可解释？
「Agent 越深入业务，数据治理就越不能只管数据本身，而要管 Agent 如何理解、调用和改变数据。」
HTAP：让 Agent 参与正在发生的业务
金融、电商、物流、制造这些行业有个共同特点：业务状态变化快，同时需要实时分析。传统架构把交易系统和分析系统拆开，交易进 OLTP，分析进数仓。
但 Agent 不能等离线同步几小时以后再看分析结果。它需要在业务发生时理解状态、做判断、执行动作。
TiDB 的 HTAP 能力让事务数据和分析更接近，减少从交易库到分析系统之间的延迟和复杂同步。Agent 可以同时读取实时订单和库存状态，分析趋势和异常，在业务闭环里执行。
「HTAP 让 Agent 不只是事后分析业务，而是可以在业务正在发生时参与业务。」
APAC 市场：不要讲概念，告诉我能不能跑起来
作为 PingCAP TiDB APAC AI Business & Product Leader，李粒对亚太市场的感受是：极度务实。
「很多企业不是为了'做一个 AI 项目'而做 AI，」他说。「他们会直接问：能不能降低成本？能不能提升效率？能不能更快上线？能不能在合规边界内跑？能不能跟现有系统结合？」
和欧美相比，APAC 企业更关注落地速度和业务结果，对成本更敏感。大型企业强调安全、合规和本地部署；互联网和 AI-native 公司看重速度、弹性和架构简化。
他观察到 APAC 企业的需求正在经历三个阶段。
第一阶段：从模型体验到业务结果。 一开始关注模型能力和 Chatbot 效果，很快发现单纯回答问题创造不了足够的业务价值。真正有价值的是 AI 进入销售、客服、运营、风控等真实流程。
第二阶段：从知识库到实时业务系统。 最开始做内部知识库、文档问答，相对安全。一旦 Agent 要执行任务，就必须连接订单、客户、库存、合同、工单、支付、权限。这时 RAG 只是入口，后端真正需要的是统一的数据状态层。
第三阶段：从单点 AI 项目到生产级平台。 进入规模化以后，成本、安全、弹性和运维复杂度变成核心议题。
「企业正在从'我要一个 AI 功能'，走向'我要一个能支撑 AI 持续运行的数据底座'。」
最早有感知的行业是互联网和 AI-native 公司，它们最先遇到 Agent 高并发、状态管理和隔离问题。其次是金融，对一致性、权限、审计和实时风控要求高。然后是电商物流，有高频交易和实时库存。再往后是制造业和大型企业。
在全球化方面，亚洲 AI 企业同时面对业务增长快、市场分布广、成本压力大三重挑战。全球化 AI 应用不只是部署模型，还要部署记忆、状态、文件、权限和业务数据。开源带来可控性，云原生带来弹性，分布式数据库带来跨区域能力。
写在最后
我问李粒：未来三年，AI 对数据库行业最大的改变是什么？
他的回答不是某个功能。向量能力会成为标配，数据库和搜索会继续融合，实时分析会更重要。但更大的变化在角色层面：数据库会从应用后台的存储系统，变成 Agent 的上下文操作系统。
未来 Agent 不会只问数据库「这条数据是什么」。它会持续追问：我现在处于什么状态？用户偏好是什么？任务执行到哪一步？哪些文件可以用？哪些记忆可信？业务数据是不是最新？下一步可以采取什么动作？做完以后如何更新状态？
「模型让 AI 会思考，Agent 让 AI 会行动，而 TiDB Agent State Layer 让 AI 记得住、看得准、跑得稳、管得住。」
不管你是否看好 TiDB 的方案，有一个趋势判断可能没什么争议：企业 AI 的下一阶段，不是给数据库加一个向量字段，而是给 Agent 建一个状态层。
谁来建，怎么建，用什么建？这些问题值得每一个正在把 AI 从 Demo 推向生产的团队认真想想。
精选问答
Q：如果不用官方介绍，你会怎么向一个不了解 TiDB 的企业客户解释你们在做什么？
我们在帮企业把 AI 应用真正跑进生产环境。模型负责思考，Agent 负责行动，而 TiDB 负责把所有上下文、状态、记忆、文件、业务数据和分析数据可靠地管理起来。AI 不是只要一个聪明大脑就够了，它还需要长期记忆、工作台、任务记录、权限边界和实时业务状态。TiDB 做的就是这个「AI 应用的数据底座」。
Q：过去大家谈 AI，第一反应是模型、算力、应用。为什么你认为数据基础设施会重新成为核心？
因为 AI 应用从 Demo 进入生产以后，瓶颈会从「模型能不能回答」变成「Agent 能不能拿到正确的数据、理解当前状态、执行动作并留下可追溯记录」。企业真正上线时，问题会变成：它知道我是谁吗？知道业务现在什么状态吗？知道哪些数据能看、哪些不能看？执行错了能恢复吗？结果能审计吗？这些都不是模型参数能单独解决的。
Q：AI Agent 需要的数据库和传统应用需要的有什么不同？
传统数据库服务确定性系统。AI Agent 是在不断理解、计划、调用工具、写入状态、修正计划。所以它要支持长期演化，未来更自然的模式是 one agent, one database，让每个 Agent 拥有独立的数据边界和演化空间。要支持多模态上下文，不只是表，还有文档、代码、音频转写、图片描述、向量、文件、任务日志。要支持实时状态。要支持搜索、分析、文件一体化。
Q：混合搜索在企业 AI 应用里的价值在哪？
企业场景里有大量必须精确匹配的内容：订单号、合同编号、SKU、设备 ID、错误码、版本号、法律条款编号。向量搜索解决「意思像不像」，全文搜索解决「事实准不准」，混合搜索解决企业 AI 能不能真正可信。
Q：你怎么看 context platform for AI applications 这个方向？
未来 AI 应用最稀缺的不是模型调用，而是上下文组织能力。谁能把企业的业务状态、用户记忆、文件、权限、历史任务、分析结果组织成 Agent 可调用的上下文，谁就掌握了 AI 应用的核心入口。数据库会从后台系统变成 AI 应用的上下文平台。它不只是被动存储，而是主动回答：这个 Agent 当前是谁？它正在做什么任务？可以访问哪些数据？过去学到了什么？下一步需要哪些上下文？
Q：Agent 如果要执行业务任务，对数据一致性、实时性和可追溯性的要求有多高？
高很多。如果 AI 只是回答「公司报销制度是什么」，错了最多是体验问题。但如果 Agent 要执行「帮我申请退款」「帮我修改订单」「帮我触发付款」，它就进入了业务系统核心流程。Agent State Layer 里，Metadata 非常重要，它要记录 Agent 的 Job、Step、Tool Call、Human Approval、Sandbox Lease、Retry、Rollback、Audit Trail。没有这一层，Agent 很难从玩具进入生产。
Q：Agentic scale 会给数据基础设施带来什么新挑战？
过去访问系统的主要是人，人的点击频率有限。未来访问系统的会是大量 Agent。请求频率更高，状态写入更多，数据形态更复杂，隔离性要求更强，成本模型会变化。以前按用户访问量估算，现在要按 Agent 活跃时间、任务复杂度、状态写入量来估算。未来数据库要支持的不只是 user scale，而是 agent scale。
Q：企业在部署 AI Agent 时，应该如何重新理解数据治理？
过去数据治理主要管人：谁能看什么表。Agent 时代，要管「人 + Agent + 工具 + 动作」。企业需要回答：这个 Agent 代表谁？能访问哪些数据？能不能写入生产系统？哪些动作需要 human approval？每一步能不能审计？生成的文件、结论、记忆是否可删除、可回滚、可解释？数据治理不再只是数据目录和权限配置，而是 Agent 的运行治理。
Q：企业什么时候会意识到，真正的问题不是前端交互，而是后端数据架构？
通常在第三阶段。第一阶段做 Chatbot，关注流畅度。第二阶段做知识库和 RAG，发现检索质量和权限是问题。第三阶段让 Agent 执行业务任务，比如查实时订单、写入 CRM、管理文件产物、失败后恢复。到这里，企业会发现前端聊天框只是入口，真正决定 AI 能不能生产化的是后端 State Layer。
Q：未来三年，AI 对数据库行业最大的改变是什么？
数据库会从应用后台的存储系统，变成 Agent 的上下文操作系统。未来 Agent 不会只问数据库「这条数据是什么」，它会不断追问：我现在什么状态？用户偏好是什么？任务到哪一步？哪些文件可用？哪些记忆可信？业务数据最新吗？下一步做什么？做完怎么更新状态？真正有价值的数据库不只是支持 vector，而是能成为 Agent State Layer。
