多Agent协作做股票研究的全链路工程实践笔记

# 多 Agent 协同做股票研究：我的全链路工程实践复盘

过去半年，我在本地搭建了一套“多 Agent 协同的股票研究系统”，把“数据采集、因子挖掘、策略生成、回测验证、报告输出”这 5 个关键环节分别交给不同的 Agent 处理。今天把这套系统的完整工程实践记录下来，重点聊清楚“为什么股票研究需要多 Agent”以及“多个 Agent 之间如何高效协作”。

## 一、为什么需要多 Agent

做股票研究这件事，单靠一个人非常累，团队协同又往往比较慢。更理想的方式其实是“流水线分工”——每个人，或者说每个 Agent，只负责一个明确环节，上一环节的输出直接成为下一环节的输入。

我尝试过用“单 Agent 包办所有任务”，结果很明显：

- 上下文窗口很快被占满（Qwen2.5-72B 是 32K）

- 任务规划容易混乱（一个 Agent 同时处理“因子设计”和“回测验证”时，很容易来回打转）

- 调试难度很高（一个 Agent 出错时，很难快速定位到底是哪一步出了问题）

多 Agent 架构可以很好解决这三个核心问题。每个 Agent 都拥有独立上下文、独立目标和独立工具集，Agent 之间通过“消息队列”完成协作，这也是多 Agent 系统在量化研究和股票分析场景里更适合落地的原因。

## 二、整体架构

整个系统包含 5 个核心 Agent：

```

┌──────────┐┌──────────┐┌──────────┐

│ 数据 Agent │ → │ 因子 Agent │ → │ 策略 Agent │

└──────────┘└──────────┘└──────────┘

│││

↓↓↓

数据接口因子库策略代码

│

↓

┌──────────┐

│ 回测 Agent │

└──────────┘

│

↓

┌──────────┐

│ 报告 Agent │

└──────────┘

```

每个 Agent 都有自己清晰的“角色定位”和“工具能力边界”。

三、数据 Agent

**角色定位**：根据其他 Agent 的请求，从本地数据引擎中拉取所需股票数据与行情信息。

**核心工具**：

- `query_stock_basic`：查询股票基本信息

- `get_realtime_quote`：获取实时行情

- `get_history_kline`：获取历史 K 线

- `get_money_flow`：获取资金流向

- `get_longhubang`：获取龙虎榜

- `get_industry_flow`：获取行业资金流向

- `get_tick_data`：获取逐笔成交

- `get_financials`：获取财务数据

**设计要点**：数据 Agent 只负责“取数”，不参与任何分析判断。这样它的上下文非常纯净，基本不会出现“上下文爆掉”的问题，也更适合承担高频数据查询任务。

**容易踩坑的一点**是，数据 Agent 的“超时”问题其实非常常见。举个典型场景：如果一次性拉取 5000 只股票的全量财务数据，耗时通常会超过 30 秒。这样一来，上层 Agent 就只能持续等待，整体响应速度会明显下降。后来我在这里做了一个优化：引入“异步任务队列”，让数据 Agent 先把这类高耗时任务放入队列，再返回一个 task_id；上层 Agent 拿到 task_id 后，就可以选择轮询结果，或者直接订阅任务回调。

四、因子 Agent

**角色定位**：根据用户的研究方向，设计、筛选并挖掘量化因子。

**核心工具**：

- `list_existing_factors`：列出已有因子库

- `add_factor`：添加新因子

- `test_factor`：单因子检验（IC、收益、回撤）

- `analyze_factor_decay`：分析因子衰减

- `correlate_factors`：因子相关性分析

**输入**：研究方向（如“我想找能预测短期反转的因子”） 已有因子库

**输出**：新因子定义 单因子检验报告

**设计要点**：因子 Agent 必须具备“自我评估”能力——它生成的新因子，必须先自己跑一轮单因子检验，IC 太低的因子自动丢弃。这个“自检”机制对提升因子挖掘质量非常关键。

**踩坑**：因子 Agent 很容易出现“过度优化”问题——它会持续尝试各种因子变种，一旦找到一个 IC 较高的结果就提交，但这个因子很可能已经“过拟合”。后来我增加了一个“样本外测试”模块，要求每个新因子都必须在训练集之外的数据上再做一次检验，IC 衰减超过 30% 的会被标记为“可疑因子”。这一步对于量化因子研究尤其重要。

## 五、策略 Agent

**角色定位**：根据因子 Agent 产出的有效因子，组装成完整可执行的量化交易策略。

**核心工具**：

- `generate_strategy_code`：生成策略代码

