文章摘要
大型语言模型（LLM）无需理解模型上下文协议（MCP）即可有效工作。MCP标准化了代理与工具的连接方式，但LLM只需看到工具定义列表，无需关心背后的具体实现。MCP简化了工具调用设置，开发者负责调用工具，而LLM仅生成调用工具及其参数的代码片段。
文章总结
标题：LLM无需理解MCP
主要内容：
在构建AI代理时，模型上下文协议（MCP）已成为工具调用的标准。然而，与普遍认知相反，大型语言模型（LLM）并不需要理解MCP。你可能听说过“上下文工程”这一术语，即与LLM交互的人负责提供正确的上下文以帮助其回答问题。为了收集这些上下文，你可以使用工具调用，让LLM访问一组工具以获取信息或执行操作。
MCP通过标准化代理与这些工具的连接方式来提供帮助。但对LLM来说，使用MCP与“常规”工具调用并无区别。它只看到工具定义的列表，并不关心背后的操作。这是件好事。
使用MCP，你可以访问数千种工具，而无需为每种工具编写自定义集成逻辑。它极大地简化了涉及工具调用的代理循环设置，通常几乎不需要开发时间。开发者负责调用工具，LLM只生成调用哪些工具及输入参数的代码片段。
LLM理解工具调用的概念，有时也称为工具使用或函数调用。你可以在提示中提供工具定义的列表，每个工具包括名称、描述和预期输入参数。基于问题和可用工具，LLM可能会生成调用。
但重要的是，LLM并不知道如何使用工具。它们没有原生工具调用支持，只是生成表示函数调用的文本。例如，如果你提供一个名为get_weather的工具，并询问“圣何塞的天气如何？”，LLM可能会生成如下代码片段：
json
{
"name": "get_weather",
"input": {
"location": "San Jose, CA"
}
}
LLM基于提供的上下文生成此片段，但它并不知道如何调用get_weather工具，也不需要知道。你的代理循环或代理应用程序负责解析生成的工具名称和输入，运行工具，并将结果作为新消息传递回LLM。
MCP是一种标准化代理连接到数据源（如工具、提示、资源和样本）的方式。目前，MCP以简化工具连接而闻名。它定义了一致的模式和通信模式，就像工具领域的通用适配器（如USB-C）。
MCP通常涉及三个组件：主机应用程序、MCP客户端和一个或多个MCP服务器。主机可能是包含MCP客户端的聊天应用或IDE，能够连接到不同的服务器。这些服务器暴露工具、提示、样本或资源。
与LLM的交互方式不变，变化的是工具如何呈现给它。代理应用程序与MCP客户端通信，客户端与正确的服务器通信。工具以LLM可使用的格式描述。
MCP的好处在于为开发者管理复杂性，而不是为LLM。它帮助管理随着代理增长而增加的多种工具，使跨项目重用工具、强制执行一致格式和插入新系统变得更容易，而无需重写所有内容。
LLM永远不会知道你正在使用MCP，除非你在系统提示中告知它。开发者负责调用工具，LLM只生成调用哪些工具及输入参数的代码片段。
上下文工程是关于为LLM提供正确的输入，以便生成有用的输出。这听起来简单，但实际上是构建有效AI系统最重要的部分之一。当你向模型提问时，你实际上是在给它一个提示——它用来预测下一段文本的文本块。提示的质量直接影响响应的质量。
工具调用通过让模型访问外部系统来解决这个问题。但模型不需要知道这些工具如何工作，只需要知道它们的存在、用途和调用方式。这就是上下文工程与工具设计的交汇点，你正在制作一组工具定义，作为模型提示的一部分。
MCP使这一过程更清晰、更可重复。你定义一次结构化接口，并通过MCP暴露它。LLM仍然看到相同类型的工具定义，但现在它们更容易维护和扩展。
最终，MCP是开发者而非LLM的工具。它帮助我们构建更可靠、模块化的系统，并专注于上下文工程，而无需每次都重新发明轮子。
评论总结
评论内容主要围绕MCP（可能指某种工具或协议）的实用性、复杂性和未来前景展开，观点多样且存在争议。以下是总结：
1. MCP的实用性与复杂性
- 支持观点：MCP在特定场景下有用，尤其是在需要约束AI输出格式（如JSON）时，能够限制工具调用和参数。
引用：- "AI output can be constrained to a fixed format... MCP is useful because the 'tool_calls' section of that fixed JSON output can be restricted." (zozbot234)
- "It actually works when you prompt the LLM with 'use the abc MCP'." (nsonha)
- 反对观点：MCP增加了复杂性，对于简单应用可能不必要，甚至可能降低性能。
引用：- "If all your app needs few internal calls, MCP may be an overkill in beginning." (malpani12)
- "Simply making more tools available can give the agent more capabilities, but it can easily trash performance." (ai-christianson)
2. MCP的设计与用户体验
- 批评：MCP设计不够直观，可能是一种匆忙推出的概念，用户更倾向于使用其他更直观的工具。
引用：- "MCP seems just like a rushed concept... Very un-intuitive at first." (TechDebtDevin)
- "Why am I not just importing a package of tools, I’m not sure what the MCP server is adding." (crowcroft)
- 支持：MCP为本地模型提供了更多可能性，尤其是在边缘计算场景中。
引用：- "The way I’ve been thinking about MCP has been how you unshackle the local models as I believe the future will be inference at the edge." (DrAwdeOccarim)
3. MCP的未来前景
- 质疑：MCP是否会被广泛采用，尤其是在通用聊天机器人（如ChatGPT）主导的生态中，可能显得多余。
引用：- "Will anybody care about MCP? If LLMs are still wrapped in application wrappers, isn’t a more traditional agentic approach going to make more sense?" (dougbright)
- 探索：MCP在多模型交互中可能有潜力，但具体实现方式尚不明确。
引用：- "In a multi model situation, shouldn’t LLM A talk to LLM B as a tool call via MCP?" (the_arun)
4. 工具调用的本质
- 反思：LLM并不真正“理解”工具调用，只是生成代表函数调用的文本，这引发了对工具使用本质的思考。
引用：- "LLMs don’t know how to use tools. They just generate text that represents a function call." (creddit)
- 替代方案：直接使用HTTP调用API可能更简单直接。
引用：- "Use raw HTTP calls to API, like a man." (donpepitogrillo)
5. 上下文工程与MCP的关系
- 观点：上下文工程不仅仅是增强提示工程，而是为代理创建丰富的操作环境，MCP可能在其中发挥作用。
引用：- "Context Engineering is not just 'enhanced prompt engineering'... It is creating the context in which an agent operates." (aeon_ai)
总结：MCP在特定场景下有其价值，但其复杂性、设计直观性和未来前景受到质疑。用户对其态度两极分化，部分人认为其是未来边缘计算的关键，而另一些人则认为其可能被更简单的工具或传统方法取代。