ZCode全面升级：Goal、Subagents与手机远控上线，GLM缓存命中率超98%

2026年8月11日，深度适配GLM-5.2的AI编程工具 ZCode迎来新一轮能力升级。

此次更新的重点已经不再只是代码补全或单轮改代码，而是围绕长程开发任务加入并强化：

• Goal目标模式
• Subagents子智能体
• Remote Control手机远程控制
• 微信/飞书Bot Channel
• 闲时任务

ZCode官方目前将自己定位为面向GLM-5.2真实编程工作流的 Agentic Development Environment（ADE，智能体开发环境），通过自研ZCode Agent，将项目文件、终端、浏览器、Git状态、权限和模型上下文放在同一个任务中持续推进。

与传统IDE中增加一个AI聊天框不同，ZCode希望让Agent成为主要执行者：

理解需求
↓
分析代码库
↓
拆解任务
↓
修改文件
↓
运行命令
↓
打开网页验证
↓
发现问题
↓
继续修改
↓
测试通过
↓
完成交付

这次上线的Goal和Subagents，则进一步把这条链路从“需要开发者不断说继续”，推向“给出目标后自主持续执行”。

ZCode体验入口：

https://zcode.z.ai/cn

ZCode是什么？

ZCode是智谱/Z.ai围绕GLM系列模型打造的AI编程开发环境。

官方当前重点适配 GLM-5.2。GLM-5.2拥有100万Token上下文，并针对Long-Horizon Tasks，也就是长程任务进行了专项训练。ZCode则负责将模型能力与代码库、终端、Git、浏览器、工具调用和权限系统结合。

简单来说：

GLM-5.2
=
负责理解、推理和生成

ZCode
=
负责给模型上下文、工具、任务环境和执行能力

同一个模型放进不同Coding Harness或Agent框架中，最终能够完成的真实开发任务可能存在明显差异。

这也是为什么AI编程竞争正在从：

“谁的模型代码Benchmark更高”

进一步变成：

“模型＋Agent Harness谁能真正稳定完成一个项目”。

98.10%缓存命中率是什么概念？

此次传播中最吸引眼球的数据，是：

ZCode缓存命中率达到98.10%。

根据AIBase援引的智谱内部数据，ZCode针对GLM的上下文缓存复用进行了专项优化，内部统计的缓存命中率达到98.10%，并称由此使有效Token利用量得到明显提升。

不过，这个数字需要注意口径。

ZCode官方公开文档目前确认提供Token用量、上下文组成、模型消耗和Coding Plan额度等统计功能，但没有在文档中公布98.10%这一数字对应的完整Benchmark条件、会话长度、冷启动比例和具体计算方法。

因此更准确的表述应该是：

根据媒体援引的智谱内部测试数据，ZCode针对GLM优化后的缓存命中率达到98.10%。

而不是：

所有用户使用ZCode都能稳定达到98.10%。

实际缓存命中率会受到任务、会话长度、模型切换和上下文变化等因素影响。

为什么Coding Agent特别在意缓存？

普通AI聊天通常只有几轮对话。

Coding Agent却可能围绕一个项目执行几十甚至上百轮模型调用。

上下文中不断重复出现：

• 系统提示词
• 项目规范
• 工具定义
• AGENTS.md
• 已读取代码
• 任务历史
• 前几轮工具结果
• 当前项目结构

假设一个Agent每次请求需要处理100万Token上下文，而其中98万Token此前已经出现过，那么高缓存命中可以避免每一轮都重新按完整输入成本处理相同内容。

所以对长程Coding Agent来说，真正重要的不只是：

模型单次调用多少钱

而是：

一整个开发任务
需要重新计算多少Token

ZCode官方也已经提供编程套餐统计，可以查看模型Token消耗、套餐额度、工具调用次数和当前上下文组成。

内部Z.ai Code Bench：同模型下ZCode高2.39%

除了缓存数据，此次还有一项值得注意的测试结果。

AIBase援引智谱内部 Z.ai Code Bench 数据称，在同样使用GLM-5.2的条件下，搭配ZCode的任务整体通过率，比搭配Claude Code高出 2.39%。

这项数据想表达的是：

GLM-5.2 + ZCode
vs
GLM-5.2 + Claude Code

也就是说，尽量固定模型，只比较不同Agent Harness对任务完成率的影响。

不过同样需要说明：

这属于智谱内部Benchmark，目前没有公开完整测试集、任务数量、运行参数和第三方复现结果。

因此不能据此写成：

ZCode编程能力已经全面超过Claude Code。

更合适的结论是：

智谱内部测试显示，针对GLM-5.2进行专项适配的ZCode，在部分真实长程开发任务中能够更充分发挥GLM模型能力。

第一项大升级：Goal目标模式

这次最值得实际使用的功能，很可能是 Goal Mode。

过去使用Coding Agent做复杂项目，经常出现这样的情况：

用户：把这些TypeScript错误全部修掉

Agent：修了一部分

用户：继续

Agent：又修了一部分

用户：继续

Agent：还有3个错误

用户：继续

Goal模式希望把这套过程改成：

用户：
/goal 修复全部TypeScript错误，并确保测试通过

↓
Agent执行
↓
自动校验
↓
没完成
↓
自己继续
↓
再次校验
↓
直到真正满足目标

ZCode官方文档明确表示，设定Goal之后，每一轮结束都会自动进行目标校验；如果没有达成目标，就根据校验结果进入下一轮，不需要用户不断输入“继续”。

Goal不是“运行很久就算完成”

Goal模式比较关键的设计是：

它要求目标能够被验证。

官方给出的示例包括：

• 重构整个模块并保持测试通过
• 修复所有TypeScript编译错误
• 把页面Lighthouse性能分提高到90以上

相比：

优化一下这个网站。

更适合Goal的写法是：

把pnpm test全部跑通，并将首屏加载时间控制在2秒内。

原因是后者存在明确验收条件。

Goal会使用真实证据校验结果

ZCode官方特别强调：

一轮Agent运行结束，并不会因为“Agent说自己完成了”就判定目标成功。

校验会寻找：

• 实际修改后的文件
• 命令输出
• 测试结果
• 可验证的项目状态

如果还有待办事项没有完成，Goal不会结束，而是继续下一轮。

这实际上解决了Coding Agent长期存在的一个问题：

模型很容易宣布“任务完成”，但代码实际上并没有真正跑通。

Goal把结束条件从：

模型觉得完成了

改成：

有证据证明完成了

一个Goal可以连续执行很多轮

ZCode官方文档展示的案例中，一个研究任务连续运行了20轮。

每一轮都会在右侧面板记录：

• 当前目标
• 已使用时间
• 当前迭代
• 完成的清单
• 仍未完成的任务
• 下一步动作

整个流程类似：

第1轮
分析代码

第2轮
找到问题

第3轮
修改模块

第4轮
运行测试

第5轮
测试失败

第6轮
定位新问题

……

第20轮
全部验证通过

对跨文件重构、性能优化和复杂Bug来说，这比传统“一问一答”更接近真实工程流程。

Goal中途仍然可以人工介入

自主执行不意味着任务开启后用户就失去控制。

Goal支持：

/goal pause
/goal resume
/goal replace
/goal clear

用户也可以直接用自然语言：

先停一下。

改成优先修API问题。

不要继续重构数据库部分。

ZCode会保留此前已经完成的轮次、文件和工具调用状态，然后按照新的要求继续。

Goal也不会无限运行。

以下情况会停止自动推进：

• 目标验证完成
• 用户主动暂停
• 用户清除目标
• 达到该Goal配置的用量上限

第二项升级：Subagents子智能体

一个Agent处理一个大型全栈项目，很容易出现上下文越来越复杂的问题。

例如同时需要：

• 调查前端Bug
• 检查数据库
• 阅读API文档
• 写测试
• 进行代码Review

如果全部塞给同一个Agent顺序执行，会大量占用主上下文。

ZCode的Subagents允许主Agent创建独立上下文，把不同工作拆给多个子智能体执行，再将结果汇总回主任务。

例如：

主Agent
│
├── Explore Agent
│   └── 查找登录Bug调用链
│
├── General Agent A
│   └── 修复前端状态问题
│
├── General Agent B
│   └── 补充后端测试
│
└── Review Agent
    └── 检查最终改动

完成以后，每个Subagent把结论返回主Agent，由主Agent继续决定下一步。

内置两个Subagents

ZCode当前内置两种子智能体。

general-purpose

这是通用型Agent，拥有完整工具权限。

适合：

• 修改代码
• 修复独立问题
• 执行命令
• 整理文件
• 独立完成小功能

Explore

Explore是只读型代码库探索Agent。

它不会：

• 创建文件
• 修改文件
• 移动文件
• 删除文件

主要用于：

• 搜索代码
• 梳理调用链
• 查找实现位置
• 分析项目结构
• 收集证据
• 阅读外部资料

因此，可以先让多个Explore并行调查问题，再让主Agent决定真正修改哪些文件。

可以自定义自己的Subagent

