没有 schema 的远程调用：Cloudflare 的 Cap'n Web 想把接口设计还给语言本身

为什么"系统对接"总是很痛

做过企业系统集成的人都知道，两套系统之间的每一次对接，成本大头从来不在业务逻辑，而在接口约定：定义数据结构、写文档、双方对齐字段、上线后发现字段理解不一致，再改一遍。RPC 框架存在的意义就是把这层摩擦压下去，但传统方案往往又引入了新的负担——接口定义语言、代码生成、版本兼容。

Cloudflare 开源的 Cap'n Web 选择了另一个方向：一个纯 TypeScript 的 RPC 协议实现，没有 schema，几乎没有样板代码，序列化就是人可以读的 JSON，客户端和服务端都像在写普通的 JavaScript 函数。

对象能力模型带来的三个特性

Cap'n Web 是十年前 Cap'n Proto 的 "精神兄弟"，但为 Web 技术栈重新设计。它实现的是对象能力（object-capability）RPC 模型，由此带来几个少见的能力：支持双向调用——客户端可以调服务端，服务端也能反过来调客户端；支持函数和对象按引用传递，把一个函数传过去，对方拿到的是一个 "桩"，调用它等于回调到你这里；支持承诺流水线，发起一次调用拿到 promise 后不必等它返回，可以直接在后续调用里使用，于是链式调用能在一次网络往返里完成。

最后一点对体验的影响最直接。很多 "点了按钮要转三圈" 的界面，根因就是串行等待；承诺流水线把等待压到一次。

工程上的取舍

它开箱支持 HTTP、WebSocket 和 postMessage，能在浏览器、Workers、Node.js 里跑，压缩后不到 10kB，没有任何依赖，MIT 许可。代价是：没有 schema 意味着没有编译期的强约束，类型安全要靠 TypeScript 自己维系；能力模型虽然优雅，但团队需要理解 "引用传递" 带来的生命周期与权限问题。

对企业内部系统的启发

不必立刻换掉现有框架，但这个方向值得记住：把接口设计拉回到 "像写普通代码一样"，同时承认网络延迟的存在，这件事对内部工具的收益往往比对外部 API 更大。当一套系统的对接成本从 "两周对齐文档" 降到 "半天写个类", 小的自动化需求才有机会被真正做出来。