大家好，欢迎参加我的演讲。我是乔舒亚·莫（Joshua Mo），今天我们将探讨构建尊重隐私的 AI 系统所面临的一些挑战。首先简单介绍一下我自己，我目前是威尼斯人工智能（Venice AI）的开发者关系负责人。目前我负责合作伙伴关系、文档编写、与开发人员沟通，以及一些工程和其他事务。在此之前的经历中，我曾是 Rig 的主要维护者，Rig 是 Rust 语言中最领先的 AI 框架。

那么什么是威尼斯呢？威尼斯是一个私密且无限制的人工智能平台。我们托管所有最新的开源模型，完全兼容 OpenAI 接口。我们不存储任何提示词或对话记录，我们还提供了一个网络应用程序，您可以用来与我们的模型进行交互。此外，我们还有面向内容创作者的工作室服务产品，包括视频、音频生成以及转录功能。

那么为什么隐私如此重要呢？让我们深入探讨这一点。众所周知，数据泄露正日益成为一种必然事件，这意味着声誉风险至关重要。您只需要发生一次数据泄露，用户就会停止信任你并转向其他提供商。或者如果您是面向企业客户，您可能会失去那个贡献了几乎 90% 年收入的企业大客户。在这种情况下，敏感数据会严重加剧任何安全事件的影响。此外，直接存储较少的用户数据可以减少发生安全事件事件的爆炸半径（影响范围）。

那么威尼斯目前是如何实现隐私保护的呢？主要有几种方式。首先，正如我们之前提到的，我们不存储任何提示词和对话记录，这意味着您在您这一侧产生的数字足迹本质上减少为零。因此，当您使用像 GLM 5.2 和 Kimi 2.7 这样的模型时，您可以保证您的任何对话都不会保存在我们这边。所有数据都将存储在本地。

我们还设有预定义的隐私层级。“默认私密”意味着上述措施适用于像 OpenAI 和 Claude 这样的提供商。我们会匿名化您的用户足迹，以便他们无法仅从提示词或请求中识别出您。我们还将在可信执行环境中托管模型，这意味着您可以验证证明您的推理是在一个完全私密的过程中运行的。

此外，我们还采用隐私优先的软件架构。对于需要拉取端点的视频生成等场景，我们使用分割密钥保管（split key custody）将结果存储在完全加密的有效载荷中。这意味着攻击者无法访问您的数据，即使团队账户被攻破，他们也无法访问。我只是想向大家介绍一个理念：并非所有系统都是平等的。也就是说，并非所有系统都具有隐私保护特性。

有些公司可能声称他们的系统是私密的，但实际上并不是。大家对此都心知肚明。虽然模型是代理系统（agentic system）中非常重要的一部分，事实上也是至关重要的部分，但它们仍然只是其中一部分。实际上，为了创建一个完整的系统来协助大型语言模型（LLM）完成任务，您必须围绕它构建一整套流程。

然而，这些系统也更容易发生数据泄露和漏洞。因此真正的问题是：我们如何针对这类问题进行优化？我想举的一个例子是可观测性日志记录。正如许多人所知，可观测性是当今任何严肃的生产系统的核心部分。为了快速分解一下：

可观测性可以细分为指标、日志和追踪（traces）。追踪只是指在单位时间内完成的工作跨度。指标则是简单的数字，例如计数器、仪表盘等；而日志则是实际的消息记录。众所周知，日志对于调试非常有用，特别是在生产或开发环境中。但是如果您不小心，默认情况下也可能存储提示词和密钥，其中可能包含个人信息。

然而，当您使用威尼斯时，您无需担心这些问题。那么让我们谈谈密钥是如何在常规代理中流动的。例如，假设您使用的是 OpenClaw（或类似工具）。您将用户请求发送到代理运行时。该运行时可能需要一个密钥，它会从 1Password 保险库或 HashiCorp Vault 中获取该密钥。

随后，该密钥将被发送到 LLM 推理层。“天哪”，由于这种架构方式，密钥被直接提供给大语言模型，这意味着它可能会被用于训练数据中。那么关于有效的隐私保护模式呢？我们在威尼斯使用的一种方法是存储代表所需 ID 的哈希值，而不是直接数据。

