Sapan Pandya，高级软件工程师、IEEE 高级会员——访谈系列

Sapan Pandya是常驻新泽西州的高级软件工程师和 IEEE 高级会员，在弹性分布式事务系统领域拥有十余年经验。他的工作涉及事务完整性、软件与物理设备的集成、生产环境故障排查，以及受监管环境中的部署验证。他拥有 Stevens Institute of Technology 的计算机科学硕士学位，并参与学术评审和技术研究。

Pandya 的研究涉及自助服务终端网络安全、边缘 AI 和 AI 辅助的可靠性工程；他在生产环境中的经验，则影响了他对证据、事务结果和运营问责的关注。在本次访谈中，他探讨了幂等性、相互冲突的事务记录、恢复系统中的不确定性，以及 AI 智能体在操作任务关键型基础设施之前所需的控制措施。他还区分了实践工程经验与通过文献分析及受控或合成测试开展的研究。

您的职业生涯一直专注于软件可靠性和分布式事务系统。这些经验如何塑造了您对可靠性的理解？又有哪些挑战影响了您对利用 AI 管理复杂系统的看法？

我的关注点已经从“某个组件是否正常运行”转向“客户的事务是否已完成，以及能否对其进行核算”。

职业生涯早期，我的大部分精力都放在应用程序的行为上：验证输入、处理响应，并确保界面遵循预期的工作流程。随着职责扩展到系统集成、生产环境故障排查和部署验证，我不得不把目光放到单个组件之外。

一个服务可能已经完成工作，而另一个服务仍在等待确认。软件可能记录了操作成功，但物理设备却未能交付预期结果。各个组件分别通过测试，本身并不能证明整个交互过程会正常运行。

这些经历让我特别关注系统之间的边界。每个组件掌握哪些信息？它们依赖哪些假设？当这些假设不再成立时，会发生什么？

这也影响了我对 AI 的看法。帮助工程师汇集证据、识别模式并更快地调查故障，确实很有价值。但对“可能发生了什么”的解释，不等于对“实际发生了什么”的核实记录。

我希望 AI 能减少故障调查所需的工作量，同时不降低解决问题所需的证据标准。

您曾强调，代码在技术层面正确，并不总能保证事务结果正确。能否举一个具体例子，说明事务看似因超时而失败，实际上却已经完成？系统自动重试操作时可能会出现什么问题？工程师应如何防止重复交易？

假设有一笔 50 美元的付款。应用程序发送请求后，支付服务成功记录了这笔付款，但响应在到达应用程序之前丢失了。

尽管付款已经完成，客户看到的却是超时提示。如果应用程序重新提交付款请求，客户可能会被再次扣款。

超时说明响应未能及时到达，但无法说明底层事务是否成功。

一种常见的防护措施是幂等性：允许重复发送同一个逻辑请求，而不会产生另一笔资金交易。应用程序在重试过程中保留同一个操作标识符，接收服务则将其识别为原始请求，而不是一笔新的购买。

关键不只是附上一个标识符。服务必须强制执行这一标识，并保留足够的信息，以区分已完成的操作和仍在进行的操作。如果下游操作忽略该标识符，它就无法受到保护。

如果结果仍不确定，恢复流程应检查现有事务并核对相关记录，而不是立即创建一笔替代交易。

我还会限制重试次数，并明确规定自动恢复无法确定结果时该如何处理。客户需要明确的待处理状态和解决问题的途径，而不是反复被扣款或一直看到处理页面。

在分布式系统中，数据库、后端服务和实体自助服务终端可能会针对同一笔事务报告相互矛盾的信息。您在生产环境中遇到过这类不一致吗？当时是如何调查并解决的？AI 是否能在协调这些相互冲突的记录方面发挥作用？

是的，调查事务状态不一致一直是我生产工作的一部分。为了说明其中的思路，同时避免讨论工作中的具体事件，我会举一个假设性的例子。

