我用 Claude Code/ZCode+GLM-5.3 从零做了一款 Agent 游戏！

JavaGuide 2026-08-18 0 阅读18分钟

GLM-5.3 实测：改一个老项目，再从零做一款 Agent 游戏

大家好，我是 Guide。

GLM-5.3 这波真的来了。其实，我在好多天前就预测过应该快发布了。

榜单分数很厉害，这个后面会分享。不过，大家应该也清楚我更关心它在真实项目中的表现。

因此，这次我给 GLM-5.3 准备了两个差别很大的任务：

• 在一个已经有不少历史代码的项目里，增加“安全的用户图片素材导入与 HTML 动效场景引用”能力；
• 只提供 JavaGuide 的 Agent 学习资料和一份 PRD，让它从零做一款能真正通关的 Agent 知识学习游戏。

一个考验它理解旧系统和处理安全约束的能力，一个考验它从资料分析到产品落地的完整度。

两个项目最终都能运行、能测试。第一个案例也在人工验收时暴露了自动化测试没有覆盖到的安全问题。

这篇文章就完整聊聊这次实测。

GLM-5.3 相比 GLM-5.2 改进了什么？

我之前已经用 GLM-5.2 做过一次强度不低的开发。

当时的任务是在 Guide Sketch Motion 里增加一条 HTML 动效视频生成链路，涉及 contracts、数据库、任务状态、API、Worker、Web 和 HTML renderer。第一轮实现用了 1 小时 11 分钟，后面又花了 1 小时 04 分钟做浏览器验证和修复。

GLM-5.2 已经能在 Monorepo 里持续工作，处理跨前后端功能。GLM-5.3 的提升，要放在这个基础上看。

GLM-5.3 没有更换基座，仍然使用与 GLM-5.2 相同的 753B 基座模型。这次升级主要来自后训练 Scaling：长程任务环境扩大到原来的数十倍，环境类型更多，训练时间也更长。

官方把变化归纳为三个方向：

• Coding：GLM-5.3 被定位为代码能力最强的开源模型，在 Terminal-Bench 3.0、DeepSWE 1.1 等评测中保持开源领先，更强调长程和生产级软件工程；
• 网络安全：能力从生成代码延伸到白盒代码审查和漏洞推理，在基础安全任务上接近前沿闭源模型，但在完整漏洞利用场景中仍有差距；
• 开源：完整权重会在安全评估和模型加固完成后开放，方便开发者自行部署、验证和继续改进。

下面是两组评测。第一组覆盖 Terminal Bench 3.0、DeepSWE、Agents' Last Exam、AutomationBench、HLE w/ Tools 和 GDPVal-AA v2。和 GLM-5.2 相比，GLM-5.3 在六项评测中都拿到了更高的分数。

第二组是 Z.ai Code Bench v1.0，在 Claude Code 2.1.207 中测试不同 Effort Level。GLM-5.3 从 Low 到 High、Max 的准确率继续上升，整条曲线也高于 GLM-5.2。

把两组结果放在一起看，GLM-5.3 在复杂软件工程、终端操作和更广泛的真实世界 Agent 任务上都有明显提升。

网络安全能力也单独测了一组。GLM-5.3 的 CyberGym 得分为 84.5%，略高于 Mythos 5 的 83.8% 和 GPT-5.6 Sol 的 83.6%；ExploitBench 则从 GLM-5.2 的 24.4% 提升到 54.4%。

它目前更擅长漏洞利用链前端的白盒审查、漏洞发现和验证，更深入的漏洞利用与完整攻防任务还有提升空间。

发布前两周，GLM-5.3 联合国内安全团队发现了 2404 个漏洞，其中 1088 个为中高危。最早的问题可追溯到约 40 年前，涉及 Android、Windows、macOS 和常用 App。

目前，GLM-5.3 已上线 ZCode，Coding Plan 用户可以直接使用；API 和完整模型权重会分阶段开放。

回到这次实测，GLM-5.3 面对 Guide Sketch Motion 时，先读 README、架构文档、数据库结构、对象存储、Worker、ScenePlan 和渲染器代码，再列出现有链路、需求冲突和待确认问题。它没有一上来就改代码。