例如，如果您需要为了速率限制目的来识别用户，您可能不想直接使用他们的个人足迹数据。您可能会选择将其存储为哈希值等格式，以便在不直接使用的情况下识别他们任何个人数据。此外，我们使用分割密钥保管将加密数据存储在一个无法访问的隔离区中。

从上下文来看，加密密钥被存储为两半：读取半部分和写入半部分。通过分割这些密钥，攻击者无法访问数据，因为解密完成需要这两半部分。此外，您还可以使用像句柄（handles）这样易于撤销的设计模式。

所谓“句柄”只是一个授予您访问某物权限的对象。例如，假设您有一个使用句柄的数据库池。当您拥有该句柄时，您可以访问数据库池；当没有时，您就无法访问它。这一点非常重要，特别是在使用授权机制如 JSON Web Tokens 或会话密钥时，它们可能是您授权系统的核心部分。

此外，当然地，在设计提示词时将隐私考虑在内对于使用 Cursor 和 Clawed Code（或类似编码工具）的工程团队在保护代理句柄数据方面非常有帮助。这本质上确保了狭窄的代理范围以降低风险。例如，假设您从 NCP 服务器拉取工具，那里可能有 15 到 20 种不同的工具。

您并不真的需要使用所有工具，实际上您可能只需要其中一种，但您需要一个 API 密钥来处理该 API 调用。如果您从密码保险库中拉取那个 API 密钥，然后将其作为代理的一部分发送出去，可能会发生的情况是：它通过代理的工具调用被窃取到由坏人托管的某个 Web 服务器上。

例如，除了代理本身之外，我们在代理前端还设有一个分类层，用于检测提示注入等情况。实现这一目标有几种方法：你可以使用基于大型语言模型的层，或者采用语义搜索层（例如通过向量数据库如 Qdrant、LanceDB 等），还可以使用内存处理进程。此外，值得注意的是，由于代理范围狭窄而导致的紧密上下文循环也能提升上下文窗口的性能。例如，因为工具较少，代理的表现可能会更好众所周知，当填满上下文窗口并接近其极限时性能会显著下降。通过保持空白或近乎空白的上下文窗口，我们可以确保代理以最佳状态运行。

接下来我们看看如何将秘密信息排除在模型之外。这里有一个用户请求被发送到推理层，该推理层随后为代理运行时生成一系列非确定性输入。通过将密码库连接到代理运行时而不是推理层，代理运行时本质上就变成了执行层，我们可以将其视为确定性的。在 LLM 层面出于隐私和安全原因通常无法做到的事情，我们现在都可以做。例如，假设你想使用浏览器工具并需要登录一个要求凭据的网站采用这种软件架构，说它是私密且安全的要合理得多，而不是直接将密码喂给推理层或调用外部 API。

关于代理的沙箱处理众所周知，使用沙箱和虚拟机（如 Firecracker 或 VPC 中的 AWS EC2）可以显著提升代理的安全性。然而，这并不能解决所有问题。例如，如果启用了互联网访问，如果不谨慎代理仍可能通过外部 API 访问意外泄露数据，因此监控权限至关重要。我个人的建议是构建自己的代理运行时环境本质上就是建立自定义的代码执行框架，在其中添加你自己的步骤、可观测性工具和工具等。这意味掌控执行层和推理层。

最后快速谈谈硬件层面的隐私保护。这里有一种我称之为“机密计算”的技术，它通过硬件级别的受信任执行环境使推理过程能够私密运行。在 Venice 中，当你发送请求并获得响应后我们会返回一个证明（attestation），你可以使用我们的验证器进行核实。这意味着你可以在密码学层面完全隔离推理层的代理并加以证明。不过，关于机密工具调用仍有一些工作要做虽然 TEE 对工具调用来讲依然很棒但我们还提供端到端加密，但由于需要提供优雅的用户体验 API 同时允许用户返回完全加密的工具调用仍是一个持续的挑战。

一个非常可靠的解决方案是让提供商拥有你运行工具调用的计算层。（笑声）抱歉，请稍等一下。关于机密工具调用确实还有一些工作要做。好了，就是这些了，感谢聆听。