- `validate_strategy_syntax`：语法检查

- `preview_strategy_logic`：预览策略逻辑

- `submit_to_backtest`：提交到回测 Agent

**输入**：1-3 个有效因子 用户的风控要求（如最大回撤、夏普比率）

**输出**：策略代码（Python 函数） 策略说明文档

**设计要点**：策略 Agent 必须输出“可直接执行的策略代码”，而不是停留在“伪代码”层面。我要求它生成的代码必须通过 `validate_strategy_syntax` 工具的语法检查，否则就重新生成。这一点对量化策略开发和自动化回测非常关键。

**踩坑**：策略 Agent 生成的代码经常会“调用不存在的因子”——也就是它引用了因子 Agent 还没有正式产出的因子。后来我要求因子 Agent 必须先把因子“注册”到因子库，策略 Agent 只能引用因子库中已经注册的因子。这个“注册机制”解决了大部分“因子不存在”的问题。

## 六、回测 Agent

**角色定位**：执行量化策略回测，并输出标准化回测报告。

**核心工具**：

- `run_backtest`：运行回测

- `generate_backtest_report`：生成回测报告

- `check_overfitting`：检查过拟合

- `compare_strategies`：多策略对比

**输入**：策略代码 回测时间范围 初始资金

**输出**：回测报告（年化、最大回撤、夏普、胜率、IC） 过拟合检查结果

**设计要点**：回测 Agent 必须“独立运行”——它拥有自己的回测引擎，不依赖其他 Agent。这样当策略 Agent 提交代码后，回测 Agent 就可以异步执行，不会阻塞整个股票研究流程。

**踩坑**：回测 Agent 的“计算资源管理”是一个难点。一次全市场回测（5000 只股票 × 3 年数据）可能要跑 10 分钟以上。后来我采用了“分布式回测”方案——把一个大回测任务拆分成多个子任务，分发到多台机器并行执行，从而显著提升回测效率。

## 七、报告 Agent

**角色定位**：把前面 4 个 Agent 的产出进行汇总，形成最终的股票研究报告和量化分析结果。

**核心工具**：

- `generate_research_report`：生成研究报告

- `generate_visualizations`：生成可视化图表

- `summarize_findings`：总结核心发现

- `export_to_pdf`：导出 PDF

**输入**：研究问题 数据 Agent 的数据 因子 Agent 的因子 策略 Agent 的策略 回测 Agent 的回测报告

**输出**：完整的研究报告（Markdown / PDF 格式）

**设计要点**：报告 Agent 是“信息整合者”，它不负责新增分析，而是把前面 4 个 Agent 的结果做“结构化、可视化、可读化”处理。对于股票研究系统来说，这一步直接决定最终交付质量。

**踩坑**：报告 Agent 很容易“过度包装”——它倾向于把所有数据都塞进报告，导致内容非常冗长。后来我增加了“核心发现提取”模块，要求报告 Agent 先用 LLM 提炼出 3-5 个核心发现，再围绕这些关键信息组织报告结构。

## 八、Agent 之间的协作机制

这 5 个 Agent 之间并不是简单的“串行流水线”，更准确地说，是“消息总线 任务队列”的组合协作模式。

**消息总线**：用 Redis Pub/Sub 实现。每个 Agent 订阅自己关心的消息频道，并将自己的产出发布到对应频道。

**任务队列**：用 Celery 实现。耗时任务（例如数据 Agent 的批量查询、回测 Agent 的全市场回测）放入任务队列中异步执行。

**协作流程示例**：

用户提问：“帮我设计一个‘短期反转 低估值’的量化策略”

1. 用户问题 → 因子 Agent（消息总线接收）

2. 因子 Agent 调用 `list_existing_factors`，发现已有“短期反转因子”和“低估值因子”

3. 因子 Agent 调用 `correlate_factors` 检查两个因子的相关性（避免共线性）

4. 因子 Agent 输出“已有因子，无需新增”

5. 因子 Agent → 策略 Agent（消息总线传递）

6. 策略 Agent 调用 `generate_strategy_code`，组合两个因子并生成策略代码

7. 策略 Agent 调用 `validate_strategy_syntax` 检查语法

8. 策略 Agent 把代码提交到回测 Agent（任务队列）

9. 回测 Agent 异步执行回测，生成回测报告

10. 回测 Agent → 报告 Agent（消息总线传递）

11. 报告 Agent 调用 `generate_research_report`，汇总全部产出并生成最终报告

整个流程通常在 2-5 分钟内完成（具体取决于回测耗时）。

