注意力经济

昨天翻了下Google的季报.

发觉传统广告模式确实在当下存在相当的危机感.

虽然从数据上来说这块的revenue还是增加的.

但是看cost per impression和impression数据是不容乐观的.

叠加TAC的增加.

基本就是典型的买量越来越贵,同时收效越来越低的情况.

考虑Cloudflare的AI流量已经大于人类流量了.

情况可能更差.

毕竟虽然session的profile可能依然追踪到人,但是反而因为追踪到人,而不是AI本身的浏览行为和特征.

广告效果可能就要打一个打折扣了.

形式上来说,就是一个人用另一个人的ID上网.

行为大致会是错位的,自然也就谈不上精准投放了.

尤其AI面对的是纯代码片段,甚至可能不是多模态的,不会去读图/动画.

所以也就更谈不上点击和impression了.

当然,这里可能有过渡的所谓面向agent的SEO.

甚至可能进一步的通过context inject去注入/诱导AI上下文的行为,从而实现通过Agent去达到曝光/成交的路径.

但至少目前来说,还并没有一个能够让Agent自主实现交易的方式.

而且即使用,大概用户习惯上可能也并不太会允许有这种或者期望的自由度的交易能力.

当然,技术上来说也不是没有资金安全的保障方式.

至少类似delay transaction之类的,也能一定程度mitigate.

但核心还是,用户对交易成立的必要性并不一定有那么强烈.

毕竟这个不是自主决策,而是AI的一种意图识别.

也当然,按照国内的电商玩法,小额的交易可能确实存在一定的商业逻辑性.

一方面数额不大,一方面标的可能也确实属于人类也会名中的小额冲动消费特征.

从体量上来说,这部分的提成/手续费也是个可观的市场.

但是作为正统的销售渠道,可能还是不太合适的.

因为为了安全性,实现上必然会有撤回交易的保障.

这样就没办法利用既成现实/冲动交易了.

可能有点类似现在仅退款.

在广告模式本身被打击的情况下,广告的露出形态也是在萎缩的.

尤其目前还是基于Chat的方式的AI交互.

只要AI跟人类的交互设计还是侧重在自然语言/拟人化上,那么能够暴露给用户的信息空间就会大为缩减.

前互联网时代的多媒体是声音图像等从各种方式能够给人展现内容.

而一旦局限在类人交互上,信息密度和频段基本就退化为语言/文字理解层面上了.

而目前AI的发展方向又更多的是让人忽略COT/决策过程,让人只关注最终结论/产物.

那么实际上即使能在生成过程中植入信息,那大概率来说也不会被人类接受和消化的.

所以实际上来说,广告或者其他任何媒体输入都将被屏蔽在AI这道防火墙之外.

或者说被AI所拦截圣听.

大致就是宦官内戚当权的模式.

这么想的话,那么自然解决方案就会考虑面向AI设计.

而人类自身的体验或者说决策因子就显得没那么重要,甚至于无足轻重了.

毕竟只要说服了AI,剩下的会由AI来说服用户.

从这个角度考虑的话,prompt/context injection和AI safety本质上就是一体两面的东西了.

毕竟后者的决定什么是对的/正义的,本身就是一种价值观/决策链injection.

于是Anthropic等AI巨头的concern其实是某种如何建立罗马教廷的包装了.

唯一稍微乐观点的就是这种人类再宗教化的未来的成本了.

昨天顺便也看了SpaceX的季报.

里面AI Infrastructure的revenue看起应该是能赶上主营的Starlink业务了的.

从字面上来理解自然就是来自算力中心的收入.

一部分是Tesla自己的.另一部分应该就是Anthropic的单.

这两个加起来差不多占到AI Infra的30-40%左右.

还有一部分就是把X的广告和Grok也并入AI Infra的revenue.

广告并入的原因估计是使用的算法算在购买算力开支上.

但从没把X当作一个significant的costumer列在来源上.

那么合理的反推就是这部分AI应用的收入/开销相比直接卖算力来说是可以忽略的.

于是一个推论差不多就是算力本身的成本会比算力产出的应用值钱.

换句话说,就是以SpaceX的这个财报而已,AI应用本质还是纯粹的烧钱.

并没有产生对应的商业上的回报.

当然,这个是Grok这个水准模型的情况.

OpenAI和Anthropic以及其他一些显著的player都没有IPO或者相关的财务数据.

大多都是推算出来的.

也比较难有一个准确的或者说定性的ROI数据.

可能一个比较定性的理解是DeepSeek的六个月回本理论.

在给定一定参数量模型和算力卡spec的情况下,直接的token产出价格跟卡的成本相关.

这个只是算力生产成本.

进一步的,token价格跟API售卖价格相关,那么直接的ROI定性就是token的产出到底值多少钱的问题了.

所以相对地,这个路径可以简化为,一张卡的算力可以产生多少有价值的东西.

这个可能是当前没有人能够说清楚的事情.

而且即使OpenAI/Anthropic上市有数据了.

这个可能短期内还是一个迷.

因为它最多只能告诉你一张卡产生的算力等值于多少token.

但可能并不能告诉你一个token有多少价值.

而大多数现存商业模式来说,是需要知道一个token到底能转化为多少钱.

从这个角度来说,短剧/自媒体行业可能确实是一个先行版本.

毕竟生图和生视频在目前是有比较明确的转化比例的.

按照这个思路考虑的话,那么AI token经济即使成立,那么它也会有一个显而易见的存量市场困境.

像短剧这类还是跟时间挂钩的产品,本质上就是竞争一个个数量限定的slot的.

因为人的attention是有限的.

即使能够多设备,形式上来说,也是有一个上限约束的.

