旅行与预订智能体。
旅行智能体在下单之前做的每一件事都免费、可重复；而下单本身是一笔支付、一份合同，以及一个别人再也拿不到的座位。把这两半做成两套系统——一个廉价的探索循环，加上一条窄窄的提交通道，带着新鲜报价、幂等键和支出上限——因为终结这款产品的失败不是一条糟糕的行程建议，而是某个星期二早上，同一位旅客被订了两张机票。
四件差事，只有一件危险。
"旅行智能体"打包了四种产品，它们除了共享一个领域之外没什么共同点。按你要出货的是哪一种来界定范围，因为工程内容几乎不重叠。
- 搜索与比较。多航段、多供应商、多约束的探索。纯只读、可以无限重试，也是 LLM 直截了当擅长的那一件。失败的代价是浪费一次调用。
- 下单。一次不可逆的写入，针对的是别人也在同时消耗的库存，还挂着钱。这个领域里所有难的东西都住在这一条里。
- 行程中服务。改座位、加行李、改姓名、申请升舱。半可逆、规则密集，也是走量的那一块。
- 中断恢复。被取消的 06:40、错过的中转、查不到预订记录的酒店。时间紧迫、情绪高涨，也是产品真正值回票价的地方。
多数团队做了一和二，发现用户真正感到价值的是四，却始终没有真正修好一件事：二和一接在同一个循环里。这条线路正是本文要谈的 bug。购物与结账智能体形状相同；旅行是更难的一种，因为库存稀缺、价格按分钟变动，而附在一次购买上的规则比这次购买本身还长。
用户批准的那个价格是一张照片。
下面这种失效会让来自其他领域的团队吃惊。智能体在 14:02 搜索，14:03 给出一个选项，用户读完在 14:06 确认，下单在 14:07 执行——而库存与定价自搜索以来已经动过三次。循环里没有哪一步是错的。结果依然是一笔用户没有同意过的预订。
会过期的有三样不同的东西，需要分别处置：
- 价格。通常变动不大，通常往上，而且是用户最不肯原谅的那一样，因为他们觉得被误导了。永远不要让模型从上下文里复述价格——一个穿过令牌流的数字是一项声称，不是一份报价。
- 可用性。非黑即白，毫不留情。那个价位的最后一个座位没了，而智能体绝不能悄悄订下一档。
- 条件。同一航线、同一价格，可能因为实际可售的舱位不同而带着不同的改签费、行李额或可退性。这一样会在六周后变成一起投诉。
能同时修好这三样的机制是同一个，而且它不是一条提示词指令。把每一次批准绑定到一个带 ID 与有效期的报价对象上，并在提交时重新计价。下单工具接受的是一个报价 ID，而不是模型自己拼出来的一组参数。如果报价已过期，或者供应商返回了不同的价格或舱位，工具就失败——它不去自适应——循环带着用相同单位表述的差额回到用户面前。设置一条容差带是正当的（"高于 10 美元、或可退性有任何变化就重新确认"），而它必须是你代码里的一个数字，不是你提示词里的一次判断。
这条规则的一般形式是：智能体永远不得从自己的上下文里重新推导出一项承诺的条款。用户同意过的任何东西，都必须由一个服务端对象来表示，智能体只能引用它；而做提交的那个工具，必须就是做校验的那个。一个能复述价格的模型就能编造一个价格，而且它会在最要紧的那笔交易上编得最像真的。
一条窄窄的提交通道，而且它不重试。
下单工具是这款产品里唯一一处"通常正确的智能体工程默认值"反而是错的地方。重试在循环的别处是美德，在这里是缺陷；一条友善的错误消息等于邀请模型换个花样再试一次，而这恰恰是绝不能发生的事。
- 幂等键，在调用前生成，由报价 ID 派生。用同一个键重试的下单就是同一笔下单。这是防住"重复预订"事故的那一个控制点，而它属于你的服务，不该交在供应商手里——见幂等与重试。
- 模型不重试写操作。遇到超时或含糊的响应，正确的动作是对账，不要重发：拿这个键去供应商那里查有没有匹配的预订，只针对查到的结果行动。把这条编进工具，而不是编进提示词，因为提示词是建议性的，工具不是。
- 下单工具的错误是终止性的，而且简短。"报价已过期。""该票价已无。"不给建议、不给替代、不回显参数——写工具上一条内容丰富的错误消息，就是一份即兴发挥的邀请函。在别的任何地方，好的错误消息都在引导模型；在这里它们是攻击面。
- 支出上限在循环之外执行。按笔与按天的额度，由智能体调用的一个服务来校验，绝不做成一条要求智能体自觉遵守的规则。道理和受限作用域凭据一样：由智能体自己执行的额度，是一条注入指令可以跟它讲道理的额度。
- 单写者。如果你为搜索跑并行子智能体——你应该跑，那是扇出真正划算的唯一场合——那么有且只有一个部件可以持有下单能力，而它不能是扇出的工作者之一。
然后，凡是市场愿意卖"可逆性"的地方，都把它买回来。在美国，交通部的 24 小时规则要求航司允许在出票后 24 小时内免费取消，前提是预订发生在起飞前至少七天；可退票价、免费取消的酒店房价、锁价产品的存在也是同一个道理。落在可逆窗口内的一次预订，从根本上就是一个更便宜的错误；而付一点溢价把智能体留在那个窗口之内，通常比收紧审批流程的经济账更划算。
三本规程，没有一本该放进提示词。
一次预订所受成文规程的约束，比几乎任何其他消费级交易都多，而这些规则来自三个互不协调的所有者。
- 票价与房价规则——改签费、取消窗口、行李、选座、误机处理。供应商所有，机器可读，而且是按舱位而非按航线变化的。
- 旅客自己的政策——差旅制度、优先承运人、按职级定舱等、每日限额、审批阈值。客户所有，常常是一个 PDF，也是大多数升级投诉的来源。
- 入境要求——护照、签证、过境规则、机票与证件的姓名一致性。政府所有，会变，而且是唯一一类"错了就会把人卡在边境"的规则。
诱惑是把这三本都粘进系统提示词。按上面这个严重性顺序抵抗它。票价规则应当作为结构化数据查出来展示给用户，而不是由模型来概括。企业政策应当由一个策略服务来评估，返回允许 / 需审批 / 禁止外加一条理由，这样答案是可审计的，而且对每位旅客都一样。入境要求则根本不该由智能体来断言——把权威来源摆出来、说明这次核对的时效，然后把旅客引过去。
理由不是为了整洁。压力之下的多轮政策遵从，是当前模型（包括很强的那些）在可测量意义上最弱的一条轴，而一位想要例外的旅客，正是一个在十几个回合里持续施压的用户。住在提示词里的规则，是一条模型可以被劝走的规则；住在服务里的规则，第十二轮的答案和第一轮一样。见策略执行。
中断恢复才是产品，而它把每一个假设都翻了过来。
下单是风险所在；中断恢复是价值所在。清晨六点排在改签队伍里的旅客，要的不是行程对比，而是一个好选项，现在就执行。有三件事变了：
时延不再是舒适度指标。你的智能体在斟酌的时候，救援航班上的座位正在被别人拿走。一个更慢、更好的答案是一个更差的答案。这是整个产品里你真该在并行搜索与热通道上花真金白银工程的部分，也是一个本地预筛或一个快的小模型能挣到位置的地方。
自主性该往上调，不是往下调。直觉是风险变高就要求更多审批。在中断场景里，正确的做法在一个有界的信封之内恰恰相反：在下单的时候就预先授权智能体，可以在一个写明的票价差额之内，把同一位旅客改签到同等或更好的行程上——于是旅客在睡觉、或在航站楼里没有信号时，它也能行动。一个在平静状态下谈好的信封，比一个没人能回答的确认弹窗值钱。这就是渐进式自主里的常备授权模式，而中断恢复是它最好的用例。
智能体必须知道自己已经做过什么。恢复循环是重复动作风险最高的地方，因为旅客同时也在给航司打电话，而航司自己的系统也在自动改签。每次写入之前先从供应商读取当前状态，把你自己的记录当成缓存，两边不一致时要大声对账。
两半分开度量，否则你看不见那种失败。
一个聚合的"下单成功率"恰好把要紧的事故藏了起来，因为危险的结果被计成了成功。沿着架构的同一条缝，把指标切开。
- 探索那一半：约束满足度（行程是否满足了每一条写明的要求，用程序核验而不是用裁判模型）、相对一个留出的人类选择的选项质量，以及给出候选清单的耗时。
- 提交那一半，数事件而不是算比率。重复预订。用过期报价执行的预订。没有审批记录、超出政策的预订。提交时超出容差的价差。这几项每一项都该是零，而且每一项都该触发呼叫，而不是出现在一块仪表盘上。
- 追踪"静默替换率"：那些舱位、行李额或可退性与展示给用户的不一致的预订。这个数字能预测投诉，而在任何只看结果的评测里它都不可见——正是结果评测与轨迹评测里的那个论点。
- 先让提交动作跑影子模式。让智能体产出它本会提交的那份确切下单载荷，在真实流量上跑几周，再与人工客服实际做的动作做差分。这很便宜，是发布前唯一诚实的信号，而且这些差分比你会写出的任何评测集都更有信息量。
- 每天与权威方对账。你的数据库不是那笔预订；航司的才是。一个每晚比对两者的作业，能抓住"你的系统相信了一件不成立的事"这一类失败。
搜索循环你想怎么建都行——那一半很宽容，扇出还有帮助。然后把下单当成一个独立、无聊、单写者的服务来对待，只带四条性质、不带任何聪明：它接受报价 ID 而不是参数；它在提交时重新计价，任何超出数值容差的差额都直接失败；它带幂等键，并且用对账代替重试；它校验一个不归它所有的支出上限。在下单时就预先授权一个改签信封，好让中断恢复不必去等一个联系不上的人。并且把重复预订、过期报价提交与静默替换当成事故来度量，而不是当成百分比。
相关：撤销与可逆性谈如何围绕收不回的动作做设计，审批与确认的交互设计谈一个提交界面必须展示什么，浏览器智能体的失败模式谈唯一的集成方式只有一个网站时会怎样，以及委托访问与同意记录谈事后如何证明旅客当初同意了什么。