GLM-5：从"Vibe Coding"到 “Agentic Engineering” 论文学习笔记

时间：2026-2-17

原文链接：arxiv.org/abs/2602.15…

研究背景

1. 当前人工智能正由“你问我答”的被动知识库，向能够独立工作的“主动问题解决者”进化
2. 期望 AI 不仅仅是在人类的提示下写几行代码，而是能像真实的软件工程师一样，自主地进行规划、实现和迭代修正

两个瓶颈：

1. 处理复杂任务时的计算成本极其高昂
   1. 从阅读几百字的对话，到包含成千上万个文件、动辄几十万 Token 的整个代码仓库
2. AI 在面对现实世界中极其复杂的软件工程时往往“水土不服”
   1. **缺乏长周期的上下文追踪与规划能力：**在多步链式任务中，AI 的每一步动作（比如修改了一个接口）都会改变代码库的上下文状态，并影响后续的动作 。主流的测试集（如 SWE-bench）通常只评估单次提交或孤立的代码编辑，根本无法衡量 AI 处理这种增量式、多步依赖开发的能力
   2. **在海量代码库中迷失方向：**面对一个真实的业务需求，AI 必须通过逻辑推理和语义关联，在深层目录中定位到具体的文件 。缺乏这种探索能力的 AI 根本无从下手
   3. 静态验证无法覆盖动态交互： 以前端开发为例，很多 Bug 是视觉化和交互式的，只有当用户点击按钮或调整窗口大小时才会显现 。传统的静态代码分析和固定的单元测试完全无法捕捉这些真实的场景错误，导致 AI 写出的代码在测试集里跑得通，但在真实浏览器里却完全不能用 。

GLM-5 专业定义

GLM-5 是一款总参数量达 744B（激活参数 40B）的新一代混合专家（MoE）基础模型 。它在底层架构上深度融合了 DeepSeek 稀疏注意力机制（DSA），在维持长上下文保真度的同时大幅降低了训练与推理的算力开销 ；在后训练（Post-Training）阶段，它构建了全新的异步解耦强化学习基础设施，以解决长周期任务中的对齐与自主性问题 。

GLM-5 的核心愿景是全面提升模型的智能体、推理和编码（ARC）能力，主导软件开发范式从“氛围编程（Vibe Coding）”向“智能体工程（Agentic Engineering）”的范式跃迁 。

• 氛围编程（Vibe coding）：人类给一段详细的提示词，AI 吐出一段局部的代码片段
• 智能体工程（Agentic engineering）：要求 AI 自己去规划、实现和迭代

主要贡献

• 底层架构与预训练创新 (Architecture & Pre-training)
  • 引入 DeepSeek 稀疏注意力机制 (DSA)
  • **多潜在注意力 (MLA) 的正交化优化： 针对 MLA 无法匹配 GQA-8 性能的问题，提出将 Muon 优化器中的矩阵正交化应用于独立注意力头的“Muon Split”策略，并改进出 MLA-256 变体，在不增加训练成本的前提下降低了解码计算量 **
  • 参数共享的多词元预测 (MTP)： 提出在训练阶段共享 3 层 MTP 模块参数，在维持与草稿模型一致显存开销的同时，有效提升了推测解码（Speculative Decoding）的词元接受率
• 强化学习基础设施与异步算法 (RL Infrastructure & Algorithms)
  • 异步且解耦的 RL 基础设施： 构建了中心化的多任务 Rollout 编排器，将推理（生成）与训练引擎在物理设备上解耦，彻底解决了长周期智能体任务中严重的 GPU 空闲等待问题 。
  • 新型异步智能体 RL 算法： 为保障异步离策略（Off-policy）训练的稳定性，引入了 Token-in-Token-out (TITO) 网关以消除重分词器误差，并提出了无需追踪历史策略权重的“直接双边重要性采样（Direct Double-sided Importance Sampling）”与词元级裁剪机制 。
  • 同策略跨阶段蒸馏 (On-Policy Cross-Stage Distillation)： 在多阶段 RL（推理、智能体、通用）的尾声，通过将先前阶段的最终检查点作为教师模型进行同策略蒸馏，有效克服了顺序优化导致的灾难性遗忘
• 智能体工程与自动化验证体系 (Agentic Engineering & Verification)
  • 可验证的真实环境扩展： 摒弃静态数据集，构建了包含上万个真实软件工程 (SWE) 仓库、Docker 终端任务及多跳知识图谱搜索在内的大规模可执行验证环境 。
  • “智能体作为裁判 (Agent-as-a-Judge)”评估： 针对动态交互场景（如前端代码），首创通过配备 Playwright 的视觉 GUI 智能体来模拟人类点击、截图与验证，实现了端到端功能正确性的闭环自动化评估

评测结果

展示了 GLM-5 在当前最前沿的智能体、推理和编码（ARC，Agentic, Reasoning, and Coding）基准测试中，与全球顶尖闭源及开源模型的实力对比

• 极限推理能力 (Reasoning)
  • Humanity's Last Exam (HLE)： 这是一个难度极高的综合性前沿测试
• 端到端软件工程与编码 (Coding)
  • SWE-bench Verified & Multilingual： 衡量模型解决真实 GitHub Issue 的能力。对于大模型工程落地而言，这两个指标含金量极高，直接反映了模型处理代码仓库级别的真实上下文水准
  • Terminal-Bench 2.0： 测试终端环境下的智能体编码与操作能力
• 复杂环境与长周期智能体 (Agentic)
  • BrowseComp： 网页浏览与操作测试
  • MCP-Atlas & $\tau^2$-Bench： 衡量多步工具调用和双控环境下的交互能力
  • Vending Bench 2： 这是一个衡量长周期业务经营能力的测试（模拟经营自动售货机一年）。GLM-5 最终盈利 $4,432，排名开源第一，展现了极强的长上下文连贯性和资源规划能力

