企业官网建设流程全解析

TradingAgents 这个项目我前后折腾了差不多两个月，从最早只是想看看"多智能体到底能不能拿来读财报"，到后来真的把它当成一个半自动的研究助理跑在本地，中间踩的坑不算少。它不是那种装完就能给出买卖点的黑盒工具，更像是一套把"投研团队开会"这件事拆成代码的开源框架：分析师先各自出报告，研究员分多头空头互相怼，交易员拍板，风控团队再上来挑刺，最后组合经理给结论。整个过程用状态机串起来，每一步的推理过程都留痕。这篇文章我想把它的设计逻辑、智能体分工、环境跑通步骤、成本控制、常见报错排查，以及我后来做的几次二次改造，完整地讲一遍。适合两类人看：一类是做过一点量化或数据分析、想了解多智能体框架怎么落地到具体业务场景的工程师；另一类是做行业研究、想给自己搭一套"不眠不休的初筛助手"的从业者。代码细节我会尽量给到能直接抄的程度，但会明确标出哪些是官方仓库里的东西，哪些是我自己补的。

1. 项目整体设计与思路拆解

1.1 为什么是"多智能体"而不是"一个大模型加一段长提示词"

刚接触这个方向的时候，我第一反应是：为什么不直接写一段超长提示词，让 GPT 一口气把技术面、基本面、情绪面全分析了？答案在实测里很快就出来了。单个模型在一条上下文里同时处理四类信息时，会出现明显的"注意力塌陷"——它会把大部分推理预算花在最先出现的新闻文本上，后面的财报数字基本被忽略；而且它天然倾向于给出模棱两可的结论，因为"综合来看建议观望"这种话在任何训练语料里都是安全答案。

TradingAgents 的做法是把这件事拆开。每个分析师的上下文是隔离的：基本面分析师只拿到财报和财务比率，技术面分析师只拿到价格和成交量指标，新闻分析师只拿到公告和媒体报道，情绪分析师只拿到社交平台上的讨论热度。这样做的好处有三个。第一，上下文长度可控，每段提示词都能塞进更多高信噪比的原始数据，而不是被无关内容稀释。第二，角色分工带来视角冲突，冲突本身就是信息——多头研究员和空头研究员在辩论时被迫引用具体数据来反驳对方，这个"被迫引用"的动作，比任何一句"我认为"都值钱。第三，全链路可观测，哪一环判断错了可以单独回放，而不是面对一大坨不可解释的输出。

注意：框架的"多智能体"本质是多次独立的 LLM 调用 + 结构化状态传递，不是真的并行训练了多个模型。理解这一点很重要，因为它直接决定了成本模型——调用次数是可以数的，钱是可以预算的。

1.2 骨架：一张用状态机串起来的投研流程图

整个项目的执行骨架是一张有向图。节点是各个智能体，边是状态流转关系，中间共享一个全局状态对象。我把它简化成四层来看，会清楚很多。

第一层，分析师层，四个节点并列，各自独立跑，互不干扰，跑完把报告写进状态的四个字段。

第二层，研究员层，看多和看空两个研究员轮流发言，围绕分析师产出的报告做多轮辩论，最后由研究主管（Research Manager）汇总成一份投资计划。

第三层，交易员层，拿到投资计划后，结合当前仓位和价格，输出一个明确动作：买入、卖出还是持有，以及数量级。

第四层，风控层，这是我觉得设计得最妙的地方——三个风险偏好不同的角色（激进、中性、保守）针对交易员的方案再做一轮辩论，最后由组合经理做终审裁决，可以推翻交易员的结论。

这个"决策—对抗—再决策"的结构，其实抄的是真实投研机构的流程。我在实际用的时候明显感觉到，最终结论的质量高低，往往不取决于分析师写得多好，而取决于辩论轮数够不够。轮数太少，空头还没发力就结束了；轮数太多，两边开始车轱辘话来回说，边际收益递减得厉害。

1.3 它和传统量化框架的边界在哪

这一点必须说清楚，否则很容易用错。TradingAgents 不是回测引擎，也不是执行系统。它没有撮合逻辑、没有滑点模型、没有仓位管理算法，它输出的是一段自然语言加上一个方向性判断。它自带的那个"回测"功能，严格来说是事后验证：拿它给出的信号，和之后几天的实际涨跌做个对比，算一下命中率和收益分布，用来评估框架本身的判断质量，而不是用来跑策略曲线。

