countinghouse：支持进程内 MCP 工具互调的多租户运行时

近日在 Hacker News 上亮相的 countinghouse，是一个面向 MCP（Model Context Protocol）的多租户运行时项目，采用 Apache-2.0 协议，已发布到 npm。其作者并非 AI 行业新人，而是把十年前自己用于 IoT 设备互联的框架「CDIF」重新激活，定位为面向第三方开发者的 MCP 托管与结算平台。

项目核心：把 MCP 当作服务发现协议来跑

countinghouse 的设计延续了 MCP 的核心契约：每个工具暴露一个发现端点，返回机器可读的描述；调用端点接收一个 schema 定义的 JSON 对象作为入参，返回一个 schema 定义的 JSON 对象作为出参，服务端在进入实现代码之前完成校验。这一「单对象进、单对象出」的形态，正是作者 2016 年在 CDIF 中通过 allowSimpleType 标志强制执行的规则，也与 gRPC 的消息设计异曲同工。

换句话说，作者认为 MCP 并不是凭空发明，而是把「跨进程、跨团队、无需共享代码的服务调用」这一已经存在多年的设计范式标准化了。当客户端变成 LLM 之后，自描述接口从「锦上添花」变成了「承重墙」——模型读一份描述、填一个对象、处理响应，这件事它比任何传统客户端都做得好。

与早期 IoT 框架的对照

CDIF 诞生于 2015 年前后的物联网浪潮，解决的是异构设备（Z-Wave、ZigBee、UPnP 以及普通 Web 服务）之间的互操作问题。客户端的整个生命周期被压缩为四个 HTTP 调用：列出可用设备、获取设备的 JSON 描述、获取入参的 dereferenced JSON Schema、按 JSON payload 调用动作。十年后回头看，这套流程与 MCP 的 tools/list、tools/call、inputSchema 完全一一对应。

作者强调，这并不意味着 MCP 借鉴了 CDIF，而是三种独立压力（gRPC 追求向前兼容、CDIF 追求类型卫生、MCP 追求生成可靠性）收敛到了同一个解。位置参数是同进程函数调用的产物；一旦调用双方不共享代码，「单对象进、单对象出」就不再是约定，而更像是一条工程上的经验法则。

countinghouse 的工程细节

复活并非简单的改名上架。作者列出几个关键工作：

• JSON Schema 从 draft-04 迁移到 2020-12，并为每一个模块规范写了迁移脚本。
• 接入 MCP 的无状态 Streamable HTTP 传输。
• 十年积累的 ES5 代码全部重写。
• npm audit 从 31 个 high/critical 漏洞清理到 0，残留 4 个 moderate（另在开发工具链中存在，作者未掩饰）。

最大的结构性改动是把曾经的「可关闭标志」变成唯一规则：每个动作直接携带 input、output、fault 三段 schema，旧的 UPnP 状态表、direction 字段、无人在用的 retval 全部删除。工具的编写方式也从「一个事件发射器加一份重复罗列名称的注册文件」收敛为「一个 async 函数」。

多租户与计费：面向第三方开发者的托管

承载这一切的是一套多租户运行时：每个第三方模块跑在独立的 worker thread 中，拥有隔离的 V8 堆。作者在 docs/security-model.md 中坦率说明了 worker thread 并不能完全阻挡哪些威胁，给出了「诚实的威胁模型」。在此之上，还包括按 API key 的计量、限流，以及一套 verify/publish 流水线。

作者认为，当前 MCP 托管赛道的玩家几乎都在做「托管工具」，但少有人在工具级别为第三方开发者做计量和结算，这也是 countinghouse 想要切入的位置。换句话说，它不是另一个 MCP 客户端，而是面向工具发布者的基础设施层。

从 IoT 到 LLM：消费者变了，合约没变

CDIF 在 2015 年商业上没有跑通，原因是当时并不存在「通用消费者」——schema 驱动的表单生成器、可视化流程编辑器是有用但小众的方案；普通开发者更愿意直接集成 SDK。直到 LLM 出现，「读过就能填、从未见过也能调」的客户端才大规模出现。

作者在文中写道：如果你在 2023 年之前就构建过服务基础设施（集成平台、ESB、设备抽象层），你的旧代码可能比大多数全新项目更接近 MCP-ready。难点从来不是传输层，而是「机器可读合约」的纪律——而这件事，作者在没有任何 AI 动机的情况下，已经执行了十年。