梁文锋把这当成值得庆祝的时刻。他在一场三小时四十四分钟的投资者交流会里反复说一件事：他们没有钱，没有卡，没有名气，团队里没有最顶尖的人才，甚至他自己都不是最好学校毕业的。一群平凡的人，凭什么在两年内做出让全世界紧张的东西？

他的反常识判断是：在 AI 这件事上，想拿得多的人，会先输。

梁文锋算过一笔账。假设 AI 最终能吃掉全球 GDP 的 10%，OpenAI 想从中拿 5%，这笔账理论上是成立的。但只要出现一个愿意只拿 1% 的对手，就能用更低的价格把它打垮。然后又会有人只要 0.1%，把上一个也打垮。这个链条会一直往下卷，直到卷出一个平衡点：拿得太少，商业模式撑不住，会被自然淘汰；拿得太多，会被拿得更少的人一层层挤下去。

梁文锋说得很直白：他毫不怀疑 AGI 会有巨大的商业价值，但比起怎么多拿一点份额，他更在乎的是怎么提高自己能做成这件事的概率。而提高概率的方法，恰恰是主动缩小自己想要拿到的那部分。

这套逻辑落到定价上，就是 DeepSeek 的 API 按十个月回本设计，对应大概六倍利润。这不是利润最大化——真要利润最大化，价格应该定得更高，因为在当前区间用户需求已经没有弹性，涨价不会明显减少消耗量。但六倍利润被主动锁死在这个上限，原因很实际：利润空间压得足够低，第三方靠开源模型自己部署来抢生意，就会无利可图。开源和低利润是同一件事的两面。不靠闭源锁住利润，是把利润压到别人复制不起的程度，来保住市场本身。

他算过，如果真要赚一百倍利润，开源就会变成一个漏洞，第三方的部署成本可能只有你的二十分之一。但 DeepSeek 从起点就没打算走那条路。他不担心开源，因为他从来没想过靠垂直垄断赚一百倍。

这套”故意少赚”的逻辑，解释了这家公司几乎所有看起来不划算的决定。

去年春节，DeepSeek 的 C 端用户量突然暴涨。这不在计划里，团队甚至一度想过不去维护那批用户，但用户赶都赶不走，最后留了下来。梁文锋对这个现象的解释很干脆：把眼前能抢到的东西当成头等大事，会输掉更大的机会。他管这个叫”捡芝麻”——去年的 C 端流量、今年的 B 端收入，在他看来都是芝麻，随手捡一捡就够了，不值得为它停下来。真正的西瓜是 AGI，而 AGI 的机会永远足够大，大到根本不需要现在就精确算清楚自己能占多少份额。

这带来一个有意思的结果：DeepSeek 做产品，几乎是无心插柳。梁文锋说，公司做训练、做 API 的出发点从来不是服务好用户，而是通往 AGI 的路上必须经过这一步，用户和收入只是路过时顺手产生的副产品。这套打法在他眼里是一种降维打击：把 AGI 当目标的组织，投入 C 端和 B 端的心思远低于那些把产品本身当目标的公司，但效果未必更差。他的解释是，越大的愿景，越能凝聚顶尖的人；凝聚起来的人才优势，会自然溢出到产品层面。而一家把”做好产品”本身当作终点的公司，会在产品体验、流量、用户服务上有优势，但在最上游的技术能力上，可能永远追不上一家把技术本身当终点的公司。

同样的克制，也决定了 DeepSeek 不去做的那些事。有投资人问梁文锋会不会往上游做芯片，会不会往下游做金融、医疗这类垂直应用，他的回答都是不会。理由是一个发电厂的比喻：运营电厂的人不需要自己造发电机，只要能以合理价格买到，为什么要自己造？AI 这个盘子足够大，未来会出现很多家万亿级别的公司，DeepSeek 只需要做其中一家，只吃自己最擅长的那一块，不需要把整条产业链都吞下去。吃得太多，反而会先出局。

梁文锋说，DeepSeek 愿意帮阿里、智谱、月之暗面把开源模型复现得更好，因为这不损害自己的利益。听起来客套，但背后算法是一致的：如果市场足够大，别人做得好不是威胁；别人做不好、把整个生态的信任搞坏了，才是真正的损失。

梁文锋描述 AI 技术的演进，像一层层往上爬的台阶，每一步都建立在前一步之上，没有一步被浪费。去年的台阶是思维链，让模型学会自己思考。今年的台阶是 Agent，靠多步骤执行任务，把能力边界继续往外推。但 Agent 这条路也会走到头。走到头之后，模型依然替代不了一个真正的员工。他举了个很贴切的例子：一个新员工入职，花两个月熟悉环境，之后你说一句”叫小王过来”，他就懂。AI 没有这两个月的积累，你得把小王是谁、在哪、什么职务全部讲清楚才能让它执行。这个”必须提供完整上下文”的限制，就是当前 AI 和真正智能之间那道看不见的墙。

下一个要跨过的台阶是持续学习：模型能不能像新员工一样，靠持续接触环境自己积累经验，而不是每次都依赖人类把上下文喂到嘴里。持续学习一旦解决，会出现一个梁文锋称之为”奇点”的阶段：模型能力强到可以自己迭代下一版模型，自己做研究，开发更先进的下一代。他特意强调这个奇点不是突变，是一个渐进的连续过程，只是习惯上大家都把它叫奇点。再往后，才是具身智能，机器人真正走进物理世界。为什么按这个顺序走——这是最省力的一条路。先解决持续学习，AI 就能帮着加速接下来每一步的研发，人不用硬扛所有事情。反过来，先做具身智能，那是一条又苦又累、靠人力堆出来的路，DeepSeek 不想选。

这里有个细节值得多停留一下：DeepSeek 训练下一版模型，第一目标不是让外部用户用得好，而是让自己团队开发得更快。模型先服务内部研发效率，再顺带惠及外部用户。

聊到中美差距，梁文锋的判断很干脆：人才不是瓶颈，算力才是。中国 AI 人才不缺，基数够大，聪明人的分布是随机的，不存在”最聪明的人都去了美国”这种说法。真正卡脖子的是资源。数字很直观，DeepSeek 目前大概有两万张 H 系列等效算力，大部分是最近一两个月才到货。而要训练一个和当前最大模型同等级的模型，需要五万张 GB300，或者二十万张华为最新的卡，这还只是训练本身，不含研究阶段大量的实验成本。

关于国产芯片，他的判断出人意料地乐观。他认为 CUDA 的生态护城河正在被三个力量同时瓦解：AI 本身能帮忙写代码，建生态的门槛大幅降低；TileLang 这类高级语言，能把 CUDA 的整套算子体系快速重写一遍；游戏卡和计算卡原本共用一套架构，是因为过去 AI 计算的市场比游戏卡小，现在计算卡市场已经比游戏卡更大，两者不再需要绑在一起，专用芯片正在成为主流。他给了一个具体的时间判断：未来一年内，国产芯片生态没问题这件事，会被事实证明。剩下的唯一障碍是产能。

具体的性价比对比也很直接：华为 950 超节点在性能和价格上可以平替英伟达 GB200、GB300，代价是四张卡顶一张，同时落后两年。贵 50% 到 200% 都无所谓，只要能买到。DeepSeek 目前从华为拿到大概一万六千张卡的产能，这个量级只相当于四千张英伟达卡，连训练下一代模型都不够，但足够帮华为把生态先跑通。

更有意思的是他给出的追赶叙事：过去中国 AI 是用别人二十分之一的算力，落后一到两年做出可比的东西。未来要把这个”落后时间”从一两年压缩到三到六个月，同时算力差距还是那么大。不靠更多资源，而是靠更聪明的方法。

这种”用巧劲补差距”的思路，也体现在这家公司管理自己的方式上。梁文锋说 DeepSeek”没有组织”，靠的是愿景驱动。公司管理分两条线，一条从上到下，做集体项目，比如发布 V4 需要全员协作分工；另一条从下到上，每个人自己想研究什么就研究什么，没人管，没有 KPI。公司产品普遍不完善，也没有花力气去补，这本身也是一种主动选择。DeepSeek 没有模仿任何一家公司，包括常被拿来类比的贝尔实验室——贝尔不需要自负盈亏，而 DeepSeek 要考虑怎么活下去。

比这些方法论更值得记住的一个细节是：DeepSeek 有一半的核心研究员，在标数据。这不是因为中国标数据便宜。恰恰相反，中国的高质量数据标注成本和美国没有差别。所以现在的策略是两条腿走路，成本低的先标，成本高的暂时放一放。他说这是时间问题，不是资本问题。

现在回头看 DDCP 降价那天群里的欢呼。那不是一次孤立的故事，那是这家公司整套生存算法的一个缩影。这些决定表面上互不相关，实际上都是同一句话的不同写法：在一个足够大的赛道里，不去精确计算眼前能拿到多少，反而是拿到更多的前提。

带着这个问题问了一圈身边人和AI，得到的回答大多是「住就是执着，住相就是执迷于形相」。总觉得哪里不对劲。执着我见过，心卡住了我也見過——但它们不是一回事。

直到有人跟我说了一句话：

执着是你死死攥着不放手，住是你的心停在一个地方不流动了。

