一个 Agent 完成任务后可以通过 Message 沟通过程信息通过 Task 表达正在处理的工作再通过 Artifact 交付正式结果。解决了“传什么”本文继续讨论 Agent 和外部能力之间以及 Agent 之间具体应以什么方式协作。比如一个 Agent 要查询数据库可以直接调用 API也可以通过 MCP 使用数据库工具如果它无法独立完成任务还可能把工作交给另一个专业 Agent。这几种情况看起来都是“调用”实际面对的问题并不相同。一、Agent 系统的三类交互方式先看 Agent 系统中最常见的三种情况。第一种是直接调用已有服务Agent | | REST / RPC v业务服务例如客服 Agent 查询订单GET /orders/{id}如果服务地址固定、接口明确直接使用 REST 或 RPC 已经足够。第二种是 Agent 使用外部工具Agent | | MCP vMCP Server | v数据库 / 搜索 / 文件 / 业务系统这里 Agent 关心的是当前有哪些工具每个工具有什么用途需要哪些参数会返回什么结果这属于 MCP 主要解决的范围。第三种是两个独立 Agent 之间协作Agent A | | A2A vAgent BAgent A 面对的已经不是一个简单工具而是另一个可以独立完成任务的 Agent。它可能有自己的模型、Prompt、工具和运行状态甚至由另一个团队开发和部署。此时需要了解的是对方具备哪些能力怎样提交任务任务当前是什么状态最终能够得到什么结果这属于 A2A 主要解决的范围。A2AAgent2Agent Protocol是由 Google 发起、现由 Agentic AI Foundation 推进的开放标准用于让不同厂商、框架和语言实现的 AI Agent 能够发现彼此能力、交换消息、委派和跟踪任务并交付结构化结果从而实现跨系统的 Agent 协作与互操作。因此REST/RPC、MCP 和 A2A 面向的是不同场景不需要互相替代。二、MCP 的工具接入机制假设我们正在开发一个客服 Agent它需要查询客户资料查询订单搜索知识库创建工单读取退款记录传统做法通常是分别调用各个系统的 API再在 Agent 中维护相应的函数和参数定义。调用工具较少时这种方式没有问题。随着工具越来越多会变得越来越不易维护。每个工具怎样描述自己的用途参数格式放在哪里不同 Agent 是否都要重复开发适配代码模型怎样知道当前有哪些工具可用MCP 为这些问题提供了一套统一方式。外部系统可以通过 MCP Server 暴露能力Agent 一侧通过 MCP Client 获取并使用这些能力。其调用流程如下Agent |MCP Client | | MCP vMCP Server | -- Tool A -- Tool B -- Tool C其中最值得关注的是 Tool。一个 Tool 通常需要说明工具名称工具用途输入参数返回结果例如一个查询发票的工具可以描述为{ name: get_invoice, description: 根据发票编号查询发票信息, inputSchema: { type: object, properties: { invoice_id: { type: string } }, required: [invoice_id] }}这里的name是工具名称description说明用途inputSchema定义参数结构。Agent 获取这些信息后就能知道当前有哪些工具以及调用时应该提供什么参数。因此MCP 能够让 Agent 以统一方式认识和使用外部能力。至于 Tool 背后调用 PostgreSQL、REST API还是企业内部服务并不是 Agent 必须了解的内容。三、A2A 的 Agent 协作机制假设客服 Agent 收到用户的问题我的退款已经申请五天了为什么还没有到账Customer Agent 可以处理普通客服问题但退款调查由 Billing Agent 负责。于是任务会转交给 Billing AgentCustomer Agent | | A2A vBilling AgentCustomer Agent 不需要知道 Billing Agent 使用什么模型也不需要了解它内部有哪些 Prompt 和工具。它更关心Billing Agent 是否能处理退款问题任务应该怎样提交当前处理到哪一步结束后会返回什么A2A 主要解决的正是这类 Agent 之间的协作问题。其中有几个核心概念Agent CardTaskMessageArtifact它们分别解决能力描述、任务状态、过程沟通和结果交付等问题。四、Agent Card 的能力描述A2A 使用 Agent Card 描述 Agent 对外提供的信息和能力。可以把它理解为 Agent 的服务说明。例如{ name: Billing Resolution Agent, description: 处理账单和退款相关问题, skills: [ { name: refund_investigation }, { name: invoice_query } ]}其中skills表示这个 Agent 对外提供的能力。真实的 Agent Card 还可以包含访问地址、支持的交互方式和安全相关信息。这样系统面对一个新任务时可以先确认有哪些 Agent各自擅长什么哪个 Agent 能处理当前任务确定目标之后再进入具体的任务交互。五、Task 的任务状态管理在 Agent 内部Tool 调用通常比较直接get_invoice(INV-1001) ↓返回发票信息但 Agent 接到的往往是一项需要持续处理的工作。例如调查这笔退款为什么迟迟没有到账检查支付记录、退款状态和客服历史最后给出处理结果。Billing Agent 可能需要连续访问多个系统中途还可能等待新的信息。因此A2A 使用 Task 表示一项正在处理的任务。一个 Task 可能经历类似这样的状态变化submitted | vworking | vcompleted有些任务还可能进入等待输入、失败或取消等状态。这里体现了 Agent 与普通函数调用的一个明显区别。函数通常关注请求 ↓结果Agent 协作还需要知道任务是否已经开始当前进行到哪一步是否需要额外信息最终是否完成对于耗时较长的任务系统还可以通过 Streaming、订阅状态变化或通知机制持续获得进展而不必一直等待一个同步请求返回。六、Artifact 的结果形态任务完成之后还需要交付结果。如果只是简单回复退款正在处理中Message 已经足够。但 Agent 的正式产出可能是一份报告、一段结构化数据甚至一个文件。例如 Billing Agent 最终生成Refund Investigation Report - 退款申请时间- 支付渠道状态- 当前退款状态- 异常原因- 建议处理方式这类可以继续被其他系统使用的正式结果可以通过 Artifact 表达。因此上述几个概念的职责如下Agent Card描述“我具备什么能力” Task表示“当前正在处理什么工作” Message承载任务过程中的沟通 Artifact保存任务产生的正式结果这也与上一篇中介绍的 Agent 交付内容完全一致。上一篇关注 Agent 之间交接什么这里进一步关注这些内容怎样在独立 Agent 之间流转。七、MCP 与 A2A 的组合结构MCP 和 A2A 并不冲突。它们很可能同时出现在一个系统中。继续使用前面的客服场景Customer Agent | | A2A vBilling Resolution Agent | ---- MCP ---- CRM | ---- MCP ---- Invoice Database | ---- MCP ---- Ticket System用户询问退款问题后Customer Agent 判断自己无法完成完整调查于是通过 A2A 把任务交给 Billing Resolution Agent。Customer Agent 关心Billing Agent 擅长什么怎样提交 Task当前处理到哪一步最终返回什么 ArtifactBilling Agent 接到任务后需要查询客户资料、发票和客服工单。这时它通过 MCP 使用对应工具get_customer()get_invoice()search_tickets()Billing Agent 关心有哪些 Tool每个 Tool 需要哪些参数调用后返回什么数据所以同一个系统中两种协议承担的是不同职责Agent | | A2A | Agent 之间的任务协作 vAgent | | MCP | Agent 对外部能力的使用 vTool / Data / API八、不同交互方式的适用边界实际工程中我们应根据不同场景选择不同的调用方式。场景适合方式主要原因同一程序中的固定逻辑函数 / 模块调用简单直接没有网络交互已知的内部业务服务REST / RPC地址和接口稳定Agent 使用搜索、数据库、文件MCP工具可以统一描述和使用独立 Agent 之间的任务委托A2A需要能力描述和任务状态跨团队的 Agent 协作A2A双方无需了解内部实现Agent 内部使用多个外部工具MCP工具可以独立接入和复用如果当前对象提供一个明确、清晰的能力例如查询订单搜索文档创建工单读取数据库它应该以 Tool 的方式实现。如果当前对象能够接收完整任务自行组织执行过程调用多个工具维护任务状态返回完整结果它应以 Agent 形式实现。总结Agent 系统中常见三种交互方式直接调用 API、通过 MCP 使用工具以及通过 A2A 与另一个 Agent 协作。MCP 更关注工具和资源接入。它让 Agent 知道有哪些能力、需要哪些参数以及调用后能够得到什么结果。A2A 面向独立 Agent 之间的协作。Agent Card 描述能力Task 表示正在处理的工作Message 负责过程沟通Artifact 承载正式结果。在完整的 Multi-Agent 系统中两者往往同时存在Agent A | A2A |Agent B | MCP |Tools / Data / APIs因此系统设计中首先需要分清的是当前对象是供 Agent 使用的一项能力还是一个能够独立接收并完成任务的 Agent。边界确定后就能够确定适合的交互方式。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 从 MCP 到 A2A：Agent 如何接入工具、与其他 Agent 协作
一个 Agent 完成任务后可以通过 Message 沟通过程信息通过 Task 表达正在处理的工作再通过 Artifact 交付正式结果。解决了“传什么”本文继续讨论 Agent 和外部能力之间以及 Agent 之间具体应以什么方式协作。比如一个 Agent 要查询数据库可以直接调用 API也可以通过 MCP 使用数据库工具如果它无法独立完成任务还可能把工作交给另一个专业 Agent。这几种情况看起来都是“调用”实际面对的问题并不相同。一、Agent 系统的三类交互方式先看 Agent 系统中最常见的三种情况。第一种是直接调用已有服务Agent | | REST / RPC v业务服务例如客服 Agent 查询订单GET /orders/{id}如果服务地址固定、接口明确直接使用 REST 或 RPC 已经足够。第二种是 Agent 使用外部工具Agent | | MCP vMCP Server | v数据库 / 搜索 / 文件 / 业务系统这里 Agent 关心的是当前有哪些工具每个工具有什么用途需要哪些参数会返回什么结果这属于 MCP 主要解决的范围。第三种是两个独立 Agent 之间协作Agent A | | A2A vAgent BAgent A 面对的已经不是一个简单工具而是另一个可以独立完成任务的 Agent。它可能有自己的模型、Prompt、工具和运行状态甚至由另一个团队开发和部署。此时需要了解的是对方具备哪些能力怎样提交任务任务当前是什么状态最终能够得到什么结果这属于 A2A 主要解决的范围。A2AAgent2Agent Protocol是由 Google 发起、现由 Agentic AI Foundation 推进的开放标准用于让不同厂商、框架和语言实现的 AI Agent 能够发现彼此能力、交换消息、委派和跟踪任务并交付结构化结果从而实现跨系统的 Agent 协作与互操作。因此REST/RPC、MCP 和 A2A 面向的是不同场景不需要互相替代。二、MCP 的工具接入机制假设我们正在开发一个客服 Agent它需要查询客户资料查询订单搜索知识库创建工单读取退款记录传统做法通常是分别调用各个系统的 API再在 Agent 中维护相应的函数和参数定义。调用工具较少时这种方式没有问题。随着工具越来越多会变得越来越不易维护。每个工具怎样描述自己的用途参数格式放在哪里不同 Agent 是否都要重复开发适配代码模型怎样知道当前有哪些工具可用MCP 为这些问题提供了一套统一方式。外部系统可以通过 MCP Server 暴露能力Agent 一侧通过 MCP Client 获取并使用这些能力。其调用流程如下Agent |MCP Client | | MCP vMCP Server | -- Tool A -- Tool B -- Tool C其中最值得关注的是 Tool。一个 Tool 通常需要说明工具名称工具用途输入参数返回结果例如一个查询发票的工具可以描述为{ name: get_invoice, description: 根据发票编号查询发票信息, inputSchema: { type: object, properties: { invoice_id: { type: string } }, required: [invoice_id] }}这里的name是工具名称description说明用途inputSchema定义参数结构。Agent 获取这些信息后就能知道当前有哪些工具以及调用时应该提供什么参数。因此MCP 能够让 Agent 以统一方式认识和使用外部能力。至于 Tool 背后调用 PostgreSQL、REST API还是企业内部服务并不是 Agent 必须了解的内容。三、A2A 的 Agent 协作机制假设客服 Agent 收到用户的问题我的退款已经申请五天了为什么还没有到账Customer Agent 可以处理普通客服问题但退款调查由 Billing Agent 负责。于是任务会转交给 Billing AgentCustomer Agent | | A2A vBilling AgentCustomer Agent 不需要知道 Billing Agent 使用什么模型也不需要了解它内部有哪些 Prompt 和工具。它更关心Billing Agent 是否能处理退款问题任务应该怎样提交当前处理到哪一步结束后会返回什么A2A 主要解决的正是这类 Agent 之间的协作问题。其中有几个核心概念Agent CardTaskMessageArtifact它们分别解决能力描述、任务状态、过程沟通和结果交付等问题。四、Agent Card 的能力描述A2A 使用 Agent Card 描述 Agent 对外提供的信息和能力。可以把它理解为 Agent 的服务说明。例如{ name: Billing Resolution Agent, description: 处理账单和退款相关问题, skills: [ { name: refund_investigation }, { name: invoice_query } ]}其中skills表示这个 Agent 对外提供的能力。真实的 Agent Card 还可以包含访问地址、支持的交互方式和安全相关信息。这样系统面对一个新任务时可以先确认有哪些 Agent各自擅长什么哪个 Agent 能处理当前任务确定目标之后再进入具体的任务交互。五、Task 的任务状态管理在 Agent 内部Tool 调用通常比较直接get_invoice(INV-1001) ↓返回发票信息但 Agent 接到的往往是一项需要持续处理的工作。例如调查这笔退款为什么迟迟没有到账检查支付记录、退款状态和客服历史最后给出处理结果。Billing Agent 可能需要连续访问多个系统中途还可能等待新的信息。因此A2A 使用 Task 表示一项正在处理的任务。一个 Task 可能经历类似这样的状态变化submitted | vworking | vcompleted有些任务还可能进入等待输入、失败或取消等状态。这里体现了 Agent 与普通函数调用的一个明显区别。函数通常关注请求 ↓结果Agent 协作还需要知道任务是否已经开始当前进行到哪一步是否需要额外信息最终是否完成对于耗时较长的任务系统还可以通过 Streaming、订阅状态变化或通知机制持续获得进展而不必一直等待一个同步请求返回。六、Artifact 的结果形态任务完成之后还需要交付结果。如果只是简单回复退款正在处理中Message 已经足够。但 Agent 的正式产出可能是一份报告、一段结构化数据甚至一个文件。例如 Billing Agent 最终生成Refund Investigation Report - 退款申请时间- 支付渠道状态- 当前退款状态- 异常原因- 建议处理方式这类可以继续被其他系统使用的正式结果可以通过 Artifact 表达。因此上述几个概念的职责如下Agent Card描述“我具备什么能力” Task表示“当前正在处理什么工作” Message承载任务过程中的沟通 Artifact保存任务产生的正式结果这也与上一篇中介绍的 Agent 交付内容完全一致。上一篇关注 Agent 之间交接什么这里进一步关注这些内容怎样在独立 Agent 之间流转。七、MCP 与 A2A 的组合结构MCP 和 A2A 并不冲突。它们很可能同时出现在一个系统中。继续使用前面的客服场景Customer Agent | | A2A vBilling Resolution Agent | ---- MCP ---- CRM | ---- MCP ---- Invoice Database | ---- MCP ---- Ticket System用户询问退款问题后Customer Agent 判断自己无法完成完整调查于是通过 A2A 把任务交给 Billing Resolution Agent。Customer Agent 关心Billing Agent 擅长什么怎样提交 Task当前处理到哪一步最终返回什么 ArtifactBilling Agent 接到任务后需要查询客户资料、发票和客服工单。这时它通过 MCP 使用对应工具get_customer()get_invoice()search_tickets()Billing Agent 关心有哪些 Tool每个 Tool 需要哪些参数调用后返回什么数据所以同一个系统中两种协议承担的是不同职责Agent | | A2A | Agent 之间的任务协作 vAgent | | MCP | Agent 对外部能力的使用 vTool / Data / API八、不同交互方式的适用边界实际工程中我们应根据不同场景选择不同的调用方式。场景适合方式主要原因同一程序中的固定逻辑函数 / 模块调用简单直接没有网络交互已知的内部业务服务REST / RPC地址和接口稳定Agent 使用搜索、数据库、文件MCP工具可以统一描述和使用独立 Agent 之间的任务委托A2A需要能力描述和任务状态跨团队的 Agent 协作A2A双方无需了解内部实现Agent 内部使用多个外部工具MCP工具可以独立接入和复用如果当前对象提供一个明确、清晰的能力例如查询订单搜索文档创建工单读取数据库它应该以 Tool 的方式实现。如果当前对象能够接收完整任务自行组织执行过程调用多个工具维护任务状态返回完整结果它应以 Agent 形式实现。总结Agent 系统中常见三种交互方式直接调用 API、通过 MCP 使用工具以及通过 A2A 与另一个 Agent 协作。MCP 更关注工具和资源接入。它让 Agent 知道有哪些能力、需要哪些参数以及调用后能够得到什么结果。A2A 面向独立 Agent 之间的协作。Agent Card 描述能力Task 表示正在处理的工作Message 负责过程沟通Artifact 承载正式结果。在完整的 Multi-Agent 系统中两者往往同时存在Agent A | A2A |Agent B | MCP |Tools / Data / APIs因此系统设计中首先需要分清的是当前对象是供 Agent 使用的一项能力还是一个能够独立接收并完成任务的 Agent。边界确定后就能够确定适合的交互方式。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】