多Agent协作构建AI投资团队：QuantBot架构与实战解析

1. 为什么给自己做一整个“AI 投资团队”

做 QuantBot 的起因其实挺直接的：我自己平时会关注一些市场数据，也写过不少脚本去抓行情、算指标，但慢慢发现一个很尴尬的问题——单靠一两个策略脚本，根本覆盖不了“看宏观、盯行业、读财报、控风险、下决策”这一整条链路。我想要的不是又一个指标回测工具，而是一个能像真实投研团队一样分工协作的系统。于是就有了 QuantBot，一个由多个 AI Agent 组成的量化投资协作体。

市面上很多量化框架擅长“算”，但它们不擅长“读”和“想”。比如让程序去读一份几百页的年报、去理解一条宏观政策对某个板块的传导路径，传统因子模型基本无能为力。LLM 的出现让“读”和“想”这件事变得可行，再加上 Agent 可以调用工具、访问数据、互相校验，我才觉得时机成熟了——可以用大模型把投研流程里的“信息获取、分析判断、风险控制、执行决策”串起来。

这篇文章不是要教你抄一个一模一样的系统，而是想完整拆解 QuantBot 的设计思路、架构分工、实现细节和踩坑记录。适合谁看？如果你对 AI Agent 开发感兴趣，或者正在做量化研究、想用大模型改造自己的投研流程，这篇文章应该能给你一些可落地的参考。

2. 整体设计：为什么“团队”比“单一大模型”靠谱

2.1 单一大模型做投资决策的问题

一开始我也试过最简单的方案：把所有数据丢给一个大模型，直接问“该不该买”“目标价多少”。实测下来问题非常突出。

首先是上下文窗口有限。一家公司的财报动辄几十页，再加上历史行情、行业新闻、宏观数据，一轮对话塞进去，模型很快就“忘了”前面的内容，或者开始答非所问。其次是角色混乱。让同一个模型既做乐观的研究员，又做谨慎的风控官，它很容易在两种角色之间摇摆。比如刚分析完“这只股票基本面优秀”，转过脸问它风险，它又开始说“但也要注意风险”——说了等于没说。

更关键的是无法追溯。如果模型直接给出一个结论，你根本不知道它依赖了哪些数据、做了哪些推理、在哪里可能出现偏差。投资决策最怕的不是犯错，而是不知道错在哪里。

2.2 用多智能体模拟投研团队分工

QuantBot 的核心思路，是把投资决策流程拆成五个角色，每个角色由一个独立的 Agent 承担：

• 数据采集 Agent（情报员）：负责抓取行情、财报、新闻、宏观数据，并把非结构化文本转成结构化信息。
• 研究分析 Agent（研究员）：基于采集到的数据，做基本面分析、行业对比、估值判断，输出研究报告。
• 风险控制 Agent（风控官）：独立审查研究员的结论，检查数据是否有缺失、逻辑是否有漏洞、风险是否被忽略。
• 组合管理 Agent（基金经理）：综合研究和风控的意见，决定仓位比例、买入卖出时机。
• 复盘 Agent（投后分析师）：定期回顾决策结果，对比预期和实际，生成复盘报告，反馈给其他 Agent 优化后续决策。

这五个角色不是简单的“串行问答”，而是通过一个工作流引擎协作。数据采集完成后会触发研究分析，研究报告会同时发给风控和组合管理，风控有“否决权”，组合管理需要给出明确的仓位和理由。

这样做的好处很明显：每个 Agent 的职责单一，Prompt 可以写得更精准；决策过程有迹可循，每一个结论都能追溯到具体的输入数据和分析逻辑；某个环节出错时，可以单独修复而不影响整个系统。

2.3 技术选型背后的取舍

• 用 LangChain 还是自研工作流？我一开始用了 LangChain，但后来发现对于这种固定流程的场景，自研一个简单的状态机反而更可控。因为投资流程是相对确定的，不需要太多动态规划，自己写成本低、排错快。
• 用开源模型还是 API？我本地跑了 Qwen 和 Llama 做数据清洗和情感分析，但核心研究和风控用的是商用 API。原因很简单：本地模型在长文档理解和多步推理上暂时还比不上头部商用模型，而投资分析对推理质量要求很高。为了成本控制，我会用小模型做预处理，大模型做深度分析。
• 用 Python 还是其他语言？Python，生态太强了，pandas 做数据处理、backtrader 做回测、FastAPI 做服务封装，基本一条龙。