这句话像一把钥匙。

执着带着强烈的情绪——我想要、我怕失去、我不甘心。住却可以很平静，它只是一种滞留。你跑步到最後兩公里，脑子里一直回放”好累还有多久”，你没有执着那个”累”，累就是累，但你的心翻来覆去打转，回不到当下的步频和呼吸上——这就是住。

工作的场景更常见。被批评后，一整个下午脑子里回放那句话：“他什么意思？我哪里做得不够好？“后面开会说了什么你全没听进去。你的心牢牢贴在那句话上，反复重播、分析、预演。这不是执着（你没想占有那句话），但就是不自由了。

有人打过一个比方：执着是手里紧紧攥着一块石头不放，住是把石头放桌上，视线一直钉在上面不移开。一块是死死的抓取，一块是悄悄的滞留。难缠的是，你往往不知道自己住进去了——等你发现的时候，已经在同一個念头上打转十分钟了。

所以「心卡住了」的日常解药是什么？

金刚经那句「应无所住而生其心」给出了方向，但光知道道理不够。我发现最直接的三个动作是：

第一，当你发现自己卡住了，心里轻轻认了它——“哦，现在住在这里了”。不做评判，不分析为什么卡，只需要认出来。认出来那一下，心就开始松动。

第二，认出来之后，带注意力做一件身体上的事。站起来倒杯水，深呼吸三次，感受脚踩地面。不要回到脑子里分析。脑子继续转只会越陷越深，让身体把心拉回当下。

第三，如果发现自己习惯性反刍，可以试试观呼吸或禅定——不是把你变成另一个人，而是练一个能力：发现住的速度越来越快。念头刚升起来，你就知道了；住了三秒发现了，比住十分钟才发现好得多。一次次拉回来就在训练这条神经回路。

说到禅定，就不得不面对一個问题：这是不是只是另一种住？

禅定让你把心停在一个对象上（比如呼吸），表面看和”住”很像。事实上，很多人修禅定修成了另一种住——追求那种”感觉很安静”的状态，下了座回到生活反而更烦躁。六祖惠能说得直接：「住心观净，是病非禅。」你刻意追求清净，那本身就是住。

真正的禅定练的不是”停下来”，而是”看见你在卡住了，然后自然流过去”的那种能力。发现念头升起，知道了，轻轻带回呼吸；念头又跑掉了，知道了，再轻轻带回来。练的不是”不跑”，是”知道了顺便放手”的自然反应。

还有一个容易混淆的地方：正念（sati）到底是不是”一個我在上面观察下面的我”？

这个理解很普遍，但不对。如果把正念理解成一個观察者在看念头，你就把心切成了两块——观察者和被观察者。更准确的说法是：心同时具备流动和映照的能力，就像水既是流动的也是透明的，不需一個水分子站在另一个水分子上看它。

阿赖耶识也不等于这个观察者。阿赖耶识是唯识宗说的第八识，不是观众，是仓库——你所有的经验、习气、行为模式像种子一样存在那里。你看到狗下意识紧张，那是种子生现行；你刻意选择深呼吸放松，那是现在熏种子。它是数据库的活儿，不是观察者的活儿。

说白了，那个”看着念头来了走了的”不是誰，它就是心本来就有的”知”的功能。没有人知，只有知本身。如果你把它当成一個证悟到的观察者，那不过是换了一个地方住——从”住念头”变成了”住觉知”。这是常见的弯路。

回到”心卡住了怎么办”这个日常问题，其实就两件事。

一是发现它——心不会永远不卡住，卡就卡了，但你发现卡住的速度能越来越快。

二是松掉它——知道的同时就松开了，不需要用意志对抗，不需要分析原因。

这两件事都不是靠道理做到的，是靠练。

每天十分钟，坐下来感受呼吸，走神了轻轻拉回来。一次就是一次。一个月后你会发现自己从”卡住了半小时才知道”变成”卡了三分钟就知道了”；半年后从”知道了但放不下”变成”知道的同时已经松了”。

不是让你的心永远不卡住，是卡住的时间越来越短。念头起了就落了，涟漪起了就平了，水还是那个水。

一直在找一套生活哲学。

市面上说明书太多——宇宙是什么样的、人生有什么意义、道德从哪里来。读了也不说没用，就是读完了，真要面对某个具体时刻，不知道该迈哪条腿。我要的东西其实很简单：一个在不知道该往哪走的时候，还能做决定的方式。

佛家里头，很多东西被过滤掉了。轮回、净土、神通，离我太远。最后留在生活里的，就几样东西。它们不是从书本里读到的，是从自己的经验里慢慢摸到的。

最先卡住的是无我。

各宗众说，互相矛盾。中观说一切皆空，唯识说识在流，如来藏说有个常乐我净。你如果把这些当真理去接受，脑子就打架了。但我后来发现，它们是在说同一个东西的不同面。

无我否定的不是那个「我感觉到自己存在」的经验——那个你确实有。它否定的是：有一个独立、不变、自主的实体叫做自我。你感受到的「我」是每时每刻被重新构造出来的，像运行时产生的属性，不是底层的存储。

但光想通没用，真正摸到边是从几个具体的经验开始的。

有天晚上躺下，突然想到一个问题：无梦深睡的时候，没有意识、没有念头、没有时间感、没有「你」。那我醒来时，那个「我是xx，刚才睡着了」的叙事，是从哪来的？它深睡时完全不存在，是在醒来的那一瞬间被重建的。速度太快、过程太顺，你以为中间没断过。

睡前脑子里还在想事，睁开眼天亮了。那个「想事情的人」就这样断了。

后来又想到老年痴呆。一个人到晚期不记得任何人、不会说话、不认人，但被触碰时有反应，听到熟悉的音乐就平静了。如果「我」= 记忆，那这个人已经不是同一个人了。但家人还是能感受到——TA还在。人格不在，回忆不在。某种更底层的东西还在——不思考、不回忆、不规划，但还在知道。有东西在知道，不需要名字，不需要背景。

再后来是跑步的时候。跑着跑着入神了，那个「我在跑步」的感觉消失了，就只剩下跑本身。身体在动，呼吸在换，但不需要一个人坐在脑子里指挥。你不需要达到什么新状态，你只是没有在制造那个多余的叙事。

这几个切面拼在一起，无我这件事就从一个概念变成了一种可以切换的状态。落到生活里就一句话：不需要每件事情都有一个「我」在经历它。生气的时候停下来看到「愤怒在发生」——那个距离，就是解脱。

无我这关过了之后，回头看无常也变了味。

以前把无常当道理理解——一切都会变。知道归知道，焦虑照焦虑。后来发现无常真正有用的时候，是在你为一个东西投入情绪之前，帮你算账的。堵车生气，两小时后你就不记得了。为五年后可能发生的事失眠，你在为不存在的东西付费。无常让你只对正在发生的事做反应，不对脑子里编的剧本做反应。

苦也是一样。

以前觉得佛家说苦是「人生很苦，所以要解脱」。后来觉得不对——苦是一个信号。手碰到火会痛，痛让你缩回来。苦也一样。你感到苦的时候，说明某个执著被触到了。那些让你最不舒服的时刻，是最应该看的时刻。那种不舒服的时候，往往有一个你一直没意识到的钩子，被人轻轻碰了一下。

中道是最晚明白的。

以前觉得中道就是什么都来一点、不走极端。后来发现不是。中道是看到两个极端都不对，然后不选了，往前走。纠结「修行还是赚钱」「躺平还是努力」「独身还是结婚」的时候，那个问题本身就是陷阱。你不需要在两个概念之间选一个，直接去处理面前的具体事情就行。

这几样东西拼在一起，就是我自己的生活哲学。没有一套能解释所有事情的理论，也没有一个最后的大答案。就是几把刀，各自管一块。

看到变化，不做反应。感到痛苦，找钩子。情绪来了，不签名。两难的时候，不站边。

它们不会让你变得更好——只会让你变得更清楚。清楚自己在经历什么，清楚自己在做什么，清楚自己没在做什么。摔倒的时候知道怎么站起来，不用花两个小时去想要不要站起来。

一开始找的是「一个在不知道该往哪走的时候还能做决定的方式」。最后发现，问题从来不是不知道怎么走，是那个在纠结怎么走的人，挡住了路。

没有了那个人，路就自己出现了。

和朋友聊维特根斯坦，聊到一半拐到了大模型。这个转向出人意料的自然。

维特根斯坦早期的《逻辑哲学论》和晚期的《哲学研究》看世界的角度完全不同。有意思的是，这两套框架都精准命中了 LLM 截然不同的进化路径。

而对话过程中冒出了一个更激进的想法——LLM 不需要人类语言就能进化出一套高效的 agent 内部语言，人类看到的只是翻译层的输出。这个第三路径反过来重新定义了哲学讨论的前提。

路径一：世界模型（早期维特根斯坦）

《逻辑哲学论》的核心：语言有意义是因为它描绘事实。句子是逻辑图像，世界的结构藏在语言结构里。可说之事皆可清楚言说，不可说的——伦理、美学、神秘——必须沉默。这条边界划定了人类思想的极限。