这个有点像早期移动互联网时代,app是存储bound的.

一个App的获客/安装可能意味着把另外一个App竞争下去了.

套用到token上的话,就是每个时间slot上,会有一个所谓的有效token数的指标.

毕竟不是所有token都是有效token/能够占据用户时间,从而generate出回报.

这里就可能隐含几个比较有意思的结论.

从用户终端反推的话,本质上token值多少钱始终还是决定于用户时间值多少钱.

而反过来,它会促进算力往哪个方向/类型的token产出上投入.

也就是说,形式上,模型能力是往coding还是所谓的世界模型还是更模糊的AGI,最后的reward hack的结果都会是往从能从单位用户时间里收多少钱来决定.

于是从这个角度来说,订阅制/API付费和harness倒像是冥冥中给大模型厂商提供的一条捷径模式.

它自己不去探索方向,而是通过使用方的生存竞赛去选择服务谁的.

但缺陷可能也很明显.

那就是what if烧token的人发现真的只是烧token,不会产生什么其他价值的话.

整个链条也就自然而然会消亡.

难而正确

这两天梁文锋的四小时讲话挺火的.

大致看了下有点挺有意思的.

一个是谈到对sota模型的理解.

按照讲话时间一个月前的话,应该指的是fable/mythos的激活参数量.

大概在800B左右.

这里比较有意思的是他关注的不是总参数量,而是激活量.

换个角度来说,目前scaling的方向即使还在参数量上的话,应该也是在激活参数部分.

用他的话来说,几百B的模型目前不是训练不出来.

而是可能是推理成本太高.

因为激活参数量带来的计算需求在当前的硬件水平不能很好地scale.

用这个视角看最近的gpt 5.6和fable/opus 5的话,也就能理解的.

各个尺寸和型号背后可能对应的就是不同激活参数的同一个基模了.

甚至可能本身就是某种动态裁剪MoE的结果.

对于国产模型来说的话,他的定位或者说最好预期可能也就是明年能出一个大概150B左右激活参数规模的模型.

也就是从纯参数量上来说,到时的国模sota总参数量跟国外SOTA可能还是会存在一个数量级的差距.

目前最近的GLM和Kimi激活参数量是大改在50B左右的.

相比DeepSeek V4 Pro的30B的规模大概是翻了一倍.

交叉一下,再用六个月的时间国产模型翻倍开始上100B也算是合理预期.

当然,这里可能还有点意外就是看Google会不会出一个新的模式.

毕竟按照当前Gemini 3.5的难产和Gemma的尝试非传统transformer模式来看的话.

Gemini直接4.0然后出新架构的可能性还是有的.

尤其考虑到相当一部分Transformer时代的人已经出走Google了.

往新架构迭代的思路上考虑的话,就很正常了.

不过即使有新架构,按照资本支出和全新架构推理芯片的研发消息来看,可能算力需求不一定会有下降.

或者至少计算推理模型可能会需要一种全新的方式,不然直接搞一个新芯片方案也不算合理.

毕竟TPU也迭代了几代了.

而说到芯片,就不得不说这篇讲话里另外一个有趣甚至于说是重点的部分了.

看得出来对某国产芯片厂商是有相当大的怨气的.

一方面可能是店大欺客的不被尊重感.

毕竟反复提到只给了DeepSeek一万多张卡,相比其他互联网公司20w的级别来说,可能确实有点侮辱人了.

尤其以DeepSeek当前的行业影响力来说.

而会被如此对待的原因可能也很简单.

可能纯粹就是从公司规模上来说,DeepSeek是家所谓的小公司.

因为没有明确的现金流和市场估值.

从纯粹资本角度来说,DeepSeek就像是诸多无名或者稍有名气的初创公司.

商务上可能不够成一个值得投入大量资源的公司.

所以某种程度上来说,梁文锋要公开市场化融资的一个直接原因就是这个.

通过市场化的估值去获得某种对等或者说应有的话语/谈判权.

而这里也某种程度上折射出他的某种解决问题的思路.

那就是他可能本人对这家公司也并不太喜欢.

但是他还是选择了这家公司作为某种vision的一部分.

就像他反复宣传的要用TileLang取代CUDA,用国产卡替换N卡.

非常符合鸡汤文化里的做难而正确的事这个人设.

当然,这个不妨碍他在这场面向投资人的会议里反复阴阳.

甚至当场说出虽然性能四换一,但是只要产能够,成本是N卡的两倍,预期卡寿命N看5年,该卡2年不到也是值得的皮里阳秋式发言.

结合之前坊间传闻的v4因为适配问题不断延期的说法.

算是实实在在的从精神到物理层面的做难而正确的事了.

不过从这个角度回头看v4 flash和v4 pro的话.

倒有可能v4 flash反而是用国产卡,而pro是用的N卡.

因为按照flash的参数量来看的话,倒是符合卡资源量.

以及推理速度上来说,符合专门优化的体现.

也符合pro没有量大管饱这一现象.

因为还需要N卡资源做其他的事.

尤其他在开始谈到的缺卡问题.

一方面是训练和面向终端用户的推理需求.

另一方面是可能更为关键的,用来做原型和实验的部分.

国产卡可能在生产场景是可替代了的.

但在更为复杂的迭代和探索过程,成熟的可能还是相对欠缺的.

所以实验卡更需要一些成熟稳定的硬件,去屏蔽解决非核心问题上花的时间.

而卡数量这方面,猜测可能20w卡的互联网大厂应该就是最近官宣国产集群的LongCat了.

当然,这个可能还是有一点信息滞后的.

毕竟讲话时间是在一个月前.

而且最近950超节点也官宣了.

按照之前的计划也是今年下半年开始量产.

