Production-grade AI agents for financial compliance: Lessons from Stripe

TL;DR · AI 摘要
Stripe 使用 AWS 的 Amazon Bedrock 构建了生产级 AI 代理系统,将合规审查时间减少了 26%,同时保持人工监督。
核心要点
- Stripe 使用 AI 代理系统将合规审查时间减少了 26%。
- AI 代理系统实现了 96% 的有用性评分,人工专家仍掌控最终决策。
- 通过提示缓存和任务分解,Stripe 优化了成本并提升了合规操作的可扩展性。
结构提纲
按章节快速跳转。
- §引言
Stripe 处理了 1.4 万亿美元的年支付交易量,需要每天审查数千笔交易。
Stripe 的使命是推动互联网 GDP 增长,但其规模带来了合规操作的挑战。
Stripe 面临如何在不增加人力的情况下扩展合规操作的挑战。
代理 AI 能够解决合规操作中的资源密集问题,并提升效率。
Stripe 使用 Amazon Bedrock 构建了 ReAct 代理框架,并设计了专用代理服务。
Stripe 分享了任务分解、编排模式和成本优化方面的关键经验。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- Stripe 的 AI 代理系统
- 技术架构
- ReAct 代理框架
- Amazon Bedrock
- 关键经验
- 任务分解
- 编排模式
- 成本优化
- 成果
- 减少 26% 审查时间
- 96% 有用性评分
金句 / Highlights
值得收藏与分享的关键句。
Stripe 使用 AI 代理系统将合规审查时间减少了 26%,同时保持人工监督。
AI 代理系统实现了 96% 的有用性评分,人工专家仍掌控最终决策。
通过提示缓存和任务分解,Stripe 优化了成本并提升了合规操作的可扩展性。
用于金融合规的生产级AI代理:来自Stripe的经验 | 人工智能
用于金融合规的生产级AI代理:来自Stripe的经验
本文由Stripe的Christopher Phillippi和Chrissie Cui共同撰写。
Stripe每年处理全球50个国家约1.4万亿美元的支付交易量,这要求合规团队每天审查数千笔交易。本文探讨了Stripe如何利用AWS和Amazon Bedrock构建一个生产级AI代理系统,将审查处理时间减少了26%,同时保持人工监督。本文涵盖了技术架构、基础设施决策以及部署代理AI所学到的经验,这些AI系统实现了超过96%的有用性评分,且最终决策始终由人类专家掌控。
在本文中,你将了解到Stripe如何构建用于金融合规的生产级AI代理系统。我们将介绍Stripe的ReAct代理框架的技术架构,以及专用代理服务背后的基础设施决策。我们还将讨论人工监督在保持问责制中的作用,以及关于任务分解、编排模式和通过提示缓存进行成本优化的关键经验。到文章结束时,你将了解如何设计可扩展合规运营的代理系统,同时不损害质量和可审计性。
Stripe的规模与合规挑战
Stripe的使命是推动互联网的国内生产总值(GDP)增长。这一目标需要可编程的金融基础设施,以支持各类规模企业的顺畅交易和运营管理。截至2026年初,Stripe已从一个以开发者为中心的支付API扩展为全球经济体系中的关键支柱。公司支持全球50个国家的数百万家企业,从初创公司到财富500强企业中的62%,并处理约1.4万亿美元的年支付交易量。这一规模约占全球GDP总量的1.3%,使Stripe处于技术创新与严格监管框架交汇的关键位置。
合规扩展问题
随着Stripe的全球足迹扩展到50个国家,组织面临一个关键挑战:如何在不按比例增加员工数量的情况下扩展合规运营,同时保持监管质量标准。每天,合规团队都会进行详细审查,以识别和缓解金融犯罪风险。然而,熟练的分析师却花费多达80%的时间在碎片化的系统中收集文件,而不是进行高价值的风险评估。Stripe的解决方案是将AI代理与自动化编排相结合,将合规从资源密集型过程转变为可扩展的引擎。这种方法通过帮助组织实时识别95%的卡片测试攻击,并减少20%的不必要的客户摩擦,解决了全球约2060亿美元的合规负担。这种方法还保持了监管机构所需的可审计性和精确性。
为什么使用代理AI进行合规?
传统自动化在处理复杂且基于判断的合规工作时存在局限性,因此需要AI代理来以规模、一致的质量和完整的可审计性处理辅助调查,同时保持人类的控制。
- 监督与问责 – 以人为中心的验证,具备可配置的审批工作流程和多层次的决策检查点。人类始终掌握主导权,并由代理提供支持。
- 透明度 – 完整的审计追踪,对每项操作、决策和理由进行不可更改的文档记录。
- 效率 – 预调查和动态分析使得能够以更快的速度进行更深入的审查。
技术架构
Stripe 的代理合规系统的技术实现由三个关键组件组成:任务分解与编排、ReAct 代理框架以及支持性基础设施服务。每个组件在实现可扩展、可审计的合规自动化方面都发挥着至关重要的作用。
任务分解与审查编排
将单个代理分配来一次性处理这个漫长而复杂的审查任务是行不通的。一个没有约束的单一代理会过于关注错误的事情,而忽视真正需要关注的内容。相反,Stripe 通过将复杂的审查任务分解为可组合、小块的子任务,使解决方案变得可处理。每个子任务可能依赖于其他子任务的结果,形成一个有向无环图(DAG)。这些框架有助于验证每个代理流程仅在经过验证的问题上运行,这些问题的质量已经通过质量测试得到确认。它们还帮助确认调查涵盖了必要的方面,并为代理提供足够的上下文和专注度以提供高质量的结果。
尽管在每个子任务中对代理的响应进行了严格的质量测试,Stripe 的实现并不完全依赖于代理的响应。相反,这些响应作为补充信息提供给人工审核员,人工审核员必须最终回答每个子任务。这解决了监督和问责的问题,同时仍然能够获得效率方面的优势。高层次的审查流程如下图所示。
审核员与审查工具进行交互,该工具了解当前的问题以及后续问题需要该答案作为上下文。工具作为编排器,将人工审核的答案作为上下文传递给后续问题。
ReAct 代理框架实现
为了获取每个子问题的研究信息,Stripe 使用 ReAct(推理和行动)代理框架构建了一个合规代理。除了使用大型语言模型(LLM)和亚马逊 Bedrock 上的一种基础模型(FM)进行推理外,代理方面通过工具调用动态收集相关信号。Stripe 选择此代理框架是为了应对可能与特定主题相关或无关的近乎无限数量的信号问题。代理确定哪些信号相关,并提出后续问题,直到它们足够自信以提供最终答案。高层次的代理逻辑如下图所示。
为了演示这个流程,想象一下被问到以下问题:“10 除以 π 的答案是什么?”
如果你是一个 ReAct 代理,你的第一个想法会是考虑你是否已经知道答案。你不知道,所以你会提出一个动作,即拿出计算器并输入 10/π。计算器随后会返回一个观察结果。你的下一个想法会是判断你是否已经有了答案,并将该计算作为最终答案。你可以想象更复杂的问题,例如“生成一份预测公司明年收入的分析”,这需要多次数据库查询(工具)和解释(思考)的迭代过程。
在 ReAct 循环中,每当在“思考”块中请求一个工具时,代理框架会停止 LLM 的执行,转而通过编程方式运行该工具。然后,它会将该输出作为观察结果强制返回给代理,然后再允许代理继续执行。这种注入模式实现了一种闭环控制机制,具有以下优势:
- 使代理的推理基于实际数据 —— 通过强制要求每个工具的输出都必须作为观察结果进行处理,这可以防止代理产生幻觉或编造工具结果。
- 保持上下文的一致性 —— 强制代理在继续之前明确承认并推理每一条检索到的信息。
- 防止推理偏离 —— 观察步骤充当检查点,有助于验证代理的推理过程是否仍然与事实性的工具输出保持一致,而不是基于推测性推理。
- 支持审计性 —— 创建一个明确的工具调用 → 观察 → 推理的追踪记录,可以用于合规审查。
这类似于工程中的反馈控制系统。代理在继续下一步操作之前,必须首先处理来自其上一步操作的反馈(观察),从而防止可能导致幻觉或偏离轨道推理的开环行为。
这种方法的一个挑战是,当任务非常复杂,需要很多轮次和观察时,后续轮次中的提示可能会变得非常长,特别是当观察内容冗长时。子任务分解可以限制每个问题的范围,以保持轮次数量较少。提示缓存也有助于减少输入令牌的成本,这是此处的主要成本驱动因素。通过提示缓存,你只需为每个轮次中附加到先前消息的新观察和思考内容付费。Amazon Bedrock 提供了这一功能。
完整的代理式审查架构和基础设施
Stripe 依赖大量基础设施来支持实际的代理执行。下图展示了完整的架构。
完整的架构包括之前提到的审查界面和协调器,以及一个托管代理逻辑并促进执行的代理服务。代理服务由 Stripe 的 LLM 代理服务支持,并通过可用的代理工具连接到内部信号。
构建专用的代理服务
在该项目之前,Stripe 没有代理服务,而该项目促使 Stripe 要求创建该服务。最初,Stripe 尝试将代理嵌入传统的机器学习推理引擎中。由于以下原因,这种方法很快被拒绝:
- 计算配置文件 —— 传统机器学习是计算密集型的,需要昂贵的硬件,如 GPU、快速多线程 CPU 或大内存分配。相比之下,代理式应用主要是网络受限的,需要等待基础模型完成或工具调用执行。
- 延迟 – 参考之前描述的 ReAct 流程,代理完成所需的时间是不确定的,这取决于它需要进行多少轮工具调用。一个长时间运行的代理查询或数据库工具调用可能导致线程闲置几分钟,而相比之下,XGBoost 模型可以在毫秒内完成。
- 不同的 API – 与传统机器学习倾向于输出基本类型(浮点数、布尔值等)不同,代理需要在它们的架构中具有更大的灵活性来标注结果。一些代理需要维护有状态的对话状态。
因此,Stripe 建立了它自己的代理服务,最初类似于一个无状态的、同步的推理端点。如今,它也能够处理有状态的、多轮对话的代理。它从发布时的几个代理,不到一年的时间里已经增长到超过 100 个代理。
LLM 代理架构
Stripe 的 ReAct 代理不会直接调用 Amazon Bedrock。相反,Stripe 使用一个名为 LLM Proxy 的微服务作为其访问 LLM 的标准方法。下图展示了 LLM Proxy 的架构。
Stripe 使用 LLM Proxy 服务的原因如下:
- 噪声邻居 – Stripe 有许多团队使用 LLM 来进行各种应用。LLM Proxy 提供了保护措施,防止其他团队占用特定模型的 LLM 带宽,从而避免资源竞争。
- 一个 API,多个模型 – 单一端点简化了在 Amazon 和领先的 AI 公司的基础模型之间指定功能,如提示缓存或工具调用。更改模型只需更改模型类型作为参数,而不是每个使用场景管理许多不同的客户端。
- 模型回退 – 这提供了在资源受限或完全失败的情况下自动指定默认模型的能力。
- 监控 – 通过要求认证,该服务可以跟踪模型使用情况,以帮助预测未来的资源需求,并根据应用的隐私性确认使用了适当的模型。
架构组件如何协同工作
人工审核人员主导审核过程,使用代理的响应作为预取的研究资料。在他们回答问题时,这些响应可以用于同一审核过程中的提示,以提出更深入的问题,从而将审核问题组织成有向无环图(DAG)。
对于给定的问题,代理可以调用工具以动态访问内部数据或服务。这种方法被使用,是因为可能需要检查的相关信号通常比可以包含在提示中的信息要多得多。代理的工具调用特性意味着思考日志中只包含回答当前问题的相关数据,而没有额外的不相关信息,从而引导注意力。
代理本身由 Amazon 和领先的 AI 公司的基础模型驱动,这些模型负责思考并确定需要哪些工具调用。代理应用程序通过 LLM 客户端访问 LLM,该客户端抽象了诸如提示缓存和模型回退等功能。
Amazon Bedrock 集成优势
Stripe 在其 LLM Proxy 中使用了 Amazon Bedrock。Amazon Bedrock 提供了以下进一步的优势:
- 标准化的隐私和安全 – 作为支付处理器,Stripe 必须在隐私和安全方面格外谨慎。Amazon Bedrock 帮助验证来自 Amazon 和领先 AI 公司的基础模型是否符合现有的安全和隐私限制,而无需对每个模型进行额外的审查。
- 功能丰富 – 正如之前所述,Amazon Bedrock 允许在支持的模型上进行提示缓存。此外,Amazon Bedrock 还允许对模型进行微调和部署自定义模型,这正是 Stripe 在未来一年中计划重点投入的方向。
- 一个 API,多种模型 – 由于模型都属于同一个 API,集成非常简单。更换模型只需使用不同的模型名称。Amazon Bedrock 还支持来自 Amazon 和领先 AI 公司的多种不同基础模型,为 Stripe 提供了行业标准的性能。
用于法规合规的审计追踪实现
尽管 Stripe 最终使用人工审核员来做出判断和决策,但系统仍必须确保其经得起监管审查。因此,Stripe 实现了日志记录功能,以便可以历史地检索每次运行的完整代理日志。每次代理的操作、决策和理由都会被记录下来。
结果与影响:审核速度提升 26%,帮助性评分超过 96%
通过代理自动化,Stripe 将中位审核处理时间减少了 26%,同时保持了审核员超过 96% 的帮助性评分,且人工审核员仍然掌控决策。这一切是在提供符合审查标准的完整审计追踪的前提下实现的。
随着 Stripe 的持续增长,组织将能够按比例满足风险管理的需求。人工审核员可以将时间集中在更复杂的问题或新的调查机会上,从而提升合规计划的效果。
从生产部署中获得的关键经验教训
在构建和部署这个生产级代理 AI 系统的过程中,Stripe 总结出了一些关键见解,这些见解对项目的成功起到了重要作用,并可为类似实施提供参考。
小任务 – 保持代理任务足够小,以便于工作记忆处理。应逐步测试质量,而不是直接进入全面自动化。
编排 – 异步工作流架构和 DAG 支持对于复杂的代理交互至关重要,同时在大规模情况下仍能保持可审计性和人工监督。
基础设施 – 专用的微服务架构至关重要,因为代理的资源使用情况与传统的机器学习模型有本质的不同。传统的推理系统是计算密集型的,优化用于在昂贵的 GPU 硬件上实现毫秒级响应。而代理是网络密集型的,需要花费数分钟等待大语言模型(LLM)调用和工具执行,且延迟模式不可预测。专用的代理服务通过异步执行模式处理这些长时间运行、有状态的交互。这使得线程能够高效地管理多个并发的代理会话,而不会因外部调用而阻塞。通过在代理回合之间重用常见的提示前缀,而不是在每一步重新处理整个对话历史,令牌缓存将成本降低了 60%。成本监控跟踪每个代理调用的令牌使用情况,帮助团队预测随着工作负载的扩展开支情况,并在影响预算之前识别优化机会。这种以基础设施为核心的方法将代理从实验原型转变为一个生产服务,支持 Stripe 上超过 100 个代理。
保持人类控制 – 代理提供协助,但专家审核人员保留最终决策权。通过设置限制条件来约束代理的上下文范围。
下一步
最初,Stripe 聚焦于在审核甚至开始之前就能回答的问题。其余的问题可能需要在审核过程中已知并验证的上游上下文信息。这将导致更复杂、多步骤的调查,协调实时答案作为审核过程中的上下文,从而支持更深层次的效率提升。目前 26% 的减少代表了初步进展。
由于 Stripe 不愿意通过使用这项技术来接受风险容忍度的增加,团队会将代理调查组件与人类质量标准进行测试。在允许该组件在生产环境中向审核人员提供信息之前,团队会通过实际的人类验证。团队还在探索使用大语言模型(LLM)快速判断并剔除低质量方法的途径。
Amazon Bedrock 提供了 Stripe 正在探索的定制化功能,以进一步增强其合规系统。目前,Stripe 通过工具调用使用检索增强生成(RAG)实现动态知识注入,使代理能够访问实时合规数据。展望未来,Stripe 正在考虑使用 Amazon Bedrock 的微调功能,针对金融合规任务调整模型行为。这将有助于锁定模型质量,并随着模型的演变减少重新评估的开销。此外,Amazon Bedrock 提供了持续预训练选项,用于整合领域特定知识,这可能有助于在代理推理中构建更专业的合规专业知识。Amazon Bedrock 的模型版本管理和 6 个月的弃用通知窗口有助于战略性地规划这些定制化工作,仅在模型显著提升调查能力时才进行模型升级。这些互补的技术共同作用,以在合规操作扩展时平衡性能、稳定性和适应性。
结论
Stripe 已经证明,代理可以加速人工审核流程,在保持人类拥有决策权而非完全自动化的情况下,实现了审核处理时间减少 26%,同时保持了超过 96% 的有用性评分。Stripe 并不是仅仅依靠代理本身的力量,而是通过构建限制代理在特定审核领域内运作的框架,使代理在这些领域内取得成功。为了实现这一点,Stripe 需要新的代理服务基础设施,这一基础设施受到传统机器学习推理系统的启发,但又有所不同。
这一切得益于 Amazon Bedrock,它为 Stripe 提供了隐私保护和模型选择功能,从而支持了审核效率的大幅提升,这些功能预计将在许多其他领域得到应用。
如需了解如何在 Amazon Bedrock 上构建类似的代理系统,请参阅《Amazon Bedrock 用户指南》和《Amazon Bedrock 提示缓存文档》。要开始使用,请访问 Amazon Bedrock 控制台。
作者简介
'\"