▶ 原文链接

JP 摩根如何利用 LangGraph 为投资研究构建 AI 代理 | LangChain Interrupt

来源： YouTube | David & Jane (JP Morgan Private Bank) | 2025-05-29 播客： LangChain 分类： AI 工程 原文发表： May 29, 2025 纪要生成： 2026-08-06

---

嘉宾/话题简介

本次演讲来自 JP 摩根私人银行 投资研究团队的 David 和 Jane。他们所在的团队负责为高净值客户筛选和管理数千种复杂的投资产品。面对海量的结构化数据、爆炸式增长的非结构化文档，以及高度依赖人工专家的专有分析模型，他们自主开发了内部 AI 智能系统 "Ask David"。本集深入探讨了他们如何基于 LangGraph 从零开始构建这一多代理系统，以在严苛的金融合规与极高准确性要求下，实现投资研究的自动化与规模化。

---

分节详述

00:09 从人工排查到 AI 驱动：投资研究的自动化愿景

本节重点

• 当前投资研究极度依赖人工，难以规模化以应对数千种产品的咨询需求
• "Ask David" 的目标是提供即时的、策展过的答案与可视化分析
• 核心目标不是替代人类，而是将人类专家从重复劳动中解放以提升效率

详细精要

• 传统投资研究的痛点在于纯粹的手动模式导致的无法规模化
• 团队管理的不是几十个产品，而是 数千种 金融产品，每个产品背后有跨越 多年 的宝贵数据与材料数据库
• 现有工作流是完全手动的：分析师需要手工翻阅各种材料、文件和数据库，像拼图一样去拼凑出一个问题的答案，这是一个极其 耗时 且限制洞察输出的过程

• 这种模式阻碍了团队为平台上的所有产品生成深度洞察的能力，使高质量服务受限于人力瓶颈

• "Ask David" 旨在成为数据、分析、可视化与洞察的一站式决策助理

• 愿景是实现实时决策支持：例如在客户会议中，金融顾问可以现场查询某基金为何被终止，系统瞬时给出包含历史状态、现状分析、相似基金对比的策展答案
• 通过 AI 代理，将过去需要联系真人 David 并手动制作演示文稿的 "白手套服务"，转化为可规模化触达更多客户的自助式洞察
• David 明确表示，工具不会让自己失业，而是让工作变得 "更轻松、更高效"，因为其管理着涉及 数十亿美元 资产的风险敞口，准确性是底线

💬 精华片段（中文）

"Today, when you have a question, you come to me. You come to David and Dave will give you an answer. But tomorrow, you'll be able to go ask David, our AI powered solution designed to transform the way we answer investment questions." （"今天，如果你有问题，你来找我，找 David，我会给你答案。但明天，你就可以去问 David —— 我们专为转变投资问答方式而设计的 AI 驱动解决方案。"）

02:12 "Ask David" 的数据基础与术语解析

本节重点

• 系统整合了结构化数据库、非结构化文档以及专有分析模型三类数据源
• "Ask David" 是 "数据、分析、可视化、洞察与决策辅助" 的缩写
• 多代理系统由监督器、结构化数据代理、非结构化 RAG 代理和分析代理构成

详细精要

• 结构化数据是已有生产系统的骨干
• 团队拥有 数十年的结构化数据 积累，这些数据支撑着现有的关键业务系统
• 在引入代理前，用户也可以访问这些数据，但必须跨多个不同系统手动导航和 "手动整合" 信息

• 代理的核心作用在于引入 效率 和 一体化的用户体验，将分散的查询结果聚合

• 非结构化数据的管理挑战与机遇

• 银行内部管理着海量的非结构化文档，包括：电子邮件、会议纪要、路演 PPT 等
• 随着远程会议的兴起，数据还包含了越来越多的 视频和音频记录

• 大模型技术的进步为充分利用这些非结构化信息带来了巨大的机会，能够从以往必须由人工阅读的杂乱文件中提取有效信息

• 专有模型与分析工具的封装与调用

• 研究团队拥有自研的 专有模型和分析方法，能够生成深度洞察和可视化图表，驱动决策
• 过去这类分析完全由 人类专家 手工操作，提供极其定制化的分析服务

• 代理系统的任务是能够自动调用这些分析 API，实现洞察生成的 规模化

• "Ask David" 的正式含义

• 全称为：Data（数据）、Analytics（分析）、Visualization（可视化）、Insights（洞察）、Decision-making Assistant（决策辅助），这完美诠释了系统的功能范畴

💬 精华片段（中文）