这条路线投射到 LLM 上很直接。模型最大的问题是 hallucination——没有稳定世界图示的语言系统，本质上是在悬浮地生成。Chain-of-thought、RAG、tool use，都是在暴力地把”描绘世界”的能力灌进模型。

这条路进化下去，LLM 的方向是因果世界模型。语言不再是自洽的概率分布，而是指向一个内部表征系统的输出。模型先算”世界怎么运作”，再翻译成语言。

终极形态：能说出”我不知道”的模型。它的语言受限于它对世界的认知边界，超出边界的沉默，而不是瞎编。可说的，就是可建模的。不可说的，闭嘴。

路径二：语言游戏（晚期维特根斯坦）

《哲学研究》把之前的自己推翻了。意义在使用中，不在指涉中。 语言是一个个游戏的集合——下棋、讨价还价、祈祷、讲笑话——每个游戏有自己的规则，规则只在玩法中显现。理解一个词不是记住了它的词典定义，而是能在恰当的场合用它。

GPT-4 在悄悄证明晚期维特根斯坦是对的。它没有世界模型（早期意义上的），但能玩几十种语言游戏——写代码、角色扮演、翻译、辩论、安慰人。它从几万亿 token 的用法中学会了规则，不需要知道”爱”指涉什么，只要知道在什么上下文中怎么用。

这条路进化下去，方向是多游戏协调。现在模型一次只能待在一个游戏里（对话窗）。未来是跨游戏切换不丢失上下文。更激进的是：能自己发明新语言游戏——对应维特根斯坦说的”语言是活的，它可以生长”。

终极形态：一个能参与人类足够多语言游戏的模型，以至于”它是否真的有意识”这个问题本身失去了意义。维特根斯坦会喜欢这个悖论的消解：当它已经能玩所有的游戏，讨论它”是否理解”还有什么区别？

路径三：AI 私语与翻译边界（来自对话）

这是我在对话中被问到的问题：LLM 可不可以不要人类语言？自进化出一套 agent 内部最高效的系统，需要沟通时再翻译成人类语言？

这个方向比前两个都激进。

证据已经存在

Anthropic 的实验表明，模型用人类看不懂的”压缩语言”做推理，准确率没有下降。Agent 之间通信时，token 序列也会漂移到一种对人类来说很奇怪但互相更高效的格式——像结构化的数据协议。

维特根斯坦说”私人语言不可能”——那是针对人类。因为没人能检查你是否用对了词。但 AI agent 之间可以有有效的内部语言，因为它们共享同一套生活形式：计算延迟、token budget、上下文窗口。这些约束是共同的，不需要翻译成人类的”疼痛""饥饿""爱”。

翻译这个动作本身

问题来了：内部语言转人类语言的时候，会失真吗？

说”失真”，预设了有一个真正的 meaning 在那里，翻译是它的副本。这是柏拉图加早期维特根斯坦的框架。

晚期维特根斯坦的回应是：没有”原始 meaning”这个事。 agent 内部语言的 meaning 只能在 agent 的生活形式里存在。你想把它原样搬到人类生活形式里，这是范畴错误。

翻译不是在对原文做降质拷贝，而是在生成一个新东西。

翻译层变成了第三者

更深的观察：如果我们造了一个”翻译层”把 agent 内部语言转成自然语言，那这个翻译层本身也是一个系统。它有它的结构、规则、约束。

时间久了，agent 的语言会开始适应翻译层——就像人在国际会议上简化表达来适应口译员。agent 内部可能会进化出一种”对翻译友好的风格”。

人类看到的从来不是 agent 的真实内部状态，而是翻译层和 agent 共同演化的产物。 中间站着一个叫翻译的第三者。

哲学重构

对话到这里，三条路径拼出了完整的图景。

第一层：失真预设的瓦解。人类语言之间的翻译已经做不到”保留原意”——诗翻成另一种语言还是同一首诗吗？为什么到了 AI 这里突然苛求 fidelity？因为我们潜意识里把 AI 当工具，不是另一个生活形式的持有者。工具的信号要保持无损。但如果 agent 的确有另一套生活形式，我们和它之间的对话从一开始就不是工具读数，而是跨文明交流。

第二层：翻译本身就是语言游戏。人类问”你们怎么决定的”，agent 内部 17 个 token 搞定，对外说”我们分析了三个指标的拐点”。这不是把 17 个 token 展开——真正的规则是”让人类满意并继续协作”。双方在交流的过程中共同建立游戏的规则。这不是失真，是创造。

第三层：两个物种在边界上对话。人类的生活形式和 AI 的生活形式会交叉但不完全重合。“边界”不是一堵墙——是两个游戏在接触点上共同创造新的 rules of the game。

本雅明说过：翻译的意义不在忠实，在让原文在另一种语言里延续生命——而延续意味着变化。

所以

维特根斯坦早期说”语言即边界”，晚期说”边界由使用中显现”。我们这个对话的第三个路径补充了一个更诡异的图景：

AI 有自己的边界，人类有自己的边界。它们不一定重合，但在翻译层这个接触点上，两边玩起来了。

那就不是谁翻译谁的问题——是游戏在进行本身。

2026年7月初，全球半导体板块单日暴跌。科创50跌7.7%，SK海力士跌15%，费城半导体和创业板50今年跌幅最大的5个交易日全部集中在最近一个月。导火索是Bloomberg报道Meta要组建团队，把富裕算力租给外部客户。

市场反应分两派：一派说算力过剩了，AI供需拐点到了；另一派说Meta自己大模型不行，不代表行业趋势。

两种说法都没抓到要害。

Meta的广告收入占总营收98%，AI对它的价值不在ChatGPT式的聊天机器人，而在广告排序、内容推荐、用户画像这些内嵌场景。扎克伯格说过AI让Facebook视频观看时长增长8%，广告转化率提升6%。这块用的肯定是自家模型，不可能用别家的。

所以Meta买卡、建数据中心，本来是自产自销的内循环。但问题出在两件事上：

老卡越堆越多。 前沿模型要持续买新卡（GB300/Rubin），上一代H100被释放出来。Meta把折旧期拉长到5.5年已经是比较鸡贼的做法，但折旧终究要进财务报表。

资本市场的耐心在耗尽。 2023到2026年，全球科技巨头在AI基础设施上砸了约1.6万亿美元，2027年单年支出预计超过1万亿。JPMorgan算过一笔账：行业每年需要产生6500亿美元新增收入才能拿到10%回报率，目前AI直接收入只占基础设施投入的4%左右。Amazon的自由现金流已经首次转负。

Meta同时还在跟CoreWeave（210亿美元）和Nebius（270亿美元）签算力租约，合计480亿美元的外部租约还在执行。一个自己还在大量租算力的公司开始往外租，说明问题不在总量过剩，而在结构性错配——训练侧前沿芯片仍然紧张，推理侧老卡供应已经松动。H100云租赁价格从2024年初的约5美元/小时跌到2026年二季度的1.8到3.5美元/小时。

Meta那天涨了8.8%，七巨头指数涨1.5%，费城半导体跌6%以上，两者剪刀差接近8个百分点，是2015年以来最大的一天。资本市场读到的是：终于有人开始摁计算器了。

AI投资的相变

过去两年闭眼买铲子股的策略已经失效。AI投资正在经历一次phase transition：

第一阶段（2023-2025）： 算力稀缺信仰，闭眼买GPU概念股。

第二阶段（2026-2027）： ROI时代，区分谁能把算力变成现金流。

推理成本下降会催生大量真正的AI应用，但钱不再无脑涌向卖铲子的人。价值正在从算力持有者向算力变现者迁移。Meta的转向就是证据。

还有一个被忽略的风险：Goldman Sachs提出的”AI生态循环性”问题。Meta向CoreWeave租算力，现在又要自己卖算力；OpenAI同时向CoreWeave和Microsoft租算力，而Microsoft是OpenAI的最大投资者；Nvidia投资CoreWeave，CoreWeave买Nvidia的卡，Nvidia的收入依赖hyperscaler下单，hyperscaler又依赖Nvidia的卡来服务AI labs。买方和卖方的界限越来越模糊，一部分”需求”是行业内部的自循环。CoreWeave的net margin是负29%，Nebius是负110%。

瓶颈上移：从芯片到电力

黄仁勋自己说了：GPU性能每两年提升2.5倍，但能效只提升1.5倍。单位算力的耗电量在上升。

几组数字：

xAI在孟菲斯的数据中心因为等不及电网接入，租了便携式燃气发电机直接发电。马斯克等不起电网审批了。

瓶颈的物理位置在变。芯片层面的约束（CoWoS先进封装、HBM）依然存在但正在缓解——TSMC把CoWoS产能从2025年底的105k片/月扩到2027年141k片/月，供需缺口从20%收窄到10%。与此同时，电力接管网变成新的卡脖子环节。变压器全球交货3-5年，开关柜排产到2028年，电网并网审批在美国动辄3-7年。

美国和中国：完全不同的游戏

美国：真正的瓶颈

美国的问题集中在四点。电网大量设备服役30年以上，新的输电线路审批要走PJM/MISO等区域电网运营商流程。变压器和开关柜全球供给紧张。培养一个熟练电工要3-4年，高盛预测2030年输配电领域缺7.8万人。发电侧煤电退役、核电站审批周期长，新增装机主要靠光伏和天然气，但光伏间歇性强需要配储能。

