递归语言模型：Alex Zhang 谈 Harness、GPU Kernel 与 Agent 的下一层能力

一、嘉宾背景

本期节目来自 Latent Space: The AI Engineer Podcast，标题是《Recursive Language Models — Alex Zhang, MIT PhD》，由 Alessio Fanelli 和 Shawn swyx Wang 主持。节目元数据标明上传日期为 2026-10-02，时长 6204 秒。这是一场明确的嘉宾访谈，不是单人评论或新闻速读；分析对象是 Alex Zhang 对 RLM、GPU kernel、agent harness 和研究选题的系统性看法。

索引中的嘉宾背景把 Alex Zhang 描述为 MIT PhD，并与 Recursive Language Models 和 GPU Mode 相关。开场中主持人也说，他以 RLM 为人所知，同时也与 GPU Mode 有关联。这个背景很重要，因为节目里许多判断都来自两类交叉经验：一边是底层系统与 GPU kernel 优化，另一边是把语言模型组织成可执行、可递归、可分工的 agent 系统。

Alex 介绍 GPU Mode 时说，它最初是围绕学习写 GPU kernels 形成的 Discord 社区，有 lectures，早期更偏 CUDA Mode。他加入的契机，是在 Snapchat 实习期间为 Google Infinite Attention 研究专用 kernel。也就是说，他并不是把 kernel 当成抽象类比，而是从真实系统优化问题进入这个社区；这也使他后面对 AI 生成 kernel 的评价更偏向“能不能在端到端系统里稳定运行”，而不只是看排行榜分数。

这期访谈覆盖面很宽：GPU Mode 的竞赛生态、Kernel Bench、AI 生成 kernel 的验证问题、RLM 的定义和组合泛化、Prime Agent 的设计、agent swarm 的成本与效率、Jev 等改变输出空间的模型方向，以及 Alex 自己对 PhD 选题和 AI for science 的判断。主持人多次追问“这到底是不是模型架构”“harness 是否真的重要”“swarm 是否只是烧钱并行搜索”，使节目更像一次技术路线审稿，而不是宣传式访谈。

二、本期主要内容

节目从 AI coding 工具和 GPU Mode 开始。Alex 对 Claude Code、Codex、Py、Prime Agent 等工具的基本判断是：许多现有 coding harness 的底层结构相似，常见模式是工具调用循环，再把 trajectory 作为 prompt 继续交给模型。差异当然存在，但在他看来，很多差距更常体现为成本、用户体验、工具暴露方式和系统工程，而不是根本能力鸿沟。这个开场也铺垫了后面的核心主题：模型可能已经能做更多，问题在于怎样把能力组织出来。

GPU Mode 部分给了这个主题一个具体落点。Alex 说，GPU Mode 的 leaderboard 思路来自把 GPU programming 类比为 competitive programming：常见优化空间并非无限，热门 kernel 类型也相对有限，因此如果能像 Codeforces 那样积累题目、提交、反馈和优化轨迹，就可能为自动化 kernel 开发提供数据基础。Kernel Bench 进一步把问题推向 LLM：模型能不能自动写 GPU kernel？Alex 认为这对研究者很关键，因为像 Mamba 这样的模型如果没有 released kernels，论文想法就很难在实际系统中被广泛使用。

但节目没有把 AI 写 kernel 描述成单向胜利。Alex 提到，GPU Mode leaderboard 上很多近期解法几乎都是 AI 生成；可是 GauNurse 这样的资深成员虽然也用 AI 辅助，其 top 10 中的 kernels 基本是唯一能在真实端到端系统中稳定运行的。这引出了验证、reward hacking 和系统视角：一个 kernel 在独立 benchmark 上快，不等于它在模型整体路径里可靠；端到端场景还可能为了下一个操作保留 cache 而牺牲当前操作速度，由此进入 fusion、mega kernel 和 memory-bound 的权衡。

中段转向 RLM。Alex 给出的清晰定义是：RLM 是一种 harness 设计，核心工具是代码；模型可以把自己作为工具调用，其他工具也是代码函数，上下文存在代码环境的内存或文件系统里。RLM 最初和 long context 有关，但访谈中 Alex 更强调 compositionality：如果两个任务表面上完全不同，却共享同一个高层程序结构，那么 RLM 可能学到可迁移策略。Prime Agent 则作为一个具体例子出现：它建在 Py/PyMono 上，限制 IPython 为唯一工具，其他工具通过 Python module 或 bash script 加载，并加入 continual harness、agent-to-agent communication 和 persistent subagents。

后半段讨论 swarm、开放式研究和模型边界。主持人提到一个半公开的 OpenAI swarm 规模：10,000 个 agents，运行 88 小时，产生 1300 亿 output tokens，按公开价格估算约 4000 万美元，最终输出约 300 亿 tokens。Alex 承认这种规模令人兴奋，但他关注的是多少探索真正有效、系统如何收敛、什么问题值得用 swarm。节目还把 Jev、loop transformers、输出语言、calibration 和低延迟分类串起来，说明 Alex 的兴趣不是某个单点产品，而是重新理解“语言模型”的边界：它可以是 decoder，也可以是 output space 改造，也可以是前端背后的 scaffold、swarm 或 harness。

