数据库卫生墙保障AI代理数据一致性

为什么AI代理会「成功却错误」：数据库卫生墙的重要性

问题开始于一条看似成功的更新操作。AI代理正常返回，JSON格式合法，字段类型匹配，枚举值也合法。但当我们检查PostgreSQL数据库时，发现：客户记录被错误更新，产生了重复行，状态字段滞后，甚至有笔记被错误附加到错误的账户上。 这完全没有报错，没有崩溃，甚至通过了所有结构化输出的校验。但数据已经错了。

这类问题在AI代理应用中越来越常见。许多开发者试图通过优化Prompt、更换模型版本（如Claude Opus 4.6）、增加验证步骤（使用Qwen或Llama）或要求更严格的结构化输出来解决问题。但这些方法往往只解决了表面问题。

结构化输出的局限性

OpenAI的Structured Outputs擅长确保模型返回的JSON符合预定Schema，这有助于避免以下问题：

• 格式错误的JSON
• 缺少必填字段
• 非法的枚举值
• 因格式错误导致的重试循环

但它无法防止代理执行如下危险操作：

• 更新错误的数据行
• 插入重复记录
• 违反业务规则
• 错误顺序写入数据
• 与其他worker竞争并覆盖最新数据

合法的JSON对象仍然可能做出愚蠢的操作。因此，我们需要从根本上改变思路。

将LLM视为不可信的规划器：数据库事务的保障作用

最大的改进来自于一次思维转变：将LLM视为不可信的规划器。 它可以分类、总结、起草内容或建议操作，但PostgreSQL才是决定哪些操作最终被提交的 authority。

这意味着模型可以提出写操作，但不能随意执行副作用。我们需要用事务、SAVEPOINT、UPSERT以及ON CONFLICT等成熟的SQL技术来约束写操作。

使用事务与SAVEPOINT保障操作安全性

以下是一个典型的事务控制模式：

BEGIN;

SAVEPOINT before_agent_write;

-- 执行经过验证的插入/更新操作

-- 如果下游检查失败：
-- ROLLBACK TO SAVEPOINT before_agent_write;

COMMIT;

这种方式可以在模型提出的操作中添加安全边界，防止错误数据污染数据库。

通过乐观锁防止数据覆盖

使用乐观锁机制，可以有效避免并发场景下的数据丢失问题。例如：

BEGIN;

UPDATE customers
SET status = 'active', updated_at = now()
WHERE id = $1
 AND updated_at = $2;

-- 如果 row_count = 0，表示其他进程已修改该记录
-- 则应中止或重试

COMMIT;

这个简单的WHERE updated_at = $2条件可以防止大多数静默覆盖问题。

使用UPSERT处理重复插入问题

对于可能存在重复插入风险的操作，使用ON CONFLICT进行Upsert处理非常有效：

INSERT INTO customer_notes (customer_id, external_id, body)
VALUES ($1, $2, $3)
ON CONFLICT (external_id)
DO UPDATE SET body = EXCLUDED.body;

这样可以确保即使外部系统发送了重复请求，也不会产生脏数据。

为什么只调优Prompt远远不够

许多团队试图通过以下方式提升AI代理的可靠性：

• 再次调整GPT-5的Prompt
• 更换为Claude Opus 4.6
• 增加额外的验证步骤
• 要求更严格的结构化输出

这些方法固然有帮助，但它们并不能从根本上解决问题。正如前面所说，OpenAI Structured Outputs只能确保JSON格式正确，而不能保证语义正确。 一个合法的JSON对象仍然可能执行错误的操作。

因此，我们需要将注意力转移到数据库层面。通过构建数据库卫生墙（Database Hygiene Wall），我们可以在应用层与存储层之间建立清晰的边界，确保所有写操作都经过严格的校验与事务控制。

构建数据库卫生墙的关键技术

要构建有效的数据库卫生墙，需要应用以下关键技术：

• 事务（Transactions）：将多个相关操作打包为原子单元，确保一致性。
• SAVEPOINT：在事务内部设置检查点，便于局部回滚。
• UPSERT 与 ON CONFLICT：处理可能重复插入的数据，避免脏数据。
• 乐观锁：通过版本号或时间戳防止并发覆盖。
• Advisory Locks：在多个worker可能同时访问同一实体时，手动加锁保护关键操作。

这些技术并非新概念，但它们在AI代理系统中却经常被忽略。

总结：从“调Prompt”到“守数据库”

AI代理的可靠性问题，很大一部分源于数据库规范的缺失。当我们将焦点从Prompt调整转移到数据库事务控制上时，问题得到了显著改善。

通过将LLM视为不可信的规划器，并在数据库层面构建卫生墙，我们可以有效防止AI代理在执行过程中引入的数据错乱问题。这不仅提升了系统的稳定性，还为后续的扩展与维护打下了坚实的基础。

记住：一个合法的JSON响应并不代表操作是正确的。真正的智能应该来自于对数据的严格管理，而不是对模型输出的盲目信任。