AI Agent 推荐航班，代码决定下单：确定性验证架构实践

为什么不能全交给 AI Agent？

近年来，AI Agent 在旅行预订、电商下单等场景中越来越活跃——它能理解自然语言需求、调用工具查询航班、生成推荐方案。但一个核心问题始终存在：如果让 Agent 直接完成下单操作，风险有多大？

大语言模型存在幻觉、上下文漂移、工具调用参数错误等问题。在涉及支付、库存锁定等不可逆操作时，这些不确定性是不可接受的。AWS 近期展示的一种架构思路正是针对这一痛点：Agent 负责"建议"，确定性代码负责"决定"。

核心架构：建议与执行分离

这套架构的核心思想是将系统拆分为两个层次：

• Agent 层（建议层）：由大语言模型驱动，负责理解用户意图、查询航班库存、生成候选方案。Agent 的输出是一个结构化的推荐结果，而非直接的操作指令。
• 验证层（执行层）：由传统确定性代码（如 Python/Java 服务）实现，负责校验 Agent 推荐结果的合法性，并执行最终的预订操作。

这种分离带来几个关键优势：

1. 可审计性：验证层的每一步逻辑都有明确的代码路径，出了问题可以精确定位。
2. 安全性：Agent 无法绕过验证层直接操作支付接口或库存系统。
3. 可测试性：验证逻辑可以用单元测试和集成测试覆盖，不依赖 LLM 的输出稳定性。

确定性验证层怎么设计？

验证层是整个架构的"安全阀"，其设计要点包括：

输入校验

Agent 输出的推荐结果需要严格校验：

• 航班号是否存在：调用航司 API 确认航班号真实有效。
• 价格是否合理：校验推荐价格与实际库存价格的一致性，防止 Agent 生成虚假报价。
• 时间是否合法：出发时间必须晚于当前时间，到达时间必须晚于出发时间。
• 用户权限检查：确认当前用户有权限进行该笔预订操作。

业务规则校验

除了基础数据校验，还需要检查业务规则：

• 是否超出用户的预算上限。
• 是否违反常旅客计划的兑换规则。
• 是否触发了风控系统的拦截规则。

幂等性保障

预订操作必须保证幂等性——即使 Agent 重复发送相同的推荐请求，系统也不会重复下单。通常通过请求 ID 去重和分布式锁来实现。

实际开发中的落地建议

如果你正在构建类似的 AI Agent + 确定性验证架构，以下是几条实践经验：

1. 定义清晰的中间协议：Agent 和验证层之间需要一个结构化的数据契约（如 JSON Schema），明确每个字段的类型、约束和可选值范围。

2. 验证层不要依赖 LLM：验证逻辑全部用确定性代码实现，不要在其中嵌入任何 LLM 调用，否则就失去了"确定性"的意义。

3. 记录完整的决策链路：保留 Agent 的原始输出、验证层的校验结果、最终的操作记录，方便事后审计和调试。

4. 设计降级策略：当验证失败时，系统应该能优雅地降级——比如通知用户"推荐方案无法预订，请查看备选方案"，而不是直接报错。

适用场景与价值

这种架构模式特别适合以下场景：

• 涉及不可逆操作的业务流程：支付、下单、发券、转账等。
• 需要合规审计的领域：金融、医疗、保险等强监管行业。
• Agent 能力尚不成熟的早期阶段：在模型能力逐步提升的过程中，验证层提供了安全兜底。

对于开发者而言，这种架构的最大价值在于：它不需要你等待 AI 变得完美，就能安全地将其引入生产系统。 Agent 提供智能，代码提供保障——两者各司其职，协同工作。