最近 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 有明确的"忙/闲"状态，忙碌时不接收新任务。

坑 2：Agent 输出格式不统一

不同 Agent 输出的格式可能不一致，导致下游 Agent 解析失败。

我后来定义了一套"标准消息格式"（JSON Schema），所有 Agent 必须按这个格式输出。

坑 3：Agent 之间的"信任问题"

下游 Agent 不能盲目信任上游 Agent 的输出。

比如主力 Agent 必须自己验证涨停板 Agent 提供的"真封板清单"是否真实存在。

我加了"交叉验证"机制。每个 Agent 接到上游输出后，都要做一次"事实核查"。

坑 4：调试和监控困难

多 Agent 系统的调试比单 Agent 难 10 倍。

我后来加了一套"全链路日志"系统，记录每个 Agent 的输入、输出、思考过程、工具调用。

这样可以用 Trace 视图回放整个流程。

十、效果和未来

这套系统跑了大半年，最大的几个发现：

• 多 Agent 的"流水线"效率比单 Agent 高 3-5 倍：每个 Agent 只做自己擅长的事，整体效率大幅提升。
• 错误隔离效果好：单个 Agent 出错不会影响整个流程，最多某个环节失败。
• 可扩展性强：新增一个 Agent（如"风险 Agent"评估封板风险）就能给整个系统增加新能力，不需要重写其他 Agent。

未来我打算加两个 Agent：

• "舆情 Agent"：监控新闻、股吧、雪球等渠道的情绪指标，给涨停板识别提供"另类数据"
• "回测 Agent"：自动做"历史样本回测"，验证涨停板识别规则的稳定性

十一、最后说几句

多 Agent 系统的核心思想是"专业化 流水线"。

把复杂的涨停板复盘任务拆分成多个简单任务。每个任务交给专门的 Agent 去做，最后通过"消息总线"协作完成整体目标。

如果你也想做多 Agent 系统，建议从两个 Agent 开始，比如"涨停板 Agent 主力 Agent"。

先把"消息传递"和"任务队列"跑通，再慢慢扩展到 3-4 个 Agent。不要一开始就设计太复杂的系统。

工程实践中最难的不是"怎么写 Agent"，而是"怎么让 Agent 之间协作顺畅"。

这套笔记重点记的是后者。前者网上资料很多，后者基本要靠自己踩坑。