面向 AI 智能体的 zkTLS：验证网页数据而不泄露秘密

zkTLS 让 AI 智能体能够证明私密网页数据来自哪里，同时只向验证者披露必要字段。它可以把经过身份验证的 HTTPS 响应变成「该账户处于活跃状态」或「该购买已经完成」之类的证据，而无需暴露会话 Cookie、完整账户记录或响应中的无关数据。

这个承诺比「无需信任的智能体」更窄，也因此更实用。奠定基础的 DECO 研究展示了如何在不依赖可信硬件、不修改源网站的前提下证明 TLS 数据来源 （ACM CCS，2020）。到 2026 年，商业问题已经不再是网页证明是否可行，而是剩余信任、延迟、数据源脆弱性和运维成本是否适合你的智能体工作流。

本文专门回答这项架构决策。若要了解更广泛的技术现状，请先看我们的2026 年零知识证明生产指南。身份、KYC 与供应链场景则由加密行业之外的零知识应用单独覆盖。

对 AI 智能体而言，zkTLS 是什么？

zkTLS 是一类协议，它让 HTTPS 会话中的选定事实可由另一方验证。网站通常只会看到普通 TLS 连接，无需新增证明 API。由以太坊基金会 Privacy Stewards of Ethereum 推动的开源项目 TLSNotary，把流程描述为证明者在验证者参与 TLS 会话的情况下请求数据，随后进行选择性披露与验证 （TLSNotary 文档）。

1. 请求：用户设备或智能体访问指定的 HTTPS 数据源，认证材料保留在请求的私密部分。
2. 见证：验证者通过 MPC-TLS 参与会话，或在代理模式下观察加密网络路径。
3. 承诺：协议把选定的请求与响应字段绑定到被见证的会话。
4. 披露：证明者只展示某个值、脱敏片段或派生条件，其余内容继续隐藏。
5. 决策：应用在允许智能体继续行动前，验证证明或受信任公证方的证明书。

隐私边界必须说清楚。如果证明在用户设备上生成，zkTLS 可以向下游验证者隐藏凭证。它不会自动向本地智能体运行时、浏览器扩展，或代为发起请求的 TEE 隐藏凭证。先画出明文出现在哪里，再把架构称为隐私保护。

AI 智能体究竟能证明什么？

有用的 zkTLS 声明需要绑定指定来源、具体响应字段、主体和有效时间窗口。「智能体检查了某个网站」过于含糊，不足以授权资金或数据访问。

最后一列就是产品边界。zkTLS 证明会话记录的来源与披露内容的一致性。它不会让错误的数据源变得真实、让旧页面变得新鲜、让提示词变得安全，也不会让智能体决策自动正确。

zkTLS 是否无需信任、可公开验证？

任何可移交的 zkTLS 声明都并非完全无需信任。验证者必须在 TLS 会话发生时参与，因为客户端本身知道对称会话密钥，否则可能伪造记录。如果你的后端在线并亲自运行验证者，它可以直接信任结果。如果智能合约、离线审核者或许多后续使用者都需要结果，就必须由受委托验证者签署证明书，而这些使用者会信任该公证方。

TLSNotary 在 2026 年 6 月的说明中把它称为指定验证者边界：零知识保护选择性披露，并阻止证明者篡改已展示的片段，但没有参加会话的人仍要依赖当时见证会话的一方 （TLSNotary，2026 年 6 月）。公证方密钥、法定人数、撤销流程与审计记录都是生产基础设施，不是可以忽略的 SDK 默认值。

为什么 zkTLS 在 2026 年值得关注？

三项变化让它成为智能体团队的近期议题：

• 使用场景从身份证明扩展到操作回执。智能体正在读取已登录面板、调用付费 API、预订服务并改变外部状态。可验证响应可以成为结算或审批输入。
• 浏览器与代理路径降低了集成摩擦。证明可以靠近用户的已认证会话生成，无需把凭证转移到中央抓取器。
• 取舍已经可以测量。TLSNotary 发布可复现的测试数据，并同时提供 MPC 和代理模式。

