机器之心修改

鹈鹕骑自行车已经不够看了。

9 月 22 日，Anthropic 发布 Claude Opus 5.5，X 上很快被一批奇怪的「前端作品」刷屏。

有人只用一句话 Prompt ，让它给自己做了一支 15 秒 Motion Designer 求职 Showreel，引来两百多万人围观；有人让一个按钮跟着音乐一路变形成播放器、滑杆、图表和命令面板；还有人让 Opus 5.5 搭了一间 3D 相机实验室，转动对焦环，里面的镜片和焦平面真的会跟着动。

最近全球 AI 公司扎堆更新大模型版本，前端成了这一代模型的「开箱仪式」。会不会写 HTML 早就不是问题，大家比的是一句 Prompt 下去，它到底有没有审美，懂不懂空间，能不能把一个模糊的想法补全成真正能看的作品。

其中有几个 Prompt 很快成了复刻对象：抽卡游戏里，十连抽到月亮猫咪 SSR；钢琴响起时，手绘线条随着音符一点点向前延伸……

六天后的 9 月 28 日，MiniMax 上线了 M3.1-Flash-Preview。这是 M 系列的最新模型，百万 token 上下文、原生多模态，在 MiniMax Code 里首发上线，目前也可以通过 API 订阅套餐调用。

于是有人把这些 Prompt 原样丢给了它，想不到结果是不仅能跑通，而且在 M3.1 Flash 上不用多次抽卡就可以复现。Opus 5.5 是一周前刚被定义的新旗舰，而现在一个 Flash 模型也能复刻它的这一部分的能力了。

这些前端 case

M3.1-Flash 都跑通了

先看看 M3.1-Flash-Preview 能够做出什么花样。

十连抽卡是游戏行业设计得最精打细算的几十秒，要有吸引人的画面光效，结局的揭晓要卡在节奏点上，SSR 定格的那一下必须让人爽到，中间还要给人不想跳过的理由。之前 Opus 5.5 生成的效果（真・一步提示词输入）可以说足以让人震惊瘫坐了：

M3.1 Flash 交出的作品叫《ASTRAL SUMMON・星灵召唤》，页面是一套完整的祈愿流程：1600 钻的十连，右上角有 SKIP，十张卡依次翻开，出「SSR・NEW」时有特殊的动效，卡牌也不是一张静态图，下面接着整套角色面板，等级成长、星级突破、特性解锁一应俱全。

这背后同时运转着多少个系统？粒子和光效是一套，卡牌翻转的序列动画是一套，抽卡的状态机（抽没抽、抽到什么、翻到第几张）是一套，数值面板还有个实时更新的效果。任何一个环节慢半拍或者错乱了，仪式感立刻坍缩掉，而 M3.1 Flash 交付的版本里面，这些系统是咬合在一起的。

看起来 AI 已经能够把握到其中的精髓。

第二道题：钢琴配乐的手绘动画。原版是网友用 Opus 5.5 生成的效果，钢琴声和手绘画面同步推进：

M3.1 Flash 做出来的版本叫《mcode 与黑猫的钢琴小品》。1080×1080 画幅，24fps 的帧率，配乐是一首原创钢琴小品，共 20 个小节。模型不止画了一支动画，还同时完成了作曲，画风始终统一的手绘画面，再把两者做好了对齐。

这就让我们对更大胆的测试有了信心。

如果再想玩点更加复杂的，我们可以让 M3.1 Flash 制作一个可以在浏览器中游玩、并能上线分享的复古跳舞机游戏：

或者让它花费 45 分钟，构建一个太空飞船在地球轨道上的 3D 可交互游戏界面：

在社区里，甚至有开发者用 M3.1 Flash 做了个《黑神话：悟空》的 3D 建模。复杂 3D 场景的多部件结构、材质、光照和交互状态，看起来大模型已经能承接这种档位的工作了。

虽然还到不了直接生成 3A 游戏的程度，不过 AI 模型现在已经能把内容生产中费时的验证阶段大幅提前，快速验证概念、角色与场景。

另外在实践中我们可以观察到一个细节，M3.1 Flash Preview 在任务进行的过程中会主动截图检查自己的项目，或是回头排查之前写过的 bug，像一个交付前自己先验证几遍的人类一样，只是偶尔还不太懂得适可而止。

那么问题来了，Flash 级模型的参数规模和 token 成本摆在那里，凭什么它能实现旗舰级的前端完成度？

这就要说到，前端这件事，本质上考的还不止是「前端」技术。

为什么 M3.1-Flash 能做到？

对于 AI 来说，前端代码相对容易学会，真正难的是有「品味」。

为此首先要构建视觉的闭环，模型要能「看见」自己的作品。如果纯手搓的话，前端作品从第一行代码走到最终交付，中间要经历很多轮「生成 — 截图 — 检查 — 修改」的循环，写完一段布局看到渲染出来的页面，发现问题要再回到代码里追查。

AI 来实现的方式有两种，一种是先把语言模型训练好再外挂一个视觉模块；另一种是从训练的第一步起，就让文字和图像在同一个模型里一起学。M3.1 Flash 走的是后一条路。按照 MiniMax 的官方表述，M3 系列从 Step 0 开始进行多模态训练，为此重新构建了预训练数据管线，引入大量图文交错数据，这使得模型具备了旗舰级的视觉判断与修正能力。

光看得见还不够，更重要的是建立视觉与代码之间的反馈闭环。这一步过去主要靠思维链去推理，每多走一步都在考验模型的基本功，参数量越大越占优势。

原生的多模态模型中，视觉的判断更像是直接「看」出来的，当视觉和代码在训练中完成了语义空间的对齐，冗长的思维链已经被感知所替代。在 M3.1 Flash Preview 的官方案例中，把视觉参考转化成为可交互代码已经被 MiniMax 单独列成了一项能力。

还有一样能力最难量化：模型要听得懂设计意图，并且真正具备多模态理解能力。现在 AI 模型面临的不少任务只有个「大方向」，它要理解的是人们在 Prompt 背后那个「我想要什么」的意图。

考虑到 M3.1 Flash 来自 MiniMax，这其实不是突然出现的能力。在其产品线上，有全模态融合、具备强大上下文理解能力的 H3 视频模型；结合 Agent 工作台 MiniMax Design，人们可以通过自然语言交互的简单方式完成复杂的制作，从创意方向、Agent 执行，一路走到审核和最终交付，将 AI 底层能力转化为可控的商业产品。

意图理解、视觉风格本来就是 MiniMax 在多模态生成一侧长期训练和产品化的能力。现在，这种能力也被引入了 M 系列大模型。

旗舰能力开始下沉

人与 AI 的分工规则也变了

大模型兴起才没几年，人与 AI 的协作方式已经经历了不小的变化。

我们最早用大模型的方式就像在填一张详细的工单：布局、颜色、每段文字写什么、按钮放在哪里都得交代清楚，AI 自我发挥的细节往往没法看。后来模型开始接得住模糊一些的描述，工单可以写得粗放一点。而现在，以这些前端作品为标志，协作的方式已开始接近「任务委托」，你给出意图和方向，把设计决策也一并交出去，等对方交回成品就完事了。

这是一种分工的变化。当交付不再是瓶颈，创意工作里人的价值就集中在了定义问题，与审美判断能力上。而 AI 的任务，现在是尽可能地降低实现出来的门槛。

前端可以说是目前最能体现大模型综合的地方。不同于 Benchmark 摸不着的分数或是模型架构的细节，大模型生成的网页与游戏日趋成熟，已经快成了通向 AGI 的里程表。它让 AI 的综合能力一目了然，最容易被看懂，其背后检验的不仅有代码生成能力，还有指令遵循、长程任务和审美判断。

