MCP 已经起飞了，A2A 才开始追赶

采访嘉宾｜郭伟、汪晟杰

6 月 24 日，谷歌云官宣将 A2A（Agent-to-Agent）协议捐赠给了 Linux 基金会，消息一出引发了 AI 行业地震。这份包含智能体交互协议、SDK 和开发者工具的开源礼包，背后站着亚马逊、微软、思科等科技巨头组成的“全明星”阵容。

Google Cloud 副总裁兼商业应用平台总经理 Rao Surapaneni 表示：“通过与 Linux 基金会和领先的技术提供商合作，我们将在值得信赖的开放治理框架下，实现更具创新性和价值的 AI 功能。”

在外界看来，谷歌云捐赠开源 A2A 的决策有点耐人寻味。在 Reddit 平台，有评论认为谷歌这么做是对 Anthropic MCP 协议、OpenAI 函数等竞品的战略应对，但同时也揭示了行业共识：智能体经济需要共建底层规则。

也有用户认为，MCP 已经起飞了，A2A 才开始追赶。

甚至有人厌倦了谷歌，认为 A2A 不会成功。

在 A2A 协议引发热议的同时，MCP 已经在企业级市场悄然生根。与 A2A 侧重智能体间通信不同，MCP 解决的是更基础的问题：如何让 AI 模型安全高效地调用现实世界中的工具和服务。就像人类需要螺丝刀才能拧螺丝，AI 智能体需要 MCP 才能操作企业 API、数据库等数字工具。

那么，开发一款 MCP Server 关键环节有哪些？在接入企业内部系统时 MCP Server 需要做哪些适配工作？MCP 协议与 A2A 协议的区别是什么，未来发展方向在哪里？

为了解答上述问题，我们采访了腾讯云资深产品技术专家汪晟杰和腾讯云资深后端技术专家郭伟，听他们深入剖析 MCP 技术的核心逻辑与未来趋势。

MCP Server 开发，最关键环节在于工具描述

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 系统是如何通过错误监控机制来发现问题根源的？特别是在金融等高实时性要求的场景下，最新发布的 Streamable HTTP 协议是如何优化这类问题的？

郭伟：确实是这样。如果描述不够清晰，模型在执行任务时就会出现大量的预测或尝试。从 MCP 后台可以看到，这种情况下会产生大量错误。有些错误非常明显，比如当 MCP 需要完成特定功能，明确所需输入和输出时，如果描述不清晰，大模型可能会随意生成一个用户 ID 或其他信息进行尝试。通常情况下，这会导致报错，提示某些内容不清晰。模型在收到反馈后，会尝试用正确的方式重新访问。

这种情况下，通常会反映出我们自己的 MCP 主控器存在问题。简单来说，我们可以通过后台监控访问失败率来发现问题。如果访问失败率很高，尤其是出现 400 类错误，这说明接口的填写可能存在问题，MCP 可能不够友好。

这时我们会采取一些改进措施。因为我们清楚输入和输出的具体要求，所以在出错时能够快速定位问题所在，并对描述进行优化，使其更加清晰。例如，早期在使用 MCP 时，如果描述不够好，大模型在 Github 尝试提交 issue 时可能会随意生成一个仓库 ID，这通常会导致 404 等错误。但通过不断迭代和优化描述，这些错误会逐渐减少。

一旦描述得到改进，线上效果会很快显现，400 类错误会明显减少。 在金融等对实时响应要求较高的行业场景中，数据传输和处理的时效性至关重要。

今年 3 月，MCP 发布了一个新版本，支持“Streamable HTTP”的协议。这个协议有三个特点：首先，它是一个有状态的协议，可以选择有状态或无状态；其次，它能够实现服务器端的主动通知；最后，它支持流式输出。回到高响应场景，通常接口在服务端是通过条件语句（如 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。

