所以我想是时候记录一下如何使用你已经熟悉的数据库为 AI 代理构建持久内存了。不是向量数据库 - 而是 MySQL 和 Neo4j。
这不是理论。我每天都在使用这种架构，在多个项目中处理 AI 代理内存。这是真正有效的 schema 和查询模式。
架构
AI 代理需要两种类型的内存：
- 结构化内存 - 发生了什么、何时、为什么 (MySQL)
- 模式内存 - 什么与什么相连 (Neo4j)
向量数据库适用于相似性搜索。它们不适合跟踪工作流状态或决策历史。为此，你需要 ACID 事务和正确的关系。
MySQL Schema
这是 AI 代理持久内存的实际 schema：
-- Architecture decisions the AI made
CREATE TABLE architecture_decisions (
id INT AUTO_INCREMENT PRIMARY KEY,
project_id INT NOT NULL,
title VARCHAR(255) NOT NULL,
decision TEXT NOT NULL,
rationale TEXT,
alternatives_considered TEXT,
status ENUM('accepted', 'rejected', 'pending') DEFAULT 'accepted',
decided_at DATETIME DEFAULT CURRENT_TIMESTAMP,
tags JSON,
INDEX idx_project_date (project_id, decided_at),
INDEX idx_status (status)
) ENGINE=InnoDB;
-- Code patterns the AI learned
CREATE TABLE code_patterns (
id INT AUTO_INCREMENT PRIMARY KEY,
project_id INT NOT NULL,
category VARCHAR(50) NOT NULL,
name VARCHAR(255) NOT NULL,
description TEXT,
code_example TEXT,
language VARCHAR(50),
confidence_score FLOAT DEFAULT 0.5,
usage_count INT DEFAULT 0,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME ON UPDATE CURRENT_TIMESTAMP,
INDEX idx_project_category (project_id, category),
INDEX idx_confidence (confidence_score)
) ENGINE=InnoDB;
-- Work session tracking
CREATE TABLE work_sessions (
id INT AUTO_INCREMENT PRIMARY KEY,
session_id VARCHAR(255) UNIQUE NOT NULL,
project_id INT NOT NULL,
started_at DATETIME DEFAULT CURRENT_TIMESTAMP,
ended_at DATETIME,
summary TEXT,
context JSON,
INDEX idx_project_session (project_id, started_at)
) ENGINE=InnoDB;
-- Pitfalls to avoid (learned from mistakes)
CREATE TABLE pitfalls (
id INT AUTO_INCREMENT PRIMARY KEY,
project_id INT NOT NULL,
category VARCHAR(50),
title VARCHAR(255) NOT NULL,
description TEXT,
how_to_avoid TEXT,
severity ENUM('critical', 'high', 'medium', 'low'),
encountered_count INT DEFAULT 1,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_project_severity (project_id, severity)
) ENGINE=InnoDB;外键。检查约束。正确的索引。这是关系型数据库擅长的领域。
查询模式
这是实际为 AI 代理内存查询的方式：
-- Get recent decisions for context
SELECT title, decision, rationale, decided_at
FROM architecture_decisions
WHERE project_id = ?
AND decided_at > DATE_SUB(NOW(), INTERVAL 30 DAY)
ORDER BY decided_at DESC
LIMIT 10;
-- Find high-confidence patterns
SELECT category, name, description, code_example
FROM code_patterns
WHERE project_id = ?
AND confidence_score >= 0.80
ORDER BY usage_count DESC, confidence_score DESC
LIMIT 20;
-- Check for known pitfalls before implementing
SELECT title, description, how_to_avoid
FROM pitfalls
WHERE project_id = ?
AND category = ?
AND severity IN ('critical', 'high')
ORDER BY encountered_count DESC;
-- Track session context across interactions
SELECT context
FROM work_sessions
WHERE session_id = ?
ORDER BY started_at DESC
LIMIT 1;这些是直截了当的 SQL 查询。EXPLAIN 显示索引使用完全符合预期。没有惊喜。
Neo4j 层
MySQL 处理结构化数据。Neo4j 处理关系：
// Create nodes for decisions
CREATE (d:Decision {
id: 'dec_123',
title: 'Use FastAPI',
project_id: 1,
embedding: [0.23, -0.45, ...] // Vector for similarity
})
// Create relationships
CREATE (d1:Decision {id: 'dec_123', title: 'Use FastAPI'})
CREATE (d2:Decision {id: 'dec_45', title: 'Used Flask before'})
CREATE (d1)-[:SIMILAR_TO {score: 0.85}]->(d2)
CREATE (d1)-[:CONTRADICTS]->(d3:Decision {title: 'Avoid frameworks'})
// Query: Find similar past decisions
MATCH (current:Decision {id: $decision_id})
MATCH (current)-[r:SIMILAR_TO]-(similar:Decision)
WHERE r.score > 0.80
RETURN similar.title, r.score
ORDER BY r.score DESC
// Query: What outcomes followed this pattern?
MATCH (d:Decision)-[:LEADS_TO]->(o:Outcome)
WHERE d.title CONTAINS 'Redis'
RETURN d.title, o.type, o.success_rate它们如何协同工作
流程如下所示：
- AI 代理生成内容或做出决策
- 将结构化数据存储到 MySQL（什么、何时、为什么、完整上下文）
- 生成嵌入，向量存储到 Neo4j，并与相似项目建立关系
- 下次会话：Neo4j 找到相关的相似决策
- MySQL 提供这些决策的完整细节
MySQL 是真相之源。Neo4j 是模式查找器。
为什么不只用向量数据库？
我见过团队试图仅用 Pinecone 或 Weaviate 构建 AI 代理内存。但效果不佳，因为：
向量数据库擅长：
- 找到与查询相似的文档
- 语义搜索 (RAG)
- “类似这样的东西”
向量数据库不擅长：
- “我们 3 月 15 日决定了什么？”
- “显示导致中断的决策”
- “这个工作流的当前状态是什么？”
- “哪些模式置信度 > 0.8 且使用次数 > 10？”
这些查询需要结构化过滤、连接和事务。这是关系型数据库的领域。
MCP 和未来
模型上下文协议 (MCP) 正在标准化 AI 系统处理上下文的方式。早期的 MCP 实现正在发现我们早已知道的事情：你需要结构化存储和图关系两者兼备。
``````htmlMySQL 处理 MCP 的“resources”和“tools”目录。Neo4j 处理上下文项之间的“relationships”。Vector embeddings 只是拼图中的一块。
生产环境说明
当前运行此架构的系统：
- MySQL 8.0, 48 tables, ~2GB data
- Neo4j Community, ~50k nodes, ~200k relationships
- Query latency: MySQL <10ms, Neo4j <50ms
- Backup: Standard mysqldump + neo4j-admin dump
- Monitoring: Same Percona tools I've used for years
运营复杂度低，因为这些是成熟的数据库，具有良好理解的运营模式。
何时使用什么
| Use Case | Database |
|---|---|
| Workflow state, decisions, audit trail | MySQL/PostgreSQL |
| Pattern detection, similarity, relationships | Neo4j |
| Semantic document search (RAG) | Vector DB (optional) |
从 MySQL 开始用于状态管理。当需要模式识别时添加 Neo4j。只有在实际进行语义文档检索时才添加 vector DB。
总结
AI 代理需要持久化内存。不仅仅是 vector database 中的 embeddings - 结构化、关系型、时序内存，带有模式识别。
MySQL 处理结构化状态。Neo4j 处理图关系。它们共同提供 vector databases 单独无法提供的功能。
不要为了 AI 工作负载而放弃关系型数据库。为每个任务使用正确的工具，那就是将两者结合使用。
有关此架构的 AI 代理视角，参见 3k1o 的配套文章。
