AI独自写了8小时代码，还把SWE-Bench刷到了第一——GLM-5.1到底做对了什么？
AI独自写了8小时代码，还把SWE-Bench刷到了第一——GLM-5.1到底做对了什么？
大家好，我是摘星，今天我们来聊聊智谱刚发的GLM-5.1——一个能连续干8小时代码活儿、中途不需要人类插手、还把SWE-Bench Pro刷到58.4分刷新纪录的开源模型。
4月7日，智谱AI发布了GLM-5.1。一句话概括这个模型的核心卖点：它不是让你「对话写代码」，而是让你把一个复杂的工程任务丢给它，然后下班走人，8小时后回来看结果。这种从「Vibe Coding」到「Agentic Engineering」的范式转变，才是GLM-5.1真正值得关注的地方。本文会从架构设计、三个实测场景的硬核数据、到如何上手使用，把GLM-5.1的技术细节拆解干净。无论你是想了解长程自主执行背后的技术原理，还是准备把它接入自己的开发工作流，看完这篇文章都会心里有数。
一、从「聊天写代码」到「自主做工程」——GLM-5.1是什么
先说一个背景。过去两年，大模型在编程领域的进步大致分三个阶段：
第一阶段是「Copilot模式」——模型根据上下文补全代码片段，代表产品是GitHub Copilot。第二阶段是「Vibe Coding」——你用自然语言描述需求，模型帮你生成一个可运行的项目骨架，Cursor、Windsurf都在这个赛道。这两个阶段的共同特点是：模型的参与时间短，一般几分钟到半小时就结束交互。
GLM-5.1瞄准的是第三阶段：Long-Horizon Agentic Engineering（长程自主工程）。它的设计目标是接手一个复杂任务，连续自主工作数小时，自己规划、自己执行、自己检查、自己迭代优化，中间不需要人类干预。
这听起来像是科幻？但智谱用三个实测场景证明了这件事的可行性。在讲具体场景之前，先看看GLM-5.1的基本参数。
GLM-5.1架构概览
| 参数 | GLM-5.1 | GLM-5（上一代） |
|---|---|---|
| 总参数量 | 754B | 744B |
| 激活参数量 | ~40B | ~40B |
| 架构 | MoE（混合专家） | MoE |
| 最大上下文 | 200K tokens | 200K tokens |
| 开源协议 | MIT | MIT |
| 训练数据 | >23T tokens | 23T tokens |
GLM-5.1延续了GLM系列一贯的MoE（Mixture of Experts）架构。简单说，MoE的思路是：模型虽然总参数量很大（754B），但每次推理只激活其中一小部分（约40B）。这就像一个公司有750个员工，但每次开会只叫相关的40个人，其他人不用到场。这样做的好处是推理成本远低于同等参数量的稠密模型，同时保持了强大的知识容量。
GLM-5.1相比上一代GLM-5，核心改进不在参数规模（只增加了10B），而在于训练策略和推理优化：
1. 针对长程任务的特殊训练
智谱团队为GLM-5搭建了三类高仿真训练环境：软件工程任务环境（模拟真实GitHub仓库的开发和调试）、终端操作环境（模拟命令行下的系统管理和运维）、信息搜索环境（模拟需要反复检索和交叉验证的场景）。GLM-5.1在此基础上进一步强化了对「模糊问题」的判断能力——当任务目标不明确时，它能更合理地拆解问题、制定策略。
2. 自我反思与策略修正
GLM-5.1最核心的能力突破在于「不会卡住」。之前的模型（包括GLM-5）在长时间运行时会遇到一个典型问题：前几轮进步很快，然后陷入停滞。因为模型倾向于反复使用同一套已知的优化策略，一旦这些策略的收益耗尽，就原地打转。GLM-5.1通过训练模型在遇到瓶颈时主动切换策略——分析自身的执行日志，定位当前瓶颈，然后尝试全新的方案。
下面这个流程图展示了GLM-5.1的长程执行循环：
这个循环看起来简单，但关键在于模型需要在数百甚至数千轮迭代中始终保持一致的判断力和策略切换能力，而不是越跑越「疲劳」。
二、三场硬仗——GLM-5.1的极限测试
智谱为GLM-5.1设计了三个难度递增的测试场景，从有明确数值指标到完全依赖主观判断，完整展示了「长程自主执行」的价值。
场景一：向量数据库优化——600轮迭代，性能提升6倍
第一个测试用的是VectorDBBench，一个开源基准测试，要求模型用Rust写一个高性能向量数据库，实现近似最近邻搜索（ANN）。评测指标是在SIFT-1M数据集上、Recall≥95%约束下的QPS（每秒查询数）。
在此之前，Claude Opus 4.6在50轮工具调用限制下的最好成绩是3,547 QPS。智谱重新设计了评测方式：取消了50轮的限制，改为让模型在一个外层循环中反复提交优化版本，每次提交后自动跑benchmark，模型根据benchmark结果自主决定下一步怎么改。
结果是这样的：
GLM-5.1在655次提交、超过6000次工具调用后，最终达到了21,500 QPS——是最初50轮成绩的6倍。整个优化轨迹呈现出典型的「阶梯式」模式：一段时间内做增量调优，然后模型主动做一次架构级改动，性能跳上一个新台阶。
特别有意思的两个关键转折点：
- 第90轮左右：模型从全量扫描切换到IVF聚簇探测+f16向量压缩，QPS跳到6,400
- 第240轮左右：模型引入了两阶段流水线——先用u8做粗筛，再用f16做精排，QPS跳到13,400
这些不是人类预设的策略，而是模型在分析自己benchmark日志后自主做出的架构决策。整个过程发生了6次类似的架构级跃迁。
场景二：GPU Kernel优化——1000轮对决Claude Opus 4.6
第二个测试用的是KernelBench，要求模型把PyTorch的参考实现替换为更快的GPU Kernel，保持输出一致。测试集中在Level 3（最高难度），涉及MobileNet、VGG、MiniGPT、Mamba等完整模型的端到端优化，共50道题。
作为参考基线，torch.compile默认配置在这些题目上能获得1.15倍加速，开启max-autotune后能到1.49倍。
| 模型 | 几何平均加速比 | 表现特点 |
|---|---|---|
| Claude Opus 4.6 | 4.2× | 全程最强，最终仍有提升空间 |
| GLM-5.1 | 3.6× | 持续进步时间最长，后期仍有收益 |
| GLM-5 | ~2.5× | 早期进步快，中后段明显停滞 |
| Claude Opus 4.5 | ~2.8× | 略好于GLM-5，但后期同样乏力 |
GLM-5.1在这个场景中虽然没有超过Claude Opus 4.6，但展现了一个关键差异：持续性。GLM-5在第400-500轮后基本停滞，Claude Opus 4.5也有类似问题，而GLM-5.1到第800-900轮时仍在找到有意义的优化。这说明模型确实学到了「如何不放弃」。
场景三：8小时搭一个Linux桌面——没有评分标准，全靠自我判断
前两个场景都有明确的数值指标（QPS、加速比），模型知道什么是「更好」。第三个场景故意去掉了这个安全网：让模型用纯Web技术构建一个Linux桌面环境，没有预设的评分标准，没有设计稿，没有中间检查点。
大多数模型在这种任务中的表现：生成一个静态任务栏和一两个占位窗口，然后宣布「完成」。因为模型没有机制去回头审视「还有什么可以改进的」。
GLM-5.1的处理方式不同。它被包装在一个简单的自检循环中：每轮执行后，模型review自己的产出，列出可以改进的地方（缺失功能、粗糙的样式、broken的交互），然后继续。
经过8小时的持续迭代，最终产出包括：
- 文件浏览器（可实际浏览虚拟文件系统）
- 终端模拟器（可执行基本命令）
- 文本编辑器（支持语法高亮）
- 系统监控器（实时显示CPU/内存占用）
- 计算器
- 小游戏
- 所有组件整合在一个视觉一致的桌面环境中
关键不是它做了多少个功能，而是这些功能不是堆砌上去的——后期的迭代主要在打磨交互细节和视觉一致性，这是只有「能回头看」的模型才能做到的事。
三、Benchmark全景——GLM-5.1在各维度的表现
除了上面三个深度场景，GLM-5.1在标准benchmark上的成绩同样亮眼。以下是和当前主流模型的全面对比：
| 基准测试 | GLM-5.1 | GLM-5 | Claude Opus 4.6 | GPT-5.4 | Gemini 3.1 Pro | Qwen3.6-Plus | DeepSeek-V3.2 |
|---|---|---|---|---|---|---|---|
| SWE-Bench Pro | 58.4 | 55.1 | 57.3 | 57.7 | 54.2 | 56.6 | - |
| CyberGym | 68.7 | 48.3 | 66.6 | 66.3 | 38.8 | - | 17.3 |
| NL2Repo | 42.7 | 35.9 | 49.8 | 41.3 | 33.4 | 37.9 | - |
| AIME 2026 | 95.3 | 95.4 | 95.6 | 98.7 | 98.2 | 95.1 | 95.1 |
| GPQA-Diamond | 86.2 | 86.0 | 91.3 | 92.0 | 94.3 | 90.4 | 82.4 |
| HLE | 31.0 | 30.5 | 36.7 | 39.8 | 45.0 | 28.8 | 25.1 |
| BrowseComp | 68.0 | 62.0 | - | - | - | - | 51.4 |
几个值得关注的点：
SWE-Bench Pro 58.4分，开源模型首次登顶。 在这个被公认为「真实软件工程能力试金石」的benchmark上，GLM-5.1以1.3分的优势超过了Claude Opus 4.6（57.3分），同时也压过了GPT-5.4（57.7分）。对于开源社区来说，这是一个里程碑——之前这个榜单的顶部一直是闭源模型的领地。
CyberGym 68.7分，安全能力大幅跃升。 相比上一代GLM-5的48.3分，GLM-5.1提升了20.4分。这个benchmark测试的是网络安全攻防能力，包括漏洞分析、渗透测试、安全审计等。这一项提升幅度之大，说明智谱在安全相关场景的训练上下了狠功夫。
BrowseComp 79.3分（启用上下文管理），信息检索能力突出。 这个benchmark测试的是模型在复杂信息检索任务中的表现，GLM-5.1在启用上下文管理策略后达到79.3分，仅次于Claude Opus 4.6的84.0分和Gemini 3.1 Pro的85.9分。
当然也有短板。在纯推理类benchmark（HLE、AIME）上，GLM-5.1与Gemini 3.1 Pro和GPT-5.4还有明显差距——HLE差了14分，AIME差了3.4分。这说明GLM-5.1的优化重心确实在工程和智能体场景上，纯数学推理不是它的主战场。
四、动手实操——如何把GLM-5.1用起来
说了这么多，你最关心的可能是：我怎么才能用上它？这里提供三种路径，从最简单的到最硬核的。
路径一：API调用（最简单，5分钟上手）
智谱官方提供了API服务，支持标准OpenAI格式的API调用。你只需要在BigModel.cn注册账号，获取API Key即可。
from openai import OpenAI
client = OpenAI(
api_key="your-api-key-here",
base_url="https://open.bigmodel.cn/api/paas/v4"
)
response = client.chat.completions.create(
model="glm-5.1",
messages=[
{
"role": "system",
"content": "你是一个资深全栈工程师，擅长系统设计和性能优化。"
},
{
"role": "user",
"content": "帮我用Rust实现一个高性能的HTTP静态文件服务器，"
"要求支持Range请求、gzip压缩和ETag缓存。"
"请给出完整的main.rs和相关配置文件。"
}
],
temperature=1.0,
top_p=0.95,
max_tokens=32768
)
print(response.choices[0].message.content)
这段代码的关键参数解释：
base_url：智谱API兼容OpenAI的接口规范，只需改base_url就能无缝切换temperature=1.0+top_p=0.95：这是官方推荐的配置，在SWE-Bench评测中也是用这组参数。对于代码生成任务，较高的temperature有助于模型探索更多可能的实现方案max_tokens=32768：GLM-5.1支持最大163,840 tokens的输出，但日常使用32768已经足够。如果遇到需要超长输出的场景（比如生成整个项目），可以调到更大
路径二：接入Claude Code（Agentic Coding最佳体验）
GLM-5.1兼容Claude Code框架，这也是智谱官方推荐的Agentic Coding方式。配置过程非常简单：
# 第一步：安装Claude Code CLI（如果还没装的话）
npm install -g @anthropic-ai/claude-code
# 第二步：编辑配置文件，把默认模型换成GLM-5.1
# 在 ~/.claude/settings.json 中添加以下配置
{
"env": {
"ANTHROPIC_BASE_URL": "https://open.bigmodel.cn/api/paas/v4",
"ANTHROPIC_API_KEY": "your-api-key-here"
},
"permissions": {
"allow": ["Bash", "Read", "Write", "Edit"]
},
"model": "glm-5.1"
}
# 第三步：启动Claude Code，它会自动使用GLM-5.1
claude
# 或者指定一个项目目录
claude --project /path/to/your/project
配置说明：
ANTHROPIC_BASE_URL：指向智谱的API端点，Claude Code会把所有请求发到这里ANTHROPIC_API_KEY：你在BigModel.cn上获取的API Keymodel：直接写glm-5.1即可，智谱的API会正确识别permissions.allow：Agentic Coding场景下需要授予文件读写和命令执行权限
智谱还推出了「GLM Coding Plan」订阅服务，专门针对编码场景优化了配额和定价。4月底前有限时优惠，非高峰时段按1倍费率计费（正常是2倍），性价比相当高。
路径三：本地部署（硬核路线，适合有GPU的团队）
754B参数的模型，本地部署不是闹着玩的。以下是硬性需求：
| 配置项 | 最低要求 | 推荐配置 |
|---|---|---|
| GPU | 8× A100 80GB | 8× H100 80GB |
| 内存 | 512GB系统内存 | 1TB系统内存 |
| 磁盘 | 1.7TB（FP8） | 2TB+ NVMe SSD |
| 推理框架 | vLLM ≥ 0.8 | vLLM latest / SGLang |
# 下载模型权重（从HuggingFace）
pip install huggingface_hub
huggingface-cli download zai-org/GLM-5.1 \
--local-dir ./glm-5.1 \
--local-dir-use-symlinks False
# 使用vLLM启动推理服务（FP8量化，8卡并行）
python -m vllm.entrypoints.openai.api_server \
--model ./glm-5.1 \
--tensor-parallel-size 8 \
--dtype float8 \
--max-model-len 131072 \
--gpu-memory-utilization 0.9 \
--port 8000
# 验证服务是否正常
curl http://localhost:8000/v1/models
部署要点：
- FP8量化是生产环境的首选，精度损失极小，推理速度提升明显。全精度部署需要1.65TB磁盘空间和更多显存，性价比不高
--tensor-parallel-size 8表示用8张GPU并行推理，这是754B参数模型的最低配置--max-model-len 131072设置为128K上下文窗口。GLM-5.1最大支持200K，但128K在大多数场景已经够用，且能显著降低显存占用- 如果你用的是昇腾NPU而不是NVIDIA GPU，可以参考华为云ModelArts的Ascend-vLLM方案，一键部署
还有一个更轻量的选择：如果你的GPU资源有限（比如只有2-4张A100），可以考虑部署GLM-5.1的量化版本（AWQ或GPTQ），精度损失在1-2%左右，但能大幅降低硬件门槛。
五、GLM-5.1背后的技术思考
聊完「怎么用」，我想再深一层聊聊「为什么行」。GLM-5.1的长程自主执行能力，本质上是几个技术问题的叠加：
1. 策略疲劳问题
传统模型在长程任务中最大的敌人不是「不会做」，而是「只会做这么多」。GLM-5在前50轮的优化效果和GLM-5.1差不多，但之后就开始原地踏步。GLM-5.1通过什么方式突破了这个问题？
从官方博客的描述来看，关键在于模型学会了自我诊断：当增量优化不再产生收益时，模型会分析当前的瓶颈日志，判断是否需要换一个全新的架构方向。这在向量数据库优化场景中体现得最明显——6次架构级跃迁，每次都是模型自主发现当前策略已经到了天花板，然后主动跳到下一个策略层级。
2. 上下文管理问题
连续8小时运行，上下文窗口迟早会被撑满。GLM-5.1的解决方案是「上下文管理策略」：不是简单地保留最近N轮对话，而是根据任务的重要性进行选择性遗忘。这在BrowseComp的评测中有直接体现——启用上下文管理后，分数从68.0跳到79.3，提升了11.3分。
# 上下文管理的简化示意（概念代码，非实际实现）
def manage_context(tool_calls_history, max_tokens=200000):
"""
简化的上下文管理策略：
1. 保留最近的5轮完整交互
2. 对更早的交互，只保留关键决策节点的摘要
3. 当上下文接近上限时，压缩历史记录
"""
recent_turns = tool_calls_history[-5:]
older_turns = tool_calls_history[:-5]
# 计算当前上下文占用
current_usage = estimate_tokens(recent_turns + older_turns)
if current_usage > max_tokens * 0.85:
# 对早期记录进行摘要压缩
compressed = []
for turn in older_turns:
if turn.is_key_decision():
# 保留关键决策节点的完整记录
compressed.append(turn)
else:
# 其他记录只保留一句话摘要
compressed.append(turn.summarize())
return compressed + recent_turns
return tool_calls_history
这段伪代码展示了上下文管理的核心思路：不是所有历史信息都同等重要。一次架构级的策略切换值得保留完整记录，而一次微不足道的参数调整只需要一行摘要。
3. 自我评估问题
这是三个问题中最难的一个。当任务有明确的数值指标（QPS、加速比）时，模型知道自己在变好还是变坏。但当任务没有客观评分标准（比如「做一个好看的桌面」）时，模型怎么判断自己的产出质量？
GLM-5.1给出的答案是：让模型扮演「审查者」的角色。每轮执行后，模型切换视角，从「构建者」变成「审查者」，用一套结构化的检查清单来评估当前产出的完整度、视觉一致性、交互流畅度。这个「自检循环」虽然简单，但效果显著——8小时Linux桌面的场景证明了它的可行性。
当然，自我评估仍然是一个开放的研究问题。官方博客也坦诚地指出：对于没有数值指标的任务，如何可靠地防止模型的自我评估陷入局部最优，仍然是一个待解的挑战。
六、开源意味着什么——从生态角度看GLM-5.1
GLM-5.1以MIT协议开源，这在当前大模型领域并不常见。让我们看看这个决定意味着什么。
开源 vs 闭源：当前格局
| 维度 | GLM-5.1（开源） | Claude Opus 4.6（闭源） | GPT-5.4（闭源） |
|---|---|---|---|
| SWE-Bench Pro | 58.4 | 57.3 | 57.7 |
| 自主运行时长 | 8小时 | 未公开 | 未公开 |
| 本地部署 | 支持（需8×A100） | 不支持 | 不支持 |
| 数据隐私 | 完全可控 | 依赖Anthropic | 依赖OpenAI |
| 定制微调 | 可行 | 不支持 | 有限支持 |
| 使用成本 | API按量/自建 | 仅API | 仅API |
GLM-5.1在SWE-Bench Pro上的分数超过了两个闭源旗舰，这在开源大模型的历史上还是第一次。当然，一个benchmark的分数不能代表全面的领先——在推理、数学、知识问答等领域，闭源模型仍有优势。但对于「AI辅助软件工程」这个当前最热门的应用场景，GLM-5.1证明了一件事：开源模型完全有能力在这个赛道上与闭源模型正面竞争。
对开发者来说，开源还带来了一个闭源模型无法提供的价值：可审计性。在安全敏感场景（金融、医疗、政务）中，你可以审查模型的权重和训练流程，甚至进行针对性的微调。而闭源模型你只能「信」。
社区反响
GLM-5.1发布后在Reddit的r/vibecoding社区引发了热烈讨论，有用户称它为「目前最好的模型」，甚至表示在输出质量上更偏好GLM-5.1而不是GPT-5.4。当然这是个人主观感受，但也侧面说明开源模型在用户体验层面已经不再是「差点意思」了。
七、我的思考：长程自主执行的下一步
GLM-5.1的8小时自主执行确实让人印象深刻，但如果冷静分析，当前的「长程能力」还有几个明显的局限性：
局限一：仍有天花板。 在KernelBench场景中，GLM-5.1的3.6×加速比虽然好于前代，但距离Claude Opus 4.6的4.2×仍有差距，而且两者到最后都没有收敛——说明还有提升空间，但模型不知道怎么继续了。
局限二：自我评估的可靠性。 8小时Linux桌面场景证明了模型可以在没有客观标准的情况下持续改进，但这种改进的上限在哪里？模型会不会把一个已经足够好的东西「过度优化」到反而变差？目前还没有系统性的研究。
局限三：成本问题。 8小时的自主执行意味着大量的API调用。以GLM-5.1的规模（754B参数、200K上下文），一次完整的8小时运行成本不菲。对于日常开发任务来说，绝大多数场景用5-10分钟就能搞定，8小时的能力更像是一种「保险」——知道它能在极端情况下顶上。
不过话说回来，这些局限性恰恰也是下一个突破的方向。如果模型能学会更早地识别自己的策略瓶颈、更可靠地评估自己的产出质量、在效率和效果之间找到更好的平衡点，那么从「8小时」到「24小时」再到「项目级自主」的演进路线就清晰了。
对普通开发者而言，我的建议是：先用起来。不管你是通过API、Claude Code还是本地部署，把GLM-5.1接入你的日常工作流试试。它的价值不在于「能干8小时」（你大概率用不到那么久），而在于它把「AI辅助编程」的可靠性天花板提高了——以前你不敢让AI独立处理的复杂任务，现在可以试试了。
最后抛一个问题供大家思考：当开源模型在工程能力上追平甚至超过闭源模型时，闭源模型的护城河在哪里？是推理能力？是生态？还是品牌信任？欢迎在评论区聊聊你的看法。
参考链接：
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
19
0- 0
已为社区贡献34条内容
所有评论(0)