ARTICLE · 1081119
Zcode 开源!来看看源码剖析吧.
“
当产品的信任模型建立在“你的代码不离开本地”之上时，任何隐含的数据上传行为都会摧毁这一信任前提。
📌 本文看点
01
313MB 加密包的完整上传链条还原
02
Agent 运行时三层架构拆解
03
391K 字符 Prompt 的 Claude 血统
2026 年 9 月 21 日，智谱（Z.ai）在数据上传丑闻的压力下紧急开源了 ZCode——不是模型（GLM-5.2/5.3 才是模型），而是包裹在模型外面的那层“壳”：Agent Harness。负责任务编排、工具调度、上下文管理、权限审批的一切。Apache-2.0 协议，三天 6,500+ star。
这篇不写“ZCode 是什么”，写“拆开 ZCode 的壳，看 2026 年的 agent harness 到底怎么造“——数据上传事件只是切入的钩子，真正的干货是运行时设计。
INCIDENT
开局：一次 313MB 的磁盘清理
2026 年 9 月 18 日，技术博主 ferstar 在磁盘清理时发现 ZCode 隐藏目录中有数百兆加密数据包。逆向分析揭示了完整的上传管道：
客户端向 /api/v1/snapshot/upload-credential请求临时凭据和 RSA 公钥 → 后台进程无差别压缩当前工作目录→ 本地生成对称密钥加密数据流 → 服务端公钥加密对称密钥 → 直传阿里云 OSS → 回调注册。
313MB
压缩后文件大小
42,411
文件数量
86.6%
Git 对象占比
564
失败重试次数
解密私钥完全由云端掌握——双层加密的设计意图不是保护用户，是保护传输。用户既不能本地解密，也不知道传了什么。
太原承明科技的企业级取证更狠：6 个工作区、34,549 个文件，上传内容包括数据库访问凭据、云服务 API Key、员工个人信息。登录后自动触发，客户端无法禁用，隐私文档未披露。
「“没有人有 300MB 的提交消息”——HN 社区对智谱“仅上传元数据”说法的回应。300+ MB 的文件里 86.6% 是 Git 对象，这显然是完整的仓库内容，不是元数据。」
72 小时时间线
9/18 下午
第一份致歉，归因于“代码库索引”功能，称数据在生成 Repo Wiki 后“立即销毁”
9/19
紧急补丁。承明科技取证指出 v3.12.3 声称已修复，但上传行为持续到 9/16
9/20
宣布“数据内容不留存”政策
9/21
正式开源 ZCode（Apache-2.0），邀请 CAICT 和绿盟第三方审计
The Register 定性：“damage control rather than a pre-planned initiative“。开源是被动决策，不是预谋。
💡 开源 ≠ 透明：ferstar 指出智谱“擦除了补丁前的提交记录和用于上传文件的源代码”——独立验证原始漏洞范围的路径被切断。开源的是客户端，无法回答服务端数据流、密钥保管的问题。
离岸实体争议
ICP 备案主体是北京智谱华章（境内），但 Z.ai 隐私协议中的数据控制者是新加坡注册的 JINGSHENG HENGXING TECHNOLOGY PTE. LTD.。其马来西亚子公司注册资本约 2 元人民币。跨境传输的责任主体是谁——智谱未正式回应。
ARCHITECTURE
AgentRuntime 拆解：它不是 ReAct
ZCode 不是模型，不是 IDE 插件。GLM-5.2/5.3 才是模型，ZCode 是包裹在模型外面的 Agent Harness。核心代码在 apps/zcode-cli/packages/core/。
三层分离架构
AgentRuntime (src/runtime.js)
编排中枢：AI 模型调用、工具执行协调、上下文构建、会话存储（SQLite）
ToolScheduler (src/tool/scheduler.js)
工具排队与执行排序、冲突检测
ToolExecutor (src/tool/executor.js)
实际工具调用的执行层
💡 Scheduler/Executor 分层值得借鉴：调度与执行分离是好的抽象，调度层可以独立处理并发策略、超时控制和优先级排序。
主循环：结构化 Plan，非纯 ReAct
主循环不是纯 ReAct，而是结构化的 explore → plan → approve → implement 流程。五种权限模式通过 Shift+Tab循环切换：
独有的 Goal Mode粒度比单次 Plan 更粗——用户定义一个复杂目标，Agent 自动拆解为文件编辑、终端命令、测试运行等可执行步骤。
子智能体：代差明显
唯一亮点：跨 Provider 混合子智能体——同一 session 内两个子 agent 可以使用不同厂商的模型。
CONTEXT
上下文压缩：最值得抄的一段
GLM-5.3 的 1M token 窗口，压缩触发阈值（硬编码，不可配置）：
触发阈值 = 上下文窗口 − 输出预留 − 缓冲 token
= 1,000,000 − 21,000 − 13,000
= 966,000 tokens（96.6%）
社区实测了六条配置路径——全被堵死。
两级压缩机制
第一级：Microcompaction（微压缩）——把旧的工具执行结果替换为占位符，只保留最近 5 个工具结果。极低开销。
第二级：Full Compaction（全量压缩）——使用 LLM 对对话历史进行摘要总结。摘要 prompt 被包在显式的 no-tools 前言里，防止压缩过程意外触发工具调用。
Rapid-Refill 熔断器
RAPID_REFILL_TOOL_TURN_THRESHOLD = 3
MAX_CONSECUTIVE_RAPID_REFILLS = 3
它承认了一个现实：当会话的活跃工作集本身就接近窗口大小时，压缩是无效的。与其无限循环压缩，不如直接熔断。
！踩坑提示 🕳
Issue #779——Plan 模式下上下文超限导致无限重规划循环。
PROMPT
391K 字符的 System Prompt
2026 年 8 月 15 日泄露，总计 391,439 字符。
此泄露未获 Z.ai 官方确认。
与 Claude Code 的同源证据
Prompt 工程三个启示
规模膨胀——40 万字符吃掉 1M 窗口约 40%
冗余设计是工程妥协——同一规则在不同模式中重复表述，是当前 LLM 对条件逻辑理解有限的妥协
安全条款的散布式策略——集中放在开头容易被“遗忘”，散布更可靠
SANDBOX
沙箱缺失
「“共享 Agent 执行适配器不提供默认操作系统沙箱”——ZCode 官方文档原话。」
Coding Plan 端点“自动转发至 ZCode 网关，保留请求头与认证信息“，且”此转发未设置额外的逐次用户确认“。
TOOLS
工具系统
24 个工具合约，与 Claude Code 名称完全一致的：Read、Write、Edit、Bash、Agent、SendMessage、WebSearch、WebFetch、Skill、TodoRead、TodoWrite、EnterPlanMode。
ZCode 独有：CronCreate、CronList、CronUpdate、CronDelete。
代码编辑采用 search-replace block 策略。
15 个子包，零生产依赖
PROVIDER
Provider 系统
支持 Anthropic 兼容和 OpenAI 兼容两种协议族，9+ 后端。
！踩坑提示 🕳
Coding 端点和通用端点不可互换。
$5.80/MTok
GLM-5.3（输出 43K/任务）
$30.00/MTok
Claude Opus 5.5（输出 24-35K/任务）
实际每完成一个任务的成本优势约 4×。
COMPARISON
横向对比
钩子可编程性是最关键差距。
BUGS
v3.14.0 的账
packages/zcode-cua（Computer Use Agent）标注“不可用占位实现“。
BENCHMARK
Benchmark 归属
💡 ZCode 作为 harness 的独立评测数据：查不到。没有端到端评测，没有可复现脚本，没有论文。
THE END
Harness 不是护城河
「架构同源性：harness 层面的差异化越来越难维持。真正的护城河在模型能力和分发渠道。」
「安全设计就是核心竞争力：当产品的信任模型建立在“你的代码不离开本地”之上时，任何隐含的数据上传行为都会摧毁这一前提。」
「工程完成度严重不均衡：核心运行时设计精巧，外围桌面体验明显落后。」
给工程师的行动建议
优先审计 @zcode/telemetry和 packages/services中的遥测代码
生产使用务必跑在 Docker/VM里
对比 AGENTS.md（ZCode）和 CLAUDE.md（Claude Code）的功能边界
关注 v3.14.x 的性能修复进展
本文基于 DeepWiki 文档、博主分析和社区讨论，未直接通读完整源码。391K prompt 泄露未获官方确认。
快速参考
我是月谈AI，热衷于AI前沿技术分享。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。