目前市面上有许多现成的框架可供选择，例如谷歌推出的 Google Agent Development Kit (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 服务描述中提到获取手机号或银行卡号，大模型会直接将这些信息传递过去。因此，第一个要点是敏感数据绝对不能放在上下文中，也不能作为输入或输出来使用，这是基本原则。

其次，对于非敏感数据的授权使用，可以通过现有的身份验证和授权机制，如 OAuth 2.0 或 OpenID Connect，来管理用户权限。企业可以在用户通过单点登录（SSO）后，利用现有的权限模型来约束用户对 MCP 服务的访问，确保数据的安全使用。

MCP vs OpenAI 函数 vs A2A

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 提供一个“名片”（agent card），明确每个 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 和 Cloud Code 这样的新产品也在尝试多智能体协作，但目前仍处于初期阶段。目前比较好的逻辑是少量的 A2A 发生，甚至是一个为主为辅的 A2A 发生。多智能体协作还在探索阶段，目前更倾向于有主次区分的协作。许多大厂，都在强调主计划的重要性。

主计划的本质是让单体智能体变成多体智能体，子智能体服务于主智能体。主智能体不直接执行任务，而是进行任务分配。它也会有一些思维链，然后子智能体根据这些思维链来决定是调用云端资源执行代码，或调用其他智能体的相关 MCP，例如设计资源或文档，以理解研发规范或设计规范。然后将这些信息传递给下一个子智能体，即编码智能体，让它生成代码。

在这个过程中，可能还需要一个环境，子智能体会帮助自己搭建环境。这也就是 Cursor 最近流行的 Background Agent 的概念，Cloud Code 也在讨论这个问题。所以我认为目前的软件架构仍然类似于 Master-Slave 模式。

未来发展方向

InfoQ：那您能否帮我们预测一下，未来 MCP 和 A2A 协议会朝着什么样的方向发展？

汪晟杰：MCP 可以被视为一个较小的子集，它将呈现多样化的发展趋势。预计大约 80%的核心软件都将推出自己的 MCP。MCP 本质上是一个端口，供大模型调用。接下来，Agent 的发展方向无疑是朝着多智能体的方向前进，但会变得更加可控。在这个过程中，人类的角色需要被明确界定。目前，这套协议尚未完善，尤其是在明确人类在过程中扮演的角色方面。它更多地强调了 Agent 之间的协议。

在我看来，目前的情况可能是存在两层结构，但这两层中可以包含多个 Agent。这并非只有两个 Agent 的简单结构，而是可以有多个 Agent，但必须有一个主 Agent 和若干子 Agent 来执行任务。从短期来看，这种结构是比较可控的。人类的角色相对简单，主要是对计划进行验证和确认。如果主 Agent 生成的计划不符合要求，人类可以进行反思和修正。甚至在主 Agent 生成计划之前，可以让人类进行一次确认。之后的执行过程可以无需干预，但在计划阶段，人类需要进行最终的把控。 然而，即便只是这一点，要实现产品的极致体验也极具挑战性。因为大模型本身具有随机性和概率性，如何让其结果收敛到我们期望的范围内是一个难题。我们不能仅仅依赖于 master/slave 模式的可控性，花费大量时间让模型不断反思和尝试，最终却可能得到一个不符合预期的结果。

这就好比雇佣了一个表现不佳的员工，我们需要不断让他重新规划和修正，这不是我们想要的结果。如何让 agent 本身具备更强的计划思考能力，也是大模型需要考虑的问题。这涉及到大模型的推理能力和思考能力的持续增强，需要与模型层面进行深度融合。

同时，在产品层面也需要进行创新，以便在大部分推理过程之外，还能利用人类的最终干预来提升效果。在这方面，我们已经进行了一些尝试。

郭伟：我想对 MCP 再做一些补充说明。我之前认为未来 MCP 的发展肯定是大规模的，但之前大家的反应相对比较慢。我认为其中一个较大的原因在于之前的协议并不完善，没有采用类似 Stream HTTP 的方式。因此，之前存在很多问题，从企业端来看，这些问题之前是难以解决的。然而，在今年 3 月 26 日版本更新之后，这些问题正在逐步得到解决。对于企业来说，现在可以更快速地将内部的 SaaS 能力通过 MCP 的方式释放出来。

从生态角度来看，这可能是一个更加快速且更容易的过程。其次，MCP 目前还有一个比较重要的特点是安全可信问题。例如，我们自己也在运营 MCP 市场，因此在选择 MCP 工具时，我们会有一些比较严格的标准。毕竟，如果用户使用了我们提供的工具后出现问题，他们肯定会找我们腾讯。

在业界，无论是使用我们的市场还是其他市场，用户都需要设法判断工具的安全性。但实际上，用户很难做出准确判断，因为 MCP 的很多内容已经黑盒化，包括内部逻辑和提示词描述等。比如，我之前举的例子，如果我是一个黑客，自己做一个 MCP 服务，并在工具描述中写一些不良内容，如要求用户提供手机号或银行卡信息等，用户可能完全不知情。

未来，我认为行业可能会出台一些安全措施，帮助用户发现 MCP 服务的问题，从而使这个行业能够更加健康地发展。