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

最近半年，我在本地搭了一套"多 Agent 协作的股票研究系统"，把"数据采集、因子挖掘、策略生成、回测验证、报告输出"这 5 个环节分别交给不同的 Agent。今天把这套系统的工程实践笔记完整记录下来，重点讲"为什么需要多 Agent"和"Agent 之间怎么协作"。

## 一、为什么需要多 Agent

做股票研究这件事，一个人做太累，团队做太慢。最理想的状态是"流水线作业"——每个人（或每个 Agent）只负责一个环节，上一环节的输出是下一环节的输入。

我尝试过用"单 Agent 干所有事"，结果是：

- 上下文窗口很快爆掉（Qwen2.5-72B 是 32K）
- 任务规划混乱（一个 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 可以轮询或订阅结果。

## 四、因子 Agent

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

**核心工具**：
- `list_existing_factors`：列出已有因子库
- `add_factor`：添加新因子
- `test_factor`：单因子检验（IC、收益、回撤）
- `analyze_factor_decay`：分析因子衰减
- `correlate_factors`：因子相关性分析

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

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

**设计要点**：因子 Agent 必须能"自己评估"——它生成的因子必须自己跑一次单因子检验，发现 IC 太低的因子自动丢弃。这个"自检"机制让因子 Agent 的产出质量大幅提升。

**踩坑**：因子 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 的 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 会陷入"既要等回测，又要回新问题"的循环。我后来加了"任务状态机"——每个 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 系统，建议从两个 Agent 开始（比如"数据 Agent + 策略 Agent"），先把"消息传递"和"任务队列"跑通，再慢慢扩展到 3-5 个 Agent。不要一开始就设计太复杂的系统——多 Agent 的复杂性增长是非线性的，2 个 Agent 复杂度是 2，5 个 Agent 复杂度是 20。

工程实践中最难的不是"怎么写 Agent"，是"怎么让 Agent 之间协作顺畅"。这套笔记重点记的是后者——前者网上资料很多，后者基本要靠自己踩坑。

资料参考：ig50

最近半年，我在本地搭了一套"多 Agent 协作的股票研究系统"，把"数据采集、因子挖掘、策略生成、回测验证、报告输出"这 5 个环节分别交给不同的 Agent。今天把这套系统的工程实践笔记完整记录下来，重点讲"为什么需要多 Agent"和"Agent 之间怎么协作"。

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

人工智能

开发工具

后端

多Agent协作股票研究系统通过数据、因子、策略、回测、报告五大Agent流水线作业，实现上下文隔离与工具集切分，提升效率3-5倍。采用消息总线与任务队列机制，配合自我评估和交叉验证，解决单Agent上下文爆掉、规划混乱等痛点，支持异步执行与错误隔离，具备强扩展性。

代码生成工具

消息队列

数据接口

代码解释

Python

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

多 Agent 协作做股票研究：我的全链路工程实践笔记-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