"With the help of agent, we can scale the insight generation and we can make our service available to more of our clients." （"在代理的帮助下，我们可以规模化地生成洞察，并将我们的服务提供给更多的客户。"）

04:50 多代理系统架构详解：监督器与专业化分工

本节重点

• 系统采用监督器加多子代理的架构，监督器负责任务路由与协调
• 短时记忆与长时记忆用于定制化用户体验
• 区分了针对通用问题与针对特定基金问题的两种独立工作流子图

详细精要

• 监督器代理充当系统的协调大脑
• 监督器作为中心节点与终端用户交互，旨在准确理解用户的 真实意图
• 基于意图识别，监督器将具体任务 委派 给团队中的一个或多个专业子代理
• 系统具备记忆机制：能够访问 短期 与 长期记忆，以便根据用户历史和语境定制个性化的使用体验

• 监督器具备关键的安全意识：它掌握 何时触发 Human-in-the-loop，确保在高风险环节引入人类监督以保障最高的准确率和可靠性

• 结构化数据代理的设计模式

• 核心工作是将自然语言问题精准地翻译为 SQL 查询 或 API 调用

• 在获得结构化的返回数据后，再利用 大语言模型 对数据进行最后的归总与润色，生成易于阅读的自然语言回答

• 非结构化数据代理的设计差异

• 与结构化数据不同，处理非结构化数据通常需要额外的 预处理 步骤，然后将其存入向量数据库

• 系统采用基于 RAG 的代理 来检索最相关的文档片段，并从中提炼答案

• 分析代理的复合决策机制

• 对于简单的请求，系统使用 ReAct Agent 直接调用内部 API 作为工具来获取结果

• 对于复杂的分析需求，代理会采用 文本转代码生成 的技术，且在最终执行代码前会引入 人类监督 层，确保金融模型计算的绝对安全

• 端到端工作流的双通道子图设计

• 流程始于一个 规划节点，根据意图进行分流
• 通用 QA 流：处理诸如 "如何投资黄金" 这类非特定产品的通用性问题
• 特定基金流：如果问题关联到具体的特定基金（如某某基金为何被终止），则流向右侧的专业处理流程
• 两种流程虽然路径分离，但都配备了一个独立的 监督器 与一组专用代理，并在检索答案后经过统一的 个性化节点 与 反省节点

💬 精华片段（中文）

"The supervisor agent have access to both short-term and long-term memories so that it can customize the user experience. It also knows when to invoke human in the loop to ensure the highest level of accuracy and also reliability." （"监督器代理能够访问短期和长期记忆，从而定制用户体验。它也知道何时调用人机协同机制，以确保最高水平的准确性和可靠性。"）

07:25 实战案例拆解："某基金为何被终止"的幕后技术流

本节重点

• 规划节点将提问路由至特定基金流，由内部监督器精准调度文档检索代理
• 答案会依据用户角色在 "个性化节点" 进行差异化输出
• "反省节点" 利用 LLM 做裁判进行逻辑自纠，若不通则重试

详细精要

• 规划与路由机制详细拆解
• 针对 "为何这只基金被终止" 的提问，系统在 规划节点 精准解析出该询问与 某一特定基金强相关

• 随后，系统将请求送入 特定基金工作流，该工作流内部的监督器会提取出具体的基金信息作为上下文，并意识到需要调用 文档检索代理 去挖掘相关资料

• 数据检索与工具调用

• 文档检索代理接受任务后，立刻触发底层的数据库工具，从 MongoDB 中提取关于该基金的历史绩效、运作状态以及终止相关的文件

• 快速抓取到背后的结构化与非结构化背景信息

• 关键节点：基于用户角色的答案个性化

• 系统检测到发起提问的用户身份具有差异性，并在 个性化节点 对同一份底层数据做差异化包装
• 例如面对基金终止原因，尽职调查专员 需要获取深度、详尽的技术性解释；而 投资顾问 则仅需一个高度概括、适用于转述给客户的总结

• 该节点能够根据用户画像和角色权限智能 定制回答的颗粒度与语言风格

• 质量保障：基于 LLM 审判的反省节点

• 经过个性化的答案会进入 反省节点，系统采用 LLM 作为裁判 来审视生成答案的逻辑一致性
• 如果 LLM 判定当前的回答存在歧义、幻觉或逻辑不通顺，系统会自动触发 "重试" 机制，直到生出一个经过检核的合格答案

• 这一环是为了在不添加人工负担的情况下，最大限度地擦除低级错误

• 最终处理与记忆更新

• 整个执行链路的终点是 摘要总结节点，系统在此处执行三项任务：对会话交流进行压缩摘要、更新用户的长期记忆（以便未来更好地预测意图）、以及格式化并返回最终答案给终端用户

