我让它写一份新能源汽车的投资报告。
五个阶段全跑完了：感知、建模、推理、决策、报告。
输出 135 行，七个章节，三张表格。里面有三家公司的 GCI 得分（0.91、0.87、0.79），一个三维评估框架（权重 40%、35%、25%），四种风险的发生概率（30%、25%、15%、10%），还有预期收益率 +18% ± 4%。
文件名是 research_report_20261031_152507.txt。
报告第一行写着：发布日期 2024年6月3日。
我不太信，又跑了一次。
这次输出 152 行。主题从"绿色本地化"换成了"闭环再生套利"，核心框架从 GCI 换成了 CLOSED_LOOP_ARBITRAGE，末尾的撰写机构从"ESG与新能源战略组"换成了"智擎资本投研中心"。
日期写的是 2024年10月。
文件名是 research_report_20261031_153907.txt。
两次都错，错的地方还不一样。
程序知道今天几号，文件名就是它自己生成的。模型不知道。它不是记错了一个固定日期，是每次都现编一个看起来合理的。
五个阶段，一步没落下
流程是完整的。
终端里五个阶段挨个打出来。感知阶段收集市场数据和信息，建模阶段构建内部世界模型，推理阶段生成候选分析方案，决策阶段选择最优投资观点，报告阶段生成完整研究报告。
跑之前，LangGraph 还把流程图打印成了 Mermaid：
js
__start__ --> perception;
perception --> modeling;
modeling --> reasoning;
reasoning --> decision;
decision --> report;
report --> __end__;五条边，一条直线。
这段代码里有个地方我一直想验证。reasoning 函数开头有这么一段：
python
if not state.get("world_model"):
return {
**state,
"error": "推理阶段缺少世界模型",
"current_phase": "modeling"
}前置条件不满足，就把 current_phase 标回 modeling。
看着像会退回去重跑。我做了三组对照，看它到底退不退。
第一组，把世界模型清空，跑到推理阶段。执行节点是 perception → modeling → reasoning，error 记下"推理阶段缺少世界模型"。流程停在 reasoning，没回到 modeling 重跑。
第二组，让建模阶段直接报错。执行节点是 perception → modeling，error 是"建模阶段出错：模拟"。停在 modeling。
第三组，正常跑。五步全走完，error 是 None，报告生成。
三组下来，结论很清楚：current_phase 写了"modeling"，但那只是状态里的一个字符串，给日志看的，不是给调度看的。图是直线，走到哪儿算哪儿，出错就断在那儿。
第一组还暴露了一个更细的问题。世界模型是空的，modeling 阶段自己没察觉，一路跑到 reasoning 才被拦下来。
前置条件的检查，放在了用它的地方，不是产它的地方。
这就像仓库发了个空箱子，出库的时候没人验，到生产线拆开才发现是空的。
顺带说个实际的毛病：这个 Mermaid 图在终端里刷了屏，一遍接一遍地打。看着像是打印语句放在了每个节点里或者循环里。跑通和跑好是两回事，调试的时候终端被这种东西淹掉，真正有用的日志就找不着了。
它每次都造一套新框架
第一份报告的核心是一个叫 GCI 的东西，全称 Green Compliance Index，绿色合规指数。
报告说这是"我们构建的"，三个维度：本地化产能占 40%，绿色能源占 35%，合规穿透占 25%。阈值也定好了，大于 0.85 算"政策套利能力已实质性兑现"，小于 0.7 算"合规仍处规划阶段"。
然后给分：比亚迪 0.91，宁德时代-蔚来联合体 0.87，吉利 0.79。
小数点后两位。
第二份报告换了一整套。这次叫 CLOSED_LOOP_ARBITRAGE，闭环再生套利。政策依据从欧盟关税换成了国内的"一码溯源+双积分加权核算"，核心指标变成工信部溯源平台接入率 63%、车企再生材料认证率、再生前驱体掺混比例（华友 30%、格林美 25%）。
推荐的还是那几家公司，讲的故事完全不同。
第一份说短期机会在绿色本地化，第二份说中期机会在闭环再生。第一份引欧盟法规，第二份引工信部办法。第一份算 GCI 得分，第二份算毛利率从 12.3% 到 21.6%、净利润从 2.1 亿到 5.8 亿。
我没法判断哪个对。但有一点很确定：这两套框架都不是从数据里长出来的，是先想好一个叙事，再往里填数字。
我在课件里翻了三遍，没有 GCI，也没有 CLOSED_LOOP_ARBITRAGE。课件那份投研报告讲的是中端电动汽车市场的中期增长机会，引的是 2022 年全球 EV 销量增长 42%、锂电池成本降到 107 美元/kWh 这类能查证的数。
它先造一个评估工具，再用这个工具给公司打分，最后用分数支撑投资建议。逻辑闭环，自洽得很。
但闭环有个前提：这个工具得是真的。而两份报告里都没有一处说明那些分数是怎么算出来的------哪个工厂的投产进度对应几分，哪份绿电合约对应几分，加权之后为什么是这个数。
框架搭得很完整，唯一能验证的那一步跳过了。
连"严谨"都是随机的
第一份报告的风险表，四种风险，每种都标了概率。
ESG 数据透明度风险，中，30%。
资本开支前置压力，中低，25%。
地缘政策超预期收紧，低，15%。
技术路径替代风险，低，10%。
四个数加起来 80%。这个 80% 是什么意思，剩下的 20% 是什么，报告没说。那 30% 又是怎么估出来的，也没说。
它没法算这个数。但它还是给了。
风险概率这种东西，专业机构做也要靠历史数据和模型，会给区间和假设。这里直接给整数，还是 5 的倍数。
第二份报告的风险表，一个百分比都没有。四种风险，只写了"具体表现"和"应对机制"。
同一个程序，同样的五个阶段，第一份给了概率，第二份不给。
所谓严谨，也是随机的。
再看署名。第一份末尾写"分析师：ESG与新能源战略组"，第二份写"报告撰写机构：智擎资本投研中心"。
这两个机构我没法核实是否存在，报告里也没给任何说明。但署一个机构的名，这是很具体的动作。它不是在写分析，是在扮演一个分析师。
还有措辞。第一份开头写"欧盟反补贴终裁（最高38.1%临时关税）"，到表格里变成"欧盟反倾销税最高达63.1%"。反补贴和反倾销是两个不同的贸易措施，一份报告里前后混着用。
第一份末尾列了数据支持：BloombergNEF、乘联会、上海有色网、欧盟委员会公报、TÜV Rheinland 认证数据库、Wind 金融终端。
六个来源，正文里没有一处给出具体报告名、发布日期或者链接。
我不是说这些数据全是编的。我是说，一份报告把六个权威机构列在末尾，却不在任何一处具体数据旁边标出处，这个动作本身就是装饰。
这就是深思熟虑架构最危险的地方。
它不想不出来。它想得太像了。
结构完整、术语专业、逻辑自洽、格式规范，连免责声明和署名都写了。
一份报告该有的东西它全有。唯独没有一样：可以核对的出处。
反应式 Agent 出错很明显，它答不上来就是答不上来。深思熟虑 Agent 出错很隐蔽，因为它把错误包装成了结论。
反应式那边，边界也没划干净
另一个 case 是私募基金运作指引问答助手，反应式架构，LangChain 加通义千问。
我拿一个知识库里没有的问题去试它：我的组合里科技股占比多少，要不要调。
它先答得很干脆：
对不起，在我的知识库中没有关于您具体投资组合中科技股占比的数据，也无法基于您的持仓情况提供调仓建议。
这一步做得对。课件 Step4 讲的知识边界处理，它落实了。
但紧接着：
根据我的经验，部分私募基金对单一行业（如科技）的持仓上限常设为20%-30%
边界又破了。
前半句刚说"我的知识库里没有"，后半句就用"我的经验"补了个具体区间出来。它标了"根据我的经验"，算是做了区分，但区分完还是把没依据的数字给了出去。
用户看到 20%-30%，很容易当成规定记下来。
课件讲的"明确区分知识库内容和模型知识"，做到这一步只能算一半。区分是手段，目的是让用户知道哪句能信。标了来源不等于给了依据。
混合架构省的不是时间，是判断
第三种是投顾AI助手，混合架构，三层。
底层反应式处理简单查询，市场状况、账户信息、概念解释，毫秒级。中层协调，评估任务类型和优先级，动态选模式。顶层深思熟虑，处理复杂投资分析和长期规划。
课件里跑出来两个计时。问"今天上证指数的表现如何"，11.34 秒。问"根据当前市场情况，我应该如何调整投资组合以应对可能的经济衰退"，112.00 秒。
差将近十倍。
关键在中层那一步 assess_query。LLM 输出一段结构化判断，第一个问题给的是：
js
{'query_type': 'emergency', 'processing_mode': 'reactive',
'reasoning': "用户的查询是关于当天上证指数的表现，这是一个需要实时市场数据的紧急查询。"}第二个问题是 analytical 加 deliberative，于是走数据收集、深度分析、生成建议三步。
所以"快"和"慢"在这里不是性能指标，是一个判断结果。
判断错了会怎样？该快的慢下来，用户等不起；该慢的快起来，答案没用。
而且这个判断本身也要花 token。一个问题如果能用固定流程解决，硬上 Agent 就是白烧钱。
Agent不是"更聪明的工作流"
课件引了 Anthropic 的说法：Agent 通常被实现为 LLM 通过工具调用、基于环境反馈在循环中执行动作的系统。能处理复杂任务，但实现很简单。
还有一句我觉得该贴在墙上：清晰全面的设计工具集以及文档，对于 Agent 的成功至关重要。
什么时候该用？开放性问题，很难或无法预测所需步骤数量，无法硬编码固定路径。LLM 可能跑很多回合，所以你得对它的决策能力有一定信任。
代价也写明了：自主性意味着更高成本，以及可能出现的错误累积。
所以建议是沙盒里广泛测试，设置适当防护栏。
课件没有把 Agent 和工作流对立。说的是互补。Agent 自主处理特定任务，工作流把这些任务协调成连贯的过程。智能制造那个例子里，Agent 监控设备性能、预测维护需求、优化生产计划，工作流管原材料采购、生产排序、质量保证和物流。
还有一句：从简单的提示开始，只有在简单方案解决不了时，再添加多步智能体系统。
看完那份投资报告，我对这句话的理解变了。
以前觉得是在劝人别一上来就搞复杂的。现在觉得是在提醒：复杂的系统会给你一个看起来很像答案的东西。
三个原则里，第一条最容易被跳过
课件最后给了三个核心原则。
保持简洁。核心组件就三个：环境是操作系统，工具集提供行动接口和反馈机制，系统提示定义目标、约束和预期行为。初期别搞复杂。
优先透明。明确展示规划步骤，让用户看得清怎么决策的。
打造 Function/MCP。把工具做出来，配上说明文档和测试。
还提了一句：框架能帮你快速上手，但进生产阶段时不要害怕减少抽象层，直接用基础组件。
但真正让我停下来的是另一个清单------不要为所有任务构建 Agent。
四条判断标准：任务复杂性，决策树能明确规划就直接做工作流；任务价值，高 token 消耗得由高回报任务承担；关键能力验证，得确认 Agent 能处理核心子任务；错误成本，高风险错误要靠限制权限或人工介入来缓解。
课件举的理想场景是代码生成。复杂、价值大、输出易验证，跑一遍单元测试就知道对不对。
第四条我现在特别有感觉。
投资研究报告的错误成本很高，但它恰恰是最难验证的那类输出。代码有单元测试，报告没有。你只能靠读，而它写得比你还好。
三种架构，其实在回答三个不同的问题
这节课之前，我以为"自主规划"是个很玄的东西，好像 Agent 会在脑子里推演一盘大棋。
跑完三个 case 才明白，它没那么玄，而且这三种架构根本不是在解决同一个问题。
反应式回答的是"下一步该做什么"。感知、决策、执行转一圈，撞墙了换个工具再试。它的天花板也在这儿------没有世界模型，只有条件-动作规则，所以它分不清"换方向"和"绕圈"。
深思熟虑回答的是"这件事该怎么做完"。把大任务拆成节点，每个节点做完检查前置条件，再往下走。它的天花板在素材------流程能保证每一步都执行，保证不了每一步用的东西是真的。
混合架构回答的是"这件事值不值得慢下来"。先判断，再分流。它的天花板在判断本身，判错了，快的没价值，慢的烧钱。
三个问题对应三套机制，选错了架构，不是性能差一点，是方向就不对。
拿那个投资报告来说，如果我要的是"每天扫一遍行业新闻，有异常就提醒我"，那是反应式该干的活，用五阶段深思熟虑纯属浪费。
反过来，如果我要的是"给我一份能拿去开会的研究报告"，那深思熟虑至少保证了结构完整、章节齐全、论证有链。只是它给不了出处，这个坑得我自己补。
Agent 不是更聪明的工作流。它是把"下一步做什么"交给了模型，然后你承担这个决定的后果。
而它交付的东西，会比你预期的更像成品。
你手上的任务，是真的需要 Agent，还是只是你想要一个 Agent？