第一次把 TradingAgents 跑通的那天我盯着终端里一屏一屏滚出来的报告脑子里冒出的第一个念头不是这玩意儿能赚钱吗而是原来投研流程可以被拆成这样一条流水线。这个项目最吸引人的地方不在模型有多强而在于它把一个团队怎么吵出一个结论这件事用图结构和大模型硬生生复刻了一遍基本面、情绪、新闻、技术四个分析师各写各的报告然后多空两位研究员对着报告互相拆台最后交易员和风控三方再辩论一轮由组合经理拍板。整个过程有角色、有立场、有记忆、有反思输出还是可读的 Markdown。如果你是大模型应用开发者它是一个非常好的多智能体编排教学样本如果你是量化或者投研背景它能帮你把日常的研究框架翻译成可执行的代码如果你只是好奇跟着我下面的步骤一台普通笔记本加一个 API Key 就能把它跑起来。需要提前说清楚的是这是一个开源的研究与工程框架它的输出只是模型的推演结果不构成任何投资依据把它当一个会自动写研报的小组来用心态会稳很多。下面我按自己实际踩过的路径把它的设计逻辑、架构细节、配置参数、运行实录和坑点全部摊开讲。1. 项目全景与设计动机拆解1.1 它到底是个什么东西把投研团队塞进一个进程TradingAgents 的核心定位是多智能体大模型金融交易框架。名字听起来很唬人拆开看其实很朴素它不做行情接入网关不做低延迟撮合也不做仓位管理系统。它只做一件事——给定一个标的代码和一个日期组织一群被赋予了不同身份的大模型角色围绕现在该不该动手、往哪个方向动手产出一份带推理链条的决策文档。我把它类比成一家小型的、只在纸面上运作的投研工作室。工作室里有四位分析师负责收集和解读素材两位研究员分别站在看多和看空立场上互相攻击一位交易员负责把观点翻译成买/卖/持有 理由三位风控人员从激进、中立、保守三个角度再吵一轮最后组合经理签字。所有角色都由大模型扮演所有会议记录都落盘成文件。这种设计的价值在于可解释性。单次问大模型NVDA 能不能买你得到的是一个黑箱结论而在这套框架里你能看到每个角色在每一步拿到了什么信息、说了什么话、被谁反驳、最后为什么改口。对做研究的人来说这个过程的参考价值往往比结论本身更大。另外要强调一点项目默认走的是一套日频、研究导向的流程它不追求分钟级的时效也不追求高频交易的吞吐。它的节奏更像一个研究员花半天写出来的一份备忘录只不过这个过程被压缩到了几分钟到几十分钟。1.2 为什么是多角色 辩论而不是单次推理我一开始也怀疑这是不是过度设计。毕竟一个大模型在提示词里把请从基本面、技术面、情绪面分别分析写上看起来也能出多视角结论。但实测下来差异很明显原因大概有三层。第一层是注意力分配。单次推理时模型必须在一次前向过程中同时处理财报数据、K 线指标、新闻情绪这些东西上下文里信息一多它很容易抓住最显眼的那个信号放大其余部分被稀释。拆成四个独立分析师之后每个角色的上下文窗只装自己那一路信息技术分析师可以专心算均线、MACD、RSI不会被十篇新闻稿挤掉注意力。第二层是对抗性纠偏。多空辩论这个环节是我认为最值得抄的设计。多头的任务就是找买入理由空头的任务就是找风险点这种屁股决定脑袋的设定听起来不理性但恰恰能逼出双方各自最强的论据。裁判研究经理拿到两边的完整论证后再下判断比让一个模型客观中立地一次说清所有利弊要可靠得多——因为后者往往会给出一个模棱两可、两头都不得罪的中间答案。第三层是错误隔离。某一路数据源挂了只会影响那一个分析师的报告其他角色的推理链条还在。这种容错性在真实生产环境里非常关键我在后面排查章节会具体讲。提示辩论轮数不是越多越好。默认配置里max_debate_rounds是 1也就是一轮交锋。我试过调到 3结论确实更细但 token 消耗几乎线性上涨而且到第三轮时双方常常开始重复已说过的观点边际收益很低。1.3 适用边界谁适合上手谁可以绕道说几类我觉得特别适合的人。第一类是做 Agent 编排的工程师这个项目的图结构、状态管理、条件跳转写法非常规范是学习 LangGraph 实战的好材料。第二类是投研或量化的从业者你可以把它当成一个自动化的研究流程记录仪用来对比自己人工分析的思路差异。第三类是金融科技方向的学生完整跑一遍能建立起对大模型能做什么、不能做什么的直觉。不太适合的场景也要讲明白。如果你要的是毫秒级交易信号这套东西完全帮不上忙光是几轮大模型调用就够行情走完一大段。如果你指望它直接输出可实盘的仓位建议那更危险它没有考虑你的资金规模、持仓约束、税费和滑点输出的买/卖更像是一种倾向性表达而不是可执行指令。如果你对成本极度敏感也要先算一笔账——一次完整运行的调用次数远比你想象的多。还有个容易被忽略的边界它对数据源的依赖。项目默认接的是海外市场数据A 股、港股这些要走自己的接口。这个改造成本不低我在第 6 节会具体展开。2. 架构拆解五个角色怎么串成流水线2.1 分析师层四种视角各管一段框架的第一层是分析师团队默认包含四类角色可以在启动时勾选启用哪些。技术分析师负责行情数据输入是历史价格和成交量输出的报告里会包含趋势判断、动量指标解读、支撑压力位这类内容。它的底层依赖是行情库加上指标计算库均线、MACD、RSI 这些是代码算出来的硬数值不是让模型凭空想象的这一点很关键。基本面分析师走的是财报和公司数据那一路关注营收、利润、估值倍数、内部人交易这类信息。情绪分析师看的是社区讨论默认抓的是海外论坛上关于该标的的帖子。新闻分析师则负责检索和解读近期新闻标题与摘要。这四路的分工逻辑是信息源正交。技术面看价格行为的统计规律基本面看企业经营的数字情绪面看人群的心理倾向新闻面看外部事件冲击。它们的输入几乎不重叠因此放在一起时冲突更多是真实的多空分歧而不是同一条信息被反复计数。我在实际使用中的一个体会是四个角色的启用与否应该跟着你的持有周期走。做中长线就重点开基本面和技术做短线情绪驱动的标的情绪和新闻的权重反而更高。全都打开固然全面但成本和噪声都会上升。2.2 研究员层多空对喷与裁判落锤四位分析师产出报告后架构进入研究辩论阶段。这里有两个角色——看多研究员和看空研究员。他们不是简单复述分析师观点而是被明确要求站在各自立场对已有的四份报告做出自己的解读和攻击看多方要找出被低估的积极信号看空方要指出被忽视的风险和被高估的乐观。辩论的轮数由max_debate_rounds控制。每一轮里双方都能看到对方上一轮的发言因此可以针对性地反驳。这种看到对方说了什么再回应的机制是它比单轮生成更接近真实辩论的关键。多轮之后由研究经理角色做总结输出一份投资计划investment plan里面通常包含方向判断、核心理由、以及主要的风险提示。我特别喜欢这个环节的一个副产品辩论记录本身就是一份正反双方论据清单。哪怕最后你不认同结论光是看空方列出的那几条风险就足够让你在决策时多留个心眼。这也是我觉得这套框架比单纯让模型写研报更有意思的地方。注意辩论质量高度依赖分析师报告的质量。如果某一路数据抓空了报告里写着数据不可用多空双方仍然会硬着头皮基于空信息辩论这时候输出的计划参考价值会大打折扣。务必在运行后检查各份报告是否都有实质内容。2.3 交易与风控层从观点到仓位语言拿到投资计划之后交易员角色登场。它的任务是把研究报告里的观点翻译成更接近交易的语言方向是什么大致什么时候进什么条件下应该退出。这里要注意它输出的依然是自然语言的计划不是可以直接下单的结构化指令。接下来是风控辩论。这里有三个角色分别是激进、中立、保守三种风险偏好他们会围绕交易员的计划进行讨论。激进方会强调机会成本、质疑过度谨慎保守方会放大尾部风险和回撤可能中立方试图在两者之间找平衡。讨论轮数由max_risk_discuss_rounds控制。最后由组合经理角色做终裁输出最终交易决策。这份文件是整个流程的终稿也是大多数人最关心的一份。但我建议你先看投资计划和辩论记录再看终稿因为终稿的说服力完全来自前序环节的论证质量单看结论很容易被带跑偏。三个风控角色的设定其实是在做一件事把风险偏好这个通常隐藏在提示词里的隐含变量显式化。真实世界里的分歧很多时候不是对事实的分歧而是对风险承受度的分歧。把这一层单独拎出来辩论比让一个模型综合考虑风险要诚实得多。2.4 状态对象与流转机制整个流程跑在一张有向图上节点就是各个角色边是消息传递。框架内部维护一个共享的状态对象随着流程推进不断追加内容——分析师的报告、研究员的发言、交易员的计划、风控的讨论全部按顺序累积在里面。这种共享黑板式的设计有个明显好处每个角色天然拥有完整的历史上下文。你不用手写复杂的消息路由只要把新产出写进状态下一层的角色读状态就能拿到全部前情。代价是上下文长度会快速增长尤其是辩论轮数开大的时候这也是成本上涨的主要来源。图里还有几个关键机制值得注意。一是进度可视化终端界面会把当前进行到哪个角色、哪个环节实时显示出来跑长任务时非常必要。二是缓存同一标的同一天的数据通常会被缓存到本地目录重复运行时能省下大量网络请求时间。三是反思记忆这个我会在第 4 节单独讲它是这套框架区别于一次性提示词工程的重要特征。顺带说下技术栈编排用的是 LangGraph 那一套指标计算依赖行情分析库终端界面用了富文本渲染库数据侧则混合了多个免费和付费接口。理解了这套技术栈你改造起来会有明确的抓手——想换数据源就动数据层想换编排逻辑就动图定义互不干扰。3. 环境搭建与最小可跑通配置3.1 依赖与安装别在系统 Python 里折腾环境这块我给的第一条建议很朴素用虚拟环境别往系统 Python 里装。这个项目的依赖里有一堆数据分析和网络相关的库版本冲突的概率不低。git clone https://github.com/TauricResearch/TradingAgents.git cd TradingAgents # 用 conda 或者 venv 都行我习惯 conda conda create -n tradingagents python3.12 -y conda activate tradingagents # 也可以纯 venv # python -m venv .venv source .venv/bin/activate pip install -r requirements.txtPython 版本建议 3.12 附近太老的版本部分异步和类型写法会报错。安装完成后先别急着跑主程序先确认几个核心库能正常导入图编排库、行情库、指标计算库、终端渲染库。导入不报错说明基础环境干净。如果你在容器里跑记得给容器留足内存。辩论轮数开大之后上下文会很长加上多个角色的中间结果内存占用会比想象中高。我第一次在 2G 内存的小机器上试跑到风控环节直接被系统杀掉了。3.2 模型选型deep_think 与 quick_think 的分工这个项目最有意思的配置项之一是它把模型分成了两个档位deep_think_llm和quick_think_llm。quick_think_llm用在那些量大但不太难的环节比如把原始行情数据整理成一段描述、把新闻摘要压缩成要点。这类任务调用次数多用便宜的小模型性价比极高。deep_think_llm则用在做判断的环节比如多空辩论的发言、投资计划的撰写、最终决策的拍板。这些地方需要更强的推理和长上下文能力省钱的代价往往是结论质量明显下滑。我自己的配置思路是这样的小模型尽量选便宜且稳定的用来扛数量大模型宁可少开几个角色也要保证是能扛长上下文的那一档。因为辩论环节会把前面所有报告塞进上下文上下文太短的模型会直接截断导致它根本没读到关键信息就开始发言。Provider 这一层框架做了抽象切换不同的模型服务商只需要改配置里的 provider 和 backend_url代码几乎不用动。本地部署的模型也能接只要暴露了兼容的接口。这一点对想控制成本或者做离线实验的人很友好。提示切换 provider 之后一定要重新跑一次完整的冒烟测试。不同服务商对结构化输出、函数调用的支持程度差异很大我遇到过一次换 provider 之后某个环节的输出格式解析全部失败程序卡在那儿一动不动。3.3 配置文件逐项拆解核心配置集中在一个默认配置字典里几个关键项我按重要性排一下。llm_provider决定用哪家模型服务backend_url是接口地址。deep_think_llm和quick_think_llm就是上面说的两个档位建议填具体型号而不是别名避免服务商那边悄悄换了默认版本导致结果不可复现。max_debate_rounds控制多空辩论几轮max_risk_discuss_rounds控制风控讨论几轮。这两个是成本和质量的直接杠杆默认都是 1。我的建议是第一次跑保持 1先看整体效果觉得论证太浅再加到 2。results_dir是结果落盘目录data_cache_dir是数据缓存目录。这两个目录我强烈建议从默认位置挪到你自己的项目路径下一是好找二是缓存复用能实打实省时间——同一天同一个标的第二次运行网络请求会少很多。online_tools这个开关决定是否联网抓取实时数据。关掉它就走本地或离线数据适合做可复现实验开着它数据更新但每次结果都会有细微差异。做对比实验的时候一定要固定这个开关。还有一个上限参数控制图的最大循环次数防止某个条件判断写错导致流程无限打转。这个值默认给得比较宽裕一般不用动但如果你自己改图逻辑记得检查它。3.4 成本与耗时预估先算账再开跑我建议每个新上手的人都先做一次成本估算不然第一次跑完看到账单容易心跳加速。粗算方法很简单数一下有几个环节需要调用大模型每个环节调用几次每次的输入输出大概多少 token。一次完整运行里四个分析师各自至少一次调用技术分析师因为要处理多段数据可能更多辩论环节是双方各一次乘以轮数再乘以轮数相关的裁判调用交易员一次风控三方各一次乘以讨论轮数再加一次最终裁决。全部加起来保守估计也是几十次调用起步而且辩论环节的输入上下文很长单次成本明显高于普通对话。耗时的瓶颈通常在网络请求和模型响应两处。数据抓取是并行的还是串行的模型服务商当时的负载如何都会影响总时长。我实测下来从启动到出完整结果几分钟到几十分钟都出现过取决于角色数量、辩论轮数和模型档位。省钱有三个我验证过有效的做法。第一先用小模型把全流程跑通确认没有代码层面的问题再换大模型做正式实验。第二把基本面这类变化很慢的报告缓存下来短时间内不重复生成。第三减少同时启用的分析师数量只保留跟你研究目标最相关的那几路。这三条加起来通常能把成本压掉一半以上。4. 一次完整运行的过程实录4.1 从启动到调用链程序里到底发生了什么项目提供了命令行入口也支持在代码里直接调用。我两种都试过命令行适合交互式摸索代码调用适合做批量实验。python -m cli.main跑起来之后是一串交互式提问选标的、选日期、勾选启用哪些分析师、选研究深度、选模型服务商和具体型号然后确认执行。研究深度这个选项会直接影响辩论轮数和分析详细程度浅档适合快速验证深档适合正式出结论。如果你想在脚本里调用路径大概是这样的from tradingagents.graph.trading_graph import TradingAgentsGraph from tradingagents.default_config import DEFAULT_CONFIG config DEFAULT_CONFIG.copy() config[deep_think_llm] 你的强模型 config[quick_think_llm] 你的便宜模型 config[max_debate_rounds] 1 ta TradingAgentsGraph(debugTrue, configconfig) _, decision ta.propagate(某标的代码, 2025-01-10) print(decision)propagate这个方法名字起得很直白——把初始输入顺着图传播下去走完全部节点返回最终决策。中间过程的每份报告都会落到结果目录里。调试阶段把 debug 打开图里每一步的执行顺序和状态变化都会打印出来排查问题时非常有用。调用链的顺序用一句话概括就是数据层准备素材分析师各自出报告研究员辩论出计划交易员出方案风控辩论组合经理出终稿。每一步的产出都写进共享状态供后续节点读取。4.2 输出目录与报告解读先看哪份跑完之后结果目录的结构大致是按标的/日期/各类报告这样分层组织的。同一标的不同交易日的运行结果互不覆盖方便你做时间序列对比。里面通常包含这几类文件技术面报告、情绪面报告、新闻面报告、基本面报告然后是研究阶段的投资计划、交易员的方案、以及最终交易决策。有些版本还会把完整的辩论对话记录单独存一份这个文件我认为价值最高值得单独翻。阅读顺序我的建议是反着来。先看最终决策知道结论是什么再回头看投资计划看它的理由是哪些最后翻辩论记录重点看反方提出的风险点。这样读一遍你对整份结论的可信度会有一个相当准确的判断——如果反方的质疑被正方用具体的数字或事实回应了结论相对扎实如果反方提的问题从头到尾没人正面回应那这份结论就要打个问号。还有个小细节不同角色输出的文档格式不完全统一有的用表格有的用分点列表。如果你要做批量分析最好写个小解析脚本把这些文档里的方向判断、关键词抽取出来人工读几份就够了多了眼睛受不了。4.3 记忆与反思这套框架最容易被忽略的一层框架里有一个记忆机制会把历史决策和之后的实际表现关联起来。运行的时候同一标的过去若干次的决策记录和由此产生的反思会被注入到当前的分析上下文里。ta.reflect_and_remember(returns)类似这样的调用用来把这段时间的实际收益反馈给系统触发一次反思并把反思写进记忆。下一次再分析同一标的时这些上次我判断错了因为……的记录就会出现在上下文里。我认为这是整个项目里设计思路最超前的一环。绝大多数大模型应用都是无状态的每次对话从零开始同一个错误可以反复犯。而这套机制试图让系统具备从自己历史判断中学习的能力。实测效果取决于你怎么用它——如果你持续用同一个标的反复运行确实能观察到它对某些反复出现的判断偏差有了警觉但如果你每次都换标的记忆基本派不上用场。一个实操建议把反思当作一个固定的收尾步骤。每次跑完等实际走势出来后把收益数据回灌进去做一次反思再把整条记录存档。攒上几十条之后你会得到一份非常有价值的模型判断偏差图谱比如它在趋势反转的时点是不是总是慢半拍在震荡行情里是不是过度解读噪声。这个东西的价值我觉得比单次决策本身大得多。5. 常见坑与排查技巧实录5.1 数据源类问题最常见的翻车点数据问题是我踩坑最多的一类表现形式通常是某份报告内容异常简短或者直接写着数据不可用。根因无非几种接口需要认证信息而你没配免费接口在某些地区或某些时段不稳定标的代码在不同数据源里的写法不一致。排查顺序我总结成三步。第一步看报错日志里有没有明确的认证失败或超时提示这类信息框架通常会打出来但容易被人忽略。第二步单独写个最小脚本去调同一个数据接口确认是接口本身的问题还是框架调用的问题。第三步检查标的代码格式海外标的和本地标的的编码规则经常不一样写错了接口会静默返回空数据不报错但也拿不到东西。有个经验值得单独说数据抓取失败往往不会让程序崩掉而是让某个角色看着空报告硬编。这是最危险的情况因为最终结论看起来正常其实某一层已经失效了。所以每次跑完务必扫一眼四份分析师报告的字数明显偏短的那份就是嫌疑对象。注意把联网开关打开和关闭跑两次对比结果差异是快速定位数据依赖问题的好办法。如果两次结论南辕北辙说明这套结论对实时数据极其敏感用的时候要格外谨慎。5.2 输出解析类问题模型不按格式说话框架内部大量依赖模型输出结构化内容比如某个决策字段、某个方向标签。模型一旦不按格式输出解析就会失败流程卡在某个节点或者走到异常分支。我遇到过的几种典型情况换了模型版本之后原来能解析的输出突然解析不了因为新版本更倾向于加一段解释性开场白再给结构化内容辩论轮数开大之后模型在长上下文下偶尔输出截断的片段还有一些模型的思维链内容会混进正式回答里导致字段错位。应对办法有三条。最直接的是降级到更听话的模型版本尤其是做批量和复现实验的时候稳定性比聪明程度更重要。其次是给关键的输出节点加一层容错解析先尝试严格解析失败就退回宽松的正则提取再失败就把原始输出存下来人工看。第三条是把温度参数压低这类需要结构化输出的场景创意性毫无意义稳定压倒一切。实测下来把quick_think_llm换成更稳定的型号能消除大部分解析类报错。真正需要模型聪明的地方其实集中在辩论和最终决策那几处其余环节用最稳妥的配置就好。5.3 复现性与时延同一输入两次结果不一样这个问题的根源有三处模型服务本身有随机性联网抓的数据在不同时点不同以及上下文里混入了历史记忆。如果你要做对比实验必须把这三处都锁死。温度调到最低联网开关关掉走本地缓存同时清空或者固定记忆内容。我做过一组对照同样是那个标的那个日期锁死不锁死的情况下最终方向判断有时候会不一样这个差异在做严谨评估的时候是致命的。时延方面我感觉最容易让人误判的是程序没反应。其实它可能正在等一次很长的模型响应终端界面上的进度指示会告诉你当前在哪个节点。如果卡在同一个节点超过预期时间大概率是网络或接口的问题这时候去看日志比干等有效得多。还有一个我踩过的坑缓存目录权限或者路径写错时程序会反复去抓同一份数据而不报错表现为运行时间莫名其妙变长。检查缓存目录里有没有实际生成文件是最快的判断方法。5.4 常见问题速查表现象大概率原因我的处理方式某份分析师报告明显偏短对应数据源认证失败或接口超时单独写脚本直连该接口验证检查凭据配置流程卡在某个节点不动模型响应慢或结构化输出解析失败看调试日志定位节点降低温度或换稳定模型决策字段解析报错模型输出混入解释性文字或思维链加宽松解析兜底同时保留原始输出备查两次运行结论差异大联网数据变化、模型随机性、记忆干扰关联网、降温度、固定或清空记忆运行时间异常变长数据缓存失效导致重复抓取检查缓存目录是否有文件生成确认路径可写成本远超预期辩论轮数过多、小模型也用大模型跑先用小模型全流程验证再替换关键节点模型内存被系统杀掉上下文过长机器内存不足减少启用角色、降低辩论轮数、换更大内存机器切换服务商后全线失败新服务商不支持某些调用特性跑冒烟测试确认结构化输出和长上下文支持6. 二次开发与扩展把它改成你自己的东西6.1 换数据源动数据层别动编排层想接入自己的数据正确姿势是只改数据层让上层分析师拿到的数据结构保持不变。也就是说你的任务是把自有数据整理成框架期望的那几个字段而不是去改分析师角色内部的逻辑。这样做的好处是升级框架版本时你的改动不会被冲掉。具体做法是找到数据获取的入口函数在里面加一个分支走自有数据还是走原有接口。我习惯用一个配置项来切换默认走原接口实验时切成自有数据。修完先用同一个标的跑一次对比两份报告的内容差异确认数据确实喂进去了。一个细节提醒时间对齐。自有数据的时区、交易日历、复权规则很可能跟框架默认的不一致这类问题不会报错但会让报告里出现数据缺失或者指标数值明显异常。接完数据后先肉眼核对几个价格点位再往下走。6.2 适配不同市场要先想清楚三件事把框架用到其他市场我认为要先解决三个问题。第一是数据可得性不同市场的行情、财报、新闻接口完全不一样国内标的用海外免费接口基本抓不到有效财报数据这块必须自己接。第二是信息生态差异情绪分析师默认抓的是海外社区换成别的市场就要换社区源否则这一路等于空转。第三是交易制度差异涨跌停、T1、做空限制这些约束在这套框架里完全没有体现而它们对策略可行性的影响是决定性的。我的建议是分阶段做先只接行情数据只开技术分析师把链路跑通再接财报数据开基本面分析师最后处理情绪和新闻这两路。每接一路都单独验证输出不要一次性全上出了问题根本没法定位。6.3 接回测与评估让结论有可比性框架本身输出的是自然语言决策要做评估就必须把它转成结构化信号。我一般会写一个解析函数把最终决策里的方向、置信度、关键理由抽成一行结构化记录加上标的、日期、当时价格存成表格。攒够样本之后就能做最基础的评估了。评估指标不用搞复杂先看方向判断的命中率再看如果按它的方向持有固定天数会是什么结果重点是看它在什么类型的行情下表现好、什么类型下表现差。这个分场景表现的分析比一个笼统的准确率有用得多。还有个我在实践中觉得特别值得做的实验把辩论记录里反方提出的风险点逐条抽出来看这些风险在后续实际走势里有没有兑现。如果反方提的风险大部分都兑现了说明这套系统的风险识别能力还不错只是最终仲裁偏向乐观如果反方提的风险基本是空炮那可能它只是在为了辩论而辩论。这个分析能帮你判断到底该相信这套框架的哪一部分。需要再说一次的是这类评估只能用于研究和技术验证任何基于它做出的实际资金决策风险都由自己承担框架的设计目标从来不是给出可直接执行的交易指令。最后分享一个我自己用下来的习惯每跑完一个标的把最终决策、反方最强的一条反驳、以及我自己的独立判断三样东西写在一张便签上并排放着。攒到几十张之后回头看最有意思的不是谁对谁错而是能清楚看到自己在哪些类型的信号上会系统性地跟模型产生分歧。对我个人来说这个分歧清单的价值比框架输出的任何一份报告都高——它照出来的是我自己的认知盲区而不只是模型的局限。