3. 核心功能与实现细节

3.1 数据层：让 Agent “看得见”真实世界

没有数据，Agent 就是纸上谈兵。QuantBot 的数据层主要解决三个问题：数据从哪来、怎么存、怎么让 Agent 高效“读懂”。

我用的是“公开数据源 + 定时任务”的组合。行情数据通过免费的行情接口获取，财报和公告则是定时抓取公开披露信息，新闻舆情用 RSS 加爬虫补充。数据统一清洗后存入本地数据库（SQLite 加 Parquet 文件，兼顾轻量和性能）。

这里有一个容易被忽视的难点：非结构化数据的处理。财报是 PDF，新闻是网页，公告是表格，Agent 不能直接读原始格式。我的做法是先用一个小模型做 OCR 和版面解析，把 PDF 转成 Markdown，再用规则加模型把关键财务指标抽取成 JSON。这个环节的准确性直接影响后续所有 Agent 的质量，值得花大力气。

比如，“营业收入”在财报里可能有“营业总收入”“营收”等不同叫法，还有“本期”和“上年同期”的区分。我用了一套字段映射规则加二次校验：先按正则抽候选人，再用小模型判断哪个才是“本期营业收入”。实测下来准确率在刚开始只有 70% 左右，加了人工标注样本微调后能到 90% 以上。

3.2 研究分析 Agent：长上下文与结构化输出

研究分析 Agent 是 QuantBot 里最重的一个模块，它的输入是数据层整理好的财报 Markdown、行情数据和新闻摘要，输出是一份结构化的研究报告。

我采用“分块阅读、逐步归纳”的方式来应对长文档。先让 Agent 分块总结每部分内容，再把总结汇总成几个维度：盈利能力、成长性、财务健康度、行业位置、近期催化因素。这一步用的是带 JSON 输出约束的 Prompt，返回结果是一个严格的 JSON 对象，方便下游直接解析。

Prompt 的设计我反复调了很多版，几个关键经验：

• 明确输出 schema，用 few-shot 示例固定结构，最稳妥的方式是给模型一个“填表”任务，而不是开放式的“写报告”任务。
• 要求模型在每一项判断后都附上数据来源版本号或数据片段，便于追溯。比如“应收账款周转天数从XX天上升到XX天，来源：2023年财报P12”。
• 禁止模型做没有数据支撑的“想象”。我专门加了一条指令：如果某项数据缺失，必须明确写“数据缺失”，而不是编造一个合理值。

研究分析做完后，会生成一个“标的画像”JSON，包含评分、关键指标、风险点、催化剂等字段。这个 JSON 是后续所有 Agent 的数据基础。

3.3 风控 Agent：用“对抗式审阅”降低模型幻觉

风控 Agent 是我觉得最有价值也最难做好的模块。它的任务不是重复研究分析，而是“挑刺”。我会让它从以下维度审阅研究报告：

• 数据一致性：研究报告中使用的财务数据与原始财报是否一致？有没有张冠李戴？
• 逻辑完整性：从数据到结论的推理链条是否成立？有没有跳跃？
• 风险遗漏：是否只讲了好的一面，而忽略了流动性、行业政策、竞争格局等风险？
• 极端情况：如果核心假设不成立，最坏情况下会怎样？

为了减少大模型的“惯性认同”，我的做法是用对抗式 Prompt。风控 Agent 拿到的指令是“你是首席风险官，你的职责是推翻研究员的结论，找出一切可能的问题”，并且要求它先列出质疑点，再给结论，而不是先给结论再补充理由。

连带地，我在风控环节设了一个“置信度”评分。如果风控对某项数据的置信度低于阈值，系统会触发数据复核流程——重新调用数据采集 Agent 去核对原始来源，或者标记为“低置信度”并降低该标的最大仓位上限。

实体对齐也是一个很实际的问题。“贵州茅台”在新闻里可能叫“茅台”“贵州茅台酒股份有限公司”“600519”，如果不对齐，研究 Agent 很可能把 A 公司的新闻安到 B 公司头上。我用了一个简单的别名表加向量匹配的组合方案，实测对 A 股主要标的效果很好。

