【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
标题
157、【Agent】【OpenCode】TuiThreadCmd（RPC）
背景
上篇 blog
分析了 CLI 应用的顶层异常捕获与优雅退出机制，它确保了无论程序内部发生什么错误，用户都能看到有意义的反馈，并且进程一定会被彻底清理和关闭，其中 cli.parse() 是 Yargs 解析命令行参数并执行对应命令的异步入口，并进行了结构化错误收集，这部分不是简单地打印错误，而是根据错误类型提取不同字段，构建一个结构化的 data 对象用于日志记录，接着分析了整体流程，下面继续
OpenCode
之前 blog 提到了 cli.parse 会解析命令行参数，并执行对应命令，而当用户什么子命令也不敲，只输入
bash
opencode时，就会进入 OpenCode 默认的子命令 TuiThreadCmd
下面来看下 OpenCode TuiThreadCmd 子命令的实现
这里实现了一个 RPC 代理 Fetch。它的核心作用是：把当前进程中的 fetch 网络请求，通过 RPC 通道转发给另一个进程（Worker）去真正执行，通常用于 CLI 或桌面应用中，主进程不直接发网络请求，而是委托给专门的 Worker 进程处理。下面逐块拆解：
1. 全局类型声明
javascript
declare global {
const OPENCODE_WORKER_PATH: string
}声明一个编译时存在的全局常量 OPENCODE_WORKER_PATH，这个值通常由构建工具在打包时注入，指向 Worker 脚本的文件路径，declare global 让 TypeScript 知道这个变量是外部注入的，避免类型报错
2. RPC 含义
RPC 的全称是 Remote Procedure Call，中文叫远程过程调用，RPC 可以让程序调用另一台机器（或另一个进程）上的函数，就像调用本地函数一样简单。
为什么需要 RPC？
在传统的网络编程中，如果想让程序 A 请求程序 B 的数据，需要：
- 手动拼接 HTTP URL、Method、Headers
- 手动把参数序列化成 JSON
- 手动发送请求、接收响应
- 手动解析返回值、处理各种网络错误
非常繁琐，而且容易出错。
RPC 的目标就是把这些底层细节全部隐藏起来。 只需要写：
javascript
// 看起来就像调用一个普通的本地异步函数
const result = await client.fetch({ url: "https://example.com" })但实际上，这个 client.fetch() 内部完成了序列化、网络传输、反序列化等所有脏活累活。
3. RPC vs HTTP API
| 维度 | 传统 HTTP API | RPC |
|---|---|---|
| 实现模型 | 请求一个资源 | 调用一个函数 |
| 接口定义 | 靠文档/OpenAPI，代码和类型分离 | 代码即契约，类型自动推导 |
| 调用方式 | fetch("/api/users", { method: "POST", body: ... }) |
client.getUser({ id: 1 }) |
| 类型安全 | 通常需要额外工具生成类型 | 天然类型安全（比如后面要提到的泛型推导） |
| 适用场景 | 面向公网、跨语言、浏览器兼容 | 内部服务间通信、CLI↔Worker、微服务 |
4. RPC 客户端类型推导
javascript
type RpcClient = ReturnType<typeof Rpc.client<typeof rpc>>- 利用 TypeScript 的类型推导，从 rpc 服务定义中自动提取出客户端的类型
- 这样后续调用
client.call("fetch", ...)时能获得完整的参数提示和返回值类型检查
这是一种类型安全 RPC 的典型写法：服务端定义了哪些方法、参数是什么类型，客户端自动获得对应类型，无需手写接口
💡 一句话总结
RPC = 把网络请求伪装成本地函数调用，开发者只管调函数、传参数、拿结果，底层的序列化、传输、路由全由框架自动完成。
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog