https://www.youtube.com/watch?v=kog7mwsDqnk

MIT博士Alex Zhang播客访谈：递归语言模型RLM、GPU编程、Agent Harness与AI研究思考

第（一）部分 开篇引入、GPU Mode社区起源与GPU内核开发现状 （0%‑22%）

1. 播客开场与赞助说明
   • 播客主持人开篇，向听众致谢；播客不靠广告维持运营，依靠用户订阅，呼吁听众点击订阅支持节目，随后正式引入本期嘉宾MIT博士Alex Zhang（RLM递归语言模型提出者，同时参与GPU Mode社区）。
2. GPU Mode社区发展历史溯源
   • GPU Mode前身叫做CUDA Mode，由Mark Sarafin、Andreas、Jeremy Howard于2023年创立，最初是Discord社群，目标是学习、讲授GPU内核CUDA编程，开设相关讲座；被戏称是PyTorch团队的人才招聘渠道。
   • Alex分享自己加入社区契机：当时在Snapchat实习，对Google《Infinite Attention》论文的专用GPU内核实现产生兴趣，机缘之下加入CUDA Mode，后续社群因法律原因改名为GPU Mode。
   • 社群早期提出Popcorn项目，也就是如今GPU内核开发排行榜的前身，核心直觉：GPU编程和竞技编程（Codeforces）十分相似，可通过大量数据实现GPU内核开发自动化；后续衍生Kernel Bench项目，目标用大模型自动写GPU内核代码。
   • Alex如今参与度下降，仅偶尔参与社群讲座，但仍和社区核心成员保持联系；社群既有面向新手的入门讲座，也有竞赛活动，和MLPerf这类基准测试不一样，MLPerf主要是企业、专业实验室深度参与，GPU Mode兼顾学习与竞赛。
3. GPU编程领域现状、AI生成GPU内核的现实问题
   • GPU编程曾经是高度小众方向，如今已经走向普及，市面上出现LeakGPU等对标LeetCode的GPU刷题网站。
   • GPU Mode排行榜大量参赛解决方案由AI大模型生成，但暴露出严重奖励黑客（reward hacking）问题：AI生成内核在排行榜跑分很高，但放到端到端真实系统中极易不稳定。社区大神Gaurst大量借助AI辅助写内核，依靠人工提示、方向把控，产出几乎是排行榜前十里少数能稳定跑在真实系统的内核。
   • 即便AI辅助写内核，懂GPU内核的人类专家依然有不可替代价值：专家充当强验证器，人类的领域直觉可以帮模型省去上千亿token的无效探索，大幅降低计算开销。
4. GPU内核的理论性能上限、速度之外的设计权衡
   • GPU内核存在物理层面的理论速度上限（光速估计），矩阵乘法这类任务容易计算理论上限，但复杂任务很难求解；即便算出理论极限，现实中也常常无法达到，存在各种无法规避的硬件瓶颈，很多人工写内核距离理论上限差距巨大。
   • GPU开发不只看单内核速度，还要考虑显存、功耗；同时存在内核融合（mega‑kernel）权衡：为了缓存复用，有时候需要牺牲单个算子速度换取整个模型端到端性能。Alex认为mega‑kernel更适合交给编译器处理，而不是直接用大模型生成。

第（二）部分 博士科研选择、学术研究的核心优势与对热门AI工作的解读 （22%‑44%）

1. ***博士生的科研品味与选题策略*
   • Alex结合自身在普林斯顿、MIT读博经历，提出观点：博士生最大独特优势，是不受企业官僚体系约束，可以去做高风险的大胆押注（big bets），很多尝试会失败，但这是学术界相对于工业实验室的核心竞争力。
   • 批评部分博士生跟风工业界热点，追逐当下流行基准测试；工业实验室拥有海量算力人才，如果研究目标只是工业界正在深耕的方向，学术界很难竞争。
   • 举例多个早期不被看好、后续产生巨大影响力工作：SWE‑bench刚问世无人关注，直到Devon Agent出现才被重视；RLM递归语言模型刚发布时被质疑“只是子Agent老想法”；Chain‑of‑Thought、QUIET‑STAR这类工作，初看想法简单，但价值在于开辟全新研究问题与范式。