我一开始也误解过，想着直接拿它的输出接一个交易接口。真这么干之前先冷静一下：单个标的单次分析的推理成本在几十美分到几美元之间，延迟从几十秒到十几分钟不等，这个量级根本撑不起日内交易。它真正有价值的场景是低频、深度、需要解释的决策——比如周度调仓前的候选池筛选，比如给某个持仓写一份"多方观点汇编"，比如把一份财报的四种解读角度一次性铺开摆在面前。把定位摆正，后面的期待值就不会跑偏。

2. 多智能体分工与协作链路拆解

2.1 四个分析师：各自看什么、产出什么

分析师层是整个系统的输入侧，质量上限基本由他们决定。下面这张表是我按实际跑下来的感受整理的，包含每个角色的数据来源、核心关注点和常见失效场景。

有一点必须强调：这四个分析师的输出是并列的，没有主次权重。框架不会告诉你"基本面比情绪面重要三倍"，这个权重隐含在后续研究员的辩论和组合经理的裁决里。如果你希望某个维度占更大话语权，得自己动手改提示词或者改状态字段的拼接顺序——我在自己那版里就把基本面报告放在了研究员提示词的最前面，实测下来最终结论对财务数据的引用密度明显上升。

每个分析师内部都不是"一问一答"，而是一个小的工具调用循环：模型先决定要看什么数据，调用工具拿到结果，再决定要不要继续挖，直到它认为信息够了才输出报告。这个循环的深度由配置里的研究深度参数控制。浅度模式大概两三轮就收，深度模式能跑到七八轮，报告明显更厚实，但成本也涨得快。

2.2 看多与看空的辩论：把"抬杠"变成一种机制

研究员这一层是我最喜欢的设计。两个角色拿到的原始材料完全一样，但系统提示词把它们锁定在对立立场上：一个必须找出所有支持买入的证据，另一个必须找出所有支持卖出或观望的证据。它们轮流发言，每一轮都能看到对方上一轮说了什么。

这个机制解决了一个很实际的问题。单独问一个模型"这只股票能不能买"，它十有八九给你一段四平八稳的废话。但当你明确说"你是空头研究员，你的任务是找出这份投资逻辑里的漏洞"，它会突然变得非常犀利，会去揪基本面报告里"营收增长但经营性现金流下滑"这种细节。我在实测中见过好几次空头研究员直接把多头研究员的估值假设拆掉，指出对方用的同业可比公司根本不是同一赛道。

辩论轮数是核心参数。我的经验值是这样的：

• 轮数为 1：基本等于走个过场，空头反驳一轮就结束，结论偏向多头。
• 轮数为 2 到 3：性价比最高的区间，两边都能完整表达，冲突点清晰。
• 轮数为 4 以上：开始出现重复论证，token 消耗线性上涨但信息增量很小。

辩论结束后，研究主管会拿到全部发言记录，产出一份"投资计划"。这份计划不是简单投票，而是一份带有明确逻辑链条的文字，包含方向、理由、以及关键假设。这份文件是整个流程里我最常单独拿出来看的东西，因为它把多空双方的冲突点浓缩成了一段可读性很强的文字，比后面那些结论性的判断有价值得多。

2.3 交易员与风控团队：三层对抗式决策

交易员拿到投资计划后，输出的是一个结构化对象，包含动作方向和数量级。这里框架做了强制约束——动作只能是买入、卖出、持有三者之一，不能含糊其辞。这个约束看起来简单，实际上非常关键：自然语言模型天然倾向于输出"建议谨慎参与"这类无法执行的表述，用结构化解码把它逼到墙角，才能得到可统计的信号。

然后是风控层。三个角色的设定大致是：激进派会质疑交易员"太保守，错失机会"，保守派会质疑"风险敞口过大，止损位不合理"，中性派做平衡。它们同样进行多轮讨论，最后由组合经理裁决。

我在跑的过程中发现一个有意思的现象：风控层经常推翻交易员的结论，而且推翻的理由通常集中在"仓位规模"而不是"方向"上。也就是说，方向判断大多能通过，被砍掉的往往是数量级。这个观察对我理解整个框架的定位很有帮助——它更像一个谨慎的投资委员会，而不是一个激进的信号发生器。

2.4 状态对象与结构化输出：让自然语言能被程序消费

