01

60 秒回答模板

金融场景里 Agent 超时、失败或中断时，第一原则不是尽快重试，而是确保不重复扣款、不重复转账、不产生不可追踪的资金状态。我会先把操作分层：查询、草稿生成、风控校验等可安全重试；扣款、汇款、入账、撤销等资金变更必须走幂等和状态机。每笔操作都要有业务幂等键、全链路 requestId、订单状态和外部支付流水，Agent 只能推动状态流转，不能绕过资金系统直接执行。超时后先查状态和流水，再决定继续、回滚、人工确认或补偿；对高风险动作要二次确认、权限校验和操作审计。兜底上要有任务恢复、对账、告警、人工处理队列和补偿流程，最终以账务一致和可审计为准。

考点 金融 Agent 重试的第一目标是资
难度 真实面经题
回答目标 守住 Agent 资金安全边界
02

深入解析

01

先区分可重试和不可随意重试

金融 Agent 里的读取、试算、信息补全、风控预检通常可以重试，但扣款、汇款、入账、退款、撤销等会改变资金状态的动作不能简单重放。面试回答要先划清操作风险等级，把重试策略建立在业务语义上，而不是只按 HTTP 超时或异常码处理。

02

用幂等键保护资金动作

每一次资金相关动作都应绑定业务幂等键，例如订单号、交易号、用户确认版本和操作类型组合。下游资金系统要能识别同一意图的重复请求，只返回已有结果，不重复执行。Agent 重试时必须携带同一幂等键，不能重新生成一个看似新的交易。

03

状态机比临时标记可靠

跨境汇款或支付链路通常需要明确状态机，例如创建、待确认、处理中、成功、失败、状态未知、待人工处理、已补偿。Agent 只能按合法状态迁移推动任务，不能凭模型判断跳过关键状态。中断恢复时也要从持久化状态继续，而不是从对话上下文猜测。

04

超时后先查证再处理

金融链路超时并不等于失败，可能是下游已成功但回包丢失。因此兜底流程应先查订单状态、支付流水、银行或通道回执，再决定是否继续轮询、发起幂等重试、进入人工确认或触发补偿。直接再次发起转账是典型风险。

05

高风险操作需要确认和审计

Agent 可以辅助填单、解释汇率费用、推荐路径，但真正提交资金动作前要有用户确认、权限校验、风险提示和必要的人工审批。系统还要记录输入、模型建议、工具调用、用户确认、状态变更和下游回执，保证事后能审计责任链。

06

用对账和补偿闭环兜底

最终兜底不是让 Agent 自己猜答案，而是建立对账任务、异常告警、人工处理队列和补偿机制。比如发现账务系统、交易系统和通道流水不一致，要冻结后续动作、标记状态未知、通知运营处理，并把结果回写到 Agent 任务状态。

03

易错点

  • 把金融场景当成普通接口超时，直接指数退避重试。
  • 没有区分查询、预校验和真实资金变更操作。
  • 每次重试生成新的交易号或幂等键，造成重复扣款风险。
  • 把超时等同于失败，没有先查询下游真实状态。
  • 依赖模型对对话上下文的记忆恢复任务，没有持久化状态机。
  • 缺少用户确认、权限校验、审计、对账和人工兜底。
04

面试官追问

如果下游支付通道超时但后来实际成功，你的系统如何避免二次转账？

关键是同一业务意图必须使用同一幂等键。超时后先查询订单、流水和通道回执；如果已成功，只返回已有结果并关闭重试，不再发起新的资金动作。

幂等键应该由 Agent 生成还是业务系统生成？为什么？

应由业务系统生成和持久化，Agent 只能引用。因为幂等键必须和订单、用户确认版本、操作类型绑定，并被下游资金系统识别，不能依赖模型临时生成。

状态未知时，产品和工程上分别应该如何兜底？

工程上进入状态未知、冻结后续动作、启动轮询和对账；产品上给用户明确处理中或待确认状态，不承诺成功或失败。超过阈值后进入人工处理和补偿流程。

哪些金融 Agent 动作可以自动执行，哪些必须人工确认？

信息查询、费用试算、表单草稿和低风险解释可以自动执行；扣款、汇款、退款、撤销、额度变更等资金或权限动作必须经过确认、校验或人工审批。

对账发现交易系统成功但账务系统失败，你会怎么处理？

先冻结交易并进入异常队列，依据账务凭证、支付流水和业务订单做对账。确认是账务写入失败时走补账或补偿；确认通道状态不确定时继续查询或人工处理。

Agent 的审计日志应该记录哪些字段？

至少记录用户请求、模型建议、工具调用参数、幂等键、状态迁移、用户确认、权限校验、下游流水、异常原因、人工处理记录和最终对账结果。