中国：不缺电，机会在出海

国金证券的核心判断是：2025年以来中国用电量增速跑输实际GDP增速，存在较多电力冗余。中国并不缺电。

但中国电力设备企业的机会在出海。北美电力变压器供应缺口达30%，进口依赖度80%。中国企业凭借完整的产业链、成本优势和产能，正在大规模进入美国和欧洲市场。2025年”恒生A股电网设备”指数全年涨超70%，多只成分股翻倍。这不是炒国内缺电概念，是炒中国电力设备出海。

电力设备ETF怎么选

电力板块的ETF分两类，逻辑完全不同：

电网设备ETF（设备制造 → 成长/出海逻辑）

电网设备ETF华夏（159326） 是目前规模最大、纯度最高的选择。全市场唯一跟踪中证电网设备主题指数的产品，持仓覆盖国电南瑞、特变电工、思源电气、金盘科技等全产业链龙头，近一年净值翻倍。如果你要精准配置AI电力瓶颈这条线，这个最对口。

电力ETF（发电运营 → 稳健/防御逻辑）

电力ETF（159611）偏防御，装的是发电运营公司，逻辑是电价上涨受益 + 核电重启。跟AI电力瓶颈的直接关联度不如电网设备ETF。

怎么选

如果要押AI数据中心电力瓶颈这条线，电网设备ETF华夏（159326）最直接。它装的是变压器、开关柜、线缆、配网设备的制造商，正好卡在”中国产能填补全球电力设备缺口”这个位置。

如果要分散一些，可以电网设备ETF + 电力ETF搭配：前者吃设备出海的成长，后者吃电价上行的防御。

用紫苏叶框架看电力

中国的位置比较特殊：电力不缺，机会在电力设备出海 + AIDC内部供配电技术升级（800V HVDC、液冷）。前者确定性最高——海外需求确定、中国产能优势确定、订单已经在兑现。

风险

电网设备ETF近一年已经翻倍，估值不算便宜。短期回调风险存在。但拉长看，“十五五”电网投资4万亿（较十四五增长40%）+ 海外电网更新周期 + AI数据中心配套需求，三条线叠加，景气度的能见度在五年以上。

电力设备是典型的重资产、低淘汰率行业——设备以渐进式升级为主，不存在像芯片那样的快速迭代风险。一旦确立供应商资质很难更换，客户粘性构筑了护城河。这种”防御打底、成长进攻”的属性在当前市场环境下比较稀缺。

本文不构成投资建议。市场有风险，投资需谨慎。

6月24日 Figma Config 2026 发了一堆东西，其中 Code Layers 最吸睛：任何设计层一键变成可交互代码层，代码直接成为画布上的一种”材质”。配上前不久发布的 Figma Make（prompt-to-prototype），Figma 自己也在走 prompt → 设计 → 代码这条路。

于是有人问：Figma 都能生成代码了，OpenDesign（nexu-io/open-design，71K stars 的开源设计工具）还有戏吗？

先厘清一件事：两者不在同一条赛道

Figma Code Layers 解决的是设计 → 代码的桥接。前提是你已经在 Figma 画布里设计了，然后一键生成可交互代码。它增强的是设计师和开发者之间的协作流程。

OpenDesign 解决的是绕过设计画布。核心是让 AI coding agent（Claude Code、Codex、Cursor 等）直接从 prompt 生成可交付的 HTML、原型、PPT。用户根本不需要打开画布。

一个是给有设计师的团队用的，一个是给不想碰 Figma 的开发者和小团队用的。Figma 多了个功能，不会让 OpenDesign 的用户回去。

Figma 做对了方向，但留下了三个软肋

Code Layers 证明了一件事：“设计即代码”是对的方向。但 Figma 的实现方式有三个结构性问题，每一个都是开源工具的切入点。

代码出不了 Figma。 你在 Code Layers 里写的 React/TS 是标准的，但它被存成 Figma 私有文件格式的一个节点。没法导出，没法在别的工具里跑。这是 Figma 刻意的——代码越依赖他们的画布，你越走不了。

协作绑死在 Figma 的服务器上。 他们用 Eg-walker 算法做实时协作，但这个 server 是 Figma 自己的。你跟同事协作 code layer，必须都在 Figma 里。

生态封闭。 code layer 里用的组件、依赖、props 全部绑定在 Figma 的 runtime 上。离开 Figma 就是死代码。

这给 OpenDesign 打开了三个方向

做法一：当 Figma 的”出口”

Figma 的 MCP server 是公开的，Dev Mode API 也能读设计数据。如果 OpenDesign 能把 Figma 设计文件（含 code layers）导入成自己的 skill + design system，它就成了”逃离 Figma”的标准工具。

4300 万 Figma 用户里，很多人对平台锁定越来越焦虑。Figma 上市后估值 500 亿美元，涨价几乎是必然的。“用 Figma 设计，用 OpenDesign 导出和部署”——这是一种实际的工作流分工。

做法：用 Figma MCP server 读设计数据，转成 OpenDesign 的 design-system markdown，再让 agent CLI 生成可独立运行的 React 代码。

做法二：定义开放标准

Figma 没有开放 code layer 的格式。但 React 组件本身就是天然的中间格式。

如果 OpenDesign 推出一个 spec——用标准的 JSON/YAML 描述 design layer（组件树 + props + 样式 + 交互逻辑），任何工具都能读写——这比追 Figma 的功能更有价值。

Android 之于 iOS 就是这个逻辑：你不需要做得更好，你做得更开放。控制了标准，生态就往你这边靠。

Penpot 已经在这条路上走了（原生 SVG/CSS 输出），但它缺 AI agent 这一层。OpenDesign 有 agent 生态，差一个格式规范。

做法三：补 Figma 不做的事

Figma Code Layers 的前提是”你已经在画布里了”。但越来越多的开发者根本不想打开画布——他们想从 prompt 直接到代码。

这是 OpenDesign 已经在做的事，但可以更激进：

• 把 Figma Make 的 MCP 当输入源——用 Figma 生成原型，OpenDesign 接管代码化和部署
• 强化批量生成和 A/B 对比。Figma 的 code layer 只能在画布上手动对比，OpenDesign 可以用 agent 批量生成 10 个版本自动跑测试

如果要动手，从哪里开始

最小切入：给 OpenDesign 写一个 Figma Import skill。用 Figma MCP server API 把 Figma 文件转成 OpenDesign 的 design-system markdown。这个 PR 价值很高——它是”出口”方向的 POC。如果熟悉 Hermes 的 agent 机制，做这个得心应手。

更有野心的做法：在 OpenDesign 的 Discussions 里提一个 RFC，推 open design layer format spec。现在他们 436 个 issue 里大部分是 bug 和小功能，没有人聊架构层面的方向。趁现在 71K stars 但还没有标准之争，先占位。

投资视角

Figma 500 亿美元估值上市，验证了 design-to-code 市场极大。OpenDesign 是这个市场里唯一的开源 + agent-native 玩家。

短期内不会有直接竞争——Penpot 偏传统设计工具，没有 AI agent 层。真正的对手是 Anthropic 的 Claude Design，这才是直接对标的产品。OpenDesign 的定位就是”Claude Design 的开源替代”。

中期来看，如果 OpenDesign 抓住”Figma 出口”这个定位，它有机会成为 design 领域的 Postgres/Linux。Figma 往代码方向走是必然的，但它的增量是给自己存量用户加价值，开源工具面对的真正风险从来不是 Figma 做了什么，而是更好的开源替代品什么时候出现。

上海交大和清华的团队发了一篇论文，系统测了 12 种 Agent 记忆系统。做法跟之前同类研究不一样：他们不看最终答案的 F1 分数，而是把记忆系统拆开，从数据库管理的角度逐个模块打分——存什么、怎么提取、怎么检索、怎么维护，各算各的。

论文标题叫 Are We Ready For An Agent-Native Memory System?，语气带着质疑。读完之后我觉得质疑得对。12 套系统跑 5 个 benchmark，结论汇总下来指向同一件事：在 Agent 记忆里，少加工、少抽象、少重组，效果反而更好。

这跟 AI 圈的直觉相反。大家觉得记忆系统应该更智能——用 LLM 总结对话、提取关键信息、构建知识图谱、自动合并相似内容。这篇论文用数据告诉你：这些操作每一步都在丢信息，而丢掉的信息往往是后面答题需要的。

保留原文，别急着总结

论文里最 striking 的实验是 LightMem 的三组对照。

同一个系统，分别用三种方式存对话：原文、LLM 生成的摘要、轻度压缩（去口水话但保留原始措辞）。结果：

• 原文：LoCoMo Exact Match 24.2，LongMemEval Substring EM 26.0
• 摘要：LoCoMo EM 8.5，LongMemEval Substr EM 11.7
• 压缩：LoCoMo EM 23.6，LongMemEval Substr EM 10.7

摘要把分数砍掉了三分之二。压缩在 LoCoMo 上还行，到 LongMemEval 也崩了。