整条链路能被串起来，靠的是一个在所有节点间传递的状态对象。它大致包含这么几块内容：待分析标的、分析日期、四份分析师报告、辩论历史、投资计划、交易员方案、风控辩论记录、最终裁决，以及每个环节的完整消息日志。

这里有个工程细节值得单独讲：框架在多个环节使用了结构化输出约束。比如交易员的输出会被强制成"动作 + 数量"的格式，组合经理的裁决也会被解析成固定字段。这样做的好处是后续可以批量统计——你能很方便地跑一百个标的，然后把所有结论汇总成一张表，算方向分布、算动作和实际涨跌的相关性。

但也带来一个坑：模型偶尔会输出不符合格式的内容，导致解析失败。我在早期版本上遇到过几次，表现是流程跑完但最终决策字段是空的。解决办法有两层，一是换用支持结构化输出的模型和接口，二是在自己的代码里加一层兜底解析——先用正则从文本里提取方向关键词，如果拿不到再做一次单独的轻量级调用让它只输出一个词。这层兜底后来帮我省了不少重跑时间。

3. 从零跑通一次完整分析

3.1 环境准备与密钥配置

先把运行环境说清楚。项目是标准的 Python 工程，我建议用 3.10 及以上的版本，3.11 实测最稳。用虚拟环境隔离依赖是必须的，因为它的依赖树里有一些对版本比较敏感的包，直接装到全局环境里很容易和别的项目打架。

# 1. 拉取代码（换成你自己的目录习惯） git clone https://github.com/TauricResearch/TradingAgents.git cd TradingAgents # 2. 建虚拟环境 conda create -n tradingagents python=3.11 -y conda activate tradingagents # 3. 安装依赖 pip install -r requirements.txt # 4. 让本地能直接 import 这个包 pip install -e .

第四步的pip install -e .很多人会漏掉，结果在别的目录下执行脚本时报找不到模块。加上它之后，无论你在哪个路径下写调用脚本，都能正常引用。

接下来是密钥。这部分需要准备两类：大模型服务商的密钥和金融数据源的密钥。数据源方面框架默认走的是 FinnHub，你需要去它官网注册一个免费账号拿 token；行情数据一般通过雅虎财经的公开接口拿，不需要密钥但偶发不稳定。把这些写进项目根目录的.env文件：

# .env 示例，字段名以官方文档为准 OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxx FINNHUB_API_KEY=xxxxxxxxxxxxxxxx ANTHROPIC_API_KEY=sk-ant-xxxxxxxx GOOGLE_API_KEY=xxxxxxxx

注意：.env一定要写进.gitignore。我在群里见过有人把带密钥的仓库推到公开平台，半小时内额度就被刷空了。密钥泄露的后果是直接的经济损失，不是危言耸听。

3.2 配置文件逐项说明

框架的核心配置是一个 Python 字典，可以在代码里覆盖，也可以用命令行交互的方式选。我把自己常用的那套贴出来，然后逐项解释为什么这么设。

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"] = 2 # 风控辩论轮数 # 是否允许联网抓取实时数据 config["online_tools"] = True # 目录相关 config["data_cache_dir"] = "./data_cache" config["results_dir"] = "./results"

为什么要分成"深思考模型"和"快思考模型"两个？这是整个成本控制的关键。一条链路里 LLM 调用次数最多的环节不是辩论，而是工具调用前的路由决策——模型要反复判断"我现在该调哪个工具、参数填什么"。这类调用对推理能力要求很低，用便宜的小模型完全够用。真正需要大模型的只有三类：分析师的最终报告、研究员辩论、组合经理裁决。把这两者分开之后，我实测单次分析的成本大概降了六成，输出质量几乎没变化。

辩论轮数怎么定？我做过一组对照：同样的标的、同样的日期，轮数分别设 1、2、3、5，跑四遍。结论是 2 到 3 轮是甜点区。轮数为 1 时，空头研究员的反驳明显没有展开，最终结论里几乎看不到看空逻辑的痕迹；轮数为 5 时，第 4、5 轮的发言和前两轮高度重复，我抽样看了几段，基本是在换词不换意。

3.3 命令行跑一次：完整流程记录

配置好之后，最省事的跑法是直接用它的命令行入口。执行python -m cli.main（部分版本是python main.py），接下来是一串交互式提问，我按实际操作的顺序记一遍。

第一步，输入标的代码。这里要注意代码格式，美股直接写代码，部分市场需要带后缀。我第一次跑的时候输了个中文名称，直接报错退出。

