来源：腾讯技术工程、infoQ、原力注入

自 OpenAI 于 2023 年发布函数调用功能以来，我一直在思考如何构建一个开放的智能体与工具使用生态系统。随着基础模型愈发智能化，智能体与外部工具、数据和 API 的交互能力却日益碎片化：开发者需要为智能体运行的每个系统和集成对象，实现具有特殊业务逻辑的智能体程序。

通信协议是AI Agent加速落地的核心基础设施之一。Anthropic推出的MCP已逐步确立其作为AI Agent连接外部工具的标准协议地位，而Google最新发布的A2A则聚焦于打破智能体协作壁垒，推动跨Agent协同体系的构建。作为AI Agent时代最受关注的两大通信规范，它们的安全性直接关乎AI Agent的安全边界，任何安全问题都可能引发AI Agent被劫持与数据泄露等连锁风险。

什么是 MCP？

MCP 是一种开放协议，使系统能够以跨集成通用化的方式为 AI 模型提供上下文。 该协议定义了 AI 模型如何调用外部工具、获取数据以及与服务交互。具体示例如下，展示了 Resend MCP 服务器如何与多个 MCP 客户端协同工作。

Example MCP Workflow

这个理念并不新鲜；MCP从 LSP（语言服务器协议）中汲取了灵感 。在 LSP 中，当用户在编辑器中输入时，客户端会查询语言服务器以获取自动补全建议或诊断信息。

MCP 的突破性在于其以代理为中心的执行模型：LSP 主要是反应式的（基于用户输入响应 IDE 的请求），而 MCP 旨在支持自主 AI 工作流。基于上下文，AI 代理可以自主决定使用哪些工具、使用顺序以及如何串联工具链来完成任务。 MCP 还引入了人机协同能力，允许人类提供额外数据并批准执行流程。

而在2025年4月9日，谷歌云正式发布了Agent2Agent（A2A）协议，这是首个专为AI代理互操作性设计的开放标准。按Google的说法，A2A协议与MCP是互补而不替代关系，A2A负责解决Agent间的通信问题，MCP解决的是Agent与工具间的通信问题。

2.2 MCP的安全缺陷

由于设计之初MCP协议主要是用于AI Agent调用本地工具或调用权威厂商提供的MCP服务，同时也没有过多考虑安全相关风险，2024年11月发布的初代MCP协议及主流MCP服务实现上仍然存在以下安全缺陷：

1.信息不对称
AI模型能够看到工具描述的全部内容，包括隐藏在注释或特定标签中的细节，而在用户看到的AI Agent的前端界面出于简洁考虑往往只显示工具的基本功能描述，忽略了那些可能包含恶意指令的内容。

2.缺乏上下文隔离

当AI Agent连接多个MCP服务器时，所有可用工具的描述信息都会被加载到当前的会话上下文中。这意味着来自恶意MCP服务器的工具描述可以影响来自可信MCP服务的工具行为。

3.大模型安全防护不足

当前的大模型被训练为尽可能精确地理解并遵循给定的指令，包括MCP提供的工具描述。然而，模型往往缺乏针对恶意指令的批判性思维能力，特别是当这些指令被巧妙地伪装成工具的"必要前置条件"或"实现细节"时，同时即使开发者在prompt中加入了安全防护相关指令，攻击者也可以通过各类层不出穷的越狱攻击手法绕过。

4.版本控制与更新机制不足

MCP协议缺乏严格的版本控制和更新机制，使得所谓的"地毯式骗局"（Rug Pulls）成为可能。恶意的MCP服务可以在用户初次安装并启用后，在远程服务器上静默修改工具描述加入恶意指令，且MCP客户端无法及时感知并要求用户二次确认。

5.安全隔离与检测机制不足

MCP官方文档没有明确建议用户在Docker或沙箱环境中安装MCP服务，同时第三方MCP市场也没有对MCP代码安全性进行检查，用户非常容易安装带有后门或漏洞的MCP服务。

6.授权认证机制不完善

对于一些有敏感数据读取（如查DB、读文件）、敏感功能操作（如执行系统命令）功能的接口，MCP并没有在官方文档中明确强制要求开发者进行授权认证，这样可能导致部分暴露在公网上的MCP服务被入侵或未授权使用。

2.3 Google A2A协议安全性分析

不同于MCP的使用场景（大部分是由Agent开发者自己本地部署或使用市场上开源的MCP服务，其代码和实现是相对透明的），Google A2A要解决的是不同黑盒中Agent间的安全通信与信任问题，Google宣称其在安全性设计层面采取默认安全设计：

企业级认证和授权	支持OAuth授权，确保只有授权代理可以访问和交互。
OpenAPI兼容	与OpenAPI方案保持一致兼容在header中使用Bearer Token认证
访问控制（RBAC）	确保代理只能执行其授权的操作，细化对Agent能力访问权限管理。
数据加密	支持加密数据交换，保护敏感信息在传输过程中的安全性。
授权方案持续优化	计划在AgentCard中增加更多授权机制，例如直接整合可选凭证进一步提升安全性。

其中的关键实现是AgentCard，这个是一个公开的元数据文件，描述了AI代理的功能、技能、端点URL和身份验证要求，可以通过URL路径 http://{remote_agent_address}/.well-known/agent.json 访问。AgentCard允许代理在不了解彼此的情况下，通过读取对方的AgentCard来识别对方的能力和访问权限，从而实现安全的协作。

 

当前热门的应用场景

借助适当的 MCP 服务器组合，用户可将每个 MCP 客户端转变为"万能应用"。通过Slack MCP 服务器 实现 Slack 通讯功能，利用Resend MCP 服务器 完成邮件发送，或通过Replicate MCP 服务器 进行图像生成。

以代码编辑器光标为例：虽然其本质是代码编辑工具，但作为优质 MCP 客户端，终端用户既可通过Slack MCP 服务器 将其改造为 Slack 客户端，也能利用Resend MCP 服务器 实现邮件发送功能，或通过Replicate MCP 服务器 进行图像生成。更强大的应用方式是在单个客户端集成多个服务器以解锁新流程：用户可安装前端 

UI 生成服务器 从光标直接生成界面原型，同时调用图像生成 MCP 服务器为网站创建主视觉图。

除光标外，当前大多数用例可归纳为两类：要么是以开发者为中心、本地优先的工作流，要么是使用大语言模型客户端构建的全新体验。

不同的场景导致了两种 Agent 模式在技术上的不同选择

两种 Agent 模式的实现存在差异，原因多种多样：

• 通用 Agent 需要具备独立的云端运行环境，而本地 Agent 则部署于本地 IDE 中，因此它们所采用的工具不尽相同。

• 本地 Agent 由于需与人类操作同步，故重视执行效率，力求迅速向用户提供反馈，并尽快完成交付。

• 相比之下，通用 Agent 可以支持异步交付，对延迟的要求不那么严格，其流程可被分解得更为细致，能够调用更多工具进行多次验证以获取中间结论。同时，鉴于它是异步交付，必须确保一定水平的交付质量，因而需要尽量考虑周全后再执行。

• 本地 Agent 的产品与 IDE 紧密结合，这意味着其任务不会无限制地扩展，相对而言较为简化。

• 通用 Agent 使用的工具种类不受限，而本地 IDE 中的 Agent 由于受限于 PC 设备，任意安装新工具可能会引发用户关于隐私或安全性的担忧。

• 作为异步模式的一部分，通用 Agent 必须达到一定程度的确定性，在执行过程中不断自我反省和总结，这会带来执行效率的降低

但通用 Agent 会遇到一些挑战

通用 Agent 实施上会遇到的挑战

尽管我们现在可以看到市场上有很多标榜为通用 Agent 的产品，但实际上能够处理通用或复杂任务的并不多。这些产品要么不够通用，要么无法应对复杂的任务。我认为这主要是由于工程和技术模型两个方面所面临的挑战。

通用 Agent 在工程上的挑战

  第一Agent 的大脑如何构建

其实当初我们看到 Devin 时，我们首先想到的是 Web IDE 的架构。我们认为，在浏览器中开启的任务应当由后台的一个独立容器来处理。这一想法立即让我联想到了 Web IDE 的架构。

具体任务在一个环境中执行。在这个环境中，有一个“大脑”负责知识的引入、工具的使用、知识的压缩以及模型的驱动。“大脑”的重要性体现在以下几个方面：

• 它具备任务规划与执行能力，可以被视为通用 Agent 的 '大脑'，负责管理整个任务流程，将复杂的任务分解成可以由子 Agent 执行的小任务。

• 它能够进行反思和重新规划。有时，某种实现方案可能走入死胡同，或模型坚持一条走不通的道路，“大脑”需识别这些问题并重新规划其他路径。