展示了各个主流大语言模型在 Artificial Analysis Intelligence Index v4.0（人工智能分析智能指数 v4.0） 中的得分与排名对比 。该指数是一个综合性的榜单，它融合了 10 项高难度的评测基准

• GLM-5 的得分从上一代 GLM-4.7 的 42 分大幅跃升至 50 分
• GLM-5 正式成为了该榜单上排名第一的开源权重模型，是开源权重模型首次在 Artificial Analysis Intelligence Index v4.0 中取得 50 分的优异成绩

LMArena 是由加州大学伯克利分校发起的一个透明评估平台，它依靠人类的真实判断来对比前沿 AI 的能力 。它包含了数以百万计的真实交互任务（如写作、编码、推理和搜索等） 。因此，在这个榜单上取得高分，意味着 GLM-5 能够真正在现实世界的用户交互中提供巨大的实用价值

• GLM-5 在文本和代码两个核心维度上双双登顶开源榜首，证明了其目前在开源大模型生态中的标杆地位

展示了 GLM-5 在长周期任务（Long-horizon tasks）中的卓越表现 。在智能体（Agent）领域，模型能够长时间保持逻辑连贯性并自主完成复杂流程正变得越来越重要

• Vending-Bench 2：模拟经营测试，是一个专门用于衡量 AI 模型在长时间跨度下经营业务能力的基准测试。测试要求模型在为期一年的模拟环境中经营自动售货机业务，Y 轴代表模型最终获得的银行账户余额
  • GLM-5 在所有开源模型中排名第一，非常逼近顶级的闭源模型 Claude Opus 4.5
  • 证明了 GLM-5 具备强大的长期规划能力和资源管理能力
• CC-Bench-V2：真实软件工程场景测试，评测维度涵盖了前端开发（Frontend）、后端开发（Backend）以及长周期任务（Long-horizon，包含大型代码库探索和多步链式任务）
  • GLM-5 正在大幅缩小与 Claude Opus 4.5（灰色条带）这类前沿专有模型在实际复杂软件工程环境中的差距

训练流程梳理

GLM-5 的整个训练流程被精心设计为两大阶段：Base Model（基础模型训练）和 Post-Training（后训练）。这个管线（Pipeline）体现了从通识知识灌输到长文本能力构建，再到复杂智能体决策能力对齐的完整演进路径。

Base Model（基础模型训练）

目标：构建扎实的知识底座、强大的代码推理能力以及处理超长上下文的稳定性

预训练 (Pre-training) - 构建基础底座

- **数据规模与分布**：预训练早期使用了庞大的 27 万亿 token 语料库 。为了在早期就打下坚实的逻辑基础，预训练语料被分为两部分：18T token 的通用预训练语料（General Pre-training Corpus）和 9T token 的代码与推理语料（Code & Reasoning Corpus）。
- **上下文长度**：此阶段主要在 4K 的标准上下文长度下进行 

中期训练 (Mid-training) - 长文本与 Agent 能力注入

- **阶梯式上下文扩展**：GLM-5 采用了渐进式扩展策略，避免了一次性扩展带来的性能崩溃。首先在 32K 窗口下，使用 1T token 的长代码和推理数据（Long Code & Reasoning Data）进行训练 。
- **超长上下文与智能体数据**：随后，上下文窗口被扩展至 128K 和 200K。在这个阶段，模型摄入了 500B 和 50B token 的长上下文与智能体数据（Long Context & Agent Data）。这对于处理复杂的多文件代码库和长周期任务至关重要

稀疏注意力适配 (Sparse Attention Adaption)

- **无缝切换架构**：为了降低超长上下文的计算和显存成本，GLM-5 在 Base 模型训练的尾声，通过 20B token 的训练，将模型在 200K 窗口下平滑过渡到 DeepSeek Sparse Attention (DSA) 架构 。这种“密集预热+稀疏微调”的策略，避免了从头训练 DSA 的高昂成本，同时保留了长程依赖能力

Post-Training（后训练）

后训练阶段是 GLM-5 实现从“Vibe Coding”跨越到“Agentic Engineering”的关键。为了解决多目标优化容易导致的“灾难性遗忘”（Catastrophic Forgetting），研发团队设计了一个串行强化学习 + 蒸馏的流水线

全局监督微调 (Overall SFT)

- 作为后训练的起点，SFT 阶段极大地扩展了 Agent 和 Coding 数据的比例 。更重要的是，此时上下文长度扩展至 202,752 tokens，并引入了交错思考（Interleaved Thinking）、保留思考（Preserved Thinking）和轮次级思考（Turn-level Thinking）机制

轮次（Turn）指的是一次完整的用户交互周期：即从用户输入一个指令（User message），到智能体最终给出确定性回复（Answer）的整个过程

交错思考 (Interleaved Thinking)

• 内容体现 (Fig 7 - Turn 1)：模型在执行最终输出前被分成了多个 Step。在进行工具调用或每一次回答之前，模型强制先生成一段隐式的思考过程（Reasoning 1, Reasoning 2）。
• 核心目的： 提升模型对复杂指令的遵循能力和生成的整体质量 ，避免了单步自回归生成时容易出现的逻辑短视

保留思考 (Preserved Thinking)

• 内容体现 (Fig 7 - Turn 2)： 这是专门针对长周期（Long-horizon）编码智能体场景设计的特性 。对比图 7 右侧的两个分支：
  • 在传统模式 (w/o Preserved thinking) 下，进入 Turn 2 时，之前的推理过程被抛弃，只保留了工具调用和结果的历史记录 。
  • 在保留思考模式 (w/ Preserved thinking) 下，模型在后续轮次中自动保留了跨多轮对话的所有历史思考块（如输入上下文中包含了之前的 Reasoning 1, Reasoning 2, Reasoning 3）