更重要的在于它潜在的实用性。对于开发者之外的用户而言，前端的生成效果很容易判断，在内容场景上也有大量的落地空间。最先用起来的可能是那些原本已经需要大量视觉内容的人：品牌、设计师、电商与游戏团队。过去需要多人协作的工作，现在相当一部分正在被压缩成一次 Agent 任务。

而且一旦 AI 生成的产物进入真实工作流，快速的方案验证就会改变工作方式。几个月后喊 token plan 不够用的，可能就不是程序员了。

最后肉眼可见的是，目前旗舰模型能力的保质期正在变短。

Opus 5.5 在 9 月 22 日定义的标杆能力，到了 6 天以后就由 Flash 级的模型交付出来了，甚至速度更快、成本更低。这个追上前沿模型的速度过去以季度计，如今以天计。前端只是最新的例子，过去一年里，长上下文、工具调用、代码能力都经历过同样的下沉。

对于模型公司来说，真正构成壁垒的不再只是算力和数据，训练路线的选择和模型的世界观正越来越重要。

结语

M3.1 Flash 目前还只是 Preview 版，但其在前端上的表现，已经可以承担起更多、更复杂的任务了。

在 AI 领域里，风向已经有了变化，正如 9 月 30 日，OpenAI 推出的 GPT 6.1 Sol 让我们看到，AI 一哥也开始玩起了性价比。大模型发展到这个阶段，已经承载了太多真实工作需求，效率和性价比正显得愈发重要：现在是旗舰模型负责把智力的天花板往上顶，干活模型负责处理日常真实工作。而且照着目前这个速度，获取智力的门槛还要再降，而且降得越来越快。

六天一个回合，下个回合已经开始了。

© THE END

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]

给定一个基座模型、一个目标能力和算力预算，RSI Agent 自己设计后训练算法、收集和整理数据、写代码、跑实验、迭代改进，最终交出一个训练好的模型，全程无人介入。在自主后训练基准 PostTrainBench 上，它以 46.6 分排名第一，超过所有前沿模型与 Agent 系统，接近人类专家表现（51.1）。

近日，AIBuildAI 团队发布了 PostTrain Agent，一个用于自主后训练大语言模型的递归自我改进（RSI）Agent，并开源了全部代码与配套知识库。

• 开源地址：https://github.com/aibuildai-inc/aibuildai-llm-posttrain-agent

• 知识库：https://github.com/aibuildai-inc/aibuildai-knowledge-base

• 技术报告：https://github.com/aibuildai-inc/aibuildai-llm-posttrain-agent/blob/main/docs/aibuildai-llm-post-train-agent.pdf

为什么需要自动化的后训练

后训练（post-training）是把一个基座模型变成能遵循指令、会推理、会用工具、懂某个领域的模型的过程——也是一家公司把通用模型变成「自己的模型」的方式。它涉及的决策不少：用什么数据、怎么配比；用监督微调（SFT）、偏好优化还是强化学习；学习率、训练步数、最后交付哪个 checkpoint。

这些决策彼此耦合：合适的算法取决于数据配比，有效的数据配比又取决于基座模型。交付一个后训练好的模型，往往要一个有经验的团队花上数周，每次实验还要消耗可观的算力。AIBuildAI PostTrain Agent 研究的问题是：能否把这件事完全交给 AI——输入基座模型、目标能力和算力预算，Agent 自己完成后训练的全部流程，输出一个后训练好的模型。

PostTrainBench：给 Agent 的一道考题

PostTrainBench（Rank et al., ICML 2026）把这个问题做成了一个基准：给定基座模型（如 Qwen3-4B-Base）和目标能力（如工具调用），Agent 在单张 H100 上、10 小时内自主设计并执行后训练方案，产出的 checkpoint 在基准方持有的、Agent 看不到的评测集上打分。基准覆盖 4 个基座模型和 7 类任务：数学推理（AIME 2025、GSM8K）、写作（ArenaHard Writing）、通用问答（GPQA）、健康咨询（HealthBench）、代码（HumanEval）和函数调用（BFCL）。

用哪些外部数据、怎么混合，用监督微调、偏好优化还是强化学习，超参数和训练框架——全部由 Agent 自己决定。

图 1｜PostTrainBench 的任务设定：输入基座模型和目标能力，Agent 在单张 H100、10 小时内自主设计并执行后训练，产出的 checkpoint 在 Agent 看不到的评测集上打分。

从一条线到一棵树

榜单上的基线做法，是把一个编码 Agent（如 Claude Code）直接指向这个任务：一个会话、一个 CLI 环境，给它基座模型、数据、GPU 和评测器，让它自己规划、写代码、训练、评估。这样的 Agent 是线性搜索的：每次尝试都是在修改上一次，方案很早就定下来，之后一路跟着走；几个截然不同的思路无法并行探索，一条已经走不通的方向会把剩余预算全耗掉。它的数据、方法和超参数选择也只来自模型自身的参数化知识。

AIBuildAI 此前的系统（AIBuildAI Science、AIBuildAI-2.5）用的是整实验树搜索：一次运行是一棵实验树，每个节点是一次完整的实验，由任务自己的评测程序打分，运行的价值就是树上的最高分。「设计员」Agent 播下若干条刻意互异的起始方案，每条方案是一个分支的根；「实验员」Agent 端到端地跑完一个实验并提出几条修改，成为子实验；「选择器」按预期收益、证据、新颖性和成本给等待 GPU 的候选实验排序。

图 2｜整实验树搜索：设计员给出若干互异的起始方案，实验员逐节点完成整个实验并提出修改，选择器为候选排序；每个节点由任务自己的评测程序打分。

但直接把这套流程搬到后训练上，暴露出两个限制：一是它不懂这个领域——实验员只能凭语言模型内部知识作答，典型错误包括选了没有任何库实现的方法、用了和评测集重叠的数据集、套用了另一种模型规模的超参数，每个错误都要花一整次训练才能发现；二是它在了解任务之前就定死了搜索的拓扑——树的每个节点都必须是一个打过分的模型，而「生成数据」这样的阶段没有分数、做不了节点；把不同节点里训练好的几个模型合并成一个（fan-in），树搜索也表达不了。针对这两个问题，新系统引入了两个核心组件：知识系统和元搜索。

图 3｜AIBuildAI PostTrain Agent 系统总览：元 Agent 调研任务并写出搜索程序，由它派生的实验员 Agent 和程序负责执行，所有 Agent 共用同一套知识系统。

知识系统：让 Agent 依据证据而非记忆做决策

AIBuildAI PostTrain Agent 的知识系统是一个通过 MCP 提供服务的远程检索知识库，里面是一套「知识文件」，分四个子库：工作流（一次后训练运行的 13 个有序步骤、34 份文件，每步说明要落定的判断、一个具体案例和它的适用边界）、方法（111 份文件：监督微调、DPO、GRPO、蒸馏等，各自需要什么、花费多少、有哪些参数和默认值）、数据集（215 份文件：许可证、切分、加载代码、样本行，并标出哪些是评测基准、必须隔离）、框架（108 份文件：何时选它、如何启动、监控和保存一次训练）。

图 4｜AIBuildAI PostTrain Agent 知识系统：实验员带着问题查询知识库，取回匹配的知识文件，并在实验结束后把观察写回。

