# 多 Agent 协作做涨停板复盘：从封板识别到主力意图挖掘的全链路

最近 3 个月，我在本地搭了一套"多 Agent 协作的涨停板复盘系统"，把"涨停板识别、主力意图挖掘、次日表现预测、复盘报告输出"这 4 个环节分别交给不同的 Agent。今天把这套系统的工程实践笔记完整记录下来。

## 一、为什么需要多 Agent

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

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

- 上下文窗口很快爆掉（Qwen2.5-72B 是 32K）
- 任务规划混乱（一个 Agent 同时想"封板识别"和"主力意图挖掘"会陷入循环）
- 调试困难（一个 Agent 出错不知道是哪一步错的）

多 Agent 架构能彻底解决这三个问题。

## 二、整体架构

整个系统有 4 个核心 Agent：

```
┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ 涨停板 Agent │ → │ 主力 Agent │ → │ 预测 Agent │ → │ 报告 Agent │
└──────────┘    └──────────┘    └──────────┘    └──────────┘
   识别真假封板   挖掘主力意图    预测次日表现    输出复盘报告
```

每个 Agent 都有自己的"角色定位"和"工具集"。

## 三、涨停板 Agent

**角色定位**：从当日所有涨停板中识别"真封板"和"假封板"。

**核心工具**：
- `query_daily_boards`：查询当日涨停板列表
- `analyze_tick_data`：分析涨停板封板瞬间的逐笔数据
- `score_board_quality`：计算封板质量分数
- `is_fake_board`：判断是否为假封板

**输入**：当日日期（如 '20260808'）

**输出**：涨停板清单 + 真假封板标签 + 封板质量分数

**设计要点**：涨停板 Agent 必须能"自己评估"——它识别的真假封板必须自己跑一次回测验证（用过去 3 年的数据），发现准确率低的样本自动丢弃。这个"自检"机制让涨停板 Agent 的产出质量大幅提升。

**踩坑**：涨停板 Agent 容易"过度严格"——它会不断尝试更严格的识别规则，找到一个准确率高的规则就提交，但这个规则可能是"过拟合"。我后来加了"样本外测试"模块，要求每套新识别规则必须在训练集外的数据上再做一次检验，准确率衰减超过 30% 的会被标记为"可疑规则"。

## 四、主力 Agent

**角色定位**：从涨停板 Agent 输出的"真封板"中，挖掘主力意图。

**核心工具**：
- `analyze_main_inflow`：分析主力资金净流入
- `detect_washsale`：检测主力对倒
- `identify_main_seats`：识别主力关联席位
- `infer_main_strategy`：推断主力操作策略

**输入**：涨停板 Agent 的输出（真封板清单 + 封板瞬间数据）

**输出**：每只涨停板的主力意图标签（拉升/出货/震荡）

**设计要点**：主力 Agent 必须输出"可解释的主力意图"——它不能只给一个标签，必须给出"为什么是这个标签"的证据（如主力净流入 > 30% + 大单笔数占比 > 30%）。这个"可解释性"让我能快速验证主力 Agent 的判断是否合理。

**踩坑**：主力 Agent 容易"过度解读"——它会把一些"普通的主力行为"误判为"主力出货"。我后来加入了"主力意图边界"机制——只有"主力净流入 > 30% + 大单笔数 > 10"这种"明显的出货特征"才判为"主力出货"。

## 五、预测 Agent

**角色定位**：基于涨停板 Agent 和主力 Agent 的输出，预测涨停板次日表现。

**核心工具**：
- `query_history_kline`：查询历史 K 线
- `calculate_correlation`：计算因子相关性
- `predict_next_day`：预测次日表现
- `validate_prediction`：验证预测准确率

**输入**：涨停板 Agent + 主力 Agent 的输出

**输出**：次日高开/低开概率 + 5 日后预期涨幅

**设计要点**：预测 Agent 必须"独立运行"——它有自己的预测模型，不依赖其他 Agent。这样涨停板 Agent 和主力 Agent 的输出可以直接喂给预测 Agent，不阻塞上层流程。

**踩坑**：预测 Agent 的"过拟合"问题很严重——它在训练集上的预测准确率 75%，但在样本外的预测准确率只有 52%。我后来加了"样本外测试"模块，每次训练后必须在样本外做一次验证，准确率衰减超过 30% 的模型自动重新训练。

## 六、报告 Agent