## 九、关键设计决策

**决策 1：每个 Agent 使用独立上下文**

这是整个多 Agent 股票研究系统里最重要的设计。每个 Agent 之间不共享上下文，只通过消息传递“结果”。这个设计让每个 Agent 的 prompt 都可以单独优化，同时避免上下文冲突。

**决策 2：工具集按 Agent 角色拆分**

数据 Agent 的工具集是“数据获取工具”，策略 Agent 的工具集是“策略代码生成工具”，回测 Agent 的工具集是“回测执行工具”。不同 Agent 的工具能力不重叠，可以有效避免工具越权调用。

**决策 3：每个 Agent 都具备“自我评估”机制**

数据 Agent 会评估“数据质量”（如缺失值、异常值），因子 Agent 会评估“因子有效性”（IC、衰减），策略 Agent 会评估“代码质量”（语法、逻辑），回测 Agent 会评估“过拟合风险”。也就是说，每个 Agent 都要对自己的产出负责。

**决策 4：异常处理走“fallback Agent”**

当某个 Agent 执行失败时，会触发 fallback Agent 重试，或者退回到“半自动”模式，由人工介入处理。这个机制可以保证整个系统不会因为某一个 Agent 出错就完全瘫痪。

## 十、踩过的坑

**坑 1：Agent 之间的“消息循环”**

策略 Agent 调用 `submit_to_backtest` 后，会触发回测 Agent；回测 Agent 完成后再触发报告 Agent。但如果策略 Agent 在等待回测结果时，又收到了用户的另一个问题，就会陷入“既要等待回测，又要处理新问题”的循环。后来我加入了“任务状态机”——每个 Agent 都有明确的“忙/闲”状态，忙碌时不接收新任务。

**坑 2：Agent 输出格式不统一**

不同 Agent 的输出格式如果不一致，下游 Agent 就很容易解析失败。后来我定义了一套“标准消息格式”（JSON Schema），要求所有 Agent 必须按这一格式输出。

**坑 3：Agent 之间的“信任问题”**

下游 Agent 不能无条件信任上游 Agent 的结果。比如策略 Agent 必须自己验证因子 Agent 提供的因子是否真实存在，不能默认上游一定正确。后来我增加了“交叉验证”机制，每个 Agent 在接收到上游结果后，都要做一次“事实核查”。

**坑 4：调试和监控困难**

多 Agent 系统的调试难度比单 Agent 至少高 10 倍。后来我补了一套“全链路日志”系统，记录每个 Agent 的输入、输出、思考过程和工具调用，并支持通过 Trace 视图回放完整流程。

## 十一、效果和未来

这套系统跑了大半年，我最大的几个观察和结论是：

1. **多 Agent 的“流水线协同”效率比单 Agent 高 3-5 倍**：每个 Agent 只做自己最擅长的事，整体处理效率提升非常明显。

2. **错误隔离效果更好**：单个 Agent 出错不会拖垮整个流程，通常只是某个局部环节失败。

3. **系统可扩展性很强**：新增一个 Agent（例如“风控 Agent”）就能为整个系统增加新能力，不需要重写其他 Agent。

未来我打算再增加两个 Agent：

- **“研报解读 Agent”**：自动阅读券商研报，提取核心观点，并判断观点可信度

- **“舆情监控 Agent”**：监控新闻、股吧、雪球等渠道的情绪指标，为策略提供“另类数据”支持

十二、最后说几句

多 Agent 系统的核心思想其实就是“专业化分工 流水线协作”。把复杂任务拆解成多个简单任务，每个任务交给专门的 Agent 去执行，最后再通过“消息总线”完成整体协同。

如果你也在考虑搭建多 Agent 系统，更稳妥的做法是先从 2 个 Agent 起步，比如“数据 Agent + 策略 Agent”。先把“消息传递”和“任务队列”这两条核心链路跑通，再逐步扩展到 3-5 个 Agent。不要一开始就把系统设计得过于复杂，因为多 Agent 的复杂度增长并不是线性的：2 个 Agent 时复杂度是 2，到了 5 个 Agent，复杂度就可能直接升到 20。

在工程实践里，最难的往往不是“怎么写 Agent”，而是“怎么让 Agent 之间稳定协作”。这份实践笔记重点记录的也是后者——前者网上资料很多，后者更多还是要靠自己不断踩坑、不断迭代。

资料参考：ig50","createTime":1786069716,"ext":{"closeTextLink":0,"comment_ban":1,"description":"","focusRead":0},"fa vNum":0,"html":"","isOriginal":0,"likeNum":0,