把服务端代码放到 GitHub，是重要的第一步。但用户看到的仓库和实际处理请求的程序之间，还隔着构建、部署和运行。仅凭“代码开源”，无法排除服务器运行着另一份程序的可能。
PrimeRouter 想解决的正是这段距离：发送内容之前，先让本地客户端核验远端程序的身份。
开源解决了什么，没有解决什么
开源让人能够检查程序是否会改写模型、记录内容或绕过既定路由。但即使代码通过审阅，也还需要回答两个问题：当前运行产物是否对应认可的版本？客户端正在连接的密钥是否属于这个运行产物？
把源码、可审查的构建产物与运行度量值对应起来，是第一层工作。它仍不等于连接验证：用户的电脑需要在每次建立受保护的连接时，核验远端给出的证明材料。
连接建立前的四步
- **核验证明来源。**本地开源客户端检查可信执行环境证明材料的签名及其证明体系。
- **核验运行身份。**客户端将证明中的程序度量值与认可版本对照。
- **核验密钥绑定。**客户端确认后续通信使用的公钥与这份证明绑定，而不是只看一个声称“验证通过”的页面。
- **建立加密会话。**前面的检查通过后，客户端才协商会话密钥并发送请求内容。
其中任何一步失败，都不应该退回到“先发请求再说”。验证是发送内容的前置条件。
证明的边界也要说清楚
远程证明能够帮助确认特定程序运行在受保护的环境中，并把通信密钥绑定到该程序。它不会单独证明上游模型的名称或订阅等级。要判断平台是否会替换模型和渠道，还必须审查被验证程序中的路由逻辑，以及请求在实际链路上的可核验记录。
同样，内容机密性与请求元数据是不同问题。中转平台仍需处理路由和计费所需的信息；请求正文则通过客户端与已验证程序之间的加密会话传输。
想继续了解这三项技术如何协同工作，可以读验证与加密。