2026 年 9 月 11 日，OpenAI 介绍了在线存储平台 Habitat 的演进。1 我更关心的是它在业务和基础存储之间占据的位置：业务接入一种存储产品之后，通常还要自己处理另外几种存储，以及它们之间的关系。这部分工作有没有可能成为一个独立产品？
Agent 把这个问题暴露得更明显。一次任务会留下会话状态、文件、工具调用记录和分析数据，业务需要把它们接起来，才能支持任务接续、查看制品和排查问题。数据库、对象存储、缓存都有了，完成一次业务动作仍然需要写不少代码。
本文先看 Habitat 怎样从 Python SDK 演进成服务，再与 InstantDB 这类 BaaS 比较服务范围。最后讨论 Agent 存储已经分拆成多种产品之后，哪些需求有机会重新收敛，以及业务共性、公司投入和组织分工会怎样影响这个过程。
1. Habitat 的演进：客户端库、独立服务与 Rust 实现
起点：用 Python SDK 复用存储逻辑
Habitat 在 DevDay 2023 为 GPTs 上线，起点是访问 Azure Cosmos DB 的 Python 客户端库。1
客户端库很适合初期建设。业务只需要依赖一个包，就可以复用存储接入逻辑；维护方也不用立刻承担一套常驻服务的部署、容量和故障处理。这个选择与后来服务化并不矛盾，它们面对的是不同规模的使用关系。
版本协调成本：把存储逻辑拆成独立服务
到 2025 年中，跨服务更新路由的协调成本已经很高；一次业务回滚带回旧客户端，甚至触发了故障。OpenAI 随后把 Habitat 拆成独立服务，先保留 Python。1
SDK 共享的是代码，运行在各个业务里的版本仍然分散。假设一次存储迁移要求新旧路由配合，维护方要确认每个调用者已经升级，还要考虑这些业务能回滚到哪里。代码仓库里只有一个最新版本，并不能证明现网执行着同一套规则。接入团队越多，这件事越难靠约定维持。
从这个角度看，服务化改变了存储逻辑的发布单位。业务仍然需要遵守接口兼容性，但内部路由、流量控制和连接管理可以独立发布。维护方终于能够为自己修改的行为负责，代价则是调用链多了一跳，也多了一套需要持续运营的服务。
图 1：OpenAI 原文 Figure 02 的网页截图。1 客户端 SDK 经 Envoy 访问 Habitat 服务，服务再经 habitat-envoy 连接 Azure Cosmos DB；蓝色方块表示请求，绿色圆点表示响应。原图为交互动图，这里保留静态画面。
Event Loop 排队：降低单进程并发
asyncio 的一个 Event Loop 在一个线程里执行任务，某段 CPU 工作持续占用它时，其他已经就绪的协程也得等。Python 官方文档明确提醒，阻塞计算会延误同一循环里的其他任务与 I/O。2 因此，数据库已经返回，不代表业务已经拿到结果；解析、压缩或其他处理如果还在排队，用户一样觉得慢。只看下游数据库耗时，很容易漏掉中间服务自己的等待。
Habitat 的处理方式是监控调度延迟，降低单进程并发，再横向增加 Worker。1 控制的是每个 Event Loop 同时承担的工作量。
图 2：OpenAI 原文 Figure 03 的演示完成画面。1 上半部分 CPU 工作较短，I/O 等待可以重叠；下半部分 CPU 工作较长，已经就绪的响应仍需等待 Event Loop。时间轴使用原文的示意单位，不是生产实测延迟。
配置刷新停顿：精简配置并错开刷新时间
Statsig 配置的集中解析会占用 Worker 的 CPU。Habitat 精简配置、延长刷新间隔，并加入 Jitter，让后台任务错开执行。1
连接复用偏斜：从 LIFO 改为 FIFO
在 Habitat 遇到的负载中，慢连接较晚归还，LIFO 又优先复用最近归还的连接，容易继续把请求交给慢进程。改成 FIFO 后，这个反馈被打断。1 图 3、图 4 是原文在同一组请求条件下的对照；FIFO 也不能代替完整的负载均衡。
图 3：OpenAI 原文 Figure 04A 的 Outcome 画面。1 慢进程 C 的连接较晚归还，LIFO 的复用顺序让后续请求继续集中到 C。图中的请求数是演示状态。
图 4：OpenAI 原文 Figure 04B 的 Outcome 画面。1 相同的请求到达与服务端工作量下，FIFO 减少了后续请求向 C 集中的现象。
下游连接压力：用 Envoy 汇聚连接
增加 Worker 能分散这部分 CPU 工作，也会带来更多连接。这里需要区分请求并发和 TCP 连接数：Envoy 的 HTTP/2 连接池可以把多个请求复用到一个连接上，并受并发 Stream 等限制约束。3 对存储接入平台来说，连接复用策略、负载分配和下游保护要一起考虑。把每个组件单独调到吞吐最高，未必得到一条稳定的数据路径。
图 5：OpenAI 原文 Figure 05 的稳定负载演示画面。1 从上到下分别是各 Python Pod 单独管理连接、Envoy 共享 HTTP/1 连接池、Envoy 使用 HTTP/2 多路复用。18、6、1 条连接是原图用于解释机制的示例，不是 Habitat 生产集群的连接统计。
Python 资源成本：接口稳定后迁移到 Rust
到 2026 年第二季度，OpenAI 用两名工程师配合 Codex、GPT-5.5 将服务重写为 Rust；文章发布时，Rust 已承接 95% 的生产请求。1 这里有两次不同的决策：先改变交付和运营方式，等接口与使用关系稳定后，再更换实现。把它们绑成一次大重构，会让业务接入、平台治理和语言迁移同时等待彼此。
复杂查询干扰：隔离在线与分析路径
Habitat 还主动限制了查询能力：在线侧提供 Object / Edge NoSQL API，数据变更通过 CDC 进入隔离的 Rockset 实例，供复杂查询使用。1 这个取舍会直接影响后面讨论的平台形态。接口承担的语义越多，平台要解释和控制的执行成本就越多，单纯统一入口并不能消除这些成本。
2. InstantDB 与 Habitat：应用后端与内部存储平台的服务范围
OpenAI 收购 InstantDB 的消息，可以放在这里一起看。按 Instant 公告的口径，确认的是团队加入 OpenAI；公告没有披露与 Habitat 的整合方案。4 两个产品都在替业务减少基础设施代码，但它们面向的使用者，以及接管的服务范围，差别很大。
InstantDB 属于 Backend-as-a-Service，也就是把应用常用的后端能力作为服务交付。它将数据库、认证、权限、文件存储和实时同步组织在一起，应用开发者可以通过客户端 SDK 访问数据。5 对一个需要登录、读写记录和多端同步的 Web 应用来说，开发者原本要搭建的那部分公共后端，已经由 BaaS 提供了。
它的抽象也一直延伸到应用客户端。数据用 [entity, attribute, value] 三元组表达，InstaQL 查询在客户端进入 Datalog 与本地 Triple Store，在服务端转换成 SQL 并访问 Postgres；本地响应、乐观更新与同步都包含在这条链路里。5 开发者当然还需要实现自己的业务规则，但不必为了每个应用重新搭一套相似的数据访问与同步系统。
图 6：Instant 官方 About 页中客户端 Datalog 与服务端 SQL 两部分的网页截图。5 它的服务范围覆盖应用客户端到后端的数据访问与同步；图中展示查询路径，其他 BaaS 模块未画出。
这也解释了 Instant 为什么会强调 AI 编码。Agent 生成一个应用之后，仍然需要有人提供可用的后端。Instant 的类型约束和 CLI 可以让 Agent 创建项目、修改 Schema，并获得类型检查反馈。6 被创建的应用可以是任务看板、内容社区或内部工具，并不需要本身就是一个 Agent 产品。这里首先服务的是应用开发过程。
Habitat 的调用方则是 OpenAI 内部已经存在的业务服务。产品工程师需要保存和读取数据，Habitat 统一处理访问存储时的路由、授权、缓存和连接管理。1 它处在业务服务与基础存储之间，承担跨产品的存储接入与治理。产品界面怎么交互、一次任务如何推进，仍然由上层业务负责。
这个区别也反映在 API 上。Instant 希望开发者方便地表达应用所需的数据及其关系；Habitat 主动限制在线查询的复杂度，把请求成本的可预测性放在很高的位置。16 前者努力减少应用开发者需要编写的公共后端代码，后者努力让内部业务以可控的代价访问大规模存储。两者都包含权限和数据接口，但接口要优先解决的问题不同。
| 产品 | 主要使用者 | 接管的服务范围 | 优先优化的目标 |
|---|---|---|---|
| InstantDB | 应用开发者 | 应用的公共后端链路 | 降低应用开发成本 |
| Habitat | 内部业务服务 | 跨产品的存储访问 | 大规模存储的可控运行 |
所以不能只按功能数量判断谁的范围更大。Instant 对单个应用覆盖的链路更长，从客户端体验一直到服务端数据；Habitat 横跨公司内部的多条产品线，统一它们访问基础存储的方式。一个侧重应用开发的完整性，一个侧重内部基础设施的一致性。
如果一个编码 Agent 使用 Instant 做出报告应用，Instant 保存的是这个应用的用户、报告记录和业务数据；运行这个编码 Agent 的平台，又可能需要用 Habitat 一类系统保存它自己的会话与任务数据。这两种需求可以同时存在。把应用开发的后端能力产品化，与把 Agent 产品自己的存储需求收敛起来，是相邻但不同的产品方向。
3. Agent 存储的产品整合与组织约束
-
Agent 的共性存储需求已经存在。 上一篇《AgentState 的产品定位与设计取舍》已经讨论过会话状态、制品、观测与评估等共性需求。7 它们可以由不同产品承接，但业务仍要处理产品之间的数据关联、权限与生命周期。进一步整合的空间，就在这些反复建设的交互中。
-
Habitat 的组织定位和生态位很好。 我认为，它的位置恰好适合承接这部分工作：向上服务内部产品线，向下连接基础存储，把路由、授权、缓存和连接管理集中建设。OpenAI 的核心产品围绕模型交互与 Agent 任务展开，需求相近，更容易抽象共性；共享平台也为公司层面集中投入、统一治理提供了落点。原文披露的演进路径是先自发采用客户端库，再走向独立服务。1
图 7：沿着 Habitat 的位置推演的 Agent 存储平台。统一接口与治理，各类负载保留独立资源；这是本文设想，不表示 Habitat 已实现图中全部功能。
-
放到一般的大公司里，就没有那么顺了。 业务差异更大，存储、Agent、可观测和平台团队也各有目标。一个跨越多个产品的方案，很难天然归属于某个部门，还要协调既有系统、排期和故障责任。技术上可以统一，组织上却可能更愿意各做一层，最后呈现百花齐放的状态。
-
通用平台仍然要面对业务特化。 可观测性就是例子：接入、查询、告警和 Dashboard 都有了，业务未必觉得好用。同样是排查问题，有的团队按作业定位，有的要把任务、工具调用和制品连起来。面板展示、跨产品联结和跳转上下文都得贴合实际流程。最后每个大团队自己出几个人，在通用平台上再包一层。又是一种产出。
图 8：共享基础能力，保留业务入口与流程的特化空间。图中是本文的分工判断，不是 OpenAI 的组织架构。
4. 总结
我认为，类似 Habitat 的平台有机会把几条产品线中重复的存储需求统一起来，形成面向业务的解决方案。分离的产品形态依旧有意义：有些团队希望拿到一套能直接接入的解决方案，减少产品之间的交互建设；有些团队已经有自己的架构和业务流程，需要的是产品本身，并且希望保留组合、替换和特化的空间。统一平台与独立产品可以长期共存，分别满足这些需要。
无论以哪种形态交付，想服务更多业务，都应该先把一类场景做好，再接第二类、第三类。每接入一类业务，都要检验哪些能力能够复用，哪些应该留给场景扩展。先简单，再复杂，逐步演进产品的通用性。
人的经验可以让我们在见过各种场景以后，提前识别一些共性，少走一点弯路。共性最终还是要靠业务证明。先把一个问题解决，再把几个问题里的共性抽出来，别先意淫共性，然后等业务来配合一个完美架构。
5. 参考资料
1 OpenAI：Rapidly scaling online storage to serve over 1 billion ChatGPT users（2026-09-11）
2 Python Documentation：Developing with asyncio
3 Envoy Documentation：Connection pooling
4 Instant：The Instant team joins OpenAI