金融文档智能多智能体框架
金融服务行业建立在文档之上：贷款档案、KYC 资料包、授权文件以及合规证明文件等。智能体 AI 改变了人工分类和处理这些文档的成本结构，但前提是底层数据层能够支持多智能体在大规模场景下完成数据摄取、信息提取和数据核对。
文档智能参考架构采用基于统一 MongoDB 数据层构建的监督式多智能体系统：
- 扫描智能体：识别并解析相关的企业输入文档。
- 评估智能体：根据业务场景需求，对资产的上下文相关性进行评估和评分。
- 提取智能体：提取目标内容，并为后续自动分块处理做好准备。
- 处理器代理：使用 voyage-context-3 生成嵌入向量，以同时捕捉文档的局部和全局上下文，从而提高检索准确率。
- 文档助手智能体：负责下游智能体 RAG 流程，并根据用户查询判断何时以及如何检索相关上下文信息。
智能体记忆往往是整个系统中默默承担大部分工作的部分。每个智能体都会记住以往的交互记录，并随着持续接收反馈和修正而不断学习。这些记忆必须存储在持久可靠的环境中，并配备严格的访问控制机制和审计追踪能力，以满足金融服务行业治理要求。
释放智能体力量，实现全球支付系统现代化
支付系统是金融技术架构中最难实现现代化改造的环节之一，同时也是出错代价最高的环节之一。负责资金流转的各类支付网络诞生于不同的发展阶段：SWIFT 使用 ISO 20022 XML，ACH 使用固定宽度文件格式，银行卡网络使用 ISO 8583，而加密货币网络则使用 JSON。大多数银行通过点对点集成的方式将这些系统连接起来，并依靠人工处理异常情况来弥补其中的衔接缺口。仅支付失败一项，每年就会给全球经济造成超过 1,000 亿美元的损失。其结果是产品上市周期缓慢、总体拥有成本居高不下，以及持续存在的合规风险。
解决方案并不是替换这些支付网络，而是将它们产生的所有数据统一映射到一个标准化的支付模型中。该模型包括：业务数据（如支付指令和交易参与方信息）、运营与 AI 数据（如处理任务和向量嵌入）和配置数据（如路由策略和数据转换规则）。在这一统一模型之上，结合 AI/ML、业务规则以及内置审计追踪能力的自动化引擎，便能够真正发挥价值，执行包括路由决策、对账处理、欺诈分级处置、异常问题解决以及客户沟通等关键业务流程。
其结果是更快的产品上市周期、更低的总拥有成本 (TCO)，以及将合规要求沉淀为数据层固有属性，而不是每个季度都需要集中处理的一次合规“救火”。真正被改变的，是银行的交付能力。
面向供应链中断管理的多智能体系统
供应链中断是典型的多智能体问题。一个港口的天气事件、另一个港口的劳资纠纷、二级供应商的质量问题，以及关键市场中的需求激增，都会相互影响并产生连锁反应。没有任何一个人工团队能够实时掌握全局情况，同样也没有任何单一智能体能够做到这一点。而判断失误所带来的代价是实实在在的：据估计，供应链中断每年给企业造成的损失高达 1,840 亿美元。
在实际应用中，这项工作通常会拆分为多个专业角色：中断分析负责在事件发生过程中持续监测和识别异常情况；供应链规划负责建模分析下游影响并提出缓解方案；风险分析则负责评估风险敞口，并识别需要升级处理的问题。LangGraph（用于多智能体工作流编排的框架）负责在这些角色之间进行协调与调度，而各智能体对业务环境的共享认知则建立在底层数据层之上：一个统一的数据存储平台，将货运信息、天气数据、承运商信息、运输枢纽以及经过向量化处理的历史事件报告集中存储在一起。
MongoDB Atlas 所带来的价值远不止存储能力。天气事件可以作为时间序列数据持续流入系统；货运和仓储数据包含地理坐标，可通过地理空间查询进行分析和推理；历史事件报告则可借助 Voyage AI 生成向量嵌入，通过向量搜索快速检索智能体所需的过往事件和处置经验。此外，LangGraph 在智能体执行步骤之间写入的记忆检查点同样存储在这一平台中。这使得事后复盘过程中产生的记录能够以结构化数据的形式持续积累，而不是零散地散落在 Slack 对话线程之中。
由 MongoDB 和智能体 AI 驱动的现代端到端数字借贷之旅
贷款堪称金融行业中最典型的端到端自动化场景。过去二十年来，人们一直期待实现贷款流程的全面自动化，但现实情况往往只是分散在多个系统和业务孤岛中的局部自动化。原因并不陌生：数据分散在十多个系统之中；合规流程在多个环节都需要人工判断；而客户体验往往取决于流程中衔接最差的那个系统。
智能体 AI 改变了瓶颈所在。现代化贷款流程可以被设计为一组协同运作的智能体，覆盖从贷款发起到续贷的完整生命周期。贷款申请智能体充当智能化入口，引导借款人完成申请流程，实时验证并丰富数据，从文档中提取关键信息，生成可直接用于审批决策的贷款档案。承保智能体结合业务规则、机器学习模型和替代数据来源，持续评估借款人的信用状况，并将例外情况及高风险案件转交给人工审核人员进行最终审批。续贷智能体则负责监测放款后的整个生命周期，预测再融资需求、财务困难及客户流失风险，并主动触发个性化优惠方案或提前干预措施。每个智能体都有明确的职责边界，每个智能体都可被监控和追踪，并共享同一个以业务对象形式呈现的申请视图。客户获得的是连贯一致的体验，而贷款机构获得的则是完整可追溯的审计记录。
架构之所以重要，是因为贷款业务本质上属于高度依赖判断和决策的工作。数据层决定了哪些环节适合自动化处理、哪些环节必须由人工审核介入，并最终决定贷款流程是能够在几分钟内完成，还是需要数周时间。这一模式不仅适用于贷款业务，也适用于任何以文档为核心、同时需要在效率与监管要求之间取得平衡的金融业务流程。
可移植性测试：防止单一云服务中断
行动系统开始承载真实业务负载时，可移植性就不再是事后考虑的问题，而是核心要求。企业级智能体系统很少会长期局限于单一环境之中，它们通常横跨多个云平台、不同地理区域以及多种计算模型。如果运营数据存储、向量搜索能力和智能体记忆必须分别迁移，那么整个技术栈很快又会重新走向碎片化。
超大规模云服务提供商的容量限制以及数据驻留监管要求，往往会促使企业采用多云架构。例如，一家前沿模型企业如果在某个云平台上面临 GPU 资源不足的问题，可能会将部分工作负载迁移至 Google Cloud，以利用其 TPU 资源。出于实际基础设施限制的需要，其数据层也因此被分布在两个云平台之间。
单个 MongoDB Atlas 集群可以同时跨 AWS、Google Cloud 和 Microsoft Azure 运行。对于需要气隙环境或数据主权部署的场景，同样的数据库引擎也可通过 MongoDB Enterprise Advanced 在本地环境中运行。这能够帮助企业避免代价最高的一类云架构错误：构建出只能在单一云服务提供商上正常运行的架构，而当企业需要增加、替换或同时使用其他云平台时，整个架构却无法适应。这一优势在 2025 年发生的三次重大故障后体现得尤为明显：6 月的 Google Cloud 故障、10 月 20 日的 AWS US-EAST-1 故障，以及在此 9 天后的 Azure Front Door 故障。这些事件都影响了依赖单一云服务提供商的客户；而对于数据层跨多个云平台部署的客户而言，则能够更从容地应对并维持业务连续性。
智能体商业的授权账本
智能体商业代表着数字化运营领域的下一个重要转折点。在这一模式下，客户会将购买决策直接委托给自主购物智能体来完成。三项新兴技术协议正在塑造这一交互模式：智能体间通信协议 (A2A)、智能体支付协议 (AP2) 和通用商业协议 (UCP)。
每种协议都需要一个防篡改的授权记录账本，用于记录客户授权、智能体行为以及商户响应。AP2 明确定义了三种授权模式：意图授权（定义允许执行的操作）、购物车授权（定义正在购买的商品或服务）和支付授权（定义资金划转相关参数）。底层数据存储库必须在应用层实现仅追加机制，以确保记录不可被修改；同时还需要支持基于结构化数据和语义数据的查询能力，并具备足够的灵活性，以便随着协议的发展吸收新的文档字段和数据结构。
什么会比智能体更长久？
在本期讨论开始时，两支团队在同一天启动了同一个 AI 项目。到了季度末，其中一支团队已经完成上线；而另一支团队拥有一个令人印象深刻的演示，却仍然看不到走向生产环境的路径。如今，这样的场景已屡见不鲜：智能体能够正常运行，演示文稿足够吸引人，模型也能在足够长的时间内表现良好，让所有人相信它已经准备就绪。但随后，真正的问题开始出现：数据归谁负责？结果是否能够被审计？当客户正在等待、监管机构正在关注，而系统又必须立即采取行动时，会发生什么？
纵观本期内容，答案始终如一。McKesson 并不是依靠一个巧妙的提示词来保障患者安全，LG U+ 也不是通过将智能能力与运营体系割裂开来提升实时客户服务水平。本期所介绍的金融机构、制造企业、零售商以及建筑企业，同样没有等待所谓“完美模型”的出现。他们正在做的是一件更低调、却也更持久的事情：构建能够让智能真正达到可用、可信和可靠水平的基础层。
重要的不是智能体本身所展现出的能力，而是支撑它的基础，是能够持续保留的记忆，是伴随每一次行动而生效的权限控制，是能够及时抵达的运营真相，是能够在事后证明一切发生过程的审计追踪记录。
模型会被替换，框架会被重新命名，协议也会不断成熟。
最终胜出的架构，将是那些能够吸收所有这些变化，而无需让业务重新开始的架构。
智能体时代并不会仅仅依靠智能体驱动，而将由使智能体变得值得信任的数据层提供支撑。
