有了MCP，还需要深入研究Agent吗？

推荐语

探索MCP协议与Agent技术之间的差异与联系。

核心内容：
1. MCP协议的工作原理及其局限性
2. Agent技术在理解用户意图和任务规划方面的优势
3. 未来可能的协议架构与Agent技术的应用前景

杨芳贤

53A创始人/腾讯云(TVP)最具价值专家

作为连接大模型和工具的通用协议，MCP让用户可以有机会将自己正在使用的大模型，与全世界优秀的软件连接，从而，可以在类似ChatGPT之类的聊天类应用中，完成智能的任务处理（期间调用工具来实现特定目的）。

当我们在聊天界面中，连接了工具体系时，可能会有一个疑问：这几乎和我们接触的智能体并无二致，我们还有必要深入研究Agent技术吗？

今天，我想聊一聊这个问题，并结合自己的实际落地场景，来聊一聊未来可能的一种协议架构。

MCP未解决之点

通过我前面的文章，我们可以大致理解MCP的工作原理，基于此，我们知道，MCP解决的是和Function Calling类似的问题，即让大模型在与用户对话过程中，可以返回用来调用工具的元数据，从而可以在chat应用层面去调用工具。然而，这个call的过程，实际上只解决了大模型调用工具的问题。MCP并没有颠覆已有的程序交互模式，只是将原来的事实方案，进行了标准化设计，以让任何大模型应用都可以按照这个标准进行工具调用。但是，与Agent相比，MCP还有多个没有考虑和解决的问题。

理解用户的真实意图

虽然随着时间的推移，大模型的智能程度越来越高。但是由于全球数据枯竭，这种智能提升的速度越来越慢。而即使智能程度越来越高，也无法理想化的理解用户输入的真实意图。原因包括但不限于如下：

• 人类语言的随机性，同一句话在不同背景下意图不同
• 大模型的幻觉，会自动联想用户意图，而这部分可能与用户的真实意图有偏差
• 用户真实意图无法完全用语言表达
• 用户表达错误

而Agent是怎么解决的呢？主要涉及到如下内容：

• 记忆，Agent和单一用户之间形成了长期记忆，从而能够判断用户当下需求背景，提升理解意图能力
• 多轮交流，Agent会与用户多轮交流，让用户补充需求细节
• 验证，部分Agent会提供类似“测试用例”的方案，通过用例来对其用户需求
• 动态调整，Agent在执行任务过程中，用户可根据阶段结果进行调整，避免过度跑偏的情况

可见，Agent作为上层应用，并不完全依赖大模型来解决问题，而是通过巧妙的架构设计来让程序更能准确执行用户目标。

规划更为合理的任务

虽然类似deepseek之类的大模型，在规划的表现上非常不错，但是存在的问题是，大模型只能一次性的生成任务列表，而想要完全符合用户目标，则需要人的参与，并且需要再次重新全部生成。更多内容关注我的公众号 wwwtangshuangnet 了解。而且，作为对话，大模型chat应用无法直接进行反馈修改。而Agent则可以从应用层面，采取一定的策略来规划任务，比如通过与用户的互动来确定最终任务列表和阶段，比如根据系统设定，让特定类型的任务有固定的规划框架等等。

阶段化螺旋式任务执行

对于大模型而言，调用工具是一次性的，工具的选择是否正确，结果是否符合预期，都需要用户来决策。大模型应用往往只能一次执行一个任务，即根据上一次的结果选择工具执行，并拿到结果后返回给用户。

而Agent在执行任务时，则更可控。它可以阶段化执行任务，通过任务规划列表，一步一步的执行，而在执行过程中，可与用户交互，也可在多智能体框架下并行或窜行任务，并反复确认和验证。甚至，它内部可以对任务阶段结果不满意时，动态调整整个需求，以螺旋式的演进方式，一点点的向目标推进。

以GenSpark编程目标为例，我们在GenSpark中发起一个编程任务时，它会经历从需求理解到架构设计，再到原型稿，开发MVP，再到写代码，做测试。这些阶段化的步骤，让Agent在执行过程中，并不急于立即得到结果，而是在每一步都力求把步骤目标实现好。

自动执行

Agent的另外一大特色是自动执行，即在一定条件下，完全无需人工干预，由它自己完成决策和执行。这种自动执行有别于传统的RPA软件，RPA是人设定了自动执行的路径，软件按照这个固定路径自动执行。更多内容关注我的公众号 wwwtangshuangnet 了解。而Agent的自动执行则不需要人去设定执行路径，而是由Agent在过程中动态地自主判断和决策执行。这对人们工作来说极为重要，对于人来说，只需要提出需求，获得结果（当然，这个结果也可以在不符合预期的时候舍弃），而无需在过程中参与，这对节省时间和成本提升效率极为重要。

MCP和Agent的关系

MCP可以帮助Agent在调用工具层面进行提升，一方面，MCP社区会出现非常多的MCPServer可以作为备用工具，另一方面，Agent可以使用智能度更高的大模型来作为工具调度的“大脑”，从而让工具调用更准确。

但是，MCP不是专为Agent设计的，我们在开发Agent时，接入MCP还需要做基础建设开发。

Agent是一个系统，包含调度系统、执行系统、感知系统。而MCP只是执行系统中的一个小点。另外，目前市场上对感知系统的讨论还不多，我个人理解，感知系统也依赖工具，例如依赖摄像头、传感器等，但是和调用工具来执行得到结果不同，感知系统可能更多的是对远端Server进行订阅，获得来自远端Server的消息通知。不过，从安全性的角度，这种依赖远端的方案，会在远端不工作时，造成本地系统的破坏。因此，这可能是一个深度更深的话题，也是没有成为行业主流讨论的原因。

Agent之间的交互协议

一种新的协议架构，在此之前，市面上还正式未提出过不同厂商的Agent之间的交互协议，而昨日google发布会公布了他们的A2A协议方案。该方案旨在解决Agent之间的交互标准化问题。不过从google的调性，我不认为他们能将该标准推向通用化。

不过，A2A协议标准必然会出现。我在之前的文章中曾提到过，用户将来可能只会有一个Agent为自己服务，而单一Agent往往无法解决所有问题，此时，自然而然能想到的方案就是，调用其他Agent来解决特定问题，但是又不想再去购买新的Agent，所以接入其他Agent来实现特定目的，而完成特定任务之后，立即将其释放或断开，既环保又便捷。

目前，MCP市场火热，这让我们调用工具来得到特定结果的场景变得越来越简单。但是，这里也会有一个问题。在整个过程中，人仍然起着主导作用。而Agent则更多的将决策交给机器，人只是需求方，Agent是交付方。当Agent网络越来越成熟时，甚至可以脱离人的控制，形成自决策自执行的网络体系。即我们在有些科幻文中所描述的，多个Agent形成了一个社会网络，各自扮演不同角色，相互交流和数据互通，无需人类干涉。

结语

本文简单讨论了MCP和Agent之间的区别和联系，让读者可以通过简单的语言了解从MCP到Agent之间，还需要具备哪些知识和技术。2025年，作为Agent的爆发之年，我已经看到市面上很多Agent的开发商已经在盈利，但同时，Agent的执行结果距离人们理想化的结果还有一定距离。随着对执行结果要求的越来越高，未来，开发商们肯定会不断的优化Agent，使之在结果和预期之间，找到更优的解决道路。

关注我，回复“AI”有惊喜