3.4 组合管理 Agent：决策与仓位计算

组合管理 Agent 是最后一个“拍板”的角色。它拿到研究分析报告、风控意见和历史交易记录，输出具体的操作指令。

输出指令是一个结构化 JSON，包含标的、方向（买/卖/持有）、仓位占比、目标价、止损价、操作理由。

仓位计算我引入了凯利公式的简化版本。假设某次交易有 p 的概率盈利、b 为赔率，那么最优仓位比例 f = (bp - 1) / b。但实际中 p 和 b 都是模型估计的，误差很大，所以我会设置仓位上限（单标的仓位不超过 25%）作为保护。

这里有一个关键设计：组合管理 Agent 不能直接访问市场实时行情，只能依赖数据层提供的快照。这个“信息隔离”是为了避免模型因为短期价格波动做出情绪化决策，让它更专注于基于基本面的中长期判断。

3.5 复盘模块：让系统能“吃一堑长一智”

做完一笔交易后，复盘 Agent 会在一段时间后对比当时的预测和实际走势，生成复盘报告。内容包括：预测是否准确、偏差来自哪里（数据问题？逻辑问题？市场风格切换？）、下次可以怎么改进。

复盘报告的结论会写回知识库，作为后续 Agent 的参考。比如某个行业“降本增效”逻辑在市场不好时往往不奏效，如果复盘 Agent 发现了这个规律，会被记录在一个“经验教训”文档里，后续研究 Agent 分析类似标的时会被提示参考。

这一步是我觉得 QuantBot 最有“团队感”的地方。传统的量化策略是一堆死代码，而 QuantBot 通过复盘和知识库更新，有了持续进化的能力。

4. 实操过程：从零搭建 QuantBot 真实记录

4.1 第一步：明确最小可用版本（MVP）范围

做这类系统最怕一开始就想做“大而全”。我的经验是先找出一个最核心的业务闭环，跑通后再扩展。

QuantBot 的 MVP 我定义为“对单一标的（比如贵州茅台）做研报分析 + 风控审核 + 仓位建议”。只支持一个标的、一周更新一次、不接入实盘交易，只输出建议。跑通这个闭环后，再逐步扩展多标的、日频、模拟交易。

4.1.1 定义数据流

这个阶段我画了一张最基础的数据流图，确保每个模块的输入输出都明确：

数据采集 Agent → 原始数据库 → 数据清洗 → 研究报告 JSON → 风控审核 JSON → 组合决策 JSON → 复盘记录

每个环节的数据格式我都在项目启动第一天就定死了，宁可后面改，也比一开始乱传强。

4.1.2 定义技术栈

• 编程语言：Python 3.11
• 数据存储：SQLite（结构化数据）、本地 JSON/Parquet（中间结果）
• Agent 框架：自研状态机 + Prompt 模板管理
• LLM 接入：统一封装 OpenAI 兼容接口，方便切换模型
• 服务部署：FastAPI 提供 Web 界面，Process Scheduler 做定时任务

4.1.3 规划安全性

投资建议必须免责。QuantBot 的所有输出都在界面上标明“仅供研究学习，不构成投资建议”。同时，我配置了 API 访问频率限制和成本监控，防止某个 Agent 的意外死循环把 API 额度耗光。

4.2 第二步：搭建数据采集层

数据采集用 Python 的 requests 加 BeautifulSoup，配合 APScheduler 做定时任务。目标不要求实时推送，所以一天更新一次完全够用。

典型的数据获取代码如下：

import requests from bs4 import BeautifulSoup import json def fetch_financial_report(stock_code): # 这里以某个公开披露页面为例，实际中可能需要处理验证码和分页 url = f"https://example.com/financial/{stock_code}" resp = requests.get(url, timeout=10, headers={"User-Agent": "Mozilla/5.0"}) soup = BeautifulSoup(resp.text, "html.parser") # 提取关键表格，转换成 pandas DataFrame 后再序列化为 JSON table = soup.find("table", {"class": "financial-data"}) data = parse_table_to_json(table) return data