💬 精华片段（中文）

"A due diligence specialist may demand a very detailed answer while a advisor maybe just need a general answer. So this personalization node will tailor the answer based on the user roles." （"尽职调查专家可能需要非常详细的答案，而顾问可能只需要一个通用答案。因此，这个个性化节点会根据用户角色来定制答案。"）

09:09 工程心得一：从简洁起步，高频重构

本节重点

• 系统原型第一天仅是纯 React Agent，而非错综复杂的多代理图
• 共经历四次关键架构迭代才演进出带意图子图的当前架构
• 每个迭代阶段都旨在隔离问题并验证特定代理的独立性能

详细精要

• 演进路径四部曲
• 第一阶段：搭建一个最基础的普通 ReAct Agent，仅用于验证大模型理解金融语言和调用工具的可行性，深刻理解 ReAct 的运作机制
• 第二阶段：从基础代理中剥离出专门的 RAG 代理，重点攻关非结构化数据的检索与阅读理解能力，并开始探索定制化流程
• 第三阶段：当确认单个专业化代理性能达标且稳定后，引入 监督器架构 将所有代理整合成一个 多代理协作工作流，实现初步的智能调度

• 第四阶段：当前架构，依据实际业务需求生成了 针对不同意图的独立子图 —— 普通问题子图与特定基金子图。这种架构使得后续扩展新的业务意图变得极其容易

• 重构式开发的深层原因

• 架构的复杂性不是第一天就被预先设计出来的，"从简单开始，频繁重构" 是核心原则
• 团队只有在完全验证了某个单点的稳定性后，才敢于进行系统级集成，这最大程度避免了在多代理系统中出现无法定位的交叉干扰问题

💬 精华片段（中文）

"Start simple and refactor often. I know I show you a fairly complex diagram earlier but we didn't really focus on building that diagram from day one." （"从简单开始，并经常重构。我知道我之前展示了一张相当复杂的架构图，但我们从第一天起并没有专注于去构建那张图。"）

10:05 工程心得二：评估驱动开发与多维指标矩阵

本节重点

• 采用 "评估驱动开发" 以确保每一次架构迭代都走向正确方向
• 提出 "无真值" 也能启动评估的观点，并强调子代理的独立评估
• 在金融行业，除了准确度，还需引入简明度、轨迹评估等特定指标

详细精要

• 区别于传统开发的长评估周期
• 团队发现相比传统 AI，GenAI 项目的开发阶段更短，但 评估阶段会非常长，需要尽早规划
• 核心建议是 "尽早想清楚目标指标"，弄清楚你到底要衡量什么——鉴于身处金融领域，准确率 是毋庸置疑的头号指标

• 持续的评估能为你提供 日拱一卒的信心，通过数据曲线证明每次调整是在向正确的方向前进

• 多维度的评估策略与指标选取

• 独立评估子代理：演讲中的图表显示，深色条代表主流程评测，绿色条代表子代理评测，必须以分而治之的方式找出 "最薄弱的一环"，再针对该弱环进行定向优化
• 挑选合适的指标：不能只有一个准确率。如果评估的是摘要总结节点，就需要引入 简明度 指标；如果是评估工具调用，则需要检测 执行轨迹
• 打破 TDD 的迷思：开发者常认为没有标准答案就无法做评测，但 GenAI 项目可以在 有真值或无真值 的情况下评测，除了准确率外还有很多无真值指标能提供洞察

• 真值的积累飞轮：一旦启动评测，就会产生数据审阅需求，在不断的审阅过程中，会自动 积攒出更多的高质量真值数据集

• LLM 裁判与人类审阅的混合方案

• 系统采用 大语言模型作为裁判，进行大批量自动化打分
• 同时结合 人工审核 作为校准机制，这种自动化流水线使得团队能在不给 人类主题专家 带来巨量审查负担的前提下，实现评估的规模化

💬 精华片段（中文）

"You can start evaluation with or without ground truth it doesn't matter there are so many metrics beyond just accuracy and each one of them will provide you some insight." （"无论有没有真值，你都可以开始评估。除了准确度之外还有很多指标，每一个都会为你提供一些洞察。"）

12:40 工程心得三：人机协同攻破 "最后一公里"

本节重点

• 准确率的提升路径是非线性的：从基础低于 50% 到找补至 80%，再到专项微调至 90%
• 从 90% 向 100% 冲击的 "最后一公里" 最艰难，必须引入人机协同
• 数十亿美金的资产风险注定了在某些时刻 AI 必须咨询真人 David

