--- title: "它能让你的 AI Agent 记得住、看得准、跑得稳、管得住" id: "20260607A085SA00" publicationAccount: "非凡产研" originalPublishedAt: "2026-06-07T20:55:30+08:00" canonical: "https://ffcap.cn/research/20260607a085sa00" source: "https://view.inews.qq.com/a/20260607A085SA00" sourceAccount: "https://news.qq.com/omn/author/21759984" language: "zh-CN" tags: ["AI Agent","模型与基础设施","记忆与上下文","企业应用","营销增长"] --- # 它能让你的 AI Agent 记得住、看得准、跑得稳、管得住 文章中的“非凡产研”是原始发布账号署名，不代表已核实个人执笔作者。引用访谈或圆桌观点时，应按正文标明具体发言人及当时身份；无法确认时不要推断。日期为原始发表日期，历史信息以发布时点为准。 **AI行业观察** ## **AI 时代的数据库：从后台的“数据仓库”，变成 Agent 的“操作系统”** 企业 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 进入生产环境以后，最常见的卡点不是模型不够强，而是缺少一个统一、实时、可治理的状态层。 ![它能让你的 AI Agent 记得住、看得准、跑得稳、管得住 · 原文图片 1](https://inews.gtimg.com/om_bt/ODX3hAcW2er2nTndApARGDSYaNS9zF8pQPpSJAUvvwYRsAA/1000) ## **数据库不再是仓库** 传统应用里，数据库的角色相对清晰：服务交易，支撑分析。用户点击按钮，应用写入订单、库存、支付、日志。流程确定，路径固定。 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。 --- 原始发布版本：https://view.inews.qq.com/a/20260607A085SA00 本站阅读页：https://ffcap.cn/research/20260607a085sa00