ZCode目前还在Beta阶段开放 用户级自定义子智能体。

用户可以设置：

• Agent名称
• 模型
• 描述
• 工具权限
• 系统提示词
• 标识颜色

例如自己创建：

code-reviewer
test-writer
security-reviewer
frontend-expert
database-expert

自定义Agent会保存到：

~/.zcode/agents/<name>.md

启用后，可以由主Agent自动判断是否调用，也可以在聊天中通过@手动指定。

不过目前自定义Subagent仍是Beta，而且主要是全局/用户级配置，官方暂不支持直接在设置中创建项目级Subagent。

多Agent为什么适合全栈开发？

假设用户提出：

给这个电商项目增加优惠券系统，包括后台配置、API、前端领取、订单结算和测试。

一个Agent可能需要同时理解：

数据库
+
后端接口
+
权限
+
前端状态
+
订单逻辑
+
测试

使用Subagents后，可以拆成：

Explore
→ 先分析现有优惠体系

Backend Agent
→ 数据库和API

Frontend Agent
→ 页面与交互

Test Agent
→ 测试覆盖

Review Agent
→ 最终检查

主Agent负责协调和整合。

这也是ZCode此次强调“多Agent协作”的真正意义，而不是简单同时打开多个聊天窗口。

第三项：Remote Control手机远程控制

长程Agent任务可能运行几十分钟甚至几个小时。

开发者不可能一直坐在电脑前。

ZCode的Remote Control允许用户从手机临时接入当前桌面窗口，查看：

• 工作区
• 任务
• Agent会话
• 执行进度

并继续给Agent发送指令。

打开ZCode后点击手机图标，会生成：

• 二维码
• 临时连接地址

手机扫码即可进入当前桌面工作区。

一个很重要的点：代码没有跑到手机上

Remote Control并不是把整个代码仓库同步到ZCode云端或手机。

手机只是一个：

控制界面。

真正的：

• 文件读取
• 代码修改
• Shell命令
• Git操作
• Agent执行

仍然发生在原来的开发环境。

例如：

所以你在外面用手机告诉Agent：

测试失败了，再检查一下登录模块。

手机只是把这句话传回桌面ZCode。

代码仍然在原来那台机器上修改和执行。

微信和飞书其实属于Bot Channel

这里需要纠正不少报道中的一个口径。

Remote Control本身是扫码或手机浏览器临时控制。

微信和飞书则属于另一项能力：

Bot Channel。

官方目前支持：

• 微信
• 飞书

微信可以扫码绑定Bot；飞书则创建应用并通过绑定命令完成连接。

之后可以直接在微信里对ZCode说：

看一下刚才那个任务做到哪了。

或者在飞书里：

继续修复剩下三个测试。

Bot会把请求传给ZCode Agent，然后返回任务进度。

Remote和Bot应该怎么选？

官方对两种方式的定位非常清晰。

Remote Control

手机扫码
↓
临时进入
↓
看任务
↓
追加指令
↓
使用结束

适合偶尔离开电脑后看一下。

Bot Channel

微信 / 飞书
↓
长期保留入口
↓
随时发消息
↓
持续推进任务

更适合日常反复使用。

两种方式最终操作的都是桌面端已经存在的ZCode会话。

Remote Control并不是完整云IDE

Remote Control也存在明确边界。

手机端目前不能：

• 浏览电脑上的任意目录
• 打开桌面端从没登记过的项目
• 新建SSH连接
• 新建WSL环境
• 新建Docker连接

这些环境必须先在桌面端配置。

并且远程控制期间：

电脑必须保持ZCode运行并联网。

如果桌面端关闭，手机端也无法继续执行。

所以它更准确的名称就是：

Remote Control，而不是Cloud Development。

第四项：闲时任务

还有一些编程任务并不急着立即执行。

例如：

• 给整个代码库补注释
• 检查文档和代码是否同步
• 分析全部依赖
• 批量补测试
• 整理大型仓库
• 生成代码库报告

这些工作可能要运行很长时间，但晚上完成和现在完成区别不大。

ZCode的 闲时任务允许开发者把任务送进全局队列，等待平台算力富余时自动执行。

官方目前的核心卖点是：

执行过程免费，不消耗Coding Plan套餐额度。

闲时任务和定时任务完全不同

两者容易混淆。

定时任务

用户指定：

每天上午9点执行
每周五执行
每月1日执行

可以重复运行。

闲时任务

用户只提交一次：

什么时候有空闲算力
什么时候帮我跑

它不会承诺具体开始时间。

例如：

分析整个代码仓库，找出所有废弃API，并生成migration-report.md。

