通用工具调用协议 (UTCP，Universal Tool Calling Protocol) 是一种轻量级、安全且可扩展的方式，可供 AI 代理和应用程序直接查找和调用工具，而无需额外的封装服务器。
主要特点
- 轻量且安全：允许直接访问工具，避免不必要的中间层。
- 可扩展：可以支持大量工具和提供商，而不会损失性能。
- 模块化设计：1.0.0 版本引入了基于插件的核心，使协议更易于扩展、测试和打包。
- 基于 Pydantic 模型构建：提供简单、定义明确的数据结构，使实现变得简单。
当前方法的问题
传统的集成工具解决方案通常需要：
- 为每个工具构建和维护封装服务器
- 通过中央协议或服务路由所有流量
- 重新实现每个工具的身份验证和安全性
- 接受额外的延迟和复杂性
这些步骤给开发人员增加了摩擦并减慢了执行速度。
UTCP解决方案
UTCP 提供了更好的替代方案：
- 定义一个清晰的、与语言无关的标准来描述工具及其界面
- 允许代理使用其本机通信协议直接连接到工具
- 提供一种允许开发人员添加以下内容的架构：
- 新的通信协议（HTTP、SSE、CLI 等）
- 替代存储系统
- 自定义搜索策略
所有这些都可以在不修改核心库的情况下完成。
通过消除对封装服务器或其他繁重中间层的需求，UTCP 简化了 AI 代理和应用程序与工具的连接方式。由于请求不再需要经过额外的基础设施，它降低了延迟和整体复杂性。身份验证和安全也变得更加简单，因为 UTCP 允许代理使用工具的现有机制，而无需在中间服务中重复这些机制。这种更精简的方法还使集成的构建、测试和维护变得更加容易，同时随着工具和提供商数量的增加，它也能自然地支持业务的增长。
工作原理
UTCP 使工具集成变得简单且可预测。首先，AI 代理通过获取 UTCP 手册来发现您的工具，该手册包含您公开的每项功能的定义和元数据。接下来，代理通过阅读手册并理解相关的调用模板来学习如何调用这些工具。定义明确后，代理可以使用 API 的原生通信协议直接调用它们。最后，您的 API 处理请求并返回正常响应。此过程确保了无缝的互操作性，无需额外的中间件或自定义转换层。
架构概述
UTCP 1.0 版引入了模块化、基于插件的架构，旨在实现可扩展性和灵活性。其核心是手册，用于定义工具及其元数据，以及调用模板，用于指定如何通过不同协议与各个工具进行交互。
UTCP 客户端充当发现工具和执行调用的引擎。围绕此核心的是一个插件系统，支持协议适配器、自定义通信方法、工具存储库和搜索策略。这种关注点分离使得系统能够轻松扩展或针对特定环境进行定制，而无需改变其基础。
UTCP 与 MCP 有何不同？
UTCP 和 MCP 都支持 AI 代理连接外部工具，但它们侧重于不同的需求。UTCP 支持通过简单的 JSON 手册直接调用 API、CLI、WebSocket 和其他接口，从而保持基础设施轻量和低延迟。MCP 提供了一个更结构化的层，将工具封装在专用服务器后面，并使用 JSON-RPC 实现通信标准化。
要点：
- 架构：UTCP 将代理直接连接到工具；MCP 使用服务器层进行路由。
- 性能和开销： UTCP 最大限度地减少跳数；MCP 集中呼叫但增加了一层处理。
- 基础设施：UTCP 只需要手册和发现端点，而 MCP 依靠服务器进行包装和路由。
- 协议支持： UTCP 可跨 HTTP、WebSocket、CLI、SSE 等协议运行；MCP 专注于 JSON-RPC 传输。
- 安全和授权： UTCP 使用工具的现有机制，而 MCP 管理其服务器内部的访问。
- 灵活性：UTCP 通过其 MCP 插件支持混合部署，而 MCP 提供集中管理和监控。
这两种方法都很有用：UTCP 非常适合轻量级、灵活的集成，而 MCP 适合想要具有内置控制的标准化网关的团队。
结论
UTCP 是一款面向工具提供商和 AI 开发者的多功能解决方案。它允许 API 所有者、SaaS 提供商和企业团队以简单、安全的方式向 AI 代理公开 REST 或 GraphQL 端点等服务。同时，构建代理或应用程序的开发者可以使用 UTCP 轻松连接内部或外部工具。通过消除复杂性和开销，UTCP 简化了集成，使软件能够更轻松地访问强大的功能。
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/61743.html
