MongoDB Atlas Agent Engine之后，如何用版本门禁防止陈旧写入
内容提要
MongoDB 发布 9.0、Atlas Infinite 与 Agent Engine，但 Agent 的最大风险是使用过期事实。文章提出用版本门禁（乐观并发控制）防止陈旧写入：读取时带版本，写入时校验版本一致，否则拒绝并重读。长期记忆须与实时状态分离，向量检索不能作为余额、库存的真相源。高风险工具应定义版本条件、幂等键与补偿动作，并以冲突率为核心指标。
延伸解读
版本门禁：从根源阻断陈旧写入
文章指出，Agent 即使推理正确，若使用过期事实仍会出错。版本门禁通过乐观并发控制，在读取时携带版本号，写入时校验版本是否一致，不一致则拒绝并重读。这能有效防止检查—使用窗口内数据变化导致的错误动作，且不依赖模型谨慎性，而是数据层硬约束。
长期记忆与实时状态必须分离
用户偏好等长期记忆可持久保存，但余额、库存等实时状态不能作为可执行事实长期复用。向量检索只回答“哪段历史相关”，版本与事务才回答“现在能否操作”。将两者混用会导致 Agent 基于过期信息执行高风险动作，因此架构上需明确区分。
高风险工具需定义版本条件与补偿
对于转账、退款、订会议室等操作，应定义读取集合、版本条件、幂等键、审批规则和补偿动作。冲突后必须重新规划，并将冲突率作为核心指标。乐观并发适合冲突不频繁的场景，高冲突或跨系统流程可能需要锁、队列或人工确认。
平台能力不能替代架构责任
MongoDB 9.0、Atlas Infinite 和 Agent Engine 提供了性能提升与统一平台，但厂商数据需自行压测验证，且 Atlas Infinite 仍是公开预览。团队不能将架构责任外包给产品名，而应主动实施版本门禁、幂等和补偿机制，以控制错误动作的爆炸半径。
Q&A
MongoDB Atlas Agent Engine 发布后，Agent 面临的最大风险是什么？
Agent 即使推理完美，如果使用了过期的事实（如昨天的库存、旧余额或过期订单状态），也会执行错误动作。生产环境中最危险的故障之一是正确地使用了已经过期的事实。
什么是版本门禁？它如何防止陈旧写入？
版本门禁是一种乐观并发控制机制：读取数据时带回版本号，写入时要求版本号仍然一致；如果不一致就拒绝写入，并重新读取和规划。这样能防止基于过期数据的写入。
为什么长期记忆必须与实时状态分开？
长期记忆适合保存用户偏好等不易变的信息，而实时状态如账户余额、库存等不应作为可执行事实长期复用。向量相似度只能回答“哪段历史相关”，版本与事务才能回答“现在还能不能做”。
如何用代码实现一个简单的版本门禁来阻断陈旧计划？
可以用内存字典模拟：读取时返回数据副本和版本号；写入时检查请求ID是否已处理（幂等），再比较当前版本与预期版本，不一致则返回 STALE_READ；一致且库存足够则扣减并递增版本。示例代码见文章中的 freshness_gate.py。
乐观并发控制适用于哪些场景？有哪些局限性？
乐观并发适合冲突不频繁、失败可重试的业务。对于高冲突或跨多个系统的一致性流程，可能需要锁、队列、事务编排或人工确认。向量检索不适合作为余额、权限和库存的最终真相源。
团队应该为高风险工具定义哪些控制措施？
应为每个高风险工具定义读取集合、版本条件、幂等键、审批规则和补偿动作，并把冲突率作为核心指标。同时检查记忆是否带过期时间、操作数据是否有版本、工具写入是否幂等、冲突后是否重新规划、日志能否还原读取版本与实际写入。