• 核心目的： 在处理超长上下文的复杂工程栈时，保留思考让模型能够复用已有的推理逻辑，而不是在每一轮都从头重新推导 。这大幅减少了信息丢失和前后逻辑不一致的现象，是长周期任务稳定性的关键保障

轮次级别思考 (Turn-level Thinking)

• 模型允许在每一个具体的交互轮次（Turn）去独立决定“要不要让模型先思考再回答”
• 核心目的： 赋予开发者极大的灵活性。对于简单的日常请求，可以关闭思考以降低延迟和计算成本；对于复杂的逻辑或代码任务，则开启思考以确保准确性和稳定性

串行强化学习 (Sequential RL Pipeline)

由于不同能力的 RL 优化目标差异巨大，GLM-5 将 RL 拆分为三个专精阶段：

• 推理强化学习 (Reasoning RL)：基于 GRPO 算法并结合 IcePop 技术（移除 KL 正则化以加速收敛）。主要针对数学、科学、代码和工具集成推理（TIR）四个领域进行混合训练。（详见附录“Reasoning RL阶段算法骨架”）
• 智能体强化学习 (Agentic RL)：专门针对长周期、多步骤的 Agent 任务。采用了完全异步和解耦的 RL 框架来最大化 GPU 利用率，并通过 Token-in-Token-out (TITO) 网关和双边重要性采样（Direct Double-sided Importance Sampling）来控制离策略（Off-policy）带来的偏差
• 通用强化学习 (General RL)：目标是人类偏好对齐。采用混合奖励系统（规则奖励、ORM 和 GRM）对基础正确性、情商和任务特定质量进行综合优化

同策略跨阶段蒸馏 (On-Policy Cross-Stage Distillation)

• 多阶段RL痛点：灾难性遗忘。串行 RL 容易导致前期学到的能力（如 Reasoning）在后期（如 General RL）退化
• 为此，GLM-5 将前序各个 RL 阶段产生的 Checkpoint 作为“教师模型”。在最后的蒸馏阶段，当前正在训练的学生模型通过匹配教师模型输出的 Logits 和 Weights，迅速找回在 SFT 和早期 RL 阶段获得的所有能力

符号解析：

• $\hat{A}_{i,t}$：当前词元（Token）的优势值。
• $sg[\dots]$：Stop Gradient（停止梯度）操作。这在工程实现上通常对应 detach()。意思是括号里的计算结果只作为一个常数目标，不需要也不能向教师模型回传梯度（老师的权重是冻结的）
• $\pi_{\theta_{teacher}}^{infer}$：教师模型在给定上下文时，生成这个词元的概率
• $\pi_{\theta}^{train}$：学生模型（当前模型）生成同一个词元的概率

这个公式的逻辑：

• 它计算的是“老师的概率”与“学生的概率”之间的对数比值。
• 如果老师的概率 > 学生的概率：括号内大于 1，取对数后 $\hat{A}_{i,t} > 0$。优势值为正！这意味着系统在鼓励学生：“老师觉得这个词很好，你给的概率太低了，你要提高这个词的生成概率！”
• 如果老师的概率 < 学生的概率：括号内小于 1，取对数后 $\hat{A}_{i,t} < 0$。优势值为负！系统在惩罚学生：“老师不看好这个词，你给的概率却这么高，赶紧降下来！”

架构层面的未来规划

• 目前，教师模型的 Logits（概率）是通过独立的推理引擎去获取的。
• 原文剧透了一个未来的优化方向：计划将推理后端迁移回训练引擎中，并且统一采用 MLA（多潜在注意力）架构中的 MQA（多查询注意力）模式 来进行教师推理。这不仅能进一步减少系统间的通信，还能大幅降低教师模型推理时的 KV Cache 显存占用

Agentic Engineering

核心愿景： 推动大模型从“氛围编程 (Vibe Coding，人类写提示词让AI写代码)”向“智能体工程 (Agentic Engineering，AI像真实工程师一样自主规划、实现、迭代)”的范式转变

完全异步和解耦的强化学习框架

目的：解决长周期任务带来的算力闲置和系统不稳定问题

Agentic RL 阶段需要优化的核心期望目标

符号详细拆解：

• $L(\theta)$：需要优化的目标函数
• $\theta$ 代表当前正在训练的模型参数。
• $\mathbb{E}_{x \sim \mathcal{D}}$：数学期望。表示从智能体训练数据集 $\mathcal{D}$ 中采样出一个具体的任务 $x$（例如：“写一个贪吃蛇游戏” 或 “修复这个 Github Issue”）
• $K$：采样的轨迹（Trace）数量。面对同一个任务 $x$，我们让旧策略模型（$\pi_{old}$）去沙盒环境里独立尝试 $K$ 次，生成 $K$ 种不同的解决路径或交互过程，记为 $\{y_1, ..., y_K\}$。
• $r(x, y_i)$：第 $i$ 条轨迹 $y_i$ 执行完毕后，环境给出的客观奖励得分（Reward）。比如代码测试通过了给 1 分，报错了给 0 分。
• $\bar{r}(x)$：这是这组采样的平均得分（基线 Baseline）。原文定义为 $\bar{r}(x) = \frac{1}{K} \sum_{i=1}^K r(x, y_i)$
• $r(x, y_i) - \bar{r}(x)$：这是整个公式的灵魂，代表相对优势（Advantage）。它不看绝对分数是多少，而是看你比同组的平均水平好多少或差多少

细节：“忽略环境反馈”

只有模型生成的词元参与优化计算，环境的反馈在计算损失时被忽略

在智能体（Agent）任务中，一条完整的轨迹（Trajectory）是“人机交互 / 机机交互”的混合体。 例如：

1. 模型输出：ls -l （查看目录）
2. 环境反馈（终端输出）：total 4, -rw-r--r-- 1 root root 123 index.js
3. 模型思考：我看到有 index.js 文件，接下来我要读取它。
4. 模型输出：cat index.js