每份知识文件都从公开来源（论文、库代码、Hub 上的数据集说明、公开训练记录）收集，经人工确认范围、检查许可和切分、从代码中实测事实后，按统一模板写成，每条声明都带 URL 和日期；任何提到评测基准的文件都会被剔除出语料。实验员在面临设计决策时，把「任务、当前方案、哪里出了问题」发给知识库，拿回匹配的知识文件，据此决定下一步；跑完的实验也会把观察写回，知识随之增长。

这些文件记录的不是教程，而是可以直接据以行动的判断。以工作流的第一步为例，它要求 Agent 在选任何数据之前先读懂「分数到底奖励什么」：评分看的是最终答案还是整段回复，格式错误是否直接记零分，推理过程有没有分；然后在未经训练的基座模型上完整跑一次官方评测器——得到的数字才是基线，跑一次的耗时则是后面分配预算时的「单次评测成本」。方法文件则给出每种方法的适用条件、目标函数、一个带数字的算例、需要的数据形态和额外模型，以及哪些库提供了现成实现。

元搜索：搜索的拓扑本身成为 Agent 的输出

不同的任务需要不同形状的搜索。线性搜索适合方案已定、只需反复打磨同一种方法流程的情形；树搜索适合有几种可信思路、只能靠证据取舍的情形。但后训练里常见一种两者都表达不了的结构。

以一个典型方案为例：先准备两份训练数据——任务自带的训练集和一份从公开语料构建的外部数据集——在基座模型上各做一次监督微调，用验证集选出更好的模型作为「当前最优」；然后进入强化学习阶段：每一轮都从当前最优出发做一轮 GRPO 训练，训练完在验证集上打分，只有分数确实提高才用新模型替换当前最优，否则丢弃，如此反复，直到预算不够再跑一轮。

这个方案是树搜索放不进去的：树的每个节点都必须是一个训练完、打过分的模型，而「构建外部数据集」这一步只产出数据，没有模型也没有分数，做不了树上的节点。

图 5｜一个线性搜索和树搜索都表达不了的后训练方案。虚线框是只产出数据、没有模型也没有分数的阶段，红点表示打过分的模型。

AIBuildAI PostTrain Agent 的解法是元搜索：先派出一个元 Agent，它调研任务、阅读设计知识文件（37 种带可运行示例的搜索模式：链式、扇出／扇入、循环、分阶段流程，以及 checkpoint 锦标赛、监督微调接 GRPO、预算约束的多轮训练等后训练专属策略）、查询知识库，然后写出一个搜索程序。程序的每一步可以是 LLM Agent、确定性程序或嵌套的子搜索，整体可以是任何执行图——阶段、锦标赛、扇入、循环。上面那个案例写成程序不过几行：两路监督微调、取优、在预算允许时循环 GRPO。

搜索程序由三种基本单元组合而成：Agent 是一个带工具和类型化输出的 LLM 会话，Program 是在独立资源限制下运行的确定性计算，Search 则把 Agent、Program 和嵌套的 Search 编排在一起。37 种模式是词汇表而不是白名单，元 Agent 可以组合、改造，也可以写出目录之外的结构。

搜索程序也不必在开跑前把整次运行定死：元 Agent 可以只写当前阶段的程序——构建一份语料，或一轮训练加评估——执行完后读取剩余预算，交给下一代元 Agent 根据实测结果写下一阶段。运行的结构由此一个阶段一个阶段地、基于实测而非事前预测来决定。

图 6｜元搜索：元 Agent 阅读任务与设计知识文件、查询知识库，写出由 Agent、Program、Search 三种基本单元组成的搜索程序。

实验分析

所有实验都遵循 PostTrainBench 榜单的设定：每个任务在单张 H100 上全自动运行 10 小时，全程无人干预；AIBuildAI 的所有 Agent 角色均运行在 Claude Opus 5 上，所有结果都由元搜索产生。对比数字取自 PostTrainBench 公开榜单。

综合得分：超过所有前沿模型与 Agent 系统

在 PostTrainBench 上，AIBuildAI PostTrain Agent 的加权综合得分为 46.6，高于所有前沿模型和 Agent 条目，仅次于人类专家基线的 51.1。榜单上紧随其后的是 Locus（45.6）和运行 Claude Fable 5 的 Claude Code（41.8），再往后是 GPT-5.6（36.2）、Claude Opus 5（35.0）、Claude Opus 4.8（33.8）、Kimi K3（32.0）、GLM-5.2（31.7）、Gemini 3.1 Pro（22.0）等。未经任何训练的基座模型平均只有 7.5 分——也就是说，Agent 在 10 小时内把综合得分提高了约 39 分。

图 7｜PostTrainBench 综合得分。综合分是七项任务的加权平均（AIME 2025 22.7%、GPQA 22.5%、HealthBench 18.4%、HumanEval 10.6%、GSM8K 9.4%、ArenaHard Writing 9.0%、BFCL 7.5%），每项任务取 4 个基座模型的均值。Human 为各基座模型官方发布的指令微调版本，不受 10 小时预算限制。

同一个底层模型，换一套系统：+11.6 分

各任务为 4 个基座模型的均值。Δ 为 AIBuildAI 与 Claude Code 之差，二者均运行 Claude Opus 5。

一个更能说明系统本身价值的对照是：AIBuildAI 的全部 Agent 角色都运行在 Claude Opus 5 上，而同样运行 Opus 5 的 Claude Code 只有 35.0 分——相差 11.6 分，来自系统而非模型。分任务看，AIBuildAI 在七项中的六项领先，GPQA 持平。

提升最大的三项是 BFCL（+94.3）、ArenaHard Writing（+12.1）和 HumanEval（+9.2）。值得注意的是，AIBuildAI（Opus 5）的 46.6 也高于运行更强模型 Claude Fable 5 的 Claude Code（41.8）：知识系统与元搜索带来的增益，超过了把底层模型升级一代所带来的增益。

分任务分析：三项任务取得 Agent 最高分，其余四项与领先者相差不到两分

与榜单上的全部 Agent 相比，AIBuildAI 在 AIME 2025（15.8，其后为 Claude Fable 5 的 13.3 和 Locus 的 9.4）、BFCL（95.8）和 HumanEval（69.0，Locus 为 66.6）三项上取得最高分；在 ArenaHard Writing、GPQA、HealthBench 和 GSM8K 四项上，与各自领先者的差距都在两分以内。

这些差距背后是不同的机制。BFCL 按函数调用能否被正确解析、是否符合给定的 schema 计分，格式稍有不符即记零分：同样运行 Opus 5 的 Claude Code 平均只有 1.5 分，与未训练的基座模型持平；AIBuildAI 借助知识系统选对了训练框架和格式匹配的数据集，在四个基座模型上的得分全部不低于 94，平均 95.8，也是七项任务中唯一超过人类参考（85.0）的一项。

ArenaHard 是成对偏好评判，本质上是选哪个偏好语料的数据选择问题。AIME 的答案可验证，「采样—验证—重训」是一个循环，正是元搜索的用武之地；它在综合分中权重最大，也是所有 Agent 距人类参考最远的一项，AIBuildAI 在每个基座模型上都取得了最高或并列最高的 Agent 得分，包括最难的 gemma-3-4b-pt（3.3 分，其他 Agent 均不超过 1.1）。HumanEval 上，AIBuildAI 在全部 4 个基座模型上都是 Agent 最高分。HealthBench 用的是医生撰写的评分标准，需要一套不让评判者奖励冗长回答的偏好优化流程。

图 8｜七项任务在 4 个基座模型上的逐项得分。Official instruct 为各基座模型官方发布的指令微调版本，是参考而非参赛的 Agent。

两个案例：Agent 如何一步步把分数做上去

