📢 转载信息
原文链接：https://www.kdnuggets.com/the-mcp-revolution-and-the-search-for-stable-ai-use-cases
原文作者：Rachel Kuznetsov, KDnuggets
Image by Editor
# 介绍MCP
标准能否成功或失败取决于其采用率，而非技术上的优越性。模型上下文协议（Model Context Protocol, MCP）从一开始就领悟了这一点。MCP由Anthropic于2024年末发布，它解决了一个简单的问题：人工智能（AI）模型应如何与外部工具进行交互。该协议的设计足够简单，以鼓励实施，其效用又足够明确，以推动需求。几个月内，MCP引发了将一个好主意转变为行业标准的网络效应。然而，正如AI研究员兼数据工程师Sebastian Wallkötter在最近的谈话中所解释的那样，这种迅速的采用引发了关于安全性、可扩展性以及AI代理是否总是正确解决方案的关键问题。
Wallkötter为这些讨论带来了独特的视角。他于2022年在乌普萨拉大学完成了关于人机交互的博士学位，专注于机器人与人类如何更自然地协同工作。此后，他转向商业AI领域，从事大型语言模型（LLM）应用和代理系统的工作。他的背景弥合了学术研究与实际应用之间的差距，为AI系统的技术能力和现实世界约束提供了宝贵的见解。
# 为什么MCP赢得了标准之争
模型上下文协议解决了一个看似简单的问题：如何创建一种可重用的方式，让AI模型能够访问工具和服务。在MCP出现之前，每个LLM提供商和每个工具创建者都必须构建定制的集成。MCP提供了一种通用语言。
Wallkötter解释说：“MCP确实非常专注于工具调用。你有一个代理或LLM或其他什么东西，它应该与Google Docs、你的日历应用或GitHub或其他类似的东西进行交互。”
该协议的成功与其它平台标准化故事如出一辙。正如Facebook在足够多的用户加入使其网络变得有价值时达到临界质量一样，MCP也达到了一个临界点：提供商愿意支持它，因为用户需要它；用户需要它，因为提供商支持它。这种网络效应推动了跨越地域的采用，在美国和欧洲的实施之间没有明显的区域偏好。
采用的速度让许多人感到惊讶。在其2024年10月发布后的几个月内，主要平台就集成了MCP支持。Wallkötter推测，最初的动力来自于开发者认识到了其实际价值：“我怀疑只是某个工程师心想，‘嘿，这是一种有趣的方式。我们来试试看。’” Wallkötter进一步解释了这种动态：“一旦MCP足够大，所有提供商都会支持它。所以为什么你不愿意做一个MCP服务器以便与所有模型兼容呢？反之亦然，每个人都有一个MCP服务器，所以你为什么不支持它呢？因为这样你就能获得很大的兼容性。”该协议比大多数观察者预期的更快地从一个有趣的技术规范发展成为一个行业标准。
# 安全盲点
然而，快速采用暴露了原始规范中存在的重大空白。Wallkötter指出，开发者很快发现了一个关键漏洞：“第一版MCP完全没有包含任何身份验证。所以世界上任何人都可以在任何MCP服务器上调用它，运行一些东西，但这显然可能适得其反。”
身份验证的挑战比传统Web安全模型更为复杂。MCP涉及三方：用户、LLM提供商（如Anthropic或OpenAI）以及服务提供商（如GitHub或Google Drive）。传统的Web身份验证能很好地处理两方交互。用户向服务进行身份验证，这种关系很直接。MCP要求同时考虑所有三方。
Wallkötter解释说：“你有MCP服务器，你有LLM提供商，然后有用户本身。你对哪个部分进行哪个内容的身份验证呢？因为你是在验证是Anthropic与GitHub通信吗？但用户才是主体，对吧？所以是用户在进行身份验证。”
在涉及自主代理时，情况变得更加复杂。当用户指示一个旅行规划代理预订假期，而该代理开始调用各种MCP服务器而没有直接的用户监督时，谁对这些行为负责？是构建代理的公司？是发起请求的用户？这个问题具有技术、法律和道德层面，业界仍在努力解决。
# 提示注入问题
除了身份验证之外，MCP的实现还面临另一个没有明确解决方案的安全挑战：提示注入。这种漏洞允许恶意行为者通过构建输入来劫持AI行为，从而覆盖系统预期的指令。
Wallkötter将其与一个更早的Web安全问题进行了类比。“这让我想起早期的SQL注入时代，”他指出。在早期的Web中，开发人员会将用户输入直接串联到数据库查询中，允许攻击者插入恶意的SQL命令。解决方案是使用参数化查询，将查询结构与数据分开，将用户输入视为纯数据而非可执行代码。
Wallkötter建议：“我怀疑解决方案将与我们为SQL数据库解决问题的方式非常相似。你先发送提示本身，然后将你想要插入到提示不同部分的所有数据分开发送，然后有一个系统位于LLM之前，查看数据并尝试弄清楚那里是否有提示注入。”
尽管有这种潜在方法，但目前还没有广泛采用的解决方案。LLM提供商试图训练模型，使其优先考虑系统指令而不是用户输入，但这些保护措施仍然不完善。“总是有绕过的方法，因为没有万无一失的方法，”Wallkötter承认。
提示注入问题不仅限于安全担忧，还延伸到了可靠性。当MCP服务器返回的数据嵌入到LLM的上下文中时，该数据可能包含覆盖预期行为的指令。遵循精心设计的AI代理工作流程可能会因响应中意外的内容而偏离轨道。在解决此漏洞之前，在没有人为监督的情况下运行的自主代理存在固有风险。
# 工具超载陷阱
MCP的易用性带来了一个意想不到的问题。由于添加新工具非常简单，开发人员经常在他们的应用程序中积累数十个MCP服务器。这种丰富性在可衡量的程度上降低了性能。
Wallkötter观察到：“我看到了一些例子，人们对MCP服务器非常热情，结果却拥有30、40个带有所有功能的服务器。突然间，你的上下文窗口中有40%到50%是从工具定义开始就占用的。”
每种工具都需要一个向LLM解释其目的和参数的描述。这些描述会消耗上下文窗口中的token，上下文窗口是模型保存所有相关信息的有限空间。当工具定义占据一半可用上下文时，模型用于实际对话历史、检索文档或其他关键信息的空间就更少了。性能自然会受到影响。
除了上下文窗口限制，过多的工具还会使模型本身感到困惑。当前一代的LLM在面对大量选项时，难以区分相似的工具。“目前互联网上的普遍共识是，在实践中，30个左右是魔术数字，”Wallkötter指出，描述了性能明显下降的阈值。
这个限制具有架构意义。开发人员应该构建一个具有许多功能的大型代理，还是多个具有重点工具集的较小代理？答案部分取决于上下文要求。Wallkötter提供了一个令人难忘的指标：“如今，对于大多数不错的代理，你在上下文窗口中大约能获得20万个token。这大约相当于整本《傲慢与偏见》。”
这个“简·奥斯汀指标”提供了直观的规模概念。如果代理需要大量的业务背景、格式指南、项目历史和其他背景信息，这种累积的知识很快就会填满可用空间的重要部分。在此背景之上再添加30个工具可能会使系统超出有效操作的范围。
解决方案通常涉及战略性的代理架构。组织可能不会部署一个通用的代理，而是为不同的用例部署专门的代理：一个用于旅行规划，另一个用于电子邮件管理，第三个用于日历协调。每个代理都维护着一套重点工具集和特定指令，避免了功能过于丰富的通用代理的复杂性和混淆。
# 何时不应使用AI
Wallkötter的机器人学背景为评估AI实施提供了一个意想不到的视角。他关于人形机器人的博士研究揭示了一个持续存在的挑战：找到人形形态相对于更简单替代方案提供真正优势的稳定用例。
“人形机器人带来的问题是，它们有点像一种不稳定的平衡，”他解释道，借鉴了一个物理学概念。一个完美直立的钟摆理论上可以无限期地保持站立，但任何微小的扰动都会使其倒下。“如果你稍微扰动它，如果你没有做到完美，它会立即倒下。”人形机器人面临着类似的挑战。虽然它们很迷人，并且能够进行令人印象深刻的演示，但当存在更简单的解决方案时，它们很难证明其复杂性是合理的。
Wallkötter问道：“当你开始真正思考我们可以用它做什么时，你立即面临一个经济问题：你是否真的需要你开始时的人形配置？”“你可以去掉腿换上轮子。轮子更稳定、更简单、制造成本更低、更稳健。”
这种思维方式直接适用于当前的AI代理实施。Wallkötter最近遇到了一个例子：一个复杂的AI编码系统，其中包含一个专门设计用于识别代码库中不可靠测试的代理。
他回忆道：“我问，你为什么要有一个代理和一个AI系统，使用LLM来找出测试是否不可靠呢？”“你不能只是把测试运行10次，看看它是否同时失败和成功吗？因为这就是不可靠测试的定义，对吧？”
这种模式在整个行业中重复出现。团队将AI应用于具有更简单、更可靠、更便宜解决方案的问题。对尖端技术的诱惑可能会掩盖直接的替代方案。基于LLM的解决方案可能需要大量的计算资源，并且仍然偶尔会失败，而确定性方法可以即时可靠地解决问题。
这一观察结果从单个技术决策延伸到更广泛的战略问题。MCP的灵活性使得向现有工作流程添加AI功能变得很容易。这种易于集成的特性可能导致反射性的AI采用，而没有仔细考虑AI是否为特定任务提供了真正的价值。
Wallkötter问道：“这真的是前进的道路，还是仅仅因为AI很酷，所以我们把它扔到所有事情上？”这个问题在投入资源用于AI驱动的解决方案之前，值得认真考虑。
# 就业市场的悖论
这次谈话揭示了AI对就业影响的一个意外视角。Wallkötter最初相信AI将增强而非取代工人，遵循以往技术颠覆的历史模式。最近的观察使这一观点复杂化了。
“我想我在这方面其实完全错了，”他承认，反思他早期的预测。当AI首次引起主流关注时，行业中出现了一个常见的论调：“你不会被AI取代，但你会被一个使用AI的人取代。” Wallkötter最初接受了这种观点，将其与历史技术采用周期进行类比。
他指出：“打字机出现时，人们批评使用钢笔和墨水书写的人批评说，‘你正在扼杀写作精神，这已经死了，没有人会使用打字机。这只是一台没有灵魂的机器。’‘快进几十年。每个人都在使用计算机。’”
这种最初抵制随后普遍采用的模式似乎也适用于AI。关键的区别在于被自动化的工作类型，以及该工作是否存在于一个固定还是可扩展的池中。软件工程说明了可扩展类别。“如果以前你从工单系统中收到一个工单，你会编写解决方案，发送合并请求，然后你会得到下一个工单并重复这个循环。现在这个部分可以更快地完成，所以你可以处理更多的工单，”Wallkötter解释道。
在维护工作上节省下来的时间并不会消除对工程师的需求。相反，它改变了他们分配时间的方式。“你节省下来的所有时间，因为你现在可以花更少的时间进行维护，你现在可以花在创新上，”他观察到。“所以发生的情况是，你花费在创新上的时间、花费在维护上的时间发生了转变，而创新的池子随之增长。”
客户支持则呈现出完全不同的图景。“客户案例的到来是有限的，而且大多数公司至少不会在他们为客户支持所做的事情上进行创新，”Wallkötter解释说。“他们希望问题得到解决，他们希望客户能够自己找到问题的答案，他们希望与公司交流的体验良好。但这基本上就是终点了。”
这种区别是显而易见的。在客户支持中，工作量由传入的请求决定，而不是团队能力决定的。当AI能够有效地处理这些请求时，计算就很简单了。“以前有四个人做的工作，现在只需要一个人就可以完成。”
这种在可扩展和固定工作量之间的划分可能会决定哪些职位面临淘汰，哪些职位面临转型。这种模式超越了这两个例子。任何效率提升都能带来额外有价值工作机会的角色，似乎更具弹性。任何工作量受到外部限制且不以创新为优先角色的职位，面临的风险更大。
Wallkötter修正后的观点承认了一个比简单的增强或替代叙述更复杂的现实。问题不在于AI是取代工作还是增强工作，而在于一个角色的哪些特定特征决定了其发展轨迹。答案需要审查工作本身的性质、工作量的限制，以及效率的提高是否转化为扩展的机会或减少的人员需求。
# 前进的道路
MCP的快速采用证明了AI行业对标准化和互操作性的渴望。该协议解决了一个真正的问题，并且它以足够的简洁性实现了这一点，鼓励了广泛的实施。然而，这种采用带来的挑战凸显了该领域在关键领域的不成熟。
围绕身份验证和提示注入的安全问题需要根本性的解决方案，而不是增量修补。行业需要开发能够处理AI代理交互独特的三方动态的稳健框架。在这些框架存在之前，企业部署将伴随重大的风险。
工具超载问题和何时使用AI的基本问题都指向了系统设计需要更大的约束力。轻松添加工具的能力不应转化为随意添加工具。组织应在致力于复杂的代理架构之前，评估AI是否能提供比简单替代方案有意义的优势。
Wallkötter的观点，受到了学术机器人学和商业AI开发经验的影响，强调了寻找“稳定用例”的重要性，而不是为了技术能力本身而追逐技术能力。人形机器人的不稳定平衡提供了一个警示故事：如果没有证明其复杂性和成本合理性的实际应用，令人印象深刻的能力也意义不大。
随着MCP的不断发展，Anthropic和更广泛的社区正在解决安全、可扩展性和可用性问题，该协议可能会继续成为AI工具的核心。它在解决这些挑战方面的成功或失败，将极大地影响AI代理从实验性部署转变为可靠的业务基础设施的速度。
这次对话最终回到了一个简单而深刻的问题：仅仅因为我们能用AI构建某物，我们就应该这样做吗？答案需要诚实地评估替代方案，仔细考虑成本和收益，并抵制将时髦技术应用于每个问题的诱惑。MCP为将AI连接到世界提供了强大的能力。明智地使用这些能力，需要与创建该协议本身所采用的深思熟虑的工程方法一样认真。
Rachel Kuznetsov拥有商业分析硕士学位，热衷于解决复杂的数据难题并寻找新的挑战。她致力于使复杂的科学概念更容易理解，并正在探索AI影响我们生活的各种方式。在她不断学习和成长的征程中，她记录下自己的旅程，以便他人可以与她一起学习。您可以在LinkedIn上找到她。
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区