Stripe 每年处理约 1.4 万亿美元的支付量，业务覆盖 50 个国家，其合规团队每天需要审查数千笔交易。面对如此规模，Stripe 利用 Amazon Bedrock 在 AWS 上构建了一个生产级的 AI 代理系统，旨在提升金融合规审查的效率和一致性。
该系统的核心目标是在不按比例增加人力的前提下扩展合规运营，同时维持监管机构要求的高质量标准。此前，熟练的分析师可能将高达 80% 的时间花费在碎片化的系统中收集文档，而非进行高价值的风险评估。Stripe 的解决方案将 AI 代理与自动化编排相结合，把合规从资源密集型流程转变为可扩展的引擎。据披露，该系统将审查处理时间减少了 26%，有用性评分超过 96%，并且最终决策权始终掌握在人类专家手中。
为何选择代理式 AI？
传统的自动化难以应对复杂的、基于判断的合规工作。AI 代理能够以可扩展的方式协助调查，保持质量一致且完全可审计，同时确保人类控制。Stripe 的系统建立在三大支柱之上：
- 监督与问责：以人为中心的验证，可配置的审批工作流和多层决策检查点。人类始终处于主导地位，代理提供支持。
- 透明度：完整的审计跟踪，对每个操作、决策和理由进行不可更改的记录。
- 效率：通过预调查和动态分析，以更快的速度进行更深入的审查。
技术架构
该系统的技术实现包含三个关键组件：任务分解与编排、ReAct 代理框架以及支持性基础设施服务。
任务分解与审查编排
让单个代理一次性处理漫长而复杂的审查并不可行，因为无约束的代理可能关注错误的方向。Stripe 将复杂的审查分解为可组合的小型子任务，每个子任务可能依赖其他子任务的结果，形成一个有向无环图（DAG）。这种设计确保代理仅在经过质量测试的、经过审查的问题上运行，帮助调查覆盖所有必需的基础，并为代理提供足够的上下文和焦点以产出高质量结果。
尽管每个子任务的代理响应都经过了严格的质量测试，Stripe 并不直接依赖代理的答案。相反，这些响应作为补充信息提供给人类审查员，由审查员最终回答每个子任务。这既解决了监督和问责问题，又保留了效率收益。审查员与审查工具交互，该工具了解当前问题以及哪些后续问题需要该答案作为上下文，充当编排器，将人工审查的答案作为后续问题的上下文传递。
ReAct 代理框架实现
为了为每个子问题获取研究资料，Stripe 构建了一个基于 ReAct（推理与行动）框架的合规代理。除了使用 Amazon Bedrock 上的大语言模型进行推理外，代理方面通过工具调用动态收集相关信号。Stripe 选择这种框架是为了解决信号数量近乎无限且可能与特定主题相关或不相关的问题。代理决定哪些信号是相关的，并提出后续问题，直到有足够信心给出最终答案。
在 ReAct 循环中，当思考块中请求工具时，代理框架会停止 LLM 执行，转而以编程方式运行该工具。然后，它将工具输出作为观察结果强制反馈给代理，之后才允许代理继续。这种注入模式实现了闭环控制机制：
- 将代理推理扎根于实际数据：通过强制每个工具输出都必须作为观察结果处理，防止代理产生幻觉或捏造工具结果。
- 保持上下文连贯性：迫使代理在继续之前明确承认并推理每条检索到的信息。
- 防止推理漂移：观察步骤充当检查点，帮助确保代理的思维过程锚定在事实性的工具输出上，而非推测性推理。
- 支持可审计性：创建工具调用→观察→推理的明确跟踪记录，可记录以供合规审查。
这种方法类似于工程中的反馈控制系统：代理在处理完前一个行动的反馈（观察）之前，不能继续执行下一个行动，从而防止可能导致幻觉或偏离轨道的开环行为。
一个挑战是，当任务非常复杂、需要多轮和观察时，后续轮次的提示可能会非常长，尤其是观察结果冗长时。子任务分解限制了每个问题的范围，以保持轮次较少。提示缓存也有助于降低输入令牌的成本，这是此处的主要成本驱动因素。使用提示缓存，您只需为每轮追加到先前消息的新观察和思考付费。Amazon Bedrock 提供了这一能力。
完整的代理审查架构与基础设施
Stripe 依赖大量基础设施来支持实际的代理执行。完整架构包括审查界面和编排器，以及一个托管代理逻辑并促进执行的代理服务。代理服务由 Stripe 的 LLM 代理服务支持，并通过可用的代理工具连接到内部信号。
构建专用代理服务
在此项目之前，Stripe 的代理服务并不存在，该项目促使 Stripe 提出了这一需求。最初，Stripe 尝试将代理纳入传统的 ML 推理引擎，但很快因以下原因被否决：
- 计算配置：传统 ML 是计算密集型的，需要昂贵的硬件，如 GPU、快速多线程 CPU 或大内存分配。相比之下，代理应用主要是网络绑定的，等待基础模型完成或工具调用运行。
- 延迟：参考 ReAct 流程，代理可能需要不确定的时间来完成，取决于需要多少轮工具调用。一个长的代理查询或数据库工具调用可能导致线程空闲数分钟，而 XGBoost 模型只需毫秒即可完成。
- 不同的 API：传统 ML 倾向于输出基本类型（浮点数、布尔值等），而代理需要更灵活的模式来注释其结果。一些代理需要维护有状态的对话状态。
因此，Stripe 建立了自己的代理服务，最初类似于无状态的同步推理端点。如今，它还处理有状态的多轮对话代理。在不到一年的时间里，它从推出时的几个代理发展到超过 100 个代理。
LLM 代理架构
Stripe 的 ReAct 代理不直接调用 Amazon Bedrock。相反，Stripe 使用 LLM 代理微服务作为其 LLM 访问的标准方法。Stripe 使用 LLM 代理服务的原因如下：
- 噪声邻居：Stripe 有许多团队将 LLM 用于各种应用。LLM 代理提供了保护措施，防止其他团队占用特定模型的 LLM 带宽，防止资源争用。
- 一个 API，多个模型：单一端点简化了跨 Amazon 和领先 AI 公司的基础模型指定提示缓存或工具调用等能力。更改模型只需更改模型类型作为参数，而不是每个用例管理许多不同的客户端。
- 模型回退：在资源受限或完全失败的情况下，能够自动指定默认模型。
- 监控：通过要求身份验证，服务可以跟踪模型使用情况，帮助预测未来资源需求，并根据应用的隐私性确认使用了适当的模型。
架构组件如何协同工作
人类审查员驱动审查，使用代理响应作为预取的研究资料。当他们回答时，这些响应可用于同一审查中更深层次问题的提示，将审查问题编排为有向无环图。整个过程确保了合规操作的可扩展性，同时不牺牲质量或可审计性。