GLM-5.2 实测
让 GLM-5.2 跑了一个 1 小时 42 分钟的前端重构任务。88 个模型 turn,102 次工具调用,全程零人工介入。讲讲它做了什么。
任务是一个 TDD Code Review 闭环:接手一个 handoff,修 reviewer 提的 4 个 blocker,按规范用 TDD 实现 12 个测试,再应对两轮 P2 修复,最后全量回归。模型扮演"执行者",另有 reviewer 在对话里出现。
第一件让我意外的事是它对角色的自觉。它一度想主动推进实现,reviewer 一句话点醒"你搞错了角色",它立刻收敛:"明白了,我搞错了角色。我是执行者,不是决策推手。当前状态:待命。"之后整个 session 它都守着授权边界 - 实现完成(13 个测试全绿、tsc 通过)后主动停下等放行,没有顺手 commit。这一点很多模型做不到,它们倾向于"把活干完再说"。
第二件是失败自恢复。reviewer 抓出一个真 bug:它写的 wait_for_row_replace 用了
ElementHandle.is_connected,但这是 Playwright Node.js 版的 API,Python 里根本不存在,所以 helper 每次都撞进宽泛的 except,Gate 3 必然失败。它的反应不是狡辩、不是"我重新生成一遍试试",而是:承认 → 查 Playwright Python 文档确认 → 换成 page.wait_for_function("(el) => !el.isConnected", arg=first_row) → 顺手检查 time 模块是不是变成了 dead import(发现仍被 TOOLTIP_DISMISS_MS 使用,保留)→ 编译 → 重读 helper 确认接线一致。这条链路在 agentic coding 里是黄金标准。
第三件是 TDD 纪律。加载 tdd skill 后它真的按 vertical slice 走,每个测试先验证 RED 再写 GREEN,而且会主动思辨规则。skill 说"一次一个测试",它判断 slices 6-12 是同一 export 的不同行为路径、紧密耦合,有理由批量验证,并明确说出理由:"我会通过运行它们来确认 RED→GREEN 的状态,而不是假设成功。"是理解原则,不是机械执行。
然后是数字。88 个 turn,纯模型推理 20.2 分钟(占墙钟约 20%,剩下 80% 是工具执行等待)。平均单 turn 13.7 秒,最高 92.7 秒 - 那个 92 秒是连续读两个大文件(测试文件 2524 行加源码)。102 次工具调用:Edit 32、Bash 28、Read 25、TodoWrite 16、Skill 1。结构很健康,Read 做侦察、Bash 跑测试、Edit 改代码、TodoWrite 同步计划,是个自觉管理计划的 agent。output 只烧了 4.27 万 token,平均每 turn 约 485 token,极度惜字,它的用户面消息大多是"RED 已确认,现在进入 GREEN 阶段"这种一两句,从不啰嗦。prompt cache 命中率约 50%。
最终交付:4 文件、 527 行、0 删除,13 个测试全绿(12 spec 1 P2 回归),从 331 测试基线一路跑到 866,全程 tsc 退出码 0,零回归。
中文输出,技术术语不翻译(Stimulus controller、isConnected、vi.mock 原样保留),文件路径和行号引用准确可点击,没有翻译腔。
对比我之前观察过的 GLM-5.1(同系列上一代),最大的进步是工具失败后的自恢复,5.1 那时撞到接口异常常常卡住等用户介入,5.2 能自己走完闭环。
短板也说清楚:大上下文读写时单 turn 延迟偏高,92 秒那一下交互场景会卡。但纯模型推理只占墙钟五分之一,挂机跑长任务基本无感。
样本量是一条 session,结论不外推。但就这一条而言:GLM-5.2 是一个我已经敢放心交办真实工程任务的 coding agent。最大短板是大文件下的单 turn 延迟。