TradingAgents API 配置

先说结论:三项配置,随处能跑

TradingAgents 原生支持自定义端点。把 llm_provider 设成 "openai_compatible",backend_url 设成你的端点地址,再导出 OPENAI_COMPATIBLE_API_KEY。经 kkaiapi,backend_url 填 https://api.kkaiapi.com/v1,目录里的每个模型都能通过精确的模型 ID 在 deep_think_llm 和 quick_think_llm 两个槽位里寻址。 这是上游仓库文档记录在案的配置路径,不是分叉或补丁。同样的值也能通过环境变量提供(TRADINGAGENTS_LLM_PROVIDER、TRADINGAGENTS_LLM_BACKEND_URL、TRADINGAGENTS_DEEP_THINK_LLM、TRADINGAGENTS_QUICK_THINK_LLM),定时任务或 CI 跑者不改 Python 代码就能切后端。

config["llm_provider"] = "openai_compatible"
config["backend_url"] = "https://api.kkaiapi.com/v1"
# 鉴权:export OPENAI_COMPATIBLE_API_KEY=sk-你的kkaiapi密钥

TradingAgents 怎么跟它的 LLM 后端对话

TradingAgents(GitHub 上的 TauricResearch,93K+ 星标)是一个多智能体交易框架。一次分析会在覆盖基本面、情绪、新闻、技术面的分析师团队里展开,接着看多研究员和看空研究员就结论展开一轮或多轮辩论,交易员智能体提出仓位建议,风控层在最终决策前再审一遍。 框架把这份工作拆到两个可配置的模型槽位。deep_think_llm 负责推理密集的步骤:研究辩论、交易决策、风控审核。quick_think_llm 负责高频量大的步骤:读数据、总结新闻、写分析师报告。两个槽位发的都是标准 /v1/chat/completions 请求,provider 设置只决定这些请求发到哪个客户端和主机,openai_compatible 会把它们发到你配置的 backend_url。 TradingAgents 原生也支持 OpenAI、Anthropic、Google、DeepSeek 作为一级 provider,但每一个都要单独开账号、单独拿 Key,一次跑还只能挂一个 provider。openai_compatible 模式把这些合并了:model 字段原样按字符串传递,当 backend_url 背后的端点同时提供多个厂商的模型时,深度思考槽用 Claude、快速思考槽用 GPT 或国产模型,可以在同一场分析里跑。这种按角色混搭正是把框架经网关而不是单一厂商端点接入的实际理由。

完整配置:Python 代码或环境变量

编程式配置的做法是复制 DEFAULT_CONFIG 后覆盖四个键。鉴权用的 Key 从 OPENAI_COMPATIBLE_API_KEY 读取,不需要出现在配置字典或源文件里。 环境变量路径通过 default_config.py 里的 _ENV_OVERRIDES 映射设置同样的值,Python API 和交互式 CLI(tradingagents,或 python -m cli.main)都认这套值。注意 backend_url 默认是 None,这时每个 provider 的客户端会退回自己的默认端点,只有显式设置之后覆盖才会生效。 行情数据是独立的关切。TradingAgents 通过自己的数据供应商拉行情和基本面数据(比如 ALPHA_VANTAGE_API_KEY),这些凭证和 LLM 端点无关,改 backend_url 不会动数据管线。

from tradingagents.graph.trading_graph import TradingAgentsGraph
from tradingagents.default_config import DEFAULT_CONFIG

config = DEFAULT_CONFIG.copy()
config["llm_provider"] = "openai_compatible"
config["backend_url"] = "https://api.kkaiapi.com/v1"
config["deep_think_llm"] = "claude-opus-4-8"   # 辩论轮次 + 交易决策
config["quick_think_llm"] = "claude-sonnet-5"  # 分析师、摘要
config["max_debate_rounds"] = 2

ta = TradingAgentsGraph(debug=True, config=config)
_, decision = ta.propagate("NVDA", "2026-07-16")
print(decision)