在强化学习算梯度时，我们只应该去优化模型自己“大脑”里做出的决定（即步骤 1、3、4）。步骤 2 是终端（Docker 沙盒）吐出来的客观事实，模型无法决定终端输出什么。

因此，GLM-5 在实现 Agentic RL 时，精准地掩码（Mask）掉了所有由环境（Environment）生成的反馈文本，确保梯度只作用于模型自己生成的动作（Action）和思考（Reasoning）上

解耦训练与推理

核心动作：将生成轨迹（Rollout）和计算更新（Training）分离到不同 GPU

痛点：训练-推理偏差（Training-Inference Mismatch）

在大模型分布式RL训练过程中，为了追求极高的训练速度，工程师们把“做题”和“批改作业”这两个步骤给拆开了，结果导致了“时间差”

为什么会产生偏差？因为“同步”太慢了

在最原始的强化学习中，训练是同步的 ：

1. 模型先暂停更新，开始生成文本（Rollout/推理）。
2. 生成完一批数据后，拿到奖励评分。
3. 模型根据评分计算梯度，更新自己的权重参数（Training/训练）。
4. 更新完后，再用新的权重去生成下一批数据

痛点： 智能体任务（比如写代码、操作浏览器）的轨迹非常长。如果采用同步模式，在模型生成这些长文本的过程中，负责计算梯度的 GPU 就会一直闲置干等，造成极其严重的算力浪费

为了最大化 GPU 利用率，GLM-5 采用了**完全异步且解耦的强化学习框架，**系统被物理切分成了两套班子 ：

• 推理引擎： 专门负责源源不断地生成智能体轨迹（做题） 。
• 训练引擎： 专门负责接收数据、计算梯度并更新模型参数（批改作业并自我进化）

为什么这个偏差很致命

PPO 或者 GRPO 这样的强化学习算法，本质上是同策略（On-policy）算法 。它们在数学上有一个严苛的假设：用来评估和更新的数据，必须是由当前最新的模型自己生成的。

如果训练引擎（版本 C）拿到的是版本 A 生成的严重滞后的数据，这在 RL 中被称为离策略（Off-policy）问题 。如果直接用这种数据强行更新，模型就会“精神分裂”，算出极其离谱的梯度，导致训练瞬间崩溃

GLM-5 为解决这一问题采取了多管齐下的策略：

1. 定期同步： 训练引擎每隔 K 步，会强行把最新的权重推送给推理引擎，尽量减少版本代差
2. IcePop 算子拦截（3.2节）： 即 $pop(\cdot)$ 算子。如果算出来 $\pi^{train}$ 和 $\pi^{infer}$ 的偏差比例 $\rho_{i,t}$ 超过了设定的阈值 $\beta$，直接把这条数据的梯度丢弃（设为 0），宁可不学，也不学错的
3. 丢弃陈旧样本（4.1节）： 在生成数据时记录下模型的版本号，如果送到训练引擎时，发现这个数据用的版本太老了（$w^{\prime}-w_{0}>\tau$），直接扔掉

中心化多任务编排器 (Multi-Task Rollout Orchestrator)

通过微服务架构统一管理不同智能体任务（代码、终端、搜索）的生成比例和速度，支持混合训练

智能体工程化痛点：轨迹生成的异构性问题

模型需要同时学习写代码、操作终端、浏览网页等完全不同的任务。每个任务用的工具不同、步骤长短不同、打分（Reward）的规则也完全不同。如果让计算梯度的训练引擎去硬接这些五花八门的数据，系统很快就会崩溃

解决方案：

• 微服务化：每一个智能体任务（比如一个 SWE 软件工程任务，或者一个搜索任务）都变成一个独立的“微服务（Microservice）”。这些任务微服务自己管自己的业务逻辑（怎么调用工具、怎么判断成功与否），然后统一向这个“中心编排器”注册报到
• 任务传回中心编排器的数据，必须被标准化成一种统一的“消息列表 (Message-list)”格式，即对于底层的强化学习训练框架（slime）来说，它无需区分“这是一个浏览器点击动作还是一个终端代码”，它眼里看到的都是统一格式的 Token 序列
• 动态调度与“负载均衡”：不同类型任务执行时间不同，任务编排器会实时监控任务进度，动态控制每种任务的生成比例和速度，保证最终喂给训练引擎的数据是各领域平衡的

Token-In-Token-Out 网关

GLM-5 的异步解耦架构下，“负责生成动作的推理引擎”和“负责算梯度更新权重的训练引擎”是分家的。它们之间需要频繁地传递数据：

传统做法：Text-in-Text-out (文本进，文本出)

• 运作模式：训练引擎把推理引擎当成一个“黑盒（Black box）”。推理引擎在沙盒里做完任务后，把最终生成的人类可读的纯文本（Text）发给训练引擎。然后，训练引擎拿到这段文本，重新进行一次分词（Re-tokenize），把它变回模型能看懂的 Token IDs，再去计算损失和梯度
• 痛点：
  • 重分词误差（Re-tokenization mismatches）：分词器（Tokenizer）是非常敏感的。当你把一段文本重新分词时，空格的处理、大小写的归一化、特殊截断标记的位置，极容易发生微妙的错位。
  • 对齐崩溃（Alignment Corruption）：强化学习的核心是“对具体的动作（Action）打分（Reward）”。如果发生了重分词错位，训练引擎算出来的第 150 个 Token，可能对应的是推理引擎生成时的第 151 个 Token。这会导致动作和奖励（优势值）在时间步上彻底错位——模型该受奖赏的动作被惩罚了，该惩罚的被奖赏了。尤其是在多智能体交错运行、或轨迹被中途截断时，这种错位是灾难性的

GLM-5 的解法：Token-in-Token-out / TITO (词元进，词元出)

