炒股这事，放在十年前是行情软件加一根网线，放在五年前是量化回测加一堆Python脚本，而到了现在，最前沿的玩法已经变成让一群AI像券商里的投研小组那样分工协作，各自负责基本面、技术面、新闻情绪、多空辩论、风控和交易执行。我前段时间完整部署并跑通了一个名为TradingAgents的中文多智能体股票分析项目，把它的工作方式拆开来看之后，最大的感受是：这套东西本质上不只是"换个更强的模型问答案"，而是把"投资决策流程"本身做成了可编排、可回溯、可干预的Agent协作系统。这篇内容就是我对它从设计动因、角色体系、工作流链路到中文落地和回测验证的一次完整复盘，适合已经接触过LLM应用开发、想在金融数据分析方向尝试多智能体架构的朋友参考。
1. 单模型选股为什么容易翻车：多智能体协作的设计动因
1.1 单体大模型做股票分析的三块短板
先说一个很多人踩过的坑：直接把行情数据、公司财报丢给一个ChatGPT或开源大模型，让它"分析一下这只股票值不值得买"。单模型方案不是不能用，而是存在三个非常明显的结构性短板。
第一，上下文窗口撑不住。一份长达两三百页的财报、几十条新闻公告、几年K线数据，塞进去之后光是token消耗就够喝一壶，模型还会在中后段"失忆"，把前面读到的关键财务数据忘掉。第二，单模型缺少"对抗机制"。一个人分析容易陷入"屁股决定脑袋"——先有了观点再去找论据，AI同样如此。让它自己做完多头分析又做空头分析，它往往拗不过自己的立场惯性。第三，无法审计。所有判断挤在一次推理里，你不知道它到底是根据PE还是新闻还是资金流向做出来的判断，出了错也没法复盘。
TradingAgents的设计思路恰好就是冲着这三个短板来的：把上下文分段消化，把观点拆给不同立场的角色，把决策链路拆成显式的步骤节点。
1.2 从"一人拍板"到"投研小组"：多智能体的协作哲学
你可以把传统单模型方案理解成一个"超级个体户"——什么活都干，但什么都干不精。而TradingAgents更像一个"小型投资公司"，内部有明确的岗位分工：有人专门看研报，有人专门盯K线，有人专门刷新闻，有人负责综合各方观点下判断，还有人专门负责在你头脑发热的时候泼冷水。
这个协作哲学的核心在于：信息在不同角色之间经过"加工—质询—综合—复核"的流转，每一步都带有独立的上下文和目标，而不是所有信息一股脑堆给同一个大脑。这样做的直接好处是——每个Agent只需要在自己相对窄的专业领域内使用上下文，精度更容易保证；同时因为每个角色的产出都要接受其他角色的审视，系统性偏差会被压缩。
1.3 借鉴真实交易机构的组织架构
为什么说这套设计非常聪明？因为它在用软件工程复刻一个已经被验证了上百年的组织形式。你去任何一家正规券商或者基金公司，投研流程基本就是"研究员出报告、投资经理拍板、交易员执行、风控部门把关"。这个组织架构之所以长期存在，不是因为机构喜欢开会，而是因为它能有效隔离不同类型的风险：判断风险、操作风险、合规风险分别由不同角色承担。
TradingAgents把这一套搬进了Agent编排层。每个Agent不只是"套了人设的提示词"，而是有各自独立的角色目标、输入数据源和输出约束。这意味着你完全可以在某一个环节替换模型、修改策略、加入新的数据源，而不需要推翻整个系统。
2. 角色体系拆解：分析师、基金经理、交易员和风控经理各管一段
2.1 前台角色：基本面、技术面、新闻面三位分析师
在TradingAgents的初始架构里，分析层由三个核心角色并联作业。
基本面分析师负责逐行读取财务数据，包括收入增长、利润率、负债结构、现金流、估值指标等，产出以"这家公司值不值这个价"为核心问题。它的难点在于财务名词多、单位差异大，提示词里必须明确说明数据单位、时间口径和指标计算方式，否则很容易出现"用单季度利润对比全年利润"的低级错误。
技术面分析师的任务是识别趋势形态、支撑压力位、量价配合，以及计算常用技术指标。在提示词里要明确要求它"不要只看单个指标，要结合多个时间周期的趋势做交叉验证"，否则它可能会被单一金叉死叉信号带偏。
新闻分析师负责把非结构化文本结构化——从新闻标题、公告内容、社媒情绪里提炼出对股价可能产生影响的信号，并标记情绪倾向是正面、负面还是中性，同时给出影响程度的等级判断。这个环节最容易遇到的问题是对新闻的"时效性"把握不准，一条三年前的旧闻被当成新利好拉高权重，所以提示词里要强制它带上"发布时间"字段并做时间衰减处理。
2.2 决策中枢：基金经理与多空辩论机制
三份分析报告出来之后，并不会直接进入交易环节，而是先进入基金经理的视野。基金经理在系统中扮演"汇总者"的角色，把三方观点压缩成一份投资建议。
但TradingAgents还有一个值得单独拎出来讲的设计——多空辩论。系统会从交易员和分析师中派生出一组"看多方"和"看空方"两个阵营，针对同一只标的进行观点交锋。多方要论证上涨逻辑，空方要寻找反证和风险点，双方各有固定的发言轮次，每一轮都能看到对方的论据并做出回应。
这个机制解决了单模型一个非常隐蔽的问题：语言模型的输出有"顺从性"，你让它提反对意见，它很多时候只是在做"防御性反驳"，先肯定再转折，最后仍然支持原观点。但在辩论机制下，空方被要求"必须找出足以否决买入决策的具体理由"，且双方会被反复交替质询，这就逼着模型跳出舒适区，去真正挖掘反方数据。
辩论结束后，基金经理再综合辩论纪要，输出最终的投资逻辑和态度。如果你的系统接入了PEFT微调的行情预测模型，这个模型的得分会被当作一个额外信号注入基金经理的参考列表，帮助它从纯文本分析之外获得量化维度的信息。
2.3 中后台：交易员、风控经理与心理分析师
基金经理给出投资态度后，交易员负责设计具体执行方案：买入还是卖出、建议仓位比例、目标价区间、止损位置。交易员输出的是"可执行动作"，因此提示词里必须明确"给出的每个数字都要有来源依据"，防止模型拍脑袋说一个"基于经验"的仓位。
接着是风控经理，这是很多人忽略但极其重要的一环。它的核心职责有两块：一是检查整个决策链路里是否有遗漏的风险因素，比如流动性风险、行业政策风险、财务报表异常；二是针对交易员的方案给出风控约束，比如"单标仓位不超过总资金20%""止损线不得低于成本价5%"这类硬性规则。如果风控经理的判断与基金经理矛盾过大，系统会要求重开一轮讨论或者直接降级交易建议等级。
心理分析师则是一个很有本土特色的角色设计——它的大盘心理预期分析本质上是在帮你判断当前市场情绪是否过热或过冷。在过热行情里AI模型容易统计到大量乐观新闻，从而系统性高估上涨概率，心理分析师的角色就是替决策层踩一脚刹车，从舆论温度、市场宽度等维度给出"当前情绪是否极端"的独立判断。
2.4 角色之间的信息依赖关系
这些角色并不是简单堆砌的。在TradingAgents的编排里存在清晰的依赖关系：三位分析师并行产出报告，基金经理在报告齐备后启动多空辩论，辩论完毕后形成投资态度，交易员基于投资态度设计执行方案，风控经理和心理分析师对方案进行最终校正，最后才进入回测或模拟交易环节。这个链路是单向的，但存在多个反馈回路，比如风控发现问题时可以打回给基金经理重新决策，交易员也可以要求分析师补充数据。
3. 一条决策指令的完整流转链路：状态机、消息与Graph编排
3.1 从触发到产出：一次股票分析的八个阶段
整个流程如果用"阶段"来切分，大致可以分成以下八步：
- 系统接收标的代码和基础配置，启动分析任务
- 三类数据获取子流程并行拉取财务数据、行情数据和新闻数据
- 三位分析师各自完成独立分析并产出结构化报告
- 基金经理组织多空辩论，辩论内容被完整记录
- 基金经理结合辩论纪要+PEFT预测信号输出投资态度
- 交易员将投资态度转化为具体执行方案
- 风控经理和心理分析师对方案进行复核与约束修正
- 系统输出最终决策包，包含决策依据链、辩论纪要和风险提示
每一步的输出都是结构化数据，比如分析师输出JSON格式的报告对象，内部包含"分析结论""关键依据""风险点"等字段。这样做的好处是后续环节可以直接引用字段值做判断，也方便接入审计系统。
3.2 LangGraph如何描述这套工作流
TradingAgents底层的编排依赖LangGraph这套状态机框架。这里值得解释一下为什么选它而不是传统的Agent循环框架。传统Agent框架大多是"单Agent + Tool循环"，即一个Agent反复调用工具直到完成任务，这种模式适合问天气、查资料这类简单任务，但在多角色协作场景下有致命缺陷：没有显式的状态持久化，Agent之间难以传递复杂的中间产物。
LangGraph则允许你把整个流程定义成一个图结构：节点是每个角色的处理函数，边是节点之间的依赖关系，共享状态存放在一个全局的State对象里。分析师A的输出会被写入State的fundamental_analysis字段，基金经理节点只会在该字段存在且有数据时被触发，这就是"条件边"。如果有人想新加一个"行业景气度分析师"，只需要注册一个新节点，并在基金经理的输入引用里加一个字段，不需要动其他任何流程逻辑。
3.3 上下文的记忆与共享：让每个智能体"接得上话"
多智能体系统里最常见的翻车现场是上下文断链——基金经理引用"刚才辩论中提到的营收增速下滑"，但辩论环节的完整文本没有传给它，模型只能靠猜。TradingAgents对这个问题的处理方案是把所有中间产出集中放进共享消息队列，并按"角色+轮次+内容类型"打标签。每个角色在启动时除了读取自己的专用输入字段，还可以按需翻阅历史消息。
同时要注意token开销的增长。普通的单模型分析可能只消耗几千token，但完整的TradingAgents流程跑完一次单标的分析，总消耗量可达2万到5万token以上，具体取决于辩论轮次深度和新闻数量。所以如果用在实时盯盘场景，建议把分析频率控制在关键时点触发，而不是每分钟跑一轮，否则API账单会先让你"亏钱"。
4. 中文场景落地：数据源、提示词与模型选型的实战经验
4.1 A股数据源对接：获取与清洗的完整链路
TradingAgents原始项目本身偏美股市场，中文落地最大的工作量和最容易出问题的地方全在数据源这一层。A股和港股的数据生态与美股完全不同，美股有Yahoo Finance和SEC EDGAR这类相对标准化的数据接口，而A股的财务数据散落在巨潮资讯、上交所、深交所，行情数据则依赖聚宽、Tushare、AkShare等第三方库，每家机构的字段命名和数据粒度都不一样。
我自己的做法是用AkShare作为基础行情数据源，用Tushare Pro补充财务索引类数据，再对字段做一层统一封装。封装层只暴露三个标准化方法：get_financial_report(stock_code)、get_price_history(stock_code, period)、get_news_sentiment(stock_code, time_range)，所有Agent只与这层封装交互，不直接接触底层数据源。
清洗环节要特别警惕三件事：第一是非标准时间格式，很多公告日期是中文格式如"二〇二六年一月三日"，必须统一转成ISO格式；第二是财务数据的单位问题，有的字段以万元为单位，有的以元为单位，不统一的话计算误差非常大；第三是分红送转导致的股价除权缺口，直接从数据源拉回来的复权价如果没处理，技术面分析里的支撑位和均线系统会整体失真。
4.2 提示词的构造思路：别把分析师养成"复读机"
很多人在多智能体项目里翻车，不是模型不行，而是提示词把Agent的独立思考空间堵死了。写TradingAgents的分析师提示词时，我总结了三个关键原则。
第一，给定角色目标但不下达结论。不要写"请分析该股票是否值得买入"，而要写"请从财务数据角度识别该公司的核心投资逻辑与潜在风险，并输出关键数据依据"。前者诱导模型直接跳向结论，后者强迫它先呈现事实。
第二，要求输出结构化字段并设定排他约束。比如基本面分析师输出的字段集固定为{盈利质量, 成长性, 财务健康度, 估值水平, 定性判断}，每个字段必须有对应的"数据支持片段"。这能显著减少模型空话套话的比例。排他约束的意思是明确告诉它"不要输出你并未在数据中读到的内容"，防止基于训练集先验知识脑补数据。
第三，辩论角色之间要设置硬性立场对抗参数。多方提示词中写"你必须在既有的多方结论之上找出至少3条新论据"，空方提示词中写"你必须是空方立场，找出所有可反驳多方论点的证据，如果找不到也要指出对方论证中逻辑不完备之处"。这样能有效防止辩论变成两个立场相同的人互相客套。
4.3 模型选型的实际取舍
整个系统跑下来，不同角色对模型能力的需求差异非常大，我推荐按角色分层选型而不是一模型全家桶。
基础数据抽取类任务，比如从财报文本里提取收入利润字段，使用便宜的中小型开源模型就够了，关键是提示词里的格式约束要写得死。分析推理类任务，比如基本面分析师和技术面分析师，建议使用主流的旗舰级商业模型或能力较强的开源大模型，因为这里需要真正的多步推理。多空辩论环节最吃模型能力，不仅要有逻辑性，还得能在对抗压力下坚持立场并回击，在实测中，小模型在这个环节很容易崩，动不动就"你说得也有道理"，辩论直接变成认错大会。
另外建议单独用一个Token成本统计模块记录每个角色的耗token量，方便后续针对高频高耗的角色做模型降级或调用缓存。
5. 回测与有效性验证：如何判断系统是真靠谱还是假聪明
5.1 过拟合与未来函数：两个最隐蔽的陷阱
这里要说一个非常严肃的现实问题——多智能体系统很容易给你一种"专家在手、天下我有"的错觉，但回测结果漂亮不等于实盘靠谱，尤其是当系统里存在"未来函数"时。未来函数是指模型在t时刻做决策时，数据里实际上混入了t时刻之后才产生的信息。在多Agent系统里这种问题往往出现在新闻数据对齐环节：新闻发布时间戳解析错误，导致某条利好新闻被当作"盘前已发布"的数据，而实际上它是收盘后才发出的。
另外还要提防提示词层过拟合。如果你在开发阶段反复用同一批股票测试并不断调整提示词，模型可能已经被"教导"出针对这组股票的特殊偏好，换一批股票效果立刻崩盘。建议固定测试集只是用于调参，同时留一组"从未参与开发"的股票池做终审验证。
5.2 用对比实验验证每个Agent的真实贡献
判断多智能体系统有效性最靠谱的方法不是看整体收益曲线，而是做消融实验。把系统以"完整模式"“去掉辩论模式""去掉风控模式""单模型直出模式"分别跑在相同时间段、相同股票池、相同数据源上，然后对比四组结果。
我实际跑过的对比中，最直观的结论是：去掉多空辩论环节之后，系统的换手率明显上升，分析报告里的"自信程度"虽然提高了，但回测曲线并没有变好；而去掉风控环节后，最大回撤数据显著恶化。这说明辩论和风控这两个环节在系统里承担的功能是真实的，不是摆设。你也可以用同样的方法验证你的自定义Agent是否值得保留，如果加了某个Agent之后整体表现没有统计意义上的提升，果断砍掉。
5.3 实操中的几个运行注意项
关于实际运行TradingAgents，还有一些零散但很实用的注意点值得记录。
第一，逐标的串行分析非常慢，建议在数据获取和基础分析层用异步并发，但决策和风控阶段必须保持串行。理由很简单：决策阶段的输出会互相影响，并发会导致状态竞争。
第二，缓存机制必须要做。财务数据和历史行情短期内不会变，同一个标的在一天内被重复分析的时候，直接复用缓存可以节省大量时间和token。但新闻数据不能走长缓存，建议单独设置30分钟到1小时的短缓存窗口。
第三，每一轮完整分析的决策依据需要落盘成JSON或Markdown文件，文件命名带上标的代码和时间戳。这是多智能体系统最值钱的资产——你可以在几周后回去核查当时的决策链路，定位是哪一步的判断出了问题，再针对性优化对应Agent的提示词。
第四，接入模拟交易时建议给风控Agent绝对否决权。如果风控输出的硬性规则与交易方案冲突，宁可让当轮不交易、只输出观察报告，也不要让系统带着违规仓位进入实盘。多智能体系统的价值不只是让你抓住更多机会，更重要的是让你在没有好机会时管住手，这一点在实盘中的意义远大于任何一次单笔盈利。