设想一个普通的自助结账场景：支付服务记录显示购买成功，打印机报告已接收收据打印任务，随后屏幕却显示错误。这些观察结果可能反映的是交互过程中的不同阶段，并不能证明整笔交易都失败了。

我会先根据交易标识符以及相关服务和设备记录，还原事件的先后顺序。然后，我会确认每项观察结果究竟能证明什么。打印机接收了任务，并不一定意味着纸质收据已经送到顾客手中。系统收到请求，也不一定意味着其财务影响已经正式入账。

如何解决，取决于哪个阶段出了问题。如果只需处理输出阶段的问题，重做整笔交易可能并不妥当。如果现有证据无法确认实际发生了什么，就应在有人调查期间对受影响的操作保持受控。

要彻底解决问题，还需要查明这种不一致为何会发生，而不只是修正某一条记录。

AI 可以帮助关联事件并找出缺失的信息。我会让它列出相互竞争的解释，并说明各自依据的证据。它应该帮助缩小调查范围，而不是挑选听起来最可信的解释来消除记录之间的冲突。

随着 AI 智能体从诊断生产事故发展到提出或执行恢复操作，在 AI 系统可以重试、撤销或修改交易之前，应当设置哪些保障措施？幂等键、交易日志和对账机制等确定性控制，如何防止 AI 引发更多故障？

我会把提出操作建议与授权和执行操作分开。

AI 智能体可以建议重试，但应由独立的控制机制判定是否允许重试。该机制应检查交易的当前状态、操作标识、智能体的权限，以及安全执行该操作所需满足的条件。

这项检查必须在操作执行时进行，而不能只在模型初次检查事故时进行。与此同时，其他流程可能已经完成了这笔交易。

还应严格限制智能体可使用的工具。获准查询交易状态，不等于获准撤销付款或修改财务记录。智能体不能仅仅因为自己偏好的解决方案需要更多访问权限，就自行扩大权限。

幂等性可以限制重复操作造成的影响。日志可以保留调查所需的历史记录。对账可以检查相关记录是否一致。但这些措施无论单独还是合起来，都不能证明某项拟议操作是恰当的。

我还会记录所依据的证据、提出的建议、授权决定以及实际结果。这样事后就能审查这次干预。

这些控制应由模型之外、可进行测试的软件来强制执行。要求智能体谨慎行事的指令可以提供有用的指导，但不能代替授权机制。

设想这样一种情况：AI 监控系统检测到一笔交易似乎失败了，并建议自动撤销该操作。如果交易实际上已经成功，只是确认信息有所延迟，这种干预就可能引发新的问题。工程团队应如何设计 AI 驱动的恢复系统，使其能够识别不确定性，并避免根据不完整的信息采取纠正措施？

系统需要有一个真正的“结果未知”状态。否则，它很可能会把信息缺失误判为操作失败。

确认信息延迟是展开调查的理由，而不是自动撤销交易的理由。撤销本身也是一项会产生后果的金融操作，因此必须有独立确认的理由，并取得适当授权。

我会把应对措施分成两条路径。调查路径可以查询状态、收集缺失的事件信息、比对记录，并通知负责团队。金融操作路径则应保持阻止状态，直到满足相关条件。

这样可以避免用 AI 的置信度评分取代交易证据。模型可能对某种解释很有把握，但该解释可能建立在不完整的信息之上。

还需要设定明确的升级处理节点。让一笔交易无限期处于待处理状态，并不能令顾客满意。应有人负责处理尚未解决的个案，并掌握足够的背景信息，以判断下一步如何安全处理。

因此，恢复流程应当既能说明“我目前还无法证明应当更改这笔交易”，也能说明“需要采取以下措施才能解决问题”。

只有当系统具备切实可行的方式来处理不确定性时，识别不确定性才有意义。

围绕自主式 AI，最重要的问题之一是：何时仍必须取得人工批准？您认为哪些生产环境中的恢复操作可以由 AI 独立执行，哪些操作则应始终要求人工授权？当财务交易、法规合规或客户信任受到影响时，组织应如何划定这些界限？

