源码级核验：requirements.txt + 上游 tradingagents/graph/setup.py@v0.5.0
PanWatch 的深度分析到底跑了什么：12 个节点、两种模型与一次分析的真实成本
PanWatch 把「多 Agent 投资决策」作为核心卖点，但官方 README 只说「9-Agent 投研团队」，没有列出这 9 个是谁。本页把上游锁定版本、节点清单、默认参数与失败模式从源码里数出来——你会发现真实节点是 12 个，而「9」在仓库里找不到对应名单。
它调的是哪个 TradingAgents？锁定版本与安装代价
PanWatch 不是「调用一个 API」，而是把上游仓库作为依赖直装。因此上游版本决定了你会看到什么行为。
| 项目 | 取值 | 来源与边界 |
|---|---|---|
| 依赖声明 | tradingagents @ git+https://github.com/TauricResearch/TradingAgents.git@v0.5.0 | requirements.txt（锁 tag，不是 @main） |
| 对应上游 commit | 2d17df8da1536c121e4d7395ac5a5dcec9e96d6f | GitHub API 解析 tag v0.5.0 得到 |
| 上游许可与规模 | Apache-2.0；2026-09-29 实测 109,117 star / 20,937 fork，创建于 2024-12-28 | 上游仓库 API（本站实测，非转述） |
| README 里的旧数字 | PanWatch README 写「76k+ star / more than 76k stars」 | 已过期：与上游当前数字差距约 3 万 |
| 安装代价 | 首次安装会拉约 115 个依赖包（langchain / langgraph / yfinance 等），耗时约 2–5 分钟 | requirements.txt 注释 |
| 不启用时的开销 | 零开销——只有真正启用「TradingAgents 深度分析」Agent 时才会调用 | 同上（官方注释） |
上游 v0.5.0 的真实节点有哪些？12 个，不是 9 个
下表来自上游 tradingagents/graph/setup.py 的 setup_graph()，逐个节点数出来的。
| 阶段 | 节点 | 角色 | PanWatch 是否启用 |
|---|---|---|---|
| 分析师（默认 4 个） | market | 市场 / 技术面分析 | 启用（analyst_types 列表首位） |
social | 情绪分析（由 create_sentiment_analyst 渲染） | 启用 | |
news | 新闻分析 | 启用 | |
fundamentals | 基本面分析 | 启用 | |
| 研究辩论 | Bull Researcher | 看多研究员 | 启用，与看空辩论（默认 1 轮） |
| Bear Researcher | 看空研究员 | 启用 | |
| Research Manager | 研究主管：汇总结论 | 启用 | |
| 交易 | Trader | 交易员：形成投资计划 | 启用 |
| 风控 | Aggressive Analyst | 激进方 | 启用 |
| Neutral Analyst | 中立方 | 启用 | |
| Conservative Analyst | 保守方 | 启用 | |
| 决策 | Portfolio Manager | PM 整合，输出最终决策书 | 启用 |
sentiment_analyst.py 与 social_media_analyst.py 两个文件，但 setup.py 的工厂函数只把 social 映射到 create_sentiment_analyst——也就是说「社交媒体分析师」这个文件没有被接线。③ 由于这些都随上游版本变化，本页写的是 v0.5.0 的快照。一次深度分析从点击到收到结论，中间发生了什么
下面把「触发 → 取数 → 图执行 → 映射 → 推送」串成一条链；每一步都能在源码里找到对应实现。
从点击到收到结论的七个环节
single 模式，会先检查该标的所属市场是否在交易时段。data_context.py），并通过工具适配层把行情工具暴露给上游（toolkit_adapter.py）。final_state 映射成本站能展示的分析结果，解析 PM 正文里的评级标签，并决定是否标记为「待人工复核」。哪些默认参数决定账单与体验？十一个关键取值
下表全部来自 agent_catalog.py 里深度分析的默认 config；这些值比「单次 0.05 美元」这种宣传数字更能决定你的实际体验。
TradingAgents 深度分析的默认 config（agent_catalog.py）"analyst_types": ["market", "social", "news", "fundamentals"],
"debate_rounds": 1, # 多空辩论轮数
"monthly_budget_usd": 10.0, # 月度预算上限
"over_budget_action": "reject", # 超预算时的动作：直接拒绝执行
"cache_ttl_hours": 12, # 同标的结果缓存时长
"deep_model": "", # 留空 = 用默认 AI 服务商的模型
"quick_model": "", # 留空 = 与 deep_model 相同
"timeout_minutes": 15, # 单次分析总超时
"llm_timeout_seconds": 120, # 单次模型请求超时
"llm_max_retries": 0, # 图内重试次数：0 = 失败快速落终态
"llm_max_tokens": 4096, # 限制输出，避免网关空闲超时
"emit_paper_trading_signal": False, # 是否把 BUY 写入模拟盘信号
"enable_sec_edgar": False, # 仅美股：优先用带 filing 时间的 SEC EDGAR 财报
"holding_period_days": 5, # 上游决策质量回测用的持仓期限| 参数 | 默认值 | 它实际控制什么 | 什么时候该改 |
|---|---|---|---|
debate_rounds | 1 | 多空辩论轮数；轮数越多越贵也越慢 | 想让双方多交锋一轮可以加到 2，但成本近似翻倍 |
monthly_budget_usd / over_budget_action | 10.0 / reject | 月度花费上限；超限时直接拒绝执行而不是降级 | 预算敏感就保持 reject；这样最坏结果是「不分析」而不是「账单失控」 |
cache_ttl_hours | 12 | 同一标的 12 小时内的重复分析直接复用结果 | 短线盯盘可缩短；只在盘后复盘可加长 |
deep_model / quick_model | 空（用默认） | 把贵模型留给决策、便宜模型做采集，可显著压成本 | 想控成本时是最有效的一个开关 |
timeout_minutes | 15 | 单次分析总超时 | 标的特别多或模型特别慢时可延长 |
llm_timeout_seconds | 120 | 单次模型请求超时 | 网关有空闲超时限制时，配合 llm_max_tokens 一起调 |
llm_max_retries | 0 | 图内重试次数 | 官方注释写明是「深度分析失败快速落终态，不在图内重复重试」——失败就是失败，不烧钱重试 |
llm_max_tokens | 4096 | 限制单次输出长度，避免网关空闲超时 | 模型输出被截断时可上调 |
emit_paper_trading_signal | False | 是否把买入结论写进模拟盘信号 | 建议保持关闭；打开也只处理买入方向 |
enable_sec_edgar | False | 仅美股：用带 filing 时间语义的 SEC EDGAR 财报 | 做美股基本面时打开，能改善数据时点问题 |
holding_period_days | 5 | 上游决策质量回测的默认持仓期限 | 注意它与模拟盘桥接里写死的 10 天不是同一处参数 |
这条链可能在哪里断：五种失败与它们的表现
多 Agent 链路的价值在于「分工」，代价是环节多、每环都可能失败。下表按环节列出失败表现。
| 环节 | 可能的失败 | 表现 | 设计上的处理 |
|---|---|---|---|
| 触发前 | 该市场当下不在交易时段 | 点下去没反应或直接跳过 | single 模式按市场时段跳过，日志有记录 |
| 预算检查 | 本月花费已达上限 | 分析不执行 | over_budget_action=reject：拒绝而非降级 |
| 缓存命中 | 12 小时内分析过同一标的 | 几乎立即返回旧结论 | 这是省钱机制，不是故障；看分析时间戳即可确认 |
| 上游图执行 | 模型超时 / 网关空闲断连 | 运行失败并落失败终态 | llm_max_retries=0：不重试，避免重复烧钱 |
| 评级解析 | PM 输出无法解析出评级 | 标记为「待人工复核」 | REVIEW 不等同于「持有」，也不会触发自动交易动作 |
REVIEW 语义——当无法解析 PM 评级时返回 REVIEW，而 PanWatch 明确把它处理成「待人工复核」并降级为不触发自动交易的状态，而不是当成「持有」混过去。官方注释原文：REVIEW 不是可交易的 Hold。这也是本站建议把结论当第二意见而非指令的原因之一。对话助手用的是什么运行时？一套独立的 Agent 内核
PanWatch 把「受限 Agent 执行内核」抽成了与业务无关的包（pan-agent-runtime，import 名 pan_agent），对话助手就跑在它上面。它的设计边界对理解「AI 能不能自己动你的数据」很关键。
| 机制 | 规则 | 对你的意义 |
|---|---|---|
| 工具风险分级 | read / write / external / destructive 四级 | 读操作可默认放行，写与外部副作用需要宿主策略决定 |
| 默认策略 | ReadOnlyToolPolicy 只暴露风险等级为 read、且无需确认的工具 | 即使模型想写，也过不了默认策略 |
| 人工审批 | 遇到需要审批的调用会暂停并返回 WAITING_FOR_APPROVAL | 可以只批准其中一张审批卡，其余保留 |
| 恢复执行 | resume 不要求同一个 runtime 实例 | 只要宿主持久化了 checkpoint，换进程也能继续 |
| 执行限额 | 默认 max_steps=6、max_tool_calls=8、工具超时 20s、总超时 90s | 单次对话不会无限循环烧钱 |
| 循环熔断 | 检测连续重复的相同工具调用并返回 repeated_tool_call | 模型卡在错误参数上时会主动中断 |
| 工具渐进暴露 | ToolSpec.exposure 可设 direct / deferred / hidden | 工具变多时用检索而不是全量塞进上下文 |
TradingAgents 研究链常见问题
答案基于固定 commit 的官方源码与文档；上游节点与默认值会随版本变化，以你实际锁定的版本为准。
相关页面：AI 输出审计与后验复核 · 运行成本与运维安全
它用的到底是哪个版本的 TradingAgents？
PanWatch 在 requirements.txt 里锁定了 @v0.5.0（不是跟踪 @main），对应上游 commit 2d17df8da1536c121e4d7395ac5a5dcec9e96d6f。锁定 tag 的好处是行为可复现；想追新需要自己改依赖并承担上游变更风险。
README 说的「9-Agent」到底是哪 9 个？
没有名单。上游 v0.5.0 的图里实际是 12 个节点：4 个分析师 + 看多/看空研究员 + 研究主管 + 交易员 + 三方针险分析师 + PM。PanWatch 自己的流程图文档写的是「四类分析师 → 多空辩论 → 风控 → PM」。本站把三处口径并列，而不是替官方选定一个说法——本页的节点清单是从上游源码数出来的。
一次深度分析大概多少钱？
官方 README 给的口径是「默认 deepseek-chat，单次约 0.05 美元、3–5 分钟」。但更值得看的是控制机制：月度预算默认 10 美元、超预算直接拒绝执行、同标的 12 小时内复用结果、单次总超时 15 分钟、图内重试 0 次。这些参数决定了你的账单上限，本站不复制任何模型单价。
为什么我的分析失败了却不自动重试？
因为官方把 llm_max_retries 默认设为 0，注释写明「深度分析失败快速落终态，不在图内重复重试」。这是一个成本取舍：多 Agent 链路重试一次可能就要再花一遍钱。要重试请手动再触发一次。
分析结论会直接写进模拟盘吗？
默认不会。emit_paper_trading_signal 默认 False，需要你主动打开；而且即使打开，桥接逻辑也只处理买入方向（buy/add），卖出不会开新仓，入场区间与止损止盈是用当前价按固定比例算的粗略值。
能不能只跑便宜模型？
可以。深度分析支持把 deep_model 与 quick_model 分开配置：留空表示都用默认模型，填便宜模型可以做采集、贵模型只做决策。官方还提示可以配 Ollama 走本地模型，从而把按量计费换成硬件成本。
这条链的输出可以直接用来下单吗？
不建议，也不符合官方定位。项目是监控与研究工具；评级无法解析时会被标为「待人工复核」，通知也只推决策摘要。合理用法是把它当第二意见，并按输出审计页的清单逐项复核。