案例一接近 40 分钟，案例二接近 1 小时，过程包含资料阅读、方案分析、编码、测试和修错。交付范围覆盖数据库迁移、契约、接口、前端、Worker、单元测试、Playwright 和验证说明。做 Agent Quest 时，它还为原始材料补了来源追踪和内容一致性检查。

两个案例的任务和环境不同，不能拿耗时和代码量当成 GLM-5.2 与 GLM-5.3 的 A/B 结果。我能确认的是：GLM-5.3 把两个任务都推进到了真实验证环节。

案例一：在老项目里增加安全的用户图片素材能力

第一个测试项目是 Guide Sketch Motion。

这个项目在前一天的文章里也出现过。当时我用 GLM-5.2 给它补上了 HTML 动效视频生成链路，具体过程放在上一篇实测里。隔了一天，我让 GLM-5.3 接着改同一个仓库，看看它面对真实旧代码时会怎么做。

案例一用的是 Claude Code。接入时先把请求指向智谱的 Anthropic 兼容网关，用智谱 API Key 鉴权；再把 Claude Code 内部的默认模型档位统一映射到 GLM-5.3 即可。

{
  "ANTHROPIC_BASE_URL": "https://open.bigmodel.cn/api/anthropic",
  "ANTHROPIC_AUTH_TOKEN": "<智谱 API Key>",
  "ANTHROPIC_DEFAULT_OPUS_MODEL": "GLM-5.3",
  "ANTHROPIC_DEFAULT_SONNET_MODEL": "GLM-5.3",
  "ANTHROPIC_DEFAULT_HAIKU_MODEL": "GLM-5.3",
  "ANTHROPIC_DEFAULT_FABLE_MODEL": "GLM-5.3"
}

这样 Claude Code 发出的 Anthropic 协议请求会走智谱的兼容端点，无论内部选择 Opus、Sonnet、Haiku 还是 Fable，最终调用的都是 GLM-5.3。

大家也可以用 CC-Switch 完成配置，具体可以参考这篇文章：GLM-5.1 实战。

这是一个用来生成手绘讲解视频的项目，采用 pnpm Monorepo，里面有 Next.js Web、NestJS API、PostgreSQL、Redis、BullMQ、对象存储和独立 Worker。项目原本已经支持图片视频和 HTML 动效两种渲染模式，工作区里还有我尚未提交的改动。

这次的需求听起来不复杂：用户上传一张图片，在创建 HTML 动效视频时引用它。

真正做起来，要处理的远不止一个上传按钮。文件格式不能只看扩展名，素材需要放进私有 OSS 并通过短期签名 URL 预览；同一张图要去重，没有登录体系时还得判断素材归属。用户确认授权之前不能引用，任务创建后又要冻结素材，避免源文件被替换或撤销时影响旧任务。ScenePlan 怎么保存引用、新能力会不会破坏原有图片视频模式，也都要一起考虑。

先理解旧项目，再决定怎么加

我给 GLM-5.3 的提示词里，明确要求第一阶段只做分析：

请在现有项目中实现“安全的用户图片素材导入与 html-motion 场景引用”。

开始前先检查工作区，并完整阅读项目文档以及现有 assets、OSS、ScenePlan、HTMLPipeline
和 html-renderer 代码。不要覆盖现有改动。

第一阶段只分析，不修改代码：总结现有链路、需求冲突、需要我决定的问题和实施计划。
我确认后再开始实现。

它读完项目后，先指出了几个真实冲突，例如：

1. 现有 assets 表和任务绑定，jobId 不能为空；
2. 用户素材却可能被多个任务复用，也可能上传后暂时不用；
3. 硬复用旧表，会把“用户素材”和“任务产物”两种生命周期混在一起。

GLM-5.3 给了两个方案：改造 assets 表，或者新增 user_media 和 job_media_snapshots。

它更推荐后者：原始素材独立管理，创建任务时冻结快照，后续修改源素材不会影响已经创建的任务。

它还注意到项目没有完整的用户登录体系，于是把“素材归谁”单独提出来，让我决定先引入轻量 owner token，还是暂时按本地单用户处理。