不要把发展势头误当成成熟度。截至 2026 年 8 月 11 日复核时，TLSNotary 在 GitHub 上的最新版本是 v0.1.0-alpha.15，并标记为预发布 （官方发布说明）。应固定版本、执行独立安全审查，并在证明者、验证者、解析器和证明书格式之间设计可迁移边界。

应该选择哪种 zkTLS 架构？

TLSNotary 在 2026 年 5 月公布的基准中，对 1 KB 请求与 2 KB 响应进行测试。代理模式在所测原生与浏览器网络配置下耗时 1.0 至 2.0 秒，MPC 模式为 3.6 至 15.5 秒 （TLSNotary 基准工具）。这些是项目维护的参考测量，不是你的 SLA。响应大小、脱敏逻辑、设备、网络、数据源行为和证明声明都会改变结果。

生产环境中会在哪里出错？

• 数据源漂移：JSON 路径、重定向、压缩方式、反机器人规则或 A/B 测试变化，都可能在业务语义不变时破坏提取。
• 重放：如果验证者不检查合适的随机数、时间戳、受众、主体和过期时间，旧但有效的证明仍然危险。
• 解析歧义：密码学可以验证字节，但两个组件可能对字节含义有不同理解。请求、响应、数字、字符编码与错误状态都要规范化。
• 凭证暴露：浏览器工具需要强大的已认证流量访问权限。TLSNotary 的插件采用基于能力的 QuickJS 沙箱，但生产团队仍需最小权限、明确同意、签名插件与更新政策 （TLSNotary 插件文档）。
• 验证者集中：即使公证方从不看到明文，单一受委托公证方仍是单一政策与签名密钥依赖。
• 错误授权：证明网站返回「成功」并不能证明用户希望智能体发起该请求。

SDK 的便利性可能遮住这些边界。例如 Reclaim 的 zkFetch 文档分别处理公开与私密请求选项、响应匹配、脱敏、证明验证和链上转换 （Reclaim 开发文档）。无论选哪家供应商，都要独立审查每一层，绝不能为了让 Demo 通过而关闭内容验证。

应该自建、采购，还是避免 zkTLS？

采购或使用托管 SDK，适用于可逆试点、数据源已有持续维护的模板、证明量适中，且声明不会授权灾难性操作的情况。合同中应明确证明格式稳定性、公证方政策、数据保留、事故通知与退出路径。

自行掌控验证者与集成，适用于专有数据源、声明会解锁资金或受监管数据、延迟与可用性属于产品要求，或风险团队不能委托公证政策的情况。即使采用开源协议，你的团队仍要负责解析、重放防御、主体绑定、可观测性与恢复。

避免使用 zkTLS，适用于合作数据源可以返回第一方签名回执、公开数据已有成熟预言机聚合，或普通 OAuth 加服务间授权已经解决问题的情况。TLSNotary 说明当前参考流程支持 TLS 1.2，TLS 1.3 仍在路线图上，而且 MPC 会增加显著带宽开销 （TLSNotary FAQ）。数据源兼容性是上线门槛，不是脚注。

生产试点必须证明什么？

在绑定某个平台之前，用七道门槛评估：

1. 声明：用一句话写出确切来源、字段、阈值、主体、受众和有效期。
2. 威胁模型：明确恶意用户、智能体、数据源、验证者、扩展与公证方分别能做什么。
3. 兼容性：测试真实认证会话、重定向、负载大小、浏览器版本与错误响应。
4. 隐私：追踪凭证和明文出现的每个位置，包括日志、崩溃报告、队列与 Enclave。
5. 可靠性：测量成功率、p50 与 p95 延迟、带宽、证明大小、数据源漂移失败与恢复时间。
6. 验证：拒绝错误来源、过期证明、重复随机数、错误主体与受众、格式异常内容以及已撤销公证方。
7. 退出：证明可以更换数据源适配器、验证者或供应商，而无需重写产品授权核心。

如果智能体还需要私密计算，不要强迫 zkTLS 解决另一个问题。我们的ZK、FHE、MPC 与 TEE 决策框架会把每项保证放到正确层。Wavect 的零知识工程服务可以在 SDK 选择变得昂贵之前，把证明声明、威胁模型和试点门槛转化为可审计架构。