第二步，输入分析日期。这个日期决定了它去抓哪一天附近的数据。建议不要用当天，因为很多数据源对当日数据有延迟，容易抓到空值。我一般用前一到两个交易日。

第三步，勾选分析师。四个角色可以全选也可以只选部分。如果只是快速试水，我建议先只选基本面和市场两个，跑通了再全开。全开的情况下，单次分析的 LLM 调用次数会翻倍。

第四步，选择研究深度。浅度、中度、深度三档。浅度适合批量初筛，深度适合对少数重点标的做细致研究。这一步直接决定工具调用循环的次数上限。

第五步，选择模型服务商和具体模型。会分别让你指定深思考和快思考两个模型。

选完之后就开始跑了。终端会实时打印每个智能体的动作和中间的推理过程，这个日志本身价值很高，我经常一边跑一边看，能直接观察到模型在纠结什么、在引用哪段数据。

3.4 用 Python 脚本调：更适合批量场景

命令行适合单次探索，要批量跑还是得写脚本。核心调用只有两行：

from tradingagents.graph.trading_graph import TradingAgentsGraph from tradingagents.default_config import DEFAULT_CONFIG config = DEFAULT_CONFIG.copy() config["max_debate_rounds"] = 2 config["max_risk_discuss_rounds"] = 2 ta = TradingAgentsGraph(debug=True, config=config) state, decision = ta.propagate("NVDA", "2024-05-10") print(decision)

propagate的第一个参数是标的代码，第二个是日期字符串。返回值里，state是完整的中间状态，所有报告、辩论记录都在里面；decision是最终裁决的文本。

批量跑的时候要注意两点。第一，加异常捕获和重试，网络抖动和数据源限流是常态，一个标的失败不应该让整批任务挂掉。第二，控制并发，我一开始图快开了八个并发，结果十分钟内连续撞限流，反而是串行跑得稳。后来改成并发三路、每次调用之间加一点随机延迟，整批任务的成功率从七成提到了九成五以上。

import time from concurrent.futures import ThreadPoolExecutor def analyze_one(ticker, date): for attempt in range(3): try: ta = TradingAgentsGraph(debug=False, config=config) state, decision = ta.propagate(ticker, date) return {"ticker": ticker, "decision": decision, "ok": True} except Exception as e: time.sleep(5 * (attempt + 1)) return {"ticker": ticker, "error": str(e), "ok": False} with ThreadPoolExecutor(max_workers=3) as pool: results = list(pool.map(lambda t: analyze_one(t, "2024-05-10"), ticker_list))

3.5 结果落盘：目录结构与阅读顺序

跑完之后结果会写到results目录下，按标的和日期分层。结构大致是这样的：

results/ └── NVDA/ └── 2024-05-10/ ├── reports/ │ ├── market_report.md │ ├── sentiment_report.md │ ├── news_report.md │ ├── fundamentals_report.md │ ├── investment_plan.md │ ├── trader_investment_plan.md │ └── final_trade_decision.md └── message_tool.log

我的阅读顺序是这样的：先看investment_plan.md，因为它已经把多空冲突浓缩好了，五分钟能抓住核心矛盾；再看final_trade_decision.md，看风控层有没有推翻交易员的方向或数量级，推翻的理由是什么；如果某个点没看懂，再回头查对应的分析师报告。全部通读一遍太费时间，除非是重点标的，否则没必要。

message_tool.log是个容易被忽略的宝藏。它记录了所有工具调用的原始返回，当某份报告看起来数据不对时，翻这个日志能立刻定位是模型理解错了，还是数据源本身返回了脏数据。这两种情况的处理方式完全不同。

4. 成本、延迟与稳定性调优

4.1 先把成本算清楚，再决定跑多少

很多人上来就全开、跑深度、跑几十个标的，然后被账单吓一跳。我把自己实测的参数整理成一张表，方便估算。下面的调用次数是大模型调用次数的粗略量级，小模型调用没算进去因为价格差了一个数量级。

调用次数的构成大致是：分析师数量乘以每人的工具循环轮数，加上辩论轮数乘以二，加上风控轮数乘以三，再加上几个固定的一次性调用。举个具体例子，4 分析师、每人循环 3 轮、辩论 2 轮、风控 2 轮，粗算就是 4×3 + 2×2 + 2×3 + 3 = 25 次核心调用，再算上重试和格式修复，落到 35 到 45 这个区间是合理的。