需要注意，不是所有 Source 都稳定。我的做法是每一类数据源都写一个 adapter，统一返回标准化格式。这样即使某个数据源挂了，也不会影响其他数据导入。

4.2.1 财报解析的细节坑

财报 PDF 转成文本后，有很多格式噪声。比如表格会变成一行一行的文本，数字之间的分隔符不统一。我后来总结了一个最佳实践：先用 PyMuPDF 把 PDF 按页面转成图片，再用 OCR 模型识别表格结构，而不是直接提取文本。虽然多了一步，但对表格型数据的还原度高了一个档次。

4.3 第三步：Agent Prompt 设计实战

Prompt 是整个 QuantBot 的灵魂。同一个模型，Prompt 写得好不好，效果差别非常大。分享一下我在研究 Agent 上的最终版本核心逻辑：

4.3.1 系统提示词（System Prompt）

你是 QuantBot 研究团队的高级分析师。你以严谨、客观、数据驱动的方式工作。 你的输入是经过清洗的财报数据和市场信息，你的输出必须严格遵循给定的 JSON Schema。 注意： 1. 只使用输入数据中明确存在的信息，不要推测或编造。 2. 对于缺失的数据，在对应字段中写入"数据缺失"，不要自动填默认值。 3. 对每项判断，都给出数据支持，并注明数据来源。 4. 如果某项数据存在重大不一致或异常，在高亮风险区域标明。

4.3.2 用户提示词（User Prompt）

请分析以下财务数据，输出 JSON。 【财报摘要】 {financial_summary} 【行情数据】 {market_data} 【JSON Schema】 {json_schema}

这个设计把角色、任务、约束、输出格式四件事分开说清楚。实践中最有效的技巧是用“负面约束”明确告诉模型不要做什么，这比正面要求更有效。

4.3.3 引入“思考草稿”机制

我让模型在输出最终 JSON 前，先生成一段“思考草稿”（chain-of-thought），放在一个隐藏字段里，然后基于草稿生成最终结果。这么做能显著提升分析质量，但会增加 token 消耗，所以只对研究 Agent 和风控 Agent 启用。

4.4 第四步：状态机工作流实现

工作流我用一个非常轻量的状态机实现，不需要引入重型框架。核心就是一个 Python 字典来定义状态转移：

workflow = { "采集完成": ["研究分析"], "研究完成": ["风控审核"], "风控否决": ["重新研究", "终止"], "风控通过": ["组合决策"], "组合决策完成": ["执行/输出"], }

每个状态对应一个执行函数，函数内部处理输入输出，并把结果写入数据库。如果某个状态执行失败（比如 API 超时），状态机会自动重试三次，然后进入错误处理流程。这个流程简单可靠，排错时也能很方便地看到卡在了哪一步。

4.4.1 并发与异步的坑

一开始我天真地以为多 Agent 之间可以用异步并发提高效率，后来发现大模型 API 的调用很容易触发限流，而且多个 Agent 同时写数据库会有锁竞争。最终方案是：数据采集阶段用并发（IO 密集），分析阶段用串行（确保顺序和可追踪）。这个取舍让整体系统稳定了一个量级。

4.5 第五步：回测与模拟验证

QuantBot 的核心输出是决策建议，但决策对错不能靠感觉，需要一套回测机制。

我用 backtrader 做了简化回测：把 QuantBot 每天的决策记录转成“模拟交易”，假设按决策价成交，扣除手续费和滑点，最后计算累计收益率、最大回撤、夏普比率等指标。

回测框架的核心代码片段：

import backtrader as bt class QuantBotStrategy(bt.Strategy): def __init__(self): self.decision_log = {} # 从数据库加载决策记录 def next(self): date = self.datas[0].datetime.date(0) if date in self.decision_log: decision = self.decision_log[date] if decision["action"] == "buy": self.buy(size=calculate_position(decision["weight"])) elif decision["action"] == "sell": self.sell(size=calculate_position(decision["weight"]))

回测结果只是参考，不能过度优化。我在回测里刻意没有加入“未来函数”，也不允许模型看到当日收盘后的信息来做当日决策，这是一个底线原则。

5. 实测结果与关键发现

5.1 用历史数据做“模拟盘”验证

