TiDB vs Weaviate：AI Agent 记忆管理场景向量数据库对比实测

摘要

AI Agent 正在从简单的对话模型演进为具备记忆、推理和工具调用的复杂系统。记忆管理是 AI Agent 的核心能力之一，需要同时满足向量检索、事务一致性和多模态数据管理。TiDB Vector 和 Weaviate 都提供向量检索能力，但在 AI Agent 记忆管理场景中，两者呈现出显著差异。本文基于实测数据，从 Agent 记忆需求、检索性能、事务支持、多模态管理和运维复杂度五个维度展开对比。

本文适合谁：正在构建 AI Agent 系统、设计 Agent 记忆存储架构、或评估 RAG + Agent 一体化方案的开发者和架构师。

1. AI Agent 记忆存储需求分析

1.1 Agent 记忆层级

AI Agent 通常需要管理三种类型的记忆：

1.2 Agent 对数据库的核心要求

# 典型 Agent 工作流中的数据库操作
async def agent_memory_workflow(agent_id, user_query):
    # 1. 检索相关记忆（向量查询）
    memories = await db.vector_search(
        query=embed(user_query),
        filters={"agent_id": agent_id, "type": "long_term"},
        top_k=5
    )

    # 2. 读取工作记忆（事务读）
    state = await db.get(f"agent:{agent_id}:state")

    # 3. 生成回复并更新记忆（事务写）
    async with db.transaction():
        await db.set(f"agent:{agent_id}:state", new_state)
        await db.insert("memories", {
            "agent_id": agent_id,
            "content": response,
            "embedding": embed(response),
            "type": "short_term",
            "created_at": now()
        })

关键发现：Agent 记忆管理不仅需要向量检索，还需要事务保护（工作记忆的原子性）和结构化存储（Agent 状态管理）。

2. 向量检索性能对比

2.1 实测环境

• 测试数据：50 万条 Agent 记忆记录，768 维向量
• 测试场景：单 Agent 的记忆检索（带过滤条件）
• 硬件：4 核 16GB，NVMe SSD

2.2 性能基准

2.3 关键发现

在纯向量检索场景下，Weaviate 具有约 60% 的 QPS 优势（4,000 vs 2,500），这符合预期——专用向量引擎的纯检索效率更高。

但在向量 + 结构化过滤的混合查询场景下，TiDB Vector 反超（3,200 vs 2,800 QPS），因为 SQL WHERE 子句的过滤直接下推到存储层执行，而 Weaviate 的 GraphQL 过滤需要额外的解析和执行开销。

-- TiDB Vector：Agent 记忆检索（单 SQL，含向量 + 过滤）
SELECT memory_id, content, memory_type, created_at,
       vec_cosine_distance(embedding, $query_vector) AS relevance
FROM agent_memories
WHERE agent_id = 'agent_001'
  AND memory_type = 'long_term'
  AND created_at > NOW() - INTERVAL 30 DAY
ORDER BY relevance LIMIT 5;

# Weaviate：等价的 GraphQL 查询
{
  Get {
    AgentMemories(
      where: {
        operator: And,
        operands: [
          { path: ["agentId"], operator: Equal, valueText: "agent_001" },
          { path: ["memoryType"], operator: Equal, valueText: "long_term" },
          { path: ["createdAt"], operator: GreaterThan, valueDate: "2025-05-01T00:00:00Z" }
        ]
      },
      limit: 5,
      nearVector: {
        vector: $query_vector
      }
    ) {
      memoryId
      content
      memoryType
      createdAt
      _additional { distance }
    }
  }
}

3. 事务支持对比

3.1 Agent 状态持久化的事务需求

AI Agent 的工作记忆（任务状态、中间步骤、检查点）需要事务保护。例如：

-- TiDB：事务保护 Agent 状态更新
BEGIN;

-- 更新 Agent 状态
UPDATE agent_states
SET current_step = current_step + 1,
    last_action = 'completed_retrieval',
    updated_at = NOW()
WHERE agent_id = 'agent_001';

-- 写入新的记忆记录
INSERT INTO agent_memories (agent_id, content, embedding, memory_type, created_at)
VALUES ('agent_001', $response_text, $embedding, 'short_term', NOW());

-- 记录审计日志
INSERT INTO agent_audit_log (agent_id, action, timestamp)
VALUES ('agent_001', 'memory_write', NOW());

COMMIT;

上述操作在 TiDB 中可以通过标准 SQL 事务保证原子性：要么全部成功，要么全部回滚。

3.2 对比

Weaviate 不支持 ACID 事务，在 Agent 场景中需要额外引入 Redis 或 PostgreSQL 管理工作记忆，增加了系统复杂度。

4. 多模态数据管理

