Eason Mao☢@KELMAND1
GLM-5.2长session评测：连续跑完一个完整迁移任务
前面做的都是短任务对比,修一批 defect、跑个 TDD。这次给 GLM-5.2 一个完整的:一个模板迁移任务,从 CP1 迁到 CP3,模型连续跑了 1 小时 11 分、306 个 turn,中途零人工接管。讲讲它在完整工程任务里表现怎么样。
任务是个标准的交接执行:开篇加载 executing-plans 这个 skill,读 tasks/todo.md 拿到计划,然后开始执行。从里程碑看脉络清楚:turn 50 在做模板转换,turn 100 在重建 npm 依赖(从 0 恢复到 115 个包,包括 vite 和 vitest),turn 200 在配 entry 和 vite config,turn 300 在跑最终的全量 pytest 门禁,turn 303 加载 finishing-a-development-branch 这个 skill 做收尾,turn 305 主动停下来用 AskUserQuestion 问我要不要 push,因为分支上叠了别人早先的很多 commit、它只动了顶部 8 个。整个生命周期干净:执行计划、干活、收尾分支、等授权。306 个 turn 一口气跑完,工具执行几乎零等待,模型全程连续工作没断档。
效率数字：306 个 main turn,纯模型推理 66.4 分钟,平均单 turn 13 秒。这个比我之前在短任务 head-to-head 里测到的 19.8 秒快不少。最慢单 turn 66.1 秒,是改一个 Edit,全程只有 13 个 turn 超过 30 秒,占比 4%。吞吐 26.8 token 每秒,比修 defect 那段的 14.1 高出将近一倍。这个反差正好验证之前根因分析的结论:GLM 慢大头是推理吞吐,但吞吐不是恒定的,跟任务里 output 结构有关,长任务里大量是短促的 Edit 和 Bash,output token 少,反而把吞吐拉高了。而且非高峰时间GLM确实也会快一点（我的是max plan）。
工具调用 305 次,结构是这个 session 最有意思的点。Bash 116 次、Read 66 次、Edit 59 次、Write 51 次、TodoWrite 只有 10 次。Write 高达 51 次说明它新建了大量文件,符合模板迁移这种生成型任务。但 TodoWrite 只有 10 次,平摊到 306 turn,平均每 30 个 turn 才更新一次计划。这跟修 defect 那段完全相反,那段 GLM 14 turn 里 TodoWrite 用了 5 次,碎得要命。长任务里它反而收敛了,大段大段连续 Edit 和 Write 不打断自己。这个发现重要:GLM-5.2 的"流程碎"不是固有属性,是任务规模决定的,长任务里它会自动切到更紧凑的节奏。
token 这块印证了之前的判断。总 input 4985 万 token,cache read 4906 万,命中率 49.6%,净新输入 79 万。cache 命中率跟之前所有 session 一样卡在 49% 附近,是 harness 层面的常数。但净新输入 79 万平摊到 306 turn,平均每 turn 2582 token,比修 defect 那段 GLM 的每 turn 3.7 万小了一个量级。这解释了为什么长任务反而快:它没有每 turn 重新啃一大段没缓存的上下文,prompt 结构稳定、缓存复用率高。
几个体现能力的细节。一个是信号噪声判断。turn 100 重建依赖后 npm 报了 vulnerabilities,它没慌着去修,而是判断这些是 echarts 和 vitest 的传递依赖、pre-existing,继续验证 build 能不能用。长任务里这种"区分信号和噪声"的判断很关键,能避免在无关告警上空转。另一个是收尾纪律。turn 303 主动加载 finishing-a-development-branch 这个 skill,turn 305 用 AskUserQuestion 把 4 个标准选项摆出来,而且特别说明边界:分支上叠了很多别人早先的 commit、它只动了顶部 8 个,所以没有擅自 push。授权边界守了全程没破。
慢 turn 分布也值得说说。4 个超过 45 秒的,分别在 turn 46(改 Edit 55 秒)、65(读文件 50 秒)、76(写文件 55 秒)、210(改 Edit 66 秒)。清一色大文件的读写,没有一个是"卡住想不出来"的慢。坐实了之前分析里"慢 turn 主要由大文件 IO 决定、跟模型关系小"的判断。
所以结论可以更新了。GLM-5.2 用 1 小时 11 分连续跑完了一个完整的模板迁移任务,306 turn、305 次工具调用、零人工接管(除了最后那个该不该 push 的确认)。能力上模板转换、依赖重建、构建配置、全量测试、分支收尾这一整条链路它自己走完,中途不崩不乱不越权。效率上长任务反而是它的舒适区,吞吐升到 26.8 token 每秒,流程收敛、TodoWrite 不再碎。这跟之前短任务里"慢在流程碎、每 turn 净处理量大"的发现不矛盾,反而说明:GLM 的慢有一部分是短任务里过度自检造成的,任务一长、它自动优化节奏,这部分慢就消失了,真正剩下的是推理吞吐这个硬指标。
局限照旧:单个 session、模板迁移这一类任务。但作为"GLM-5.2 能不能独立连续跑完一个完整工程任务"的回答,这个 session 的答案是能,而且 1 小时 11 分一口气跑完,效率比短任务场景还高。