我选取了过去两年几个主要宽基指数的成分股池，每个月让 QuantBot 做一次调仓建议，然后用历史行情做模拟交易。

9个月的模拟运行结果显示，QuantBot 的累计收益率大致跑赢了基准指数，但最大回撤也略高。更让我关注的是它的几个行为特征：

• 现金比例控制较好。在几次急跌行情中，风控 Agent 会主动建议降低仓位，系统整体回撤被控制住了。
• 频繁交易的问题依然存在。有些月份调仓过于频繁，手续费和滑点吃掉了不少收益，后来不得不在组合管理 Agent 的 Prompt 里加入“每次调仓时考虑交易成本”的约束。
• 复盘模块的价值开始显现。有几笔亏损交易在复盘中被归因为“财报数据更新延迟导致使用了过期数据”，后来我在数据层增加了“财报发布时间戳”校验，情况明显改善。

5.2 不同模型的对比观察

我对比了 GPT-4o、Claude 和本地部署的 Qwen-72B 在同样任务上的表现。

• 本地模型在数据清洗和实体对齐任务上基本够用，成本低且数据不出本地，适合做前处理。
• 商用模型在“从数据到结论的推理”上明显更强，但偶尔会出现“迎合用户”的情况。如果 Prompt 暗示某个标的是好公司，模型往往会更积极。对抗式风控 Prompt 能在一定程度上对冲这个倾向。
• 推理速度是瓶颈。一次完整的单标的研报分析 + 风控审核 + 决策，调用大模型 API 需要大约两分钟，多标的场景下需要串行排队。这个延迟在做日频级别是完全够用的，但想做分钟级别就太慢了。

5.3 成本分析

API 调用成本是量化 Agent 系统不可回避的问题。我做了粗略统计：

• 单次单标的完整分析流程（数据清洗 + 研究 + 风控 + 决策）大约消耗 4 万到 6 万 token。
• 如果每天分析 20 个标的，一个月的 API 成本大约是 100 到 300 美元，取决于模型。这个成本对个人玩家来说不便宜，但对专业机构来说完全可以接受。

优化策略有几个方向：使用小型模型做预处理；对财报做增量更新而不是每次全量分析；引入缓存机制，对同一个标的短期内多次调用时直接复用中间结果。

5.4 核心结论：QuantBot 能做和不能做的事

做完整套系统后，我对它的能力边界有了比较清楚的认识。

能做：快速处理大量公开信息、生成结构化的投研报告、用对抗式机制降低单一模型偏见、保持决策过程的完整可追溯性。

不能做：预测短期股价、处理市场情绪突变、克服数据本身的滞后性。QuantBot 的本质是把“信息处理自动化”，而不是“预测未来”。

6. 常见问题与避坑指南

6.1 数据问题：财报数据抓取不稳定

这几乎是绕不开的坑。公开数据源经常改版、反爬策略收紧、字段名称不一致、历史数据缺失。我的排查思路是：

• 给数据采集模块做“健康检查”，每次抓取后统计行数和关键字段缺失率，异常时自动告警。
• 不同数据源相互校验。同一指标用两个源交叉比对，如果差异超过阈值就标记为“可疑数据”，并在报告中降权。
• 保留原始文件备份。不要只存处理后的数据，原始 PDF、HTML 都要存档，方便回溯。

6.2 模型问题：大模型“一本正经地胡说八道”

这是所有 LLM 应用的老大难。在投资领域，幻觉的代价非常高。我的防线是：

• 在数据层给每个数据片段加来源 ID，研究 Agent 在报告中引用数据时必须附带来源 ID。
• 风控 Agent 专门做一致性检查，比对报告中的数字和原始数据源。这一层能拦住相当一部分幻觉。
• 对于低置信度的数据，不设定性结论，只标“数据缺失”或“无法判断”。

6.3 Agent 问题：多智能体之间互相“传染”错误

多智能体系统最头疼的问题，是错误会被逐级放大。数据采集阶段的一个小错误，经过研究、风控、决策，到最终输出时可能变成一个完全不可信的结论。