token 消耗方面，单次大模型调用的输入普遍在 4000 到 15000 token 之间，输出在 500 到 2000 token 之间。把中间值代进去，一次四分析师深度分析的总输入 token 量在 50 万这个量级，输出在 8 万左右。用中档价位的模型，单标的成本落在几毛到一两美元之间。这个数字意味着：跑一百个标的做初筛，成本是一个需要认真对待的数字，别闭着眼睛跑。

提示：批量任务一定先拿三到五个标的试跑，确认输出格式、耗时、成本都在预期内，再放开跑全量。我吃过一次亏，脚本参数写错，一下午跑掉了一个月的预算额度。

4.2 三层缓存策略，把重复计算砍掉

框架本身带数据缓存，但缓存策略值得再往上叠一层。我自己加的三层是这样：

第一层，数据缓存。同一个标的同一天的数据，跑第二次的时候不应该再去请求数据源。这个框架默认有做一部分，但我把它扩到了所有外部调用上，用标的加日期加接口名做缓存键，落成 json 文件。这一层带来的收益最直接，因为数据源的免费额度通常是最紧张的资源。

第二层，报告缓存。四个分析师的输出，在提示词和输入数据完全一致的情况下，结果是可以复用的。我在做参数对照实验时，只改辩论轮数、不改分析师配置，这时候分析师报告其实没必要重跑。加一层哈希校验，把分析师这一层的结果直接读缓存，一次对比实验的时间从四十分钟压到十分钟。

第三层，模型分层。前面已经说过，把所有"路由类""整理类""格式修复类"的调用全部下沉到便宜模型。这一层不用改框架代码，只要在配置里把快思考模型换成便宜的就行，改造成本几乎为零，收益却最大。

4.3 稳定性的两个隐形杀手

第一个是数据源的空返回。金融数据接口在非交易日、财报空窗期、小市值标的上返回空值是家常便饭。如果直接把它塞进提示词，模型会基于"没有新闻"这个信息做出过度解读，输出"近期无重大事件，风险可控"这类结论——但实际上可能是接口挂了。我的处理办法是在工具层加过滤：返回为空时，明确在提示词里标注"该数据源本次无返回，请勿据此推断无事件"。这一句提示词的改动，让我的输出质量稳定了不少。

第二个是上下文膨胀。辩论轮数一多，历史发言全部累积在上下文里，到了第三、第四轮，输入 token 会快速膨胀，既贵又容易触发长度上限。我的做法是给辩论历史加一个滑动窗口，只保留最近两轮的完整发言，更早的压缩成一段摘要。这个改动让我在深度模式下也能稳定跑完，不会再中途崩掉。

5. 常见问题与排查技巧速查

5.1 报错对照表

下面这张表是我两个多月攒下来的，按出现频率排序。

5.2 输出老是"持有"，怎么办

这是新手最常反馈的问题。原因通常不在框架，而在提示词和输入。三个排查方向，按优先级来：

先看数据够不够。如果四个分析师的报告都很薄，说明工具调用没拿到有效数据，模型在没有信息的情况下，最理性的选择就是"持有"。去看message_tool.log，确认每个工具是不是真的返回了内容。

再看日期选得对不对。选了一个信息密度很低的窗口期，自然没什么可判断的。挑财报前后、重大事件附近的时间点试试，输出会立刻变得有锐度。

最后才是调提示词。框架内部的提示词偏向保守，这本身是合理的。如果你想让它更果断，可以在交易员和风控环节增加明确要求，比如强制要求给出方向并说明关键假设，禁止使用"观望""谨慎参与"这类表述。我改过之后，方向输出的明确度提升很明显，但也要接受误判率上升的代价。

5.3 几个我踩过的具体坑

坑一：拿当天的数据跑。我最早总是想分析"今天"，结果大量数据源当日延迟，报告里出现"未获取到最新价格"这种句子，结论完全没法用。改成用前一两个交易日，问题消失。

坑二：批量脚本没做去重。我的任务列表是从一个文件里读的，文件里有重复行，结果同一个标的跑了两遍，白白多花了一笔钱。加一个集合去重就解决了。

坑三：把中间状态当最终结论。我一度只看investment_plan.md就去下判断，后来发现风控层推翻结论的比例比我想的高。一定要看到最后一份裁决文件，中间产物只能当过程材料。