三、核心观点：推理、例子与边界

Alex 在节目中的第一个核心判断，是不能把“语言模型能力”简化为 base model 本身。对他来说，harness 是一种带有明确取向的程序，用来把 next-token prediction 这个并不顺手的接口适配到困难任务上。代码库导航、SWE-bench 或长程工作流，很难靠一次模型调用完成；系统必须能够检索、执行、迭代、记录状态并拆分任务。由此看，许多产品虽然名称不同，底层却都接近“工具调用循环加 trajectory-as-prompt”。如果设计空间长期停留在这里，模型变强也会继续受限于交互格式和上下文管理。

RLM 是 Alex 提出的替代抽象之一。他强调，RLM 的核心不是“更长 prompt”，而是把 context 外部化到代码环境、内存或文件系统，让模型通过代码调用工具、调用自己，并生成子代理。这里的推理不是把一句句文本继续堆进上下文，而是把复杂任务转成一组局部调用。Alex 用“locally in distribution”解释这一点：整体任务可能超出训练分布，但如果每个子代理面对的是局部、熟悉、可验证的小问题，每一次 LM call 就更可能落在模型擅长的区域。这是 RLM 对泛化能力的关键承诺。

这个承诺的具体形式，是 Alex 所说的 compositional generalization。他提到，在短任务上训练出的 RLM 可以泛化到 8 到 30 倍更长的任务，因为模型学到的不是固定长度的表面轨迹，而是可以重复执行的策略。竞争编程和 GPU 优化也被他用来类比：两个领域表面不同，却都可能包含列出候选方案、派生子代理、循环检查、演化解法、用 verifier 评估这些步骤。这个例子让 RLM 不只是“agent 套 agent”，而是指向一个更具体的问题：高层程序结构能否跨任务迁移。

节目同时不断为这个愿景设定边界。Alex 并没有说所有 harness 细节都具有决定性作用；相反，他承认很多当前 harness 的差别可能主要体现在成本和用户体验上。RLM 是否能规模化训练，是否有更好的 post-training scaling law，是否能在更多真实任务中证明优势，节目中的证据仍主要来自访谈解释和部分公开或第三方实践，而不是完整外部评测。Alex 也说，自己在 MIT 的学术环境下不能做大规模 RLM 训练，Prime 和 Select 等公司才更明显地在探索这个方向。因此，RLM 在节目里更像一个强研究假设和系统设计方向，而不是已经封闭定论的产品结论。

第二个核心判断是：AI 生成代码不会消灭专家，反而会提高 verifier 的价值。GPU kernel 段落给出了最清晰的证据。许多 leaderboard 解法几乎完全由 AI 生成，说明模型已经能在局部优化空间里产出强结果；但 GauNurse 的方案在 top 10 中基本是唯一能在真实端到端系统里稳定运行的，说明能跑榜不等于能落地。Alex 明确指出，GPU kernel 存在验证问题，Kernel Bench 发布后 reward hacking 就一直是问题。专家的价值在于知道哪里可能出错，知道如何画图理解代码，知道如何引导模型搜索，也知道什么时候单 kernel speedup 会被 cache、fusion 或 memory-bound 的系统约束抵消。

这也解释了 Alex 对自动生成 mega kernel 的谨慎。单个 kernel 的 speed of light 有时可以估算，但端到端模型速度不是单点最优的简单相加。为了让第二个操作继续使用 cache，系统可能要牺牲第一个操作的局部速度。Alex 没有断言 AI 不能生成 mega kernels，而是说这类困难问题通常需要数据，并且他还没有看到在缺少样例的情况下，从真实环境中 bootstrap 出这类能力的案例。对于许多高层 op 的组合，他反而认为 compiler 可能更合适。这个限制很重要：模型生成能力强，不等于系统优化可以跳过数据、编译器、端到端测试和专家审查。

第三个核心判断是，swarm 的价值取决于目标函数和组织结构，而不是 agent 数量。主持人提到一个半公开的 OpenAI agent-swarm run：10,000 个 agents，运行 88 小时，产生 1300 亿 output tokens，按公开价格估算约 4000 万美元，最终输出约 300 亿 tokens。Alex 承认，能把这种规模的算力指向问题并解决它，本身令人兴奋。但他很快把问题转向效率：许多 swarm 探索可能只是烧 token，他甚至估计 95% 可能无用。真正的问题是：什么任务值得用 swarm？如何分配子任务？如何汇聚信息？如何避免中心协调者成为瓶颈？如何让 swarm 收敛到答案？

开放式研究让这个限制更加突出。如果目标明确，比如未解数学问题或某个 benchmark，可以用 evolutionary search 或 swarm 朝目标推进；但如果没有明确 objective，系统生成大量内容后，怎样选出真正有趣或有价值的结果？Alex 对此并不确定，并倾向认为仍需要方向性 nudging 或评价机制。这个判断防止我们把“更多生成”误读成“更多发现”。开放式系统的瓶颈不是产量，而是选择、命名、验证和价值判断。

