在 LLM 应用从单智能体向多智能体演进的过程中，如何设计有效的角色协作机制与消息协议成为系统落地的关键挑战。TradingAgents 作为一个专注于金融交易场景的多智能体 LLM 框架，其架构设计提供了一种值得参考的实现思路。该框架通过将复杂的交易决策流程拆解为相互协作的专业角色，实现了分析、研判、交易、风险管理的有机配合，本文将从角色协作模式与消息协议两个维度进行深入解析。
多角色分层架构设计
TradingAgents 的核心设计理念是模拟真实金融机构的专业分工模式，构建了一套四层的智能体协作体系。最底层是分析师团队（Analyst Team），包含四个专业化角色：基本面分析师（Fundamentals Analyst）负责评估公司财务指标与内在价值；情感分析师（Sentiment Analyst）通过社交媒体情绪评分算法判断市场短期情绪走向；新闻分析师（News Analyst）监控全球新闻与宏观经济指标，解读事件对市场的影响；技术分析师（Technical Analyst）运用 MACD、RSI 等技术指标识别价格走势与交易模式。这四个角色并行工作，从不同维度对标的信息进行采集与初步分析。
第二层是研究员团队（Researcher Team），由看涨研究员（Bullish Researcher）和看跌研究员（Bearish Researcher）组成。两类研究员对分析师团队提供的观点进行批判性评估，通过结构化的辩论机制平衡潜在收益与固有风险。这种双向校验的设计有效避免了单一视角可能带来的认知偏差，使系统能够更全面地评估交易机会的可行性。
第三层是交易员智能体（Trader Agent），该角色的核心职责是整合分析师与研究员的见解，形成完整的交易决策报告。交易员需要确定交易的时机与规模，基于全面的市场洞察做出最终的操作建议。最后一层是风险管理团队与投资组合经理（Risk Management & Portfolio Manager），其中风险管理团队持续评估投资组合的波动性、流动性等风险因素，并向投资组合经理提供策略调整建议；投资组合经理则拥有交易的最终批准权，决定是否执行交易员提出的交易建议。
消息协议与信息流转机制
在 TradingAgents 的多智能体架构中，消息协议的设计直接影响协作效率。框架基于 LangGraph 构建图状态机，每个智能体作为图中的一个节点运行，节点间的边定义了消息传递的流向与条件。从信息流转的角度来看，整个流程可以概括为四个阶段：分析阶段、辩论阶段、决策阶段与风控阶段。
分析阶段中，四个分析师角色并行接收原始市场数据（如股票代码、分析日期），并各自输出结构化的分析报告。这些报告以统一的格式汇总后，传递给研究员团队进入辩论阶段。辩论阶段支持多轮交互，通过配置 max_debate_rounds 参数可以控制辩论的轮次，默认为两轮。每轮辩论中，看涨与看跌研究员轮流提出支持或质疑论点，消息内容被持久化到决策日志中，供后续的学习与回溯使用。
决策阶段由交易员智能体主导，该角色不仅接收分析师与研究员的输出，还会被注入历史决策信息。TradingAgents 的持久化机制会自动将同标的历史决策与跨标的经验教训注入交易员的提示词中，使每次分析都建立在历史反馈的基础上。这一设计体现了从实践中学习的能力，是多智能体系统向自主进化方向发展的关键一步。
风控阶段的消息流较为特殊，风险管理团队输出的风险评估报告并不直接触发交易，而是提交给投资组合经理做最终审批。这种设计将决策权与风险控制权分离，符合真实金融机构的风控逻辑。在实际配置中，可通过 llm_provider 参数选择不同的底层模型提供商，框架支持 OpenAI、Google、Anthropic、xAI、DeepSeek、Qwen、GLM、OpenRouter、Ollama（本地模型）以及 Azure OpenAI（企业版）等十余种选择。
关键可配置参数与调优策略
针对多智能体协作的性能优化，TradingAgents 提供了一系列可配置参数。在模型选择方面，deep_think_llm 参数用于指定执行复杂推理任务（如辩论、决策）的模型，建议使用能力较强的模型如 GPT-5.4 或 Claude 4.6；quick_think_llm 参数用于执行快速任务（如新闻摘要、情绪评分），可以使用较小尺寸的模型如 GPT-5.4-mini 以降低成本与延迟。这种分层模型策略在大规模部署时能够显著控制 Token 消耗。
辩论轮次 max_debate_rounds 的设置需要权衡决策质量与运行时间。增加轮次可以提升决策的全面性，但也会线性增加调用成本与响应延迟。对于高波动市场或大额交易，建议将轮次设置为 3 至 4 轮以获得更充分的辩论；对于常规交易，2 轮配置即可满足需求。框架默认配置为 2 轮，这是一个在质量与效率之间的平衡选择。
持久化与恢复机制通过 checkpoint_enabled 参数控制。当启用检查点功能时，LangGraph 会在每个节点执行完成后保存状态，一旦运行中断可从最后一个成功的节点恢复，而非从头开始重新运行。检查点文件存储在 ~/.tradingagents/cache/checkpoints/ 目录下的 SQLite 数据库中，每个标的对应一个独立的数据库文件。在长时间运行的交易分析任务中，启用检查点功能可以有效避免因网络波动或进程崩溃导致的工作丢失。
决策日志（Decision Log）是框架的另一个核心持久化机制，默认路径为 ~/.tradingagents/memory/trading_memory.md。每次完成交易决策后，系统会自动追加决策记录；当下次分析同一标的时，系统会获取已实现收益率数据，生成一段反思性的总结，并将其注入投资组合经理的提示词中。这一机制使多智能体系统具备了从历史决策中学习的能力，是实现持续优化的基础设施。
工程落地的监控与回调设计
在生产环境中部署 TradingAgents 时，需要关注几个关键的监控指标。首先是 Token 消耗监控，由于多智能体架构涉及多个角色的多轮调用，单次完整分析的 Token 消耗可能是单智能体的数倍。建议在调用入口处集成 Token 计数与成本追踪，以便及时发现异常消耗。其次是决策日志的完整性检查，确保每次决策都被正确记录，避免因日志丢失导致历史学习机制失效。
对于需要集成到自有系统的开发者，框架提供了 Python API 以替代 CLI 调用。通过 TradingAgentsGraph 类可以初始化智能体图，调用 propagate 方法传入股票代码与分析日期即可获得决策结果。返回值包含决策内容与完整的执行轨迹，可用于后续的审计与分析。在调试模式下（debug=True），框架会输出每个节点的详细执行信息，便于定位问题。
总体而言，TradingAgents 框架的多智能体架构通过角色专业化、消息协议结构化、持久化机制健全化三个设计要点，构建了一套可工程化部署的金融交易智能体系统。其基于 LangGraph 的实现提供了良好的扩展性，开发者可以在此基础上根据具体业务需求定制新的角色或修改消息流转逻辑。对于希望在金融场景中探索 LLM 多智能体应用的研究者与工程师而言，这套框架提供了有价值的架构参考与实现范式。
资料来源：GitHub - TauricResearch/TradingAgents