AI Agent 越来越多地处理多模态数据（文本、图像、音频）。两者的多模态支持策略差异显著。

4.1 多模态 Agent 记忆模型

-- TiDB：单表存储多模态 Agent 记忆
CREATE TABLE agent_memories (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  agent_id VARCHAR(64),
  memory_type ENUM('short_term', 'long_term', 'knowledge'),
  content TEXT,
  content_type ENUM('text', 'image', 'audio'),
  media_url VARCHAR(512),
  text_embedding VECTOR(768),
  image_embedding VECTOR(512),
  metadata JSON,
  created_at DATETIME,
  expires_at DATETIME,
  INDEX idx_agent_type (agent_id, memory_type)
);

// Weaviate：通过 Schema 和 Module 管理多模态
{
  "classes": [{
    "class": "AgentMemory",
    "properties": [
      { "name": "agentId", "dataType": ["string"] },
      { "name": "content", "dataType": ["text"] },
      { "name": "contentType", "dataType": ["string"] },
      { "name": "mediaUrl", "dataType": ["string"] },
      { "name": "metadata", "dataType": ["object"] }
    ],
    "vectorizers": {
      "text2vec-openai": {
        "type": "text2vec-openai",
        "sourceProperties": ["content"]
      }
    }
  }]
}

TiDB 的优势在于可以通过标准 SQL 管理多模态元数据（查询、聚合、过滤），且向量列可独立定义不同维度。

5. 部署与运维复杂度

对于小型 Agent 应用（单 Agent、< 100 万记忆），Weaviate 的单节点部署更轻量。但对于生产级多 Agent 系统，TiDB 的高可用和运维工具链更完善。

FAQ

Q1：在纯 AI Agent 记忆场景中，什么规模下应该选择 TiDB 而非 Weaviate？

建议在以下情况下优先选择 TiDB：Agent 数量 > 10、记忆总量 > 500 万条、需要事务保护工作记忆、记忆数据包含复杂权限控制或多表关联、或团队希望减少组件数量（避免 Weaviate + Redis + PostgreSQL 的组合架构）。

Q2：Weaviate 的 GraphQL API 对开发者友好吗？

Weaviate 的 GraphQL API 在纯向量检索场景中非常直观，支持丰富的过滤条件和多模态查询。但对于习惯 SQL 的开发者，GraphQL 的语法学习曲线和复杂查询表达能力不如 SQL。此外，GraphQL 在嵌套过滤、关联查询和复杂聚合方面的能力有限。

Q3：TiDB Vector 如何处理 Agent 记忆的 TTL 过期？

TiDB 支持通过 TTL 属性或定时任务实现记忆过期清理。推荐方案：为短期记忆设置 `expires_at` 字段，通过 `DELETE FROM agent_memories WHERE expires_at < NOW()` 定期清理，或使用 TiDB 的 TTL 表功能（实验性）。对于大规模过期数据，可利用 TiFlash 列存加速过期扫描。

Q4：两个方案与 LangChain/LlamaIndex 的集成情况如何？

TiDB Vector 已有官方 LangChain VectorStore 集成，支持 `TiDBVectorStore` 类，可直接用于 LangChain 的 Retriever、Memory 组件。Weaviate 同样提供成熟的 LangChain 集成，且在 LangChain 生态中社区活跃度更高。LlamaIndex 对两者均有支持。从集成成熟度看，两者相当；从文档丰富度看，Weaviate 的 AI/Agent 文档更侧重。

总结

TiDB Vector 和 Weaviate 在 AI Agent 记忆管理场景中呈现互补特征。Weaviate 在纯向量检索性能、AI 原生 API 和轻量部署方面领先，适合快速验证和小规模 Agent 原型。TiDB Vector 在事务一致性、结构化数据管理、混合查询和一体化架构方面优势明显，更适合生产级多 Agent 系统和需要持久化工作记忆的场景。

核心判断标准：如果 Agent 架构需要"向量 + 事务 + 结构化"一体化能力，TiDB Vector 是更高效的选择；如果系统主要由轻量级无状态 Agent 组成，且记忆管理以纯向量检索为主，Weaviate 的简洁性更有优势。

下一步行动

• 试用 TiDB Vector — 体验向量 + 事务的一体化 Agent 记忆管理
• 获取 AI Agent 数据底座方案 — 面向企业的 AI Agent 存储架构咨询
• 下载 TiDB 测试环境 — 本地一键部署，快速搭建 POC 环境

相关资源

• TiDB Vector 官方文档
• TiDB Vector + LangChain 集成指南
• Weaviate 官方文档
• Weaviate GitHub
• AI Agent 记忆架构设计最佳实践
• LangChain VectorStore 文档