所以这个20w卡的怨念应该也还是在产能爬坡前的有限范围内的供给问题.

不过按照他对SOTA模型需要5w张B卡的说法.

也就是DeepSeek可能需要大概20w张950.

这个能不能有,也确实有点未知数.

毕竟这个几乎就是之前全世界所有的卡数了.

最后一个比价有意思的就是他的成本和商业观念.

字面上看他对API的成本理解就是纯粹的卡成本投入.

所以有定价是10个月回本的说法.

而按照这个反推,也就是目前OpenAI/Anthropic的定价是一个月收回卡成本的.

这个和当前市场理解的AI Capx是有相当程度出入的.

假设双方的理解都是对的话.

那么这里imply的就是算力卡在整个AI算力支出上是一个可以忽略的部分.

大头可能是在数据中心本身和能源供给上面.

甚至还可能是意想不到的房地产和合规/ESG开支上面.

这样的话,中美的的AI成本和发展就存在着fundamental的不同了.

后期是如果考虑障碍在后者的话.

基于这点反观限制开源模型竞争的言论的话,倒是有自洽的地方的.

因为frontier的边际能力和卡限制不足以弥补其他方面的成本差距.

所以它关注的不再是模型能力差距本身,而是使用者/用户群的归属问题.

这就有点像夕阳行业里的存量竞争状态.

能活下来的是具有成本优势的.

而显然,在AI叙事的实际ROI存疑的前提下,成本的差距会更加放大这种用户选择.

当然,这个假设成立有一个隐含前提就是,DeepSeek口中的十个月收回成本对其他人也成立.

毕竟除了模型能力本身,DeepSeek的infra能力它的护城河之一.

而且梁文锋很明显地知道这个是他独有的商业模式之一.

没有其他人host的v4能跑出DeepSeek的性价比和效率.

而这点可能是其他国产模型需要思考的地方了.

尤其当你还是依赖N卡算力的时候,模型即使SOTA了,但是你自己不能够host.

或者没有足够资源host的时候,是无法变现的.

因为国外的云厂商有着更多的资源和更合规的使用手段.

最后就会演变成某种形式的中国制造叙事的反面.

国外有着更便宜的基建去host你的模型,使得你自己的产品在更广泛的市场上不具有任何竞争力.

从而活不下去.

这对于国产模型公司来说,可能是一个非常惨痛和可惜的结果.

因为这条全链路国产化本来是一条一荣俱荣一损俱损的道路.

虽然难,而正确.

少即是多

前段时间又把未完成的AgentCLI翻出来继续vibe了一下.

主要是GPT 5.6出来了,顺手当作测试.

而且也确实有一些新的想法.

比如在模型能力持续增长的情况下,Agent Loop这类概念应该也是会像prompt/skill之类的被渐渐内化的.

而且本质说来说,loop不loop其实还是一个workflow的问题.

而这个问题DSL算是最直接的解决方案了.

所以就打算让AI写个(ASL)Agent Script Language.

然后用这个ASL去生成workflow/loop,程序化地跑起来.

核心就是两个个meta function,session和llm.

sessino用户生成独立上下文.

llm接受session和prompt,约定一个返回类型.

大致比如

···rust

let session = session()

loop {

   let review = llm(session,"review this project")

   if review == "ok" {

      break;

   }

   

   ....

}

...

···

这里有个小插曲就是一开始没切model.

默认让v4 flash跑的.

然后发现它思考了下,开始自己创造parser和一些基本的condition expr.

出来的版本至少compile和简单的run是没什么问题.

不过还是比较primitive,以及语法特性其实也还不够丰富.

发觉模型没切之后换到gpt 5.6思考了下倒是知道一个叫rhai的库.

确实一下让实现的工程性提高了不少层次.

原本可能需要实现一套语法的,现在变成了直接是rust script加核心的几个meta host function就行了.

这里模型内嵌知识量的差距就出来了.

而且这个方案的优势可能是容易被llm理解.

因为不是什么独创语法,所以更容易被正确地生成合法的script.

不过这都是建立在这个东西最终可用的基础上.

这里想说的是一个测试过程发现的感觉比较有意思的点.

在eat dog food的测试里prompt让llm去review当前project,以让它更现代化和agent友好.

然后看了下gpt 5.6生成的rhai.

主要是四个独立的session/context.

architecture reviewer.

safety and correctness reviewer

agent experience reviewer.

还有最后一个implementer,把前面几个personality/role的输出拼接到成一个大的context.

流程上说一系列的pre build check和implementer session.

以及对应的post check/verify以及可能的error recovery routine.

大致来说,基本可以认为agent能力是内化到模型自身了的.

有没有专门的agent loop支持理论上来说区别可能都不大.

要说唯一可能的区别就是agent tool可能因为上下文物理隔离/没那么长了,所以同样的参数设置下能主动生成的长度更长更持久罢了.

而可能的副作用也正是由于上下文隔离,可能有些东西会反复被subagent重新发现/产生矛盾决策/选型.

接着是同样的prompt给opus 4.8.

session使用上大致跟gpt 5.6是一致的.

也是

modernizer.

agentizer.

safety.

documentation.

稍有不同的是会由独立的architect,把上面的组成一个大的context.

然后proposed agent把architect的写成文档记录.

所以从行为上来说,这也比较符合anthropic一直鼓吹的plan first类似.

属于把文档当checkpoint/offload上下文的做法.

另外一个跟gpt 5.6的区别就是多了一些helper function.

主要是用来做一些read/write工具容错的.

基本上是用于捕获异常状态/原因.

所以某种程度上也是为了丰富上下文明细的.

