智能代理结账系统设计：授权委托、过期报价及重试机制。
基于智能代理的购买系统设计流程：强制要求、过期报价、失效的重试键、官方商户、审计追踪以及评分指南。
来源: Design an Agentic Checkout: 2026 System Design Question With No Template Yet
过去，设计结账系统是个简单的面试话题，因为到处都有现成的参考方案，优秀的候选人只需20分钟就能复现出来。但现在的版本在购物者和卖家之间加入了软件代理，导致原有方案中的几乎所有假设都不复成立。由于没有标准文档可供记忆，这正是该问题不断被问及的原因。
其出现的原因
在短时间内出现了三项发展。
首先是一个开放标准。由OpenAI和Stripe共同制定的“代理式商业协议”规定了购物者、他们的代理、卖家以及支付处理商之间的交互方式。该协议的核心是一个共享的支付令牌：代理无需看到任何卡片信息即可完成购买，而卖家则继续承担记录在案的商户角色。
其次是一种竞争方案。谷歌的Agent Payments Protocol将授权视为经过签名的指令，以选择性披露的JWT形式传递。一个指令证明用户已批准购买，另一个指令证明已批准支付，二者既可以公开并提前记录相关限制，也可以封闭并绑定到最终的购物车中。
第三，安全研究进展迅速。针对AP2的系统性研究列出了5类共48种独立威胁，其中8种的严重程度被评定为高，而且所有这些威胁都已在实际测试环境中得到验证，而不仅仅是理论描述。对于面试官而言，这是理想的素材，因为这些故障模式真实且具体，无需任何花招就能为问题增添深度。
收到的任务描述
表述方式虽有所不同，但要求大致如下：
- 购物者向客服请求购买某样商品，可能会设定最高价格或交货截止日期等限制条件。
- 客服会对比多家卖家，权衡各种选项后选定一家。
- 付款流程完成时，客服不会接触到任何原始的卡片数据。
- 购物者可以查看已获批的购买内容，后续如有争议也可进行处理。
- 绝不会重复进行任何购买操作，也不会超出购物者实际同意的范围。
第五项要求值得仔细阅读，因为所有难题都集中在这里。这五行文字涵盖了下面所有的复杂子问题；那些一开始就进行比较而非直接列出框架的候选人，早已甩开了大多数竞争者。通过练习真实的支付基础设施相关问题，可以快速掌握所需的术语，因为账本、幂等性和结算等内容都会以代理形式出现在这些题目中。
问题一：授权委托
购买时买方不在场，因此需要有人来代替其表示同意。
这种薄弱的解决方案只是将支付方式保存在系统中，等待用户同意后再由客服收取费用。但这存在问题，因为10点时对价格低于80英镑的咖啡研磨机的同意，并不能涵盖客服在10点04分选择的其它商品。模型、工具套装，甚至被篡改的产品描述都可能出现在这个漏洞之中。
相关标准通过三种方式来解决这一问题：
- 授权不再是单纯持有凭证，而是一个具有明确范围的签名对象。
- 该对象将意图与执行分开：开放式授权会设定价格上限和类别等限制，而封闭式授权则绑定到某个特定的最终购物车。
- 支付凭证被替换为仅对单个商家和单笔交易有效的令牌，这样被盗的令牌也只能用于购买一次单件商品。
需要明确强调的几点：需对每笔补助设置金额、商家、类别及有效期限制；在资金划转之前必须确认最终方案，确保签署的条款与实际购买的内容完全一致；同时应将授权指令视为真正的授权记录，而非仅为方便使用卡片而设计的包装。
第二个问题：状态绑定，或为何细致的代理机构会使用过时数据
几乎没人会主动提及这一点，但它是可以被量化的。
一个尽职的购物代理在做出选择前会仔细查看众多优惠信息。最终被选中的那个优惠，其实是在比较初期就看到的，这意味着代理机构越细致，其最优质的数据来源就越可能过时。
模拟结果附有一张图表。智能体会依次向每位卖家询价，每家花费3到8秒，随后用5到15秒时间综合分析所有信息并做出决策。价格和库存按泊松过程变化，最终得出的便是到决策时刻时所选报价是否已经变动的概率。
值得注意的是其中的规律：从一位卖家变为二十位卖家时，无论转换率如何，决策过时的概率都会增加约五倍，因此消费者期望的行为反而会削弱智能体自身的判断依据。在采用较为激进的动态定价策略时，每进行三次仔细比较，就有一次会遇到报价已经变动的情况。
这种设计带来的后果十分明显：
- 报价是由服务器生成的对象，每个报价都有唯一的编号且存在时间较短。
- 最终授权会绑定已完成购物车的哈希值，这正是封闭式指令所提供的功能。
- 在确认订单时，卖家会重新检查价格和库存，一旦发现不一致就会拒绝处理，而不会默默完成订单。
- 如果价格变动超出了买家设定的限制，系统会重新报价并向买家发送消息。
很多人容易忽略最后一点：拒绝无效订单是正确的做法，如果没有重新报价机制，价格错误就只会变成可靠性问题。
第三个问题：重试机制以及无用的幂等性密钥
每个解决方案都会提到幂等性密钥，但常规设置中其实隐藏着一些问题。
通常情况下，客户端会生成一个密钥并在重试时发送相同的密钥。但代理程序会破坏这一机制。如果响应丢失，代理程序往往不会重新发送完全相同的请求，而是重新规划，从而生成带有新密钥的新请求，服务器则会将其视为新的请求。
这种行为是通过直接建模而非假设得出的，在已产生费用且最多进行三次尝试后，有5%的响应会丢失：
- 当代理程序每次尝试都生成新密钥时，4.98%的订单会被重复收费，平均每单需支付1.052次费用。
- 当密钥在服务器端根据购物车绑定信息生成时，重复收费的情况降至0.00%，每单仅会被收取一次费用。
模拟出的4.98%与精确计算的5.00%概率相符，这是合理的，因为重复收费恰好发生在第一次响应丢失之时。
关键点在于：幂等键应基于购物者认可的信息生成，而非由调用方自行编造的内容。用于将已确认的订单与购物车关联的哈希值已经具备此功能，因此无需额外处理。
问题四：谁是正式的商家
这其实是一个以系统问题为伪装的商业问题，它决定了数据模型。
- 使用共享令牌时，卖家仍是正式的商家，这样代理平台就能避免在结算、税务及退款处理方面的责任。
- 如果由平台负责采购并转售，则代理的工作会更轻松，但同时也会涉及诸多监管要求。
- 应在两分钟内明确这一假设，因为退款、税务及纠纷等问题都与之相关。
问题五：将可审计性作为一项要求
在AP2分析中，五个威胁类别之一完全与责任追溯相关，即证据保留与可审计性。人们常常忽视这一点，但它却决定了六个月后争议是否能够解决。
针对每笔交易，需以不可更改的方式存储以下内容：
- 已签署的授权指令的两种形式，即开放状态和关闭状态。
- 已被批准的购物车哈希值以及该购物车内的商品信息。
- 报价编号，以及其生成时间和有效期。
- 执行操作的代理和模型版本，以及它们所依据的授权方式。
- 每一次拒绝操作及其原因，因为拒绝记录能够证明控制措施有效。
参考路径
要得到清晰答案，需完整追踪每一笔购买流程：
- 购物者提出带有限制条件的需求，平台则会发出在金额、类别和有效期方面都有约束的开放授权指令。
- 代理人从潜在卖家处收集报价，每位卖家都会回复一份包含编号和有效期的报价单。
- 代理人从中选择一份，并要求卖家确认最终订单，由卖家签字确认。
- 平台会根据该订单的哈希值创建一个封闭式委托，同时对照开放式委托的限制进行验证。
- 仅为该卖家发放对应金额的支付令牌。
- 卖家重新核对价格和库存，然后使用从订单哈希值生成的幂等键完成交易。
- 在发出任何回复之前，第一步到第六步的所有记录都会被保存到审计存储中。
- 如果第六步出现匹配错误，则返回到第二步；若变更超出购物者的限制，则将问题反馈给购物者。
这八个步骤的存在都是为了确保某些特定的故障不会被忽视，而面试官实际上就是在评估每个步骤与相应故障之间的关联程度。
对练习答案的评分
以下类型的答案会获得高分：
- 能在两分钟内阐述委托模型并始终遵循该模型；
- 将开放式授权与封闭式承诺区分开来，并说明为何两者都必不可少；
- 主动提及数据过时问题，最好还能给出大致的时间范围；
- 基于已确认的状态来实现幂等性，而非依赖调用方提供的信息；
- 将审计追踪视为一项必要要求，而不仅仅是简单的日志记录。
以下类型的答案会失去分数：
- 将智能体想象成行动迅速的人类，但实际上大部分难题都源于它与人类的差异；
- 赋予智能体任何可重复使用的凭证；
为何值得为这个主题做准备
一旦对于所有常见问题的完美答案都能免费获得，波兰语就不再能作为有用的招聘指标。而代理式结账正是目前缺乏这种快捷解决方案的案例。相关规范仅诞生数月，威胁研究也仍处于初期阶段，各种权衡方案尚未形成共识。
这就意味着，该提示词不再奖励那些已不再使用的技能标准题库：即基于真正被理解的约束条件进行推理的能力。熟练掌握这一能力也能为任何替代它的题目做好准备，因为核心思路并不会改变。只需考虑当API另一端不再是人类时会发生什么变化即可。
相关阅读
- 七种智能体循环设计模式及其失效场景：ReAct、Maker-Checker等 —— 一份涵盖从计划-执行-验证到人工介入等各种智能体循环设计的实用指南，说明了每种模式的适用场景、应避免的情况以及选择方法。