代理与执行器
通常情况下，rdc 运行在您自己的机器上，携带您的配置和SSH密钥，直接连接到您的服务器。代理模型把这个过程拆成两半：一个不持有任何密钥的轻客户端，以及一个持有密钥并真正执行操作的执行器。网页控制台的运行按钮和CLI的 --proxy 标志都是轻客户端，它们使用同一套通信协议。
传递的是命令意图，而非命令本身
轻客户端从不持有SSH密钥、机器地址或已解密的配置。当它想运行某个操作时，只发送命令意图：命令的标识符（其在CLI合约中的路径，例如 repo up）加上参数。执行器在同一份合约中查找该命令，解析出对应的服务端函数，从解密后的配置中解析出目标机器，然后通过自己的SSH连接执行该命令。输出会流式传回客户端。
执行器就是CLI本身，以 rdc serve 的方式作为服务启动。运维人员在笔记本电脑上运行的同一个二进制文件，摇身一变就成了代表他们执行命令的角色。它有两种部署位置：
--mode daemon：运行在您自己掌控的主机上，像普通CLI一样以无浏览器方式注册（参见配置存储），因此它能自行推导出配置密钥，无需每次会话单独授权。这是严格层级：SSH流量永远不会离开您的网络。--mode container：运行在为您托管的、按组织隔离密钥的容器中。它启动时不持有任何密钥，只有客户端为本次会话授权后才能执行任何操作。这是便利层级。
CEK授权
配置存储是零知识的：服务器只存储加密后的数据块，内容加密密钥（CEK）只会以明文形式存在于已解锁该密钥的客户端上。因此，容器模式的执行器必须被授权才能拿到密钥，而授权过程中密钥不能暴露给服务器。
流程如下：一个已解锁的浏览器与执行器开启一个会话，接收该会话的公钥，然后使用X25519将CEK封装后发给该会话。封装后的数据块会经过账户服务器传输，但服务器无法打开它，因此零知识特性在整个链路中都得以保持。执行器只在内存中解密出CEK，30分钟无操作后自动过期，密钥从不写入磁盘。后续的命令请求通过 X-Config-Session 请求头引用已授权的会话。
审计时有一个细节很重要：同一个用户身份贯穿全部三个环节（开启会话、授权密钥、执行命令）。账户服务器从不将自己的凭据转发给执行器。每个环节它都会签发一个归属于实际用户的短期令牌，并每次都重新校验该用户的成员身份。执行器会验证它所收到的具体令牌后才执行操作。一个用户所做的授权无法被另一个用户使用。
配置中的 state 部分（主机本地的运行时数据）从不出现在配置数据块中传输，因此这条路径也永远不会将它传给执行器。
哪些命令可以通过代理运行
不是所有命令都适合远程执行。合约中的每个命令都带有一个 proxyCapable 标志，执行器会在服务端强制校验它，不受任何客户端策略配置的影响：
- 机器层、非交互式命令（部署、备份、状态、日志等）支持代理执行。
- 配置层命令不支持：这类命令用于编辑配置，在此路径下这是浏览器的职责（网页控制台会将它们路由到内置的配置编辑器）。
- 交互式命令（终端、VS Code会话）不支持：这条通信链路上没有TTY。
- 客户端传输命令（
rdc repo sync）不支持：它们在客户端文件系统和机器之间移动数据，而执行器拿不到客户端的文件。
网页控制台读取同一个标志来决定某个命令是否显示运行按钮，但无论客户端发送什么，执行器都会拒绝不支持代理的命令。
模拟执行器
在开发环境中，如果没有配置真实的执行器，账户服务器会自行以模拟数据流和明显是伪造的数据（资源名称带 mock- 前缀）来响应命令请求。这使得整个控制台（包括表单、流式输出和结果渲染）都可以在没有机器、也无需解锁的情况下被完整地演练。真正执行命令则需要真实的执行器。