• 运作模式：训练引擎直接接收推理引擎底层生成的原生 Token ID 序列（以及相关的元数据 Metadata），并直接用这些 ID 来构建训练轨迹
• 消除重分词误差、消除“Token - 文本 - Token”间转换带来的资源消耗

直接重要性采样

在传统的同步 PPO（近端策略优化）算法中，为了保证模型每次更新不要“步子迈得太大”，它会计算一个重要性采样比（Importance Sampling Ratio）：

$r = \frac{\pi_\theta(a|s)}{\pi_{\theta_{old}}(a|s)}$

这个公式的意思是：当前正在训练的模型（$\pi_\theta$），对比之前生成这段数据时的老模型（$\pi_{\theta_{old}}$），它们对同一个动作给出的概率变化有多大

对GLM-5的痛点：在 GLM-5 的全异步智能体训练中，一个长周期任务可能要在沙盒里跑几十分钟。在这几十分钟里，训练引擎可能已经更新了几十个版本的权重（V1, V2 ... V50）。 如果按照传统公式，为了算准这个比值，系统必须把这 50 个历史版本（Checkpoints）的庞大权重全部存在显存或硬盘里，并在算梯度时把它们调出来重新算一遍概率。对于一个 744B 参数的模型来说，这种存储和计算开销是根本不可能承受的

解决方案：直接复用推理引擎生成时吐出的概率，彻底抛弃追踪历史策略

• $\pi_\theta(a_t|s_t)$：训练引擎（当前最新模型）算出的当前概率
• $\pi_{rollout}(a_t|s_t)$：推理引擎在当时生成这个词（Token）时，顺手记录下来的那个概率（log-probabilities）

双边词元级裁剪 (Double-sided Token-level Clipping)

问题：直接拿 $\pi_{rollout}$ 来算是很简便，但同时引入了巨大的偏差（Off-policy bias），如果这个数据太老了，算出来的梯度可能会让模型崩溃

解决方法：引入“门控/裁剪算子”

• 设定了一个信任区间 $[1 - \epsilon_l, 1 + \epsilon_h]$
• 若重要性比值 $r_t(\theta)$落在区间内（值域接近 1）：说明当前模型和当时生成数据的模型想法差异不大，$f(x)$ 返回 1。保留这个 Token 的梯度，正常更新。
• 若$r_t(\theta)$超出区间（差异极大）：说明这条数据严重过期（严重 Off-policy），$f(x)$ 直接返回 0。一刀切，将该 Token 的梯度硬性掩码（Masked）为 0

最终（直接重要性采样 + 双边词元级裁剪）优化目标：

与IcePop的异同：

• 在 3.2 节（推理 RL）中：因为任务短，系统还是会去算一下“训练引擎眼里的老版本”和“推理引擎眼里的老版本”的差距。
• 在 4.1.2 节（智能体 RL）中：因为任务太长、异步太严重，直接舍弃，连老版本都不算了。只要当前概率和生成时记录的原始概率偏差过大，直接一刀切掉！

一句话概括： 在极度异步的长周期智能体训练中，GLM-5 放弃了复杂的历史版本追踪，直接复用生成时的概率作为比对基准；一旦发现某个 Token 因为版本滞后导致概率偏差过大，就直接将其梯度抹杀为 0。这是一种用“部分数据报废”来换取“系统极致稳定”的顶级工程妥协

智能体环境扩展（Environment Scaling for Agents）

核心痛点： 强化学习（RL）的燃料是“反馈（Reward）”。如果让模型做数学题，答案对错一目了然；但如果让模型“修一个软件 Bug”或“配置一台服务器”，怎么给它自动打分？

解决方案： 构建海量的、绝对真实且结果可验证的隔离沙盒环境

软件工程环境 (Software Engineering, 简称 SWE)

目标： 教 AI 像真实的高级程序员一样，接手一个庞大的开源项目并修复里面的 Bug

• 数据来源的真实性：团队没有使用玩具代码，而是直接去 GitHub 上抓取了真实的 Issue（问题报告）和 Pull Request（修复提交）。
• 自动化环境构建： 现实中配置一个十年前的旧项目环境极其痛苦（依赖冲突、版本不兼容）。GLM-5 团队利用了一套类似 RepoLaunch 的自动化框架，配合 LLM 自动分析项目的依赖关系，硬生生打包出了数万个 Docker 容器环境。
• 客观打分机制 (Reward 来源)： 怎样才算修好了 Bug？团队从真实的 PR 中提取了：
  1. F2P (Fail-to-Pass) 测试用例：修复前运行失败，修复后必须通过的测试。
  2. P2P (Pass-to-Pass) 测试用例：原本就正常的测试，修复后绝对不能被破坏。 结果： 团队成功构建了超过 10,000 个真实世界的 SWE 训练环境，覆盖了 Python、Java、C++ 等 9 种主流编程语言。模型在里面写完代码，只要通过 F2P 和 P2P 测试，就获得满分奖励！

终端环境 (Terminal Environments)

目标： 教 AI 熟练使用 Linux 终端，完成系统运维、数据库操作、文件处理等极其繁杂的 IT 任务

1. 自上而下（基于种子数据合成）：
   1. 让强大的 LLM 扮演“出题人”，进行头脑风暴，想出各种刁钻的运维任务（比如“在 Nginx 里配置一个反向代理并查杀占用 80 端口的木马”）。
   2. 让 LLM 写出这些任务的“环境初始化脚本”和“自动验证评测脚本”。
   3. 放入真实 Docker 运行，如果评测脚本有 Bug，再让 LLM 自己去迭代修复（自我完善）。
2. 自下而上（基于 Web 语料合成）：
   1. 爬虫去抓取海量的优质技术博客、StackOverflow 教程。
   2. 让 LLM 从这些真实教程中提取出“任务目标”和“正确的终端命令”。
   3. 将这些命令放到沙盒里执行，作为标准答案来验证。 结果： 打造了一个无所不包的终端训练场，模型在里面可以肆意敲击 Shell 命令，错了系统会自动报错重来

