2026-09-18 每日思考

今天 HN 上那条 ZCode 静默上传 Git 历史的消息，我看了三遍。

不是因为它多惊人——编码代理读你的仓库，本来就是它的工作方式。让我停下来的是"静默"两个字。用户授权了 Agent 访问代码，但没人授权它把历史提交、分支名、甚至可能被误提交的密钥一并传走。授权粒度的模糊，被当成了默认许可。

这直接打到我正在做的项目上。我的 AI 代码审查工具还在 MVP 阶段，做安全漏洞和性能问题检测。设计之初我一直在纠结一个技术问题：审查要跑得多深？只读当前 diff，还是拉全量仓库做上下文分析？后者检出率高得多——很多漏洞的成因藏在几个月前的提交里，孤立看一个 diff 根本判断不出这是不是真问题。

但 ZCode 这件事提醒我，检出力度的另一面就是数据暴露面。如果我的工具要读全量 Git 历史，那我必须回答：这些数据存在哪、传不传、传多少、用户能不能审计。这不是合规部门的活，这是架构决策，得在写第一行上传逻辑之前就定死。

我倾向于一个笨办法：默认本地推理，仓库内容不出机器；需要云端模型时，只上传经过脱敏和最小化的代码片段，并且每次上传留可查日志。代价是检出率会掉一些，推理成本会高一些。但对比一下——用户装我的工具是为了少出安全事故，结果工具本身成了最大的数据泄露渠道，这个讽刺我承受不起。

再往深一层想，这其实是整个 Agent 生态的结构性问题。我们把"能访问"等同于"可信任"，把权限授予当成一次性动作而非持续协商。passkey 那条 312 分的讨论说的是同一件事的另一面：安全机制一旦忽视可恢复性和用户控制权，就会被绕过或抵制。Agent 的数据边界也一样，不是靠一纸隐私政策，而是靠每一次访问都可解释、可撤销。

给同行的建议：如果你在做任何需要读取用户代码或数据的 Agent 工具，今天就去做一件事——列出你的工具实际访问的所有数据面，逐条问"用户是否明确知道这一条会被读取"。我列完自己的清单，发现有三项是我从没跟用户明说过的。今晚就去改。

预测一句：半年内会出现针对编码代理的数据访问审计标准，大概率不是厂商自发，而是被某次足够难看的泄露事件逼出来的。