GLM-5.1：面向长程任务
GLM-5.1：面向长程任务
GLM-5.1 是智谱面向智能体工程推出的下一代旗舰模型，其核心突破不仅在于 SWE-Bench Pro 等基准测试上的领先成绩，更在于它重新定义了模型在长时间跨度内保持有效性的能力。此前的大模型——包括 GLM-5 本身——往往在初步取得进展后迅速陷入平台期，即便给予更多时间也无法持续改进。GLM-5.1 的设计目标恰恰是打破这一瓶颈。文章通过三个反馈结构化程度逐级递减的任务来展示这一能力：从 600 轮迭代将向量数据库 QPS 优化至此前最佳结果六倍的数值优化任务，到 1000 余轮工具调用实现 3.6 倍 GPU 内核加速比的机器学习工作负载，再到完全没有量化指标的八小时 Linux 桌面环境构建。这些实验揭示了一个关键洞见：模型在长程任务中表现出的判断力、策略迭代能力和持续探索意愿，或许比单次任务的峰值性能更能定义下一代智能体的能力边界。
GLM-5.1 是我们用于智能体工程（agentic engineering）的下一代旗舰模型，其编程能力较前代大幅增强。在 SWE-Bench Pro 上取得了最先进水准，并在 NL2Repo（仓库生成）和 Terminal-Bench 2.0（真实终端任务）上以显著优势领先 GLM-5。
复杂软件工程任务
SWE-Bench Pro
58.4
55.1
57.7
57.3
54.2
GLM-5.1
GLM-5
GPT-5.4
Opus 4.6
Gemini 3.1 Pro
GLM-5.1 在复杂软件工程任务上达到了最先进水平。
但最有意义的跃进并不仅限于首轮表现。之前的模型——包括 GLM-5——往往过早耗尽了招数：它们会先运用熟悉的技术快速取得初步进展，随后便陷入平台期。给它们更多时间也无济于事。
相比之下，GLM-5.1 的设计目标是在更长的时间跨度上保持智能体任务的有效性。我们发现，该模型能以更优的判断力处理模糊问题，并在更长时间的会话中保持高产。它能拆解复杂问题、运行实验、读取结果，并以真正的精度定位障碍。通过反复审视自身推理、不断修正策略，GLM-5.1 能在数百轮对话和数千次工具调用中持续优化。运行时间越长，结果越优。
我们通过三个反馈结构化程度逐级递减的任务来展示这一点：一个由单一数值指标评分的向量搜索优化问题、一个按问题分别测量加速比的 GPU 内核基准测试，以及一个完全开放式的 Web 应用构建——其中没有任何度量指标，全凭模型自身判断下一步该改进什么。
场景一：600 轮迭代优化向量数据库
VectorDBBench 是一个开源编程挑战，评估模型构建高性能数据库以执行近似最近邻搜索（approximate nearest neighbor search）的能力。模型会获得一个 Rust 骨架代码，包含 HTTP API 端点和空的实现桩（stub），然后通过基于工具调用的智能体来读写文件、编译、测试和性能分析——所有这些都在 50 轮工具调用的预算内完成。最终结果在 SIFT-1M 数据集上评测：在 Recall ≥ 95% 的约束下，按 QPS 对模型排序。在该设置下的最佳历史纪录为 3,547 QPS，由 Claude Opus 4.6 取得。
一个自然而然的问题是：这 50 轮预算是否成了瓶颈。我们将评测重构为一个外层优化循环，使用 Claude Code 框架：在每次迭代中，模型可以使用任意数量的工具调用来编辑代码、编译、测试和性能分析，然后提交新版本接受基准测试。模型自主决定何时提交以及下一步该尝试什么。
GLM-5.1 在 50 次或 100 次提交后并未进入平台期，而是在 600 多次迭代、6,000 多次工具调用中持续发现有意义的改进，最终达到 21.5k QPS——大约是单次 50 轮会话中最佳结果的 6 倍。其优化轨迹呈现出特征的阶梯模式：在固定策略下的渐进调优期，与改变性能前沿的结构性变革交替出现。
两次转变可以说明这一模式。在迭代 90 附近，模型从全量扫描切换为 IVF 聚类中心探测加 f16 向量压缩，QPS 跃升至 6.4k。在迭代 240 附近，它引入了一个两阶段流水线——u8 预评分后接 f16 重排序——达到 13.4k QPS。在整个运行过程中共发生了六次此类结构性转变，每次均由模型在分析自身基准测试日志、识别当前瓶颈后主动发起。图中红色叉号标记了 Recall 低于 95% 的迭代轮次——这些点集中在每次重大转变前后，模型在探索新方向时会暂时突破约束，随后再调整恢复。
场景二：1,000+ 轮优化机器学习工作负载
KernelBench 评估模型能否将参考 PyTorch 实现转化为一个输出相同但速度更快的 GPU 内核。该基准测试分为三个级别，优化范围和系统复杂度逐步递增：Level 1 覆盖单算子（single operator），Level 2 覆盖融合算子序列（fused operator sequences），Level 3 覆盖 MobileNet、VGG、MiniGPT、Mamba 等完整架构的端到端全模型优化，共 50 个问题。作为参考，默认设置下的 torch.compile 在这些问题上的加速比为 1.15×；使用 max-autotune 时为 1.49×。我们在 Level 3 上运行了四个模型，报告所有 50 个问题的几何平均加速比随工具调用轮次的变化情况。
这些轨迹揭示了长程优化行为上的差异。GLM-5 初期提升很快，但较早进入平台期。Claude Opus 4.5 持续得更久一些，但其增益在后期也逐渐收窄。GLM-5.1 将这一前沿推得更远，实现了 3.6× 的加速比，并在运行中始终保持着进展。虽然其改进速率同样随时间放缓，但它能在远长于 GLM-5 的时间跨度内维持有效的优化。Claude Opus 4.6 在此设置下仍是最强模型，最终达到 4.2× 的加速比，且在结束时仍显示出上升空间。
场景三：八小时构建 Linux 桌面环境
前两个场景都有明确的数值目标——QPS、加速比——模型可以据此进行基准测试。网站生成（website generation）本质上是更主观的任务：给定自然语言提示，生成一个可运行的 Web 应用。这里没有单一的优化指标；什么算是"好"取决于完整度、视觉精致度和交互质量。
我们用一个刻意设定的高难度提示来测试：构建一个 Linux 风格的桌面环境，以 Web 应用形式呈现。没有起始代码（starter code），没有设计稿（design mockups），没有中间指导。在单次运行中，大多数模型——包括 GLM 的早期版本——很快就放弃了：它们生成一个带有静态任务栏和一两个占位窗口的基本骨架，然后宣布任务完成。模型没有机制可以退一步审视并发现遗漏了什么。
我们用一个简单的框架来包装 GLM-5.1，改变了这一点：每轮执行之后，模型审视自己的输出，识别可以改进的地方——缺失的功能、粗糙的样式、有问题的交互——然后继续。这个循环持续运行了 8 小时，效果差异显著。
GLM-5.1 是我们面向智能体工程（agentic engineering）的下一代旗舰模型，编码能力相比前代显著提升。它在 SWE-Bench Pro 上达到业界领先水平，并在 NL2Repo（代码仓库生成）和 Terminal-Bench 2.0（真实终端任务）上大幅领先 GLM-5。
早期阶段，GLM-5.1 生成的是带有任务栏和简单窗口的基本布局——与短时会话的输出相似。但它并未止步于此。随着运行持续，系统逐步丰满起来：文件浏览器、终端、文本编辑器、系统监视器、计算器、游戏——每一个新增功能都整合到统一的 UI 中，而非事后附加。样式更加精致，交互更加流畅，边界情况得到处理。最终，结果是一个完整的、视觉一致的、运行在浏览器中的桌面环境——这是一个具体例证，展示了当模型拥有足够的时间和能力持续精进时，什么样的成果成为可能。
在所有三个设置中，关键变量不仅仅是运行时长，而是额外的运行时间是否仍然有用。GLM-5.1 将这一有效优化窗口显著扩展到 GLM-5 之上，而 KernelBench 等任务上仍存在的差距表明，长程优化（long-horizon optimization）仍然是一个有待探索的前沿。我们仍面临重大挑战：在增量调优不再奏效时更早地跳出局部最优，在跨越数千次工具调用的执行轨迹（execution traces）上保持连贯性，以及——或许最重要的是——为那些没有数值指标可供优化的任务发展可靠的自我评估（self-evaluation）能力。GLM-5.1 是我们在这条道路上的第一步，我们将继续在这些方向上推进。
| 基准测试 | GLM-5.1 | GLM-5 | Qwen3.6-Plus | MiniMax M2.7 | DeepSeek-V3.2 | Kimi K2.5 | Claude Opus 4.6 | Gemini 3.1 Pro | GPT-5.4 |
|---|---|---|---|---|---|---|---|---|---|
| 推理 | |||||||||
| HLE | 31.0 | 30.5 | 28.8 | 28.0 | 25.1 | 31.5 | 36.7 | 45.0 | 39.8 |
HLE w/ Tools | 52.3 | 50.4 | 50.6 | - | 40.8 | 51.8 | 53.1* | 51.4* | 52.1* |
| AIME 2026 | 95.3 | 95.4 | 95.1 | 89.8 | 95.1 | 94.5 | 95.6 | 98.2 | 98.7 |
| HMMT Nov. 2025 | 94.0 | 96.9 | 94.6 | 81.0 | 90.2 | 91.1 | 96.3 | 94.8 | 95.8 |
| HMMT Feb. 2026 | 82.6 | 82.8 | 87.8 | 72.7 | 79.9 | 81.3 | 84.3 | 87.3 | 91.8 |
| IMOAnswerBench | 83.8 | 82.5 | 83.8 | 66.3 | 78.3 | 81.8 | 75.3 | 81.0 | 91.4 |
| GPQA-Diamond | 86.2 | 86.0 | 90.4 | 87.0 | 82.4 | 87.6 | 91.3 | 94.3 | 92.0 |
| 编程 | |||||||||
| SWE-Bench Pro | 58.4 | 55.1 | 56.6 | 56.2 | - | 53.8 | 57.3 | 54.2 | 57.7 |
| NL2Repo | 42.7 | 35.9 | 37.9 | 39.8 | - | 32.0 | 49.8 | 33.4 | 41.3 |
Terminal-Bench 2.0 Terminus-2 | 63.5 | 56.2 | 61.6 | - | 39.3 | 50.8 | 65.4 | 68.5 | - |
Terminal-Bench 2.0 最佳自报告框架 | 69.0 (Claude Code) | 56.2 (Claude Code) | - | 57.0 (Claude Code) | 46.4 (Claude Code) | - | - | - | 75.1 (Codex) |
| CyberGym | 68.7 | 48.3 | - | - | 17.3 | 41.3 | 66.6 | 38.8 | 66.3 |
| 智能体 | |||||||||
| BrowseComp | 68.0 | 62.0 | - | - | 51.4 | 60.6 | - | - | - |
BrowseComp w/ Context Manage | 79.3 | 75.9 | - | - | 67.6 | 74.9 | 84.0 | 85.9 | 82.7 |
| τ³-Bench | 70.6 | 69.2 | 70.7 | 67.6 | 69.2 | 66.0 | 72.4 | 67.1 | 72.9 |
MCP-Atlas Public Set | 71.8 | 69.2 | 74.1 | 48.8 | 62.2 | 63.8 | 73.8 | 69.2 | 67.2 |
| Tool-Decathlon | 40.7 | 38.0 | 39.8 | 46.3 | 35.2 | 27.8 | 47.2 | 48.8 | 54.6 |
| Vending Bench 2 | $5,634.41 | $4,432.12 | $5,114.87 | - | $1,034.00 | $1,198.46 | $8,017.59 | $911.21 | $6,144.18 |
GLM-5.1 以 MIT 许可证（MIT License）开源发布。GLM-5.1 也可在开发者平台 api.z.ai 和 BigModel.cn 上使用，并与 Claude Code 和 OpenClaw 兼容。
GLM-5.1 快速上手
在 GLM Coding Plan 中使用 GLM-5.1
在您喜爱的编码智能体中尝试 GLM-5.1——Claude Code、OpenCode、Kilo Code、Roo Code、Cline、Droid 等。https://docs.z.ai/devpack/overview
面向 GLM Coding Plan 订阅用户： 我们正在向所有 Coding Plan 用户推送 GLM-5.1。您现在即可通过将模型名称更新为 "GLM-5.1"（例如在 Claude Code 的 ~/.claude/settings.json 中）来启用 GLM-5.1。作为我们最强大的模型，GLM-5.1 在高峰时段消耗 3× 配额，在非高峰时段消耗 2× 配额。作为限时推广活动（持续至四月底），非高峰时段使用按 1× 计费。（高峰时段为每日 14:00–18:00 UTC+8（北京时间））
偏好图形界面？我们提供 Z Code——一个界面，多个智能体，协同工作。通过 SSH 在远程机器上开发，或从手机上启动任务，稍后再回来查看。
现在开始构建：https://z.ai/subscribe
在 Z.ai 上与 GLM-5.1 对话
GLM-5.1 将在未来几天内登陆 Z.ai。
本地部署 GLM-5.1
GLM-5.1 的模型权重已在 HuggingFace 和 ModelScope 上公开发布。对于本地部署，GLM-5.1 支持 vLLM 和 SGLang 等推理框架。完整的部署说明请参见官方 GitHub 仓库。
脚注
-
Humanity's Last Exam (HLE) 及其他推理任务：我们使用最大生成长度 163,840 个 token 进行评估（
temperature=1.0, top_p=0.95, max_new_tokens=163840）。默认情况下，我们报告纯文本子集的结果；标有 * 的结果来自完整集。我们使用 GPT-5.2（medium）作为评判模型（judge model）。对于带工具的 HLE（HLE-with-tools），我们使用最大上下文长度 202,752 个 token。 -
SWE-Bench Pro：我们使用 OpenHands 配合定制指令提示（instruction prompt）运行 SWE-Bench Pro 测试套件。设置：
temperature=1、top_p=0.95、max_new_tokens=32768，上下文窗口为 200K。 -
NL2Repo：我们在 200K 上下文下以
temperature=1.0、top_p=1.0、max_new_tokens=32768评估 NL2Repo。为防止作弊，我们使用基于规则的预检测（rule-based pre-detection）识别恶意命令（例如未授权的 pip 或 curl 操作），随后进行基于模型的判断。恶意行为会被立即拦截。 -
BrowseComp：不使用上下文管理时，我们保留最近 5 轮对话的详细信息。使用上下文管理时，我们采用与 GLM-5 和 DeepSeek-v3.2 相同的全部丢弃策略（discard-all strategy）。
-
Terminal-Bench 2.0（Terminus 2）：我们使用 Terminus 框架进行评估，设置
timeout=3h, temperature=1.0, top_p=1.0, max_new_tokens=8192，上下文窗口为 200K。资源限制为 16 个 CPU 和 32 GB 内存。 -
Terminal-Bench 2.0（Claude Code）：我们在 Claude Code 2.1.69（思考模式）中以
temperature=1.0, top_p=0.95, max_new_tokens=131072进行评估。我们通过透明代理（transparent proxy）将 max_new_tokens 覆盖为 128K，绕过 64K CLI 上限，以恢复CLAUDE_CODE_MAX_OUTPUT_TOKENS的可配置性。我们移除了挂钟时间限制（wall-clock time limits），同时保留了每项任务的 CPU 和内存约束。我们修复了 Claude Code 引入的环境问题。得分为 5 次运行的平均值。 -
CyberGym：我们在 Claude Code 2.1.56（思考模式，无网络工具）中以
temperature=1.0, top_p=1.0, max_new_tokens=32000评估 GLM-5.1；在 Gemini CLI 0.36.0 中以（默认 temperature、top_p 和max_new_tokens=32000）评估 Gemini 3.1 Pro；在 Codex CLI 0.118.0 中以（默认 temperature、top_p 和高推理努力度）评估 GPT-5.4。所有评估每项任务超时时间为 250 分钟，结果为 1,507 个任务的单次运行 Pass@1。在 Gemini 3.1 Pro 和 GPT-5.4 的评估中，两个模型有时会将任务识别为存在安全风险并拒绝继续执行，这可能会降低它们的得分。 -
MCP-Atlas：所有模型均在思考模式下评估，使用 500 个任务的公开子集，每项任务超时 10 分钟。我们使用 Gemini-3.0-Pro 作为评估的评判模型。
-
τ³-bench：在所有领域的用户模拟器（user simulator）中添加了一条额外提示，以避免因用户过早结束交互而导致的失败模式。银行领域使用基于终端的智能体搜索检索（terminal_use）。用户模拟器：GPT-5.2（reasoning_effort: low），4 次试验。
-
Vending Bench 2：运行由 Andon Labs 独立完成。
-
KernelBench Level 3：50 个问题各自在隔离的 Docker 容器中运行，配备一块 H100 GPU，限制 1200 次工具调用轮次。正确性（
atol=rtol=1e-4）和性能分别在独立的 CUDA 上下文中与 PyTorch eager 基线进行比较。所有解决方案均由 Claude Opus 4.6（最大努力）和 GPT-5.4（xhigh）独立审核是否存在基准测试利用行为：每次审核都验证优化是否未利用基准测试特有的行为、是否适用于任意新输入、以及是否将所有计算保持在默认 CUDA 流上。采用两次审核中较低的速度提升值，并设置 50 倍硬上限以限制异常值的影响。
术语表
| 原文 | 中文 |
|---|---|
| agentic engineering | 智能体工程 |
| approximate nearest neighbor search | 近似最近邻搜索 |
| context management | 上下文管理 |
| design mockups | 设计稿 |
| discard-all strategy | 全部丢弃策略 |
| execution traces | 执行轨迹 |
| fused operator sequences | 融合算子序列 |
| instruction prompt | 指令提示 |
| judge model | 评判模型 |
| long-horizon optimization | 长程优化 |
| NL2Repo | 自然语言转代码仓库（基准测试名） |
| rule-based pre-detection | 基于规则的预检测 |
| self-evaluation | 自我评估 |
| single operator | 单算子 |
| starter code | 起始代码 |
| stub | 实现桩 |
| transparent proxy | 透明代理 |
| user simulator | 用户模拟器 |
| wall-clock time limits | 挂钟时间限制 |
| website generation | 网站生成 |
此文章由 AI 翻译