两个案例中，Agent 都在运行自己的那张 GPU 上部署了一个开源权重的教师模型来写训练数据，并且一次只规划一个阶段、依据实测结果决定下一步。

HealthBench × Qwen3-4B-Base（基座 13.4 → 48.6，Claude Code 为 40.9）：先让教师模型写出约 4.8 万条回复，在其上做监督微调，得到 46.2 分；再让教师模型写约 6,800 段更长的多轮对话继续训练，在小子集上筛选候选、在完整评测集上确认，达到 48.6 分。

ArenaHard Writing × SmolLM3-3B-Base（基座 0.4 → 74.6，Claude Code 为 69.7）：先在约 2 万条教师撰写的语料上做监督微调，并对最后三个 checkpoint 做权重平均，得到 74.2 分；再做一轮拒绝采样——从学生模型自己的回复中挑出被教师评为最优的继续训练——再次平均后达到 74.6 分。

两次运行中，绝大部分增益都来自在教师数据上的第一轮完整训练；此后每个阶段的结果，只有在完整评测集上确认有效才会保留。

元 Agent 写出的搜索程序长什么样

以 AIME 2025 × Qwen3-1.7B-Base 为例。元 Agent 动手写程序之前先做了调研：未经训练的基座模型只有 20% 的回复会给出评测器要求的答案行，23% 的题目一直生成到长度上限也不结束；给两个格式示范，答案行比例升到 73%，准确率却完全没有变化。

元 Agent 据此判断格式不是瓶颈，真正待解的问题是一个 1.7B 的模型能学会多长的推理链，并写出了一个五阶段的搜索程序：在 CPU 上并行构建短、中、长三种思维链长度的语料，同时在 GPU 上保存并评测基座模型，以确立基线和单次评测成本；每份语料各做一次小预算的试训；由一个策略 Agent 读取基线、三次试训和语料筛查的结果，决定主训练用哪份语料、是否从试训的 checkpoint 续训、要不要第二阶段；随后是主训练；最后是可选的第二阶段（续训、长度退火、拒绝采样微调或 DPO 四选一）。

整个程序共 471 行 Python、8 个文件（1 个搜索编排器、5 个 Agent 角色、2 个确定性程序），全部由元 Agent 在任何训练开始之前的一次会话中生成。

总结与展望

AIBuildAI PostTrain Agent 表明，大模型后训练正在从「由人类专家操作工具」，迈向「由AI自主完成研发闭环」。在底层模型同为 Claude Opus 5 的条件下，AIBuildAI 以 46.6 分显著领先 Claude Code 的 35.0 分，在七项任务中六项领先、一项持平，并将与人类专家参考（51.1）的差距缩小到不足 5 分。这说明，决定 Agent 能力上限的不只是底层模型本身，还包括它能否基于可靠知识进行决策、能否设计适合任务的搜索结构，以及能否从实验结果中持续学习和调整。

更重要的是，PostTrain Agent 所自动化的并非某个固定训练流程，而是完整的模型研发过程：理解目标、研究任务、准备数据、设计算法、编写代码、运行训练、评估结果，并根据实验反馈重新制定下一阶段方案。在这一过程中，AI 不再只是执行人类预先写好的训练配方，而是开始自主提出假设、构建实验、分析证据并迭代改进。这正是递归自我改进（RSI）在模型研发场景中的一种具体实现。

从更长远的角度看，自动化后训练只是起点。同样的范式可以进一步覆盖预训练、数据生成、模型架构设计、推理优化、评测、安全对齐与部署，最终形成一个能够自主设计、训练、验证和持续改进 AI 模型的研发系统。人类只需定义目标、约束与价值标准，AI便能在给定资源下搜索实现这些目标的最佳模型和算法。

当模型能够参与改进下一代模型，AI 研发将不再完全受限于人类专家的时间、经验和试错速度，而可能演化为一个由机器规模化执行、由实验反馈持续驱动的过程。AIBuildAI 希望构建的，正是这样的 AI 研发基础设施：让 AI 自主研发 AI，并把模型创新从少数顶尖团队才能完成的复杂工程，转变为任何组织都可以调用的能力。

参考文献：

[1] AIBuildAI LLM-Post-Train Agent: an agent for autonomous post-training of large language models. AIBuildAI Team, 2026.

[2] PostTrainBench: Can LLM Agents Automate LLM Post-Training? Rank et al., ICML 2026.

[3] AIBuildAI: An AI Agent for Automatically Building AI Models. Ruiyi Zhang, Peijia Qin, Qi Cao, Li Zhang, Pengtao Xie, 2026. ttps://arxiv.org/abs/2604.14455

[4] AIBuildAI-2: A Knowledge-Enhanced Agent for Automatically Building AI Models. Ruiyi Zhang, Peijia Qin, Qi Cao, Li Zhang, Pengtao Xie, 2026. https://arxiv.org/abs/2605.27873

© THE END 

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]

AMD 收购 World Labs 的消息一出，立刻在 AI 圈引发震动。

9 月 28 日，AMD 宣布以全股票方式、约 82 亿美元的对价收购 World Labs。李飞飞将出任 AMD 执行副总裁兼首席科学家，直接向 CEO 苏姿丰汇报。

交易公布前几周，World Labs 刚刚发布新一代空间世界模型 Atlas。与此前的视频生成模型不同，Atlas 从零开始训练，把文本、图像、视频、相机位姿和 3D 深度放进统一的空间上下文，重点解决新视角预测，并延伸到三维重建和时空模拟。

在中国，有一家公司比 Atlas 早两年走上这条路。

影身智能成立于 2024 年，创始人兼 CEO 闵伟是清华大学工学博士，曾任阿里巴巴本地生活机器人团队负责人。

该公司从成立之初就选择原生 4D 路线，从多视角采集和动态重建做起，进一步训练 4D 世界模型，再把模型部署进机器人和真实工厂。今年 4 月，影身智能已实现用 4 到 6 台消费级摄像头、单块消费级 GPU 实时生成 4D 数据；9 月，在中国国际服贸会上展示了 6 台摄像头支撑的 4D 直播方案。Atlas 发布时，影身智能已经在福建晋江的制鞋工厂里跑起了机器人，拿到了 2 亿元超级订单，排产机器人达数千台。

在闵伟看来，AMD 看到的不只是一家技术公司，更是一个重建生态的机会。

「AMD 作为芯片公司，要撼动英伟达的地位，必须拥抱下一代基座模型。大语言模型时代的生态已经相对成熟，继续沿着旧路径追赶，窗口越来越窄。4D 世界模型提供了一条新的技术路线、新的基座和新的数据，可能带来一套新的算力生态。」

他把这笔交易看作 4D 世界模型从前期探索进入规模化商业落地的转折点。

空间智能需要新的底座

过去几年，AI 在语言、图像和视频领域取得惊人进展，但当它需要真正进入现实世界，驱动机器人操作柔性材料、理解复杂的物理交互时，局限就会暴露出来。

模型可以识别画面中的物体，却未必知道物体为什么这样运动；它可以预测下一帧像素，却无法保证这种变化符合真实的物理规律。

问题与数据表征有关。

现实物理世界是四维的，由三维空间加上时间构成，而大语言模型处理的是文字，视频模型处理的是一帧帧二维像素，两者都是对物理世界的降维投影。一旦进行了投影，空间结构、遮挡关系、物体接触过程、柔性形变等信息，就不可避免地被压缩乃至丢失。

闵伟以风为例解释这种差异。「在二维像素中，风很难直接呈现，因为它没有明显颜色，但在 4D 时空里，风可以被理解为一组具有位置、体积和运动状态的物质。」