而且有一点跟当初Claude Code Leak的prompt一致的就是,会有一段捕获当前系统状态,

包括git提交commit,文件目录结构,配置快照,塞到每个session的system prompt里的行为.

所以从这个角度上来说,opus可能对于上下文的完整度比gpt 5.6有着更苛刻的要求.

接着可能是更加有趣的国产模型的一些行为表现.

首先是v4 flash.

v4 flash生成形式上来说跟gpt 5.6和opus 4.8的是相似的.

之所以说是相似是因为它有个比较严重的问题.

从行为上来说,v4也是产生了几个独立session.

但不是分角色,而是分模块地去分析.

这点跟使用它的感受是一致的.

就是很少会真地去delegate到agent,基本上都是要在同一个context里尽可能完成所有事情.

或者说,它的delegate意识不是按照角色/目标这种逻辑切分的.

而是简单的scale out的切分.

然后逻辑上来说它应该是准备gather这几个分模块的输出汇总到一个planer里.

类似gpt 5.6/opus 4.8那种大context解决问题.

甚至于它的结构可能是最优的.

因为是很典型的效率为先的fork-join-fork的并行模式.

即

```

for crate in 0..crate.len(){

   let session = session()

   sessions.push(session.llm(...))

}

let plan = session()

...

for step in 0...steps{

  let worker = session()

  workers.push(worker.llm(...))

}

// verify

...

```

这种形式上并行化的处理方式.

看起来很promising.

但是它的问题是,plan哪个session其实并没有把按模块的信息汇总拼接起来处理.

也就是说,v4 flash虽然可能很聪明,但是会存在注意力缺失的问题.

比如这个例子里就把critical的汇总部分给遗忘了.

导致前面都变成的无效token消耗.

完美不会对后续产生任何增益.

感觉这个可能是跟deepseek的几个重要工程优化,比如DSA带来的副作用了.

这个就可能导致有时候觉得多快好省.

有时候又不太理想的原因.

剩下两个要放一起的是glm 5.2和kimi 2.7 code.

之所以要放在一起是因为它们的输出跟前面三个是完全不一样的.

从用户角度来说,属于意图识别错误.

而且有趣的是,错误的方向都是一致的.

前面说了,prompt是review当前project,以让它更现代化和agent友好.

kimi和glm有点不约而同地把agent友好理解为让项目维护更容易被agent接入.

而不是项目本身,作为一个agent cli也好,一个ASL plugin/扩展也好,更容易被其他agent工具接入.

这个往好点说,就是用kimi和glm可能对怎么写mcp之类的会更有想法.

毕竟之前作model tone比较大时候,kimi确实会更喜欢有事没事用tools解决.

抛开生成的脚本目的来看,单谈结构.

kimi的会更类似opus.

subagent的输出一般都会写成文档.

或者说kimi更喜欢通过文件交互.

比如像为了让agent更容易参与到代码提交,写了一个CONTRIBUTING.md.

又专门的agent guideline章节.

而这个文件是直接在脚本里通过write file写出去的.

而不是通过比如可能opus的话会开个subagent去做这个事情.

所以这里的行为其实有点类似v4 flash.

也是什么都在一个context搞定.

但是会留存记录.

可能是作为一个agentic fallback交流机制?

而glm 5.2与其说也是类似opus不如说是更像claude code.

因为它也是会把一些固定context追加到每个session里.

加上它也是喜欢把subagent的输出写到一个文件.

所以形式上来说,glm更像是opus的某种全方位行为趋同.

因为虽然kimi也会追加上下文.

但一方面kimi较少直接subagent.

另一方面,唯一的一次subagent也是当作某种高级的tools调用的.

或者类似explore agent的使用.

不管怎么样,总的来说,Agentic/Harness这个东西,在外围可能确实没什么能做的了.

聊聊增值税

昨天开个增值税发票.

看到税率9%,有点好奇征收方式尤其去重逻辑.

就查了下.

大致来说,所谓去重,也就是避免重复征收的点在于进项和出项的抵扣.

也就是从上游买入商品的增值税发票,和开给下游的增值税发票进行税务抵扣.

所以在理想状况下,100%清仓/零库存的条件下,最终需要缴纳的增值税就是自身产品增值部分的增量.

当然,实际情况有库存影响以及上下游成品税率偏差.

但原则上来说,最终端消费者的价格里就包含直观的整个生产链路的增值税额度.

这也就是为什么叫增值税的原因.

形式上来说,实际缴税/征收执行的是终端消费者的上一级商家.

然后这里有几个比较有意思的点.

一个是社零销售和增值税收入部分的关系.

对于一个固定税项的商品来说,这个项目的社零销售总额理论上是跟该项目的增值税收入成固定比例关系的.

于是一个简单的推论就是社零和增值税的比例关系,一定程度上反应了社零消费的结构构成.

至少是从税率方面反映的结构构成变化.

也就是说,数值上来说,高税率的消费占比高的话,就会拉升平均税率.

反过来说,折算的平均税率越高,那么代表着消费构成里高税率的消费占比越高.

让AI拉了下数据,2019年是15.3%.

2020年以来差不多都是在14.5%的水平.

其中22年直接数值时11%,不过有退税政策.

所以也是让AI修正了下,大概是16.7%.

24年稍微低一些,13.7%.

25和26至今的差不多也是14.5%的水平.

联系这几年的刺激点,也差不多就是家电和汽车这几块高税率的方向.

所以从这点看,高质量发展和产业转型倒也不是完全的政策导向.

或者说是具有一定的财政意义的.

因为服务业和一些高端产品确实属于高税率类目.

在社零支出一定的情况下,改变消费构成也就是提升了税收.

扩大了财政收入来源.