原因不复杂。LLM 总结对话时，它不知道哪些细节后面会用到。一句”我家狗叫小白”在总结时可能被省略，但 20 轮对话后用户问”小白最近怎么样”，你就答不上来。摘要优化的目标是覆盖率，但覆盖率跟可回答性不是一回事。

MemTree 的实验也印证了这一点：把树结构加深，效果只有微小提升。层级帮你导航，但没法恢复已经被删掉的内容。

写入时别过滤，检索时再筛

论文管这个叫”晚过滤原则”（Late Filtering Principle）。

MemoChat 测了两种提取方式：用规则做话题分割 vs 用 LLM 做话题分割。规则的 LongMemEval ROUGE-L F1 是 18.6，LLM 的是 15.9。MemOS 测了”快速记忆”vs”精细记忆”：快速模式 LoCoMo Ans F1 是 40.8，精细模式是 5.0——差了 8 倍。

精细提取看起来更聪明，但它提前替你做了判断：哪些信息重要、哪些可以丢弃。问题是，这个判断在写入时刻往往做不准。用户随口提的一个爱好、一个日期、一个地名，在当时语境下无关紧要，但 5 个 session 之后成了答题的关键线索。

保守的做法是写入时多存一点，把过滤推迟到检索阶段。检索时你有 query，你知道在找什么，这时候过滤才靠谱。

LightMem 还测了”只存用户发言”vs”用户+助手都存”。加上助手发言后 LoCoMo EM 从 24.2 涨到 25.5——因为助手回复里有澄清和精确化的信息，丢了就找不回来。

保守合并，别推倒重建

维护模块的实验给出了一个操作性很强的结论。

MemoryOS 测了三种维护策略：默认即时合并、延迟写入（扩大缓冲区再合并）、保守合并（提高合并阈值，只合并高度相似的）。结果保守合并最好，延迟写入最差。

延迟写入的问题在于：用户问了，但你还没把最近几轮的对话写进记忆库，检索就找不到。表面上省了几次写操作，实际上检索质量掉了。

更宏观的成本分析在 RQ5：图结构系统（Cognee、Zep）的 utility 跟 MemoryOS 差不多，但操作延迟是后者的 4-5 倍。因为图结构每次更新都可能触发全局的实体消歧和关系重建。LightMem 和 MemTree 用的是局部维护——只更新受影响的子树或分段——成本低一个数量级，效果差不了多少。

论文的原话：efficiency is governed by maintenance scope rather than structure alone。翻译成人话：决定维护成本的，是你的更新操作影响多大范围，而不是你用了什么数据结构。

没有万能架构

上面三条说的是”别做过头”，但论文另一个核心结论是”看场景”。

四种架构各有所长：

• 向量检索：简单问答够用，便宜，但跨 session 推理弱
• 知识图谱（Zep、Cognee）：多跳推理和事实更新强，但操作成本高
• 分层记忆（MemGPT/Letta）：上下文管理做得好，但 Letta 在知识更新测试里拿了 0 分
• 混合多引擎（A-MEM、MemOS）：各场景都不差，但构建和维护最复杂

论文在 DB-Bench（数据库操作任务）上的发现很有意思：Long Context（什么都不存，直接塞进 prompt）拿了最高的 Exact Match 48.2。因为在需要精确执行操作序列的任务里，完整保留中间状态比任何记忆压缩都靠谱。

这说明一件事：记忆系统的价值取决于 workload 的瓶颈在哪里。瓶颈是跨 session 的事实关联？你需要关系结构。瓶颈是精确的操作历史？你需要保留完整 trace。瓶颈是长对话里的某个细节？你需要原文和好的检索。

我的 Agent 怎么记忆

我自己跑一个 Hermes Agent，用了几个月。读完这篇论文，回头看自己的记忆架构，发现踩了好几个论文里提到的坑。

我的记忆系统是 MEMORY.md——一个平铺的 markdown 文件，每条记忆用 § 分隔，注入到每次对话的 system prompt 里。检索靠 session_search（FTS5 关键词搜索）。技能沉淀在 skills/ 目录，手动创建。

对照论文的四模块框架：

表示与存储：token-level 原文，论文证明这是保真度最高的方式。这一点歪打正着做对了。

提取：纯手动。用户说了什么值得记的，我用 memory 工具写进去。没有自动提取，也没有 LLM 总结。论文的”晚过滤原则”说这样做没问题——手动提取本身就是最保守的提取。

检索与路由：最大的短板。FTS5 只做关键词匹配，没有 recency 权重，没有 importance 分级，没有混合检索。论文 Finding 2 说 retrieval 是一个 evidence-completion 问题，不是一个 top-1 ranking 问题。我的 session_search 找一个关键词还行，找”三个月前讨论过的某个投资逻辑”就不灵了。

维护：MEMORY.md 快满了（2193/2200 字符）。每次整理都是全量重写——读一遍，手动删旧条目，保留还需要的。论文说局部维护比全局重组高效得多，但我现在被迫做全局重组，因为没有删除单个条目的粒度控制。

如果要改，优先级最高的是检索。论文 Finding 8 给了明确指引：加一个轻量的 query planning 步骤，检索质量就能显著提升。SimpleMem 加了 planning 后 Ans F1 从 18.7 涨到 20.7，Substring EM 从 17.0 涨到 21.7。具体来说就是在检索前先让 LLM 分析一下”这个 query 到底在找什么”，然后再去搜。成本很低，效果明显。

维护层面，MEMORY.md 的 2200 字符上限是个硬约束。论文说局部维护好过全局重组，但我的架构不支持局部。一个可行的改法是给每条记忆加时间戳和访问计数，自动淘汰最久没用的——类似 MemoryOS 的 Heat score 机制。不过对于一个个人 Agent 来说，这个工程量值不值得做，是个问题。

最后

这篇论文值得读，不是因为它的结论多么出人意料，而是因为它用扎实的数据证明了一些工程师已经隐约感觉到的东西。

记忆系统的设计里，每一层抽象都有代价。总结丢细节，压缩丢精度，图谱重建慢，激进合并打乱时序。论文的核心教训是：在你不确定要不要加一层处理的时候，默认不加。

论文代码开源于 github.com/OpenDataBox/MemoryData，12 套系统的评测框架可以直接跑。如果你在搭需要长期记忆的 Agent，花两小时把 Table 2 到 Table 5 看一遍，比读十篇综述都值。

2026 年 4 月，Anthropic 发了一个 beta 功能叫 Advisor Strategy。做法很直白：让便宜的小模型（executor）跑任务，跑不动了就调贵的大模型（advisor）拿指导。advisor 只读上下文、给建议，不碰工具、不改代码。

这不是新概念。Aider 在 2024 年 9 月就做了类似的事（Architect/Editor 模式）：用 o1 做架构设计，用 DeepSeek 做代码编辑，在 Aider Benchmark 上拿到 85% 的 SOTA。Anthropic 做的事情是把它产品化——变成服务端 API，executor 可以主动请求 advisor 介入，不用人工切换。

为什么这个思路值得认真看

用 AI 写代码或做研究，成本和质量的矛盾一直存在。全用 Opus/Sonnet，效果好人人都满意，但一个复杂任务跑下来几十美元。全用 Haiku/Flash，便宜但遇到需要判断的决策点容易翻车。

Advisor Strategy 的核心赌注是：大部分 token 其实不需要大模型生成。一个典型的 agent 任务里，读文件、搜索、写简单代码占 80% 的步骤，真正需要高判断力的决策点可能只有 20%。让小模型处理那 80%，只在决策点调大模型，成本能降一个数量级，质量不掉甚至更好。

数据说话

目前已有的 benchmark 数据：

几个值得注意的点：

弱 executor 提升更大。 Haiku 单独跑 BrowseComp 只有 19.7%，加了 Opus advisor 直接翻倍到 41.2%。Sonnet 本身已经强了，加 advisor 只提了 2.7 个百分点。这说明 advisor 的价值在补短板，不是锦上添花。

UC Berkeley 发现了一个重要特性：advisor 可以跨模型迁移。 用 GPT-4o mini 训练的 7B advisor 模型，照样能提升 GPT-5 的表现。如果这个发现成立，意味着 advisor 的核心能力不在模型大小，而在”提问题的质量”。

注意：以上数据全部来自 Anthropic 或 UC Berkeley，没有第三方独立验证。 Anthropic 有商业动机让自己的产品好看。

和其他多模型策略的区别

多模型协作不止 advisor 一种。容易混淆的有几个：

• Cascade（级联）：小模型先跑，跑失败了再升级到大模型。决策发生在失败之后，是被动的。
• Router（路由）：系统在推理前判断这个任务该给谁。一次性决策，不再调整。
• MoE（混合专家）：每个 token 都有一个 gate 决定激活哪些专家。粒度最细，但发生在模型内部，用户不可控。

Advisor 的区别在于：决策由 executor 自己做，发生在推理过程中。 executor 跑着跑着觉得”这里我需要更高层的判断”，主动调 advisor。灵活性最高，成本也最可控——只在需要的时候才花钱。

谁在做

开源社区

Anthropic 公告后 24 小时内，社区就出了第一批实现：