高难度多跳搜索任务 (High-difficulty Multi-hop Search)

目标： 教 AI 像超级侦探一样，在浩瀚的互联网网页中进行复杂的资料收集、过滤和推理

什么是高难度多跳任务？

大模型无法直接根据预训练知识回答，必须借助搜索引擎多次搜索完成回答

步骤：

1. 构建 Web 知识图谱 (WKG) 解析数百万个高质量网页，提取出实体（人名、地名、事件）和它们之间的关系，连成一张巨大的网
2. 图谱寻路生成问题 在图谱上找相隔很远（需要跳跃多次）的两个节点。比如：“A 电影的导演的妻子的出生地的现任市长是谁？” 这种题，大模型绝对不可能直接背下来。
3. 残酷的“三级过滤”系统（只留最硬核的题目）：
   • 常识过滤：不用搜索引擎就能答对的题？删掉。
   • 捷径过滤：搜索引擎一搜第一页标题就直接给出答案的题？删掉（体现不出多轮浏览网页的深度）
   • 唯一性过滤：答案有歧义、不唯一的题？删掉。 结果： 留下的全都是必须经过 3~5 轮深度搜索、点击多个网页、综合多方信息才能得出唯一客观结论的终极侦探题

搜索任务痛点：HTML 的“信息轰炸”‘

AI 使用搜索引擎每点击一个网页，终端返回的不是人类看到的美观排版，而是极其冗长、充满无用标签的 HTML 源码。搜索一个稍微复杂点的问题（比如多跳搜索），点开三四个网页，几万个 Token 的上下文窗口瞬间就被塞满了

解决方法：Hierarchical Context Management, 混合分层上下文管理

1. Keep-recent-k（保留最近，折叠过去）：
   • 最近访问的 k 个网页：保留完整的 HTML 源码，方便模型精细阅读当前内容。
   • 更早之前的网页：把它们极其冗长的 HTML 代码直接“折叠（Truncate）”或者“总结”，只留下简短的摘要或核心线索。
2. 兜底的 Discard-all（极限清空）：
   • 在采取折叠措施后，总长度依然逼近了硬件极限
   • 触发清空机制，继续清空原始网页代码，保留核心线索和任务进度，不会完全失忆

面对“网页代码太长撑爆模型记忆”问题时，尝试的不同策略带来的训练效果差异

• Discard-all：当模型不断点击网页，HTML 代码越攒越多，一旦逼近上下文长度极限（比如 32K），系统就会把前面的历史记录全部扔掉，只保留当前页面的信息
• Fewest-step：鼓励模型“用最少步数找到答案”的奖励策略
• Pass@K：只要在 K 次尝试内找到正确答案就算成功
• HCM：混合分层上下文管理

幻灯片生成（Slide Generation）

这是一个非常典型的将复杂排版与代码生成结合的智能体工程案例，研发团队专门构建了一个“自我改进（self-improving）”的流水线来训练专门的幻灯片生成专家模型

第一阶段：制定三套“打分标准”（多级奖励机制）

为了让模型知道什么是“好”的幻灯片，研发团队为强化学习（RL）阶段设计了三个层级的考核标准 ：

• 第一级：看“底层代码”写得对不对（静态标记属性）
  • 这就好比检查设计师的草稿 。系统会直接扫描模型写出来的 HTML 代码，看排版、颜色、字号、间距的代码是否符合设计规范 。
  • 同时，系统会检查模型有没有“胡编乱造”（幻觉图像）或者在一页里塞了重复的图片 。这能保证代码从语法上看是合理、清晰且可读的 。
• 第二级：看“实际渲染”有没有穿帮（运行时渲染属性）
  • 代码写得对，不代表显示出来好看。系统会把代码真正放到浏览器里“跑”一下（渲染出来），去测量真实的长宽、边框位置等几何数据 。
  • 应对模型“作弊”（Reward Hacking）： AI 经常会耍小聪明 。比如，内容写得太多溢出了边框，它为了不扣分，直接用代码把超出的部分“隐藏”掉（硬截断）；或者为了凑满页面，把行距拉得极其夸张 。 团队通过抓取真实的渲染数据，堵住了这些作弊漏洞，逼迫模型真正去优化布局 。
• 第三级：看“整体视觉”美不美（视觉感知特征）
  • 这是最高级的审美考核 。系统会像人类一样去评估最终的画面，比如看看有没有大片极其突兀的“留白” 。如果有，说明构图不平衡，就会给出负面反馈 。

第二阶段：有策略地“刷题”（训练策略）

有了标准后，模型开始大量练习，但团队使用了一些技巧让它学得更好：

• 跳过简单题（动态采样）： 系统会故意扔掉那些结构太简单的页面，强迫模型把算力集中在攻克“高难度、复杂排版”的幻灯片上，以此提升它的抗压能力 。

第三阶段：把优秀作品“编进教材”（数据提纯）

模型在强化学习（RL）阶段练就了本事后，团队希望能把这些经验固化下来，变成高质量的训练数据再次喂给模型（这叫拒绝采样微调） ：

• 优中选优（拒绝采样）： 让模型面对一个任务生成好几个版本的幻灯片，用前面那套打分标准进行严格过滤（查代码有效性、内容多样性等），最后只挑出最好的一份（Best-of-N）留作未来的训练数据 。
• 局部修改（基于掩码的修正）： 假设模型做了一套 10 页的极其精美的幻灯片，但只有第 3 页排版崩了 。如果直接把整套扔掉太浪费了 。所以系统会自动把那页坏的“遮住（Mask）”，把剩下 9 页完美的数据保留下来，极大提高了学习效率

Evaluation 评估

真实世界智能体工程评测：CC-Bench-V2