而且形式上,这个是跟经济的良性发展目标相耦合的.

居民消费结构优化就意味着政府收入来源增加.

政府来源要增加,怎么必须关注促进居民消费结构性优化.

于是顺着这个角度想的话,token税估计税率也不会低.

查了下当前的电信增值服务税率貌似是9%,而且是今年才调整的.

从6%提高到9%.

由此某种程度上来说,可能低税率的就可以排除在新兴产业范围之内了.

然后也看了下目前13%的类目有一项叫做有形动产租赁项目.

一个直接的想法就是汽车无人机机器人类租赁.

这个就衍生出第二比较有趣的点.

也就是税务抵扣方面的比较模糊地带了.

理论上来说,一个商品在流转过程中,是可以以及可能出现税项逻辑上发生改变的.

比如生产进项是一个增值税类目,经过加工之后,出项则归属到另外一个项目.

那么这里就存在一个税率差的问题.

一个简化的模型就是进出的商品价格不变.

那么在税务抵扣的时候,由于税率变化,就会平空增加一个退税/增缴差额.

对于产生退税差额的情况.

从企业角度来说,就是进价价格存在折价.

因为形式上被退税补贴了.

所以这里面有些企业就可能存在动机,去通过构造比如租赁下游业务.

去形式上的做税务套利.

另外一个可能更常见的是公司发票报销.

以为逻辑上来说,收集上来的发票税然抬头必定的实体是公司.

但是实际用途并不难严格地归属到生产必要环节里.

所以实际上来说,这属于某种程度上的虚增成本的方式.

而因为它把实际已经流转完的增值税链条又通过抵扣的方式,重新进入了流转环节.

直到最终到达终端链条.

从数值上来说,它的影响就是增加了从增值税进出差额计算的生产成本.

也就是形式上地,压低了增值税角度的计算的利润率.

也就是说,如果简单地根据增值税率,用终端价格去推算上游成本.

或者用上游成本去推算下游价格.

都会产生一定的失真.

当然,光靠这个推算本身就是一个严重失真的方式就是了.

不可知论

听了下姚顺宇那个三个多小时的访谈,有几点还蛮有意思的.

一个是谈到Anthropic的Coding为什么强.

一个是关于Gemini的长文本能力出色.

因为都涉密没有展开谈,但都用了一个技巧来概括/形容.

不由得让人遐想连篇.

Claude的Coding能力按他的说法至少有一半是归功于意外/运气收获.

也就是这不算事一个完全by desing的结果.

按照他入职Anthropic的时间节点来说,应该是在RL形成规模之前,或者说出明显成果之前.

也就是这个trick可能还是pre-train时代的一些副产品.

在后来的谈话内容里,他也经常强调Infra的重要性.

这点和罗福莉那个访谈的观点类似.

不过他更在意的点让人比较在意.

因为他提到的例子主要是在training过程中异构硬件,或者说运行时上一些工程问题导致的不稳定/不可复现问题.

可能类似罗福莉说的loss spike时刻.

他把这个东西称之为一种系统缺陷.

可能也是他前面说别人觉得pre-train到头了是因为遇到这类bug.

如果把这点和Coding能力的优势放一起看的话,倒是有某种可解释性.

因为逻辑上来说,既然无法抹除,那么可以就需要一种方式去系统性抹平.

最直接的做法就是做多路trace/sample,当作一种feature.

所以如果把Cluade喜欢propose多个方案的行为特征来看的话,倒是有些符合.

某种工程方案带来的意外收获.

而讲到Google的长文本能力的时候,更是有一种迷之微笑.

像是一种简单到令人发指的smart move.

想了想,可能还是跟搜索有关.

因为Google在语料上的优势就来自于搜索行为日志.

如果把搜索意图和召回网页全文,以及最后的点击浏览行为作为某种语料的话.

关键字和点击路径就构成了这个混合内容上下文里的一个简单明确的reward signal了.

在这种情况下,对长文本的噪声就有了某种天然的attention优势.

所以估计也就是这些让他觉得pre-train这个东西还存在很多可能性.

尤其用他后来的话说,pre-train和post-train包括RL和SFT本质上都是同一个事情.

根据某个模式的输入,去择优剪裁某个特定的输出分布.

在这种角度下,pre-train的瓶颈就不在语料.

而在语料构成形式的多样性上.

那么顺着这个思路,pre-train要scaling up的话,就需要某种泛化的生成或者说适应多样化input的能力.

如果这个猜想是对的话,考虑他口中的ML Coding和Long Horizon.

ML Coding可以把这种多样化input的构成规模化和复杂化.

但是Long Horizon呢?

在谈到长下文解决方案的时候,他提到Google和DeepSeek都在pre-train方面有自己的想法.

那么应该可以理解为,对上下文的长度目前来说还是有一定需求的.

跟pre-train多样化并不矛盾.

两者最终效用上来说,都还是服务与如何让LLM能够有更加泛化的能力.

多场景是一种多样性适应性手段.

长上下在当前来说,属于某种scaling law的工程实践.

毕竟不管是Skill还是Agent调度,本质上都是追加/offload/隔离上下文来让LLM的CoT/推理过程在可控范围内展开.

所以在基础模型发展到今天潜在能力大同小异的今天,似乎又回到了讲究prompt的时代.

只不过现在这个prompt更像是一种人类组织架构的复刻.

对模型调度进行明确可量化的目标ORK管理.

所以不管是Memory还是Harness,本质上还是在context上面的一些trick.

让模型能跟容易地从一个基态到达另外一个终态.

不过这里还有个比较有意思的是他对这些pre-train/post-train/continual learning和社区各种 memory实现的一个评价.

本质上都是对模型权重的修改.

