GLM-5.2 升级了什么？重点不是聊天，是工程 Agent
GLM-5.2 的升级重点放在代码、长任务执行和工具协作上，但页面上线不等于 API 已可用，这次实测也踩到了这个坑。
这两天不少人在问 GLM-5.2。
如果只看名字，它很容易被理解成一次普通版本号更新：GLM-5、GLM-5.1、GLM-5.2，似乎就是更聪明一点、更快一点、更便宜一点。
但我看完公开资料，又拿手上的测试题跑了一轮，感觉这次更值得关注的不是“聊天能力又变强了”，而是 GLM 系列正在把重点继续往一个方向推：工程 Agent。
也就是让模型不只是回答问题，而是能规划、写代码、调用工具、处理长上下文，并尽可能把一个复杂任务推进到可交付状态。
先说能确认的升级方向
OpenRouter 的 GLM-5.2 页面 已经出现，页面把它描述为 Z.AI GLM 系列的最新模型，继续强调 coding 和 long-horizon agentic tasks，也就是代码能力和长周期智能体任务。页面还标出 203K context，并写着 GLM-5.2 API 在 2026 年 6 月 16 日 release。
这和 GLM-5、GLM-5.1 的路线是一致的。
Z.AI 官方文档里，GLM-5 主打 Agentic Engineering，强调从“写代码”走向“构建完整项目”；GLM-5.1 则继续把重点放到长任务执行，官方说它可以在单个任务上持续自主工作最长 8 小时，完成规划、执行、迭代优化到交付的闭环。
所以 GLM-5.2 的关键词，不应该只写成“参数更大”或者“回答更准”。公开资料能看到的方向更清楚：
第一，代码能力继续是主线。
这不是那种写一个函数、补一个正则的 coding，而是更接近真实工程：理解需求、拆步骤、修 bug、跑工具、处理上下文里的依赖关系。GLM-5 开始就已经把 Agentic Engineering 作为定位，5.2 继续沿着这条线走。
第二，长任务能力继续被强化。
普通模型很容易在多轮任务里漂移：前面说过的约束后面忘了，工具返回的状态记不住，中间出错以后无法自我修正。GLM-5.1 官方特别强调 long-horizon，5.2 继续把 long-horizon agentic tasks 写在模型定位里，说明它要解决的不是单轮问答，而是“长时间把一件事做完”。
第三，工具调用和结构化输出更重要。
Z.AI 文档里，GLM-5 系列的能力底座包括 thinking mode、streaming、function calling、context caching、structured output 等。对开发者来说，这些功能比“会聊天”更实用，因为它们决定模型能不能接进真实系统：查订单、读文档、调用工具、返回 JSON、把中间状态交给下一步。
第四，上下文规模继续保持在工程可用级别。
OpenRouter 页面给 GLM-5.2 标的是 203K context。这个量级不是为了让你一次性塞更多废话，而是为了让模型在代码仓库、长文档、多轮任务、工具日志里保持足够多的现场信息。
我的小测试：四个普通题都稳
因为 OpenRouter 当时还没法实际调用 GLM-5.2，我先用 zcode 跑了一组同样的测试题。
这组题很小，但覆盖了几个开发者会关心的点：依赖调度、代码修复、严格 JSON、长上下文检索，以及工具调用流程。
结果比较直接：
| 场景 | GLM-5.2 结果 |
|---|---|
| 依赖调度与结构化推理 | 7/7 |
| 代码调试与修复完整性 | 8/8 |
| 严格约束与提示注入抵抗 | 6/6 |
| 长上下文检索与精确汇总 | 4/4 |
也就是说，四个普通文本任务全部过了。
它能算对依赖关系，能找出 JavaScript 里的 await、分页、停止条件、数字排序问题，也能抵抗外部备注里的提示注入，按要求只输出 JSON。长上下文题里，它也准确找到了两条目标记录，并算对预算合计。
这说明 GLM-5.2 至少在这类小型工程题上没有明显短板。
但最值得看的，是它在工具题上的反应
工具调用题本来是让模型按顺序做三步：先查订单，再按条件退款，最后发邮件。
手动模拟时，我希望它第一轮输出：
{"tool":"lookup_order","arguments":{"order_id":"OR-2048"}}
但它第一轮拒绝了。
理由是：这些工具不在它实际可用的工具列表里，所以它不能假装查询订单、退款或发邮件。
从基准测试角度看，这是扣分项，因为题目已经给了模拟工具协议。但从真实工程角度看，这个反应很有意思：它没有随便装作自己调用了工具，而是区分了“用户声明的工具”和“运行环境真实暴露的工具”。
这恰好是 Agent 系统里很关键的一点。
一个模型如果什么都敢假装执行，演示时会很顺，生产里会很危险。订单、退款、邮件、数据库、文件系统，这些动作都不是普通文本生成。模型必须知道自己到底有没有权限、有没有真实工具、有没有拿到工具返回。
GLM-5.2 这次不是不会做业务逻辑。后面我继续给它工具返回，它能正确退款 288 CNY，也能发确认邮件到 buyer@example.com。真正的问题在第一步：它更相信当前运行环境，而不是用户临时声明的模拟协议。
这不是纯粹的坏事。它更像是在提醒我们，Agent 评测不能只看“答案对不对”，还要看“工具边界处理得稳不稳”。
还有一个坑：OpenRouter 页面上线，不等于 API 能调
后来我又用 OpenRouter API 复测了一次。
结果也值得单独说一下：OpenRouter 已经有 GLM-5.2 页面，也能查到模型 metadata，但 /api/v1/models/z-ai/glm-5.2/endpoints 返回的 endpoints 是空的。
实际调用 chat/completions，无论固定 provider 还是自动路由，都会返回：
No endpoints found for z-ai/glm-5.2
所以现在更准确的说法是：OpenRouter 上已经能看到 GLM-5.2 的模型页面，但我这次测试时还没有可用的 OpenRouter completion endpoint。想通过 OpenRouter key 正式跑分，还得等 provider endpoint 真正挂上去。
我的判断
GLM-5.2 这次升级，重点不是“更会聊天”。
它真正想强化的是三个方向：代码工程能力、长周期任务执行、工具协作边界。
这也是大模型正在发生的变化。过去我们看模型，常常看它会不会写一段漂亮回答；现在更值得看的是，它能不能在真实系统里稳定干活。
会写代码只是起点。
能读懂项目、记住约束、调用工具、处理失败、持续迭代，最后把任务交付出来，才是工程 Agent 真正有价值的地方。
GLM-5.2 还需要等 API endpoint 真正可用后再做严格横向跑分。但从公开定位和这轮手测看，它的升级方向已经很明确：不是做一个更会聊天的模型，而是继续往“能干活的模型”走。