先说个背景。我前后花了一个多月，搭了一个完全自主的股票分析模拟交易系统。它不是那种“给个 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 生态，配合专门的数据接口来获取行情和财报数据。

数据管家要处理的数据主要有三类：

1. 历史行情数据（开盘价、收盘价、最高价、最低价、成交量等），用于技术面分析。
2. 基本面财务数据（营收、净利润、毛利率、资产负债率、现金流等），用于基本面分析。
3. 公告和新闻文本，用于捕捉事件驱动信号。

数据清洗的坑主要在“复权”问题上。股票的除权除息会导致价格出现跳空缺口，如果不做前复权处理，技术指标的计算会完全失真。我一开始没注意，直接用原始价格算均线，结果某只股票因为一次大比例分红，均线系统直接崩掉，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 根据一个权重矩阵算出综合分，再决定交易倾向。

权重矩阵如下表所示：

为什么要设置动态权重？因为在不同市场状态下，有效的分析维度完全不同。上涨趋势中，技术面（趋势跟踪）效果好；下跌趋势中，基本面（防御属性）更重要。这个“状态判断”本身也由模型来做——策略 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 常见问题速查表

最后的一点实际体会

整套系统搭建下来，我最深刻的体会是：AI Agent 落地最大的难点，不是让模型“变得更聪明”，而是设计好它和其他模块之间的交互边界。模型的能力是下限，边界设计才是上限。

如果你也想尝试类似的项目，我的建议是从“小闭环”开始：先不要追求大而全的多 Agent 架构，先拿一个 Agent 负责一件事，把它做好。比如先做一个“财报分析 Agent”，只输出一份结构化研报，人来看，人来决策。等这个环节稳定了，再加入第二个 Agent 做技术面判断，然后再慢慢加入策略、风控、交易执行。一步到位往往意味着一步崩溃。

另外，数据源的选择要慎重。免费数据源虽然香，但稳定性和准确性都需要验证，最好能在系统里加缓存和数据校验机制。还有一点，日志记录一定要完整。Agent 系统调试起来非常困难，如果你的 Agent 没有记录下它每一步的决策依据和输入输出，出了问题你根本无从下手。

这套模拟交易系统目前还在持续迭代中，下一步我打算加入更细粒度的行业轮动分析，以及基于强化学习的仓位优化模块。如果你也在折腾 Agent 和量化结合的方向，欢迎多交流。