← 返回概念辨析

Concept Contrast Fable

工具注册表和模型上下文协议

工具注册表是一份名单,告诉你有哪些工具可用。MCP 是一套沟通规则,决定了工具怎么被发现、怎么被调用、怎么回报结果。有名单没规则,等于有电话号码但双方不会说同一种语言。

寓言

号码簿和电话线

城里有座百工馆,墙上挂着一块名录,写着谁会修钟、谁会配药、谁会测井水。新来的总管只要看名录,就知道城里有哪些手艺可用。

一开始,名录很有用。有人要修桥,总管翻到木匠;有人要查账,总管找到铁算盘师傅。可真正请人干活时,问题来了:各家递单格式不同,有人要红纸,有人要口信,有人只认旧印。

总管以为把名录写得更详细就行。他给每个手艺人加上地址、价钱、脾气、开门时辰。名录厚了许多,跑腿的人仍常被退回,因为他们不知道该按哪套规矩交接材料。

一次水井出浑,验水师傅、泥瓦匠、医馆都要参与。名录能告诉总管“城里有这些人”,却不能让三家按同一种方式接收样本、回送结果、说明失败原因。

百工馆后来设了一条统一传递规矩:请谁、带什么材料、怎样说明要求、对方怎样回话、做不了时怎样退回,都有共同格式。名录仍挂在墙上,但跑腿不再各猜各的门道。

新规矩还解决了退件问题。过去师傅做不了,只把跑腿人赶回去;现在必须说明缺什么材料、哪项条件不满足、是否可换另一位师傅。请求不再在门口无声消失。

后来百工馆扩到邻城,名录增加得很快,驿道规矩却保持一致。总管终于不用为每个新手艺重新教一套送信办法。百工馆还把权限写进驿道。修钟匠能收齿轮样本,不能看医馆病历;验水师傅能退回浑水样,不能改桥梁图纸。统一传递规矩不只是方便跑腿,也让每次交接有边界、有回执、有失败说明。总管还要求每次调用都有回执。请了谁、带了什么、对方收没收、失败原因是什么,都要回到同一本记录里。

老总管把两本册子分开放。薄册回答“有哪些手艺可找”,厚册规定“怎样把请求和结果可靠地送过去”。前者像名单,后者像驿道;名单没有驿道,知道谁会做也未必请得动。

工具注册表

一个目录或清单,记录 Agent 可以调用哪些外部工具、每个工具的接口描述和参数规格。它解决的是「有什么可用」的问题。

模型上下文协议 (MCP)

一套标准化的通信协议,定义了模型与外部工具之间如何发现、连接、调用和交换数据。它解决的是「怎么用」的问题,包括认证、请求格式、响应格式和错误处理。

故事对应

  • 号码簿:工具注册表,列出可用工具的清单和描述。
  • 供应商各说各的语言:没有统一协议时,每个工具的调用方式不一致。
  • 老郑制定的统一标准:MCP 这类协议做的事——标准化发现、调用、响应流程。
  • 可用性探测器:协议层面的健康检查和动态发现机制。
  • 号码簿封面加的那行字:注册表的价值依赖于通信协议的存在。

落到项目里

搭建 Agent 工具系统时,先定通信协议再填注册表。协议定了(MCP 或其他标准),后面加新工具只是往注册表里增条目。反过来先攒一堆工具再补协议,每个工具的接入方式都不一样,改造成本远超预期。评审时问一句:换一个工具实现,Agent 需要改代码还是只改注册表配置?