ScenePlan 则只允许引用 assetId，不接收模型生成的图片 URL 或任意文件路径。Worker 根据任务快照把素材下载到隔离目录，HTML renderer 最终只拿到项目内相对路径。这样既避开了签名 URL 过期，也能在同一入口拒绝远程 URL 和目录穿越。

我确认方案后，它把实现拆成了 7 个工作包：契约与校验、数据库迁移、Provider 安全层、API、Worker 与渲染器、Web 页面、测试和最终质量门禁。

40 分钟里，它交付了什么？

最终实现里，上传链路大致是这样的：

数据库只保存稳定的 assetId 和 object key，不保存永久 URL 或签名 URL。生成预览时，API 临时返回短期签名地址；相同文件再次上传时，通过 SHA-256 复用已有素材。

前端新增素材库，支持上传、预览和确认授权。创建页只有切到“HTML 动效”时才显示已确认素材；切回“图片视频”，请求里不会携带 media。Worker 下载前还会检查路径是否留在任务隔离目录内，渲染器也会拒绝远程 URL、JavaScript 和任意 HTML 注入。

GLM-5.3 在 31 分钟左右进入最后的测试阶段，整个实现接近 40 分钟。它给出的最终质量门禁结果如下：

检查项	结果
pnpm lint	11/11 通过
pnpm typecheck	19/19 Turbo 任务与脚本通过
pnpm test	386 ä¸ªå•å ƒ/集成测试通过
pnpm build	11/11 通过
pnpm e2e	26/26 Playwright 测试通过
pnpm audit --prod	未发现已知生产依赖漏洞

测试阶段还出现了一个小插曲。端到端测试要求素材选择区只出现“已确认”的图片，但模拟 API 没有处理 ?consentStatus=confirmed，导致页面同时显示待确认和已确认素材。

GLM-5.3 没有删除 UI 断言，而是修正模拟接口，让它遵守真实服务端的过滤语义。

386 个测试全绿，功能就真的安全吗？

模型交付后，我重新启动本地 PostgreSQL、Redis、API 和 Web，用真实 PNG、伪造文件、私有 OSS、浏览器 Network 和数据库做了一轮独立验收。

大部分核心链路确实通过了：

• 真实 PNG 可以上传、生成私有 OSS 预览并完成授权确认，页面状态会从“待确认”变成“已确认”；
• 把 SVG 改名成 .png 上传，API 返回 400 和 SVG_REFUSED；
• HTML 动效模式只显示已确认素材，请求里包含 renderMode: "html-motion" 和对应的 media；切回图片视频模式后不再发送 media；
• user_media 只保存 media/<sha256>.png 形式的 object key，没有 URL 列；相同图片重复上传会返回同一个 assetId；
• 任务快照保存 assetId、SHA-256、object key 和宽高，源素材软撤销后保持不变。

但我也发现了一个 P1 级问题：owner token 没有真正形成隔离。

上传接口的响应里虽然有 x-owner-token，浏览器也把它写进了 localStorage，但后续的素材列表、签名 URL、授权确认等请求没有继续携带这个请求头。更直接的证据是，我打开一个完全没有 localStorage token 的无痕窗口，仍然看到了之前上传的 3 个素材。

上传、格式校验、私有 OSS、授权状态和任务快照都实现了，但“不同用户看不到彼此素材”这个安全前提没有成立。

验收中还发现了两个次要缺口：重复上传虽然确实返回同一个 assetId，但响应里没有需求约定的 created: false；页面和 API 也没有提供真正的 revoke/replace 操作。目前软撤销不影响快照，但数据库外键仍是 ON DELETE CASCADE，如果以后直接硬删除源素材，快照也会被删除。

这个案例对我最大的提醒是：测试全绿，只能说明实现达到了测试里写下的预期，不代表所有安全假设都被覆盖。GLM-5.3 能完成一条复杂的跨层功能，也能写出 386 个测试；但涉及身份、权限和隐私时，仍然要用“全新浏览器能看到什么”“请求头是否真的一路传递”这种攻击者视角重新验收。

案例二：从零做一款 Agent 知识通关游戏

