请求链路:User、Relay、Worker、Partner 各做什么
用一次模型请求解释各组件的职责、密文路径和账号出口。
四个名字先记住
| 组件 | 主要职责 |
|---|---|
| User Client | 给工具提供本地 API、管理本地 Key、识别请求来源、验证远端并建立加密会话 |
| Relay | 权限、模型与账号路由、生命周期、计费与记录、配置发布和密文转发 |
| Attested Worker | 在相应受保护环境处理请求、转换协议、调用上游并返回执行与用量信息 |
| Partner Client | 接入和维护自己的供给账号、同步本机登录、管理出口及账号状态 |
User 与 Partner 都运行在各自设备上,可以由不同的人运营。Relay 不是“装在你电脑里的那个窗口”,Worker 也不是你的编码 Agent。
一次调用的顺序
编码工具或 HTTP 请求
↓ 本地入口 + 本地 Key
User Client
↓ 权限与路由准备、验证、加密
Relay
↓ 转发密文
已验证的 Worker
↓ 所选账号与出口
上游模型提供商
↑ 响应沿链路返回
你的工具处理响应并执行本机工具调用
这里的“工具调用”由你电脑上的 Agent 执行。Worker 调用模型不意味着它替你在真实项目目录里执行编码命令。
Partner 怎么参与
Partner 提供账号凭据和供号配置。托管账号与本机同步账号的续期、出口规则不同,见账号接入和本机同步。
选择本客户端或代理出口时,相应连接需要在线。出于可用性不能悄悄把本机同步切成云端 Worker 出口;暂停供给比违背出口设置更符合这个模式的含义。
为什么记录会有好几层
User 的本地诊断覆盖早期处理;Relay 使用记录覆盖平台请求与业务状态;Worker 提供执行、用量和收据信息;钱包及收益记录反映后续结算。
所以本地请求失败却没有平台记录、响应已经回来但结算仍待确认,都可能有可解释的阶段原因。用请求 ID 串起来排查,不要把每个页面的状态当成同一个瞬间。
可见性与边界
Relay 需要账号、路由、价格、状态和统计等业务元数据。正文在 Client–Worker 的加密会话内传递,但 Worker 与最终模型提供商会处理推理输入。你在提示词里主动写出的真实信息不会因为用了虚拟目录就自动变成匿名数据。
平台与自己工具的额外遥测、浏览器请求或第三方登录流量也不能混为一条链。更详细的安全说明见TEE 信任与加密。

