最近我一直在折腾一个比较“费钱费时间”的方向用 AI Agent 搭一套完整的股票分析模拟交易系统。起因很简单——我发现市面上的 AI 炒股助手大多是“聊天窗口 行情接口”的缝合怪你问一句它答一句既不会主动盯盘也没有完整的决策闭环。与其天天羡慕别人的 Agent 项目能跑通不如自己从零搭一套从多 Agent 生成研报到带硬性风控的模拟自主交易把整条链路走完。这篇文章就把完整的搭建过程、架构设计、关键代码逻辑以及三周模拟盘运行里翻车的真实案例都写出来。如果你是正在折腾 AI Agent 应用、又想了解金融场景落地的开发者这篇文章应该能省你不少试错时间。先说清楚整套系统跑在模拟资金池上所有数据和分析只用于技术验证不构成投资建议。1. 为什么我要用多 Agent 拆解而不是让一个大模型全干1.1 股票研报分析的本质是一条决策链最开始我偷懒试着把整份研报任务丢给一个超长上下文的单一大模型结果惨不忍睹。事后我才想明白一个道理股票分析根本不是“一次问答”而是一条需要不同视角交叉验证的决策链。基本面要看财务报表的利润、营收、负债还要理解行业格局技术面要看均线趋势、成交量、MACD 这些完全不同的数据形态消息面要读公告、新闻、政策判断情绪方向最后还要把这些互相矛盾的信息合成一个动作建议。这些环节的“信息类型”完全不同。基本面用的数据是季度级的报表技术面用的是分钟级的行情舆情面用的是一堆非结构化文本。它们的时间窗口不同、量化口径不同、甚至需要调用的工具都不同。让一个 Agent 在同一上下文里同时处理这些等于让一个人既当会计又当时盘操盘手还兼着新闻编辑上下文一长必然出问题。1.2 单 Agent 的典型翻车现场我最早那个单 Agent 方案最常犯的错是“角色混乱”。比如我让它同时分析市盈率和 MACD 金叉它居然能把两套系统混在一起输出类似“该股票基本面良好技术面出现金叉MACD 代表长期盈利增长强劲”这种话——MACD 是什么它是个动量指标跟长期盈利没有半毛钱关系。更常见的翻车是上下文污染。让它分析 A 公司的财报再紧接着让它看 B 公司的技术图形它经常会把两家公司的数据混着用甚至出现“该股票连续三年营收增长同时近期成交量放大”这种张冠李戴的结论。这个问题的本质不是模型不够聪明而是单一 Agent 的任务边界太宽超出它的有效注意力范围。我试过用更强的模型、更长的 prompt、更详细的 few-shot效果都很有限。1.3 多 Agent 的真实优势在于工程可控后来我换成了多 Agent 分工四个角色各干一摊事数据 Agent 负责把原始数据整理成干净的结构化数据研报 Agent 负责基于结构化数据生成观点风控 Agent 负责检查硬性约束交易 Agent 负责最后决策和动作生成。好处不是“更智能”而是工程上完全可控。每个 Agent 都只面对一类数据、只回答一个问题prompt 可以针对性优化输出格式可以用统一的 JSON Schema 约束一个环节出了问题重跑这个 Agent 就行不用整条链路全部重来。比如技术面 Agent 的模型偶尔输出不稳定我只换这一个 Agent 的模型不用动其他环节。这套拆法还有一个隐性收益调试体验好。单 Agent 方案里你不知道是 prompt 的问题还是上下文的问题多 Agent 方案里每个环节的输入输出都可单独检查出 bug 半小时内能定位到具体角色。2. 整体骨架四类 Agent 加一个调度中枢2.1 系统组成与数据流整套系统我取名“模拟项目 X”结构不复杂就是一个管道式的多 Agent 协作流数据 Agent 先从数据源抓取行情、财报、新闻做完清洗和复权后落库。然后研报 Agent 基于数据库里的结构化数据并行做基本面分析和技术面分析分别产出两份独立观点。这两份观点交给汇总 Agent 合并成一份研报包含综合评级和风险提示。交易决策 Agent 拿到研报后结合当前持仓和账户状态给出建议动作。风控 Agent 对动作做硬性校验通过的订单才交给模拟执行器去成交。我整理了一张表把这套流程的输入输出和职责说清楚环节输入输出核心职责数据 Agent原始接口数据清洗后的结构化数据复权、去重、格式统一基本面 Agent财务数据 公告基本面评分和观点分析盈利、成长、估值技术面 AgentOHLCV 行情数据技术面评分和观点分析趋势、量能、均线汇总 Agent两份观点综合研报观点冲突仲裁、生成评级交易 Agent研报 持仓 风控状态带理由的交易动作最终决策和下单意图风控 Agent交易动作 账户状态放行/拦截硬性风控规则检查模拟执行器通过风控的订单成交回报模拟撮合、手续费、滑点这个流程看起来是串行的但实际运行中基本面 Agent 和技术面 Agent 是并行跑的因为它们的数据源互不依赖并行能把单次全链路分析的时间从 3 分钟压缩到 40 秒左右。2.2 调度中枢用事件驱动替代链式调用一开始我写的是最简单的链式调用A Agent 跑完传给 B Agent。跑了几次就发现问题任何一个环节超时或者报错整条链路就断了而且断点恢复很麻烦。后来我改成了事件驱动的调度方式。每个 Agent 完成工作后把自己的产出写入中间存储并发布一个事件下游 Agent 订阅到自己关注的事件类型后从存储里取数据继续处理。这样每个环节都是独立的失败可以单独重放上游数据和下游状态完全解耦。调度状态机的核心逻辑很简单核心思想就是维护一个任务状态字典TASK_STATES { data_ingest: {next: [fundamental, technical], retry: 3}, fundamental: {next: [merge], retry: 2}, technical: {next: [merge], retry: 2}, merge: {next: [decision], retry: 2}, decision: {next: [risk_check], retry: 2}, risk_check: {next: [executor], retry: 0}, executor: {next: [], retry: 0}, }每个任务节点定义清楚下游节点和重试次数调度器根据状态流转执行。失败的任务如果超过最大重试次数就进入死信队列人工介入检查。这套机制在很多现成的 Agent 框架里都有概念但自研的好处是我能看到每一步到底发生了什么而不是把整个链路的控制权交给一个黑盒。2.3 技术栈选型为什么不用重型 Agent 框架技术栈我用的是 Python 3.11数据存 SQLite 和 PostgreSQLSQLite 负责本地缓存PostgreSQL 负责需要并发读写的核心数据。调度器是自研的写了几百行代码没有用现成的 Agent 编排框架。不加重型框架的原因很简单这类框架对单 Agent 的编排确实方便但金融链路里每个节点都需要精细控制包括输出校验、幂等处理、数据快照回放。框架封装层级越深排查问题的成本越高。我自己写调度器每个状态流转都有日志出了问题直接查状态机就能定位。Docker Compose 把整套系统编排起来定时任务由 Cron 触发每天收盘后自动跑一次全链路分析盘中每 15 分钟跑一次轻量巡检。这个节奏是我调出来的全量分析太频繁的话大模型 API 成本吃不消太稀疏的话又容易错过行情拐点。3. 研报 Agent 的落地细节数据清洗与结构化输出3.1 数据层建设接口、缓存、清洗研报能不能用一半取决于数据管道干不干净。这一层我踩的坑最多起初从财经数据接口拿到的数据直接灌给 Agent结果各种奇葩问题都来了。第一个坑是除权除息。某只股票 10 股派 8 元现金除息日当天开盘价直接跳空低开但技术指标不会自动处理这种跳空。如果用不复权的数据算均线就会得出假突破、假大跌的结论。后来我统一对所有历史行情做了前复权处理复权因子在数据入库的时候就算好指标计算全部基于复权后的价格序列。第二个坑是财报数据的发布延迟。财务数据在季报发布前是旧的发布后突然跳变Agent 可能拿旧数据做出错误判断。我的做法是给每项财务数据加一个“报告期”字段在 prompt 里明确让 Agent 只使用最近一期的报告期数据并且把财报发布日期和抓取日期都打印在研报脚注里。第三个坑是数据源偶尔断更。某个股票停牌之后行情接口可能返回全零数据如果不做过滤直接喂给 Agent它会一本正经地分析出一堆假信号。清洗规则里我加了一条当日成交量为零、连续两个交易日价格不变的股票直接跳过技术面 Agent 不给评分。3.2 研报 Agent 的 Prompt 设计角色、任务、三明治约束Prompt 设计是这套系统的核心竞争力。我给每个 Agent 写的是“角色定义 一段话任务 严格输出格式”的结构行业里管这个叫角色约束。以基本面 Agent 为例核心角色定义是这样一段话你是一名专注上市公司基本面研究的分析师。你只基于给定数据说话不猜测、不脑补。 你的输入包括最近完整报告期的资产负债表、利润表、现金流量表摘要以及近两年的营收和利润趋势。 你的任务评估这家公司的盈利能力变化、成长性趋势、财务健康度并给出 0-100 的基本面评分。 严格约束 1. 你不得讨论技术面、量价和 K 线信号 2. 你不得使用超出现有输入数据范围的信息 3. 输出必须是一个 JSON 对象包含评分以及得分因子的说明。这段 prompt 里有三层设计第一层明确角色身份来防止串台第二层限定输入范围来防止幻觉第三层约束输出格式来保证下游可解析。我还加了一个三明治技巧——在最开头和最结尾都重复一遍“只基于给定数据说话”实测下来对模型输出稳定性的提升比想象中大。3.3 Agent 的数值能力差计算交给代码这是整篇文章里我最想说的一条经验千万不要让大模型做算术。起初我偷懒让基本面 Agent 直接从营收和净利润数字里“算出”同比增长率结果它三次里有两次算错而且错得毫无规律有时候差 0.5 个百分点有时候差 5 个百分点。后来我把所有数值计算全部挪到数据层完成同比增长率、毛利率变化、ROE 的变化量都是用代码算好后塞进输入数据里Agent 只负责看趋势做判断。这样一来 Agent 的任务变成了对比“增长率从 18% 下降到 6%”这类文本描述这正好是语言模型擅长的工作。现在整套系统的数值计算误差比原来低了一个数量级。3.4 多 Agent 研报合并观点冲突怎么仲裁基本面 Agent 和技术面 Agent 经常打架一个说买入一个说卖出。最简单的做法是加权平均但我试下来发现直接把两份评分加权求平均有个大问题基本面 Agent 用的是季度数据反应慢技术面 Agent 用的是日线数据反应快在基本面平稳但技术面剧烈波动的时候加权平均会给出一个“在下跌趋势里接飞刀”的错误信号。我的解决方案是分层仲裁。先比较两份观点的方向一致度如果一致直接取加权分如果不一致就先检查技术面的趋势强度如果趋势信号特别强比如放量突破年线且均线多头发散暂以技术面信号为主但把基本面观点作为风险提示并列写进研报。也就是说仲裁的结果不是吞掉一方观点而是让研报同时呈现“短期信号指向”和“中长期基本面判断”两个维度把决策复杂性留给交易 Agent 去处理。4. 交易决策与风控模块把 Agent 关进笼子里4.1 交易决策 Agent 的输入输出决策留痕是关键交易决策 Agent 是整个链路里输出最复杂的角色。它的输入是汇总研报、当前持仓、账户可用资金、以及当天已经发生的交易记录。输出是带理由的动作建议我给它的输出定义了一套严格 JSON Schema{ action: buy|sell|hold, symbol: 字符串股票代号, quantity: 0, price_limit: 0, confidence: 0.0, reason: 不超过200字的判断理由 }这个 Schema 里最有用的是 confidence 字段。当研报两个维度观点冲突时决策 Agent 往往给出 50 分上下的低置信度判断。我在调度器里加了规则置信度低于 55 的动作默认降级为“只观察不入场”避免 Agent 在状态不明确时强行交易。决策留痕是我从头坚持到尾的工程原则。每一步 Agent 的判断都要有完整日志包括输入数据摘要、输出结果、引用的关键因子。因为模拟盘出亏损的时候如果没有留痕根本不知道是哪个判断错了只能蒙着改 prompt很容易陷入“越调越乱”的坑。4.2 硬性风控规则在 Agent 之上Agent 不能推翻规则关于风控我的实践结论是LLM 可以参与风控分析但不能作为唯一风控手段。Agent 的文本输出天然不稳定同一个输入跑两次可能有不同结果如果用大模型做最终风控相当于把安全底线建立在一个概率系统上。所以我设计了双层风控结构。第一层是代码实现的硬规则在 Agent 之上强制执行Agent 无论如何都无法覆盖第二层才是让风控 Agent 对交易动作做合理性分析比如检查决策理由是否和研报观点自洽。硬规则我用一套白名单式代码实现主要包括几条def check_risk(order, account): # 1. 单票仓位不超过账户总资产的 15% if order.value account.total_assets * 0.15: return False # 2. 单行业暴露度不超过 25% if account.get_industry_exposure(order.symbol) 0.25: return False # 3. 个股相对建仓价的回撤超过 8% 必须强制止损 position account.get_position(order.symbol) if position and position.pnl_ratio -0.08: order.force_close True # 4. 账户整体回撤超过 5% 时暂停开新仓 if account.total_drawdown 0.05 and order.action buy: return False # 5. 当日已买入的持仓不允许当天卖出模拟 T1 if order.action sell and order.symbol in account.bought_today: return False return True这套规则看起来简单但真正的难点是怎么让它“不可绕过”。我的做法是风控检查放在交易 Agent 和模拟执行器之间执行器只认经过风控校验且校验通过的订单对象。调度器层面也做了防护如果某个 Agent 因为输出格式问题导致订单字段缺失执行器会拒绝执行而不是自动补默认值。风控 Agent 的职责不在这里它拿到的输入是“已经通过硬规则校验的订单”用来做更细的分析——比如检查交易理由是否前后矛盾、是否在事件窗口期内有重大未释放风险。也就是说硬规则负责“底线安全”风控 Agent 负责“语义安全”一个靠代码一个靠模型。4.3 模拟执行器订单管理、手续费、滑点模型模拟执行器负责最后一公里。它维护一个虚拟资金池初始资金设定为 100 万模拟金额用来跑验证。每笔交易按真实市场规则计算成本佣金双边收万分之三点五印花税卖出收千分之一另外我还加了一个滑点模型模拟盘限价单如果和市场价差距过大就直接按市场价打折成交防止 Agent 设定一个永远不可能成交的极端价格。订单管理模块的职责是防止重复和错乱。比如交易 Agent 重复生成同方向订单执行器会做去重账户资金不够买入执行器会拒绝而不是按比例缩量停牌股票不允许交易黑名单股票不允许交易这些规则全部写在执行器层面不依赖大模型判断。模拟盘跑起来之后这块逻辑给我省了不少心。5. 三周模拟盘的运行结果与几个翻车案例5.1 整体运行数据先看数字再看问题系统跑了一个完整的验证周期数据样本不大但足够说明问题。整体区间是窄幅震荡市模拟账户最终的区间收益约一个多点最大回撤约三个多点交易 20 多次胜率在五成上下单笔最大亏损控制在两个点以内。单看收益不算亮眼但考虑到全程没有人为干预这个表现至少证明了整套链路能稳定跑通。收益贡献里有一个值得注意的现象大部分盈利来自少数几笔交易其余很多笔交易是赚赚亏亏打平。这和真实市场里的盈利分布很像。系统最大的问题不在选股——研报判断的质量其实还可以问题出在“结合市场节奏执行”的环节。趋势跟踪类的策略在震荡市里天然吃亏技术面 Agent 经常刚发出买入信号市场就熄火刚止损就反弹。这张表是模拟验证期的整体表现记录指标模拟验证结果区间收益率略正约 1% 级别最大回撤约 3% 级别总交易次数20 余次胜率约 50%单笔最大亏损控制在 2% 以内单笔最大盈利约 4%5.2 翻车案例一新闻分析 Agent 把利好当利空这套系统上线后的第一个低级错误来自舆情分析环节。某公司发布了一份净利润大幅增长的公告结果新闻分析 Agent 把这个消息判定成了利空理由是“净利润增长幅度低于市场预期”。但实际上这家公司当时的市场预期并没有那么高Agent 是根据自己训练数据里的“常识”脑补出了一个预期值而完全忽略了输入公告里“创历史新高”的关键词。排查链路是这样的先看决策 Agent 为什么给出卖出信号日志显示它引用了舆情 Agent 的“利空”结论再查舆情 Agent 的输入原始公告文本里没有任何利空表述问题定位在舆情分析环节对“增长”语义的极性判断上。修复方式是在舆情 Agent 的 prompt 里加了一条硬约束除非输入文本明确包含下滑、亏损、下调指引等词汇否则默认将业绩增长判定为正面信号同时把“对比市场预期”的判断从 Agent 任务中移除。这个案例给我的教训很直接舆情 Agent 的分析一定要基于输入文本的显式表达不能让它自己脑补市场预期。语言模型对“语境外补充”的倾向极强不加约束就会用训练数据里的先验判断覆盖最新信息。5.3 翻车案例二除权除息导致的“假暴跌”第二个坑发生在数据层。某股票实施了大额分红除息日当天价格向下跳空技术面 Agent 把所有均线指标重新计算了一遍发现价格跌破了关键均线支撑于是发出止损信号。但这是一次纯粹由分红除息造成的价格调整公司的实际经营没有任何变化股票仓位被白白止损了。排查链路是我最熟悉的一段先怀疑行情数据错了但检查接口原始数据没问题再怀疑是复权没做好一查才发现我数据管道的复权处理只覆盖了历史数据回测场景实时增量更新的数据没有同步做前复权处理导致技术面 Agent 拿到的序列是“未复权当前价 复权历史价”的拼接数据。修复倒不复杂把所有实时行情统一改为前复权口径并把除权除息日的调整因子单独记录在研报里标注“价格跳空是否由分红导致”。这个坑的坑点在于“复权处理做了但没做全”分成历史回测和实时更新两套逻辑是最容易埋雷的工程实现方式。后来我把复权逻辑统一收口到一个函数里所有数据进入 Agent 之前都要过一遍这个函数再没出现过同类问题。5.4 翻车案例三大模型输出 JSON 格式损坏交易 Agent 罢工模拟盘跑到第二周某一天交易 Agent 突然一整天空转调度系统显示任务全部失败。排查了半天才发现是底层模型输出了一段不合法 JSON字段之间多了一个逗号交易 Agent 的解析器直接抛异常并且重试机制在同一错误上反复重试把当天剩余的重试额度全部耗尽了。这个问题的根因在解析容错不够而不是模型真的有多不稳定。修复方案做了三层第一层加了格式化解析器对常见 JSON 错误多余逗号、缺引号、末尾逗号做自动修复第二层解析失败之后先做字段级校验缺失字段用默认值补充并标记为低置信度而不是整个任务失败重试第三层把重试策略改成指数退避避免同一个错误反复烧钱。改完之后后续运行里没有再出现过一整天空转。6. 后续还能怎么迭代方向和一些思路6.1 引入行业知识图谱增强跨股票关联分析现在的研报 Agent 是逐股分析的它不会主动把上下游产业链的联动考虑在内。比如上游原材料价格大涨下游制造业的成本压力就会上升单看标的的财务报表不一定能提前看出来。后续我想加一个轻量行业知识图谱把公司所属产业链上下游关系和主要原材料映射关系存成图结构在基本面 Agent 做分析时作为附加上下文注入让研报分析带上一点行业联动视角。6.2 用强化学习优化仓位管理现在的仓位管理是固定比例加风控阈值比较粗糙。比如系统判断某只股票是高置信度机会当前仓位上限是 15%实际上可能愿意冒更多风险低置信度机会即使不触发风控也应该更保守。这个权衡逻辑很难用规则手写后续打算用模拟环境的强化学习来训练一个仓位管理器让它根据账户回撤和信号强度动态调整仓位风控硬规则继续作为上限保护。6.3 多策略 Agent 并行与投票机制目前整套系统只有一个策略主线基本面加技术面共振。单策略在特定市场环境下必然失效后面计划加两个独立策略线比如事件驱动策略和均值回归策略让三条策略线各自独立跑分析最后通过投票机制决定整体仓位态度。这样能降低对单一策略的依赖系统在不同市场风格下的适应力会更强。6.4 成本优化把重复性任务切换到本地小模型整套系统跑一个完整研报周期大约消耗十几万 token如果一天跑几次API 成本确实肉疼。实际跑下来发现不同 Agent 对模型能力的要求差异巨大数据清洗、格式规整、字段抽取这类任务用本地开源小模型完全够用只有研报分析和交易决策这类需要强推理能力的环节才值得用闭源大模型 API。后续优化方向是做一个模型路由层根据任务类型自动选择模型服务把运行成本降下来。我自己跑下来最大的感受是AI Agent 在金融场景里的瓶颈从来不是“模型不够聪明”而是工程细节不够扎实。数据一脏再聪明的 Agent 也分析不出正确结果风控一软一个格式错误就能让系统穿仓。想复现这套模拟系统的朋友我的建议是把数据管道和风控硬规则当作第一优先级先把底层打扎实再优化 prompt会比逆向迭代省力得多。后面我还会继续迭代这套模拟系统有新坑再第一时间来同步。