我的处理办法是“置信度标签逐级传递”。数据层给每一条数据打置信度，研究 Agent 在报告中汇总整体置信度，风控 Agent 如果发现置信度不足就直接质疑，组合管理 Agent 在决策时看到低置信度会降低仓位上限。通过这种方式，错误虽然不能完全消除，但会被系统显式地标记出来，不会被静默传递。

6.4 工程问题：API 调用超时与成本失控

LLM API 不是 100% 可靠的，经常有超时和限流。我在工作流里做了三个保护机制：

• 超时重试 + 指数退避。第一次失败等 1 秒，第二次等 4 秒，第三次等 16 秒，最多重试 3 次。
• 每次调用前预估 token 用量，设置告警阈值。如果某次分析任务的 token 消耗超过预估 50%，系统会发通知提醒。
• 成本上限熔断。设置每日 API 成本上限，超过后自动切换到备用模型或暂停新任务。这在多标的、长时间运行时非常重要。

6.5 一个隐藏很深的坑：时序数据穿越

回测中最危险的 bug 是时序穿越。比如用 2024 年的财报数据去做 2023 年的决策，这在数据流水线里太容易发生了。原因是财报发布时间和数据所属期不是同一个时间。比如 2023 年的年报，可能到 2024 年 4 月才发布，如果用发布时间过滤就会漏掉，如果按所属期过滤就会穿越。

我的解决办法是数据库里同时保存“公告日期”和“报告期”，Agent 在做某一天的决策时，只能查询公告日期小于等于当天的数据。这个逻辑我用单元测试专门覆盖，不让任何 Agent 直接裸查数据库。

6.6 常见问题速查表

问题	现象	排查思路
财报数据缺失严重	研究报告里“数据缺失”字段过多	检查数据源是否改版、解析脚本是否匹配新格式
模型输出非预期格式	JSON 解析失败	检查 Prompt 中 Schema 示例是否清晰，考虑用 function calling
风控形同虚设	风控结果与研究结论几乎一致	加强对抗性指令，要求先列反驳点再给结论
回测过拟合	回测收益极高但实盘不行	检查是否有前视偏差，增加样本外时间段测试
成本飙升	API 账单比预期高很多	检查是否有死循环调用，开启中间结果缓存
多标的运行太慢	完成整个分析流程需要太久	考虑并行采集、串行分析，或引入小模型预处理

6.7 保持项目边界清晰的建议

个人做这类项目，最大的风险不是技术不会，而是越做越大、越做越散。建议从一开始就规定几个“不做”：

• 不做高频交易。QuantBot 的分析速度和处理能力就不适合高频，强行上高频只会两头落空。
• 不做短线情绪预测。模型对市场情绪的捕捉不可靠，不如只关注中长期基本面。
• 不做杠杆和衍生品。风控 Agent 还不足以驾驭复杂衍生品风险，连模拟交易都不建议开这些品种。
• 不做全自动化实盘。至少在早期，所有决策都需要人工审核确认后再执行。这个“人在回路”的设计，既是对系统的保护，也是对自己的保护。

7. 后续规划与个人体会

项目做到这个阶段，我越来越觉得 QuantBot 的价值不在于“赚钱”，而在于把投资研究这个高度依赖经验和个人判断的过程，变成了一个可拆分、可验证、可迭代的工程系统。

下一步我准备做三件事：一是接入更多类型的另类数据，比如供应链数据、专利数据，让研究 Agent 有更多的信息维度；二是引入强化学习来优化组合管理 Agent 的仓位分配策略，让它从历史复盘中自主学习；三是把前端界面做得更易用一些，方便记录人工审核意见，形成更完整的决策闭环。

最后分享一点个人的实际感受：做 AI 投资团队，最容易低估的是数据工程和评测体系的复杂度。市面上大多数教程都在教你调 Prompt，但真正决定系统上限的，往往是数据质量、评测方法和工程可靠性。QuantBot 走到今天，最花时间的不是写 Agent 代码，而是处理脏数据、设计对抗式评测集、和各种奇怪的边界条件作斗争。

如果你也想做一个类似的项目，我的建议是：先用一个标的、一个狭小的业务场景跑通闭环，再谈扩展。不要一开始就追求“全自动”“多标的”“实时”，那只会让你陷入无穷无尽的调试泥潭。投资是一条长跑，做 AI 投资系统也是。