发帖
雷达卡
一、MCP简介
标准的成败取决于采用率，而非技术优越性。模型上下文协议（Model Context Protocol，简称MCP）从一开始就明白这一点。该协议由Anthropic于2024年末发布，解决了一个简单直接的问题：人工智能（AI）模型应如何与外部工具交互。协议设计足够简洁，便于推广实施，其实用性也足够明确，能够推动需求产生。短短几个月内，MCP就触发了网络效应，将一个好想法转变为行业标准。然而，正如AI研究员兼数据工程师塞巴斯蒂安·瓦尔科特在近期对话中所解释的那样，这种快速采用也暴露出关于安全性、可扩展性以及AI智能体是否始终是正确解决方案的关键问题。
瓦尔科特在这些讨论中带来了独特的视角。他于2022年在乌普萨拉大学获得人机交互博士学位，研究方向是机器人与人类如何更自然地协作。此后，他转型进入商业AI领域，致力于大型语言模型（LLM）应用和智能体系统的研发。他的背景跨越了学术研究与实际应用，能够为AI系统的技术能力和现实约束提供宝贵见解。
二、MCP为何能赢得标准之争
模型上下文协议（MCP）解决了一个看似简单的问题：如何创建一种可复用的方式，让AI模型访问工具和服务。在MCP出现之前，每一家LLM提供商和每一位工具开发者都必须构建自定义集成方案，而MCP提供了一种通用语言。
“MCP的核心聚焦于工具调用，”瓦尔科特解释道，“你有一个智能体、LLM或其他类似工具，它需要与谷歌文档、日历应用、GitHub等服务进行交互。”
该协议的成功，与其他平台标准化的案例如出一辙。就像Facebook在吸引足够多用户、让网络产生价值后达到临界规模一样，MCP也迎来了一个转折点：提供商因用户需求而选择支持它，用户因提供商的支持而选择使用它。这种网络效应推动了MCP在全球范围内的采用，在美国和欧洲的实施中并未表现出明显的区域偏好。
其采用速度令许多人感到意外。在2024年10月发布后的几个月内，各大平台就纷纷集成了MCP支持。瓦尔科特推测，最初的动力来自开发者对其实用价值的认可：“我猜可能是某个工程师说‘嘿，这个格式很实用，我们就用它吧’。”他进一步解释了这种动态：“一旦MCP发展到足够大的规模，所有提供商都会支持它。所以，为什么不搭建一个MCP服务器来兼容所有模型呢？反过来也是一样，既然大家都有MCP服务器，为什么不支持它？因为这样就能获得极高的兼容性。”该协议从一个有趣的技术规范，以超出大多数观察者预期的速度成为了行业标准。
三、安全盲点
然而，快速采用也暴露了原始规范中的重大漏洞。瓦尔科特指出，开发者很快发现了一个关键漏洞：“MCP的第一个版本完全没有任何认证机制。所以，世界上任何人都可以访问任何MCP服务器，调用其功能、执行操作，这显然可能会产生严重后果。”
这种认证挑战，比传统的网络安全模型更为复杂。MCP涉及三方主体：用户、LLM提供商（如Anthropic或OpenAI）以及服务提供商（如GitHub或谷歌云盘）。传统的网络认证能够很好地处理双方交互——用户向服务进行认证，这种关系简单直接。而MCP则需要同时考虑这三方。
“有MCP服务器、LLM提供商，还有用户本身，”瓦尔科特解释道，“你需要对哪一部分进行哪一种认证？是要认证Anthropic是否有权与GitHub通信吗？但实际操作的是用户，对吧？所以，本质上是用户在进行认证。”
对于自主智能体而言，情况变得更加复杂。当用户指示一个旅行规划智能体预订假期，而该智能体在没有用户直接监督的情况下开始调用各种MCP服务器时，谁应对这些行为负责？是构建智能体的公司？还是发起请求的用户？这个问题涉及技术、法律和伦理多个层面，行业目前仍在努力解决。
四、提示词注入问题
除了认证问题，MCP的实施还面临另一个尚无明确解决方案的安全挑战：提示词注入。这种漏洞允许恶意攻击者通过精心设计输入，覆盖系统的预设指令，从而劫持AI的行为。
瓦尔科特将其与一个早期的网络安全问题进行了类比。“这让我有点想起早期的SQL注入问题，”他指出。在早期网络时代，开发者会将用户输入直接拼接到达数据库查询语句中，这使得攻击者能够插入恶意SQL命令。解决方案是将查询结构与数据分离，使用参数化查询，将用户输入视为纯数据而非可执行代码。
“我推测，解决提示词注入的方法将与我们解决SQL数据库注入的方法非常相似，”瓦尔科特表示，“你先发送提示词本身，然后将所有要插入到提示词不同部分的数据单独发送，之后会有一个系统在LLM处理之前对这些数据进行检查，判断是否存在提示词注入。”
尽管这种潜在方法存在，但目前尚无广泛采用的解决方案。LLM提供商试图训练模型，让其优先执行系统指令而非用户输入，但这些防护措施仍然不完善。“总有办法绕过这些防护，因为没有绝对万无一失的方法，”瓦尔科特承认。
提示词注入问题不仅关乎安全，还影响可靠性。当MCP服务器返回的数据被嵌入到LLM的上下文时，这些数据可能包含覆盖预设行为的指令。一个遵循精心设计流程的AI智能体，可能会因为响应中的意外内容而偏离轨道。在这个漏洞得到解决之前，没有人类监督的自主智能体本身就存在固有风险。
五、工具过载陷阱
MCP的易用性带来了一个意想不到的问题。由于添加新工具非常简单，开发者往往会在应用中积累数十个MCP服务器，而这种数量过多的情况会显著降低性能。
“我见过几个例子，人们对MCP服务器非常热衷，最终却配置了30、40个包含各种功能的服务器，”瓦尔科特观察到，“突然之间，你的上下文窗口从一开始就被工具定义占用了40%到50%。”
每个工具都需要一段描述，向LLM说明其用途和参数。这些描述会消耗上下文窗口中的令牌——模型用于存储所有相关信息的有限空间。当工具定义占据了一半的可用上下文时，模型用于存储实际对话历史、检索到的文档或其他关键信息的空间就会减少，性能下降也就在所难免。
除了上下文窗口的限制，过多的工具还会让模型本身感到困惑。当前一代LLM在面对大量选项时，很难区分功能相似的工具。“目前互联网上的普遍共识是，实际上30个左右似乎是一个临界值，”瓦尔科特指出，超过这个数量，模型性能会明显下降。
这种限制对架构设计产生了影响：开发者应该构建一个具备多种能力的大型智能体，还是多个具备专注工具集的小型智能体？答案部分取决于上下文需求。瓦尔科特提供了一个易于理解的衡量标准：“如今，大多数性能良好的智能体，其上下文窗口大约有20万个令牌，这大致相当于一整本书《傲慢与偏见》的字数。”
这个“简·奥斯汀衡量标准”提供了直观的规模概念。如果一个智能体需要大量的业务上下文、格式指南、项目历史和其他背景信息，这些积累的知识会迅速占据可用空间的很大一部分。在这样的上下文基础上再添加30个工具，可能会让系统超出有效运行的范围。
解决方案通常涉及战略性的智能体架构设计。组织不必部署一个通用智能体，而是可以为不同的用例部署专门的智能体：一个用于旅行规划，一个用于邮件管理，第三个用于日程协调。每个智能体都保持专注的工具集和特定指令，避免了功能过于繁杂的通用智能体所带来的复杂性和混乱。
六、何时不应使用AI
瓦尔科特的机器人学背景，为评估AI实施提供了一个意想不到的视角。他在人形机器人方面的博士研究揭示了一个长期存在的挑战：寻找稳定的用例，在这些用例中，人形形态比更简单的替代方案具有真正的优势。
“人形机器人的问题有点像不稳定平衡，”他借用物理学概念解释道。一个完美直立平衡的钟摆，理论上可以无限期保持站立，但任何微小的扰动都会导致它倒下。“如果你稍微扰动它，只要没有达到完美平衡，它就会立即倒下来。”人形机器人也面临类似的挑战：虽然它们令人着迷，并且能够完成令人印象深刻的演示，但当存在更简单的解决方案时，它们的复杂性就难以合理化。
“当你真正开始思考我们能用它做什么时，你会立即面临一个经济问题：你真的需要一开始就采用人形机器人的这种配置吗？”瓦尔科特问道，“你可以去掉它的腿，换成轮子。轮子更稳定、更简单、制造成本更低、也更耐用。”
这种思路直接适用于当前的AI智能体实施。瓦尔科特最近就遇到了一个例子：一个复杂的AI编码系统，其中包含一个专门设计用于识别代码库中不可靠测试的智能体。
“我问他们，为什么要用一个带有LLM的智能体和AI系统来判断一个测试是否不可靠？”他回忆道，“你不能只是运行这个测试10次，看看它是否会同时出现失败和通过的情况吗？因为这就是不可靠测试的定义，对吧？”
这种模式在行业中反复出现：团队将AI应用于那些有更简单、更可靠、更廉价解决方案的问题上。使用尖端技术的吸引力，可能会掩盖那些简单直接的替代方案。一个基于LLM的解决方案可能需要消耗大量的计算资源，并且仍然偶尔会失败，而一个确定性方法却能立即、可靠地解决问题。
这一观察不仅适用于单个技术决策，还延伸到更广泛的战略问题。MCP的灵活性使得向现有工作流程中添加AI功能变得容易，而这种易于集成的特性可能导致人们在没有仔细考虑AI是否能为特定任务提供真正价值的情况下，就下意识地采用AI。
“这真的是正确的方向吗？还是说，只是因为AI很酷，我们就把它用在所有事情上？”瓦尔科特问道。在投入资源开发AI驱动的解决方案之前，这个问题值得认真思考。
七、就业市场悖论
对话中，关于AI对就业的影响，瓦尔科特提出了一个意想不到的观点。他最初认为，AI会像以往技术变革的历史模式一样，增强工人的能力，而不是取代他们。但最近的观察让这种观点变得复杂起来。
“我觉得我之前在这一点上完全错了，”他在反思自己早期的预测时承认。当AI首次获得主流关注时，行业中流传着一种常见的说法：“你不会被AI取代，你会被使用AI的人取代。”瓦尔科特最初认同这种观点，并将其与历史上的技术采用周期进行了类比。
“当打字机出现时，那些受过笔墨书写训练的人批评说，打字机扼杀了写作的精神，它是冰冷的，没有人会使用它，它只是一台没有灵魂的机器，”他指出，“但几十年后再看，每个人都在使用电脑。”
这种先有阻力、后被普遍采用的模式，似乎也适用于AI。关键的区别在于被自动化的工作类型，以及这种工作属于固定工作量还是可扩展工作量。软件工程就是可扩展类别的一个例子。“以前，你从工单系统收到一个工单，编写解决方案，提交合并请求，然后接收下一个工单，重复这个循环。现在，这部分工作可以做得更快，所以你可以处理更多工单，”瓦尔科特解释道。
在维护工作上节省的时间，并没有消除对工程师的需求，反而改变了他们的时间分配方式。“由于现在可以花更少的时间在维护上，你可以把更多时间用于创新，”他观察到，“所以，实际发生的是，你在创新和维护上花费的时间比例发生了转变，创新的空间也随之扩大。”
客户支持则呈现出完全不同的情况。“客户案例的数量是有限的，而且大多数公司至少不会在客户支持方面进行创新，”瓦尔科特解释道，“他们希望问题得到解决，希望客户能找到自己问题的答案，希望客户与公司沟通时有良好的体验。但也就仅此而已。”
这种区别非常明显。在客户支持领域，工作量由 incoming 请求决定，而不是由团队能力决定。当AI能够有效处理这些请求时，结论就很简单了：“以前需要四个人完成的工作，现在只需要一个人。”
这种可扩展工作量与固定工作量之间的划分，可能决定了哪些岗位会面临被取代的风险，哪些岗位会发生转型。这种模式不仅限于这两个例子：任何效率提升能创造更多有价值工作机会的岗位，都更具韧性；任何工作量受外部约束且创新不是优先事项的岗位，都面临更大的风险。
瓦尔科特修正后的观点，承认了一个比简单的“增强”或“取代”更复杂的现实。问题不在于AI是取代工作还是增强工作，而在于一个岗位的哪些具体特征决定了它的发展轨迹。要找到答案，需要审视工作本身的性质、工作量的约束条件，以及效率提升是否会转化为更多的机会，还是减少的人力需求。
八、前进之路
MCP的快速采用，表明AI行业对标准化和互操作性的迫切需求。该协议解决了一个实际问题，并且设计足够简洁，能够鼓励广泛实施。然而，这种采用所带来的挑战，也凸显了该领域在关键领域的不成熟。
围绕认证和提示词注入的安全问题，需要的是根本性解决方案，而非渐进式补丁。行业需要开发强大的框架，能够处理AI智能体交互中独特的三方动态。在这些框架出现之前，企业部署AI将面临重大风险。
工具过载问题以及“何时使用AI”的核心问题，都表明系统设计需要更严谨的态度。轻松添加工具的能力，不应转化为随意添加工具的行为。组织在投入复杂的智能体架构之前，应评估AI相比更简单的替代方案是否具有显著优势。
瓦尔科特的观点，得益于他在学术机器人学和商业AI开发方面的经验，他强调了寻找“稳定用例”的重要性，而不是为了技术能力而追求技术能力。人形机器人的不稳定平衡提供了一个警示：如果没有能证明其复杂性和成本合理性的实际应用，令人印象深刻的能力也毫无意义。
随着MCP的不断发展，Anthropic和更广泛的社区正在解决安全性、可扩展性和可用性方面的问题，该协议可能仍将是AI工具领域的核心。它在解决这些挑战方面的成败，将极大地影响AI智能体从实验性部署向可靠业务基础设施转变的速度。
这场对话最终回归到一个简单但深刻的问题：仅仅因为我们能用AI构建某样东西，就意味着我们应该去做吗？答案需要对替代方案进行诚实评估，仔细考虑成本和收益，并且抵制将热门技术应用于所有问题的诱惑。MCP为AI与世界的连接提供了强大的能力，而明智地使用这些能力，需要与创建该协议本身相同的深思熟虑的工程思维。
推荐学习书籍 《CDA一级教材》适合CDA一级考生备考，也适合业务及数据分析岗位的从业者提升自我。完整电子版已上线CDA网校，累计已有10万+在读~ !
京公网安备 11010802022788号