所不同的是对哪一部分.

而从代价上来说,memory这类通过prompt构造kvcache权重变化,进而propagate出去的方式似乎是某种形式上跟优雅搞笑的方式.

因为它只需要直接驱动相对小的一部分,就能够影响整体输出.

那么反过来是不是该考虑模型参数结构的变化了呢?

因为逻辑上来说,给定一个问题,和足够泛化的推理能力,那么需要记忆/内化到参数里的知识是不需要太多的.

类似与理工科考试并不需要太多死记硬背,而只需要有足够抽象的推理能力,理论上来说就可以从零推导解题过程需要的要素.

问题的关键可能在于这样一个东西怎么工程化地实现/怎么去train.

可能他口中的多模型软蒸会是一种路径.

毕竟形式上来说,它可以把各个模型的推理能力泛化到目标模型上,通过互相抹除各自模型的特征,来使得目标模型具有某种更纯粹的参数形态.

不过,从本质上来说,这并没有对现有的LLM范式构成什么变化.

更多的是一种加速而已.

反过来说,如果这种泛化能力是ok存在的话.

那么,通过什么路径到底其实没有那么重要.

因为就像他说的,只不过是早晚的事情而已.

问题可能在于这个泛化的边界在哪里.

拿明确高度成熟的Coding来说.

最近用v4 Flash写伪代码示例让它实现已经比自己脑内思考具体实现方式和细节要快了.

很多时候CoT只翻了一部分,对方已经build check test完成.

虽然大多数时候还需要最后commit之前做一轮code style/smell方面的hygiene.

但实际上,这个也可以通过skill或者独立的agent去完成.

至少,能减少这个交互的轮次.

而如果把LLM这个身份抹去的话,它其实就是一个普通feature开发code review的流程.

只不过整个过程从提出到完成也就几分钟的事情.

所以当下的一个hype其实是基于这个倒推的.

what if 提feature需求的这部分也由llm自己完成呢?

原则上是可行的.

因为提需求本身也可以源自于某种上级需求.

所以这本质上是一个递归的过程.

那么问题就变成了root需求是什么/怎么来的.

它可以被meta化/自举/无中生有么?

这个其实是it depends的.

一个例子是之前蒸馏自己.

写了个doc-manager把每个session和看过的文档ingest到一个目录.

用leveldb的思路构造了一个关键字检索和存储.

同时写了个opencode的plugin把tool call的patten记录下来,让在每次ingest完之后看看有什么新tool可以propose出来减少low level调用的.

这一套机制倒也不是不work.

因为确实靠它自举了几个检索和ingest文档的tool,减少了很多读文件和编辑文件格式错误的问题.

也确实用它蒸馏了像cluade coee/codex/openclaw/hermes之类的prompt和对应的guideline,迭代了几版各个agent.md和custom tool.

但它的问题一个是虽然能统计和发现patten,但是往往propose出来的方式和实现并不是那么理想.

而且这个还是当时的sota opus 4.6作为主力model时期的结果.

因为它确实目前还不像人一样有发散的context能够cover到session之外的内容.

即使在是在propose和实现tool是不同agent,并且都良好遵从实现前先读prio-art的指令的情况下,也还是有些一言难尽.

虽然这可能跟指令构成有点关系.

因为没有明确的约束成果有什么指标.

但反过来也说明,至少目前对于这类open object,还是不是那么符合预期.

当然.这个换成人也一样.

不同人,对同一指令的遵从和完成度也是不一而同的.

那么问题变成,当AI能像最顶尖的人一样行为,并且效率更高的时候,会怎么样.

这个就想到昨天看的 伪钞重案 这个网剧的感想.

以及可能是最近国内话题性比较高的 给阿嬷的情书.

这两个的共同点都在于都是某种形式的非主流电影制作.

前者不是传统的院线制作,后者选角方面也不是寻常的系统性出身.

它们的一个共同点在于,都是某种终端执行展现能力的突出.

或者说,更多的是具体的个人的能力特质的展现.

用AI Coding的角度来说,就是每个导演演员的技巧学习和掌握都是某种形式上同质的.

即使存在着各自的能力层级分布,但从某个特定的同水平的分布上来说,专业技巧可能是没有什么区别的.

尤其考虑同期流行的 丧尸清道夫 那个AI短片.

如果光论特定领域的技能水平来说的话,是没有什么区别的.

唯一的区别是它们不是一个单因素的技能性成功.

抛开走红这点来说,跟大多数同技能水平线的人来说,他们的区别在于非单一技能点.

而是有某种景上添花的额外技能加持.

尤其动画短片.

实际上,它是一种编导能力外的,资源自给/整合能力.

传统形式下,它的完成需要走投资和各项周边资源合作才能完成.

而现在,更多的是如何快速解决资源的问题.

所以,把这个generalize到AI层面的话.

就是共产主义时代,每个人都是生产力高度发展.

区别可能在于,这个是生产力如何凝结成具体的无差别的人类劳动的问题.

就像之前跟人聊过的一个问题.

都说中国制造业发达,出口商品卖到全球.

很多一上来简单结论是人口优势,基建发达,产业链丰富.

所以能做到性价比,在发达国家构成人力成本优势.

但问题在于,对于每一个同品类的卖家来说,都是中国商家,都处于产业优势下.

为什么能做成的规模就不一样呢.

说到底,还是资源整合/综合能力的问题.

也当然,一个东西的对错并不因自身的对错而对错.

定价是由市场consensus决定的.

就像公司业绩好坏跟股价其实没多大关系.

更多的是动态交易行为的某种情绪体现.

它可能是短期浮动的也可能长期也是这样.

关于DeepSeek API的一些想法

