
1. 从一个人拍板到一间交易公司TradingAgents 想解决什么我最早接触多智能体做投资决策是把它当成一个玩具十几个大模型角色互相聊天聊完给个方向看起来很热闹。真正让我改观的是TradingAgents这个项目——它没有把智能体做成一群分析师开会而是直接把一家交易公司的组织结构搬到了代码里有负责看财报的、有盯盘面的、有刷社交情绪的、有读新闻的还有专门唱多和唱空的两位研究员吵架最后交给交易员下单风控团队再吵一轮基金经理拍板。整套流程跑完你会拿到一份带理由、带分歧、带风控意见的决策报告而不是一句干巴巴的建议买入。先说清楚它是什么、能干什么、给谁看。TradingAgents 是一套基于大语言模型的多智能体金融交易研究框架核心思路是把分析—辩论—交易—风控—决策这条链路上的每个环节都交给一个独立角色角色之间通过结构化消息传递信息最终产出交易方向、仓位建议和执行理由。它不是一个能直接接券商接口自动下单的生产系统也不是一个能保证赚钱的量化策略——它是用来做研究、复盘、决策辅助和观点对照的。如果你平时会看财报、研究个股、做主观交易或者你在做量化想加一层逻辑层进去这个框架值得花一个周末跑通。受众上我把它分三类。第一类是个人研究者想看看大模型在金融推理上到底有几斤几两能不能当第二双眼睛第二类是量化工程师已经有一套因子体系想补一个解释层和辩论层让策略输出更容易被人理解和审查第三类是产品/技术团队想研究多智能体架构怎么设计角色分工、怎么做状态管理和记忆TradingAgents 的工程结构比大多数 demo 干净得多。反过来说如果你指望装上它第二天就开始躺赚那还是别碰这东西输出的东西需要你自己判断而且它的价值恰恰在于给你提供你没想到的反面论据而不是给你一个神谕。我用下来的整体感受是它的最大价值不在于预测准不准而在于它强迫你把决策链条拆开逼你在每个环节上都给出理由。这跟我们自己做投研的流程其实是一致的——只是人会偷懒会跳过某一步或者被情绪带着走而框架不会。下面我把这套东西从设计思路到落地实操完整拆一遍包括我踩过的坑和调参经验。2. 框架整体设计与角色拆解2.1 四层组织结构它到底切了哪几刀理解 TradingAgents 最好的方式是把它当成一家小型对冲基金的人员编制表。整个框架大致分四层每一层解决一个不同性质的问题。最上面是分析师团队负责把材料变成观点。这个团队里通常有四类角色基本面分析师看财报数据、盈利能力、估值指标技术面分析师看均线、动量指标、成交量形态新闻分析师读公告和财经媒体的报道判断事件冲击情绪分析师则去抓社交平台上的讨论热度和情绪倾向。这四类角色的意义在于信息源的正交性——它们看的不是同一批数据所以观点天然会有冲突而冲突正是后面辩论环节的燃料。第二层是研究员团队也就是多头研究员和空头研究员。这两位做的事不是重新收集数据而是拿到分析师团队的结论后各自站在对立立场上做深度论证并且会来回交锋若干个回合。多头研究员要拼命找出上涨逻辑空头研究员要拼命找出崩塌风险谁的论据更扎实最后由裁判角色或者说流程本身来综合。第三层是交易员。交易员拿到研究团队的辩论结论结合当前价格和持仓情况给出具体的交易提案买还是卖大概什么价位什么时间维度理由是什么。注意这里交易员是提案者而不是决策者这是设计上的关键取舍。第四层是风险管理团队 基金经理。风控团队内部又有三个视角激进派认为可以承担更高风险去博收益保守派认为必须优先保本中立派在中间做平衡。这三方辩论完之后基金经理Portfolio Manager综合所有材料输出最终的 BUY / HOLD / SELL 决策以及执行方案。提示这套结构里最容易被忽略的是风控独立成层。绝大多数个人投资者和很多量化策略其实是没有独立风控环节的——止损规则写死在代码里但它不参与决策讨论。TradingAgents 把风控变成了一个会说话、会反对的角色这一点在工程上比多几个分析师更有价值。2.2 多空辩论为什么必须有一个人想不出的反面很多人第一次看这个框架会问既然都是同一个大模型在扮演不同角色那多头和空头辩论的意义在哪模型自己不会前后矛盾吗我一开始也这么想实际跑下来发现恰恰相反——角色提示词prompt的立场绑定能显著改变模型输出的分布。道理不复杂。当你让模型客观分析这只股票它倾向于给一个模棱两可的中性结论因为这是它在训练数据里见过的安全回答。但当你明确告诉它你是空头研究员你的任务是找出这只票最可能崩的三个理由它就会真的去挖空头论据输出的具体性和攻击性完全不同。这就是角色约束带来的行为偏移。我实测过一个很典型的场景某只票基本面数据其实一般但新闻面热度很高。单轮分析的时候模型给出的结论是短期有情绪支撑中长期需观望基本等于没说。而在辩论模式下空头研究员直接把营收增速已经连续两个季度放缓、估值却还在扩张这条摆出来多头研究员只能拿新产品线预期来挡最后交易员的提案明显偏保守。这个过程本身就是有价值的——它把你的注意力从现在涨不涨拉回到了涨的理由够不够硬。2.3 记忆与反思让第二次分析不再从零开始这是我个人认为最具工程巧思的一块。框架里有一套记忆机制每个角色在完成一轮分析后会留下自己的判断记录当同一只标的在之后的时间点被再次分析时系统能把这些历史判断和实际走势调出来让角色做一次反思——我上次说涨结果跌了错在哪这个设计解决的是纯 LLM 系统最致命的问题无状态。普通的大模型调用每次都是白纸一张你上个月对它说了什么它完全不记得。而投资这件事恰恰极度依赖连续性——同一只票的基本面判断应该随着财报更新而演进而不是每次重新拍脑袋。从工程角度看这套记忆通常以决策日志 收益回填的形式落地每次决策的日期、标的、方向、理由、以及后续一段时间的实际表现被记录下来在下一轮推理时作为上下文注入。这就让框架具备了最朴素的从错误中学习能力。我必须强调这不等同于模型权重被更新它不是训练而是把历史经验塞进上下文——所以记忆条目的质量和筛选策略非常关键塞太多无关历史反而会污染判断。3. 核心机制细节与参数取舍3.1 结构化状态传递智能体之间到底在传什么多智能体系统最容易崩的地方不是单个角色不够聪明而是角色之间传的东西没法用。你让一个模型把分析结果传给下一个模型它可能给你写三段散文下一个角色接不住整个链路就废了。TradingAgents 在这块的做法值得学习每个环节的输出都被约束成带明确字段的报告比如分析师的输出包含结论方向、核心依据列表、置信度、关键数据引用研究员的输出包含论据、反驳点、对分析师结论的采信程度。这些内容以结构化状态在流程图中流转每一层都能看到上层的完整输出。为什么要这么做因为辩论的前提是双方看到的是同一份事实。如果多头和空头各自拿到的是经过转述的、有信息损失的材料那辩论就变成了两个人在自说自话。统一的结构化状态保证了信息不失真。我自己在复刻类似系统时踩过这个坑早期我用纯文本串接结果到了第五个智能体它引用的数据已经是三重转述后的版本出现了明显的数值漂移——明明财报里营收是增长 8%传到最后变成了营收基本持平。3.2 快慢双模型为什么要有两个推理引擎框架里有一个我觉得非常实用的设计区分深度思考模型和快速思考模型。前者负责研究员辩论、交易员决策、风控综合这类需要长链条推理的环节通常用能力强但贵、慢的大模型后者负责信息抽取、格式化整理、初步摘要这类工作量巨大但逻辑简单的环节用便宜快的小模型。这个取舍背后是一笔账。一次完整的分析流程可能要调用几十次模型四个分析师各自处理多个数据源研究员辩论若干轮风控再辩论若干轮。如果所有环节都用最强模型单次成本会非常夸张。而实际上像从新闻里抽取出涉及的公司和事件类型这种任务小模型做得不比大模型差多少。具体怎么配我的经验是这样的深度思考那一档用当前你预算内最强的推理模型因为它决定了整个决策的天花板快速思考那一档用同系列的小模型就够了甚至可以考虑本地部署的开源模型来压成本。有个细节要注意如果两档模型来自不同厂商格式化和结构化输出的模板最好分开维护不同模型的指令遵循习惯差别挺大我见过小模型死活不按 JSON 输出、把整条链路卡死的情况。注意不要为了省钱把深度思考那一档也换成小模型。我试过辩论环节会退化成你对我对大家都对输出长度掉一半具体论据几乎消失等于白跑。3.3 数据源接入垃圾进垃圾出是铁律这个框架默认接的数据源大致覆盖几类行情与历史价格用于技术指标计算、公司财报数据、财经新闻聚合、以及社交平台的讨论热度。不同来源的数据在框架里进入不同的分析师角色互不干扰。这里我要说一句不太客气的话这个框架的最终输出质量七成取决于你喂给它的数据质量三成才是模型和流程的功劳。我在测试时对比过两种数据配置一种是用默认的公开数据源能拿到基本行情和零散新闻另一种是我自己补了更完整的财报字段和更及时的公告数据。同样的模型配置、同样的标的、同样的日期两次输出的具体程度差了一个量级——前者只能说近期走势偏弱后者能指出毛利率同比下滑 2.3 个百分点同期应收账款周转天数上升现金流质量恶化。所以如果你只是想快速体验流程默认数据源够用但如果你真想拿它做严肃研究花在数据上的时间应该远超花在调 prompt 上的时间。另外提醒一句部分数据源需要在服务方注册并申请密钥免费额度通常有调用频率限制跑批量回测的时候很容易撞到限流最好在配置里加一层本地缓存——框架本身有数据缓存目录但缓存策略比较粗同一标的换一个日期区间就会重新拉全量数据这点自己优化一下会省很多时间。3.4 辩论轮数怎么定我试出来的几个经验值框架里有两个关键参数控制辩论深度一个管研究员阶段的多空交锋轮数一个管风控阶段的三方讨论轮数。默认值都设得比较小我理解是为了控制成本让首次体验不至于太贵。我的实测结论是这两个参数和输出质量之间不是线性关系而是先升后平再降。具体来说研究员辩论从一轮提到两到三轮论据的密度和针对性提升明显因为第一轮往往是亮观点第二轮才开始抓对方漏洞但继续往上加边际收益迅速递减模型开始重复自己甚至出现为了辩论而辩论、强行找茬的情况。风控讨论也类似两轮左右基本能把激进、保守、中立三种立场说清楚。还有一个我自己总结的小技巧辩论轮数应该跟着标的的争议度走。像业务模式清晰、数据平稳的大盘蓝筹一轮辩论足够了硬加轮数只会让模型编出一些不存在的风险而那些正处于业务转型期、多空分歧本来就大的标的多给一到两轮辩论能挖出很多单轮分析看不到的东西。如果要做批量筛选建议先用低轮数粗筛一遍对少数值得深挖的标的再开高轮数细看这样成本可控。4. 上手实操从零跑出第一份决策报告4.1 环境准备与依赖安装这个框架是 Python 项目我建议用独立虚拟环境跑避免和系统里的其他包打架。Python 版本尽量用 3.10 以上太老的版本会在依赖解析上出问题。conda create -n tradingagents python3.11 -y conda activate tradingagents git clone 项目仓库地址 cd TradingAgents pip install -r requirements.txt如果你想把它作为库来调用也可以用包管理的方式安装pip install tradingagents装完之后建议先跑一次官方的命令行入口做自检看看依赖是否齐全、有没有明显报错。这一步别跳过我自己第一次跑的时候因为某个数据源 SDK 版本不匹配直到流程跑到一半才报错中间浪费了十几分钟的模型调用费用。4.2 密钥管理与配置项说明跑之前要准备两类密钥一类是大模型服务的访问凭据另一类是数据源的访问凭据。绝对不要把密钥硬编码在代码里也不要提交到版本库用环境变量管理export OPENAI_API_KEY你的密钥 export FINNHUB_API_KEY你的数据源密钥 # 可选如果你用别家的模型服务 export ANTHROPIC_API_KEY... export GOOGLE_API_KEY...然后是一个配置字典这是整个框架的总控台。常见字段和我的建议值如下配置项作用我的建议llm_provider指定模型服务商选你额度最充足的那家deep_think_llm深度推理用的模型预算内最强的推理模型quick_think_llm快速处理用的模型同系列小模型或本地模型max_debate_rounds多空辩论轮数粗筛 1精研 2-3max_risk_discuss_rounds风控讨论轮数一般 2 就够results_dir结果输出目录单独挂载方便归档data_cache_dir数据缓存目录和结果目录分开避免混在一起配置做好之后我强烈建议先在单一标的 单一历史日期上跑通完整流程不要一上来就批量。原因很简单第一次跑你会遇到各种格式和依赖问题单标的能把排查范围控制住而且历史日期意味着数据已经定型不会因为盘中行情变化导致结果不可复现。4.3 命令行跑一次完整流程项目提供了交互式命令行入口启动后它会依次问你分析哪个标的、用哪个日期、启用哪些分析师、用哪个模型服务商、辩论深度多少。这个过程对新手很友好因为它把参数选择变成了问答。整个流程跑起来之后你能在终端里看到各个角色的输出滚动出现——分析师先给结论然后多头和空头开始交锋接着交易员出提案风控三方讨论最后基金经理给出最终决策。跑完一次完整流程快的话几分钟慢的话十几分钟取决于标的数据量、辩论轮数和模型速度。这里有个我踩过的坑要提醒不要用当天日期去做分析。当天数据是残缺的新闻还在滚动社交情绪还在变化模型拿到的是一份半成品材料输出会非常飘。我做复盘用的日期通常是往前推一段时间这样既能拿到完整数据也能顺便验证当时的判断对不对。4.4 用代码调用并把结果落盘如果你要批量跑或者嵌进自己的流程里命令行就不够用了得用代码调用from tradingagents.graph.trading_graph import TradingAgentsGraph from tradingagents.default_config import DEFAULT_CONFIG config DEFAULT_CONFIG.copy() config[llm_provider] openai config[deep_think_llm] gpt-4o config[quick_think_llm] gpt-4o-mini config[max_debate_rounds] 2 config[max_risk_discuss_rounds] 1 ta TradingAgentsGraph(debugTrue, configconfig) state, decision ta.propagate(AAPL, 2024-05-10) print(decision)decision就是最终的决策结果state里包含整条链路上所有角色的完整输出。我强烈建议你把 state 完整持久化下来别只看最后那句决策——中间过程才是真正有价值的部分。我自己的做法是按标的/日期建目录把每个角色的报告分别存成独立文件同时把关键的中间结论抽出来存成一张表方便后续做统计。跑完之后框架通常还会支持一次反思回填把这次的决策和后续实际走势做对比写入记忆。如果你要做长期跟踪这一步千万别省它是这个框架区别于普通大模型问答的核心。4.5 结果评估别只看它猜对没猜对很多人评估这类框架的方式是让它预测明天涨跌看准不准。这个评估方式我认为是错的至少是不完整的。原因很简单任何单次预测的准确率都很容易被随机性淹没几十次样本根本说明不了问题。我用的评估维度是这样几个第一是论据的可验证性它给出的每一条理由我能不能在财报或公告里找到对应事实如果一条都对不上那这次输出去查价值第二是分歧的识别能力它有没有指出我原本没注意到的风险点尤其是空头研究员提的那些第三是稳定性同一个标的、同一个日期跑三次结论是否一致如果三次给出三个方向说明这个配置下的输出不可靠第四才是方向准确率而且要在足够大的样本上统计同时结合波动率做基准对比。提示第三种评估方式同输入跑三次看一致性是我认为性价比最高的自检方法成本低、信息量大。如果一致性很差先去调配置和数据别急着信它的结论。5. 常见问题与排查技巧实录5.1 常见报错速查表跑这类项目报错主要集中在这几类我整理成表方便对照现象可能原因排查方向启动即报依赖导入错误依赖版本冲突或缺少可选包重建虚拟环境按 requirements 重装某个数据源一直返回空密钥未生效或超出额度打印原始响应单独测试该数据源 SDK流程中途卡死无输出网络请求超时或模型限流加超时与重试降低并发输出不是结构化格式小模型指令遵循能力弱换更强的模型或简化输出模板数值前后不一致数据被多层转述失真检查状态传递是否保原始数据结论极度含糊数据不足或辩论轮数过低补数据适度增加辩论轮数成本远超预期全流程用了大模型拆分快慢模型启用缓存表格里最后一条我想多说两句。成本这件事在跑之前很难预估因为调用次数取决于数据量和辩论轮数而且是乘性关系。我的做法是先拿一个小标的做成本基线测试记录单次完整流程的调用次数和费用再按这个基线去估算批量任务的预算。经验上多空辩论每加一轮成本大概增加两到三成因为研究员阶段本身还会触发额外的工具调用。5.2 输出不稳定和幻觉的应对金融场景对幻觉的容忍度极低——模型编一个公司宣布回购的假新闻可能直接影响你的判断。我在实际使用中总结了几条应对策略。第一条是强制溯源。在提示词里明确要求每个结论必须绑定到具体的数据来源和数值不允许出现市场普遍认为这类无法验证的表述。这一条能过滤掉相当一部分编造内容。第二条是交叉验证关键数字。把模型输出的核心财务数字和你自己核对的数据做比对如果出现对不上的说明这一轮的数据注入环节有问题。我遇到过模型把两个季度的营收数字记混的情况追查下去发现是新闻抓取环节把不同公司的数据混在了一个文本块里。第三条是用确定性工具替代模型的记忆。凡是能通过计算得到的结果——比如各类技术指标、同比环比增速——不要让模型心算而是在代码里算好再喂给它。让模型做推理不要让模型做计算这是我在所有 LLM 金融应用上坚持的原则。第四条是限制输出长度。听起来反直觉但输出越长模型跑偏的概率越高。我会在提示词里给每类角色限定输出条数比如空头研究员最多列五条核心风险这样能逼它挑最重要的说而不是凑字数。5.3 把成本和时间压下来的几个实操手段除了前面说的快慢模型分离还有几个我自己在用的手段。批量任务错峰跑。模型服务在高峰时段的响应速度会明显下降限流也更频繁。我跑历史复盘这类不着急的任务时会放在夜间批量执行速度快不少重试次数也少。结果分层缓存。同一标的同一日期的分析师报告如果数据源没更新其实是可以复用的。我在自己封装的流程里加了一层判断先看结果目录里有没有同标的同日期的报告有就直接读跳过重复的模型调用。这一招在做参数对比实验时特别有用——你可以固定分析师阶段不变只改辩论轮数对比不同配置下的决策质量。分阶段执行。把分析和决策拆成两次运行中间人工介入看一眼。分析师报告出来之后先检查数据和论据有没有明显问题确认没问题再跑后续的辩论和决策。这样能避免在一个错误的基础上继续烧钱。数据预热。如果你要跑一批标的提前把行情和财报数据全部拉下来落到本地再让框架从本地读比边跑边拉快得多也不会因为中途限流导致流程中断。6. 我把它接进日常工作流的几点体会用了几个月之后我给这个框架的定位变得很清晰它不是替我做决定的它是我的反方辩手。我做完初步研究得出一个看多判断之后会把它跑一遍然后把空头研究员的那份报告单独拿出来读——如果里面有条论据是我没法反驳的那说明我的判断还有漏洞如果它的风险点全是我已经考虑过的那至少说明我的逻辑覆盖度还行。第二个体会是别指望一次配置永久有效。模型服务商在更新模型数据源在调整接口框架本身也在迭代我大概每个月会重新跑一次基线测试确认输出质量没有明显漂移。有一次某个模型服务更新之后结构化输出变得很不稳定我是在基线测试里发现的如果没这个习惯可能要等到某次重要决策出问题才察觉。第三个体会是关于数据源的取舍。默认的数据组合对美股覆盖不错但如果你关注的是其他市场很多字段是拿不到的这时候与其硬凑不如先把数据补齐——历史行情、财报三张表、公司公告这三样是基础中的基础有了它们分析师的输出质量会有质的提升。我自己的做法是把本地数据整理成统一格式再让框架从本地读取这样既不依赖外部服务的稳定性成本也低得多。最后分享一个我在调试阶段用的小方法用模型自己来检查模型。把分析师报告和原始数据一起丢给一个模型让它逐条核对报告里的每个数字和事实是否能在原始数据里找到依据输出一个可信度清单。这个方法不能完全消除幻觉但能快速筛选出明显有问题的输出帮我省下了大量人工核对的时间。调试新配置的时候我基本都会先跑一轮这个自检确认链路干净了再去正式使用。注意无论流程多完善这类框架的输出都只是研究参考不能替代你自己的判断也不能当作交易依据。把它的定位放对你才能从里面真正捞出有价值的东西。