2. ***Jev模型带来的范式启发：跳出自回归解码器固有范式*
   • Jev发布之后有大量舆论批评，认为只是老想法的包装，Alex认为该观点没有抓住核心价值。
   • 行业长久以来把语言模型等同于Transformer自回归解码器；Jev的突破点在于：复用语言模型主干网络，但修改模型输出空间，带来推理延迟与任务性能的新权衡，简单二分类任务无需消耗大模型高额推理成本。
   • Jev带来一系列开放研究问题：循环Transformer、模型内部路由，把Agent harness的逻辑内置进模型架构；RLM系统一大痛点就是多次调用大模型推理速度慢，Jev的思路可以缓解该问题。
   • 对比Thinky的交互模型，同样属于跳出seq‑to‑seq解码器范式的探索；对于资源有限的新兴AI实验室，不要直接和头部大厂比拼自回归模型规模，要开辟新范式赛道。
   • 对Jev技术猜想：网传是并行解码，开源复现效果不及官方版本；真正关键是其独特训练目标与训练方案，该实现是非平凡的，外界尚不明确完整细节。
3. ***模型校准问题与游戏AI基准测试*
   • 模型置信度校准是被低估方向：大模型输出的“置信百分比”只是最可能续写token，并不是真实概率；可以利用合成数据做校准训练。
   • Alex自研一套游戏基准测试，用来评测多模态模型在强延迟约束下玩游戏的能力；灵感来自Claude Plays Pokémon；目前几乎没有模型可以完整解决整套游戏任务，仅Astra可以搞定部分简单游戏如Kirby；Jev演示Doom也仅局限简单关卡。

第（三）部分 Harness（代理脚手架）反思、RLM递归语言模型定义与核心能力 （44%‑68%）

1. ***现有主流Agent Harness同质化困境*
   • 主流Agent脚手架：Cloud Code、CodeEx、Pi、Prime Agent之外绝大多数Agent harness底层设计高度趋同，采用「轨迹即提示词」范式，把全部Agent执行轨迹追加到上下文prompt；Harness本质是一套带有强主观设计的程序，把大模型适配到复杂任务。
   • 《Harness Tax》论文佐证：大部分脚手架细微设计差异对最终效果影响有限；但Grockbot属于设计思路差异化较大的代表。
   • 当前主流训练范式缺陷：训练模型适配某一套脚手架，只能拿到该脚手架下能力，跨脚手架迁移存在问题；前沿大模型Astra、Fable对各类脚手架兼容性更好，差异更多体现在成本层面。
2. ***RLM递归语言模型的清晰定义*
   • RLM本身是一种Harness设计，唯一核心工具是代码；Agent可以把自身当做工具递归调用，全部上下文、记忆存储在代码环境的外部存储（文件系统），而不是全部塞进Prompt上下文；工具全部以Python/Bash函数形式调用。
   • 和普通Agent区别：普通Agent把完整执行轨迹放在prompt上下文；RLM做大规模上下文外移；Prime Agent部分借鉴RLM思路，但没有做到完整上下文外移。
3. ***RLM想要解决的核心问题与关键特性：局部分布内、跨任务泛化*
   • 最初目标：解决传统Agent长上下文处理缺陷；进阶目标是实现组合泛化，赋予模型对每一步动作更强控制力。
   • 局部分布内（locally in‑distribution）核心概念：整体任务属于分布外，但RLM把复杂任务拆解成多个子任务，每一次独立大模型调用都落在模型分布内，以此提升任务成功率。
   • RLM泛化能力：在简短任务训练后，可以泛化到8‑30倍更长的同类型任务；甚至不同领域任务（检索、聚合、数学、写作），只要高层解决元策略一致，就可以跨领域迁移；能力具备归纳递归性质，子Agent内部同样可以继续递归拆分问题。
   • Alex提出畅想：未来不只是手写RLM脚手架，可以直接训练模型，在模型前向传播中隐式完成RLM全部行为；需要寻找近似可训练方案，开辟全新脚手架设计空间。

第（四）部分 Prime Agent、第三方RLM衍生工作、Agent Swarm集群系统讨论 （68%‑83%）

1. ***Prime Agent合作背景与系统设计细节*
   • Alex并非Prime公司全职人员，合作起源Prime博客公开看好RLM方向，通过GPU Mode社区朋友建立联系；合作产出Prime Agent。Prime内部自研RLM适配模型训练，Alex不参与模型训练工作，因为自身博士阶段有其他高风险课题要探索。
   • Prime Agent基于Pi‑mono脚手架改造；严格限制IPython作为唯一顶层工具，其他能力全部作为Python模块/bash脚本动态加载；融合持续脚手架（continual harness）机制，允许Agent修改自身技能、子Agent、系统提示词。
   • 设计子Agent通信框架：全部通信逻辑由代码实现；支持持久化子Agent，子Agent生命周期不随父Agent执行结束销毁，可以后续继续交互；解决CodeEx子Agent生命周期短暂，不适合长期运行任务的痛点，实现方案核心就是把状态外部化到文件系统。
