把多 Agent 协作搬到金融交易场景,是 2025 年到 2026 年 Agent 落地最具体的领域之一。Tauric Research 团队在 2024 年 12 月公开的 TradingAgents 框架,到 2026 年 9 月已经在 GitHub 上拿到 10 万以上 stars、2 万以上 forks,成为多 Agent 金融研究最有影响力的开源项目。它模拟真实交易公司的角色分工:基本
把多 Agent 协作搬到金融交易场景,是 2025 年到 2026 年 Agent 落地最具体的领域之一。Tauric Research 团队在 2024 年 12 月公开的 TradingAgents 框架,到 2026 年 9 月已经在 GitHub 上拿到 10 万以上 stars、2 万以上 forks,成为多 Agent 金融研究最有影响力的开源项目。它模拟真实交易公司的角色分工:基本面分析师、情绪分析师、新闻分析师、技术分析师,加上看多看空研究员、风险管理与最终下单的组合经理,试图用 LLM 推理替代研究员之间的讨论与判断。与此同时,2026 年下半年陆续出现的两个相邻项目——Premiss 把 Coding Agent 直接接进策略回测环境,xbrlmetrics 则曝出 LLM 在 SEC XBRL 数据管道里跑出 82.7% 的拆股调整错误——共同把"LLM 在量化场景的真实落地边界"摆到了台面上。
一、TradingAgents 是什么:一个模仿真实交易公司的多 Agent 框架
TradingAgents 的论文 arXiv:2412.20138(Yijia Xiao、Edward Sun、Di Luo、Wei Wang)把多 Agent 系统在金融场景的潜力明确写了出来:过去的工作要么是单 Agent 处理单一任务,要么是多 Agent 各自分头拉数据,缺乏对真实交易公司协作动态的模拟。TradingAgents 的目标就是补这个缺口——让 LLM 驱动的 Agent 扮演交易公司里的具体角色,在结构化的协作流程里互相补充。
这套框架的角色分工清晰。Analyst Team 由四类分析师组成:Fundamentals Analyst 看公司财务与基本面指标,Sentiment Analyst 聚合新闻头条、StockTwits、Reddit 帖子的市场情绪,News Analyst 关注全球新闻与宏观经济指标,Technical Analyst 用 MACD、RSI 这类技术指标识别价格形态。研究侧由 Bull 与 Bear 两个 Researcher Agent 互相辩论,平衡收益与风险。Trader Agent 把分析师与研究员的报告合成具体的交易决策。最后是 Risk Management Team 与 Portfolio Manager——风险管理团队持续评估波动率、流动性等风险因素,组合经理对交易提案做最终的批准或拒绝。
这套设计的工程价值在于把"分析师之间怎么协作"这件事从单 Agent 的长 prompt 里搬出来,变成结构化的多 Agent 流程。每个 Agent 只需要负责自己的窄任务,提示词更短、上下文更聚焦、判断更稳定。Agent 之间通过结构化的报告与辩论互相补充,而不是把所有逻辑塞进一个超长 system prompt。论文在累计收益、Sharpe ratio、最大回撤这三个指标上都给出了优于 baseline 的实验结果。
框架本身也是工程级的:GitHub 项目在 2026 年 8 月底发布了 v0.4.0 版本,290+ commits,9 个正式 release,支持 OpenAI、Anthropic、Google、xAI、DeepSeek、Qwen、GLM、MiniMax 等十余家 LLM provider,本地模型通过 Ollama、vLLM、LM Studio 都能接入,部署方式既支持 pip 安装,也提供 Docker 与 docker-compose。对一个研究框架来说,这种工程成熟度相当罕见,也是它能在 GitHub 上拿到 10 万 stars 的原因之一。
二、TradingAgents 的工程细节:持久化、检查点、可复现性
TradingAgents 之所以不只是一个 demo,是因为它在工程细节上做了三件事。
第一是 Decision Log 持久化。每次跑完一次分析,系统会把决策追加写到 `~/.tradingagents/memory/trading_memory.md`。下次跑同一个 ticker 时,系统会拉取实际收益(原始与相对 SPY 的 alpha),生成一段反思,把最近同 ticker 的决策与跨 ticker 的经验注入到 Portfolio Manager 的 prompt 里。这意味着 Agent 不是每次都从零开始,而是能"记得上次为什么错、这次该怎么调整"。
第二是 Checkpoint Resume。TradingAgents 基于 LangGraph 构建,可以选择启用 checkpoint——每个节点执行后保存状态,中途崩溃或中断可以从上一步恢复,而不是从头开始。每个 ticker 的状态存到独立的 SQLite 数据库:`~/.tradingagents/cache/checkpoints/
第三是对可复现性的诚实说明。TradingAgents 在文档里明确写了:LLM 驱动的框架,跑两次同一个 ticker、同一日期,结果可能不一样。原因是 LLM 采样本身就不确定性,推理模型(默认 GPT-5.x 系列)内部思维链也是采样出来的;新闻、StockTwits、Reddit 这些实时数据源每次跑都会变。降低温度可以减少差异,但推理模型本身就忽略温度设置,要做严格可复现必须换成非推理模型。文档也明确写了"Backtest results are not guaranteed to match any published figure"——回测结果不能保证匹配任何公开数字,这是研究脚手架,不是固定可复制的策略。这段坦诚说明比很多论文里"我们达到了 X% 收益"的乐观表述更可信。
三、Premiss:Coding Agent 直接接管策略回测
如果说 TradingAgents 是"模拟交易公司的分析师团队",那么 Premiss 是把 Coding Agent 直接放进策略研究环境。2026 年 8 月中旬在 Show HN 上发布的 Premiss 由独立开发者构建,核心定位是:让 Agent 在研究与回测环境里直接写代码、跑回测、看结果、迭代策略,而策略代码始终对用户透明。
Premiss 的设计动机来自一个观察:大多数现有交易平台仍然要求用户通过预定义规则与可视化编辑器搭建策略,这种范式对 Coding Agent 来说反而是束缚——把模型套在已有界面上,模型的表达力就被界面限制了。Premiss 反过来:平台本身围绕 Coding Agent 设计,Agent 能直接访问研究与回测环境,可以独立研究想法、写策略代码、运行回测、检查结果、再迭代。
这种设计的工程价值在于把"策略"从规则引擎的私有表示搬到代码这个公共表示。规则引擎里的策略是黑盒,代码里的策略是透明的——可以静态分析、可以 code review、可以版本管理、可以跨团队复用。Premiss 把这一点做到了产品层面。
Premiss 的作者也明确提到一个仍在摸索的问题:Agent 与系统确定性部分之间的边界该怎么划?回测引擎本身是确定性的,但 Agent 的策略想法、迭代方向、调参选择是探索性的。Premiss 的产品形态需要在"让 Agent 自由探索"与"让回测结果可复现"之间找到合适的张力。这条经验对所有做 Coding Agent + 量化研究的产品都通用——边界划得太死,Agent 失去创造力;划得太松,回测失去可信度。
四、xbrlmetrics 曝出的现实:LLM 在金融数据层的真实失败
把多 Agent 系统搬到金融场景,有一个绕不开的前提:数据本身要可靠。2026 年 9 月初在 Show HN 上展示的 xbrlmetrics 项目,把这件事的现实困难摆到了台面上。
项目作者搭建了一条数据管道,从 SEC EDGAR 拉取 600 多家公司的 10-K 与 10-Q 报表,把 XBRL 标签映射到约 35 个财务概念,然后用 yfinance 提供的价格计算成长性、基本面、估值等倍数。管道本身用 Anthropic Claude Fable 5 做 XBRL 标签的研究与映射,因为 XBRL 标签是"非监管、混乱的、野生西部",同一标签在不同公司可能完全不同义——一家公司某个标签能精确给出研发费用,另一家公司可能只给出部分数字,还有的公司干脆给垃圾数据。
这种数据清洗任务,五年前没有几百人做不下来,LLM 出现后才有了可能。作者花三周让 Claude Fable 5 反复遍历整个 ticker universe,搜索、对比、校验每个标签的可解释性。最后的审计结果是:**82.7% 的拆股调整是错的**。这个数字不是 LLM 推理的失败,而是数据源的失败——XBRL 本身的不规范导致任何自动化的财务数据管道都面临高错误率,LLM 也救不了根本性的数据质量缺陷。
这件事对量化场景的启示非常直接:多 Agent 框架无论设计得多精巧,如果输入数据本身不可信,所有推理都建立在沙子上。TradingAgents 的 Analyst Team 看起来分工合理,但它读到的财报数据如果存在 82.7% 的拆股调整错误,后续所有基本面判断都会被污染。Premiss 的 Coding Agent 能写策略、能回测,但如果回测用的历史价格数据本身有错,策略评估也就失去意义。
五、两条线的共同底层逻辑
TradingAgents、Premiss、xbrlmetrics 三个项目看起来在做不同的事——多 Agent 模拟交易公司、Coding Agent 写交易策略、LLM 清洗金融数据——但它们共享三个底层逻辑。
第一个逻辑是"分工优于单干"。TradingAgents 把分析师拆成四类,把研究员拆成多空双方,把决策拆成交易员、风险管理、组合经理三个角色;Premiss 把"写策略、跑回测、看结果、迭代"拆成 Coding Agent 与确定性回测引擎的协作;xbrlmetrics 把"拉数据、映射标签、计算倍数"拆成 Claude 推理与人工审计的协作。三个项目都认同一件事:复杂任务不能靠单个万能 Agent,必须把职责切清楚。
第二个逻辑是"透明优于黑盒"。TradingAgents 的策略代码是公开的,Premiss 的策略代码是公开的,xbrlmetrics 的整个数据管道是开源的。三个项目都不愿意把核心逻辑藏在私有规则引擎里,而是让代码本身成为协作的基础——LLM 写的代码可以被人审阅,人写的代码可以被 LLM 改进。
第三个逻辑是"诚实优于乐观"。TradingAgents 的文档明确写了回测结果不能保证匹配任何公开数字;Premiss 的作者承认 Agent 与确定性部分的边界还在摸索;xbrlmetrics 的审计结论是 82.7% 的拆股调整错了。这种对自身局限的诚实,比很多论文里"我们达到了 X% 收益"的乐观表述更有工程价值。
六、企业落地时该选哪条路
这三个项目不是互斥的,而是覆盖不同需求。TradingAgents 适合"已经有一套研究流程,想把分析师团队的部分工作自动化"的场景;Premiss 适合"研究团队本身就在写代码,想要 Coding Agent 加速策略迭代"的场景;xbrlmetrics 适合"数据管道本身有问题,需要专门的清洗与审计工具"的场景。
对企业架构师而言,优先级通常是先做数据层,再做模型层。xbrlmetrics 揭示的现实很清楚:如果输入数据不可信,所有模型层的优化都是空中楼阁。在部署 TradingAgents 或 Premiss 之前,先花时间审计数据管道、明确错误率、建立数据质量基线,这一步比任何模型调参都重要。
具体到实施阶段,有三条经验值得参考。第一,把多 Agent 系统的角色边界画在文档里——谁负责基本面、谁负责情绪、谁负责技术、谁负责风控、谁负责最终决策,这些边界一旦清楚,后续调试与扩展就有抓手。第二,把回测结果的不确定性明确告诉业务方——TradingAgents 的坦诚说明应当成为所有量化项目的标配文档,而不是用平均收益掩盖单次运行的巨大波动。第三,把审计能力作为数据管道的一等公民——xbrlmetrics 的 82.7% 拆股调整错误,如果当时没有审计流程,可能永远不会被发现。
七、组织层面的工程纪律
技术选型之外,企业级量化 Agent 的落地还需要组织层面的纪律。一个常见误区是"多 Agent 越多越好"——把研究流程拆得过细,每个环节一个 Agent,看似专业,实则通信开销巨大、出错定位困难。TradingAgents 的设计里隐含了一个原则:角色划分要按"功能边界"而非"看起来更细",基本面、情绪、技术、风险四个维度本身在研究公司里就是四个独立团队,这种天然边界是 Agent 拆分的合理依据。
另一个常见误区是"LLM 能解决一切数据问题"——把脏数据丢给 LLM 就以为能洗干净。xbrlmetrics 的经验恰恰相反:LLM 能加速数据清洗,但不能替代根本性的数据治理。XBRL 的混乱是结构性的,需要标签标准化、字段校验、异常告警这些基础设施层面的工作,LLM 只是辅助工具。
最后一个值得强调的点是 HITL(human-in-the-loop)。TradingAgents 的 Portfolio Manager 是最终的批准环节,Premiss 的回测结果需要人审核,xbrlmetrics 的 82.7% 错误率是人工审计发现的——三个项目的共同点是,在关键决策点都保留了人的判断。LLM 能做研究、能写代码、能清洗数据,但"该不该把这笔交易发出去、这个策略能不能上线、这个数据能不能用"的判断仍然属于组织与人。
八、结语:多 Agent 量化是工程题而不是模型题
把多 Agent 系统推到金融交易场景,让它跑出像样的回测结果是第一步,让它在真实市场里稳定输出可信信号是第二步。TradingAgents 用结构化的角色分工模拟交易公司的协作,Premiss 用 Coding Agent 把策略研究搬到代码环境,xbrlmetrics 则用 82.7% 的拆股调整错误提醒所有人——数据本身不可信,所有模型层都是空谈。三个项目共同指向一个判断:多 Agent 量化的下一步,不是更大的模型,而是更扎实的数据治理、更明确的人机分工、更诚实的回测说明。
这也是为什么 2025 年到 2026 年这三个项目值得企业架构师关注:它们都不是在做"更聪明的 AI 交易员",而是在做让量化研究在企业里可复现、可审计、可治理的基础设施。当这套基础设施逐步成熟,企业级多 Agent 量化的下一步——从研究脚手架走到生产级策略——才有真实落地的可能。