详细精要

• 准确率提升的三级跳策略
• 第一跳（至 80%）：单纯将通用大模型放到特定金融领域，准确率往往 低于 50%。通过快速的工程改良（如优化文档的 分块策略、改进搜索算法、完善指令工程），可以迅速将该指标拉升到 80% 大关
• 第二跳（至 90%）：利用 工作流链 和 子图架构，对不同类型的问题进行域内微调和流程编排。这种隔离微调的方式能防止解决某一类问题时的改动意外破坏另一类问题的准确率，将指标推升至 90%

• 最后冲刺（90%-100%）：这就是 GenAI 应用的 "最后一公里"，也是"最艰难的里程"。由于生成式 AI 的固有随机性，100% 可能难以企及

• 极限条件下的 "守门人" 策略

• 在 90%-100% 的攻坚阶段，必须引入 "Human-in-the-loop"。因为系统管理者数十亿美金的资产，无法容忍任何细微的不准确
• 这也引出了 "Ask David" 的一项关键设计原则："Ask David still consults with real David whenever needed." —— 在高度不确定的情况下，系统会自动升级并询问真人专家。任何时候，只要模型信心不足，都会触发人工干预流程

💬 精华片段（中文）

"Between 90% and 100%, that's what we call the last mile and the last mile is always hardest mile. In terms of GenAI applications, it may not be achievable to get that 100% mark, so what do we do? Human is in the loop." （"在 90% 和 100% 之间，就是我们所说的'最后一公里'，而这最后一公里总是最难的一段。在生成式 AI 应用中，可能无法达到 100%，那我们该怎么办？让人参与进来。"）

---

专业术语注释

术语	解释
LangGraph	由 LangChain 推出的用于构建有状态、多参与者应用程序的框架，本案例中用于编排包含监督器与子代理的状态图。
多代理系统	由多个具备不同专业能力的 AI 代理组成的系统，通过一个中央监督器代理进行调度，以协作完成复杂任务。
监督器代理	该架构中的中央协调节点，负责理解用户意图、访问记忆系统并将任务分发给特定的子代理。
领域特定 QA 代理	针对特定行业（如金融）或特定数据集进行深度定制，能精准回答专业问题的问答代理。
ReAct Agent	一种结合推理与行动的 AI 代理设计模式，能够根据外部工具的反馈循环执行任务，是 "Ask David" 的早期原型形态。
RAG 代理	基于检索增强生成技术的代理，在处理提问时先从向量数据库中检索最相关的非结构化文本片段，再交给大模型归纳总结。
人机协同	在本语境下指 AI 系统在信心不足或面对高风险操作（如代码执行）时，自动暂停并将任务升级给人类专家审核的机制。
子图架构	将不同意图（如通用问题 vs 特定基金问题）封装在相互独立的有向无环图中的设计，便于独立维护与横向扩展。
LLM as Judge	利用另外的大语言模型作为评估器，通过特定的提示词对 AI 生成的回答进行打分和逻辑检查的自动化评估方法。
最后一公里	指在 GenAI 应用中，准确率从 90% 提升到近乎完美的 100% 的极其艰难的最终优化阶段。
未格式化文本至代码生成	指将用户的自然语言指令自动转化为可执行的编程代码（如 Python/SQL），以调用复杂的分析模型。
个性化和反省节点	前者根据用户角色调整答案的专业度与长度；后者在生成答案后进行自我批判，如不合逻辑则触发重试。

---

延伸思考

值得进一步关注的问题、争议点或行动建议：

1. 双通道子图的取舍：虽然 "特定基金" 与 "通用问题" 两个子图易于扩展，但当出现介于两者之间或交叉的复杂问题时，监督器是否可能出现路由模糊？是否需要引入意图置信度阈值机制？
2. LLM 裁判的公正性局限：使用 LLM 审查 LLM 生成的内容，可能会产生 "回声室效应" 或对特定错误的系统性放水。在金融高压环境下，是否有必要在反省节点引入基于规则的传统裁判？
3. 人类反馈的闭环利用：文中详细描述了人机协同的触发，但未说明被拦截的错误数据如何反哺回模型进行强化学习或微调。 RLHF 或类似的反馈循环对这个系统的自我进化至关重要。
4. 评估指标间的博弈：一旦同时引入 "准确率" 和 "简单度" 作为评估标准，在向模型下达优化指令时可能会出现 "为了简明而牺牲信息完整性" 的冲突。如何设计复合评分权重以平衡监管需求与用户体验？

原文发表：May 29, 2025  ·  纪要生成：2026-08-06