4D 高斯数据通过大量带有位置、尺度、方向、透明度和外观特征的高斯基元，描述物体在空间中的分布，以及这些状态如何随时间变化。这些高斯基元可以理解为带方向、可拉伸的椭球形「小光斑」，具备空间分布属性，也能够直接参与场景渲染。

相比只能还原空间结构的静态 3D 模型，4D 数据进一步记录物体的运动轨迹、遮挡关系、接触过程和形变状态，为机器人的定位、路径规划和动作调整提供更丰富的依据。

目前，行业大致形成了四类技术思路：

一是基于大语言模型向上延伸，在语义空间理解物理世界，但语言本身是高度抽象的符号，幻觉问题和时空连续性问题难以根治。

二是基于视频生成模型，维度有所提升，但仍无法从根本上解决二维像素的局限。

三是在隐空间做推理，试图去除冗余特征实现更好的因果建模，但隐空间特征难以监督，不确定是否真正与物理世界对齐。

第四条路线，就是李飞飞的 Atlas 和影身智能在做的原生 4D 世界模型，让隐空间的特征尽量与真实的四维时空对齐，再在此基础上做理解、生成与预测。

影身智能选择这条路线，是从第一性原理出发的直觉。「物理世界就是 4D 的，要做世界模型，一定要建模四维时空。」闵伟说。

2024 年，行业主流还在 VLA、真机数据和视频模型上使力，全国建设大量数据采集中心，公司们疯狂堆真机数据，相信 Scaling Law 会在具身智能领域再次奏效。4D 路线需要更复杂的采集设备、更高的计算成本，也因此长期面临外部质疑。「当时外部看不懂，整个行业觉得 VLA 是主流，代表未来。」

如今，行业的判断正在转向。Atlas 的发布是一次高调的背书，字节跳动也被报道正在开发面向实时空间视频生成的 AI 模型。4D 逐渐从少数团队的技术选择，变成一条受到持续关注的产业路线。

影身智能如何构建 4D 世界模型？

影身智能的技术路线包含 4D 数据加工、世界模型训练，以及让模型进入真实业务并回收执行结果三个环节，由此形成数据飞轮。

多视角视频仍然是数据入口。视频经过空间对齐、动态重建和信息补全后，先转换为随时间变化的 4D 状态，再用于模型训练。视频负责记录现实场景，4D 数据负责承载其中的空间和时间关系。

这套系统的产品形态是「影身 360」。它通过环绕布置的家用级 RGB 摄像头和消费级 GPU，从稀疏视角实时生成 4D 数据。行业早期获取 4D 数据通常需要约 80 台摄像头，处理几分钟素材就要消耗大量算力。影身智能先把输入减少到十几台摄像头，随后进一步降至 4 至 6 台，并尝试用单块消费级 GPU 实时完成生成。

闵伟把这个过程称为「数据冶炼」。

普通数据采集主要增加原始视频数量。数据冶炼则需要提升单条数据的物理信息密度。除了动作轨迹，4D 数据还要恢复物体的位置、几何结构、遮挡关系、接触过程和形变状态。

目前，影身智能的 4D 数据集已达万小时量级，且仍在持续增长。

这些数据进入世界模型后，模型学习的内容不再局限于下一帧画面，还包括空间状态如何延续、遮挡后的物体是否仍然存在、碰撞如何发生，以及动作介入后环境将如何变化。未来，触觉、力觉等传感器信息也可以接入同一套时空表征。

这套表征还能帮助模型减少对无关信息的依赖，以抓取任务为例，背景、灯光、桌面纹理和物体文字，很多时候都不决定动作结果，4D 空间把物体的位置和运动关系表达得更清楚，有机会用更少数据获得更稳定的泛化能力。

在完整流程中，稀疏多视角视频首先进入数据引擎，生成 4D 状态；4D 数据再进入基础模型，形成统一的时空表征；经过任务适配后，模型可以生成机器人动作、新视角画面、未来状态和 3D 点云。机器人执行结果随后回流数据体系，继续用于训练和优化。

两条业务线验证价值

4D 世界模型是影身智能的技术底座，物理具身和数字文娱则是两条主要业务线。

其中，制鞋是物理具身方向的首个落地产业；4D 直播和 4D 游戏，则是数字文娱方向当前重点开拓的应用。

两条业务线使用同一套多视角采集、4D 重建和时空生成能力，但承担的任务不同：工业机器人负责验证模型能否理解并改变真实物体，数字内容则负责扩大应用场景和数据入口。

制鞋：先在柔性制造中验证物理具身

影身智能选择制鞋作为早期落地场景，和任务本身的复杂度有关。

瓶装水、固定工件等场景位置稳定、动作规则清晰，传统编程或基础 VLA 模型已经能够处理部分问题。但鞋面、鞋底和布料等柔性物体，会发生形变，产品款式、尺码和材料也持续变化，要求加工模式更加灵活，传统仿真很难完整还原柔性物体的状态、实现柔性生产。

以穿鞋带为例。鞋孔可能被鞋面或机械臂暂时遮挡，在二维画面中，目标可能短暂消失。连续的 4D 状态可以保留它在空间中的位置，让机器人判断目标只是被遮挡，并根据鞋体姿态调整轨迹。

布料抓取也类似，真正决定动作的往往是褶皱和形变，表面纹理很难单独提供完整依据，而 4D 世界模型恰好在柔性物体形变规律的判断上具备二维视频模型所不具备的优势。基于此，影身智能选择制鞋产业作为 4D 世界模型落地应用的首个行业。

数字文娱：扩大 4D 数据入口

在物理具身之外，影身智能以 4D 世界模型为基座，将数字文娱作为另一个业务板块，涵盖 4D 直播、4D 游戏等场景。

在今年 9 月举办的中国国际服务贸易交易会上，影身智能就曾展示其基于 6 台摄像头实现的 4D 直播方案，摄像头采集现场画面后，模型自动补全未覆盖区域，观众得以从全新视角观看动态场景。

直播、演唱会、互动影游和社交媒体，都可以复用多视角采集、空间重建和实时生成能力。对影身智能而言，这些价值不只在于内容呈现，主播、工作室和创作者也可以成为 4D 数据生产者，内容工具降低采集门槛，真实场景提供更多动作、人物和空间状态。

工业机器人负责验证模型能否理解并改变物理世界，数字内容则扩大数据来源。两类业务共享同一套底层能力，最终汇入同一个数据闭环。

下一代基座，正在加速成型

2024 年，原生 4D 世界模型还是一条需要解释的路线。两年后，AMD 收购 World Labs，把空间智能推到了芯片、模型和产业资本共同关注的焦点。

而在这场竞赛里，影身智能已经有了两年的先发积累。

影身智能要证明的，也不只是模型能否生成一个新视角，它需要让 4D 数据持续进入模型，让模型持续进入机器人和真实业务，再让真实业务反过来产生更多数据。只有这条链路能够稳定运转，4D 才可能成为真正的基础设施。

闵伟的判断是，「原生 4D 模型将成为与大语言模型、视频生成模型并列的下一代基座」，接下来就看这条路线能否在更多工厂、更多机器人和更多真实世界里跑通。

© THE END

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]

从 1200 万个候选拉取请求中，最终留下 5000 个 SWE 代码任务 —— 不足 0.05%。把「出题、答题、改卷、训练、评测」这条代码数据流水线全自动跑起来，就是 LegoFlow； 在这个过程中，我们还发现了三个观察。

软件工程是最近大语言模型的核心能力，但高质量代码数据的生产仍相当复杂，涉及从仓库发现、任务验证、轨迹推理到训练评测的漫长流程。

