1. 从看盘靠感觉到决策有依据这套多 Agent 系统到底在解决什么做股票分析这件事绝大多数散户的日常是这样的早上刷几条财经新闻盘中盯着分时图心跳加速收盘后翻几个论坛帖子找安慰然后第二天继续凭感觉操作。这套流程最大的问题不是信息不够而是信息太多、太杂、太情绪化根本没有一个稳定的框架把数据采集—分析研判—决策执行—风险控制串起来。我搭这套多 Agent 股票分析模拟交易系统的出发点很朴素既然大语言模型已经能读懂财报、能写代码、能做逻辑推理那能不能让几个各司其职的 AI Agent 像一个小型投研团队一样协作一个负责收集和清洗数据一个负责基本面和技术面研判一个负责生成交易信号还有一个专门盯着风险敞口做否决更关键的是整个过程要能跑在模拟盘上不碰真金白银先把逻辑跑通、把坑踩完。这套系统适合谁参考如果你是有一定编程基础、对量化交易或 AI Agent 编排感兴趣的开发者或者你是做投研工具的产品同学想了解多 Agent 协作的落地形态再或者你只是想给自己的投资决策加一层纪律约束那这套东西的思路都能直接借鉴。它不承诺帮你赚钱——任何声称能稳定盈利的系统都值得警惕——它解决的是决策过程可复现、可追溯、可复盘的问题。核心逻辑其实就一句话把一个人的主观决策拆解成多个 Agent 的客观分工再用风控 Agent 做最后一道闸门。下面我会从架构设计、每个 Agent 的具体职责、Agent 之间的通信机制、风控模块的实现、模拟交易的回测验证以及我实际踩过的坑这几个维度把整套系统拆开讲透。2. 多 Agent 协作架构为什么不是一个大模型干所有事2.1 单 Agent 方案的三个致命短板我一开始也想偷懒直接写一个超长 Prompt让一个模型同时干数据获取、分析、决策、风控四件事。实测下来三个问题立刻暴露第一是上下文污染。当同一个模型既要记住原始行情数据又要记住自己刚才的分析结论还要在此基础上做交易决策时它很容易把分析和决策混为一谈输出的交易信号里掺杂着大量情绪化的定性描述比如考虑到近期市场情绪偏暖建议适度加仓——这种话对执行层毫无价值。第二是职责无法隔离。风控的核心价值在于独立否决权。如果风控逻辑和决策逻辑跑在同一个模型里模型天然倾向于为自己的决策辩护风控就形同虚设。这跟公司里财务和业务必须分设是一个道理。第三是可调试性极差。当最终交易结果不理想时你根本不知道是数据错了、分析错了还是决策错了。单 Agent 是一个黑盒多 Agent 至少能把每个环节的输出单独拎出来看。2.2 四个核心 Agent 的职责边界我最终确定的架构是四个 Agent 加一个协调器OrchestratorAgent 名称核心职责输入输出数据 Agent采集行情、财报、新闻做清洗和结构化股票代码列表、时间范围结构化数据包JSON研报 Agent基本面 技术面分析生成研判报告数据包带评分的研报文本交易 Agent根据研报生成具体买卖信号研报 当前持仓交易指令含价格、数量风控 Agent审核交易指令计算风险敞口交易指令 账户状态通过/否决/修改建议协调器不参与具体分析它只做一件事按顺序调度 Agent管理它们之间的消息传递并在风控否决时决定是回退给交易 Agent 重新生成还是直接终止本轮。2.3 Agent 之间怎么说话消息协议的设计多 Agent 系统最容易翻车的地方就是通信。如果让 Agent 之间用自然语言自由对话很快就会变成一团乱麻——A 说了一堆B 理解偏了C 又基于错误理解继续往下传。我的做法是强制结构化消息每个 Agent 的输出必须符合预定义的 JSON Schema。比如研报 Agent 的输出格式{ stock_code: 600XXX, analysis_date: 2025-01-15, fundamental_score: 7.2, technical_score: 6.5, key_findings: [营收连续三季度增长, MACD 金叉], risk_flags: [行业政策不确定性], recommendation: hold }交易 Agent 拿到这个结构后不需要去理解一段散文而是直接读取字段做判断。这样做的好处是每个环节的输出都可校验、可断言、可单元测试。我在每个 Agent 后面都加了一个 Schema 校验层格式不对直接打回重生成绝不让脏数据流到下游。提示Schema 校验这一步千万别省。我早期为了图快跳过了校验结果研报 Agent 偶尔会输出建议观望但如果明天放量则考虑介入这种带条件的模糊结论交易 Agent 直接懵了生成了一个数量为 0 的无效指令整个流程静默失败排查了半天才发现是格式问题。3. 数据 Agent把脏活累活做扎实下游才不背锅3.1 数据源的选型与取舍数据 Agent 是整个系统的地基。地基不稳上面盖什么都是危楼。我评估过几类数据来源行情数据日线级别的 OHLCV开高低收量是刚需我用的是公开的行情接口按交易日拉取本地缓存成 Parquet 文件。为什么不实时拉因为这套系统定位是日频决策不是高频交易每天收盘后跑一次就够了实时数据反而引入噪音。财务数据季度财报的关键指标营收、净利润、毛利率、ROE、资产负债率从公开财报接口获取。这里有个坑财报有报告期和披露期两个时间概念做回测时必须用披露期对齐否则就是用未来数据预测过去回测结果会虚高得离谱。新闻与公告这块我做得比较克制只抓取标题和摘要不做全文情感分析。原因后面踩坑部分会细说。3.2 数据清洗里那些不写出来就会踩的细节原始数据几乎没有能直接用的。我总结了几条清洗规则都是实打实踩出来的停牌和涨跌停的处理。停牌日的行情数据是缺失的不能简单用前值填充否则会制造出价格连续多日不变的假信号。我的做法是标记停牌日在技术指标计算时跳过。涨跌停日则要单独标记因为涨停时你根本买不进去回测里如果假设能成交结果就是自欺欺人。复权问题。分红送股会导致价格跳空必须用前复权或后复权数据。我用的是前复权因为回测时看的是如果当时买入现在的收益是多少前复权更符合这个视角。但要注意前复权数据在每次分红后都会变所以缓存要设置合理的过期策略。缺失值的分级处理。不是所有缺失值都能一视同仁。财务指标缺失可能是该公司不适用该指标行情缺失可能是停牌新闻缺失可能只是当天没新闻。我建了一个缺失值分类表不同类型走不同处理逻辑缺失类型处理方式理由行情 OHLCV 缺失标记停牌跳过指标计算避免制造假信号财务指标缺失用行业中位数填充并标记保留样本但提示不确定性新闻数据缺失置空不填充没新闻就是没新闻不能编3.3 数据 Agent 的输出契约数据 Agent 最终输出一个标准化的数据包包含三个部分行情矩阵、财务指标字典、新闻摘要列表。这个数据包会被序列化后传给研报 Agent。我特意在数据包里加了一个data_quality_score字段记录本次数据的完整度和新鲜度。研报 Agent 在分析时会参考这个分数如果数据质量太差它会主动降低结论的置信度甚至直接输出数据不足建议跳过。这个设计很关键。很多系统失败不是因为模型不够聪明而是因为在数据质量很差的情况下模型还在强行给出高置信度的结论。让 Agent 学会说我不知道比让它假装什么都知道要重要得多。4. 研报 Agent让 AI 写出有观点、有依据、有边界的分析4.1 基本面分析的 Prompt 工程研报 Agent 是整个系统里 Prompt 最复杂的部分。我的核心思路是不给模型自由发挥的空间而是给它一个分析框架让它往框架里填内容。基本面分析的 Prompt 大致是这样的结构先给模型一段角色设定你是一名注重安全边际的价值分析助手然后给出结构化的财务数据接着明确要求它从盈利能力、成长性、偿债能力、估值水平四个维度打分1-10 分每个维度必须引用具体数据作为依据最后汇总成一个综合评分。这里有个细节值得说我要求模型在打分时必须给出打分理由和反面证据。比如它给盈利能力打 8 分理由是ROE 连续三年高于 15%那反面证据可能是但毛利率同比下滑 2 个百分点。强制模型同时输出正反两面能有效抑制它的过度乐观倾向。4.2 技术面分析的指标选择技术面这块我没有堆砌一堆花哨指标只用了四个经典且互补的均线系统5 日、20 日、60 日均线的排列关系判断趋势方向。MACD判断动能和背离。RSI判断超买超卖。成交量配合价格判断信号有效性。为什么只用这四个因为指标越多信号冲突的概率越大模型在冲突信号面前很容易和稀泥。四个指标已经能覆盖趋势、动能、超买超卖、量价配合四个维度足够了。我让模型对每个指标输出看多/看空/中性三态判断最后统计看多指标数量映射成技术面评分。4.3 研报的置信度设计这是我觉得整套系统里最有价值的一个设计。研报 Agent 除了输出评分和结论还必须输出一个confidence字段0-1 之间。这个置信度不是模型随便拍的而是基于几个客观因素计算数据质量分来自数据 Agent基本面和技术面评分的一致性如果两者严重背离置信度降低是否有重大风险标记有则置信度打折置信度低于 0.5 时研报会明确标注低置信度建议仅作参考。交易 Agent 收到低置信度研报时会主动缩小仓位或直接观望。这个机制让系统在看不清的时候懂得收手而不是硬着头皮交易。注意置信度这个字段一定要让模型基于客观输入计算而不是让它感觉自己有多确定。我试过让模型自己评估置信度结果它几乎永远输出 0.8 以上完全没有区分度。改成基于客观因素计算后置信度才真正有了参考价值。5. 交易 Agent 与风控 Agent决策与约束的博弈5.1 交易 Agent 的指令生成逻辑交易 Agent 拿到研报后要做的是把观点翻译成动作。它的输出必须包含股票代码、买卖方向、委托价格、委托数量、以及一句话的决策依据。委托价格我采用的是次日开盘价 ± 滑点的模拟方式因为系统是收盘后运行的只能假设次日开盘成交。滑点设为 0.1%这是对流动性的保守估计。委托数量则基于仓位管理规则单只股票最大仓位不超过总资产的 10%单次交易金额不超过可用资金的 20%。这里的关键是仓位管理规则必须硬编码在交易 Agent 的逻辑里而不是交给模型判断。模型可以决定买不买但买多少必须由确定性规则控制。我见过太多系统让模型自由决定仓位结果模型一激动就满仓一恐慌就清仓完全失去了纪律性。5.2 风控 Agent 的三道闸门风控 Agent 是我花时间最多的模块因为它决定了系统的生存能力。它有三道闸门第一道单笔交易合规检查。检查交易指令是否违反基本规则——单只股票仓位是否超限、单日交易次数是否超限、委托价格是否在合理区间比如不能偏离前收盘价 ±10%。第二道组合风险检查。计算交易后的组合风险指标包括行业集中度、整体仓位水平、以及组合的波动率估算。如果某行业集中度超过 40%或者整体仓位超过 80%风控会否决或要求缩减。第三道回撤保护。这是最重要的一道。系统会跟踪账户的净值曲线如果从最高点回撤超过 15%风控会强制降低整体仓位上限如果回撤超过 25%直接进入只平仓不开仓模式。这道闸门的存在是为了防止系统在连续亏损后报复性交易。5.3 风控否决后的处理流程风控否决交易指令后不是简单地把指令丢掉而是走一个协商流程风控 Agent 会输出否决原因和修改建议协调器把建议回传给交易 Agent交易 Agent 根据建议重新生成指令再走一遍风控。这个循环最多执行两次两次都不过就放弃本轮交易。这个设计模拟了真实投研团队里基金经理和风控总监吵架的过程。区别在于AI 不会因为面子问题坚持错误决策它只会根据规则调整。实测下来大约 30% 的初始交易指令会被风控打回其中大部分经过一次调整后能通过少部分直接放弃。6. 模拟交易引擎让回测结果说真话6.1 模拟撮合的细节设计模拟交易引擎的核心是撮合逻辑。我采用的是次日开盘价成交模型但加了几个现实约束涨跌停不成交如果次日开盘就涨停买单不成交跌停则卖单不成交。停牌不成交停牌日所有指令挂起复牌后按复牌首日开盘价成交。成交量约束单笔委托量不超过该股当日成交量的 1%避免假设自己能吃掉整个市场。这些约束会让回测收益看起来没那么漂亮但它更接近真实。我见过太多回测年化 50% 的策略一上实盘就亏钱就是因为回测里假设了完美的成交条件。6.2 回测的评估指标我关注的不是单一收益率而是一组指标指标含义我的参考阈值年化收益率收益能力跑赢基准即可最大回撤最坏情况下的亏损控制在 20% 以内夏普比率单位风险的收益大于 1 算合格胜率盈利交易占比不追求高胜率40% 以上即可盈亏比平均盈利/平均亏损大于 1.5 才有意义为什么要看这么多指标因为单看收益率会骗人。一个策略可能年化 30%但最大回撤 50%这种策略实盘根本拿不住。夏普比率和最大回撤比收益率更能反映策略的可持有性。6.3 回测中最容易骗自己的三个地方第一幸存者偏差。如果股票池只选了现在还在上市的公司那些退市的、被并购的就被自动排除了回测结果会系统性偏高。我的做法是尽量用历史成分股虽然数据获取麻烦但这是必须的。第二参数过拟合。我一开始调参数调得很起劲把均线周期从 20 调到 18 再调到 22看哪个回测收益高。后来意识到这是在拟合历史噪音。现在我固定用经典参数5/20/60不做精细调优宁可牺牲一点回测收益换取更好的样本外表现。第三忽略交易成本。印花税、佣金、滑点这些加起来对高频策略是致命的。我的系统是日频交易频率不高但我仍然把双边 0.2% 的成本算进去。不算成本的回测都是耍流氓。7. 我实际踩过的坑那些文档里不会写的教训7.1 新闻情感分析我为什么最终放弃了一开始我给数据 Agent 加了新闻情感分析抓取财经新闻标题做情感打分喂给研报 Agent。跑了一段时间发现新闻情感和短期股价的相关性极低甚至是负相关。原因很简单好消息出来时往往已经涨过了坏消息出来时往往已经跌过了。更麻烦的是新闻情感分析本身噪音极大公司获得政府补贴这种明显利好模型有时会判成中性。最终我把新闻模块降级为只提供标题列表不做情感打分让研报 Agent 自己判断哪些新闻重要。这样反而更稳因为模型在具体语境下判断新闻重要性比一个孤立的情感分数靠谱。7.2 Agent 之间的死循环有一次系统跑着跑着卡住了排查发现是交易 Agent 和风控 Agent 陷入了死循环交易 Agent 生成指令风控否决交易 Agent 调整后重新生成风控又否决如此往复。原因是我最初没设循环上限。修复方案很简单加一个最大重试次数我设的是 2 次超过就放弃。但这个坑让我意识到多 Agent 系统必须有熔断机制任何循环都要有明确的退出条件否则一个逻辑漏洞就能让整个系统挂死。7.3 模型输出的格式漂移即使我定义了严格的 JSON Schema模型偶尔还是会输出格式不对的内容比如把数字写成字符串、把数组写成逗号分隔的文本、或者在 JSON 外面包一层解释性文字。我的应对是三层防护第一层是 Prompt 里反复强调格式要求第二层是输出后用正则提取 JSON 部分第三层是 Schema 校验不通过就重试。三层下来格式问题的发生率从最初的 15% 降到了 1% 以下。7.4 回测跑通不等于实盘能跑这是最深刻的一个教训。我的回测在历史数据上表现不错但当我把它接到实时数据流上做模拟盘时问题全出来了数据接口偶尔超时、财报数据更新延迟、模型 API 有速率限制。回测是一个确定性环境实盘是一个充满意外的环境。回测验证的是策略逻辑实盘验证的是工程健壮性两者缺一不可。8. 如果你想自己搭一套我的实操建议8.1 从最小可用版本开始别一上来就搞四个 Agent。我的建议是先搭数据 Agent 交易 Agent两个跑通数据进来、指令出去的最短路径。等这条路径稳定了再加研报 Agent 做分析增强最后加风控 Agent 做约束。每加一个 Agent都要确保前一个环节的输出是稳定的否则问题会层层放大。8.2 把可观测性当第一优先级多 Agent 系统最怕的就是不知道哪里出了问题。我从第一天起就做了完整的日志记录每个 Agent 的输入、输出、耗时、以及中间状态全部落盘。每次运行生成一个 trace ID所有日志按 trace ID 关联。这样出问题时我能精确复现是哪一步、哪个 Agent、哪个字段出了问题。没有可观测性调试多 Agent 系统就是盲人摸象。8.3 风控规则要保守到让自己不舒服设计风控规则时人的本能是这个规则会不会太严了会不会错过机会。我的经验是宁可错过不可做错。风控规则严一点最多是少赚风控规则松一点可能是巨亏。我现在的单票仓位上限是 10%行业集中度上限 40%整体仓位上限 80%回撤 15% 降仓、25% 停开仓。这些数字看起来保守但正是它们让系统在极端行情下活了下来。8.4 定期做压力测试我会定期用历史极端行情比如某次大幅下跌、某次流动性枯竭去跑系统看它在极端情况下的表现。压力测试的目的不是看它赚多少而是看它亏多少、能不能扛住。一个策略在正常行情下表现再好如果扛不住极端行情那它就是个定时炸弹。9. 关于这套系统我最后想说的几句实在话搭这套系统的过程与其说是在做量化交易不如说是在做决策工程。它逼着我把模糊的投资直觉拆解成明确的规则把我觉得变成数据显示把应该没事变成风控允许。这个过程本身比系统最终赚不赚钱更有价值。我也必须坦诚地说这套系统目前的定位是辅助决策工具和逻辑验证平台不是自动赚钱机器。AI Agent 在结构化分析、纪律执行、风险监控上确实比人强但在理解市场情绪、捕捉突发事件、判断政策转向这些方面它仍然有明显的局限。把它当成一个不知疲倦、不带情绪的助手而不是一个能预测未来的先知这个心态很重要。如果你打算动手我的建议是先用模拟盘跑至少三个月把各种边界情况都跑出来把日志翻烂把风控规则调到你认为过于保守的程度。等它在模拟盘上稳定运行、你对它的每一个决策都能解释清楚之后再考虑下一步。能解释清楚每一个决策是这套系统最大的价值也是它区别于黑盒策略的根本所在。