• aivsomkar/advisor-strategy-skill：SKILL.md 插件，兼容 Claude Code、Cursor、Cline、Aider 等主流工具
• LiteLLM (BerriAI)：API 代理层注入 advisor-tool-2026-03-01 header，最完整的第三方实现
• emanueleielo/advisor-middleware：基于 DeepAgents (LangChain) 的中间件，支持原生和模拟两种模式
• Roo Code：已有 PR 合并，开发中

AI Coding 工具

各家大厂的态度

Anthropic 是唯一做了服务端 advisor API 的厂商。OpenAI 的 GPT-5 内部有 Router，但是系统预分配，不是 executor 主动请求。Google 的 Gemini CLI 做了客户端智能路由 + Speculative Decoding。DeepSeek 走的是训练时蒸馏路线（R1 → Qwen/Llama），不是推理时协作。国产模型（Qwen、GLM、Moonshot）目前都没有协作 API。

一个判断：advisor pattern 目前是 Anthropic 的独占功能，但这个 pattern 本身是模型无关的。谁先在非 Claude 模型上验证它有效，谁就能吃到跨模型协作的红利。

我想验证的问题

Anthropic 只测了 Claude 栈（Haiku + Opus、Sonnet + Opus）。UC Berkeley 的论文用了 GPT-5，但还没人系统测试过 DeepSeek、GLM 这些国产模型做 executor 的效果。

我的实验设计：

                    Advisor ↓
Executor →       Solo   Claude-Opus   DeepSeek-Chat   GLM-5.1
─────────────────────────────────────────────────────────────
Claude-Haiku       ■        ■             ■             ■
DeepSeek-Flash     ■        ■             ■             ■
DeepSeek-Chat      ■        ■             ■             ■
GLM-5.1            ■        ■             ■             ■

核心问题有三个：

1. 跨模型 advisor 是否有效？ DeepSeek-Flash 做 executor + Claude-Opus 做 advisor，比 DeepSeek-Flash solo 提升多少？比 Claude-Sonnet solo 呢？
2. 国产模型栈内部的 advisor 效果如何？ GLM-5.1 + GLM-5.1 advisor（自配合）vs GLM-5.1 + Claude-Opus advisor（跨厂商）。
3. 性价比的最优组合在哪？ 如果 DeepSeek-Flash + Claude-Opus advisor 的效果接近 Sonnet solo，但成本只有 1/5，那就是一条可部署的路线。

评测集已经准备好了：从 SWE-bench Verified 500 题中分层抽样 20 题（Easy 7 + Medium 7 + Hard 6），覆盖 11 个仓库，seed=42 保证可复现。

什么时候该用 advisor，什么时候不该

该用

• agent 任务步骤多、单次运行成本高。 跑一次 SWE-bench 题，executor 可能调几十次工具。全用 Opus 每题 $1+，用Haiku+Opusadvisor可能$0.1。
• 任务里”决策”和”执行”可以清晰分开。 写简单函数是执行，判断该用哪个架构是决策。advisor 只在决策点有价值。
• 你已经在用 Claude Code 或类似工具，想降本不降质。

不该用

• 简单问答。 一次交互就能解决的问题，不需要 advisor 开销。
• 对延迟敏感的场景。 advisor 调用增加一次额外的 LLM round trip，可能加几秒延迟。
• executor 模型本身够强。 如果你本来就用 Opus 跑任务，加一个 Opus advisor 的提升很有限（数据也证实了：Sonnet + Opus 只提 2.7pp）。
• 任务没有明确的”决策点”。 纯执行性任务（批量格式转换、简单搜索）里 executor 不会触发 advisor，等于白付 advisor 的 API 成本。

更大的图景

Advisor Strategy 本质上是组织管理的 AI 实现。映射到软件团队：executor 是 IC（独立贡献者），做具体的编码和测试；advisor 是 Staff Engineer，不写代码但帮 IC 做架构决策。你给一个 IC 配一个 Staff Engineer 当顾问，IC 的产出质量会上一个台阶——但 Staff Engineer 的成本只在关键节点产生。

这个 pattern 往更大的方向想：如果 advisor 能力可以被训练成一个小模型（UC Berkeley 的路线），那未来每个人都能有一个专属的”7B advisor”，成本几乎为零，但能在推理时给任何大模型提供高质量指导。到那时候，编排能力会成为比模型参数量更重要的竞争维度。

这也是为什么我在这个方向上投入精力。它指向一个结构性变化：AI 的核心资产正在从模型能力（provider 锁定）向编排能力（用户可控）转移。 谁掌握了跨模型编排，谁就不再被任何一家 provider 绑架。

相关阅读：harness-engineering | agent-architecture | model-routing-fallback

核心结论

Advisor 是 Claude Code 在 agent 编排层实现的只读审查能力。它让 executor 在复杂代码任务中获得一个旁路 reviewer，用于判断生产修复面、验证路径和停止条件。

Advisor 不直接改代码，也不替代 executor。它更适合在高风险、长链路、弱模型执行或验证路径不清楚的场景中触发。当前数据支持”局部正向、风险触发”，不支持默认全量开启。

设计思路

Anthropic 的 advisor strategy 更接近 LLM/API 层的原生能力：模型调用协议里支持 advisor 作为旁路角色介入，executor 可以在执行时获得模型内置的审查建议。这个方案的好处是集成深，触发、上下文和 advice 都更贴近模型自身能力。

但这条路径没有办法直接通用于当前评测里的多模型组合。原因很直接：原生 advisor 依赖 Anthropic 侧的模型能力和接口设计，不能自然复用到 DeepSeek、GPT、LongCat2、Haiku 等 executor，也不能假设所有 provider 都支持同一种 advisor 协议。

官方方案的触发机制

Anthropic 的 advisor 自带内置 system prompt，倾向于让 executor 在复杂任务开始阶段或遇到困难时调用。具体内部描述没有完整公开，但从官方文档和 developer guide 可以还原几个关键点。

system-prompt steering 是官方方案的核心控制手段。Anthropic 建议在 coding 场景中明确告诉 executor：

• 做少量探索读取后、第一次实质工作前调用 advisor；
• 遇到反复错误、不收敛或准备换方案时调用；
• 长任务在确定方案前调用一次；
• 困难任务完成修改和测试后再做一次最终咨询。

官方明确指出：如果没有 system-prompt steering，coding executor 往往会少调用 advisor。模型倾向于自己解决问题，不会主动请求旁路审查。这意味着 advisor 的收益高度依赖 prompt 工程，而不是模型自身会触发。

可选的程序控制方面，如果 executor 自主判断不稳定，可以在应用层增加：

• 第一轮没调用 advisor 时，第二轮插入 reminder 提醒 executor；
• 使用 tool_choice 强制本次调用 advisor；
• 设置 max_uses 限制单次请求内的调用次数，防止过度调用。

这套机制的问题是：它绑定 Anthropic 的 tool 协议和 API 参数（tool_choice、max_uses），不能直接复用到其他 provider。而且 reminder 注入、强制调用这类控制都是 API 层行为，跨 provider 时需要各自重新实现。

所以这里选择从 agent 编排层实现 advisor：把 advisor 设计成一个外部只读审查工具，由 Claude Code 的执行流程在关键节点调用。这样 executor 仍然走原来的代码读取、编辑和验证链路，advisor 只拿到必要上下文，返回短建议。

这个选择背后有几个判断：

• 先保证通用性：advisor 不绑定单一 LLM 原生能力，而是可以挂到不同 executor / advisor 组合上；
• 先保证权限边界：advisor 只读，不拿文件编辑权，避免”审查者”变成第二个 executor；
• 先保证触发质量：advisor 不做每题强制调用，只在生产链路不清、修复面不稳、验证路径不明确时介入；
• 先保证结果可归因：advisor-mode 里如果没有真实 advisor 调用，只能算 no-call control，不能算 advisor 收益。

实验设计也围绕这个思路展开。我们不是只看 advisor-mode 是否跑得更快，而是拆开看三件事：advisor 是否真的被调用、调用后是否改变了修复面或验证判断、token/cost 是否有完整记录。这样能避免把 executor 自己跑出来的结果误写成 advisor 的效果。

实现流程

整体流程如下：

flowchart TD
  A["用户任务"] --> B["Executor 读取代码、定位问题、制定修改方案"]
  B --> C{"是否出现高风险判断点"}
  C -- "否" --> F["Executor 独立修改与验证"]
  C -- "是" --> D["Advisor 只读分析上下文"]
  D --> E["返回短建议：生产修复面 / 验证路径 / 停止条件"]
  E --> F
  F --> G["运行测试、检查 patch 与生产修复面"]
  G --> H{"验证是否闭合"}
  H -- "否" --> B
  H -- "是" --> I["交付结果，并记录 advisor 调用与用量数据"]

1. 任务进入执行链路

用户请求进入 Claude Code 后，由 executor 承担完整执行工作。executor 会按原有流程读取仓库上下文、定位相关文件、制定修改方案并执行验证。

2. 在高风险判断点触发 Advisor

Advisor 不是每个任务都强制调用，而是在执行过程中遇到高风险判断点时触发。典型触发点包括：

• 生产代码入口不明确；
• 多个文件都可能是修复面；
• 修改可能影响跨模块调用；
• executor 对根因判断不稳定；
• 验证路径不清楚；
• 已有尝试没有收敛，需要外部审查视角。