我会根据判断错误可能造成的后果来划定界限，而不是看某项操作是否被贴上“AI”的标签。

只读调查是一个合理的起点，前提是智能体只能访问获准的信息。它可以收集诊断记录、归类相关警报并准备事件摘要，同时不得更改底层交易。

在条件经过独立验证且影响范围有限的情况下，一些预先定义的恢复流程也可能适合自动化。

如果拟议的干预措施超出获批流程的范围、记录彼此矛盾且财务结果仍未确定，或者操作会更改安全控制或智能体自身的权限，我会要求先取得人工授权。智能体不应自行批准这类决定。

这并不意味着每笔常规财务操作都需要由人批准。按照既定规则处理业务，与允许模型在事件发生期间自行想出一种修正方案，是两回事。

人工审核也必须真正发挥作用。审批界面应展示佐证材料、尚存的不确定性、预期影响以及可选方案。如果没有这些背景信息，只让某人批准一段语气笃定的文字，几乎起不到什么保护作用。

这些界限应在部署前达成共识。系统发生故障时，不是决定自动化系统应拥有多大权限的合适时机。

您在容错后端系统、可观测性工具以及软件服务与物理硬件之间的集成方面积累了丰富经验。AI 智能体需要哪些生产环境遥测数据和证据，才能可靠地诊断事件？工程团队如何区分有用的 AI 生成建议与看似合理、实则错误且可能加剧故障的结论？

我会先从能够串联客户操作在相关系统中的全过程的证据入手：交易标识符、服务事件、持久化状态变更、设备响应以及通信故障。

软件版本和配置变更也很重要。某项故障若在发布之后开始出现，可以为调查提供有价值的线索，但仅凭时间先后并不能证明因果关系。

智能体还需要了解证据的局限性。日志可能不完整，记录可能延迟到达，时钟也可能彼此不同步。没有收到确认，并不等于证明某项操作没有发生。

有用的诊断应将观察结果与解释区分开来。“客户端记录到超时”是观察结果；“后端不可用”则是一种解释，需要更多证据支持。

我希望建议能指出其依据的记录，说明哪些情况仍不明确，并明确提出需要进行哪些额外检查，才能证实或推翻其结论。

随后，工程师应根据原始记录核实可能造成重大影响的建议，而不能只依赖智能体的摘要。当摘要压缩了冗长或相互矛盾的事件历史时，这一点尤为重要。

我采用的标准很简单：另一位工程师能否循着证据得出站得住脚的结论？如果解释经不起这样的检验，就还不能据此推动生产环境变更。

在您发表的关于彩票和博彩终端勒索软件韧性的研究中，您使用模拟 500 台终端的合成环境，对一套 AI 辅助安全框架进行了评估。最重要的研究发现是什么？读者在解读这些结果时应了解哪些局限？若要将所提出的架构应用于实际生产环境，还需要进行哪些额外验证？

我希望考察的不只是检测能力，还包括终端环境如何限制攻击、识别攻击，并在保留事件证据的同时完成恢复。

由此形成的韧性安全框架结合了预防性控制、AI 辅助异常检测以及明确的响应和恢复机制。AI 部分涉及的是可疑行为检测。这项实验并非允许语言模型智能体独立修改财务交易。

评估采用了一个代表 500 台终端的合成环境，进行了为期 72 小时的模拟，并通过行为模拟来重现勒索软件攻击，而不是在 500 台实体终端上部署该框架。

与研究采用的仅使用防病毒软件的基线方案相比，平均检测时间从 52 分钟降至 31 分钟，平均恢复时间则从 120 分钟降至 56 分钟。

这些是在实验条件下对组合框架进行评估所得的结果。不能将其归因于 AI 本身，也不能将其视为在实际运行环境中的性能保证。一项有价值的发现是，仅仅提前检测到问题，并不能带来同等程度的恢复效果。遏制措施和恢复方案的设计同样重要。