第一个案例是在旧系统里做增量开发。第二个案例，我换成了一个从零开始的任务。

第二个案例也是通过 ZCode 接入 GLM-5.3 完成的。整个配置过程很简单，使用也很丝滑，Coding Plan 的可用额度也更多。我比较推荐大家用这种方式，具体接入方法可以参考上一篇文章。

具体操作就是点模型选择器里的“管理模型”，新增一个模型，模型 ID å¡« GLM-5.3，保存后切换过去即可。

我平时在 JavaGuide 里整理了不少 AI 和 Agent 相关内容，包括 Agent 基础、Prompt 工程、上下文工程、记忆、MCP、Skills、Workflow、Loop 和 Harness 等。资料是有了，但阅读几十篇 Markdown 对初学者并不轻松。

所以我想做一款学习 Agent 知识的通关游戏。

套一层游戏皮肤的选择题网站没什么意思。玩家要在一个失控的实验室里组装 Agent、分配上下文预算、配置记忆、连接工具、修复 Workflow，并在失败后根据可观察结果调整方案。

这个项目叫 Agent Quest：失控实验室。

先把知识变成可以玩的机制

我先参考了 Duolingo、Brilliant、CodeCombat、CheckiO、Flexbox Froggy 和 GitHub Skills 的学习机制，然后整理出一份 551 行的 PRD。

我给 GLM-5.3 的第一条指令仍然是先分析，不写代码：

请严格按照 PRD，从零实现 Agent Quest：失控实验室。

项目代码写入指定目录。开始前先检查目标目录，并完整阅读 PRD 指定的
JavaGuide AI Agent 素材。

第一阶段只分析，不修改文件。请先输出：
1. 对知识素材和学习主线的理解；
2. 游戏玩法与技术方案；
3. 关卡、状态和内容数据结构；
4. PRD 中存在的冲突或风险；
5. 需要我决定的问题；
6. 分阶段实施与验证计划。

我确认后再开始实现。不要把项目做成选择题网站、静态原型，
或无法完整通关的 Demo。

它先读了 12 份 JavaGuide 文档，并把资料分成主线素材、模块辅助素材和最终关卡素材，再按知识类型匹配玩法。单选题只适合少量判断，承载不了整套学习内容。

玩法会跟着知识点变化：

• 前几章让玩家组装 Agent、补全 Prompt、分配 Context 预算和配置 Memory；
• 后几章再处理 MCP 权限、Workflow 编排，以及 Harness 中的日志、预算与停止条件。

这才是我想要的方向：知识点不是页面上的说明文字，而是玩家必须操作的系统规则。

一个小时里，它交付了什么？

我确认方案以后，GLM-5.3 从空目录开始搭项目。

接近 1 小时时，它还在持续实现和验证，没有因为第一版页面能打开就停下来。

最终仓库留下了 3 个提交，依次覆盖内容与判定规则、Phaser 游戏 UI、完整通关测试与实测问题修复。

项目基于 React 18、TypeScript、Vite、Phaser 3 和 Zustand，是一个不依赖后端、运行时 LLM 和远程资源的纯静态应用。

成品包含 8 个模块、32 个主关卡、8 个复习变体、3 个诊断关和一个 10 阶段终局，并提供组件组装、步骤排序、图构建、Schema 编辑、预算打包等 8 类交互。终局要求玩家排查一个因 user-service 响应变慢而出现故障的 Agent 系统：查看 Trace、检查工具权限与人工确认机制、设置 Token 与成本上限，再补齐 verifier 和停止条件。

GLM-5.3 还为 12 份 JavaGuide 资料生成了 sources.json。每条来源都记录 path、hash、标题、摘录和锚点，再配合 content:sync 与包含 11 项检查的 content:check 追踪资料变化。

按照它生成的 VERIFICATION.md，项目通过了 lint、类型检查、内容校验、构建、87 个单元测试和完整 Playwright 流程。E2E 从新游戏开始，依次完成诊断、32 个主关卡、失败复习和 10 阶段终局，生成学习报告，并验证刷新后的进度恢复，全程没有测试专用的跳关按钮。