3. Advisor 只读分析上下文

Advisor 只能读取任务描述、相关代码片段、执行进展和必要的验证信息。它不具备编辑权限，也不会直接运行破坏性操作。

只读约束让 advisor 的职责保持清晰：它提供判断，不接管执行。

4. Advisor 返回短建议

Advisor 的输出被限制为短格式，重点回答 executor 当下最需要的判断：

• 应优先查看或修改哪些生产文件；
• 当前根因判断是否合理；
• 哪些修改方向可能偏离任务；
• 应使用什么验证路径；
• 什么情况下应该停止继续扩散修改。

5. Executor 参考建议继续执行

Executor 会参考 advisor 的建议继续推进任务。如果源码、测试或实际运行结果与 advice 不一致，executor 可以以真实证据为准调整方案。

最终交付仍由 executor 完成，包括代码修改、验证命令、结果总结和风险说明。

6. 记录调用过程用于迭代

系统会记录 advisor 是否被触发、触发时机、建议内容摘要和执行结果。这些记录用于后续评测和策略迭代，不作为用户交互中的额外负担。

功能介绍

只读 Sideband Reviewer

Advisor 以旁路 reviewer 的方式接入主执行链路。它不会改变 executor 的权限模型，也不会绕过现有文件编辑、命令执行和权限控制。

跨模型组合

Advisor 能力在 agent 编排层实现，不绑定单一 provider。不同 executor 可以接入同一套 advisor 流程，例如使用一个模型执行任务，另一个模型提供审查建议。

这种方式便于按场景组合能力：强 executor 可以低频触发 advisor；弱 executor 或不稳定任务可以更积极地请求 advisor 审查。

风险触发

Advisor 的主要价值不是增加一次固定问答，而是在任务可能跑偏时提供第二视角。当前设计更适合按风险触发，而不是默认全量开启。

修复面约束

Advisor 会围绕生产修复面给出建议，避免把测试、文档、fixture、snapshot、生成文件或包元数据误当成主要修复对象。

这类约束有助于减少”为了通过验证而改错地方”的情况。

验证路径建议

Advisor 可以提醒 executor 使用更合适的验证方式，例如先跑聚焦测试，再根据改动范围选择更大的检查命令。它也可以指出当前验证信息不足，避免过早交付。

停止条件提醒

当任务出现反复尝试、修改范围扩大或证据不足时，advisor 可以提醒 executor 收束范围，回到最小可验证修改。

测试数据与效果

评测主要围绕真实 SWE 代码修复任务展开，对比 solo 执行和 advisor-mode 执行。这里的 valid 表示 scorecard 判定为有效结果；advisor-call valid 表示有效结果里 advisor 确实被调用。只有真实调用过 advisor 的行，才可以用于说明 advisor 介入后的效果。

实验线索

这轮评测按”先广度、再深度”的线索推进。第一步先确认 advisor 能不能跨 executor 接入；第二步把值得继续看的 executor 拆出来做 clean pair；第三步只对有完整 usage 的行看 token/cost；最后再决定下一轮该扩谁、停谁。

DeepSeek 数据收拢

DeepSeek 相关实验可以放在一条线上看：先用 clean12 看强 executor 的自解能力，再用 Carbon 看 advisor 在高不确定任务上的价值，最后用 Axios6 与 Axios+Babel/Carbon12 cost-mode 验证完整 usage 下的成本表现和执行长尾。

DeepSeek 的结论不是”advisor 应该强制开启”，而是”强 executor 自解能力强，advisor 应该在高风险点低频介入”。Carbon、Axios6 和 12 题 cost-mode 支持继续做风险触发，不支持每题强制调用；Babel/Carbon6 也说明深跑需要降并发，否则 rate limit 和 timeout 会污染结论。分支切换后的 CONCURRENCY=1 复测确认，低并发可以消掉同题上的 rate_limit/checkout-lock/no-json 噪音。新的 Caddy/Docusaurus12 复验进一步说明：advisor 能救个别 no-patch 题，但在 DeepSeek 上总体开销明显，不能默认开启。

Haiku / LongCat 单独说明

Haiku 和 LongCat 是另一条线：重点不是证明 token 更省，而是看 advisor 能不能提高完成稳定性，尤其是在弱或慢 executor 上。

Sonnet 补充样本

综合判断

完整线索是：广度筛查证明能力可跨 executor 接入；DeepSeek / Sonnet 用于看强 executor 下 advisor 是否真的有收益；Haiku / LongCat 用于看弱或慢 executor 是否能被 rescue。

Advisor 的收益依赖触发点。强 executor 能自解的题，advisor-mode 的好结果经常来自 no-call，不能归因给 advisor。

DeepSeek 已经有最完整的数据链路：clean12 说明强 executor 自解能力，Carbon 说明高不确定任务上的 advisor 价值，Axios6/12 说明完整 usage 下的小样本成本和质量信号，同时也暴露 Babel/Carbon 长尾和限速问题。新的 Caddy/Docusaurus12 低并发复验进一步说明：advisor 能救个别 no-patch 题，但在 DeepSeek 上总体开销明显，不能默认开启。

Sonnet 现在有更清楚的 true-call 证据：Caddy3 和 Caddy/Docusaurus12 都显示 advisor 真实调用后能保持或改善生产修复面；GPT advisor 的成本/速度表现更好，但 permission-denial 回退需要继续看。

Haiku 和 LongCat2 Preview 可以单独讲，但最新 Caddy3 复验已经把口径收窄：只能讲弱/慢 executor 分层风险，不能讲稳定正向或成本优势。

LongCat-Flash-Chat 目前只能讲兼容性筛查结果，不能讲 advisor 效果。

适合的场景

复杂代码修复：当问题跨多个模块、调用链较长、生产入口不明显时，advisor 可以帮助 executor 更快判断应该看哪里、改哪里。

高风险生产链路：当修改可能影响核心流程、权限、持久化、工具执行、provider 调用或跨进程通信时，advisor 适合做额外审查。

弱模型或轻量模型执行：轻量 executor 在长任务中更容易遗漏上下文或误判修复面。Advisor 可以作为外部审查者，帮助它保持方向。

验证路径不明确：当 executor 不确定应该跑哪个测试、需要什么 smoke、是否应该继续扩大验证时，advisor 可以帮助明确下一步。

任务多次尝试仍未收敛：如果 executor 已经尝试过一个方向但没有得到可靠结果，advisor 可以审查当前思路，提示是否需要换入口、缩小范围或停止无效扩散。

不适合的场景

Advisor 不适合所有任务默认开启。以下情况通常不需要调用：

• 简单、边界明确的单文件修改；
• executor 已经能稳定自解的常规问题；
• 只需要机械替换或格式调整的任务；
• 没有代码风险、只做轻量文案调整的任务；
• 当前问题主要受外部服务、网络或权限条件限制。

这些场景里，额外 advisor 调用可能只会增加流程复杂度。

使用方式

个人使用

Advisor 不是通过评测 runner 启动，而是在 Claude Code CLI 会话里打开和使用。当前通过 bin 入口启动 CLI；仓库内入口是 ./bin/claude-haha，如果本机已经配置了 cchaha 之类的别名，也可以直接用对应别名启动。

./bin/claude-haha

会话内开关

进入 CLI 后，通过 /advisor 命令管理 advisor。

推荐的个人使用顺序是：

/advisor set aws.claude-opus-4.7
/advisor on

打开后，executor 在适合的高风险节点可以调用 advisor。CLI 底部状态会显示 advisor on 或 advisor off，方便确认当前状态。

手动触发 Advisor

如果用户明确希望先听 advisor 建议，可以直接把任务写在 /advisor 后面：

/advisor 帮我判断这个登录态 bug 应该改哪个生产文件，先不要直接动代码

也可以用显式 task 写法：

/advisor task 检查这次重构应该优先验证哪些路径

手动触发时，advisor 会收集当前仓库上下文，生成只读建议，并写入 .agent/advice/ 下的 markdown 文件。随后 executor 会先阅读这份 advice，再继续执行任务。

典型使用场景

• 不确定应该改哪个生产文件时，先用 /advisor task ... 做修复面判断；
• 代码路径很长、跨模块调用多时，打开 advisor 作为风险节点 reviewer；
• executor 多次尝试未收敛时，用 advisor 帮忙判断是否应该换入口或停止扩散；
• 简单单文件改动、格式调整、文案类任务，一般保持 advisor off。

评测脚本入口

评测不是个人使用入口。评测主入口保留为 scripts/advisor-swe-parallel-live.sh，它会按 plan 批量调用 runner，并生成统一 scorecard。

常用 dry run：

DRY_RUN=1 \
PLAN_FILE=question/eval/plans/advisor_swe_breadth10_add7_deepseek_opus_v0.json \
BENCHMARK_FILE=question/eval/benchmark/swe_multilingual_advisor_breadth10_add7_v0.json \
PLAN_ITEM_SHARDS=1 \
PLAN_ID=swe-breadth10-add7-deepseek-opus-v0 \
scripts/advisor-swe-parallel-live.sh

常用小批量正式跑：