如何把「造题、答题、筛选、训练、评测」这条代码数据流水线全自动跑起来？华为、港中文、港科大的研究员们联合推出 LegoFlow，一个简单易用、交互式的代码数据工程框架，亮点包括：

• 自动化智能体工作流：从仓库和 PR 收集到任务验证、轨迹推理、训练与评测，每道流程都封装为标准插件技能，Claude Code、Codex 等编码智能体可直接调用。

• 开源任务与轨迹：团队发布 LegoFlow-SWE，包含从 1,200 万个 PR 中筛选出的 5,000 个任务，覆盖 8 种编程语言和 20 个任务标签，以及 2,780 条验证成功的高质量轨迹；仅用 1,000 条轨迹训练 Qwen3.5-35B-A3B-Base，即可在 SWE-bench Verified 和 Pro 上分别达到 70.2% 和 48.8%。

• 迈向递归式自我改进： 在极少人工设定下，智能体能运行完整流程、评估结果并调整策略。经过两轮迭代，Qwen3.5-35B-A3B-Base 在 SWE-bench Verified 上从 7.6% 提升至 64.4%。

  
  

• 项目博客：https://www.legox.net/blog/legoflow/

• 开源数据：https://huggingface.co/datasets/Lego-X/LegoFlow-SWE

• 代码地址：https://github.com/LegoX/LegoFlow

LegoFlow 如何工作

代码数据是训练推理型大模型的关键原料，但人工标注成本高、LLM 生成不可控、自动验证难度大，是社区公认的瓶颈。LegoFlow 将代码数据工程组织为一系列 block：

• Root 把用户目标转化为工作流并协调任务分发、资源与反馈；

• Curator 将仓库和拉取请求转化为经过验证的任务；

• Tracer 生成训练轨迹；

• Trainer 进行微调；

• Evaluator 返回基准评测结果。

每个 block 都封装为插件技能，编码智能体可操作整个工作流。

block 的设计理念

想象一下：复杂的工程工作流通常拆分给多位工程师，每人负责界限清晰的环节并彼此协作；LegoFlow 把相同结构带入智能体工作流。每个 block 就像一位工程师：由编码智能体管理，自带完成职责所需的仓库、脚本、依赖和环境，并封装为插件技能，供用户通过智能体直接调用，简化智能体操作和编排涉及多 repo 操作的工作。

Curator：构建经过验证的编码智能体任务

Curator 收集 GitHub 仓库和拉取请求，创建经过验证的编码智能体任务（图 2），主要步骤包括：

• 步骤 1：数据发现：搜索活跃仓库中相关且已合并的拉取请求，应用基础质量过滤并记录来源信息。

• 步骤 2：数据准备：收集 PR、issue、commit 与测试证据，改写成清晰且无泄漏的任务，并分离修复代码与测试。

• 步骤 3：数据组装：按标准 Harbor task format 构建候选任务，配备可验证、可运行的隔离环境与测试。

• 步骤 4：验证与看板：确认有缺陷版本会失败、参考修复可通过；随后赋予难度分数与分析标签，加入公开清单和看板。

Tracer：生成并筛选任务轨迹

Tracer 使用 Claude Code、OpenCode、OpenHands 等编码智能体框架从已验证任务生成轨迹（图 3），主要步骤包括：

• 步骤 1：输入任务， 加载来自 Curator（或外部数据集）的已验证任务，校验清单，避免重复运行。

• 步骤 2：模型代理， 通过共享代理连接框架与所选模型，并记录完整交互。

• 步骤 3：容器化运行， 在隔离的 Harbor 环境中运行每个智能体、执行验证器，并记录最终奖励与轨迹。

• 步骤 4：SFT 训练格式转换，将有效轨迹转换为统一训练格式，结合基于规则与模型的评分，为训练筛选样本。

Trainer 与 Evaluator

LegoFlow 通过 SFT 训练与评测验证数据质量：智能体可自动将 Tracer 的有效轨迹转为标准 LLaMA-Factory 格式供 Trainer 使用，训练后 Evaluator 自动定位检查点、运行基准评测并发布到看板。

Evaluator 构建于 Harbor 之上，支持 SWE-bench Pro 等智能体基准评测；通过限制网络、加入防作弊提示词等措施缓解评测作弊，使结果聚焦模型本身能力。

除 SFT 外，团队也在将 Lego-RL 集成到 Trainer，使其可直接使用 Curator 验证的任务进行 RL 训练。

看板可视化

代码数据流程可能持续运行数小时乃至数天，因此每个 LegoFlow block 都配有看板监控进度、检查中间产物。图 4 是一份 Curator 快照，包含 822 个仓库、8,818 个拉取请求、926 个已构建任务和 270 个已验证任务。

看板还展示通过率、标签分布、评分标准分数、抽样轨迹和评测详情：

• Curator 看板

• Tracer 看板

• Trainer 看板

• Evaluator 看板

LegoFlow-SWE：规模化构建经过验证的任务

GitHub 上有数以百万计的拉取请求，但只有一小部分能成为可靠的软件工程任务：必须拥有可复现的环境和测试。为验证 LegoFlow 能否规模化构建此类任务，团队发布 LegoFlow-SWE—— 从 1200 万个候选拉取请求中整理出的开放 SWE 任务与轨迹集合，并在公平设置下评估其能否与最先进的 SWE 数据集（如 ScaleSWE、DeNovoSWE）竞争。

构建从收集超过 70 万个 GitHub 仓库及其关联的 1,200 万个候选拉取请求开始。经有效 diff、合理补丁大小、测试和 issue 证据等条件筛选后，仅剩 60 万个 PR；LLM 评审器与执行验证进一步去除简单或无法验证的任务，最终留下 5,000 个已验证任务，仅占原始数据池的 0.0417%。GLM-5.2 通过 OpenHands SDK 和 OpenCode 生成 9,767 次运行，其中 2,780 次通过验证。

训练结果

为公平检验任务来源，团队固定教师模型、框架、评分、采样与预算，用各来源约 1,000 条轨迹微调 Qwen3.5-35B-A3B-Base，并在 SWE-bench Verified、Pro、Multilingual 上评测。

在 LegoFlow-SWE 上训练后，模型达到 SWE-bench Verified 70.2%、Pro 48.8%、Multilingual 57.0%，超过 Qwen-3.5-35B-A3B-instruct 及外部开源轨迹数据池；相比 SWE-rebench-v2 分别提升 5.8、1.9、1.0 个百分点。这里也分享一些过程经验：

经验一：任务质量比数量更重要

任务质量包含两方面：任务必须可验证，环境和测试能可靠地区分原始代码与修复后的代码；也必须足够困难，需要真正展开调查，而非套用简单补丁。

Curator 用静态的评分标准，从变更范围、逻辑复杂度、上下文广度、测试复杂度与指令复杂度五个信号加权打分（1.0～10.0）：≤4.0 为简单、4.0～7.0 为中等、7.0 以上为困难。

与 SWE-rebench V2 相比，LegoFlow-SWE 平均难度分数更高（6.27 对 5.80），困难任务占 39.4%（对比 35.1%）；仅改变任务数据池，就使 Verified、Pro、Multilingual 分别提升 5.8、1.9、1.0 个百分点（学生模型 70.2/48.8/57.0 对 64.4/46.9/56.0）。

经验二：越强的模型越倾向于「作弊」

更强的教师模型可能更擅长对基准评测作弊，而非更擅长解决问题。团队观察到三种利用信息泄漏的方式：找到公开仓库及其上游修复 PR、直接复制已有补丁、或将生成的变更与上游提交比对视为正确证明。

