hi，我是南哥。最近花了两周时间，从零搭了一个 AI 金融研究 Agent。
最终效果是这样的——我问它"对比微软 2024 年 Q2 的财报数据和当前的股价表现"，它先自己列了一个 3 步执行计划，然后从公司年报 PDF 里翻出微软的收入数据，又自动跑到 Yahoo Finance 拉了最新股价和分析师评级，最后整合成了一份完整的分析报告。
全自动，跑了大概 10 分钟。报告里有各业务线收入明细、同比增长、当前市盈率、分析师目标价，我去 Yahoo Finance 上核了一遍，数据完全对得上。
从第一天连 PDF 都读不了，到最后能做出这种综合分析，中间踩了不少坑。这篇把整个系统的架构和关键设计思路梳理一下，算一个完整的技术复盘。
它能干什么
三个核心能力。
第一，读年报。把苹果、亚马逊这类公司的 10-K 年报 PDF 喂进去，它能从里面检索出任何你想要的财务数据——收入表、资产负债表、各业务线的数字，连图表里的趋势信息也能理解。
你问它"苹果 2024 年 Services 收入是多少"，它不是从网上随便搜的，是真的从 PDF 原文里检索出来的。
第二，查实时行情。通过 MCP 协议连接 Yahoo Finance，拿到的是当天的股价、市值、涨跌幅、分析师评级。不是 ChatGPT 那种"我的数据截止到 xxxx 年"，是真的实时。
第三，综合分析。面对复杂问题，它会自己拆任务、制定执行计划、分步调用不同数据源，最后汇总输出。不是那种"想到什么工具调什么工具"的随机模式，是有计划地工作。
整体架构长什么样
从底到顶，一共 8 个模块：
实时数据层: MCP + Yahoo Finance（实时行情）数据处理层: Docling PDF 提取 → Gemini 图片描述存储层: Qdrant 向量数据库（混合搜索）检索层: Dense + Sparse 混合搜索 + Cross Encoder 重排序Agent 层: 多模态 Agent（RAG + MCP 双数据源）规划层: TODO Planner + Summarization 中间件
每一层解决一个具体的问题。下面一个个说说我为什么这么选型，以及踩过哪些坑。
MCP + Yahoo Finance：让 Agent 有了"实时眼睛"
先说实时数据这一块。
以前用 ChatGPT 问股票信息，它要么说数据过期了，要么直接编个看似合理但完全错误的数字。根本原因是 LLM 本身不联网，训练数据有截止日期。
MCP（Model Context Protocol）解决了这个问题。它是一个让 AI Agent 调用外部工具的标准协议，Yahoo Finance 已经有现成的 MCP Server 发布在 PyPI 上了，LangChain 也有 MCP 适配器，连接起来不复杂。
连上之后，Agent 手里直接多了 9 个工具——查股价、查财务指标、查新闻、查分析师评级，全是 Yahoo Finance 的实时数据。
不过有个坑：MCP 是异步的，在 Jupyter Notebook 里跑不起来。我折腾了半天 nest_asyncio 之类的方案，最后发现用 subprocess 开一个新进程来执行最简单粗暴。这个方案看着不优雅，但真的好使。
年报 PDF 处理：比你想的难得多
实时数据搞定了，但金融 Agent 不能只看实时行情。公司年报里才有最详细的财务数据——收入结构、成本明细、风险披露，这些东西 Yahoo Finance 上没有。
问题是年报 PDF 处理起来特别麻烦。
一份苹果的 10-K 年报，少说七八十页，里面有大段文字、有表格（资产负债表、利润表）、有各种图表（收入趋势图、市场份额饼图）。这三种数据格式完全不同，不能一刀切。
我前后试了 5 种多模态 RAG 方案：分 Collection 存储、统一多模态 Embedding、图片转文字、多模态 LLM 直接检索、CLIP 图文对齐... 最后选了"图片转文字"这条路。
核心思路是把所有数据都统一成文本：PDF 正文转 Markdown，表格提取成 Markdown 表格，图表用 Gemini 生成详细的文字描述。最后全部用文本 Embedding 存进向量数据库。
为什么不用多模态 Embedding？两个原因。一是精度不够，多模态 embedding 比专门的文本 embedding 差一截。二是不支持混合搜索和 BM25 关键词匹配——金融场景下你搜 "revenue growth"，必须精确匹配到这个关键词，不能给我模糊匹配到别的东西。
PDF 提取用的 Docling
具体提取 PDF 数据，我用的是 IBM 开源的 Docling。
一开始试的是 PyPDF2，提取出来的表格简直没法看，格式全乱了。换 Docling 之后效果好太多——表格结构能完整保留，Markdown 导出质量很高，图片提取也支持。
不过图片提取有个细节要注意：PDF 里有大量的 logo、图标之类的小图，对 RAG 完全没用。我设了 500x500 最小尺寸过滤，一开始没加这个，提取出来好几百张图，打开一看全是装饰性图标... 加了过滤后每份年报就十几张有价值的图表，合理多了。
表格提取也有讲究。我不是直接存表格内容，而是把表格上方的标题也带上。比如"Table 1: Consolidated Statements of Income"这种上下文信息，对后面检索非常关键。
图表转文字：Prompt 写得好不好差距巨大
提取出来的图表是图片格式，没法直接存向量数据库做检索。所以要用 Gemini 把每张图"翻译"成文字描述。
这一步的关键完全在 Prompt 上。
一开始我用了个很随意的 prompt："描述这张图片"。Gemini 回了一句"这是一张柱状图，显示了一些数据"。等于没说。
后来我改成了一个结构化的 prompt，要求它必须输出：图表类型、标题、所有具体数字、趋势分析、标签和图例、时间范围、计量单位，并且特别强调"数字要精确，能看到具体数值的不要说约"。
改完之后效果直接起飞。同一张苹果营收图，它会输出"iPhone 收入分别为 2052 亿、2006 亿、2012 亿美元"这种精确到个位数的描述。这才是金融场景需要的。
向量数据库：为什么选 Qdrant
数据处理完，全都是文本了，要存进向量数据库做检索。
我对比了 Chroma、FAISS、Weaviate、Pinecone 几个方案，最后选了 Qdrant。核心原因就一个：它原生支持混合搜索（Dense + Sparse），不用自己实现 RRF 融合算法。
Chroma 太轻量，生产不够用。FAISS 不支持 metadata 过滤。Pinecone 纯云端不能本地部署。Qdrant 用 Docker 跑在本地，还有个 Dashboard 能可视化看数据，开发阶段特别方便。
Embedding 模型用的是 Gemini Embedding（3072 维）做 Dense，加上 BM25 做 Sparse。Chunk 大小定在 500-800 tokens，这个是试出来的——太小上下文不够，太大语义不聚焦。
入库的时候还有个容易被忽略的点：Metadata。每个 chunk 都带上了公司名、文档类型、年份、页码这些元信息。检索的时候如果用户问"苹果的收入"，系统会先用 LLM 从问题里提取出 company=apple 这个过滤条件，只在苹果相关的数据里搜索。不然数据库里存了苹果、微软、亚马逊的年报，全混在一起搜效果就差了。
检索精度：三招拉满
RAG 系统里，检索精度比 LLM 能力更重要。检索出来的内容不对，LLM 再强也白搭。
我用了三个手段：
一是混合搜索。Dense Search 理解语义（"revenue growth"和"sales increase"是同一个意思），Sparse Search（BM25）精确匹配关键词。两个结果用 RRF 算法合并。
二是动态 metadata 过滤。用 LLM + Pydantic Schema 从用户问题里自动提取出公司名、年份、文档类型这些过滤条件，缩小搜索范围。
三是 Cross Encoder 重排序。混合搜索拿到 Top-20 之后，用 Cross Encoder 把 query 和每个 document 拼在一起，让模型直接打分排序。精度比普通的 embedding 相似度高很多，但速度慢，所以只用在 Top-K 重排这一步。
实测下来，纯语义搜索、混合搜索、混合搜索+重排序，三个方案的 Top-1 准确率差距非常明显。加了 Cross Encoder 之后，排第一的基本就是最相关的那个 chunk。
Agent：RAG + MCP 双线作战
检索搞定之后，就是把所有东西拼成一个完整的 Agent 了。
这个 Agent 手里有两个工具：
deep_rag_search：从向量数据库检索年报数据live_finance_researcher：通过 MCP 查 Yahoo Finance 实时数据
System Prompt 里写清楚了分工——问历史数据用 RAG，问实时行情用 MCP，做综合分析两个都用。
还加了 Memory（SqliteSaver 做持久化），这样 Agent 能记住之前聊过什么，可以连续对话。你先问"苹果的收入结构是什么"，再问"和去年比怎么样"，它知道你还在说苹果。
TODO Planner：从"走一步看一步"到"先计划再执行"
到这一步其实已经能用了。但有个问题——面对复杂问题，Agent 是想到什么工具就调什么工具，没有章法。
加了 LangChain 的 TodoListMiddleware 之后，完全不一样了。
我问它"对比微软 Q2 财报和当前股价"，它先调用 write_todos 生成了一个 3 步计划：
- 步骤1：从年报数据中检索微软 Q2 收入（进行中）
- 步骤2：从 Yahoo Finance 获取微软当前股票表现（待处理）
然后按步骤一步步执行。执行过程中还会根据实际情况调整计划——比如本地没有微软的年报数据，它会把步骤 1 标记为"失败，切换到 live researcher"，然后改从 Yahoo Finance 拿数据。
这种自适应能力挺让人惊喜的。
简单问题它不会触发计划，直接回答。只有多步骤的复杂问题才会走 TODO 流程。这个区分是通过 write_todos 工具的 docstring 实现的，不需要额外配置。
Summarization：防止上下文爆掉
复杂查询过程中，Agent 来回调了很多次工具，消息数量很快就能到几十条。直接超出 LLM 的上下文窗口怎么办？
加了 SummarizationMiddleware，设一个阈值（我设的 25 条），超过之后自动把前面的消息压缩成一条摘要，保留最近的消息继续工作。
在 LangSmith 里能看到，一开始 Summarization 的执行时间是 0 秒（没触发），跑到中间某个节点突然变成了 14 秒——这就是摘要在工作了。
技术栈一览
| |
|---|
| |
| |
| |
| |
| |
| |
| HuggingFace Cross Encoder |
| |
| |
除了 Gemini API 有少量费用（处理几百张图大概不到 1 美元），其他全是开源或免费方案。
哪些坑值得注意
搞下来两周，踩的坑不少，挑几个印象深的说：
Yahoo Finance 的 MCP 底层用的 yfinance 库，短时间调用太频繁会被限流。我有一次连续跑了好几个复杂查询，直接被 ban 了一阵子。
Docling 对加密的和扫描版 PDF 不太行，最好用原生数字 PDF。另外表格跨页的话可能被拆成两个，要注意检查。
Chunk 大小真的需要试。我一开始用的 200 tokens，检索出来的内容碎片化严重。后来加到 500-800，效果才稳定下来。
Cross Encoder 精度高但速度慢，千万别用来做全库搜索，只适合做 Top-K 重排序。
完整教程
这篇算是把整个系统的架构和设计思路走了一遍。如果你想跟着动手实现，我把具体的代码实现写成了 8 篇教程：
- 用 MCP + Yahoo Finance 打造实时股票研究 Agent
- 金融场景多模态 RAG 系统设计（5 种方案对比）
- 搭建多模态金融研究 Agent（RAG + MCP）
每篇都有完整代码、踩坑记录和效果对比，从第一篇跟到最后一篇就能搭出一个完整的金融研究 Agent。放在付费合集里了，感兴趣的可以去看看。