**角色定位**：把前面 3 个 Agent 的产出汇总成最终的复盘报告。

**核心工具**：
- `generate_report`：生成复盘报告
- `generate_visualizations`：生成可视化图表
- `summarize_findings`：总结核心发现
- `export_to_pdf`：导出 PDF

**输入**：涨停板 Agent + 主力 Agent + 预测 Agent 的所有产出

**输出**：完整的涨停板复盘报告（Markdown / PDF 格式）

**设计要点**：报告 Agent 是"信息整合者"，它不做任何新的分析，只是把前面 3 个 Agent 的产出"结构化、可视化、可读化"。

**踩坑**：报告 Agent 容易"过度包装"——它会把所有数据都加进去，导致报告冗长。我后来加了"核心发现提取"模块，要求报告 Agent 先用 LLM 提炼出 3-5 个核心发现，再围绕这些发现组织报告。

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

4 个 Agent 之间不是简单的"流水线"，而是"消息总线 + 任务队列"。

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

**任务队列**：用 Celery 实现。耗时任务（如涨停板 Agent 的批量分析、预测 Agent 的回测）放进任务队列，异步执行。

**协作流程示例**：

用户提问："帮我复盘今日所有涨停板。"

1. 用户问题 → 涨停板 Agent（消息总线接收）
2. 涨停板 Agent 调用 `query_daily_boards` 拉当日涨停板
3. 涨停板 Agent 对每只涨停板调用 `analyze_tick_data` 和 `score_board_quality`
4. 涨停板 Agent 输出"真封板清单"（假设 8 只）
5. 涨停板 Agent → 主力 Agent（消息总线传递）
6. 主力 Agent 对 8 只真封板调用 `analyze_main_inflow` 和 `infer_main_strategy`
7. 主力 Agent 输出"主力意图标签"（拉升 5 只、出货 3 只）
8. 主力 Agent → 预测 Agent（消息总线传递）
9. 预测 Agent 对 8 只涨停板调用 `predict_next_day`
10. 预测 Agent 输出"次日表现预测"（高开 5 只、低开 3 只）
11. 预测 Agent → 报告 Agent（消息总线传递）
12. 报告 Agent 调用 `generate_report`，汇总所有产出，生成最终报告

整个流程大概 2-5 分钟（取决于数据量）。

## 八、关键设计决策

**决策 1：每个 Agent 有独立的上下文**

每个 Agent 不共享上下文，只通过消息传递"结果"。这个设计让每个 Agent 的 prompt 可以专门优化。

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

涨停板 Agent 的工具集是"涨停板识别工具"，主力 Agent 的工具集是"主力意图工具"，预测工具的"预测工具"，报告工具的"报告工具"。工具集不重叠，避免 Agent 调用越界的工具。

**决策 3：每个 Agent 都有"自我评估"机制**

涨停板 Agent 会评估"识别准确率"，主力 Agent 会评估"意图合理性"，预测 Agent 会评估"预测准确率"，报告 Agent 会评估"报告完整性"。每个 Agent 都对自己的产出负责。

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

当某个 Agent 失败时，会触发 fallback Agent 重新尝试，或退回到"半自动"模式（由人工介入）。

## 九、踩过的坑

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

主力 Agent 调用完 `infer_main_strategy` 后，会触发预测 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-4 个 Agent。不要一开始就设计太复杂的系统。

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

资料参考：ig50

最近 3 个月，我在本地搭了一套"多 Agent 协作的涨停板复盘系统"，把"涨停板识别、主力意图挖掘、次日表现预测、复盘报告输出"这 4 个环节分别交给不同的 Agent。今天把这套系统的工程实践笔记完整记录下来。

多 Agent 协作做涨停板复盘：从封板识别到主力意图挖掘的全链路

人工智能

多Agent协作涨停板复盘系统，通过封板识别、主力意图挖掘、次日预测及报告生成四环节流水线作业，实现高效自动化分析。系统采用消息总线与任务队列机制，确保各Agent独立运行、错误隔离，并支持可扩展架构。实战验证效率提升3-5倍，为量化复盘提供工程化解决方案。

代码解释

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

多 Agent 协作做涨停板复盘：从封板识别到主力意图挖掘的全链路-腾讯云开发者社区-腾讯云

多 Agent 协作做涨停板复盘：从封板识别到主力意图挖掘的全链路

多 Agent 协作做涨停板复盘：从封板识别到主力意图挖掘的全链路

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