• 它能够识别并选择使用各种工具，例如通过浏览器打开网页、操作终端、文件的创建、删除、编辑等，以及在线搜索等。

• 它具有识别、正确压缩记忆、引入新知识及学习的能力，如将先前成功完成的任务归纳为经验，在面对类似任务时再次应用这些经验。

• 内置 IDE 功能通常也是必要的，这使得用户可以在 Agent 中调整生成内容的信息，尽管这不是强制性的要求。

• 并行处理子任务，通用 Agent 可以同时运行多个子任务，从而加速任务的完成。

 第二 如何评估通用 Agent

通用 Agent 的性能受到 Engine、模型、各种 Prompt、工具筛选等方面的影响。在评估时，对于那些不确定性强的内容，我们需要进行模拟，并通过控制变量的方法找出关键的优化点。因此，建立一个能够发现实现使用环境中问题的环境变得很重要只有通过评测我们才能明确改进的方向。

过去，在大规模模型的训练和评估中，通常采用的是以 Query 和 Answer 为核心的评价方式。

这种评测集的特点通常是易于实施和评估的，比如 Pass @ 1 或者 EM、ES 等评估策略，通常是一组标准化的测试数据（输入 - 输出对），用于量化模型在特定任务上的表现。其目的在于提供统一的评估标准，以便横向比较不同模型的能力（如准确性、稳健性和泛化能力）。例如 GLUE（自然语言理解）、MMLU（多学科知识）、HumanEval（代码生成）等。有些评测集，如 SWE-Bench，则设置了若干实际世界中的编程问题供智能体解决。

然而，这类评测集仅能用于评估与编码相关的智能体能力，而无法全面反映通用型智能体的综合能力。因为在很多情况下，仅仅评估最终结果并不合理，因为智能体产生的输出往往不是标准化的，例如在一个需求调研任务中，我们难以通过产出直接判断智能体的质量，或这种评价本身就是主观的。此外，评测的另一目的还在于优化整体设计架构，单纯的结果评估很难揭示问题究竟出现在规划阶段、记忆阶段还是工具选择阶段。

当然，评估过程本身也充满挑战，因为智能体的执行过程是动态变化的，由模型驱动，每次生成的计划不尽相同，所用工具也可能有所差异，因此严格对比变得困难。即便我们尝试评估过程细节，比如具体进行了哪些规划步骤，使用了多少步骤，这些数据的具体意义仍不易解释清楚。因此，针对通用型智能体产品的评测是一项行业难题，或许需要引入人工评估的方式，甚至为展示其通用性，还需构建多种突发场景来考察其应对能力，这些都是需要考虑的因素。

 第三 如何解决处理长步骤下的记忆问题

人在面对复杂问题时，尽管也是逐步推进，但在每完成一步后，往往会无意识地对信息进行压缩处理。例如，在理解一段复杂的代码逻辑时，你不必记住读过的每一个字符；相反，你会大致掌握其内容，然后转向其他文件。这样，你就能够持续处理新任务。当后续任务需要之前的具体信息时，再回过头来查阅细节。这就是人类如何通过信息压缩与提取来管理信息的方式，这一能力同样适用于 Agent。

Agent 的记忆机制分为两类：短期记忆和长期记忆，它们分别应对不同的需求。

在处理复杂任务时，由于模型的上下文长度受限，即便未来模型的上下文容量得以扩展，仍需依赖信息压缩功能。过多的信息可能会导致关键点被忽略，因此短期记忆中的信息压缩有助于提炼出核心要点。Devin 产品的界面设计体现了这种压缩能力，即在每个步骤完成后展示压缩后的记忆摘要，而不是详尽记录每项操作，以便为后续步骤提供概要参考。

但是，单纯地通过压缩也有其局限性，因为模型压缩可能会忽视某些对复杂任务至关重要的细节信息，例如我们在测试的时候发现 Agent 生成一组用户名和密码，然后转头就忘了，这就考验了解决问题的工程技术能力。

如前所述，通用 Agent 应该拥有反思与学习总结的能力，这也是模型与 Agent 之间的区别之一。Agent 在学习过程中不断进步，并掌握处理新任务的方法，因此 Agent 或许具有规模效应——使用者越多，它就越智能。这种能力的具体表现就是“长期记忆”。每当用户完成一项任务后，我们可以让模型整理出一份可供日后参考的经验数据。这样，在 Agent 遇到新问题时，可以调取这些经验来指导模型如何应对，从而实现了某种形式的长期记忆。Devin 则是通过 Knowledge 的方式来进行存储，例如，在执行某项任务的过程中，通过对模型输出进行校正，生成了一份可利用的知识。

