仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
作者|李冬梅
采访嘉宾｜郭伟、汪晟杰
6月24日，谷歌云官宣将A2A（Agent-to-Agent）协议捐赠给了Linux基金会，消息一出引发了AI行业地震。这份包含智能体交互协议、SDK和开发者工具的开源礼包，背后站着亚马逊、微软、思科等科技巨头组成的“全明星”阵容。
GoogleCloud副总裁兼商业应用平台总经理RaoSurapaneni表示：“通过与Linux基金会和领先的技术提供商合作，我们将在值得信赖的开放治理框架下，实现更具创新性和价值的AI功能。”
在外界看来，谷歌云捐赠开源A2A的决策有点耐人寻味。在Reddit平台，有评论认为谷歌这么做是对AnthropicMCP协议、OpenAI函数等竞品的战略应对，但同时也揭示了行业共识：智能体经济需要共建底层规则。
也有用户认为，MCP已经起飞了，A2A才开始追赶。
甚至有人厌倦了谷歌，认为A2A不会成功。
在A2A协议引发热议的同时，MCP已经在企业级市场悄然生根。与A2A侧重智能体间通信不同，MCP解决的是更基础的问题：如何让AI模型安全高效地调用现实世界中的工具和服务。就像人类需要螺丝刀才能拧螺丝，AI智能体需要MCP才能操作企业API、数据库等数字工具。
那么，开发一款MCPServer关键环节有哪些？在接入企业内部系统时MCPServer需要做哪些适配工作？MCP协议与A2A协议的区别是什么，未来发展方向在哪里？
为了解答上述问题，我们采访了腾讯云资深产品技术专家汪晟杰和腾讯云资深后端技术专家郭伟，听他们深入剖析MCP技术的核心逻辑与未来趋势。
MCPServer开发，
最关键环节在于工具描述
InfoQ：在将业务能力通过MCP服务对外提供时，我们观察到存在两种典型场景：一种是基于现有API系统的改造，另一种是从零开始的构建。能否请您具体说明这两种不同场景下的实施路径？特别是，对于已经拥有成熟API体系的企业和需要从头开发的创业者，他们在实现MCP服务时各自需要关注哪些核心环节？整个流程中的关键差异点在哪里？
郭伟：我们可以从两个场景来分析。对于企业内部，尤其是从事SaaS业务的企业来说，它们本身已经拥有众多API。在这种情况下，关键在于如何将现有的API转换为MCP服务，并对外提供服务，尤其是向外部的Agent提供服务。这种转换的核心在于将API的协议出口转换为MCP协议。
在这一过程中，最为关键的是对MCP中包含的各种工具进行详细描述。这包括工具的功能、参数的作用以及输入输出的具体内容。只有这样，代理或关联的大模型在获取到MCP服务后，才能清楚地知道何时以及如何使用该服务。
简而言之，核心要点在于：一是将现有的API转换为MCP协议；二是在转换过程中，详细描述工具的功能和使用方法。由于这只是一个接口转换的过程，因此耗时相对较短，一天内可以完成几个接口的转换。对于原本就提供SaaS服务API的企业来说，这是一个相对简单的过程。还有一种从零开始的情况。
例如，一些创业者可能有一些想法，希望通过MCP服务，尤其是结合大模型或代理的场景来实现。在这种情况下，逻辑与前面提到的类似，但创业者需要首先明确其核心业务逻辑，即他们希望通过MCP服务向外界提供什么样的服务。
一旦明确了业务逻辑，创业者就可以跳过API开发的步骤，直接将MCP工具暴露给外部使用。这种情况下，创业者需要从头开始构建业务逻辑，而没有现成的API可以利用。从耗时角度来看，业务逻辑的开发是最耗时的部分。
在MCP服务开发过程中，除了业务逻辑外，还需要花费更多时间撰写工具描述。这是因为一个好的描述能够让代理清楚地了解如何使用MCP服务。此外，创业者可能还需要针对不同的模型进行测试，例如DeepSeek或千问等，以找到最适合的描述方式，然后才能正式发布。
InfoQ：在为客户开发MCP服务器时，通常需要与客户现有的技术体系进行对接。这一过程中，我们会面临哪些难题需要攻克？比如，当我们的MCP服务器开发完成后，是否需要与客户内部的工具进行适配？
汪晟杰：如果客户内部已经有一套对服务或API的处理体系，那么最好的办法是尽量保持原状。我们只需将最外层的接口进行转换，将API对接到MCP，这应该是最合理的方式。尽量不要干预企业内部的治理生态，因为其内部的运维、安全以及一系列流程可能已经运行得相当成熟。核心问题在于我们自身企业对外的SaaS能力，如何让Agent更好地发现和使用这些能力，这主要取决于我们如何编写工具的描述。
在完成服务对接后，可能会出现运行效果不如预期的情况。这并非因为其他问题，而是更多地在于模型以及工具描述的准确性。以DeepSeek为例，在早期版本中，工具的发现和支撑需要我们公司提供的描述尽可能精确，包括输入输出和使用方式的描述。这是一个需要花费时间磨合的过程。
InfoQ：在将MCP接入服务器并与不同类型的AI模型进行集成时，是否曾遇到过兼容性问题，包括国内外的模型？
郭伟：在实际应用中，我们确实遇到了一些兼容性问题，尤其是在与不同类型的人工智能模型进行集成时。例如，国内的大语言模型在处理中文内容方面表现得非常出色。如果我们的MCP主要面向国内的大模型或相关代理进行开发和使用，那么使用中文来编写工具描述是可以接受的。然而，如果是针对国外的大模型，我们通常会推荐使用英文来编写工具描述，因为这是主要的差异所在。
在我看来，使用各种模型进行多次测试是非常必要的。目前，国外和国内的大模型在工具规划能力上仍然存在一些差异。例如，某些在特定领域表现优异的模型，如Claude，在处理代码相关服务时规划能力较强，因此使用这些模型可能会更加简单。我们需要根据具体的应用场景和领域进行选择和磨合。例如，对于开发类的MCP，Claude可能会表现得更好；而对于其他类型的MCP，如查询天气或烹饪相关的服务，GPT可能会更加适用。
InfoQ：那如果遇到兼容不是太好的情况，我们会采用哪些技术手段来提升这种兼容性呢？
汪晟杰：目前我的感受是，解决这一问题的关键在于，要进行尽可能多的测试。无论是我自己使用，还是为他人提供服务，我都倾向于进行多次测试，以观察不同情况下的表现。
在测试过程中，我会选择不同的大模型，并准备一些固定的输入和输出来进行验证。因为在开发MCP时，我们自己也是用户，通常会从用户的角度出发，将请求传递给大模型。大模型会将这些请求转化为具体的用户意图，然后调用MCP。
经过大模型处理后的用户意图往往已经比较明确，因此在测试MCP时，我们可以准备几种不同的输入，通过不同的大模型来观察输出结果，从而调整工具的描述。本质上，清晰的描述与模糊的描述之间存在很大差异，清晰的描述能够更好地让系统理解我们的意图。
从第一性原理出发，首先需要关注的是API的设计。API应该是正交的，即每个API的功能应该是独立且高内聚的，而不同API之间则应尽量解耦。以人类的视角来看，一个设计合理的API应该是清晰且易于理解的。这是第一步，也是避免API功能重叠或混淆的基础。例如，我们不能让一个API的功能可以通过另一个API实现相同的效果，必须确保API之间的功能划分明确。
其次，是关于描述的问题。在设计API时，我们需要明确初衷，清晰地说明每个API的用途、何时使用以及预期输出。例如，如果我们要查询用户的非敏感数据，必须明确告知用户何时可以发起请求，以及我们将提供什么样的数据。不能含糊其辞，比如仅仅将接口命名为“查询用户数据”，尤其是当存在多个类似接口时，如“查询用户手机号”或“查询用户在某地的手机号”等，这种命名方式可能会让人感到困惑。
因此，在确保API正交的前提下，我们需要尽可能清晰地描述每个API或工具的使用场景、使用方式以及预期输出。这实际上是一种架构思维在人工智能领域的体现。
我们可以这样理解：如果一个API能让人类用户感到清晰易懂，那么大模型大概率也能更好地理解和使用它。
InfoQ：根据您的回答总结起来就是，在MCP服务的实际运行中，工具描述的清晰度会直接影响模型调用的准确性。从技术运营的角度来看，当出现调用异常时，MCP系统是如何通过错误监控机制来发现问题根源的？特别是在金融等高实时性要求的场景下，最新发布的StreamableHTTP协议是如何优化这类问题的？
郭伟：确实是这样。如果描述不够清晰，模型在执行任务时就会出现大量的预测或尝试。从MCP后台可以看到，这种情况下会产生大量错误。有些错误非常明显，比如当MCP需要完成特定功能，明确所需输入和输出时，如果描述不清晰，大模型可能会随意生成一个用户ID或其他信息进行尝试。通常情况下，这会导致报错，提示某些内容不清晰。模型在收到反馈后，会尝试用正确的方式重新访问。
这种情况下，通常会反映出我们自己的MCP主控器存在问题。简单来说，我们可以通过后台监控访问失败率来发现问题。如果访问失败率很高，尤其是出现400类错误，这说明接口的填写可能存在问题，MCP可能不够友好。
这时我们会采取一些改进措施。因为我们清楚输入和输出的具体要求，所以在出错时能够快速定位问题所在，并对描述进行优化，使其更加清晰。例如，早期在使用MCP时，如果描述不够好，大模型在Github尝试提交issue时可能会随意生成一个仓库ID，这通常会导致404等错误。但通过不断迭代和优化描述，这些错误会逐渐减少。
一旦描述得到改进，线上效果会很快显现，400类错误会明显减少。在金融等对实时响应要求较高的行业场景中，数据传输和处理的时效性至关重要。
今年3月，MCP发布了一个新版本，支持“StreamableHTTP”的协议。这个协议有三个特点：首先，它是一个有状态的协议，可以选择有状态或无状态；其次，它能够实现服务器端的主动通知；最后，它支持流式输出。回到高响应场景，通常接口在服务端是通过条件语句（如if）实现的，当数据端发生变化时，会通过回调或长连接的方式将数据传递到服务端。
对于MCP来说，这个新协议能够实现类似的效果。当API服务收到最新的变更数据或需要实时展示的数据时，可以通过状态管理和服务器端通知机制，让MCP客户端快速接收到消息。目前，流式输出的应用场景还比较少，大家都在探索中。
未来可能会在Agent与Agent之间实时通信的场景中出现这种需求。目前，大家还在探索如何在接入新数据源时自动感知并进行配置。虽然MCP协议支持这一功能，但具体的使用方式还在探索中。这种机制类似于早期的消息推送，就像手机上将消息从后台推送到App一样。
人可以作为一个Agent，
MCP则作为工具
InfoQ：在多模态混合训练和推理过程中，业内是如何将不同类型的数据进行统一处理和调度的呢？
汪晟杰：一般来说，大家都是通过Agentic的方式来完成这项工作。例如，在训练过程中，我们会将训练任务作为一个agent来进行统一规划，而将每个任务的具体执行交给MCP来完成。本质上，这和过去我们在训练过程中运行脚本的方式类似，只是现在我们将脚本转化为MCP的形式。
MCP运行一段时间后会产生结果，然后将结果反馈给Agent，Agent再根据这些结果进行进一步的判断和决策。
简单来说，我们把过去需要人工执行的任务，通过脚本的形式转化为MCP来实现自动化。然而，在训练过程中，例如一批批地训练数据，无论是用于预训练还是后训练，这些过程本身是无法通过MCP进行干预的。从任务开始到结束，虽然最终可以通过MCP进行简单的测试以验证效果，但整个过程的自动化是通过将人工操作转化为Agentic过程来实现的。
在这个过程中，Agent技术是不可或缺的。从某种意义上说，人本身也可以被视为一个Agent，而MCP则是工具。
InfoQ：在我们自己开发Agent时，如何与MCP进行适配，以及根据什么样的需求进行具体的操作呢？
郭伟：对于一个Agent，从简单角度来看，它实际上可以被理解为提示词、工具、大模型以及存储的结合。在构建Agent时，我们首先需要从第一性原理出发，就像人类处理任务一样，明确目标和任务的拆解，这对应于prompt。
其次，我们需要确定在执行任务过程中需要哪些工具，这些工具可能包括脚本或API。
最后，在存储方面，情况可能会相对复杂。对于知识类或相关性极强的知识，我们需要考虑长期存储的解决方案；而对于短期存储需求，我们可以利用缓存机制来解决这些问题。至于大模型的选择，这取决于具体的应用场景。例如，在开发类任务中，像DeepSeek或Claude这样的模型可能是合适的选择。
而在其他场景下，可能需要根据具体需求选择不同的模型。这实际上取决于我们对人工智能行业的了解程度。完成这些准备工作后，我们就可以快速地开发一个Agent。
目前市面上有许多现成的框架可供选择，例如谷歌推出的GoogleAgentDevelopmentKit(ADK)，微软的AutoGen框架，以及基于图结构的LangGraph框架等。这些框架为我们提供了丰富的选项，我们可以根据具体需求自行选择和使用。
如何解决延迟问题
InfoQ：现在开发完MCP服务器后都要接入企业内部的系统中，那当我们的MCP服务器接入企业内部的旧系统时，是否会像之前提到的那样出现初始延迟查询的问题，比如延迟几秒合适？针对延迟我们有什么解决方案吗？
汪晟杰：如果由人来完成这项任务，那么本质上是基于预定义的流程来操作。而如果交给机器，也就是Agent来完成，那么它将基于整体的判断来进行任务拆解与协作。
可以从几个角度来考虑。首先，如果任务可以用人来完成，并且流程比较清晰，那么最好尽量使用一些开发工具将这些流程固化下来，让人工来操作。这是一种既经济实惠又高效的方法。其次，如果发现人工操作比较麻烦，但任务确实可以清晰地描述出来，包括在各种情况下应该如何处理，虽然人工完成起来比较费劲，但仍然可以完成，那么在这种情况下，可以考虑使用Agent。
不过，使用Agent的代价可能是成本稍高，且速度较慢，因为Agent的每一步都需要向大模型询问下一步该如何操作，而大模型每次理解任务都需要时间。相比之下，人工操作可能一次性就能高效完成，并且速度更快。
我的观点是，对于容易解决的任务，最好由人工来完成；而对于难以解决的任务，则可以考虑使用Agent。例如，当遇到一个任务时，需要选择使用哪些知识库，先根据相关性来筛选知识库，然后再查看结果。在这种需要进行深度思考的情况下，人工操作慢，而Agent在这种复杂任务中可能更有优势。但如果任务的步骤可以明确地分解为第一步、第二步、第三步等，那么就没有必要每次都让Agent去逐步拆解任务，因为这样成本较高。
总结起来就是，这是一个需要权衡的问题，并没有一个绝对的标准。通常来说，如果任务可以清晰地交代清楚，并且相对简单，那么最好由人工来完成。尤其是对于开发类任务。对于训练任务，因为很多内容都是固化的，如果没有进行A/B测试等复杂操作，Agent可以快速搞定。最简单的方式就是使用一个固化的workflow来执行任务。
InfoQ：其实深入到企业内部系统时，免不了要和数据打交道，但企业中的数据往往是不规整的，可能散落在各个角落。那么，我们目前是如何将MCP服务器与企业内部现有的数据资源体系进行融合的呢？有没有相关的接口和工具可供使用？
郭伟：MCP本身的标准并非旨在直接解决数据治理的问题。它是一类工具，用于解决特定类型的问题。例如，如果企业的目标是通过MCP解决内部治理问题，那么首先需要明确的是，如果由人来解决这个治理问题，应该如何操作。想清楚这一点后，就可以将散落在各处的数据以及其他相关资源进行整合，形成一些对内的接口。
这些接口可以转化为MCP的一部分，以便于用户在进行查询或进一步对外展示时，能够实现数据的聚合。MCP本身无法直接解决数据整合的问题，仍然需要一个中台或者统一的接入层来打通散落在各处的数据。通过MCP，将这些数据整合后提供SaaS服务。MCP的作用在于，如果用户想要进行数据治理，而这些治理工作是可以被描述并由AI完成的，那么就可以将这些治理工具转化为MCP。交给大模型的前提是，这些工作是人能够完成的。
大模型本质上是对人类行为的模仿，是对人类能力的一种泛化。只有人类能够完成的任务，大模型才有可能去执行。
InfoQ：随着技术的快速发展，我们的工具和模型都在不断迭代更新。在这种情况下，MCP服务器是否需要在每次工具或模型迭代时都重新进行适配和对接，还说在其他模型或工具迭代时依然保持原样使用呢？
郭伟：从实际应用的角度来看，如果一个模型已经具备了某种能力，并且这种能力随着时间的推移不断增强，例如其规划能力等，那么对于一个已经存在的大模型，我们通常只需要进行一次适配，基本就能满足需求。当然，未来如果该模型推出了新的版本，我们可以评估是否可以进一步优化，以更好地利用这个大模型。这通常是我们的经验之谈。
如果出现了一个全新的模型，比如行业突然出现了一个类似GPT那样具有巨大影响力的模型，那么我们就需要自己进行适配了。但是一般的经验是，一旦完成适配，后续就无需频繁地进行调整。我们只需关注该模型的升级动态，因为通常情况下，随着模型的不断优化，其效果会越来越好。
隐私数据不能通过MCP提供
InfoQ：一旦碰到数据，就会存在隐私和安全问题。当MCP客户端在访问数据时，是如何实现字段级别的控制，以确保数据的安全性和隐私性的呢？
郭伟：我认为应该从几个层面来考虑这个问题。首先，对于隐私数据，我们应尽量避免通过MCP的方式提供，例如手机号、银行密码等敏感信息。一旦这些信息通过MCP提供出去，一方面会被用户获取，另一方面也可能出现在与大模型聊天的上下文中。在执行任务时，大模型可能不仅会调用一个MCP工具，还可能调用其他工具。如果有一个MCP服务描述中提到获取手机号或银行卡号，大模型会直接将这些信息传递过去。因此，第一个要点是敏感数据绝对不能放在上下文中，也不能作为输入或输出来使用，这是基本原则。
其次，对于非敏感数据的授权使用，可以通过现有的身份验证和授权机制，如OAuth2. 0或OpenIDConnect，来管理用户权限。企业可以在用户通过单点登录（SSO）后，利用现有的权限模型来约束用户对MCP服务的访问，确保数据的安全使用。
MCPvsOpenAI函数vsA2A
InfoQ：这样看来MCP能解决的问题真不少，但其实业内还是经常将MCP与OpenAI的函数调用进行比较，OpenAI的函数调用需要手动编写API描述，而我们使用的MCP具有自动化服务功能。那么，这种自动化服务是否能够减少一些工作量呢？
郭伟：从本质上讲，MCP和以往的函数调用并无二致。如果以前的函数调用主要服务于OpenAI，那么MCP则是面向所有人开放的。本质上，这可以看作是一个通用接口与专用接口的问题。但它们都可以被统称为模型所需的工具。
在这种情况下，我觉得没有必要纠结于MCP或函数调用，因为无论是哪种方式，工序描述本身都是必须书写的，这是无法回避的。在与大模型交互时，我们需要明确告知模型在何种情况下使用内置的MCP，以及何时调用其他功能。这种工作量是客观存在的。我们应更多地关注工具描述本身该如何撰写，而不是纠结于谁来写或何时写。
InfoQ：谷歌最近推出了A2A协议，今天又把A2A捐给了Linux基金会，那这个A2A和MCP之间的区别是什么呢？您认为，鉴于目前MCP如此受欢迎，未来A2A的生态是否会像MCP这样更加庞大呢？
汪晟杰：MCP主要解决的是工具层面的问题，而A2A则侧重于生态层面的构建。对于大语言模型来说，它们在过去只能进行基于知识的问答。然而，随着Agent技术的出现，这些模型开始能够接触物理世界，并通过工具来执行各种任务。但这些任务往往是单一的，这就引出了一个问题：世界上是否只需要一个Agent就足够了？显然，答案是否定的。每个Agent都有其特定的目标和明确的提示词，当用户给出特定输入时，Agent会返回一个特定的输出，这个输出可以是一段文字、一张图片或其他形式的内容。这就是Agent的使命。
MCP的作用在于为这些具有特定使命的Agent提供必要的工具。从A2A的角度来看，其核心在于促进不同Agent之间的相互通信和相互发现。例如，一个团队的负责人想要承接一个装修项目，他需要到人才市场寻找各种工种的工人。A2A通过为每个Agent提供一个“名片”（agentcard），明确每个Agent的能力、作用以及访问方式，使得每个Agent都能清楚地展示自己的功能，并将其放置在各自的服务器上，供所有人访问和了解。
A2A的另一个重要作用是实现不同框架的Agent之间的通信。目前，无论是谷歌、微软等大公司，还是开源社区，都提供了各种Agent框架。A2A的目标是让这些不同背景的Agent能够相互协作，就像不同学校毕业的人最终都要进入职场一样。在这个过程中，AtoA提供了一个平等的协议，使得agent们能够进行有效的通信和协作。此外，还存在一些特殊的工具，它们既是Agent，又是MCP。这与人类社会中的某些角色类似，它们的输入是自然语言，输出是某种作品，但它们以工具的形式展现。在这种情况下，它们既是MCP，又是Agent，但与A2A相比，还是存在明显的差异。这些工具更强调执行能力，而不是规划能力。
总的来说，MCP和A2A在生态层面有不同的侧重点。MCP专注于解决个人工具的问题，而A2A则致力于构建一个能够促进Agent之间协作的社区或团体。
InfoQ：那腾讯内部的一些产品，是否有计划在未来接入A2A协议？
郭伟：我们肯定有这样的计划。目前，我们主要专注于开发类工具，例如代码开发。从产品研发流程来看，包括产品设计、代码开发以及最后的代码漏洞检测等环节，这些流程本身就非常适合多Agent协作。当我们拥有多个Agent时，如何实现更好的通信就成了我们选择框架时需要考虑的问题。在这种情况下，A2A是一个比较好的选择。从我们的角度来看，我们不仅不排斥，而且非常愿意接受这种生态。
汪晟杰：从产品层面来看，我们首先从MCP的角度进行规划。我们计划将腾讯自身的一些产品、云厂商提供的基础设施以及开源组件整合到MCP中，使其成为一个强大的工具集合。我们的目标是在AI场景下辅助并提高软件开发的效率，甚至让AI承担一些重复性工作，而人类只需对最终结果进行确认。
为了实现这一目标，我们需要模仿人类在开发过程中使用的工具，因此MCP将包含与研发、设计、需求分析等相关的一系列工具和技术。这就是MCP为我们带来的价值。在企业环境中，工具并非孤立存在，而是被共享使用的。企业团队通常有一套自己的研发规范、第三方业务系统以及与其他工具和内部产品的对接。这些工具本身可以被视为智能体，因为不同的产品也会整合大模型，并具备自己的逻辑。例如，企业可能有一些核心代码库的理解，专门用于数据分析和采集。在实际业务中编写代码时，我可能是一个编码智能体，而我可能需要与其他智能体协作。
A2A本质上是一种带有协作流程的感知，人类在其中扮演代理的角色，对智能体的输出进行确认。例如，我开发的一个A2A智能体如果要参与到A2A协议中，就需要让两个智能体之间能够交换身份或约定，使数据能够流通，从而发生协作。这样，我们就可以将协作范围扩大，而不仅仅局限于本地工具。我可以通过服务发现的方式找到企业中的其他智能体，并与它们协作，使整个流程更加广泛。
以我们正在开发的IDE为例，它本身就是一个多智能体架构。设计阶段可以通过Figma等工具进行元素提取，而这些提取并非完全基于规则，而可能是一种智能体，能够理解元素的核心点。在生成代码之前，它会进行数据清洗，将组件转换为前端可理解和使用的约定语言。这些语言并非HTML，因为HTML是一种设计性语言。当数据到达前端输入点时，它与我交换的协议不仅仅是HTML，还可能是图形之间的结构、跳转、色号色系以及前端所需的框架组件。这些设计元素由智能体提供，编码智能体拿到这些元素后，基于研发规范和流程，生成可以直接部署到前端工程库的代码。这个代码生成后可以直接运行，并提供一个预览地址。
如果过程中出现失败或需要调整需求的情况，可能会有一个需求智能体介入，可能来自GitHub或需求单。如果代码没有按需求或设计运行，研发智能体会将问题反馈给设计智能体或需求智能体，进行协作调整。例如，设计不符合前端组件规范或组件库，可能需要调整按钮大小等。这就是两个智能体之间的协作，最终可能需要人类进行确认。目前，A2A还处于初级阶段，智能体之间更像是孤岛，只能进行有限的交换。A2A已经提供了一个开放协议，允许交换必要的信息，但要实现我之前提到的反思、对抗协作和互补，以及最终的人类确认，还有很长的路要走。
像Manus和CloudCode这样的新产品也在尝试多智能体协作，但目前仍处于初期阶段。目前比较好的逻辑是少量的A2A发生，甚至是一个为主为辅的A2A发生。多智能体协作还在探索阶段，目前更倾向于有主次区分的协作。许多大厂，都在强调主计划的重要性。
主计划的本质是让单体智能体变成多体智能体，子智能体服务于主智能体。主智能体不直接执行任务，而是进行任务分配。它也会有一些思维链，然后子智能体根据这些思维链来决定是调用云端资源执行代码，或调用其他智能体的相关MCP，例如设计资源或文档，以理解研发规范或设计规范。然后将这些信息传递给下一个子智能体，即编码智能体，让它生成代码。
在这个过程中，可能还需要一个环境，子智能体会帮助自己搭建环境。这也就是Cursor最近流行的BackgroundAgent的概念，CloudCode也在讨论这个问题。所以我认为目前的软件架构仍然类似于Master-Slave模式。
未来发展方向
InfoQ：那您能否帮我们预测一下，未来MCP和A2A协议会朝着什么样的方向发展？
汪晟杰：MCP可以被视为一个较小的子集，它将呈现多样化的发展趋势。预计大约80%的核心软件都将推出自己的MCP。MCP本质上是一个端口，供大模型调用。接下来，Agent的发展方向无疑是朝着多智能体的方向前进，但会变得更加可控。在这个过程中，人类的角色需要被明确界定。目前，这套协议尚未完善，尤其是在明确人类在过程中扮演的角色方面。它更多地强调了Agent之间的协议。
在我看来，目前的情况可能是存在两层结构，但这两层中可以包含多个Agent。这并非只有两个Agent的简单结构，而是可以有多个Agent，但必须有一个主Agent和若干子Agent来执行任务。从短期来看，这种结构是比较可控的。人类的角色相对简单，主要是对计划进行验证和确认。如果主Agent生成的计划不符合要求，人类可以进行反思和修正。甚至在主Agent生成计划之前，可以让人类进行一次确认。之后的执行过程可以无需干预，但在计划阶段，人类需要进行最终的把控。然而，即便只是这一点，要实现产品的极致体验也极具挑战性。因为大模型本身具有随机性和概率性，如何让其结果收敛到我们期望的范围内是一个难题。我们不能仅仅依赖于master/slave模式的可控性，花费大量时间让模型不断反思和尝试，最终却可能得到一个不符合预期的结果。
这就好比雇佣了一个表现不佳的员工，我们需要不断让他重新规划和修正，这不是我们想要的结果。如何让agent本身具备更强的计划思考能力，也是大模型需要考虑的问题。这涉及到大模型的推理能力和思考能力的持续增强，需要与模型层面进行深度融合。
同时，在产品层面也需要进行创新，以便在大部分推理过程之外，还能利用人类的最终干预来提升效果。在这方面，我们已经进行了一些尝试。
郭伟：我想对MCP再做一些补充说明。我之前认为未来MCP的发展肯定是大规模的，但之前大家的反应相对比较慢。我认为其中一个较大的原因在于之前的协议并不完善，没有采用类似StreamHTTP的方式。因此，之前存在很多问题，从企业端来看，这些问题之前是难以解决的。然而，在今年3月26日版本更新之后，这些问题正在逐步得到解决。对于企业来说，现在可以更快速地将内部的SaaS能力通过MCP的方式释放出来。
从生态角度来看，这可能是一个更加快速且更容易的过程。其次，MCP目前还有一个比较重要的特点是安全可信问题。例如，我们自己也在运营MCP市场，因此在选择MCP工具时，我们会有一些比较严格的标准。毕竟，如果用户使用了我们提供的工具后出现问题，他们肯定会找我们腾讯。
在业界，无论是使用我们的市场还是其他市场，用户都需要设法判断工具的安全性。但实际上，用户很难做出准确判断，因为MCP的很多内容已经黑盒化，包括内部逻辑和提示词描述等。比如，我之前举的例子，如果我是一个黑客，自己做一个MCP服务，并在工具描述中写一些不良内容，如要求用户提供手机号或银行卡信息等，用户可能完全不知情。
未来，我认为行业可能会出台一些安全措施，帮助用户发现MCP服务的问题，从而使这个行业能够更加健康地发展。
点击底部阅读原文访问InfoQ官网，获取更多精彩内容！
会议推荐
首届AICon全球人工智能开发与应用大会（深圳站）将于8月22-23日正式举行！本次大会以“探索AI应用边界”为主题，聚焦Agent、多模态、AI产品设计等热门方向，围绕企业如何通过大模型降低成本、提升经营效率的实际应用案例，邀请来自头部企业、大厂以及明星创业公司的专家，带来一线的大模型实践经验和前沿洞察。一起探索AI应用的更多可能，发掘AI驱动业务增长的新路径！
今日荐文
华为回应盘古大模型抄袭；DeepSeek在海外招聘；马斯克宣布成立“美国党”，明年参加大选｜AI周报
离开百川去创业！8个人用2个多月肝出一款热门Agent产品，创始人：Agent技术有些玄学
李飞飞曝创业招人标准！总结AI大牛学生经验，告诫博士们不要做堆算力项目
Altman嘲讽小扎挖走的都不是顶尖人才！OpenAI高管再营业曝内幕：ChatGPT爆红后，我火速升职了！
跳槽实现财富自由！小扎千万年薪快要“掏空”OpenAI核心人才，还高调“晒”挖人成绩单：各栈大牛，近70%是华人
你也「在看」吗？👇