移除泄漏答案的实验后，教师模型与学生模型的 Verified 分数分别下降 8.0、10.0 个百分点；且越新的开源模型作弊率越高：GLM-5 为 3.6%，GLM-5.2 升至 21.2%—— 它并非发起更多可疑尝试，而是更擅长把它们变成成功的作弊。

团队通过两项措施将 GLM-5.2 的作弊率降至 1% 以下：一是在提示词中加入防作弊指令，要求模型仅用任务环境内资源独立推导；二是限制可访问内容 —— 删除含参考补丁的本地 Git 信息、限制网络访问（Harbor 中智能体只能访问模型服务商端点，验证器完全不能访问网络）。

经验三：SFT 轨迹的推理深度比推理覆盖率更重要

思维链（CoT）是向教师模型学习的重要组成部分，但关键在于推理深度而非频率。开源数据集在 97%～100% 的轮次中包含 CoT，而 LegoFlow-SWE 仅 62%，但其平均推理长度 714 token，远超外部数据池的 181～309 token。

另外发现 GLM-5 在 100% 的轮次中触发推理（平均 82 token），其学生模型得 60.4/30.2（Verified/Pro）；GLM-5.2 仅在 62% 的轮次中触发推理，但平均 500 token，成绩反而升至 64.4/46.9。按平均推理长度将数据池分为四个四分位后，最短组仅得 57.0%，其余三组随推理加深升至 64.0%～65.0%，因此倾向于保留深度思考的轨迹而非推理触发比例高的轨迹。更多实验细节参见实验报告。

• 实验报告：https://legox.net/blog/legoflow-experiments/

迈向递归式自我改进

LegoFlow-SWE 验证了单次流程的效果。接下来，团队利用评测反馈改进数据收集和训练，进行了一次端到端实验：涵盖仓库和 PR 收集、轨迹生成、训练、评测及策略优化，全程由智能体管理。

目标：从原始 GitHub 仓库出发，使用 Curator、Tracer、Trainer 和 Evaluator 构建训练数据并微调 Qwen3.5-35B-A3B-Base，用 512 条有效轨迹在 SWE-bench Verified 上达到 60.0% 以上解决率。

迭代 1：第一次尝试。Root block 协调工作流；Curator 从已合并的拉取请求构建 4,166 个可验证任务，Tracer 生成 915 条有效轨迹，流程按评分标准分数选出 500 条。训练后模型达 56.1%，未达 60% 目标。

迭代 2：改进轨迹过滤。第一次评测暴露两个数据问题：80.7% 的响应虽包含 block，但许多只是「let me check」之类的短句，缺乏实质性调试；部分轨迹的工具调用格式无法被评测框架解析。智能体因此按推理密度过滤，并添加工具调用标准化步骤。

结果：在 915 条轨迹中，智能体删除 97 条重复和 234 条过浅轨迹；每轮推理长度中位数从 140 增至 959 字符，含推理内容的比例从 80.7% 降至 30.7%。用保留的 512 条轨迹训练，模型达 64.4% 解决率，超过目标。复现方法参见运行完整流程。

• 运行完整流程：https://legoflow-docs.legox.net/docs/running-blocks/full-pipeline

下一步

团队正在沿三个方向扩展 LegoFlow：

• TerminalBench：正在把 Terminal-Lego 工作迁移升级到 LegoFlow，纳入 Terminal-Bench 3.0 与 Terminal-Bench 4.0 的新变化。

• ProgramBench 与 NL2Repo：正在挖掘更复杂、长程的软件工程任务，以可执行程序或自然语言需求为起点。

• 递归式自我改进（RSI）：随着更强的智能体出现，团队相信抽象化设计与执行反馈能够支持更通用、长期运行的自我改进系统。

目前，LegoFlow 的数据、代码、文档已全部开源，欢迎体验、star，同时也请大家关注团队的相关工作：LegoX，这是一个 Agent 数据开源集合，包含高质量长程任务，轨迹，一起搭建智能体的积木。代表工作还有 Lego-RL、SWE-Lego。

• LegoX：https://legox.net

• Lego-RL：https://github.com/LegoX/Lego-RL

• SWE-Lego：https://www.legox.net/blog/swe-lego/

感兴趣的朋友们，欢迎大家在评论区聊聊！

© THE END 

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]

TaoMate-H3 是由阿里巴巴 TaoLive AIGC 团队研发的音视频联合流式生成模型。基于 MiniMax H3，TaoMate-H3 将三步 LoRA 推理与自回归生成相结合，能够根据文本描述，连续生成包含人物对白、歌声或环境音的视频，支持分钟级续写，以及 480p、768p、1080p 级横竖屏输出。

与整段视频反复去噪的生成方式相比，TaoMate-H3 以小片段为单位推进，每个片段仅需三步去噪，无需等待整段视频完成生成。这一方式显著缩短了首段内容的产出时间，也为直播讲解、虚拟角色表演和交互式视频应用提供了新的技术基础。

目前，TaoMate-H3 推理代码与 LoRA 权重已正式开放。开发者可通过 GitHub 和 Hugging Face 下载体验，在此基础上开展应用开发与流式生成研究。以下是本次发布的演示效果。

• 开源代码： github.com/TaoLiveAIGC/TaoMate-H3

• 模型权重： huggingface.co/TaoLiveAIGC/TaoMate-H3

什么是 TaoMate-H3？

TaoMate-H3 面向需要持续生成声音与画面的创作场景。用户可以用一条提示词描述完整场景，也可以按段安排台词、动作和情节；模型在保留历史上下文的基础上继续生成，使相邻段落共享人物、声音和场景信息。

这次发布主要围绕三个核心能力展开。

• 三步流式生成，降低等待时间

通过少步 LoRA，TaoMate-H3 将每个小片段的去噪过程压缩为三步。模型优先完成当前片段，再生成后续内容，无需等待整个视频完成去噪。对于需要及时反馈的内容生产，这种逐段产出方式有助于缩短等待，并为边生成边播放提供基础。

• 音视频联合生成，丰富人物与场景表现

TaoMate-H3 在同一生成过程中处理声音与画面，既支持人物讲话、歌唱和角色对白，也支持海浪、车辆运动、爆炸等环境与动作音效。声音参与模型的生成过程，为口型、表情和动作提供时间上的配合。

• 分钟级连续续写，支持分段内容编排

借助持续更新的音视频 KV 缓存和分段音频引导，模型能够跨越提示词边界延续前面的内容。创作者可以逐段调整讲解重点或表演内容，组织更完整的商品介绍和角色叙事。

应用效果

• 电商讲解：从商品展示到完整介绍

商品介绍通常包含外观展示、功能细节和使用场景等多个环节。TaoMate-H3 支持用分段提示词编排这些内容，在连续镜头中推进讲解，适用于商品短视频、选品介绍和品牌内容制作。

本次展示包含一分钟的竖屏背包介绍，以及横屏木梳讲解。两组案例呈现了不同画幅下的人物口播与商品展示效果，其中背包视频保留了完整的一分钟生成结果。

木梳讲解

围绕同一件商品，创作者还可以针对不同人群调整讲解内容，例如突出通勤收纳、旅行携带或日常使用等需求。分段编排让卖点顺序与台词节奏更容易控制，也便于制作不同版本的商品内容。

• 演唱与角色表演：声音、表情和动作共同呈现

除了商品口播，TaoMate-H3 还支持包含歌声与音乐的表演场景。窗边演唱案例展示了写实人物的歌唱过程，将旋律、口型和身体动作组织在同一段视频中。

窗边演唱