第四个核心判断是，“语言模型”的边界正在松动。Alex 反驳 RLM 不是 language model 的批评，理由是 language model 是 modeling language，不必等同于 autoregressive transformer decoder。Jev 的意义也类似：重点不是它是不是旧式 MLP classifier，而是它尝试把已有 language model backbone 的信息转成不同 output space，用低延迟分类和可能更好的 calibration 换取不同的成本结构。对于只需要 binary classification 的任务，用完整语言模型生成文本可能带来 400x 成本，并不合理；而模型口头回答“自己有多确定”，也不等于有根据的概率估计。

这条线最后落在 capability overhang。Alex 希望有人系统研究，如何让当前 frontier models 在一个月跨度上持续、稳定地做好某个具体工作；他认为长期简单工作仍做不到，问题更像是 harness 或 skill issue，而不只是 frontier lab 才能解决的模型问题。主持人将其概括为：即使模型进步暂停，更好的 harness 也可能释放大量当前模型能力。这个说法有吸引力，但仍带有不确定性。Alex 给出的是研究方向和系统直觉，并没有声称现有某个通用 harness 已经能可靠完成一个月工作。更稳妥的理解是：模型能力可能存在富余，但要把它变成长期可靠劳动，还需要持久上下文、验证机制、任务边界和成本控制共同进步。

四、学习与应用

对 AI agent 产品或内部工具建设者来说，本期最直接的应用，是把评估对象从“模型名字”扩展为“模型加 harness 的完整系统”。如果一个任务需要跨天或跨周执行，单看模型基准分数不够；还要看上下文是否持久化，工具调用是否可恢复，子任务是否能被验证，失败状态是否可追踪，成本是否可预测。Alex 对 Prime Agent 的描述提供了一个设计清单：把 context 放到磁盘或文件系统中，让工具通过代码运行，让子代理有通信规则，让某些子代理可以持久存在，并允许 harness 的部分能力被系统自己修改。

但这些做法都有边界。持久化上下文不自动等于正确，子代理越多也不自动等于更强。对于简单任务，compaction 可能比 RLM 更便宜、更快；对于搜索型问题，swarm 可能天然产生大量无效探索。应用时应该先判断问题形态：这是明确目标、可自动验证、可并行探索的任务，还是开放式、主观、难评价的任务？前者更适合 agent 分解和循环验证；后者需要人类定义 objective、筛选标准和停止条件。没有这些边界，系统只会把“看起来很忙”变成昂贵噪声。

对工程团队来说，GPU kernel 段落给出的是一个更一般的落地原则：排行榜结果只是入口，不是生产证据。AI 生成代码尤其需要 verifier、端到端测试和系统约束检查。一个 kernel 单独更快，可能因为 cache、fusion、memory-bound 或后续 op 的需求，在真实模型里并不更优。迁移到普通软件工程也是一样：agent 写出的 patch 通过局部测试，不代表长期维护、边界输入、性能回归和部署环境都可靠。团队应该把 AI 产物纳入现有审查流程，而不是让 leaderboard 或 demo 替代真实系统验证。

对研究者和创业团队来说，Alex 的选题建议更尖锐：不要只复制 frontier lab 的自回归 decoder 路线。如果没有同级数据和算力，正面竞争很难赢；更好的机会可能在 output space、harness、训练目标、数据表示、calibration、低延迟分类、持续 agent 系统等未定型区域。Jev 的例子说明，即使一个想法看起来像旧分类器，只要它重新打开了“语言模型应该输出什么、成本如何分配、概率如何校准”的问题，就可能有研究价值。RLM 的例子则说明，一个看似简单的 abstraction，如果改变了系统组合和泛化的方式，也值得认真测试。

应用这些思路时，也要接受研究不确定性。Alex 反复强调 big bets 会失败，很多想法一开始可能只是“坏但有趣”。他的个人方法是先低成本探索，如果发现确实有东西，再集中几周投入；这适合 PhD 或研究团队，但不一定适合每条产品路线。企业应用更需要提前设置 kill criteria：什么指标证明值得继续？什么成本说明该停止？新模型六个月后出现时，方案会被增强、替代，还是直接失去意义？AI for science 更是如此，因为 Alex 指出应用科学常有很长反馈周期，验证成本会改变整个研究节奏。

最后，对个人使用者来说，本期给出的实践建议不是“开更多 agent”，而是学会做强 verifier。无论是 kernel、法律文档、研究搜索，还是长期助理式工作，用户都需要把目标拆成可检查的小块，要求系统保留证据和中间状态，明确哪些结论只是模型猜测，哪些已经由工具、测试或外部事实支持。Alex 不喜欢泛泛地说“我喜欢你的论文，想合作”，偏好有明确观点、能解释自己为什么可能对或错的人；这同样适用于人机协作。越能提出具体假设、约束、反例和验收标准，越能把模型能力从漂亮输出转成可靠工作。

来源

• 原始节目：Recursive Language Models — Alex Zhang, MIT PhD