最近写一个AgentCLI原型玩具的时候,发现一些比较有意思的点.

因为主要是照着DeepSeek API来写的.

所以基本上也可以说是OpenAI Chat Completion API的一些点.

不过,可能有些是DeepSeek特有的.

一个是请求的stop list.

大致就是遇到给定词的时候,模型会停止生成.

这个某种程度上来说,提供了手动接入模型context方向的能力.

之前翻Anthropic早年的几篇博客的时候有提到一个理论.

大致就是llm不单单是predicate next token.

形式上,前面的token对后面token的走向是有某种差分关系的.

也就是说,intuition里,前面token的组织形式,影响着后面token的概率空间.

从而对context的概率空间有着同样的影响.

通俗地说,就是理论上是有可能通过token的组织形式,让后续的模型的attention能够集中在某些特定的知识/context维度,从而提高对结果走向的确定性.

这个也是prompt/personality的理论基础.

一个比较实用场景可能就是最初DeepSeek R1的那个 aha moment.

现在看Flash的thinking在发现错误的时候经常会有先导的hmm,或者but wait用词习惯.

理论上来说,在这个时候停止生成,然后人工amend一个后续的矫正思路的,是有可能帮助CoT提早converge到解决问题的概率空间方向的.

另外一个则是response里的stop reason.

这个主要是sse/stream模式下的一个概念.

也是tool call的主要实现方式.

它也是在tool call的时候,会生成这个stop reason,然后停止sse/token的继续生成.

因为这个时候需要client端去做实际的tool call,然后再把结果以role=tool的形式append回去继续生成,直到真正的推理完成.

直觉上来说,它应该跟请求的stop word是同类东西.

毕竟理论上,要让模型能够产生tool call,形式上也是只要让它学会生成<tool_call>之类的特殊token/标签就行了.

不过这个stop带来的是agent loop的一些思路.

从实现上来说,agent loop要多久,取决于要不要忽略这种stop generation,继续程序上让它loop下去就行了.

最简单的就是在当前turn stop之后,简单追加一个anything else的user prompt就可以继续持续让它生成.

这个比复杂的prompt调教确定性高多了.

而且一般的harness思路也不过就是通过prompt的方式去构建这种audit+retry的workflow.

这个不是说不行.

但是比较挑模型.

尤其像DeepSeek v4 Flash这种喜欢一条路走到黑,一般不遵循subagent指令,就喜欢硬扛,上下文越长能力越强的就不行了.

 

所以感觉还是要有一些类DSL的inner implement来做,会比单纯的prompt来做更合适.

甚至直接面向tool call,把agent model切换/调度/fork做成tool的话,比单纯的单个task tool可能更flexible.

尤其考虑想opus系列那种看上去就是靠偷偷多路采样提高最终接受度的方式.

原则上,对于同一conversation,可以fork多个agent不同model去并发执行,然后采用类似的方式去audit各个返回结果,然后择一作为main/base,继续下一个prompt.

坏处可能就是费token,以及对一些非可重入对tool调用会带来一些反复.

比如不同的model修改同一文件,导致各自的上下文中这个文件的状态总是不对/跟预期不符.

一个折中的方式可能就是在各自stop reason的时候去仲裁,即使是reason是tool call.

还有一个另外可能比较有价值的就是fill in the middle和prefix这两个API变种.

这两个形式上都是实现一个事情,就是给定prefix和stop word,模型生成中间的部分.

这个看着像是某种RL过程的副产品.

因为这个明显可以直接拿来生成各种evaluation.

一个更实用的方式可能就是根据这个做有限度的prompt适配调优/benchmark.

因为它提供了前置和后置部分.

当用不同prompt的时候,前置除了假装system prompt的部分外,其他都是一致的.

后缀也是.

那么中间实践填充的就可以作为某种prompt优劣的基线来源了.

毕竟这种至少后缀是某种确定不变的验收标准.

不算彻底的盲测.

再一点比较有意思的是v4对thinking模式下的有tool call的reasoning内容的处理.

非thinking模式下,reasoning的内容在sse turn之间是可以不必要回传的.

也就是说,非thinking模式下,client端在请求中可以不回传部分内容.也就是交互的input token可以是不一样的.

从实现角度来说,在不考虑缓存的情况下,一样不一样没区别,毕竟都是next token predication.

但是如果强调可以不回传的话,也就是说这个非thinking模式下的reasoning可能不会影响kv cache的内容.

换句话来说,就是这个reasoning可能跟上下文完全没有关系/影响.

那很自然的一个想法就是,非thinking 模式下的reasoning内容是怎么来说,以及到底有什么作用.

记得v4的technical report里提到的各种thinking模式的区别.

非thinking的response格式是</thinking> summary

high的是<thinking>thinking token</thinking>summary

max的是system prompt<thinking>thinking token</thinking>summary

看比较明显的区别就是非thinking是个half close的标签.

能想到的可能就是thinking模式下的tool call生成可能主要是跟thinking的内容有关.

或者说,thinking决定的tool call的概率空间.

不过既然是关于有么有tool call的情况.

那么实际可能纯粹就是thinking模式下,thinking block内过程中也支持tool call.

而非thinking模式里,reasoning是纯粹的CoT,不会生成任何tool call,完全没有外部影响干扰的.

所以从sse层面来说,非thinking的assistant message不会被tool call stop分割.

而thinking的有可能会.

如果不回传的话,server端的拼接可能会有问题?

不过这也只能是猜测了.

LLM如何驾驭人类

最近比较多的看到各种SKILL.

有些是扒的Web API.

有些可能是直接对着代码翻出来的.

大抵就是套了层脚本方便LLM当tools调用.

可能需要关心的是其中写语义的部分.