如果不急着拿结果，就可以扔进闲时任务队列。

长任务中途到时间也不会从头开始

ZCode官方文档表示，闲时任务单次执行存在时长上限。

如果一轮没有完成，会：

执行
↓
到达单轮上限
↓
重新进入队列
↓
下一次继续原来的会话

而不是重新从第一步开始。应用重启后任务状态也会保留。

这特别适合大型代码分析和批量工程任务。

但闲时任务目前还有不少限制

首先，它仍在 分批开放。

目前只面向部分Coding Plan订阅用户逐步开放。

使用条件包括：

• 需要有效Z.ai或BigModel Coding Plan
• Start Plan不支持
• 纯API Key模式不支持
• 当前只支持桌面端本地项目

另外，因为任务最终仍在用户机器执行，所以：

电脑需要保持唤醒。

如果电脑睡眠，任务不会丢失，但也不会继续执行。

因此它不是把代码上传到云端后，用户直接关电脑睡觉。

ZCode Agent还可以自己操作浏览器

除了这四项重点升级，ZCode已经内置Browser Use能力。

Agent可以自己：

• 打开网址
• 点击按钮
• 填写表单
• 滚动页面
• 截图
• 根据页面结果决定下一步

对于前端开发，这让任务可以进一步闭环：

修改React代码
↓
启动开发服务器
↓
打开页面
↓
实际点击按钮
↓
检查界面
↓
发现错误
↓
继续修改

而不只是Agent在终端里说：

修改应该已经生效了。

ZCode已经从IDE变成ADE

传统IDE的核心是：

人在写代码
AI帮助人

ZCode将产品定义为Agentic Development Environment后，逻辑开始变成：

人设定目标
Agent执行
人在关键节点介入

官方提供的执行模式也体现了这一点。

ZCode Agent目前包含：

• 变更前确认
• 自动编辑
• 计划模式
• 完全访问

四种执行策略。

对于：

• 生产数据库
• 关键代码
• 部署配置

可以保持严格确认。

对于：

• 小功能
• 测试项目
• 明确的低风险修改

则可以提高自动执行程度。

GLM-5.2为什么适合ZCode？

GLM-5.2本身就是面向长程任务设计的旗舰模型。

官方重点强调：

• 100万Token上下文
• 项目级工程上下文
• 长程执行
• 工程规范遵循
• 多步骤开发

而Coding Agent的真实任务恰好会持续产生：

需求
+
代码
+
终端日志
+
测试结果
+
Git变化
+
浏览器状态
+
工具返回值

ZCode做的，就是持续把这些工程状态整理并提供给GLM。

所以智谱所说的“最佳拍档”，本质并不是：

ZCode只能调用GLM。

事实上，ZCode也支持通过OpenAI / Anthropic兼容协议接入第三方模型服务。

而是：

ZCode针对GLM-5.2的工具调用、上下文和长程工作方式进行了更深的专项适配。

新用户目前可以免费体验

ZCode本身提供新用户体验额度。

当前官方文档显示，新用户连接BigModel后，从首次使用开始的5天内，每天可以获得：

这项额度只在前5天每日发放，并不是永久每天500万Token。

ZCode工具本身可以下载安装，正式长期使用GLM则可以连接BigModel或Z.ai的GLM Coding Plan，也可以配置自己的模型API。

8月31日前还有1.5倍额度活动

根据AIBase 8月11日报道，为庆祝ZCode用户突破百万，平台当天13:00对用户GLM Coding Plan额度进行了一次重置，并称 2026年8月31日前，通过ZCode使用GLM Coding Plan可以获得1.5倍限时额度加成。

该报道还称，叠加缓存优化后，整体可用量可接近常规额度的1.8倍。

这里同样需要注意：

1.8倍属于活动及缓存效果的估算，并不是每个用户一定能固定获得1.8倍实际任务量。

具体消耗仍会受到：

• 缓存命中
• 模型
• 推理强度
• 项目规模
• Subagent数量
• Tool Calls
• 输出Token

等因素影响。

正式使用时，以ZCode内的“使用统计”和Coding Plan实时额度为准。

Goal＋Subagents组合才是这次真正的重点

单独看Goal，它解决的是：

任务能不能自己持续执行。

单独看Subagents，它解决的是：

复杂任务能不能拆给多个上下文并行处理。

两者组合以后才会形成更完整的工作方式：

用户设定Goal
↓
主Agent制定计划
↓
Explore Subagents并行调研
↓
General Subagents分别修改
↓
主Agent整合结果
↓
运行测试
↓
Goal自动验证
↓
未通过
↓
继续拆任务
↓
再次执行
↓
通过后结束

