做 AI 产品别只盯模型，状态数据才是最难补的一层

一个 AI 助手突然变慢，很多团队的第一反应是去看模型 API。

是不是限流了，是不是上下文太长，是不是某家模型又在高峰期闹脾气。该看，当然该看。但真正难缠的那一下，常常藏在模型返回之后。

一条会话记录读得慢，用户刚上传的文件找不到，工具权限在三个服务里各写了一遍，运营要查一份报表，顺手把正在聊天的用户也拖进排队。模型明明回得飞快，产品却像踩住了鞋带。

好家伙，AI 产品绕了一圈，还是要回到老问题，数据到底该怎么放。

OpenAI 9 月 11 日公开了它的在线存储平台 Habitat。官方说，这层服务支撑 ChatGPT、API、Codex 等产品，每秒处理超过 7000 万次请求，覆盖每周超过 10 亿用户，管理超过 500PB 数据。数字很大，但我看完更在意的不是规模，而是它承认了一件很朴素的事。

用户点一次发送，背后可能要查很多份数据。登录状态、会话归属、权限、记忆、文件元信息、功能开关、租户配置，少一个都可能让这次请求卡住。OpenAI 的原文 写得很直白，数据读慢了，产品就显得慢。数据读不到，产品就直接不能用。

模型是前台，状态才是后台。

OpenAI 把 Habitat 定义成在线数据访问的平台层，原图来自官方文章。

这句话听上去没什么新鲜的。可一到做 AI 应用，大家很容易把注意力全放在模型、Prompt、工具调用和评测上。它们都重要，只是用户每天真正反复碰到的，是那层保存对话、文件、权限和执行痕迹的状态。

一个只会演示的 Agent，状态层乱一点没关系。真实用户一进来，麻烦就开始排队。用户切个设备，历史要在。团队成员换了角色，权限要变。模型替他调用一个工具，审计记录要在。用户删了一份文件，检索索引和缓存也得知道。不是哥们，这些东西没一件是模型自己会替你收拾的。

OpenAI 的 Habitat 一开始也不是一座看起来很厉害的服务。它最初只是 Python 客户端库，替产品工程师屏蔽数据库的细节。路由、授权、加密、序列化、连接池这些活儿，库先帮你扛着。

这在早期很顺手。每个产品在自己代码里引用同一个库，想加缓存就加缓存，想加压缩就加压缩。功能跑得起来，开发体验也棒棒的。

可当服务变多，库的升级会变成一场排队过闸的迁徙。官方讲了一个很典型的过程。为了降低一个地区故障的影响，他们要把关键数据迁到分布式账户，需要给客户端加新路由，关在 feature flag 后面，等几十个服务升级，再逐步放开。后来又想加 shadowing 验证，再等一轮。等终于准备启用，有团队因为别的原因回滚到了旧客户端，原本要躲开的故障又被带回来了。

看起来是发布协调的问题，底下其实是责任没有收拢。

于是 Habitat 从库变成了服务。部署、观测、路由、访问控制和审计可以在一个地方改，产品团队不必一起等版本车队。这种改法不是为了把架构图画得更漂亮，而是为了减少一次变化要同时碰多少人、多少代码库、多少条发布链路。

在线状态、复杂查询与权限治理各有职责，别让它们在同一条热点路径里互相拖累。

我觉得这套思路放到大多数 AI 产品上，可以先拆成三条数据路。不是照抄 Habitat 的内部实现，只是用它的取舍给自己的架构做一次体检。

第一条是用户正在等的在线状态。它包括会话归属、消息索引、用户设置、文件引用、任务状态、工具执行的最小结果集。这里的目标不是万能，而是稳定和可预测。一次读取最好能算清成本，能按租户隔离，能知道失败时谁负责兜底。用户等回答的时候，别让这条路去跑一段不受控的全表扫描。

OpenAI 在 Habitat 里刻意限制了 API 的能力。它不让客户端随手拼任意 SQL，也不默认支持无边界查询、复杂 join 或图遍历。原因并不浪漫，一条很容易写出来、却极难跑好的查询，放进热点路径，迟早有人要值班。官方也提到，早期当团队还小，大家还能逐条审查查询和索引。产品、服务和流量一多，单个昂贵查询就可能把在线数据库推到悬崖边。

这部分很容易被误解成，不许复杂查询。

不是这个意思。复杂查询只是别和用户等待中的在线读写抢同一张桌子。

第二条是分析和检索的出口。运营想看跨月留存，产品想筛一批对话，算法想做离线特征，知识库要建更重的索引，这些活儿都合理。Habitat 的做法是用 CDC，也就是把在线数据变化持续送到隔离的二级视图，再让复杂查询在那里跑。查询重一点、晚一点、要单独扩容一点，都可以。只要别在某个用户点发送的瞬间，把整间厨房搬进前台。