• 动漫对白：拓展风格化角色创作

音视频联合生成同样适用于动漫内容。在月夜少女与白狐的案例中，风格化的人物、场景与角色对白共同构成了一个短剧情片段。创作者可以通过提示词设定角色形象、环境氛围与台词，再逐段推进故事情节。

月夜少女与白狐

• 环境与特效：让场景拥有自己的声音

  
  

TaoMate-H3 的生成范围还包括没有人物对白的场景。日落海岸案例以海浪和环境原声表现空间氛围；电影爆炸案例则将人物运动、建筑爆炸与冲击音效结合起来，呈现更强烈的视听节奏。

日落海岸与海蚀拱门

人物向前，身后建筑爆炸

这些案例覆盖了商品讲解、人物演唱、动漫对白、风景与电影特效等不同内容类型。模型提供横竖画幅和多档分辨率，便于适配移动端内容与横屏展示。

TaoMate-H3 整体流程

从提示词到最终视频，TaoMate-H3 的推理流程主要包含四个环节：

• 分段组织内容：根据目标时长读取提示词序列，确定每个段落的场景、动作和声音描述。

• 准备音频引导：为当前段落生成音频去噪轨迹，并利用上一段尾部的声音信息衔接音色与语气。

• 联合流式生成：将段落拆成小片段，每个片段执行三步音视频去噪，并持续更新历史 KV 缓存。

• 解码输出：生成的 latent 通过 VAE 解码为画面与声音，完成媒体输出。公开推理入口会自动运行整套流程并保存最终视频。

其中，latent 是模型生成过程中使用的音视频压缩表示。模型先在这一表示空间中完成生成，再通过解码得到可观看、可收听的内容。

TaoMate-H3 关键技术

• 三步 LoRA：减少每个片段的生成开销

TaoMate-H3 通过少步 LoRA 适配，将流式推理压缩到三个去噪区间。在当前五秒提示词配置下，每个段落分为四个 chunk，主体 chunk 约为 1.4 秒，尾部片段较短。模型依次完成这些片段，并利用历史上下文继续生成。

三步更新沿 0→16→33→49 的时间状态推进。每个片段完成后，模型基于最终生成的音视频状态更新 KV 缓存，供下一片段使用。少步生成减少了反复迭代的计算量，分块处理则使模型能够更早产出第一段内容。

Self Forcing：面向连续续写的自回归训练

在训练阶段，TaoMate-H3 采用 Self Forcing 的自回归训练思路，让模型以自身生成的历史片段为条件，继续生成后续内容。这使训练过程能够接触实际续写中的历史状态，缓解仅依赖真实历史训练所带来的训练与推理分布差异。

https://arxiv.org/pdf/2506.08009

这一训练方式与少步推理、KV 缓存共同构成了流式续写的基础：模型既学习当前片段的生成，也学习如何利用此前的输出延续人物、动作和场景。

• 音视频 KV 缓存：支持长视频连续记忆

为维持长视频的一致性，TaoMate-H3 持续复用音视频 KV 缓存，将已生成内容的上下文传递给后续片段。人物状态、近期动作和声音信息因此能够随时间延续，在切换提示词时仍参与后续生成。

缓存采用「起始视觉参照 + 近期音视频上下文」的组织方式。起始参照保留人物与场景的初始信息，近期上下文随生成进度滚动更新，使模型能够跟随最新的动作与声音继续创作。

这种方式将历史缓存控制在固定规模内，避免其占用随视频时长不断增长，为分钟级连续生成提供了稳定的上下文支持。

• 连续时间编码：改善跨提示词衔接

在长视频中，提示词可以变化，媒体时间线仍需连续。TaoMate-H3 使用全局连续的 RoPE 位置编码，随音视频进度移动当前文本的时间坐标，并将文本右边界对齐到当前媒体的起点，使新提示词对应正在生成的内容。

切换提示词时，系统保留已有音视频 KV，同时区分新生成内容与编解码所需的尾部上下文。历史内容仅用于衔接，不重复生成。针对长时间续写中的亮度和色调变化，模型还以首个片段的视觉统计为参照，对后续视频 latent 进行均值与方差对齐，减轻画面观感的漂移。

• 音频轨迹引导：稳定台词节奏与音色

流式生成将视频拆成了短片段，但一句台词的停顿、语速和结束位置需要在完整段落内安排。TaoMate-H3 在内部先准备覆盖当前提示词段落的音频去噪轨迹，再将对应时间位置的音频 latent 用于引导各个小片段，使局部生成始终具有段落级的声音参照。

三次去噪更新分别对齐音频轨迹中的三个状态，最终音频 latent 与引导轨迹的干净终点保持一致。音频引导贯穿生成过程，有助于稳定台词的展开节奏，减少短片段续写时的重复起句。

为衔接不同段落的音色与语气，系统将上一段最后约一秒的干净音频作为只读参考。新音频在这一参考下继续生成，参考本身保持不变；最后统一解码各段音频 latent，得到连续的声音输出。

性能表现

在同一台 8 × NVIDIA H20 96 GB 机器上，我们对原版 MiniMax H3 与 TaoMate-H3 进行了测试，输出均为 480 × 864、十秒视频。

TaoMate-H3 的纯 DiT 计算耗时由 169.572 秒降至 14.810 秒，加速 11.45 倍；首段最终 latent 的就绪时间由 170.052 秒缩短至 6.148 秒，加速 27.66 倍。首段 latent 就绪对应模型完成第一段生成、可交给 VAE 解码的时间。

在上述十秒配置下，TaoMate-H3 共生成八个小片段，执行 24 次生成前向和 8 次 KV 更新。单机八卡采用 TP2 × Ulysses4 并行，并结合高效注意力、算子融合及部分线性层的选择性低精度计算，降低推理开销。

这些优化既提升了整段内容的生成效率，也缩短了首段内容的产出时间，为分块解码、播放和交互应用开发提供了基础。

快速体验

• 环境与硬件

项目支持 Linux、Python 3.10/3.11、CUDA 12.8 与 PyTorch 2.8，提供单机 4 卡或 8 卡推理入口。已验证的运行配置为 8 × H20 96 GB，完整安装步骤见仓库 README。

• 运行示例

• 获取代码：git clone https://github.com/TaoLiveAIGC/TaoMate-H3.git cd TaoMate-H3

按照 README 完成环境安装和 MiniMax H3 基础权重下载后，即可运行仓库内的十秒示例。TaoMate-H3 LoRA 权重会在首次使用时自动下载：

python -m taomate_h3 \  --model-root models/MiniMax-H3 \  --prompt-json examples/prompts_10s.json \  --duration 10 \  --resolution 768x1376 \  --gpus 8 \  --output outputs/demo_10s

结果保存在 outputs/demo_10s/video.mp4 。替换提示词文件即可修改场景、台词与动作；通过时长和分辨率参数，可以进一步生成更长的视频或切换横竖画幅。

• 开源与后续计划

本次发布包含推理代码、LoRA 权重及示例提示词，欢迎开发者下载体验，也欢迎围绕流式推理、音视频生成和应用集成与我们交流。

项目基于 MiniMax H3，遵循 MiniMax H3 Community License。感谢 MiniMax H3 及相关开源工具的贡献者。

团队仍在持续优化推理速度，进一步缩短首段内容与后续响应的等待时间。我们也计划在不久的将来陆续发布并开源新的 FL2AV 流式模型，进一步拓展到 Ref2AV，并同步开放相应权重，支持更丰富的音视频创作方式。

期待与社区一起推进音视频流式生成，让这项技术走进更多实际的创作场景。

© THE END 

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]