这些局限性不容忽视。模拟的工作负载、网络条件、攻击行为和基准防御措施，无法代表所有运行环境。不同的设备和应用都需要重新验证。

在投入生产环境使用之前，我希望先进行有代表性的硬件测试、独立的安全评估和更长时间的评测，并仔细衡量误报和处理开销。

我还会针对正常的交易活动测试恢复流程。如果这一流程会丢失核算已完成交易所需的信息，那么仅仅恢复可运行的软件映像并不足够。

这项研究为进一步测试奠定了基础。在真实运行环境中证明系统能够安全运行，则是另一个步骤。

您的视角融合了多年的生产工程经验，以及对软件可靠性和 AI 驱动安全的学术研究。您能否区分一下，哪些可靠性机制是您亲自在实际生产系统中实施或运行过的，哪些则是您通过研究或模拟测试探索的？您认为目前哪些 AI 驱动的恢复能力已经切实可用，哪些仍大多处于实验阶段？

我的生产工作包括软件开发与集成、交易验证、故障排查、测试和发布验证。

已发表的研究是我工作中的另一个独立部分，每项研究都应结合其明确说明的方法和局限性来理解。

关于勒索软件的论文在合成测试环境中评估了一种拟议的安全框架。我的边缘 AI 论文基于文献分析，探讨设备端智能及其在交易终端上的潜在应用。我的 IEEE FeedForward 文章则通过受控模拟研究一种 AI 辅助的可靠性架构，其中包括监控、升级处理和回退行为。

不应将这些论文中的任何一篇解读为我曾部署过一个有权处理实时金融交易的自主 AI 智能体的证据。

在实际应用中，我会优先考虑工程师能够检查的辅助功能：关联到源记录的事件摘要、跨警报的关联分析，以及建议的诊断检查。这些功能是否有用，仍需在其实际运行环境中进行衡量。

更棘手的问题是开放式恢复，即模型在未曾预料到的情况下选择并执行变更。与提出有用的诊断建议相比，这需要高得多的证据标准。

在我看来，生产经验与研究相辅相成：前者确立了我所了解的运行问题，后者则探索仍须经过验证才能证明其价值的方法。

展望未来，随着 AI 智能体逐渐具备更强的能力，能够检测异常、诊断故障并协调分布式系统的恢复，您认为自主系统与人类工程师之间的关系将如何演变？在组织能够放心地赋予 AI 更大的权限，使其管理关键任务生产基础设施之前，需要具备哪些技术防护措施、运行证据和问责机制？

我预计，AI 将承担更多收集和整理事件全貌的工作。工程师可以直接获得一条实用的时间线、受影响的组件、相互竞争的解释以及缺失的证据，而不必再花那么多时间手动收集这些材料。

这样一来，人们就能腾出更多时间，作出需要理解系统职责及变更后果的决策。

我会逐步扩大执行权限。智能体可以先在影子模式下运行，只提供建议而不采取行动。团队可以将这些建议与经过审核的结果进行比较，并测试智能体在信息缺失、相互矛盾或已经过时时的表现。

评估应涵盖错误干预、问题漏检、不必要的升级处理，以及从智能体自身失误中恢复的能力。如果一条快速建议会把响应团队引向错误方向，那么它就没有价值。

更大的权限也应以条件为前提。模型更新或重大系统变更可能使先前的测试结果失效。当智能体的行为不再符合要求的标准时，团队需要有办法缩减或撤销其权限。

随着自动化程度提高，人类仍须承担责任。必须有人负责制定运行规则、明确变更所需的证据，以及建立故障调查流程。

我认为，工程师花在收集信息上的时间会减少，更多时间则会用于明确、测试和维护自动化操作获得正当依据所需满足的条件。

感谢您带来的精彩访谈。希望关注他在分布式事务可靠性和负责任地借助 AI 进行恢复方面工作的读者，可以联系 Sapan Pandya。