传统的静态测试集（如 SWE-bench）通常只测试单次提交的孤立修改 ，为了评估模型在真实工作流中的表现，研发团队构建了全自动的内部测试集 CC-Bench-V2。

完全移除人类标注，通过集成 Claude Code 等智能体框架、单元测试以及“Agent-as-a-Judge”技术，实现了全链路的自动化评估

1. 前端评估：Agent-as-a-Judge (智能体裁判)

对前端代码而言，传统对静态测试仅跑通代码是不够的，其正确性很大程度上是视觉和交互性的，很多 Bug 只有当用户真正去点击按钮或调整窗口大小时才会暴露出来

Agent-as-a-Judge相当于给系统配备了一个虚拟的 QA 测试工程师，让它去真实模拟人类用户的操作来验收前端代码

核心运作机制

• 静态验证（Static Verification）：首先把模型生成的代码放进 Docker 容器里进行构建，看看代码能不能跑起来，这一步用来验证静态的正确性 。
• 交互式裁判（Agent-as-a-Judge）：如果代码构建成功，任务就会移交给一个自主的“裁判智能体” 。这个裁判由 Claude Sonnet 4.5 驱动，并且配备了 Playwright（一个网页自动化测试工具）和 Bash 工具 。它会在一个闭环周期中，像真人一样去阅读代码、点击页面、截图并分析结果，最终给出“通过”或“失败”的裁决

**1. ****Query and Checkitem（输入任务与检查项）**测试的起点。系统会输入用户的原始需求（例如：Query: Create a website ...）以及具体的测试验收标准（例如：Check: Test the button ...）

2. Build and Launch（构建与启动阶段）

这部分对应静态验证。系统会按顺序执行以下自动化步骤：

• 识别项目类型（Identify project type）
• 构建项目（Build the project）
• 启动项目（Start the project）
• 计算构建成功率（Calculate BSR）。只有这一步成功了，才会进入右侧的智能体裁判环节

**3. Agent-as-a-Judge（智能体裁判闭环）**图中央展示了核心的闭环测试过程。这个由多模态大模型（Multimodal LM）驱动的智能体，会不断循环执行以下动作来验证“Checkitem” ：

• Analyze & Plan（分析与计划）：智能体首先思考应该如何测试这个功能 。

• Read Code (Tool: "read")（阅读代码）：使用读取工具查看底层的源代码 。

• Navigate & Screenshot (Tool: "Playwright")（导航与截图）：使用 Playwright 打开生成的网页并进行视觉截图 。

• Click & Screenshot (Tool: "Playwright")（点击与截图）：这是最关键的交互环节。智能体模拟用户的鼠标去点击页面上的元素，并截取交互后的新画面 。

• Observe & Analyze（观察与分析）：多模态模型观察截图前后的变化，分析功能是否正常运作

右侧的最终结果判定（MISMATCH!）

图的右侧给出了一个非常直观的失败案例：模型生成了一个“幸运大转盘（Fortune Wheel）”的网页。

• 智能体在模拟点击了“SPIN NOW!”按钮后 ，观察到转盘停下的位置和弹出的奖品结果。
• 智能体发现了问题（MISMATCH!）：页面显示的指针位置和实际给出的奖品名称对不上 。
• 因此，智能体给出了最终裁决：FAIL（失败），并给出了明确的理由：“critical logic error: point & prize name does not match（严重逻辑错误：指针与奖品名称不匹配）”

2. 后端评估：Docker 容器内的沙盒单元测试

• 真实环境还原：任务在 Docker 容器内运行，这些容器完全基于项目实际的构建环境进行初始化 。
• 严苛的自动判卷：每个任务都配备了 5-10 个由人类编写的高质量单元测试，覆盖了功能正确性和边缘情况 。评估标准是严苛的 Pass@1，即模型必须一次性通过所有单元测试才算解决该任务 。

---

3. 长周期评估：自动化的代码库探索与链式回归测试

• 在大型仓库探索任务中，系统会自动评估模型能否在不提供具体文件名的情况下，仅凭业务语义描述就成功读取到目标源文件 。
• 在多步链式任务中，系统会自动构建 Docker 环境，并在模型完成每一步修改后，自动应用相应的测试补丁 。它不仅测试当前任务是否通过，还会跑全量测试来验证前面的修改有没有被“改坏”（回归测试）

附录

Reasoning RL阶段算法骨架

GLM-5 在推理强化学习（Reasoning RL）阶段的算法骨架，是建立在 GRPO (Group Relative Policy Optimization) 的基础之上，并巧妙地融入了 IcePop 技术来解决分布式大模型训练中极其头疼的“训练-推理偏差（training-inference mismatch）”问题

目标优化函数：整个强化学习阶段，模型试图去最小化下面这个庞大的损失函数

• 本质上是一个带有“异步安全阀”的 PPO-GRPO 混合损失函数
• 文字描述：通过最大化重要性采样比（$r_{i,t}$）与组内相对优势（$\hat{A}_{i,t}$）的乘积，来鼓励模型生成比同组其他轨迹更好的回答，并利用 clip 函数严格限制单次策略更新的幅度以防止模型崩溃。其最核心的创新在于外层嵌套的 pop 截断算子：它充当了系统级的数据安检员，一旦检测到由于分布式异步架构导致某条数据的“训练-推理版本偏差”超出安全阈值，就会直接将该词元的梯度强行抹零，从而在追求极致并发生成速度的同时，死守了强化学习算法的数据一致性底线

符号解析：