这开始非常接近一支小型AI开发团队。

一个完整全栈项目可以怎样跑？

例如用户提出：

给这个SaaS项目增加团队邀请功能。支持邮件邀请、邀请码失效、成员权限，并确保前后端测试全部通过。

Goal可以设定：

完成团队邀请系统：
1. 支持邮件邀请
2. 邀请链接24小时失效
3. 支持Admin与Member权限
4. pnpm test全部通过
5. 浏览器完成一次真实邀请流程

然后由主Agent：

Explore

分别调查：

• 用户数据模型
• 邮件模块
• 权限体系
• 前端路由

Backend Subagent

完成：

• 数据库
• API
• Token
• 权限验证

Frontend Subagent

完成：

• 邀请页面
• 成员管理
• Error State

Test Subagent

补充：

• API测试
• 权限测试
• 过期Token测试

最后主Agent启动应用，通过ZCode浏览器走完整流程。

Goal再检查：

功能是否存在
+
测试是否通过
+
页面是否真的可用

未达到目标就继续执行。

这比单纯让模型“一次性生成团队邀请功能”更接近真实软件工程。

哪些用户最适合ZCode？

GLM Coding Plan用户

这是最直接的目标用户。

ZCode围绕GLM-5.2进行了深度适配，能够直接使用BigModel或Z.ai账号中的Coding Plan。

全栈开发者

Subagents特别适合同时处理：

• 前端
• 后端
• 数据库
• 测试

的跨模块任务。

大型代码仓库

100万上下文、Explore和Goal更适合长任务与跨文件修改。

独立开发者

可以设定Goal后让Agent持续运行，再从手机查看进度。

经常离开电脑的人

Remote Control和微信/飞书Bot允许开发者在外面继续跟进桌面任务。

有大量非紧急任务的团队

闲时任务可以把代码分析、文档检查等工作放进免费算力队列。

当前仍有哪些限制？

98.10%不是所有用户的保证值

该数字来自媒体援引的智谱内部测试，官方文档没有公开完整Benchmark方法。

2.39%同样属于内部Benchmark

Z.ai Code Bench尚缺乏公开第三方复现，因此不能直接推导为ZCode全面优于Claude Code。

Goal仍然受权限和用量限制

遇到需要确认的高风险操作时，仍可能等待用户；达到Goal用量上限后也会停止。

自定义Subagent还是Beta

目前主要支持用户级子智能体，项目级配置仍有限。

Remote需要桌面端在线

手机只是控制层，桌面ZCode关闭后无法继续工作。

微信/飞书不是Remote Control本身

两者属于Bot Channel；Remote Control是二维码/链接临时连接。

闲时任务不会承诺开始时间

什么时候执行取决于整体算力余量，而且目前仍在分批开放。

闲时任务不能直接关电脑

任务仍在本地机器运行，电脑睡眠后执行会暂停。

总结

2026年8月11日，ZCode围绕GLM-5.2的长程编程能力继续升级，Goal、Subagents、Remote Control、Bot Channel和闲时任务已经构成一套更完整的Agentic Engineering工作流。

其中：

Goal解决“持续干”。

设置可验证目标后，Agent可以自动执行、检查和继续迭代，直到目标真正达成。

Subagents解决“分头干”。

不同子智能体可以在独立上下文中并行探索、编码、测试和Review，再把结论返回主Agent。

Remote Control和Bot Channel解决“人不在电脑前也能继续干”。

Remote使用手机扫码临时控制，微信和飞书则通过Bot Channel长期接入；代码仍然执行在桌面、本地SSH、WSL或Docker原环境。

闲时任务解决“不着急的活免费排队干”。

订阅用户可以把非紧急任务放进算力闲时队列，在权益规则内免费执行、不扣套餐额度。

至于此次被大量讨论的 98.10%缓存命中率 和 Z.ai Code Bench高2.39%，目前均来自媒体援引的智谱内部数据，还需要更多公开测试方法和第三方验证。

但相比单个Benchmark数字，这次ZCode升级更值得关注的是Coding Agent产品形态的变化：

过去是：

开发者写代码
AI在旁边帮忙

现在越来越接近：

开发者定义目标
↓
AI团队执行
↓
系统自动验证
↓
开发者在关键节点决策

AI编程工具的竞争重点，正在从“谁写一段代码更好”，走向：

谁能更稳定地把一个真实工程任务，从需求一直推进到验证完成。

相关链接

• ZCode官方网站
• ZCode官方文档