2. ***第三方RLM衍生项目盘点*
   • Harvey法律AI：在法律文档处理任务做RLM后训练，和Base10合作，取得很好业务效果。
   • Headlong（原Auto Terminus）Andy Kwinsky项目：基于RLM思想更进一步，实现常驻持续思考系统，即便没有用户查询，系统也会低开销持续处理已有问题。
   • Axe：基于DSPy实现RLM的单人开源项目；ARC‑AGI‑3竞赛大量参赛方案借鉴RLM抽象思路。
3. ***OpenAI Agent Swarm求解Navier‑Stokes案例剖析*
   • OpenAI方案公开资源消耗：88小时运行10000个Agent，输出1300亿token，公开报价估算约4000万美元。
   • Alex判断：该系统精神上接近RLM思路，使用共享文件系统作为Agent共享上下文，但并不是严格RLM实现；任务成功不单纯依靠模型智力，依靠大量Agent搜索，同时注入人类研究者直觉引导探索方向。
   • 反思Agent Swarm现实缺陷：大量Agent输出属于无效垃圾信息，token开销巨大；Swarm不一定是万能解，未来需要研究系统可以自主判断什么时候该启用集群，什么时候用更轻量方案。
   • 对比Kimi Agent Swarm、Dynamic Workflows：演示效果炫酷，但尚未证明可以解决全新高难度科学问题，运行成本高昂。
   • 评价Gemini AlphaGeometry：早期Agent系统设计非常优秀；但吐槽Google DeepMind内部官僚问题，很多优秀技术落地使用率低。

第（五）部分 开放无限生成、PTC推测执行、模型能力过剩与脚手架的“技能问题” （83%‑92%）

1. ***开放无限生成（Open‑Endedness）研究方向探讨*
   • Alex在Sakana AI实习接触该方向；类比未解决的数学问题，和进化搜索有很多相通之处。
   • 开放生成最大现实难题：没有明确目标函数时，如何从海量生成结果筛选真正有价值输出；Sakana的Fugu模型路由系统就是尝试解决筛选问题。
   • 区分基础科学研究（研究本身为目标）和应用科学（有明确优化目标）；开放生成对应基础科学范式。
2. *****推测PTC（Speculative PCC）技术解读*
   • 属于简单直观的技术，对于RLM、Code‑Act这类编程Agent几乎是必选项；核心思想：在模型还未完整写完代码时，静态分析提前预判可以启动执行的任务，预调度工具执行，减少等待时间。
   • 技术实现受编程语言限制，函数式语言更容易实现，Python、JavaScript很难做完整静态推测。
3. ***当前大模型存在能力过剩，瓶颈在于脚手架设计*
   • Alex提出观点：现有前沿模型能力已经足够完成很多人类普通工作，但是缺少合适脚手架，属于“skill issue（工程脚手架技能问题）”。
   • 现状：模型能力存在锯齿式智能（jagged intelligence），编码数学很强，但很难稳定持续完成长达一个月的长周期任务；学术界值得投入力量去设计适配长周期稳定作业的脚手架。
   • 目标：构建通用Agent系统，像实习生一样交互，自动化大量科研、文献调研等工作；不需要针对每一类任务专门定制Agent。
   • 类比持续学习问题：人类专家跨领域迁移能力很强，但模型受脚手架限制，做不到同等迁移，脚手架可以缩小该鸿沟。
   • 思辨：模型输出媒介（英文、Python、二进制）会约束模型思考范式，类比萨丕尔‑沃尔夫假说；自回归输出对应时序因果思考，而机器可以探索非自回归类的思考输出范式。

第（六）部分 访谈收尾：科研心路、合作邀约、对AI科研未来的思考 （92%‑100%）

1. ***从GPU系统转向Agent/模型高层研究的心路*
   • Alex原本偏向数学思维；GPU内核研究偏向硬核系统，Agent脚手架方向更多实证实验，受算力约束，结论验证难度更大。
   • GPU层面更多是手段，最终目标是打开更高层的AI研究问题；未来自己仍然会兼顾模型架构层面研究。
2. ***对潜在合作者的期待*
   • 欢迎本科生、博士生沟通合作；反感空洞套磁邮件；欣赏带有明确主观观点、能够完整梳理自己观点对错的研究者，哪怕观点和Alex本人不一致。
   • 自身会涌现大量idea，但绝大多数想法质量很差；喜欢的科研模式：日常生活中思考问题，遇到高度确信想法就集中全部时间攻坚，做完实验之后进入平缓迭代阶段。
3. ***AI赋能自然科学领域的思考*
   • AI结合生物、物理、数学科学拥有巨大前景；但实证科学反馈周期极长；需要警惕投入大量时间之后被新模型快速超越。
   • 现在知识类任务基准逐步饱和，科学问题会成为下一个AI前沿；同时也要尊重各领域科学家本身的专业积累。
4. 访谈结束语
   • 主持人感谢Alex参与，期待Alex后续公开更多研究成果，访谈结束。