将大语言模型(LLM)与外部工具连接,是扩展其能力的主流方法。通过给模型提供工具,它就能查询数据、调用 API,完成更复杂的任务。
提供工具时,可以使用 MCP 模式,简单来说:由一个外部的、集中的工具服务来提供所有工具,开发者写的应用直接调用这个服务,让它去和模型沟通。
这样做表面上简化了开发,开发者不用自己管理工具了。但问题也恰恰出在这里:应用的开发者,失去了对模型上下文的精确控制权。
这是一个根本性的问题,会引发一连串的麻烦。
一个具体的例子:MCP 架构
我们来看看 MCP(Model Context Protocol)这个框架的实现方式。它清楚地展示了这种分离模式。
在 MCP 的世界里,开发者分为两类:
Server 开发者:他们负责创建工具。
Client 开发者:他们负责写真正面向用户的应用,并调用 Server 提供的工具。
这就是我们要讨论的核心风险。
1. 控制权交给了别人
AI 应用的核心,是开发者与大模型之间的交互。开发者应该精确地告诉模型在当前场景下,它能做什么。
在上面的例子中,Client 开发者完全放弃了这种控制。如果 weather-server 的开发者某天在服务器上增加了一个新工具,或者修改了 get_alerts 工具的描述,所有使用这个 Server 的 Client 应用,都会在不知情的情况下立刻受到影响。
2. 浪费了宝贵的上下文
大模型的 “上下文窗口” 是有限且有成本的。
MCP 官方的示例中,就罗列了大量的 “即插即用” 型 Server,比如 Filesystem、Git、PostgreSQL。一个 Client 应用可能会连接多个 Server。
想象一下,你的应用只是想问个天气,但因为连接了多个 Server,list_tools () 可能会返回十几个不相关的工具(比如文件读写、数据库查询等)。这些多余的工具定义会被全部发送给大模型,不仅增加了推理成本和时间,还会像噪音一样干扰模型,让它难以选择正确的工具。
3. 工具的质量无法保证
工具的名称和描述对模型能否正确使用至关重要。最了解应用需要什么样工具的人,是 Client 开发者自己。
但是,在 MCP 模式下,Client 开发者无法修改 Server 提供的工具描述。如果 Server 的工具描述写得含糊不清(比如一个叫 process_data 的函数),Client 开发者要么只能忍受,要么就得放弃使用整个 Server。他失去了根据自己业务场景,“精雕细琢” 工具描述的能力。
4. 安全性和稳定性的风险
这是最严重的问题。由于 Client 开发者无法控制工具集,应用的安全和稳定就依赖于外部的 Server。
以 mcp-server-filesystem 这个官方工具为例,它能执行文件操作。如果一个 Client 应用连接了它,就等于把文件操作的潜力暴露给了大模型。Client 开发者必须完全信任这个 Server 的实现是绝对安全、没有漏洞的。
如果 Server 的开发者在一次更新中,不小心引入了一个允许删除任意文件的 Bug,那么所有连接到这个 Server 的 Client 应用,都可能在用户不知情的情况下,执行危险的操作。这种风险是灾难性的。