很多朋友做 RAG 时碰到的也是同一种问题。向量检索、全文搜索、聚合分析和会话状态常被一起塞进一个接口。原型阶段挺省事，流量上来后排查性能就像在一锅面里找一根掉进去的网线。你很难判断慢的是检索、数据库、缓存，还是某个临时加进去的权限过滤。

把在线状态和复杂读分开，不会让系统自动变简单。但它会让坏事更容易被看见。慢查询有自己的队列，索引有自己的容量，异常不会伪装成模型变笨。

第三条是治理。权限、租户、数据驻留、审计和限流，最好别散在每个 Agent 的工具函数里。OpenAI 把授权策略、审计日志、底层存储的访问限制放到 Habitat 这个统一关口。它想解决的不只是外部访问，也包括内部服务和 Agent 的越权风险。

这一层特别容易被低估。一个 Agent 调工具时，真正需要判断的不只是它会不会把参数写对，还包括它代表谁、能碰哪个工作区、拿到的数据能不能跨区域、这次访问以后有没有痕迹可查。把这些逻辑分散在 Prompt、业务 API 和每个工具适配器里，前几个月看不出问题。后来要改一个角色权限，才发现有八个入口，各自长得还不太一样。真的就是一声叹息。

统一的治理关口不替业务决定权限，但应负责一致地执行、记录和限制访问。

如果你正在评审一个 AI 产品的后端，可以先不急着问要不要上 Rust、要不要换数据库。先把这五个问题摆出来。

用户正在等待的那次请求，要读哪些数据，它们有没有明确的成本上限。

需要跨很多对象搜索、聚合或回放的查询，是否有独立的索引和容量，而不是直接压在会话热路径上。

租户、成员角色、数据区域和工具权限，有没有一个可以统一执行和审计的关口。

数据变化后，缓存、检索索引和分析视图怎样知道自己该更新，失败时能不能重放。

再问一个，某个存储规则变化时，究竟需要同时升级多少服务。这个数如果你答不上来，先别急着加下一个 Agent。

还有一个很实用的小动作，给每类状态补一份简短的责任说明。不要做成几十页设计文档，写清楚四句话就够。它归哪个用户或哪个租户。谁能在什么条件下读写。用户正在等待时，它是不是必须同步可用。它变更以后，哪些缓存、索引和报表要跟着更新。

这四句话写不出来的状态，往往已经在系统里游荡了一阵子。它可能藏在聊天消息的一段 JSON 里，藏在向量库的 metadata 里，也可能被某个工具调用临时记在缓存里。刚开始大家都觉得能用，直到一次重试把任务执行两遍，或者用户权限改了，旧索引还在默默吐内容。

这里还得把 Prompt 和状态分开。Prompt 可以告诉 Agent 要怎样做事，它不是用户身份、账单权限或文件归属的事实来源。模型会改写、摘要和压缩上下文，状态则需要可追溯、可撤销、可审计。把这两件事混着存，表面上是开发更快，后面往往会变成一连串很难解释的权限问题。

工具调用也一样。一个请求超时后重试，究竟是重新执行，还是读取上次结果。一个外部动作已经发生，记录还没写回，下一次恢复如何避免重复。没有人会在 demo 里专门表演这些，可线上最爱挑这种角落下手。给任务、调用和结果留出稳定的标识与状态迁移，比让 Agent 再多说两句漂亮话有用得多。

这里面没有什么银弹。小团队也没必要第一天就搭出一套 Habitat。把一个小服务拉得过于抽象，可能比一条慢查询更早把人拖垮。OpenAI 自己也不是一开始就独立服务化，它先用 Python 库换取交付速度，等到协调成本和故障半径真的顶不住，才把能力收进平台层。

我很喜欢这个顺序。先解决眼前真实的约束，再为下一次增长留门。不是一看见大厂架构图，就把所有名词搬进自己的仓库。那样大概率只会多出几份没人维护的 YAML，厉害了，复杂度倒是先上线了。

官方后面还写到，他们在 2026 年第二季度用两名工程师、Codex 和 GPT-5.5，把服务逐步迁到 Rust。新的 Rust 服务已经承接 95% 生产请求，官方给出的数据是 CPU 效率提升约 6 倍，内存效率提升约 15 倍，平均和尾部延迟都降低。

这个结果当然漂亮。有点子牛逼。

但它更像一道后面的题。前面的题是，你有没有先让请求路径可控，让数据责任清楚，让复杂需求有出口，让权限能被一致地执行。没有这些，换语言可能只是把同一团线跑得更快一点。

模型的能力会继续往前冲。可用户不会因为你换了一个更聪明的模型，就原谅一次找不到历史、一次误授权，或者一次迟到十秒的回答。

所以我会把 Habitat 这篇文章记成一个提醒。AI 产品的真正地基，不是把所有能力塞进 Agent，而是给每一次状态变化找对它该走的路。

你现在的 AI 产品里，最容易和在线对话抢同一条数据路径的，是检索、分析，还是权限判断？

官方材料见 OpenAI Engineering。中文同题标题样本见 IT 之家报道。