deep_think 与 quick_think 怎么选模型

上游默认值把旗舰模型放深度槽、mini 模型放快速槽,这个形状是对的:推理能力花在做决策的地方,量的能力花在读数据的地方。经一个端点接入,让这个配对在两次跑之间变成一次两行改动,实际工作流是固定深度槽,拿快速槽在自己的回测指标上做 A/B,而不是凭猜测。

• deep_think_llm 扛下看多/看空辩论、交易决策、风控审核。一次跑调用次数不多,但每次都要在完整分析师上下文上推理,max_debate_rounds 还会成倍放大,这是旗舰推理模型(claude-opus-4-8、gpt-5.5)该花钱的地方
• quick_think_llm 在每个分析师步骤上触发:读基本面、给情绪打分、总结新闻、写报告。一次跑的大部分请求量落在这里,一个快速的中端模型(deepseek-v4-flash、glm-5)能让跑起来更快而不拖累辩论输入质量
• 把完整财报或大段新闻窗口喂给分析师这类长上下文负载,值得在快速槽位试一下 gemini-3.1-pro-preview
• 回测会放大一切。50 只标的乘 20 个日期就是 1000 次 propagate() 调用,一次跑看起来无关紧要的 quick_think 模型选择,在回测规模下会主导 token 账单

主力模型价格

价格按 kkaiapi 中文区实时价格计算,单位 ¥/1M tokens(输入/输出)。

规模化回测:Key、锁版本、并发上限

单次跑通之后,失败面会转移到扫描规模的回测上。三个习惯能让一次多日回测保持可复现、可排查。 锁定精确的模型 ID。裸模型名在某些厂商那里是滚动指针,会悄悄迁移到更新的快照,意味着周一开始、周五跑完的回测,可能中途换了一个模型。把精确 ID 写进配置,像记录随机种子一样把配置字典和结果存在一起。 每个实验用一个独立 Key。Key 免费创建,给一次扫描单独分配一个 Key,能把用量日志变成这次实验的成本账本:每个模型的 token 数和花费,精确过滤到这次扫描里的调用。两个实验共用一个 Key,事后归因花费就只能靠翻时间戳。 并行化之前先摸清并发上限。propagate() 对每个标的-日期是同步调用,所以扫描通常按进程分片。每个分片都会先冲击 quick_think 槽的请求速率,辩论中途一次 429 报错的代价是整场跑,不是一个请求。逐步加分片数量、边看控制台边加,而不是冷启动五十个 worker;后端的多渠道池会抬高上限,但不会让上限消失。

验证接入与排查首次跑

跑完整分析前,先确认端点用你计划用的模型能应答。一条 curl 打 /v1/models 带上 Key,能列出每个可寻址的 ID;deep_think_llm 和 quick_think_llm 里的字符串必须和这些 ID 精确匹配。 首次跑的失败很规律。401 几乎都是 OPENAI_COMPATIBLE_API_KEY 导出在了跑 tradingagents 的另一个 shell 里,或者根本没导出。模型不存在的报错说明 ID 字符串和目录不匹配,ID 是精确的,包括版本后缀,上面的 /v1/models 输出是权威来源。连接错误且 backend_url 已设置,通常是 URL 缺了 /v1 后缀,客户端会在你给的 base 后面拼接 /chat/completions 这类路径。 如果跑起来了但卡在辩论阶段,这对推理模型在长上下文上的正常延迟来说是常态,不是端点问题,保持 debug=True 能看到 Agent 逐步的输出。非常长的深度思考轮次上真正的超时是客户端侧的设置,在断言后端丢了请求之前先调大它。 请求跑通之后,kkaiapi 控制台会显示每次请求的模型、token 数和花费,对这种调用密集的框架来说,这是看清一次跑的 token 到底花在哪里最快的方式。

curl -s https://api.kkaiapi.com/v1/models \
  -H "Authorization: Bearer $OPENAI_COMPATIBLE_API_KEY" | head -50

常见问题