坑四：没有记录版本信息。同一套配置，隔了几周再跑，结果可能不一样——模型服务商会静默更新模型版本。我后来的做法是在结果目录里存一份配置快照加时间戳，方便回溯。

6. 二次改造的几条思路

6.1 换掉数据源，接自己的数据

框架默认的数据源对非美股市场支持一般，这是很多人第一个想改的地方。改造的切入点比较明确：找到工具注册的那一层，把原来的数据获取函数替换成你自己的接口封装。只要保证输入输出格式一致，上层的智能体逻辑完全不用动。

我做过一次接口替换，把行情数据换成了本地的历史数据库查询，把新闻数据换成了自己维护的公告库。改完最大的感受是：输出质量对数据质量的敏感度，远高于对提示词微调的敏感度。同一套提示词，喂进去干净的结构化数据，和分析师报告里全是"未找到相关数据"，出来的结论完全不是一个水平。

具体改造时有三个约束要遵守。第一，返回内容要做长度裁剪，别把几十页的公告原文直接塞进上下文；第二，保留原始数据的溯源信息，比如数据时间和来源，方便模型在报告里标注引用；第三，对空返回做显式标注，前面讲过，这个细节很关键。

6.2 加上记忆和反思环节

原版框架在早期阶段是"一次性"的：跑完就完了，不会记住上次的结论。后来社区加了反思机制——把过去的决策和实际结果配对存进向量库，下次分析同一标的时，先把相似历史情境检索出来，喂给模型参考。

我自己也试着做了一个简化版：每次跑完，把最终决策、关键假设、以及一段时间后的实际涨跌记成一条记录，存在本地。下次分析同一标的时，把最近三条记录的摘要拼进交易员的提示词里。效果挺有意思——模型在发现自己上次判断错误后，下一次的措辞明显更谨慎，会主动提出更多的验证条件。这个"知道自己错过"的能力，是单次调用永远给不了的。

提示：做记忆环节一定要注意时间对齐。历史记录的实际结果是"已知"的，如果检索时不小心把未来信息带进了决策上下文，整个评估就失去意义了。这是这类系统里最容易出的评估偏差。

6.3 接回自己的回测框架

框架自带的验证功能比较轻量，如果你有成熟的回测体系，更好的做法是把它当成信号生成器，输出方向序列，然后接到自己的回测引擎里，加上真实的费率、滑点和仓位约束。

这里有个细节需要提前处理：框架输出的是自然语言，直接接到回测里要写一层解析。我的做法是把最终裁决拆成三个字段——方向、强度、关键假设。强度用一个简单的关键词映射得到，比如"强烈建议买入"映射到高，"可以考虑加仓"映射到中。粗糙但够用，而且比让模型直接输出数字更稳定，因为模型对绝对数值的估计一贯不可靠。

另外要提醒的是样本量问题。单个标的几十次分析的结论，统计上没有意义。要做有说服力的评估，至少得覆盖几十个标的、跨越几个不同的市场阶段，这意味着一笔不小的推理开销。我的建议是先想清楚你要回答什么问题——是想验证"这个框架的信号有没有超额收益"，还是只想"用它辅助人工做初筛"。后者对样本量要求低得多，也是我认为更现实的用法。

6.4 关于期待值，说几句实在话

用了两个月，我对这套东西的定位越来越清晰：它是一个能帮你把信息铺开、把对立观点摆到台面上的工具，不是一个能替你赚钱的黑箱。它最大的价值在于两点，一是横向的信息展开效率——原来要花半天读的财报、新闻、讨论，现在几分钟内能拿到四个视角的初稿；二是纵向的逻辑对抗——它逼着你面对看空的观点，而这恰恰是人在持有某个判断时最容易回避的部分。

我也见过不少人跑完一轮，看到结论和自己想的不一样，就反复调参数直到输出符合预期。这么做就本末倒置了。参数该调的是成本、延迟、稳定性这些工程指标，而不是"让它说我想听的话"。真要做后者，不如直接写一段提示词让模型夸你。

最后分享一个我自己的用法：我不看它的方向结论，只看investment_plan.md里多空双方各自列出的证据清单，然后拿这份清单去对照自己的判断，看有没有哪条证据是我之前忽略的。这个用法下，即使框架的方向判断是错的，它的过程产物依然有价值——而且价值可能比一个正确的结论更大，因为忽略掉的风险点，往往正是后来真正出问题的地方。