--- title: "AI 智能体 zkTLS 生产指南 2026" canonical: https://wavect.io/zh/blog/zktls-ai-agents/ language: zh description: "了解 zkTLS 如何验证 AI 智能体的私密网页数据与操作，信任仍存在哪里，以及 2026 年如何规划生产集成。" image: "https://wavect.io/img/blog/headers/header_zktls-ai-agents.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 分钟 阅读 · 2026年8月11日 最近审核 2026年8月11日 [**下一篇**](/zh/blog/zero-knowledge-proofs-production-2026/) # 面向 AI 智能体的 zkTLS：验证网页数据而不泄露秘密 要点速览 zkTLS 可把一次经过身份验证的 HTTPS 请求及其响应转换成可验证声明，同时向下游验证者隐藏凭证与无关字段。它证明数据来源和选择性披露，但不证明数据源所言为真、智能体选对了操作，或用户确实授权。到 2026 年，该技术栈正在快速发展：TLSNotary 在小型证明上公布了 1 至 2 秒的代理模式结果。但它的最新参考版本仍是 Alpha，TLS 1.3 也仍在路线图上。当产品需要来自私密网页数据的密码学证据，且无法获得第一方签名响应时，zkTLS 才是合适选项。先定验证者与公证方信任模型，再选 SDK。 **zkTLS 让 AI 智能体能够证明私密网页数据来自哪里，同时只向验证者披露必要字段。**它可以把经过身份验证的 HTTPS 响应变成「该账户处于活跃状态」或「该购买已经完成」之类的证据，而无需暴露会话 Cookie、完整账户记录或响应中的无关数据。 这个承诺比「无需信任的智能体」更窄，也因此更实用。奠定基础的 DECO 研究展示了如何在不依赖可信硬件、不修改源网站的前提下证明 TLS 数据来源 [（ACM CCS，2020）](https://dl.acm.org/doi/10.1145/3372297.3417239) 。到 2026 年，商业问题已经不再是网页证明是否可行，而是剩余信任、延迟、数据源脆弱性和运维成本是否适合你的智能体工作流。 本文专门回答这项架构决策。若要了解更广泛的技术现状，请先看我们的 [2026 年零知识证明生产指南](/zh/blog/zero-knowledge-proofs-production-2026/) 。身份、KYC 与供应链场景则由 [加密行业之外的零知识应用](/zh/blog/zero-knowledge-use-cases-outside-crypto/) 单独覆盖。 ## 对 AI 智能体而言，zkTLS 是什么？ zkTLS 是一类协议，它让 HTTPS 会话中的选定事实可由另一方验证。网站通常只会看到普通 TLS 连接，无需新增证明 API。由以太坊基金会 Privacy Stewards of Ethereum 推动的开源项目 TLSNotary，把流程描述为证明者在验证者参与 TLS 会话的情况下请求数据，随后进行选择性披露与验证 [（TLSNotary 文档）](https://tlsnotary.org/docs/intro/) 。 1. **请求：** 用户设备或智能体访问指定的 HTTPS 数据源，认证材料保留在请求的私密部分。 2. **见证：** 验证者通过 MPC-TLS 参与会话，或在代理模式下观察加密网络路径。 3. **承诺：** 协议把选定的请求与响应字段绑定到被见证的会话。 4. **披露：** 证明者只展示某个值、脱敏片段或派生条件，其余内容继续隐藏。 5. **决策：** 应用在允许智能体继续行动前，验证证明或受信任公证方的证明书。 隐私边界必须说清楚。如果证明在用户设备上生成，zkTLS 可以向下游验证者隐藏凭证。它不会自动向本地智能体运行时、浏览器扩展，或代为发起请求的 TEE 隐藏凭证。先画出明文出现在哪里，再把架构称为隐私保护。 ## AI 智能体究竟能证明什么？ 有用的 zkTLS 声明需要绑定指定来源、具体响应字段、主体和有效时间窗口。「智能体检查了某个网站」过于含糊，不足以授权资金或数据访问。 | 智能体工作流 | 有用的证明声明 | 仍未被证明的事项 | | --- | --- | --- | | 资格检查 | 指定账户在受限时间内返回活跃状态 | 数据源政策是否公平或在法律上充分 | | 购买或预订 | 商户响应包含预期订单 ID 与已完成状态 | 交付质量、退款，或智能体是否选到最佳报价 | | 财务信号 | 余额或收入字段达到阈值，而不披露原始数值 | 记录在证明时间之后是否仍然有效 | | 工具结果 | 工具从指定 HTTPS 来源收到特定响应 | 模型是否正确理解了响应 | | 操作回执 | 远程服务确认了请求的状态变更 | 用户是否授权，或其他系统中的副作用是否完成 | 最后一列就是产品边界。zkTLS 证明会话记录的来源与披露内容的一致性。它不会让错误的数据源变得真实、让旧页面变得新鲜、让提示词变得安全，也不会让智能体决策自动正确。 ## zkTLS 是否无需信任、可公开验证？ **任何可移交的 zkTLS 声明都并非完全无需信任。**验证者必须在 TLS 会话发生时参与，因为客户端本身知道对称会话密钥，否则可能伪造记录。如果你的后端在线并亲自运行验证者，它可以直接信任结果。如果智能合约、离线审核者或许多后续使用者都需要结果，就必须由受委托验证者签署证明书，而这些使用者会信任该公证方。 TLSNotary 在 2026 年 6 月的说明中把它称为指定验证者边界：零知识保护选择性披露，并阻止证明者篡改已展示的片段，但没有参加会话的人仍要依赖当时见证会话的一方 [（TLSNotary，2026 年 6 月）](https://tlsnotary.org/blog/2026/06/17/public-verifiability/) 。公证方密钥、法定人数、撤销流程与审计记录都是生产基础设施，不是可以忽略的 SDK 默认值。 ## 为什么 zkTLS 在 2026 年值得关注？ 三项变化让它成为智能体团队的近期议题： - **使用场景从身份证明扩展到操作回执。** 智能体正在读取已登录面板、调用付费 API、预订服务并改变外部状态。可验证响应可以成为结算或审批输入。 - **浏览器与代理路径降低了集成摩擦。** 证明可以靠近用户的已认证会话生成，无需把凭证转移到中央抓取器。 - **取舍已经可以测量。** TLSNotary 发布可复现的测试数据，并同时提供 MPC 和代理模式。 不要把发展势头误当成成熟度。截至 2026 年 8 月 11 日复核时，TLSNotary 在 GitHub 上的最新版本是 `v0.1.0-alpha.15`，并标记为预发布 [（官方发布说明）](https://github.com/tlsnotary/tlsn/releases) 。应固定版本、执行独立安全审查，并在证明者、验证者、解析器和证明书格式之间设计可迁移边界。 ## 应该选择哪种 zkTLS 架构？ | 模式 | 最适合的情况 | 主要成本或信任 | | --- | --- | --- | | 直接 MPC-TLS 验证者 | 后端在线、声明风险高，且数据源可能屏蔽数据中心 IP | 更多交互轮次与带宽，验证者必须实时参与 | | 受委托 MPC 公证方 | 证明需要交给离线系统或多个使用者 | 所有使用者信任公证签名，高风险场景应采用法定人数 | | 代理模式 | 浏览器 UX 与延迟重要，且你控制验证者 | 增加网络路径假设，由验证者 IP 访问数据源 | | TEE 证明方 | 亚秒级体验优先，且可接受硬件信任 | 凭证和明文可能进入 Enclave，隐私依赖硬件证明 | | 第一方签名 API | 数据源愿意配合，并能签署稳定、范围明确的响应 | 通常比 zkTLS 简单，但依赖数据源密钥与可用性 | TLSNotary 在 2026 年 5 月公布的基准中，对 1 KB 请求与 2 KB 响应进行测试。代理模式在所测原生与浏览器网络配置下耗时 1.0 至 2.0 秒，MPC 模式为 3.6 至 15.5 秒 [（TLSNotary 基准工具）](https://tlsnotary.org/blog/2026/05/10/blog-proxy-mode/) 。这些是项目维护的参考测量，不是你的 SLA。响应大小、脱敏逻辑、设备、网络、数据源行为和证明声明都会改变结果。 ## 生产环境中会在哪里出错？ - **数据源漂移：** JSON 路径、重定向、压缩方式、反机器人规则或 A/B 测试变化，都可能在业务语义不变时破坏提取。 - **重放：** 如果验证者不检查合适的随机数、时间戳、受众、主体和过期时间，旧但有效的证明仍然危险。 - **解析歧义：** 密码学可以验证字节，但两个组件可能对字节含义有不同理解。请求、响应、数字、字符编码与错误状态都要规范化。 - **凭证暴露：** 浏览器工具需要强大的已认证流量访问权限。TLSNotary 的插件采用基于能力的 QuickJS 沙箱，但生产团队仍需最小权限、明确同意、签名插件与更新政策 [（TLSNotary 插件文档）](https://tlsnotary.org/docs/extension/plugins/) 。 - **验证者集中：** 即使公证方从不看到明文，单一受委托公证方仍是单一政策与签名密钥依赖。 - **错误授权：** 证明网站返回「成功」并不能证明用户希望智能体发起该请求。 SDK 的便利性可能遮住这些边界。例如 Reclaim 的 zkFetch 文档分别处理公开与私密请求选项、响应匹配、脱敏、证明验证和链上转换 [（Reclaim 开发文档）](https://docs.reclaimprotocol.org/zkfetch/usage) 。无论选哪家供应商，都要独立审查每一层，绝不能为了让 Demo 通过而关闭内容验证。 ## 应该自建、采购，还是避免 zkTLS？ **采购或使用托管 SDK**，适用于可逆试点、数据源已有持续维护的模板、证明量适中，且声明不会授权灾难性操作的情况。合同中应明确证明格式稳定性、公证方政策、数据保留、事故通知与退出路径。 **自行掌控验证者与集成**，适用于专有数据源、声明会解锁资金或受监管数据、延迟与可用性属于产品要求，或风险团队不能委托公证政策的情况。即使采用开源协议，你的团队仍要负责解析、重放防御、主体绑定、可观测性与恢复。 **避免使用 zkTLS**，适用于合作数据源可以返回第一方签名回执、公开数据已有成熟预言机聚合，或普通 OAuth 加服务间授权已经解决问题的情况。TLSNotary 说明当前参考流程支持 TLS 1.2，TLS 1.3 仍在路线图上，而且 MPC 会增加显著带宽开销 [（TLSNotary FAQ）](https://tlsnotary.org/docs/faq/) 。数据源兼容性是上线门槛，不是脚注。 ## 生产试点必须证明什么？ 在绑定某个平台之前，用七道门槛评估： 1. **声明：** 用一句话写出确切来源、字段、阈值、主体、受众和有效期。 2. **威胁模型：** 明确恶意用户、智能体、数据源、验证者、扩展与公证方分别能做什么。 3. **兼容性：** 测试真实认证会话、重定向、负载大小、浏览器版本与错误响应。 4. **隐私：** 追踪凭证和明文出现的每个位置，包括日志、崩溃报告、队列与 Enclave。 5. **可靠性：** 测量成功率、p50 与 p95 延迟、带宽、证明大小、数据源漂移失败与恢复时间。 6. **验证：** 拒绝错误来源、过期证明、重复随机数、错误主体与受众、格式异常内容以及已撤销公证方。 7. **退出：** 证明可以更换数据源适配器、验证者或供应商，而无需重写产品授权核心。 如果智能体还需要私密计算，不要强迫 zkTLS 解决另一个问题。我们的 [ZK、FHE、MPC 与 TEE 决策框架](/zh/blog/zk-vs-fhe-vs-mpc-vs-tee/) 会把每项保证放到正确层。Wavect 的 [零知识工程服务](/zh/services/zero-knowledge/) 可以在 SDK 选择变得昂贵之前，把证明声明、威胁模型和试点门槛转化为可审计架构。 ## 常见问题 ### zkTLS 与 TLSNotary 是同一回事吗？ 不是。zkTLS 是一类用于证明 TLS 会话事实的协议。TLSNotary 是其中一个开源实现与研究项目。其他产品会以不同方式组合 MPC、代理、零知识系统、见证者、公证方与可信硬件。 ### zkTLS 能证明 AI 智能体完成了操作吗？ 它能证明指定 HTTPS 来源返回了与已披露操作回执一致的响应。它无法单独证明所有后续副作用已经完成、智能体选择正确，或用户确实授权。应把回执与请求、主体、随机数、受众和时间窗口绑定。 ### zkTLS 会向 AI 智能体隐藏登录凭证吗？ 不会自动隐藏。当用户设备创建会话和证明时，它可以向验证者隐藏凭证。本地浏览器扩展、智能体运行时或 TEE 仍可能访问明文。必须显式设计并审计这条本地边界。 ### zkTLS 在 2026 年可用于生产吗？ 它适合边界明确的试点，以及具备明确威胁模型、版本固定、数据源监控、重放防护和事故恢复的特定生产流程。本文复核的 TLSNotary 参考版本仍处于 Alpha，不应把它当作开箱即用的合规控制。 ### zkTLS 会取代 API 或数据预言机吗？ 不会。数据源配合时，第一方签名 API 通常更简单。对于需要聚合的公开数据，成熟预言机通常更合适。zkTLS 最适合用户或智能体需要证明私密认证网页数据中的选定事实，同时不披露完整响应的情况。 ## 最终思考 zkTLS 为 AI 智能体提供了日志与截图无法给出的能力：为选定的私密网页数据提供可验证来源。它的价值也是它的边界。它验证被见证的会话记录并控制披露，却不会让数据源自动真实、模型自动正确或操作自动获得授权。 生产决策从声明和见证者开始。先定义必须证明什么、需要说服谁、对方何时验证，以及哪一方可以看到明文。然后在真实数据源和设备上做基准测试，攻击重放与解析边界，并让授权核心独立于证明供应商。如果更简单的签名 API 或预言机已经满足需求，就使用它。如果不能，zkTLS 已经是可信的架构选项，前提是剩余信任被明确写出并有意识地工程化。 ## 你可能也喜欢.. [**2026 年零知识证明：哪些技术真正达到生产级** 更完整的生产版图，包括 zkVM、移动端证明、安全故障、成本与工具链。](/zh/blog/zero-knowledge-proofs-production-2026/) [**Wavect 与 Alpine Blockchain 对比** 对比产品导向的 ZK 与 Web3 工程伙伴和区块链专业机构。](/zh/compare/wavect-vs-alpine-blockchain/) 隐私与密码学 ## 继续浏览此集群 [从核心文章开始**2026 年的零知识证明：什么真正达到了生产就绪**](/zh/blog/zero-knowledge-proofs-production-2026/) - [在 2026 年用 ZK 和 FHE 构建真实应用：一份务实指南](/zh/blog/building-real-applications-zero-knowledge-fhe-2026/) - [2026 年的零知识证明：什么真正达到了生产就绪](/zh/blog/zero-knowledge-proofs-production-2026/) - [2026 年的全同态加密：什么能交付，什么还是炒作](/zh/blog/fully-homomorphic-encryption-practical-2026/) - [ZK vs FHE vs MPC vs TEE：2026 年怎么选](/zh/blog/zk-vs-fhe-vs-mpc-vs-tee/) - [加密之外的零知识应用](/zh/blog/zero-knowledge-use-cases-outside-crypto/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 分钟 阅读 · 2026年8月11日 最近审核 2026年8月11日 [**下一篇**](/zh/blog/zero-knowledge-proofs-production-2026/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/zktls-ai-agents/#webpage", "@type": "WebPage", "dateModified": "2026-08-11", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-11", "url": "https://wavect.io/zh/blog/zktls-ai-agents/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "zkTLS 可把一次经过身份验证的 HTTPS 请求及其响应转换成可验证声明，同时向下游验证者隐藏凭证与无关字段。它证明数据来源和选择性披露，但不证明数据源所言为真、智能体选对了操作，或用户确实授权。到 2026 年，该技术栈正在快速发展：TLSNotary 在小型证明上公布了 1 至 2 秒的代理模式结果。但它的最新参考版本仍是 Alpha，TLS 1.3 也仍在路线图上。当产品需要来自私密网页数据的密码学证据，且无法获得第一方签名响应时，zkTLS 才是合适选项。先定验证者与公证方信任模型，再选 SDK。", "articleBody": " 博客概览/Web3 与隐私/隐私与密码学 面向 AI 智能体的 zkTLS：验证网页数据而不泄露秘密 要点速览 zkTLS 可把一次经过身份验证的 HTTPS 请求及其响应转换成可验证声明，同时向下游验证者隐藏凭证与无关字段。它证明数据来源和选择性披露，但不证明数据源所言为真、智能体选对了操作，或用户确实授权。到 2026 年，该技术栈正在快速发展：TLSNotary 在小型证明上公布了 1 至 2 秒的代理模式结果。但它的最新参考版本仍是 Alpha，TLS 1.3 也仍在路线图上。当产品需要来自私密网页数据的密码学证据，且无法获得第一方签名响应时，zkTLS 才是合适选项。先定验证者与公证方信任模型，再选 SDK。 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 文档）。 请求：用户设备或智能体访问指定的 HTTPS 数据源，认证材料保留在请求的私密部分。 见证：验证者通过 MPC-TLS 参与会话，或在代理模式下观察加密网络路径。 承诺：协议把选定的请求与响应字段绑定到被见证的会话。 披露：证明者只展示某个值、脱敏片段或派生条件，其余内容继续隐藏。 决策：应用在允许智能体继续行动前，验证证明或受信任公证方的证明书。 隐私边界必须说清楚。如果证明在用户设备上生成，zkTLS 可以向下游验证者隐藏凭证。它不会自动向本地智能体运行时、浏览器扩展，或代为发起请求的 TEE 隐藏凭证。先画出明文出现在哪里，再把架构称为隐私保护。 AI 智能体究竟能证明什么？ 有用的 zkTLS 声明需要绑定指定来源、具体响应字段、主体和有效时间窗口。「智能体检查了某个网站」过于含糊，不足以授权资金或数据访问。 智能体工作流有用的证明声明仍未被证明的事项 资格检查指定账户在受限时间内返回活跃状态数据源政策是否公平或在法律上充分 购买或预订商户响应包含预期订单 ID 与已完成状态交付质量、退款，或智能体是否选到最佳报价 财务信号余额或收入字段达到阈值，而不披露原始数值记录在证明时间之后是否仍然有效 工具结果工具从指定 HTTPS 来源收到特定响应模型是否正确理解了响应 操作回执远程服务确认了请求的状态变更用户是否授权，或其他系统中的副作用是否完成 最后一列就是产品边界。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 架构？ 模式最适合的情况主要成本或信任 直接 MPC-TLS 验证者后端在线、声明风险高，且数据源可能屏蔽数据中心 IP更多交互轮次与带宽，验证者必须实时参与 受委托 MPC 公证方证明需要交给离线系统或多个使用者所有使用者信任公证签名，高风险场景应采用法定人数 代理模式浏览器 UX 与延迟重要，且你控制验证者增加网络路径假设，由验证者 IP 访问数据源 TEE 证明方亚秒级体验优先，且可接受硬件信任凭证和明文可能进入 Enclave，隐私依赖硬件证明 第一方签名 API数据源愿意配合，并能签署稳定、范围明确的响应通常比 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）。数据源兼容性是上线门槛，不是脚注。 生产试点必须证明什么？ 在绑定某个平台之前，用七道门槛评估： 声明：用一句话写出确切来源、字段、阈值、主体、受众和有效期。 威胁模型：明确恶意用户、智能体、数据源、验证者、扩展与公证方分别能做什么。 兼容性：测试真实认证会话、重定向、负载大小、浏览器版本与错误响应。 隐私：追踪凭证和明文出现的每个位置，包括日志、崩溃报告、队列与 Enclave。 可靠性：测量成功率、p50 与 p95 延迟、带宽、证明大小、数据源漂移失败与恢复时间。 验证：拒绝错误来源、过期证明、重复随机数、错误主体与受众、格式异常内容以及已撤销公证方。 退出：证明可以更换数据源适配器、验证者或供应商，而无需重写产品授权核心。 如果智能体还需要私密计算，不要强迫 zkTLS 解决另一个问题。我们的ZK、FHE、MPC 与 TEE 决策框架会把每项保证放到正确层。Wavect 的零知识工程服务可以在 SDK 选择变得昂贵之前，把证明声明、威胁模型和试点门槛转化为可审计架构。 常见问题 zkTLS 与 TLSNotary 是同一回事吗？ 不是。zkTLS 是一类用于证明 TLS 会话事实的协议。TLSNotary 是其中一个开源实现与研究项目。其他产品会以不同方式组合 MPC、代理、零知识系统、见证者、公证方与可信硬件。 zkTLS 能证明 AI 智能体完成了操作吗？ 它能证明指定 HTTPS 来源返回了与已披露操作回执一致的响应。它无法单独证明所有后续副作用已经完成、智能体选择正确，或用户确实授权。应把回执与请求、主体、随机数、受众和时间窗口绑定。 zkTLS 会向 AI 智能体隐藏登录凭证吗？ 不会自动隐藏。当用户设备创建会话和证明时，它可以向验证者隐藏凭证。本地浏览器扩展、智能体运行时或 TEE 仍可能访问明文。必须显式设计并审计这条本地边界。 zkTLS 在 2026 年可用于生产吗？ 它适合边界明确的试点，以及具备明确威胁模型、版本固定、数据源监控、重放防护和事故恢复的特定生产流程。本文复核的 TLSNotary 参考版本仍处于 Alpha，不应把它当作开箱即用的合规控制。 zkTLS 会取代 API 或数据预言机吗？ 不会。数据源配合时，第一方签名 API 通常更简单。对于需要聚合的公开数据，成熟预言机通常更合适。zkTLS 最适合用户或智能体需要证明私密认证网页数据中的选定事实，同时不披露完整响应的情况。 最终思考 zkTLS 为 AI 智能体提供了日志与截图无法给出的能力：为选定的私密网页数据提供可验证来源。它的价值也是它的边界。它验证被见证的会话记录并控制披露，却不会让数据源自动真实、模型自动正确或操作自动获得授权。 生产决策从声明和见证者开始。先定义必须证明什么、需要说服谁、对方何时验证，以及哪一方可以看到明文。然后在真实数据源和设备上做基准测试，攻击重放与解析边界，并让授权核心独立于证明供应商。如果更简单的签名 API 或预言机已经满足需求，就使用它。如果不能，zkTLS 已经是可信的架构选项，前提是剩余信任被明确写出并有意识地工程化。 你可能也喜欢.. 2026 年零知识证明：哪些技术真正达到生产级 更完整的生产版图，包括 zkVM、移动端证明、安全故障、成本与工具链。 Wavect 与 Alpine Blockchain 对比 对比产品导向的 ZK 与 Web3 工程伙伴和区块链专业机构。 隐私与密码学继续浏览此集群从核心文章开始2026", "articleSection": "Zero Knowledge", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "（ACM CCS，2020）", "url": "https://dl.acm.org/doi/10.1145/3372297.3417239" }, { "@type": "WebPage", "name": "（TLSNotary 文档）", "url": "https://tlsnotary.org/docs/intro/" }, { "@type": "WebPage", "name": "（TLSNotary，2026 年 6 月）", "url": "https://tlsnotary.org/blog/2026/06/17/public-verifiability/" }, { "@type": "WebPage", "name": "（官方发布说明）", "url": "https://github.com/tlsnotary/tlsn/releases" }, { "@type": "WebPage", "name": "（TLSNotary 基准工具）", "url": "https://tlsnotary.org/blog/2026/05/10/blog-proxy-mode/" }, { "@type": "WebPage", "name": "（TLSNotary 插件文档）", "url": "https://tlsnotary.org/docs/extension/plugins/" }, { "@type": "WebPage", "name": "（Reclaim 开发文档）", "url": "https://docs.reclaimprotocol.org/zkfetch/usage" }, { "@type": "WebPage", "name": "（TLSNotary FAQ）", "url": "https://tlsnotary.org/docs/faq/" } ], "dateModified": "2026-08-11", "datePublished": "2026-08-11", "description": "zkTLS 可把一次经过身份验证的 HTTPS 请求及其响应转换成可验证声明，同时向下游验证者隐藏凭证与无关字段。它证明数据来源和选择性披露，但不证明数据源所言为真、智能体选对了操作，或用户确实授权。到 2026 年，该技术栈正在快速发展：TLSNotary 在小型证明上公布了 1 至 2 秒的代理模式结果。但它的最新参考版本仍是 Alpha，TLS 1.3 也仍在路线图上。当产品需要来自私密网页数据的密码学证据，且无法获得第一方签名响应时，zkTLS 才是合适选项。先定验证者与公证方信任模型，再选 SDK。", "headline": "面向 AI 智能体的 zkTLS：验证网页数据而不泄露秘密", "image": "https://wavect.io/img/blog/headers/header_zktls-ai-agents.svg", "inLanguage": "zh", "keywords": "零知识, AI 智能体", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/zktls-ai-agents/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/zktls-ai-agents/", "wordCount": 379 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/web3-privacy/", "name": "Web3 与隐私", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/privacy-cryptography/", "name": "隐私与密码学", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/zktls-ai-agents/", "name": "AI 智能体 zkTLS 生产指南 2026 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不是。zkTLS 是一类用于证明 TLS 会话事实的协议。TLSNotary 是其中一个开源实现与研究项目。其他产品会以不同方式组合 MPC、代理、零知识系统、见证者、公证方与可信硬件。" }, "name": "zkTLS 与 TLSNotary 是同一回事吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "它能证明指定 HTTPS 来源返回了与已披露操作回执一致的响应。它无法单独证明所有后续副作用已经完成、智能体选择正确，或用户确实授权。应把回执与请求、主体、随机数、受众和时间窗口绑定。" }, "name": "zkTLS 能证明 AI 智能体完成了操作吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不会自动隐藏。当用户设备创建会话和证明时，它可以向验证者隐藏凭证。本地浏览器扩展、智能体运行时或 TEE 仍可能访问明文。必须显式设计并审计这条本地边界。" }, "name": "zkTLS 会向 AI 智能体隐藏登录凭证吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "它适合边界明确的试点，以及具备明确威胁模型、版本固定、数据源监控、重放防护和事故恢复的特定生产流程。本文复核的 TLSNotary 参考版本仍处于 Alpha，不应把它当作开箱即用的合规控制。" }, "name": "zkTLS 在 2026 年可用于生产吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不会。数据源配合时，第一方签名 API 通常更简单。对于需要聚合的公开数据，成熟预言机通常更合适。zkTLS 最适合用户或智能体需要证明私密认证网页数据中的选定事实，同时不披露完整响应的情况。" }, "name": "zkTLS 会取代 API 或数据预言机吗？" } ] } ```