AI Infra：Convex Backend数据库，AI Agent 时代的状态同步方案
以前做实时应用，得自己拼数据库、API、Redis、WebSocket，再加上缓存和乐观更新。每一层都独立，状态同步的麻烦事最后全堆给开发者。
Convex 试图把这些琐事都包了。它不单是个数据库，更像是一个响应式状态后端运行时。简单说，它把后端压缩成了一个统一的状态同步引擎。
它是什么
这套东西整合了文档数据库、TypeScript 函数、响应式同步、自动缓存、Serverless 执行，还有 AI 工作流层。
但核心不在存储，而在维持客户端与服务端之间一致且实时的状态视图。
核心逻辑：声明依赖
在 Convex 里，查询不是“读库”。useQuery(api.messages.list) 这行代码其实是在注册一个声明：“我依赖 messages 表”。
一旦表数据变动，引擎自动重算查询、算差异、同步到客户端、触发 UI 更新。整个链条由内向外驱动。不用手动搞 WebSocket，不用管缓存失效，也不用引入 Redux 或 React Query 这些中间层。
解决了什么麻烦
Web 开发里最头疼的状态一致性问题——实时协作、聊天、AI Agent 的 UI、长事务、多人操作、乐观更新和缓存失效。Convex 把这些抽象成了一个 State Sync Engine，让开发者只关注逻辑，不用管同步细节。
为什么现在突然火了
AI Agent 本质是长生命周期的状态机，天然需要持久化状态、多步骤推理、实时变化、UI 联动、乐观执行、记忆管理、事件流和人机协同。
Convex 已经从 Web App 后端演化成 Agent-native Backend，官网甚至直接叫它"Agent 构建模块”。
架构简述
前端 → 响应式 SDK → Sync Engine → Convex Runtime → 数据库 + 函数执行。
核心是 Sync Engine：
数据库采用文档关系模型，支持强事务和依赖追踪，能自动识别查询间的数据依赖。函数运行环境是 TypeScript 原生、Serverless、强一致性，内置响应式查询追踪。Sync Engine 自动处理 WebSocket 连接、重连、订阅、diff 同步、缓存失效、乐观更新与重试，维护一个稳定的 Client State Graph。
和竞品比怎么样
比 Firebase 进一步。Firebase 只做数据同步（DB → Client），Convex 做的是状态同步（Function → Query Graph → State）。它有事务优先级、查询图，以及确定性的同步与执行模式。可以说是“适用于后端状态的 React"。
比 Supabase 更“危险”。Supabase 竞争的是 SQL 与 Postgres 生态；Convex 竞争的是 Reactive Application State 层，而这正是 AI Agent 时代的关键——它是一个持续运行的状态系统。
缺点
Vendor lock-in 很强，数据迁移成本高。尽管代码已开源，商业层面的绑定仍然存在。
查询模型不适用于复杂 BI、OLAP 以及对 SQL 依赖较重的大型企业场景。
它在 infra 演进中的位置
传统链路是“数据库 → API → 前端”，Convex 将其转换为"State Runtime → Agent → UI"。它处于 Agent Runtime（L3.5 层级），已接近 Agent OS 的雏形，但尚缺完整的编排、记忆层级、语义状态管理与长周期规划能力。
为什么值得关注
Convex 将“同步”提升为基础设施的一等公民。
Agent 系统的核心瓶颈，正从模型推理转向状态一致性——包括记忆管理、上下文维护、工作流协调、多 Agent 协作、人机协同以及长时执行。Convex 恰好踩中了这一方向。