如何设计工具注册中心，并划分接口、能力和实现层？

核心回答

工具注册中心负责把模型能理解的能力描述、稳定调用契约和真正执行的代码或服务关联起来，提供注册、查询、发现和执行路由。工具少时可以是进程内的注册表，规模和治理需要增加后再做服务化。

可以按以下三项职责划分：

• 接口层：对上提供统一的工具定义、查询和调用入口，明确名称、参数、结果及错误契约。
• 能力层：描述业务上能做什么、何时使用、限制和副作用，并关联可用实现，支持按任务发现工具。
• 实现层：真正执行函数、HTTP API或MCP调用，处理底层协议、字段映射和服务依赖。

例如“查询订单”是一项业务能力，模型看到 get_order 的说明和参数规则，底层可以对接不同订单系统。更换实现时，上层尽量保持稳定，但参数含义、结果语义和权限也必须兼容，不能只保证字段名一样。

展开说明

1. 注册记录要同时回答“怎么理解”和“怎么执行”

一条工具记录可以包含三组信息：

• 调用契约：稳定标识、名称、版本、描述、输入Schema、结果结构和错误类型。
• 业务能力：业务域、适用场景、前置条件、查询或修改等副作用、所需权限。
• 执行绑定：实现标识、函数句柄或服务地址、协议适配器、超时和可用状态。

模型只需要当前任务相关的工具描述和参数规则；函数句柄、凭证、内部路由等由执行系统使用，不应全塞进模型上下文。凭证可保存为受控引用，由运行时获取。注册入口也要校验定义和来源，避免错误或不可信工具进入目录。

这三组信息可以保存在同一注册对象中，不要求拆成三套数据库。框架已有Tool对象和调用入口时，可以复用它们，再补能力标签、版本、权限及后端绑定。

2. 三层用一项能力贯穿，避免抽象只剩名字

以查询订单为设计示例：

接口层对外暴露 get_order，参数是业务订单编号，返回订单标识、状态和查询结果说明。它还规定资源不存在、无权访问、服务超时等情况怎样表示。

能力层说明该工具用于查询订单信息，不负责创建或修改订单；用户只给商品名时可能还需要先定位订单。它将这项能力关联到对应实现，并根据环境、调用者范围和可用性确定哪些实现可以使用。

实现层负责把内部参数映射成具体订单系统的HTTP请求，附带受控身份，解释底层状态码，再转换为统一结果。若接入另一个系统，需要对齐订单状态、标识和字段含义；不是包一层相同JSON，就已经语义兼容。

一种能力也可能需要多个工具，例如先搜索订单，再查询单个订单。反过来，同一工具契约可以对应不同部署实现。注册关系要清楚，不能把业务能力、公开工具名和服务实例地址混成同一个标识。

3. Agent怎样通过注册中心完成一次调用？

先根据任务发现相关能力，按当前权限和可用性过滤，再把选定工具的完整契约适配给模型。模型返回工具名和参数后，执行器按本次可用目录解析到确切版本和实现，校验参数、资源归属及操作条件，再发起真实调用。结果关联原调用返回，供Agent继续执行或回答。

工具较多时可以先检索候选，再展示完整Schema；这减少模型选择负担，但执行注册和对模型展示是不同动作。没有给模型展示某个工具，也不能让模型猜出的名字绕过执行端校验。

接入MCP时，Client可通过 tools/list 获取Server工具定义，宿主把它适配到内部目录，再通过 tools/call 调回对应Server。MCP没有规定必须存在一个全局注册中心。聚合多个Server时要使用应用管理的来源标识消除同名冲突，不能假定各Server自报名称天然唯一。

当前LangChain工具接口也区分模型参数和运行上下文，例如 ToolRuntime 由程序注入，不作为模型可填写的Schema参数。用户身份等可信信息适合走这类运行通道，但最终仍需要具体业务授权检查。

4. 实现替换和动态更新要守住契约

工具上线时检查Schema、实现绑定与结果是否一致，测试参数错误、无数据、拒绝和超时等路径。版本变化要说明兼容范围；进行中的调用应能定位到当时采用的契约和实现，不能执行到一半忽然改参数含义。配置快照可以稳定契约，但撤权、停用等当前限制仍要在执行时生效。

重试和降级同样取决于业务语义。查询超时可以按策略重试或切换等价实现；创建订单超时且结果未知时，应先凭业务标识查原操作，不能立刻换一个实现再创建一次。注册中心可以保存策略和绑定，外部副作用的一致性仍需业务接口和执行器配合。

注册中心的价值可以通过具体任务检查：是否找到正确工具、参数是否有效、结果含义是否一致、实现更新是否破坏已有调用。工具数量和可动态注册，本身不能说明任务完成得好。

常见追问

能力层和接口层都写了说明，会不会重复？

要避免重复维护同一事实。能力层关注业务用途、限制及可发现性，接口层关注可调用契约。工具给模型看的描述可以由能力元数据与契约生成，但应有明确的权威来源和版本，不能两处手写后逐渐不一致。简单系统可以把这些信息放在同一个定义里。

和Nacos、MCP有什么区别？

服务注册发现关注服务实例地址、健康与路由；工具注册还需要让Agent理解业务用途和参数结果。MCP提供工具发现和调用协议，可作为工具接入方式。可以复用已有服务治理设施，也可以先使用本地注册表，职责相互补充。

只把函数放进一个Map算注册中心吗？

可以是最小实现：工具名映射函数，同时保存可提供给模型的定义。需要进一步说明参数校验、执行上下文和结果关联放在哪里。当工具增多或跨服务时，再逐步补发现、版本、权限和适配，没必要一开始就独立部署注册平台。

对应教程

参考资料