A Comparative Study of MCP and A2A for Inter-Agent Coordination in LLM-Based Systems
本文对用于智能体间协调的模型上下文协议（MCP）与 Agent2Agent（A2A）进行了实证比较，结果表明，MCP 提供了一种轻量级、低复杂度的方案，但需要显式的应用层状态管理，而 A2A 则提供了更丰富的原生支持，用于处理有状态的多轮交互，但代价是显著提高的实现复杂度。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一个计算机不再仅仅是听从指令，而是能够通过相互聊天来解决问题的世界。这就是“智能体系统”（agentic systems）那令人兴奋又略显混乱的前沿领域。不要把这些智能体想象成长着腿的小机器人，而要将它们视为专业的数字员工。其中一个可能擅长编写代码，另一个擅长检查语法，第三个则擅长整理文件。在计算机科学的旧时代，让这些员工进行沟通，就像是试图让一位法国厨师、一位日本寿司大师和一位德国工程师在一个大家语言不通、使用的计量单位也各不相同的厨房里协作一样。他们需要一个通用翻译机，以及一套严格的规则来明确谁在何时做什么。
最近，出现了两种新的“语言”或规则手册，旨在帮助这些数字员工进行协调：模型上下文协议（Model Context Protocol, MCP）和智能体对智能体协议（Agent2Agent, A2A）。你可以将 MCP 想象成一个超高效的万能遥控器，旨在将电视（AI）与其各种输入源（工具和数据）连接起来。它的设计初衷是简单且快速。另一方面，A2A 则像是一款专为团队打造的专用项目管理软件；它内置了追踪谁在做什么、管理长期任务以及记录对话日志的功能。工程师们在构建这些系统时面临的一个重大问题是：我们是需要那个重型项目经理（A2A），还是只需使用这个万能遥控器（MCP）并自行解决团队管理问题？
本论文是一项旨在寻找答案的动手实验。研究人员构建了两支完全相同的 AI 智能体“团队”，用以解决一个特定的软件工程难题：将一个简单的图书馆系统的文本描述转化为一个复杂的、结构化的计算机模型。他们构建了一支使用 MCP “遥控器”方法的团队，以及另一支使用 A2A “项目经理”方法的团队。随后，他们观察了两支团队的表现，统计了使它们运转所需的代码行数，并检查了它们在处理诸如追踪对话、修复错误以及异步协作等方面的表现。
结果呈现了一种清晰的权衡，非常类似于在极简主义背包和功能齐全的登山背囊之间做出选择。使用 MCP 的团队表现出了惊人的灵活性。它所需的代码量减少了约 33%（1,255 行对比 1,898 行），并且依靠更少的复杂组件即可完成任务。这是一个“轻量级”的解决方案，以较低的开销完成了工作。然而，这种简洁性是有代价的：协议本身并不懂得如何处理长对话或随时间追踪任务状态。研究人员必须在他们的应用程序代码中从头开始构建所有这些“状态管理”功能，就像因为地图上没有路径，而不得不手动写下每一步旅程一样。
相比之下，A2A 团队则是那个“重体力劳动者”。它自带了一套丰富的内置工具，用于管理任务、追踪进度以及处理多轮对话（例如智能体可能需要请求澄清的情况）。它感觉更像是一个完整的、最先进的办公套件。但这种功能是以价格为代价的：它需要显著更多的代码来实现，并为系统引入了更多的复杂性。研究人员发现，虽然 A2A 更擅长处理那些“枯燥”但必要的协调工作（比如判断一个任务是暂停还是已完成），但要让它运行起来，其开发成本要高得多。
最终，本文表明，对于目前许多受限的 AI 系统而言，轻量级的 MCP 方法是一个可行且高效的选择，前提是开发者愿意在其之上构建自己的“项目管理”层。然而，如果你需要一个原生就能理解复杂、长期运行的工作流和状态变化的系统，那么 A2A 是一个更健壮、但也更复杂的选择。作者谨慎地指出，这并不是在宣布其中一个协议是“永久的赢家”；相反，这是对这两个工具在特定现实场景下表现的一种快照，强调了选择取决于你更看重速度与简洁，还是内置的复杂性管理。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。