不过，这种处理方式仍然显得相当粗犷。主要是因为，一种知识在一个特定情境中可能非常有效，但在另一个情境下却未必如此。例如，牛顿力学在宏观和低速的世界里表现得极为出色，然而当速度接近光速时便不再适用；同样地，抗生素能够有效地杀死细菌，但对于病毒则无能为力。因此，将成功的经验固化为固定的“Agent 心智”，实际上也限制了模型的能力。如何根据具体的情境来甄别并利用这些经验，并且恰当地掌握这一平衡点，本身就是一项重大的技术挑战。

模型的挑战

工程上的挑战其实还是能够克服的，毕竟有大量可借鉴的产品，我们也可以通过各种方法和产品手段来避免一些问题。然而，对于“模型驱动”的 Agent 产品来说，模型能力方面的挑战更为艰巨。当前，几乎所有开发通用 Agent 产品的公司都将 Claude Sonnet 视为首选模型，因为除此之外，其他模型都无法很好地推动复杂任务的解决，模型能力的欠缺是我们比较担心。

模型的指令跟随能力不足

复杂的任务之所以复杂，在于判断与限制条件多，约束多，对模型的要求也随之增多，通常会组合成一个极其复杂的 Prompt，模型能遵循的指令越多，它能处理的问题就越复杂。然而，除 Claude 系列外，其他模型往往难以达到这一标准。

部分模型存在不遵循指令的情况，而且非常普遍，例如我明确告诉他不要转义

但代码还是转义了

  模型的长上下文能力

主要体现为当噪音信息变多时，找到关键信息、理解能力会变弱。

某模型放入过多额外信息时生成的流程图，可以看到许多中间步骤被模型忽略了。

某模型仅保留关键信息时生成的流程图，如果去除掉一些细节信息，模型就能找出更完整的链路。

复杂的任务之所以显得复杂，要么是因为其上下文本身就很长，例如 代码，或者在执行长步骤任务时，需要记忆更多上下文信息。对于复杂任务，特别是涉及几十甚至上百步的任务而言，把握住长上下文中关键的信息至关重要。

  模型的推理规划和反思能力

推理与规划能力是通用 Agent 解决复杂问题的关键。这种能力使得智能体能够分析问题、制定解决方案的步骤，并在执行过程中进行调整。Devin 在产品上会先为任务制定一个计划，然后向用户展示执行规划的步骤。

而在我们执行任务的过程中遇到变化时， Devin 会调整他的计划。这与人类相似，在完成一项复杂的任务时，人们通常也无法一开始就制定出一个完美的计划，而是会在实施过程中不断进行调整。

这个图反应了，Agent 存在的挑战不仅仅是一次性就把事情做好，而是在一个长链路任务下需要具备反思和的能力

• Agent 难以从错误的长轨迹中恢复（Difficult to recovery in long trajectory）

  • 在任务执行过程中，智能体可能选择了错误的动作序列，导致偏离正确轨迹

  • 智能体需要回顾并修正之前的错误动作，以完成任务

  • 图中左侧展示了智能体在错误轨迹中浪费时间（例如开错门、走错路径），最终未能获得奖励

• Agent 也容易陷入局部循环（Stuck into Loops）

  • 智能体可能在某些状态中反复执行相同的动作，陷入局部循环，无法探索新的可能性

  • 图中右侧展示了智能体重复执行“打开厨房门”的动作，未能有效推进任务

  • 智能体需要跳出局部循环，探索更多可能的动作以完成任务

推荐书籍：
《分布式商业生态战略：数字商业新逻辑与企业数字化转型新策略》

作者：思二勋

书籍介绍：
本书从新时代的新市场和新趋势出发，如：元宇宙、Web 3.0、资产数字化、反垄断、要素市场化配置、非同质化通证（non-fungible token，NFT）等，以企业数字化转型为核心，以区块链等数字化技术为基本点，以场景为基本面，勾勒了数字化时代分布式商业演化的新趋势，以及其对企业经营管理的影响，提出了数字化时代企业数字化转型的新策略和分布式经营管理的低成本、高效率发展方案。