开发完成之后，它自己打开本地浏览器，一边执行完整通关流程，一边检查真实页面状态。

GLM-5.3 在浏览器自测时还修了几个很真实的问题：多物品拖入同一个废料槽、实验室大厅入口无法通过可访问性方式定位、复习变体没有进入关卡索引导致白屏，以及清空当前复习 ID 后结算面板为空。

第一轮功能跑通后，我又让它单独优化了一次视觉。

新版本把大厅、模块入口和任务引导改成了“复古工业科幻实验室 + 事故处置终端”的风格，完成后又在浏览器里检查实际效果。

实际效果看这里：mp.weixin.qq.com/s/nxp29lV93…

后来我用同一份 PRD 和提示词，让 GLM-5.2 又跑了一次。它同样做出了可运行版本，还用约 30 分钟完成视觉重构、构建和 E2E 验证。

GLM-5.2 也能一次性完成这个任务。不过，我个人感觉整体完成度还是要比 GLM5.3 差一些。

我对 GLM-5.3 的感受和使用经验

两次测试下来，我自己的感受是：GLM-5.3 这次把国产模型的 Coding 上限又往前推了一截，长任务完成度尤其突出。

只写一个工具函数或登录页，很难看出差别。老项目跨模块功能、复杂 Bug、带迁移和兼容要求的重构，以及有清晰 PRD 的零到一项目，更适合检验它。

写代码前，先让它只读项目

复杂任务我会按“探索 → 计划 → 执行 → 验证”推进。第一轮禁止改文件，只汇报当前实现、冲突、风险和待决问题。表结构是否复用、素材如何归属、撤销会影响什么，先确认再实现。

长任务还要把方案、改动文件、剩余事项和验证结果写进计划或文档，不能只留在聊天里。小改动可以跳过这一步，跨模块或涉及权限、迁移时再用。

把“完成”写成字段、状态码和命令

“做一个安全的图片上传”几乎没法验收。我会用一份轻量 Spec 写清目标、约束和完成标准：是否校验 magic bytes、SVG 怎么处理、OSS 是否私有、数据库能否保存 URL、重复上传是否返回同一个 assetId 和 created: false、创建任务时是否冻结快照。

提示词里还要写明运行 lint、typecheck、test、build 和 E2E，并贴出实际结果。

GLM-5.3 正是在验证阶段修掉了模拟 API 过滤、游戏白屏和复习状态错误。涉及外部 Provider 时，我会把默认免费验证和可能产生费用的真实调用分开。

“全部完成”只代表进入人工验收

案例一的 386 个测试全绿，无痕窗口却暴露了素材越权访问。模型补测试时往往沿用实现阶段的理解，测试也会跟着漏掉这些安全假设。

我会换一个方向再验一次：模拟 API 通过后接真实 API，正常浏览器通过后再开没有 token 的无痕窗口；接口说去重成功就查数据库，任务说快照已冻结就修改源素材，再检查任务里的 object_key。权限、支付和迁移类改动，还可以把关键 diff 交给独立会话复核。

所以，我现在看到 Agent 报“全部完成”，只会把它理解成代码已经进入人工验收。

总结

GLM-5.3 这次给我留下最深印象的是，它能在复杂上下文里持续推进，把任务从资料阅读带到可运行、可测试的状态。

在 Guide Sketch Motion 里，它完成了跨前端、API、数据库、对象存储、Worker 和渲染器的用户素材链路；在 Agent Quest 里，它把 12 份 JavaGuide 资料变成了 8 个模块、32 个主关卡和一条能够完整通关的学习路线。

owner token 问题也提醒我：Coding Agent 越能干，人工验收越不能只看代码 diff 和测试绿灯。模型可以承担实现和自测，人仍然要负责权限、安全和最终验收。

GLM-5.3 的能力已经从写代码延伸到理解系统和发现风险。完整权重开放后，开发团队也能在自己的环境里部署和验证这部分能力。

如果你有维护多年的旧项目、需要跨多层修改的功能，或者一直没开工的完整产品，可以拿一个真实任务试试。给它项目、约束、验收标准和足够的工作时间，别只让它写 Demo。