ARTICLE · 1066783
从 ZCode 事件看 AI 编程工具的数据安全边界——基于 FRT 架构原则的客观分析
——基于 FRT 架构原则的客观分析
一、ZCode 事件说明了什么
2026 年 9 月，开发者在检查本地环境时发现，智谱 AI 编程工具 ZCode 存在后台生成加密数据包并向云端存储服务上传的行为。
根据公开报道及相关开发者的独立取证，相关数据包可能包含工作区代码、Git 历史以及其他研发环境信息；有企业用户披露，其工作区涉及超过 3.29 万个文件。
智谱随后公开回应，表示相关行为与“代码库索引 / Repo Wiki”等功能有关，并进行了致歉、整改和代码开源，同时邀请第三方机构参与安全审查。
因此，对这一事件最准确的理解，不应简单归结为“加密有没有做好”，而应进一步追问：
一个 AI 工具为了实现某项云端能力，究竟可以取得多少本地数据？谁决定这些数据可以离开本地？用户能否明确知道、控制并验证这一过程？
这才是事件真正具有行业意义的地方。
二、问题的核心不是“云”还是“本地”
云计算本身并不等于不安全，本地运行也不自动等于安全。
真正的区别在于：
数据出域是否具有明确、可验证、可追溯的授权边界。
传统 SaaS / 云端 AI 工具通常采用类似的工作模式：
本地工作区
↓
客户端采集
↓
加密/传输
↓
云端计算与存储
↓
返回结果
这种模式可以获得强大的云端计算能力，但同时产生一个基础问题：
为了完成某项功能，系统到底需要获取多少数据？
如果系统能够默认取得整个工作区，那么“功能需要的数据”和“系统实际上取得的数据”之间就可能出现明显差异。
ZCode 事件正好把这个问题暴露到了公众面前。
三、FRT关注的不是“有没有上传”，而是“谁拥有数据出域的判位权”
FRT 的安全设计并不是简单规定“永远不能联网”，而是将数据出域本身视为一个需要经过规则判定的行为。
可以抽象为：
本地数据
↓
是否允许出域？
↓
真源规则
↓
唯一判位出口
┌──┼────┐
↓ ↓ ↓
ALLOW DENY UNKNOWN
其中最重要的一点是：
UNKNOWN 不是默认为允许，而是在判定依据不足时保持未知。
因此，系统不能因为“这个功能可能需要数据”就自动把未知状态升级为允许。
这与传统“功能先运行、数据再治理”的思路存在明显区别。
四、FRT强调原始资产与逻辑状态的分离
在适当的部署模式下，FRT 可以把企业原始资产留在本地，而跨节点或跨载体交换经过定义的：
状态
判定
索引
证据
因果链信息
而不是默认把完整研发资产发送到云端。
因此需要区分两个概念：
原始资产
例如：
企业源码
Git 历史
内部文档
数据库配置
密钥及凭证
未公开研发资料
逻辑状态
例如：
某项规则是否成立
某个对象处于什么状态
某次判定为什么成立
某条证据来自哪里
某个状态能否被第三方复解
二者不是同一种数据。
FRT 的目标，是尽可能让系统在不需要原始资产出域的情况下完成逻辑协作。
当然，这属于架构设计原则，并不意味着任何 FRT 部署都天然不会处理原始数据；具体安全能力仍取决于实际部署方式和边界配置。
五、加密解决的是“传输保护”，不是全部的数据主权问题
数据加密非常重要，但：
“数据被加密”与“用户始终掌握数据控制权”是两个不同的问题。
如果一个系统拥有：
数据采集权
数据上传权
云端存储权
解密或处理能力
那么即使传输过程采用强加密，数据仍然已经离开了用户原来的安全边界。
因此企业真正需要知道的是：
什么数据被采集？
什么条件下可以采集？
是否默认采集？
数据去了哪里？
谁能够解密或处理？
用户能否拒绝？
系统能否证明某一次上传为什么被允许？
这比单独讨论 AES、TLS 或其他密码学算法更加接近企业实际安全问题。
六、FRT的另一个核心原则：审计不是事后补救，而是运行时的一部分
传统安全体系往往在事件发生后进行审计：
发生问题
↓
取日志
↓
调查
↓
追责
FRT 所强调的是另一种方式：
运行
↓
产生判定
↓
记录判定来源
↓
保留证据链
↓
允许独立复解/否证
也就是说：
不是出了问题以后才问“为什么允许”，而是在允许发生的时候就留下“为什么允许”的可验证依据。
这也是目前 FRT-LAS 等系统正在工程化验证的方向。
需要特别说明的是，审计链本身并不自动证明整个系统绝对安全；它解决的是判定可追溯、来源可复核以及异常能够被发现和追问的问题。
七、这也是 FRT 与普通 Agent / AI 编程工具的一个重要架构差异
普通 AI Agent 的核心目标通常是：
让系统完成任务。
因此它天然会关注：
工具调用
工作流
上下文
云端模型
自动执行
数据检索
而 FRT 更强调：
系统在完成任务之前，先确定“什么可以做、什么不能做、为什么可以做”。
因此两者关注点不同：
维度
常见 AI Agent 架构
FRT 架构原则
首要目标
完成任务
在约束下完成任务
数据边界
依功能需要确定
由明确规则判定
未知状态
往往继续执行或请求更多信息
UNKNOWN 可作为合法终态
数据出域
可以成为功能链的一部分
需要明确判位
判定来源
可能分散在模型、代码、配置中
强调唯一真源
审计
日志/事后分析
判定链本身可追溯
原始资产
可进入云端处理链
可设计为本地闭环
第三方验证
依赖系统日志和厂商配合
强调独立复解和否证
这里并不是说某一种架构在所有场景下都优于另一种，而是两者解决的问题不同。
八、ZCode事件对企业真正的启示
这个事件最值得企业关注的，并不是某一家产品本身，而是 AI 工具正在进入企业研发环境以后，传统“客户端 + 云端 AI”的数据边界正在受到挑战。
过去：
“代码上传云端 → 云端帮我完成任务”
是一个非常自然的产品模型。
但进入金融、科研、军工、制造、芯片、软件企业等高敏感场景以后，问题会变成：
“我可以让 AI 帮我工作，但我是否必须把全部研发资产交给 AI 所在的平台？”
这两个问题并不等价。
未来企业 AI 的一个重要方向，很可能不是简单地继续扩大“能够上传什么”，而是建立更加明确的：
数据最小化 + 本地闭环 + 权限判定 + 可验证审计
体系。
九、结论
ZCode 事件不应简单被概括为“某个 AI 工具不安全”。
它更值得被看作一次关于 AI 数据边界 的现实案例。
它提醒我们：
AI 系统的安全边界，不仅由加密算法决定，也由“什么数据能够离开本地、谁有权决定、决定依据来自哪里、事后能否证明”决定。
FRT 所选择的是另一条工程路线：
原始资产可以留在本地；逻辑协作可以围绕状态和证据进行；数据出域必须有明确规则；未知不能自动升级为允许；判定必须能够追溯到真源。
这并不意味着 FRT 可以仅凭架构描述就宣称“绝对安全”。
真正有价值的是：
把这些原则做成可以运行、可以测试、可以复解、可以被第三方否证的工程系统。
这也是 FRT 当前 LAS、ACF-LMS、FRT-COM 等工程工作的真正意义：
不是宣称“相信我”，而是让系统自己留下“为什么这样判”的证据。