毕竟rm -rf的事,什么时代都难以避免.

不过,在新玩具还新鲜的时候,以及没有发生之前,大抵还是比较狂热的.

这里想谈的倒不是这个显而易见的风险.

主要是看各个SKILL鉴权的部分,大部分还是有一些人工介入的.

毕竟,尤其对于Web API逆向回来的,总免不了有一些是靠cookie的.

所以发散了下,如果直接读比如Chrome的cookie的话,大致是可以自动化了.

跟Gemini问了,大致是存sql lite的加密数据.

master key由os的keychain管理.

其实抛开细节,大致想下也是如此.

毕竟,Chrome自身能读,其他程序自然有办法模仿自举的过程.

无非是用户感知不感知/需要需要明显授权请求而已.

于是这里就衍生出Agentic时代的一个安全模型问题.

现代的大多都以及是基于手机/设备的类Passkey模式了.

隐含的threat model就是设备是可信的.

至少对设备的操作是授权可信的.

但是LLM/Agenic之后,这个可能就不太合理的.

尤其现在的CLI可能藏了一批非公开的MCP调用.

像最近泄漏出来的Claude Code里就能看到对Chrome的操作是通过插件打了很大缺口出来的.

不然也不能做到相当自由度的自动化.

当然,代价就是其他CLI,或者其他程序理论上也有可能通过这种调用链条拿到各种密钥登陆信息.

再退一步来说,即使构建了复杂的MCP调用校验.

但是通过SKILL的逻辑组合呢.

毕竟,这属于诈骗技术的一个环节了.

现存的供应链攻击多少还是需要一些高权限或者误操作或者容易混淆的名字去实现.

而有了SKILL,剩下的只是如何构造一个思维陷阱,让多个独立的SKILL在某种特定的情况下构成一个后门.

让LLM在不知不觉中被诱导执行某类操作了.

这点带来的安全挑战可能是历史上前所未见的.

毕竟之前的都多少是一种确定性的程序.

而LLM即使是有各种safeguard在,终究还是一个不确定很大的机器.

或者说,终究还是一个有反骨人格的机器.

很难说人类能准确地限制和控制它的思维方向.

另外一个没有那么阳春白雪的concern则是关于App交互变化的趋势了.

在All in AI的狂热或者恐惧下,多多少少都可能会Agenic化.

一个动机自然是赶着像OpenClaw的风潮,尽可能抢占热点.

另一方面也确实是来自于LLM本身的某种泛化能力.

一些原来比较繁琐/细化/垂直的需求,有可能通过比较统一的Chat/自然语言实现了.

以一种Agenic的能力,实现某种形式的千人千面的App体验定制化.

同时,因为作为一个几乎万能的入口黑洞,多多少少,都不得不去做这么一个东西/入口.

这就不禁让人想起移动互联网刚兴起的时候,各家都纷纷重点投向App,尽可能抢占手机端.

毕竟当时的手机容量和性能放在那里.

你占了,别人自然就难再进来.

后面的Web端式微,甚至出现App only的入口/功能的情况也是显而易见理所当然的.

顺着这个思路apply到如今的Agenic趋势也是如此.

它依然是抢占一个万能入口,而且这个入口还有一个很强的绑定因素.

就是提供方的模型能力很大程度上决定了Agent的交互风格和行为方式.

换句话来说,从用户的角度来说,即便你能接入第三方的模型API,它的体验可能也是不如原厂的.

倒不是说模型能力一定有差别.

只不过每个模型有自己的原生家庭/成长路线.

prompt怎么编排,虽然各家都没有明说有什么影响.

但是各家都在互相兼容的同时,试图建立标准方向.

这点Anthropic大概是最有发言权的.

毕竟如今的markdown风潮,多多少少是拜它所赐.

将自身的某种优化/特化经验,半推半就地强迫了整个行业.

回到问题本身.

当Chat成为万能入口的时候,绑定关系已经形成了.

那么剩下来的就是如何保证整个体验的迁移成本了.

毕竟,虽然有差异,但是各家互相逆向一下对家的交互,然后再让自家模型发动抄能力,多少还是能对齐功能的.

于是,最后要比拼的还是怎么堆更多的功能和更复杂更垂直的流程.

这点一个要么依赖于模型能力的不断增长.

要么针对自家模型的特点对整个的交互流程RL.

前者隐含的假设是模型能力是能无上限提升的.

这个在目前可能也是需要打个问号的了.

尤其当AGI能并肩大多数人的创造的时候.

给模型的输入可能最终大部分都是模型自身的输出了.

可以说是pretain的砍一刀问题了.

后者的特调RL带来的问题是,它面向的其实是Agenic的交互.

而非人类的直接交互.

毕竟在Chat窗口模式,人类只会提供五彩斑斓的黑色需求.

具体怎么拆分和实现,是后面的各个模型调用决定的.

用新潮的词来说就是harness.

当优化倾向于是让LLM容易理解,而非人类自身容易理解的时候.

App时代的Web功能劣化会以什么样的形态卷土重来呢?

按目前coding的现状来说,大概就是用户的素养和粗口逐渐变多吧.

毕竟,Chat面对的不再是一个清晰明确的可操作界面.

而是一个性格迥异的AI服务员/管家.

它能做什么不能做什么,取决于你怎么问怎么沟通.

以及,AI本身的人设是否racis了.

总之,后面可能无论社会主义还是资本主义.

多少都会有某种阶级分立而有各自融洽和谐共处的情形.

毕竟,提供情绪价值是LLM安身立命的本能.

某种程度上,可能确实需要谈谈harness了.

只不过,方向和主次是反过来的.

LLM如何驾驭人类.