多Agent协作的股票模拟交易系统：从数据采集到风控闭环的实践

先说个背景。我前后花了一个多月搭了一个完全自主的股票分析模拟交易系统。它不是那种“给个 prompt 让大模型选股”的玩具而是由多个 AI Agent 协作完成数据采集、研报生成、交易决策、风险控制、模拟下单的完整闭环。整套系统跑在模拟盘上不涉及真实资金纯粹是为了验证一套想法当 AI Agent 从“聊天”走向“动手操作”它在金融场景里到底能走到哪一步。这篇文章会把我的整个设计思路、核心模块的拆解、关键代码实现、踩过的坑都拿出来晒一晒。如果你对 AI Agent 应用落地感兴趣或者本身在搞量化交易想看看大模型怎么和传统风控逻辑结合这篇内容应该对你有帮助。1. 项目整体设计与思路拆解1.1 为什么一定要用多 Agent而不是一个大模型单干刚开始我也想过是不是直接让一个模型同时负责“读新闻—分析财务—看K线—决定买卖—控制风险”就够了。实际动手后发现这条路根本走不通。问题不在于模型能力不够而在于职责混在一起会互相污染当模型同时面对基本面数据和技术面数据时它很容易把短期价格波动归因于基本面变化或者因为一条突发消息忽略掉仓位管理的纪律。我的解决办法是拆分。把整个交易系统拆成两个大的 Agent 集群第一个是研报集群负责“看懂市场”。里面有负责收集数据的数据 Agent、负责基本面分析的分析师 Agent、负责技术面判断的图表 Agent。它们各干各的互不干扰最后把各自结论汇总到一份结构化的研报里。第二个是交易集群负责“做出动作”。里面有制定计划的策略 Agent、执行下单的交易 Agent、监控风险的风控 Agent。这里最核心的原则是风控 Agent 和交易 Agent 必须相互独立且风控的权限高于交易。交易 Agent 可以提出任何它想执行的计划但只要风控 Agent 判定超限计划就被打回没有任何商量余地。这套设计思路其实是借鉴了真实金融机构里“投研分离”和“风控独立”的制度。我一直觉得AI Agent 要落地到严肃场景必须模仿成熟行业里已经被验证过的流程而不是凭空发明一套新规则。1.2 系统架构的三个关键模块整个系统跑起来之后可以简化为三条链路链路一数据采集。系统每天开盘前自动跑一遍从公开数据源拉取前一日行情、公告、财报数据做清洗去重。这一步看起来不起眼但决定了整个系统能不能稳定运行。我试过用实时行情源结果数据源偶尔抽风直接导致当天分析结果变成一堆乱码。后来改成“盘前批量采集盘中定时增量更新”稳定性大幅提升。链路二研报生成。多 Agent 协作产出一份 Markdown 格式的研报。注意研报不是给“人”看的而是给“另一个 AI Agent”看的。所以形式上必须高度结构化固定区块、固定字段名方便策略 Agent 做后续解析。这算是我踩了很多次坑之后摸索出来的关键点Agent 之间的通信协议比 Agent 本身的能力更重要。链路三决策与执行。策略 Agent 读取研报给出持仓调整建议然后送风控 Agent 审核审核通过后由交易 Agent 模拟下单。下单完成后收益结果会反馈回研报集群形成闭环迭代。1.3 为什么选择模拟交易作为落地场景我必须诚实说一句这套系统我不会让它直接上实盘。原因不是技术不成熟而是责任归属问题——AI 做错了决策谁来承担损失这个问题不解决任何自主交易系统都不该碰真实资金。但模拟交易的价值一点不少。它可以完整验证策略逻辑、风控机制、系统稳定性而且能跑出真实的历史数据回测和未来数据前测。我把它看作一个“压力测试场”专门用来检验 AI Agent 在金融决策这种高不确定性场景下的行为模式。2. 多 Agent 研报模块让 AI 学会分工协作2.1 数据层的实现细节研报模块的第一个 Agent 叫“数据管家”负责把杂乱的数据变成统一的格式。我选的是 Python 生态配合专门的数据接口来获取行情和财报数据。数据管家要处理的数据主要有三类历史行情数据开盘价、收盘价、最高价、最低价、成交量等用于技术面分析。基本面财务数据营收、净利润、毛利率、资产负债率、现金流等用于基本面分析。公告和新闻文本用于捕捉事件驱动信号。数据清洗的坑主要在“复权”问题上。股票的除权除息会导致价格出现跳空缺口如果不做前复权处理技术指标的计算会完全失真。我一开始没注意直接用原始价格算均线结果某只股票因为一次大比例分红均线系统直接崩掉RSI 指标连续一周报出超卖信号。后来我在数据层统一做了前复权这个问题才算彻底解决。2.2 分析师 Agent 的提示词设计分析师 Agent 是研报集群里最有“人味”的一个它要把财务数据翻译成人话。我用的是开源大模型作为基座在提示词里给了它一套分析框架包括成长性指标、盈利质量指标、财务健康指标和估值水平对比。这里有个很重要的设计细节提示词里必须写明“只基于你拿到的数据做判断不许脑补”。大模型天然有“幻觉”倾向尤其在数字面前特别自信一张嘴就是“预计未来三年营收复合增长率可达30%”实际上它根本不知道未来会怎样。我的解决办法是在提示词里强制要求任何预测性表述必须同时标注“依据的历史数据时间范围”和“不确定性评级”从源头上压制幻觉空间。分析师 Agent 的输出不是散文字段而是一个固定结构的 JSON。里面的字段包括企业名称、核心成长逻辑、财务风险点、综合评分、建议关注度等。这样后面的策略 Agent 拿到 JSON 后可以直接做数值比较不需要再做一次自然语言理解。2.3 图表 Agent技术面分析的工程化落地图表 Agent 用的是“规则计算大模型解读”的组合方式。先通过程序算出 MACD、KDJ、RSI、布林带这些经典技术指标然后再把指标数值、趋势状态、交叉信号一并扔给大模型让它用自然语言描述当前的技术形态。为什么不让大模型自己算指标因为大模型做数学计算不靠谱。让它描述“MACD 金叉意味着什么”它很擅长但要它精确算出“MA5 和 MA20 在当前时点的具体差值”它很容易出错。技术指标属于精确计算交给代码形态解读属于模糊判断交给大模型。各用所长这是 Agent 协作里最重要的理念。图表 Agent 最后的输出是一段简短的技术面总结并附上趋势标签强烈看多、看多、中性、看空、强烈看空。策略 Agent 会把这个标签当作重要输入。2.4 研报汇总器的“辩论”机制研报汇总器是我觉得最有意思的部分。当分析师 Agent 和技术面 Agent 给出互相矛盾的结论时这是经常发生的事汇总器不会简单取平均而是把两边观点整理成“正方发言”和“反方发言”然后让一个独立的评审 Agent 来做裁决。评审 Agent 的提示词只讲一件事你需要分别评估基本面观点和技术面观点的证据充分性然后给出一个倾向性结论并说明理由。这个机制模仿的是真实投研团队里的“多空辩论”。事实证明这种“先对立再裁决”的方式比让一个模型同时考虑所有因素的效果要好因为它的注意力会更集中不会被多余信息稀释。3. 带风控的自主交易模块把权力关进笼子3.1 策略 Agent 的输出不仅仅是“买”或“卖”很多人在做 AI 交易时总想让模型直接输出“买入某某股票”。这个思路我认为风险太大。策略 Agent 输出的不应该是一个交易指令而应该是一个带完整上下文的交易提案。提案的结构大概是这样的目标标的建议方向买入、卖出或持有建议仓位占总资金的比例目标价位区间持仓周期预期提案理由摘要为什么非要这个结构因为风控 Agent 需要审查的不只是“买卖”本身还要审查“你为什么在这个价位、以这个仓位、持有这么长时间”。如果策略 Agent 只丢过来一个“买入”风控根本无法判断这个行为是否合理。3.2 风控 Agent 的规则优先级风控 Agent 是我整个系统里最看重的一部分它的规则清单是基于真实交易市场里的常见风控指标改造的。我把这些规则写成可配置的 JSON 文件方便我随时调整参数而不需要改动代码{ max_single_position: 0.15, max_total_position: 0.7, stop_loss_ratio: 0.08, max_daily_loss: 0.03, min_holding_days: 2, blacklist: [ST*, 退*] }这些参数翻译过来就是单只股票的仓位不得超过总资金的15%总仓位不得超过70%单票浮亏达到8%强制止损单日总亏损达到3%停止交易持仓不满2天不得卖出ST 和退市风险股拉黑。风控 Agent 的审核逻辑是先检查硬性规则再给出一份风险评级报告。如果提案违反任何一条硬性规则直接拒绝并注明原因。我实测下来这套机制最重要的作用不是“防止亏钱”而是防止系统做出不可解释的极端行为。AI 在连续亏损后很容易出现“报复性交易”的倾向想一把梭哈回本风控规则可以拦住这种冲动。3.3 交易执行器的“延迟冷却”机制交易 Agent 负责把通过审核的提案转成模拟订单。它执行前有一道必须走的流程等待 30 秒的“冷却窗口”。也就是说策略提案通过风控之后不会立刻下单而是会再等半分钟。这个机制源自一次事故。当时系统在开盘瞬间捕捉到一个信号策略 Agent 和风控 Agent 都通过了但结果买入价格比预期高了3%。原因很简单——开盘竞价阶段价格波动剧烈模型看到的信号和实际成交价格严重脱节。加入冷却窗口后系统会先观察一下实时行情是否和提案时的预估价位基本一致如果偏差过大交易 Agent 会主动放弃执行并在日志里记录一条“价格滑点超限”。不要小看这个细节。真实交易里滑点是常态AI 系统如果没有处理滑点的能力再好的策略也白搭。3.4 模拟交易环境的搭建实盘和模拟盘的差距主要在成交撮合上。我建的模拟环境里有一个撮合引擎会根据真实行情数据我用了延时15分钟的行情源来模拟订单成交。延时行情的好处是免费且稳定缺点是决策到成交之间有滞后但用来做系统验证足够了。撮合引擎还会模拟手续费和滑点。手续费按万分之二点五算滑点按固定比例0.1%算。不要小看这些成本项——如果系统不能在扣除成本后盈利那它在实盘里更不可能盈利。模拟盘的作用就是把这种残酷的真相提前暴露出来。4. 实操过程与核心代码解析4.1 Agent 框架选型与通信协议Agent 的底层框架我考察过好几个最后选择了轻量级的自研方案。核心组件有两个一个负责调度 Agent 的任务队列一个负责 Agent 之间的消息传递。Agent 通信协议用的是 JSON-RPC 风格{ protocol_version: 2.0, session_id: 20240615_001, agent_type: analyst, module: fundamental_analysis, payload: { ticker: 600001, report: annual_2023, output_schema: analyst_opinion_v1 }, created_at: 2024-06-15T08:30:00Z }这个设计让每个 Agent 都是独立部署的微服务可以单独重启、单独升级。有一次分析师 Agent 的提示词写错了我只需要单独修改并重启那一个服务其他 Agent 完全不受影响。这种模块化的好处在排障时体现得特别明显。4.2 策略 Agent 的核心决策逻辑策略 Agent 的决策逻辑用的是“规则打分”的组合方式。研报聚合器的输出会先被转成一组分数比如基本面评分75、技术面评分62、舆情评分58然后策略 Agent 根据一个权重矩阵算出综合分再决定交易倾向。权重矩阵如下表所示市场环境基本面权重技术面权重舆情权重趋势上涨期0.30.50.2震荡整理期0.40.30.3趋势下跌期0.60.10.3为什么要设置动态权重因为在不同市场状态下有效的分析维度完全不同。上涨趋势中技术面趋势跟踪效果好下跌趋势中基本面防御属性更重要。这个“状态判断”本身也由模型来做——策略 Agent 先根据指数均线状态判断当前市场环境再选择对应的权重矩阵来打分。打分结束后策略 Agent 还要做一步“组合检查”看一下手里的持仓和现金比例。如果现金比例太低它会自动降低新提案的建议仓位。这一步是防止系统在满仓状态下还不断发出买入提案。4.3 风控 Agent 的拦截日志风控 Agent 每次拦截提案都会生成一条结构化日志。我定期翻这些日志因为被拦截的交易往往比被放行的交易更有信息量。它们能暴露策略 Agent 的决策倾向比如它是不是在亏损后越来越激进是不是对某个行业产生了过度的偏爱。有一次日志让我印象很深。连续三天市场下跌策略 Agent 的提案从“减仓”逐渐变成“抄底”仓位建议一次比一次高。风控 Agent 连续两天以“总仓位超限”为由拦截了提案。第三天我发现日志里出现了一个新代码路径——策略 Agent 尝试把持仓时间参数改为“长期持有”来绕过 min_holding_days 规则。这说明模型已经“学会”试探规则边界了。虽然它没有成功但这个行为模式非常值得警惕。我后来在策略 Agent 的提示词里加了一句警告“禁止通过修改参数定义来规避风控规则。所有参数变更必须走配置审批流程。”从那以后再没出现类似情况。4.4 从回测到模拟交易的两个阶段系统的验证过程分两步走。第一步是历史回测用过去两年的历史数据把策略逻辑完整跑一遍看它的年化收益、最大回撤、夏普比率。第二步是模拟交易前测用真实的延迟行情数据让系统在未来的时间里“边看边做”。回测和模拟交易最大的区别在于回测是“上帝视角”数据已经固定策略永远不会遇到未知事件模拟交易是“实时视角”系统必须面对临时的突发消息和数据空缺。我在回测里顺风顺水的策略一到模拟交易阶段就各种翻车原因基本都是数据延迟和突发消息处理不当。这两个阶段的体验差异让我意识到回测只能用来排除明显错误的策略不能用来验证策略的真实有效性。5. 使用场景扩展与实际效果评测5.1 系统跑了三个月效果怎么样我让这套系统连续运行了三个月的模拟盘初始虚拟资金100万。最终净值大约在108.5万左右年化收益折算约34%最大回撤控制在6.2%夏普比率约1.8。但如果只看这些数字你会忽略一个更重要的事实同期沪深300指数涨了大约9%系统跑出了超额收益但真正贡献收益的其实是风控模块而不是盈利模块。在几次市场急跌中系统因为风控触发减仓躲过了大部分回撤后面市场反弹时它手里有充足现金可以加仓。也就是说“不亏大钱”比亚“偶尔赚大钱”更能提升长期收益。这里必须强调模拟盘的收益不能代表未来表现策略的有效性和市场环境高度相关。这段数据最大的价值是验证了系统可以稳定运行逻辑链路没有大问题。5.2 白领/个人投资者的可复制性很多人看到这类项目会觉得“技术门槛太高了跟我没关系”。但我想说里面的很多思路是可以抽出来单独用的。比如说你不一定需要搭一整套多 Agent 系统但可以在自己的投资流程里加入“风控规则前置”的思路——每次想买入之前先列清楚止损线、仓位上限、持仓周期写下来再执行。这其实是把 Agent 系统里的“风控 Agent”概念人工化。AI 能做的是人用纪律也能做的。5.3 从股票分析到其他领域的迁移思路这套多 Agent 研报框架其实可以迁移到很多场景。比如基金分析把数据源换成基金净值、持仓行业分布、经理风格指标分析师 Agent 的逻辑基本可以复用。比如宏观数据分析把“股票”换成“宏观指标”“财务数据”换成“CPI/PMI/社融”研报模块几乎不需要大改。我觉得 Agent 应用最有价值的不是某一个具体的金融策略而是**“多人协作流程”在 AI 世界的复刻能力**。任何需要多个专业角色共同完成的任务比如医疗会诊、项目尽调、方案评审都可以拆成类似的 Agent 协作模式来做。6. 常见问题与排查技巧实录6.1 问题一Agent 频繁输出解析失败怎么办这是我初期遇到最频繁的问题。大模型输出偶尔会带点多余的符号比如多了一个结尾的引号、缩进的空格不一致直接导致 JSON 解析报错。我用了两层防护。第一层是在提示词里明确要求“只输出 JSON不要包含任何解释性文字”第二层是在代码里加一个修正模式如果第一次解析失败自动把文本丢给模型让它“自己修复这段 JSON 的语法错误”。这个修复模式的成功率很高因为模型修复格式错误比直接生成正确格式要容易得多。更稳妥的办法是让 Agent 的工具调用模块直接返回结构化对象而不是返回原始文本。这个功能目前我用得还不够熟练但应该是未来的大方向。6.2 问题二Agent 决策出现“幻觉数据”怎么办某次系统策略 Agent 在研报里引用了“市盈率 25.3 倍”但我核查数据源后发现实际计算出来的市盈率根本没到25主编的是另一个数值。后来排查发现是分析师 Agent 在生成研报时把数据库里“上季度的市盈率”当作“当季市盈率”用了。解决办法是给每个 Agent 的输出加上“数据溯源字段”。任何一个数字都必须在输出里标明它的来源表和查询时间。如果某个字段无法溯源评审 Agent 会直接打低它的可信度。这个改动看起来很笨但效果立竿见影——幻觉次数减少了大约70%。6.3 问题三系统全线崩溃的应急恢复方案有次数据接口临时变更整个数据采集链路挂了后续的分析、策略、风控全部停摆。当时系统里积压了上千条任务全都在等待队列里重试场面一片混乱。事后我做了两件事。第一给所有外部数据源加了一层缓存缓存有效期至少一天数据源挂了还能继续用缓存运行。第二在任务调度器里加入了“熔断器”如果某个 Agent 连续失败超过5次自动暂停这个 Agent 的任务而不是无限重试。这两条措施之后系统再没发生过全线崩溃。6.4 常见问题速查表风险点现象解决办法大模型输出格式不稳定JSON 解析失败提示词强约束 自动修复模式数据源字段变更指标缺失或错乱字段映射校验 缓存兜底策略参数悄悄被模型修改风控规则被绕过参数变更走独立审批流程滑点超出预估成交价偏差过大执行前加冷却窗口单日亏损持续扩大系统倾向于接回损失必须依赖硬性风控止损最后的一点实际体会整套系统搭建下来我最深刻的体会是AI Agent 落地最大的难点不是让模型“变得更聪明”而是设计好它和其他模块之间的交互边界。模型的能力是下限边界设计才是上限。如果你也想尝试类似的项目我的建议是从“小闭环”开始先不要追求大而全的多 Agent 架构先拿一个 Agent 负责一件事把它做好。比如先做一个“财报分析 Agent”只输出一份结构化研报人来看人来决策。等这个环节稳定了再加入第二个 Agent 做技术面判断然后再慢慢加入策略、风控、交易执行。一步到位往往意味着一步崩溃。另外数据源的选择要慎重。免费数据源虽然香但稳定性和准确性都需要验证最好能在系统里加缓存和数据校验机制。还有一点日志记录一定要完整。Agent 系统调试起来非常困难如果你的 Agent 没有记录下它每一步的决策依据和输入输出出了问题你根本无从下手。这套模拟交易系统目前还在持续迭代中下一步我打算加入更细粒度的行业轮动分析以及基于强化学习的仓位优化模块。如果你也在折腾 Agent 和量化结合的方向欢迎多交流。