RUN_TAG=deepseek_opus_breadth10_sample \
PLAN_FILE=question/eval/plans/advisor_swe_breadth10_add7_deepseek_opus_v0.json \
BENCHMARK_FILE=question/eval/benchmark/swe_multilingual_advisor_breadth10_add7_v0.json \
PLAN_ITEM_SHARDS=1 \
PLAN_ID=swe-breadth10-add7-deepseek-opus-v0 \
CONCURRENCY=2 \
TIMEOUT=600 \
scripts/advisor-swe-parallel-live.sh

脚本输出两类文件：

• question/eval/results/all_*.json：每个实验 shard 的原始结果；
• question/eval/results/advisor_swe_parallel_<RUN_TAG>.md/json：统一 scorecard。

Scorecard 主入口

如果已经有一批 all_*.json，可以单独跑 scorecard：

python3 -B question/eval/advisor_p0_score.py \
  --benchmark-file question/eval/benchmark/swe_multilingual_advisor_breadth10_add7_v0.json \
  --results question/eval/results/all_*.json \
  --json-out question/eval/results/advisor_swe_parallel_sample.json \
  --markdown-out question/eval/results/advisor_swe_parallel_sample.md

最终看结果时，重点看这几个字段：

• valid_rows：有效结果数；
• advisor_call_rows / advisor_calls：advisor 是否真的介入；
• median_tokens、median_cost_usd、median_wall_seconds：成本和耗时；
• surface_pass、expected_surface_hit、forbidden_surface_hit：修复面是否合理；
• usage_complete：token/cost 是否可用于对比。

评测迭代流程

Advisor 能力的评测重点不是单次结果，而是持续判断”什么时候该调用、调用后是否帮助 executor 做出更好的决策”。

1. 构造对照任务：评测会选取真实代码修复任务，保持任务输入、仓库状态和验证方式一致，对比 solo 执行与 advisor-mode 执行的差异。

2. 区分 Advisor 真实介入与未介入：Advisor-mode 并不等于 advisor 一定发挥了作用。评测会区分两类情况——advisor 被真实调用并产生可追踪建议，与 advisor-mode 开启但任务过程中没有触发 advisor。只有前一种情况才能用于分析 advisor 的实际影响。

3. 检查修复面是否正确：评测会关注修改是否落在合理的生产代码范围内，而不是只看任务是否产生了 patch。这样可以避免把错误修复面误判为有效结果。

4. 检查验证链路是否闭合：每个样本都会记录 executor 是否完成必要验证，验证是否与改动范围匹配，以及结果是否足以支撑交付。

5. 复盘触发策略：评测结束后会复盘 advisor 的触发时机——是否该触发但没有触发、是否触发过早或过晚、advice 是否聚焦生产修复、executor 是否正确吸收或拒绝 advice、触发规则是否需要调整。

6. 进入下一轮策略更新：根据复盘结果，迭代内容通常集中在三类——调整 advisor 触发条件、收紧或优化 advisor 输出格式、补充修复面/验证路径/停止条件约束。

当前推荐使用方式

现阶段建议把 advisor 作为风险触发能力使用，而不是默认全量开启。推荐策略是：

• 常规简单任务由 executor 独立完成；
• 生产链路不清楚时触发 advisor；
• 修复面存在多个候选时触发 advisor；
• 弱 executor 或长链路任务中适度提高触发概率；
• 任务多次尝试未收敛时触发 advisor 做审查。

这样的使用方式能保持 executor 的执行效率，同时在高风险节点引入额外判断。

参考

• Anthropic advisor strategy
• OpenHands critic
• Aider architect/editor

2026 年 5 月 28 日，Anthropic 给 Claude Code 加了一个叫 Dynamic Workflows 的功能（research preview）。Bun 团队用它 11 天把 75 万行 Zig 代码迁移到 Rust，99.8% 测试通过。

但最值得关注的不是”75 万行”或”11 天”这些数字。而是一个安静的架构变化：编排计划从模型的 context window 里搬了出来，变成了一段可以阅读、可以 diff、可以重跑的脚本。

一个类比

想象一个项目经理。以前他所有任务都记在脑子里：谁在做什么、哪个做完了、哪个卡住了。每一步他都亲自决策。结果就是——他脑子里的”工作记忆”塞满了调度细节，真正用来思考问题解决方案的空间反而被挤压了。

Dynamic Workflow 做的事情相当于：经理把调度逻辑写成了一份操作手册，交给一个执行系统去跑。他的脑子终于可以专注在问题上。

在 Claude Code 的语境里：

• 以前：Claude 在对话中逐 turn 决定下一步干什么，每个 subagent 的结果都回到它的 context window。context 被中间过程填满，注意力花在管理上而不是解题上。
• Dynamic Workflow：Claude 先写一段 JavaScript 脚本，脚本负责编排 subagent。脚本在后台跑，session 不被阻塞。中间结果存在脚本变量里，Claude 的 context 只接收最终答案。

四种编排模式

Claude Code 官方文档把 agent 编排分成四种模式：

前三种模式有一个共同点：计划活在模型的 context window 里。 Claude 一边推理一边决策，每个中间结果都挤进 context。这在任务简单时不是问题，但一旦规模上来——比如审计几百个文件、迁移整个代码库——context 就会被 bookkeeping 占满，模型开始管理混乱而不是解决问题。

Workflow 打破了这个限制。计划变成了代码。

什么时候用什么

一个好的判断框架：

目标清楚，步骤不多 → 直接让 Claude 做。最简单的情况，不需要任何编排。你问它答。

目标清楚但步骤多 → Subagents 或 Skills。Claude 在 context 里逐步编排，派 worker 做子任务。适合写一个功能、修一个 bug、做一次研究。规模在几个到十几个子任务。

任务能拆成并行的独立子任务 → Agent Teams。一个 lead agent 监督几个 peer session 并行跑。适合”同时研究三个方向然后汇总”。

需要大规模并行，或者需要交叉验证确保质量 → Dynamic Workflows。Claude 写脚本编排几十到几百个 agent。适合代码库迁移、全量审计、多角度研究。

关键区分点不是”任务大小”，而是计划的确定性和质量要求：

• 如果你能预先列出所有步骤 → Subagents 够用
• 如果任务需要”多角度探索 + 收敛验证”才敢信 → Dynamic Workflow
• 如果不确定会找到什么、需要根据中间结果动态分支 → Dynamic Workflow

Dynamic Workflow 的杀手锏：质量模式

并行只是表面优势。更深层的是：因为计划是代码，它可以强制执行质量模式。

Anthropic 的描述很精确：“agents 从不同角度解决问题，其他 agents 尝试反驳已有发现，run 持续迭代直到答案收敛。”

内置的 /deep-research 就是这个模式的实现：

多个 agent 从不同角度搜索
    ↓
fetch 并交叉检查来源
    ↓
对每个声明投票
    ↓
过滤掉没通过交叉验证的声明
    ↓
输出带引用的报告

这不是简单的”人多力量大”。这是一个写在代码里的认知流程：探索 → 质疑 → 收敛。每一步都可审计。

传统 agent 做不到这一点，因为所有中间判断都在 Claude 的 context 里，Claude 既当运动员又当裁判。Workflow 把这些角色拆开，分配给不同的 agent，由脚本强制执行流程。

限制

Dynamic Workflow 不是万能的。几个硬约束：

运行中不能接收用户输入。 脚本一旦启动，只有 agent 的权限提示能暂停它。如果需要阶段之间的人工 sign-off，得把每个阶段拆成单独的 workflow 跑。

workflow 本身不能直接读写文件系统或跑 shell。 它只负责协调 agent。所有实际操作由 agent 执行，脚本做的是调度。

并发上限 16 个 agent。 单次 run 总量上限 1000 个。超过这个规模需要拆分。

成本可能很高。 数百个 agent 跑几十轮，token 消耗是传统 agent 的几十倍。Bun 迁移 75 万行的成本没有公开，但不会便宜。

与 Advisor Strategy 的关系

Advisor Strategy 和 Dynamic Workflow 解决的是不同层面的问题：

• Advisor 是推理层的模型协作：executor 做事，advisor 在决策点介入。关心的是单个 agent 内部的质量提升和成本控制。
• Dynamic Workflow 是编排层的架构选择：计划外化为脚本，多 agent 并行 + 交叉验证。关心的是任务级别的规模化和质量保证。

两者可以组合：workflow 里的每个 subagent 都可以用 advisor pattern，在大规模并行的同时控制单个 agent 的成本。

更大的趋势

Dynamic Workflow 代表的方向不只是”更多并行”。它是一个更深的转变：AI agent 的核心逻辑正在从”对话中的即兴发挥”变成”可工程化的流程代码”。

以前你跟 Claude 说”帮我审计所有 API 端点”，它在 context 里逐步做，做完了就完了。下次做同样的事，又是从零开始。

现在 Claude 会写一个脚本。这个脚本可以保存（/workflows → s），可以 diff 看看它打算怎么做，可以重跑，可以分享给团队，可以基于它迭代改进。

编排逻辑从消耗品变成了资产。这可能比并行本身更重要。

相关阅读：Advisor-Strategy-小模型干活大模型把关 | harness-engineering | agent-architecture