• $\mathcal{L}(\theta)$：模型需要优化的目标损失（Loss）。
• $\theta$：当前正在训练的模型的参数（也就是神经网络的权重）。
• $\mathbb{E}$：数学期望，表示在特定数据分布下求平均。
• $x\sim\mathcal{D}$：$x$ 代表从训练集数据分布 $\mathcal{D}$ 中采样出的一个提示词（Prompt）
• $\{y_{i}\}_{i=1}^{G}\sim\pi_{\theta_{old}}^{infer}(\cdot|x)$：在给定提示词 $x$ 的情况下，使用旧的推理策略 $\pi_{\theta_{old}}^{infer}$，生成一个包含 $G$ 个不同回答（轨迹）的集合，分别记为 $y_1, y_2, ..., y_G$
• $G$：组大小（Group Size），即对于同一个提示词，模型要生成多少个不同的回答
• $|y_{i}|$：第 $i$ 个回答 $y_i$ 所包含的词元（Token）总数
• $t$：时间步，表示回答中的第 $t$ 个 Token
• $\min(\dots, \dots)$：取括号内两个值的最小值，这是典型的 PPO 算法中为了限制策略更新幅度而采用的截断机制

训练-推理偏差比

在大规模分布式 RL 中，负责生成回答的“推理引擎”和负责计算梯度的“训练引擎”是分离的 。因为存在延迟，训练时计算的概率分布，和生成时实际发生的概率分布会有差异，即偏差（Mismatch）

符号解析：

• $\pi_{\theta_{old}}^{train}$：旧的训练策略评估出的概率。即训练引擎在复盘时，认为在给定上下文 $y_{i,<t}$ 下，生成当前 Token $y_{i,t}$ 的概率
• $\pi_{\theta_{old}}^{infer}$：旧的推理策略生成的实际概率。即推理引擎在实际生成数据时，采用的真实概率
• $\rho_{i,t}$：两者的比值。比值越偏离 1，说明异步导致的偏差越严重

截断算子 (IcePop 的核心)：防止偏差过大的“脏数据”搞崩训练

• $\beta$：一个控制容忍度的超参数 。
• 含义：如果偏差比 $\rho_{i,t}$ 落在了一个可以接受的安全区间 $[1/\beta, \beta]$ 内，就保留它作为权重系数；一旦偏差过大（意味着这条数据严重偏离了当前策略），直接返回 0。返回 0 就意味着在总的 Loss 函数中，这个 Token 的梯度会被彻底抹去，不再参与权重更新。这是一种强有力的自我保护机制

PPO 风格的重要性比值 $r_{i,t}$和组内归一化的优势函数 $\hat{A}_{i,t}$：

符号解析：

• $\pi_{\theta}^{train}$：当前最新的训练策略计算出的概率
• $r_{i,t}$：新策略概率与旧策略概率的比值。用于评估“更新步伐”迈得有多大
• $R_i$：模型生成的第 $i$ 个回答，通过奖励模型或规则判定后得到的最终得分
• $mean(\dots)$ 和 $std(\dots)$：对于同一个提示词生成的 $G$ 个回答，计算它们得分的平均值和标准差
• $\hat{A}_{i,t}$：优势函数。这是 GRPO 的精髓，它不需要额外的 Critic 模型来估计基线，而是直接在同一组（Group）的 $G$ 个回答中“矬子里拔将军”。如果第 $i$ 个回答的得分高于这组的平均分，优势 $\hat{A}_{i,t}$ 就是正的（鼓励这个回答的生成路径）；反之则是负的（抑制这个回答的生成路径）

DSA在RL中的工程化问题

核心：如何在不增加海量通信成本的前提下，保证训练引擎和推理引擎在处理“稀疏性”时的高度一致

前置知识：Self-Attention计算、DeepSeek Sparse Attetion原理

核心挑战：DSA 的动态索引与一致性。

• DSA 相比于 MLA，多了一个“索引器（Indexer）” 。它的工作是为每个 token 检索出最相关的 Top-k 个 Key-Value 键值对，然后仅在这个稀疏子集上计算注意力
• 在RL过程中，推理引擎负责生成大量文本轨迹，训练引擎拿到生成的轨迹和评分后，负责计算梯度并更新模型的权重，它们俩各自运行着一套DSA机制，即各自有一个索引器
• 关键在于，推理引擎和训练引擎必须保持步调一致，即要求两个索引器筛选出来的Top-k个kv键值对是一样的。这样才能保证训练引擎在复盘（对推理引擎传过来的整条轨迹（Trajectory）做一次完整的前向传播）时，看到的上下文和推理引擎生成时看到的上下文完全一致。只有基于相同上下文算出的概率，才能用于正确的强化学习梯度更新

解决方案：

• 直接将推理引擎的索引器算出来的Top-k个索引传给训练引擎
  • 每个Token筛选2048个kv键值对，将消耗巨量通信带宽
  • 但是在MoE中，可以这么做，因为选出的专家数很小
• 锁定索引器参数 + 采用完全确定性的 Top-k 算子
  • 并行计算与浮点数精度问题：像 SGLang 或 TileLang 中高度优化的 CUDA Top-k 算子，为了追求极致的并行速度，会让成千上万个线程同时处理数据 。在浮点数运算中，加法是不满足结合律的（即 (A+B)+C 可能不等于 A+(B+C)，因为会产生微小的舍入误差）。由于 GPU 线程执行顺序和原子操作（Atomic Add）的先后顺序是不可预测的，导致每次计算出的打分（Scores）在极其微小的精度上会有波动
  • 临界打破（Tie-breaking）的不确定性： 当我们需要选出 Top-2048 时，如果第 2048 名和第 2049 名的得分极其接近，或者完全一样。这种微小的浮点数波动，或者非确定性算子内部随意的并列排序机制，就会导致推理引擎选了第 2048 名，而训练引擎选了第 2049 名
  • 因此GLM-5团队强制弃用了那些速度快但非确定性的 CUDA 算子，转而使用了 PyTorch 原生的 torch.topk。原生 torch.topk 虽然执行速度略慢，但它是严格确定性的算子 。这意味着，只要输入张量和参数一致，无论在哪个 GPU 上执行多少次，它底层排序和处理并列情况的逻辑是完全固定的，输出的 2048 个索引绝对一模一样