Ruby UTCP：面向工具调用的可扩展安全替代方案

Ruby UTCP 是什么

Ruby UTCP 将 UTCP 1.1（Universal Tool Calling Protocol，通用工具调用协议）引入 Ruby 生态，为应用程序和 AI 智能体提供了一套标准化的工具发现与调用机制。与近来广受关注的 MCP（Model Context Protocol）不同，Ruby UTCP 强调让智能体直接通过原生协议访问工具，而不需要额外的中间层封装。

这一项目在 Product Hunt 上线后获得了 85 票，位列当日排行榜第 7 名，被归入开源、人工智能、GitHub 等分类。项目由 Juan Viera Garcia 等开发者主导，并已开源，专为 Ruby 社区打造。

UTCP（Universal Tool Calling Protocol）是一套旨在标准化 AI 智能体与外部工具之间交互方式的开放协议规范。其核心理念是让智能体直接通过目标服务的原生传输协议发起调用，而非依赖统一的中间代理层进行转译。UTCP 1.1 是该协议的当前版本，定义了工具注册、能力声明（capability manifest）、调用约定与响应格式等基础规范。与 MCP 的"服务端统一封装"思路相比，UTCP 更像是一套元协议：它描述"如何描述工具"，而把具体的通信细节留给各传输层自己处理。这种设计使得同一个工具定义可以在 HTTP、gRPC、WebSocket 等不同传输层上复用，协议本身不强绑定任何单一通信方式。

多传输协议是最大亮点

Ruby UTCP 最引人注目的地方在于它对 12 种传输协议 的原生支持，覆盖了当下主流的通信方式：

• HTTP
• CLI（命令行调用）
• WebSocket
• gRPC
• GraphQL
• MCP（兼容 Model Context Protocol）
• WebRTC

这种广泛的传输层覆盖意味着开发者无需为不同场景引入多套工具调用框架。无论是传统的 HTTP REST 接口、需要低延迟的 gRPC 服务，还是实时性要求高的 WebSocket 与 WebRTC，都可以在同一套协议规范下统一调用。

值得关注的是，Ruby UTCP 把 MCP 也纳入为一种支持的传输方式，这表明它并非要彻底取代 MCP，而是提供一个更上层、更具包容性的抽象——既能兼容 MCP 生态，又能延伸到 MCP 目前较难覆盖的原生协议场景。

UTCP 与 MCP 的定位差异

MCP 近一年来成为连接大模型与外部工具的重要协议，但它主要围绕一套标准化的服务端封装展开。UTCP 的设计思路则有所不同：它主张让 AI 智能体尽可能贴近原生协议去发现和调用工具，减少协议转换带来的开销与安全面扩大。

项目将自己定位为 MCP 的"可扩展、更安全的替代方案"。所谓可扩展，体现在多传输支持和可编程的多工具工作流；所谓安全，则与减少中间层、直接走原生认证机制有关。当然，这是项目方的宣传定位，实际的安全性与可扩展性仍需在真实生产环境中检验。

MCP（Model Context Protocol）由 Anthropic 于 2024 年末推出，旨在为大语言模型提供一套访问外部上下文与工具的标准接口。MCP 的架构以"MCP Server"为核心：工具提供方将自己封装成符合 MCP 规范的服务端，模型或智能体通过统一的 MCP 客户端与之通信。这种集中式抽象降低了接入门槛，但也引入了额外的协议转换层——原生 REST、gRPC 等接口需要先被包装成 MCP 服务才能被访问。UTCP 批评这一模式带来了不必要的中间环节，认为每增加一个代理层就意味着更大的攻击面和更多的延迟开销。两者并非纯粹对立：如本文所述，Ruby UTCP 已将 MCP 纳入其支持的传输协议之一，说明在实际生态中两者更可能走向互补而非彼此替代。

面向 AI 智能体的关键能力

除了传输层的广度，Ruby UTCP 还提供了一批面向 AI 智能体场景的实用能力：

流式传输与认证

支持 streaming（流式响应）意味着智能体在调用长耗时工具或大模型接口时，可以逐步接收结果而非一次性等待，这对交互式体验至关重要。内建的 auth（认证）机制则解决了工具调用中的权限与身份问题。

OpenAPI 自动发现

通过 OpenAPI discovery，Ruby UTCP 能够自动解析符合 OpenAPI 规范的接口定义，将现有 REST API 快速转化为可被智能体调用的工具。这大幅降低了将存量服务接入智能体生态的门槛。

OpenAPI（原 Swagger）是目前描述 REST API 最广泛使用的规范，以 JSON 或 YAML 格式定义接口的路径、参数、请求体与响应结构。绝大多数现代 Web 框架（包括 Rails）都能自动生成符合 OpenAPI 3.x 规范的文档。Ruby UTCP 的 OpenAPI discovery 功能正是利用了这一点：它解析现有服务暴露的 OpenAPI 文档，自动提取出可调用的端点，并将其转化为 UTCP 工具定义，供智能体检索和调用。这意味着一个已有完整 OpenAPI 文档的 Rails 应用，理论上无需任何业务代码改动就能被接入智能体生态，大幅缩短了存量服务的 AI 化改造周期。

CodeMode 可编程工作流

CodeMode 允许开发者编排可编程的多工具工作流，让智能体在一次任务中串联调用多个工具、组合逻辑。这类能力正是当前 Agent 框架竞争的核心方向之一，也是 Ruby UTCP 区别于简单工具网关的地方。

对 Ruby 生态的意义

长期以来，AI Agent 与工具调用的开源工具主要集中在 Python 与 JavaScript 生态，Ruby 开发者往往缺少现成的标准化方案。Ruby UTCP 的出现填补了这一空白，让 Rails 应用和 Ruby 服务能够以原生方式接入现代 AI 智能体架构。

对于已经在使用 Ruby 构建后端的团队而言，这意味着可以在熟悉的技术栈内实现工具发现、协议调用与多工具编排，而不必迁移到其他语言或引入重量级依赖。

值得观察的问题

作为一个新上线的开源项目，Ruby UTCP 目前更多是能力与愿景的展示。它对 12 种传输协议的支持成熟度、CodeMode 在复杂工作流下的稳定性，以及"比 MCP 更安全"这一主张的实际验证，都还需要社区在真实项目中反馈。评论数目前仅有 1 条，说明它仍处于早期传播阶段。

对关注 AI 工具调用协议演进的开发者来说，Ruby UTCP 提供了一个观察 UTCP 路线与 MCP 路线如何竞争与共存的有趣样本。