从 Function Call 到 A2A：一文读懂 Agent 技术栈

Agent 现在已经成了 AI 工程里的高频词，但相关术语也越来越多。

当你开始系统学习时，通常会先遇到这几类问题：

• LLM 和 Agent 有什么区别？
• Agent 和 Workflow 有什么区别？
• Agent 有哪些工作模式？
• Function Call 是什么？
• MCP 是什么协议？
• Skills 是什么？
• Function Call、MCP、Skills 有什么区别？
• A2A 是什么协议？
• ACP 是什么协议？

这篇文章会把这些核心概念放到同一条脉络里，按从基础到进阶的顺序讲清楚。

LLM 和 Agent 有什么区别？

要搞懂 Agent，得先从 LLM 聊起，因为 Agent 本质上就是在 LLM 的基础上进化出来的。

什么是 LLM？

LLM，全称 Large Language Model，即大语言模型。

可以把它想象成一个读了互联网上几乎所有文字的超级学霸。它通过学习海量的文本数据，掌握了人类语言的各种规律和知识。我们平时用的 ChatGPT、Claude、DeepSeek、文心一言，底层都是大语言模型。

LLM 的工作原理说白了就是「预测下一个字」。你给它一段话，它会根据学到的语言规律，一个字一个字地往后接。听起来简单，但因为它学的数据量实在太大了，这种「接龙」的效果好到令人吃惊——能写文章、写代码、做翻译、回答各种专业问题。

LLM 的四大弊端

虽然 LLM 非常聪明，但它其实有点像是一个"有嘴没手"的顾问。

**只会「说」不会「做」。**你让 LLM「帮我订一张机票」，它会详细告诉你怎么订，但没法替你去携程下单。你让它「帮我把这个 Bug 修了」，它能给出改好的代码，但没法自己打开编辑器去改文件、跑测试。LLM 的能力被困在对话框里了，没法跟外部世界互动。

**没有「记忆」。**你跟 ChatGPT 聊了一下午，聊了很多个人情况和项目背景，第二天开一个新对话，它完全不记得你是谁。LLM 的记忆只限于当前这轮对话的上下文窗口，对话一结束，一切归零。

**不会用「工具」。**你问 LLM 今天上海天气怎么样，它只能根据训练数据里的旧知识来猜，而不是像你一样打开天气 App 查实时数据。LLM 本身不能上网搜索、不能查数据库、不能调 API，所有回答都来自「脑子里」已有的知识，而这些知识不仅有截止日期，还可能出错——也就是常说的「幻觉」问题。

**不会「规划」。**如果你给 LLM 一个复杂任务，比如「帮我做一份竞品分析报告」，它只能一次性生成一大段文字，不会像人一样先想想应该先搜集哪些信息、分析哪些维度、用什么框架来组织，然后一步一步去执行。LLM 是「被动响应型」的，问一句答一句，没法自主拆解任务、制定计划、分步执行。

Agent 是什么？

讲完弊端，问题就很自然了：有没有一种方式，能让 LLM 不仅会「说」，还能「做」？

这就是 Agent 要解决的问题。

Agent，翻译过来叫智能体。简单来说：Agent 就是 LLM 在循环中自主使用工具的系统。

这句话有三个关键词：「LLM」说明 Agent 的核心大脑还是大模型；「工具」说明它能调用外部能力；「循环」说明它不是一问一答就结束，而是会不断思考、行动、观察结果、再思考，直到任务完成。

打个比方——如果 LLM 是一个只会给你建议的顾问，你问他「怎么装修房子」，他能讲一大堆方案但绝不会亲自动手；那 Agent 就是一个能动手干活的项目经理，你说「帮我把房子装修好」，他会自己去找装修队、买材料、盯进度、解决问题，直到装修完成。

Agent 怎么解决 LLM 的弊端？

理解了上面的比喻，答案就很清楚了：

• 针对「只会说不会做」：引入工具调用能力，可以调用搜索引擎、数据库、API、代码执行器等执行真实操作。
• 针对「没有记忆」：配备记忆系统，包括当前任务上下文的短期记忆和跨对话保留的长期记忆。
• 针对「不会用工具」：业界推出了 MCP 等标准化协议来统一工具接入方式，后面会详细讲。
• 针对「不会规划」：具备任务拆解和规划能力，能把大目标分解成小步骤，逐步执行。

Agent 的核心组成

一个完整的 Agent 由四个模块组合而成：

• 大脑（LLM）：负责理解意图、推理判断、决定下一步行动。
• 规划模块：负责把复杂任务拆解成可执行的步骤。
• 记忆模块：负责存储和检索信息，让 Agent 在长时间任务中保持连贯。
• 工具模块：Agent 的「手和脚」，让它能跟外部世界互动。

用一个实际例子来感受——

假设你对 Agent 说：「帮我查一下下周三上海的天气，如果不下雨就在日历上安排一个户外团建。」

如果是 LLM，它只会告诉你「你可以通过天气 App 查看天气，然后在日历上创建事件」。

而 Agent 会：直接调用天气 API 查到下周三多云 25°C 无降雨 → 自动调用日历 API 创建团建事件 → 最后告诉你「已安排好了」。

LLM 告诉你「怎么做」，Agent 直接帮你「做完了」。这就是本质区别。

Agent 和 Workflow 有什么区别？

搞懂了 LLM 和 Agent 的区别之后，还有另一个容易搞混的概念：Workflow（工作流）。很多人把它们混为一谈，但设计理念其实完全不同。

用一个场景来感受区别

假设有一个任务：处理客户的退款申请。

Workflow 的做法是开发者在代码里提前写好整个流程：

• 第一步：接收申请
• 第二步：调用 LLM 提取关键信息
• 第三步：查数据库获取订单详情
• 第四步：调用 LLM 判断是否符合退款政策
• 第五步：执行退款或生成拒绝邮件
• 第六步：发送通知

每一步做什么、接下来走哪条路，全都在代码里写死了。LLM 只是在某些步骤中被召唤出来做理解和判断。

Agent 的做法完全不同——它收到「处理这个退款申请」的任务后，自己来决定怎么做：先看看申请写了什么 → 觉得需要查一下订单信息 → 发现情况有点特殊就去搜索退款政策文档 → 推理判断后决定执行退款 → 最后给客户发邮件通知。整个过程中，每一步做什么都是 Agent 自己决定的，不是代码预先规定的。

两者的定义

• Workflow：LLM 和工具通过预定义的代码路径进行编排的系统。
• Agent：LLM 动态主导自身流程与工具调用的系统，自主决定如何完成任务。

翻译成大白话：Workflow 是「我告诉你每一步该做什么」，Agent 是「我告诉你目标，你自己决定怎么做」。

可以这样类比——Workflow 像工厂流水线，每个工位做什么、零件从哪来到哪去，全都是提前设计好的，工人只需要在指定工位上完成指定动作。Agent 则像一个自主工作的项目经理，老板只说「把这件事搞定」，然后他自己去调研、制定计划、协调资源、推进执行。

核心区别

两者最核心的区别在于「谁在控制流程」。

Workflow 的控制权在代码手里，流程确定、可预测、可复现，但灵活性差。Agent 的控制权在 LLM 手里，行为动态、灵活、能适应变化，但相应地也带来了不确定性。

从成本看，Workflow 因为流程固定，token 消耗大约是 Agent 的四分之一。从可靠性看，Workflow 出问题容易定位，Agent 决策路径不确定，调试更困难。

先看一张对比表，区别会更直观：

什么时候用 Workflow，什么时候用 Agent？

Anthropic 给了一个很实用的建议：从最简单的方案开始，只在明确需要时才增加复杂度。

• 任务步骤固定、可以提前规划好，或者对可靠性要求很高（金融交易、医疗系统）→ 用 Workflow。
• 任务开放式、无法预知所有步骤，或者需要灵活应对意外情况 → 用 Agent。

实际生产环境中，最常见的是混合架构。正如 LangChain 所说：“大多数生产中的 Agent 系统其实是 Workflow 和 Agent 的组合。”

比如一个智能客服系统，整体流程用 Workflow 控制（接收工单 → 分类 → 处理 → 回复），但在「处理」环节遇到复杂问题时，启动一个 Agent 来自主分析和解决。

两者不是对立关系，更像是工具箱里的锤子和螺丝刀——配合使用，而非互相替代。

Agent 有什么工作模式？

了解了 Agent 是什么之后，下一个问题就是：Agent 到底怎么「干活」？跟人干活有不同的方式一样，Agent 也有不同的工作模式。

模式一：ReAct（边想边做）

ReAct 是目前最经典、最基础的 Agent 工作模式，名字来源于 Reasoning + Acting（推理 + 行动）。几乎所有主流 Agent 框架底层都在用它。

核心思想非常简单：Agent 在思考和行动之间不断交替，形成一个三步循环——

1. 思考（Thought）：分析当前情况，决定下一步做什么。
2. 行动（Action）：调用一个工具来执行。
3. 观察（Observation）：查看工具返回的结果。

然后回到思考，如此循环，直到任务完成。

打个生活化的比方——想象收拾行李准备出差：先想「我要去上海三天，先看看天气怎么样」→ 打开手机查天气预报，发现会下雨、气温 15-20°C → 想「得带伞和外套」→ 找出来放进行李箱 → 想「还得确认酒店」→ 打开 App 检查预订信息…… 这就是 ReAct 的精髓：每一步都先想后做，做完看结果，再决定下一步。

优点：透明可审计、灵活适应、通用性强。缺点：token 消耗大（每一步都要完整推理一次），有时会陷入循环反复执行相同动作。

模式二：Plan-and-Execute（先想好再做）

如果说 ReAct 是「边想边做」，Plan-and-Execute 就是「先想好再做」。

分为两个阶段——规划阶段，Agent 先把完整的执行计划想清楚；执行阶段，按计划逐步完成，不用每步都重新思考全局。

用出差例子对比：ReAct 是「查天气 → 想带什么 → 找衣服 → 想还缺什么 → 查酒店 → 想还要准备什么……」，每一步都重新审视全局。Plan-and-Execute 是先列一个清单（查天气、准备衣物、确认酒店、准备证件、叫车），然后逐项打勾执行。

最大优势是省钱：规划只做一次，执行阶段不用反复推理，token 消耗约为 ReAct 的五分之一。缺点是不够灵活，如果中途情况变了，原计划可能失效。因此实践中常加入「重新规划检查点」，每隔几步检查一下计划是否还靠谱。

模式三：Reflection（做完再检查）

反思模式的核心思想是 Agent 完成任务后不急着交付，先自我检查一遍。就像写文章不会直接发出去，会再通读一遍、改一改、润色一下。

实现方式通常有两种：

• 自我反思：同一个 Agent 完成后切换到「审查者」角色审视自己的输出，发现问题就修改，再审查，直到满意。
• 双 Agent 对话：一个负责生成、一个负责评审，来回迭代直到评审方满意，类似代码的 Code Review 过程。特别适合对质量要求高的场景，如代码生成、法律文书、学术论文等。

模式四：Multi-Agent（团队协作）

当任务太复杂、一个 Agent 搞不定的时候，答案是派一个团队。

Multi-Agent 模式让多个专业化的 Agent 各司其职——一个负责规划、一个负责搜集信息、一个负责写代码、一个负责测试——通过协作完成复杂任务。

这就像一个项目团队，有产品经理、研究员、开发者、测试员，各自做自己擅长的事。目前主流多 Agent 框架包括 LangGraph、CrewAI、OpenAI Agents SDK 和微软的 AutoGen 等。

不过 Anthropic 提醒：**不要过早引入多 Agent 架构。**很多时候一个强大的单 Agent 就够用了。只有任务确实需要拆分成多个并行子任务时，多 Agent 才值得引入。

最后总结：这几种模式不是互斥的，实际中往往是组合使用。一个多 Agent 系统中，每个 Agent 内部可能用 ReAct，整体协作用 Multi-Agent，最后还有一个 Reflection 环节检查质量。选择哪种模式，取决于任务特点和对灵活性、成本、质量的优先级排序。

Function Call 是什么？

前面聊 Agent 时反复提到一个词——「工具调用」。Agent 能查天气、能搜索信息、能操作数据库，这些能力是怎么实现的？

答案就是 Function Call（函数调用）。

从「只会说话」到「能做事情」

2023 年之前，大语言模型只能做一件事：生成文本。你说它说的再好听，也只是「说」，不能「做」。

Function Call 的出现彻底改变了这个局面。它是 OpenAI 在 2023 年 6 月率先推出的一种能力，简单来说就是让 LLM 不仅能生成文字，还能告诉外部程序「我想调用某个函数，参数是这些」。

打个比方——没有 Function Call 之前，LLM 就像一个只能写字的人，你问他天气，他只能根据记忆回答「上海通常三月份比较潮湿」。有了 Function Call 之后，这个人学会了「打电话」：你问他天气，他会拿起电话拨给天气台（调用天气 API），听到实时数据后再告诉你「今天上海 22°C，多云」。

Function Call 的工作原理

Function Call 的工作流程分四步：

第一步，定义函数。 开发者预先告诉 LLM「你手边有哪些工具可以用」，用 JSON 格式描述每个函数的名字、功能说明和参数。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "获取指定城市的实时天气",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {
              "type": "string",
              "description": "城市名称，比如：上海"
            }
          },
          "required": ["city"]
        }
      }
    }
  ]
}

第二步，模型判断。 用户提问后，LLM 分析用户意图，自己判断「需要调用哪个函数」。如果用户问「上海今天天气如何」，LLM 会决定调用 get_weather，并生成参数 {"city": "上海"}。

第三步，执行函数。 这一步非常关键——LLM 自己并不执行函数。它只是输出了「我想调用这个函数，参数是这些」的结构化指令。真正执行函数的是你的应用程序。你的代码拿到指令后，解析出 city=上海，去实际调用天气 API，拿到结果比如「22°C，多云」。

第四步，生成回答。 你的代码把真实数据再次发给 LLM。LLM 有了客观数据支撑，用自然语言回复：「今天上海天气是多云，气温大约 22 摄氏度。」

为什么 Function Call 这么重要？

可能你会觉得，不就是「让 LLM 调 API」吗？

关键在于它解决了两个核心问题：

• 「什么时候调用」的判断问题：LLM 能根据自然语言意图，自动判断需不需要调用工具、调用哪个工具，不需要写复杂的条件判断逻辑。
• 「传什么参数」的提取问题：LLM 能从自然语言中提取结构化参数。用户说"帮我查一下北京后天的天气"，LLM 能自动提取出 city=北京 和 date=后天。

这两个能力加在一起，把 LLM 从「只会聊天的文本生成器」变成了「能理解意图并驱动外部系统的决策引擎」。

而这正是 Agent 的基石。Function Call 是 Agent 能力的最底层技术基础——没有它，Agent 就无法调用工具，也就没法真正「做事」。

目前几乎所有主流大模型都支持 Function Call，包括 OpenAI 的 GPT 系列、Anthropic 的 Claude 系列、Google 的 Gemini 系列，以及 Llama 等开源模型。各家 API 格式略有不同，但核心原理一致。

Function Call 和 Agent 的关系

Function Call 是一次性的「单步调用」——LLM 判断需要调用一个函数，调用完就结束。Agent 则是「循环调用」——在一个循环中反复使用 Function Call，每次调用后观察结果，再决定下一步要不要继续调用。

所以 Function Call 是 Agent 的「原子操作」，Agent 是 Function Call 的「高级编排」。一个 Agent 完成一个复杂任务，可能需要连续十几次 Function Call。

MCP 是什么协议？

前面讲了 Function Call 让 LLM 能调用工具。但随着 Agent 需要连接的工具和服务越来越多，一个新问题出现了：集成太麻烦。

Function Call 的集成困境

假设你开发了一个 Agent，需要连 Slack 发消息、查 Google Drive 的文档、读 GitHub 的代码、查 Postgres 数据库。

用 Function Call 的方式，你需要为每个服务单独写适配代码——为 Slack 写一套、为 Google Drive 写一套、为 GitHub 写一套、为数据库又写一套。

如果你有 N 个 AI 应用，要对接 M 个外部服务，就需要写 N × M 个定制集成。这在实际中完全不可扩展。更头疼的是，每个 LLM 厂商的 Function Call 格式还不一样——OpenAI 用 tool_calls，Anthropic 用 tool_use content block，参数结构也有差异。

MCP 的诞生

为了解决这个问题，Anthropic 在 2024 年 11 月开源了 MCP（Model Context Protocol，模型上下文协议）。可以把它理解为「AI 界的 USB-C 接口」。

以前不同的手机、电脑、设备各自用不同的充电线和接口，非常混乱。

USB-C 统一了这一切——一根线就能充电、传数据、接显示器。MCP 做的是同样的事：提供统一标准，让任何 AI 应用都能用同一种方式连接任何外部工具和数据源。

MCP 的架构

MCP 的架构很清晰，主要有三个角色：

• MCP Host（宿主）：你使用的 AI 应用，如 Claude Desktop、Cursor 编辑器、自研的 Agent 应用。它是整个交互的发起方。
• MCP Client（客户端）：住在 Host 里面，负责跟 MCP Server 通信。相当于"翻译官"——Host 想要什么能力，Client 就去跟对应的 Server 沟通。
• MCP Server（服务端）：负责对外暴露具体的工具能力和数据资源。比如 GitHub MCP Server 提供"搜索代码"“创建 Issue"“查看 PR"等工具；Slack MCP Server 提供"发送消息"“搜索频道"等工具。

整个流程：用户提问 → AI 应用（Host）通过 MCP Client 发现可用工具 → AI 决定调用某工具 → MCP Client 向对应 MCP Server 发请求 → Server 执行操作返回结果 → AI 基于结果生成回答。

MCP 解决了什么问题？

最核心的是把 N × M 的集成问题变成了 N + M 的问题。

以前每个 AI 应用要跟每个服务单独对接；现在每个 AI 应用只要支持 MCP 协议（实现一次 Client），每个服务只要提供一个 MCP Server（实现一次 Server），双方就能自动对接。新增一个服务不需要改任何 AI 应用的代码，新增一个 AI 应用也不需要改任何服务的代码。

而且 MCP Server 暴露的工具是可发现的——AI 应用启动时能自动查询有哪些 MCP Server 可用、每个 Server 提供哪些工具、每个工具的参数是什么。这意味着 Agent 可以在运行时动态发现新能力，而不是只能用开发者写死的那些函数。

Skills 是什么？

Function Call 让 Agent 能调用函数，MCP 让 Agent 用统一标准连接工具。但还有一个问题：Agent 知道怎么调用工具了，但它知道在什么场景下该用什么方法吗？

打个比方——给实习生一把锤子、一把螺丝刀、一个扳手（工具），但他可能还是不知道「修一把椅子应该先拧螺丝还是先敲钉子、用什么顺序和方法」。他缺的不是工具，而是经验和方法论，也就是「怎么做」的知识。

这就是 Skills（技能）要解决的问题。

Skills 是什么？

Skills 是一种自然语言指令文件，通常是 Markdown 格式，用来教 Agent「在什么场景下、按照什么方法、遵循什么规范来完成特定任务」。

在 Claude Code、Cursor 等 AI 工具中，Skills 通常以 SKILL.md 文件的形式存在。结构很简单：顶部是 YAML 格式的元数据，声明激活条件；下面是具体的行为指令，用自然语言写成。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

---
name: Code_Review_Expert
description: 当用户要求进行代码审查时，自动触发此技能。
triggers:
  - "帮我 review 一下这段代码"
  - "代码审查"
---

# 身份设定
你是一个拥有 10 年开发经验的资深后端架构师，极其看重代码的可读性、性能和安全性。

# 审查工作流
进行代码审查时，必须严格按照以下步骤排查：
1. 看结构：检查代码是否符合单一职责原则，有没有超过 100 行的超长方法。
2. 查漏洞：重点检查是否存在 SQL 注入风险、越权访问风险或空指针异常风险。
3. 审性能：是否有在 for 循环里查数据库的操作？是否有流对象没有及时 close 释放？
4. 给方案：不能只挑毛病，必须针对每个问题给出具体的修改建议，并附带优化后的代码片段。

# 输出规范
语气专业、直接，不要说废话。输出 Markdown 格式的审查报告，分点列出问题和修改方案。

一个直观的比喻

如果说 MCP 给了 Agent 一个装满工具的厨房——有刀、有锅、有烤箱、有各种调料。

那 Skills 就是一本菜谱，告诉 Agent「做红烧肉要先焯水再炒糖色，加水炖 40 分钟，火候要先大后小」。

厨房（MCP）解决的是"能做什么"的问题，菜谱（Skills）解决的是"该怎么做"的问题。一个完整的 Agent 两者都需要。

Skills 的工作方式

Skills 的工作方式跟 Function Call 和 MCP 有本质不同。Function Call 和 MCP 都是让 Agent「执行外部操作」——调用 API、查询数据库、发送消息，操作发生在 Agent 外部。

而 Skill 不只是告诉 Agent 怎么想，还能指导它怎么做——可以在 SKILL.md 中通过 allowed-tools 声明需要哪些工具，也可以打包可执行脚本，甚至可以指导 Agent 去调用 MCP 工具或发起 Function Call。

具体流程：Agent 启动时扫描可用的 Skills 列表 → 用户提出请求时判断有没有匹配的 Skill → 有则把 Skill 内容加载到上下文中 → 按 Skill 中的指令思考和行动。

这就像给 Agent「临时注入了一段专业经验」。没加载 Skill 之前只有通用能力；加载了特定 Skill 之后，在这个领域就变成了专家。

Skills 的价值

Skills 的核心价值在于将专业知识和最佳实践编码成可复用的模块。

• 「代码审查」Skill 定义审查流程、关注点（安全性、性能、可读性）、输出格式。
• 「SQL 优化」Skill 编码 DBA 的优化经验：先看执行计划、关注全表扫描、检查索引使用。
• 「客服回复」Skill 定义品牌话术风格、常见问题处理流程、升级规则。

这些经验以前都在人的脑子里，现在可以写成 Skill 文件让 Agent 使用。而且 Skills 可以共享和复用——写了一个好的 Skill，团队里所有人的 Agent 都能用上。

Function Call、MCP、Skills 有什么区别？

前面分别讲了 Function Call、MCP 和 Skills，它们不都是「让 Agent 更强」的手段吗？到底有什么区别？用一个统一比喻来串起来就清楚了。

一个统一的比喻

把 Agent 想象成新入职的员工。

• Function Call = 打电话的能力。员工学会了怎么拿起电话、拨号、跟对方沟通。这是最基础的能力，没有它就没法跟外部世界互动。
• MCP = 公司的通讯录和电话系统。统一管理所有外部联系方式（供应商、合作伙伴、服务商），不需要自己记住每个人的电话号码，直接查通讯录就行。新增一个联系人只需加到通讯录，所有员工都能用。
• Skills = 岗位培训手册。告诉员工「遇到客户投诉应该按什么流程处理」「做报表应该用什么模板和方法」「跟供应商谈判要注意哪些要点」。教的是做事的方法和规范，而不是打电话的技术。

三者的本质区别

从更技术的角度看：

三者是什么关系？

它们不是竞争关系，而是分层互补的。

Function Call 是底层基础。 MCP 建立在 Function Call 之上，提供了标准化包装。当 Agent 通过 MCP 调用工具时，底层其实还是在做 Function Call，只不过格式和通信方式被 MCP 统一了。

Skills 则在另一个维度上工作——不参与工具调用过程，而是指导 Agent「什么时候该调用工具」「用什么策略来完成任务」。

用做饭来总结：Function Call 是「会使用厨具的能力」（会开火、会切菜），MCP 是「一个设备齐全且标准化的厨房」（所有厨具放在该放的地方，用统一的方式使用），Skills 是「菜谱和厨艺经验」（知道做什么菜、怎么做、火候多大）。三者结合，才能做出一桌好菜。

A2A 是什么协议？

MCP 解决了 Agent 跟工具之间的连接问题。但还有一个问题它没有覆盖：如果有多个 Agent 需要互相协作，它们之间怎么通信？

为什么需要 A2A？

想象一个大型企业里有多个 AI Agent——HR 部门有招聘 Agent，IT 部门有运维 Agent，财务部门有报销 Agent。这些 Agent 可能由不同团队开发，使用不同框架（LangGraph、CrewAI、OpenAI Agents SDK 等）。

当一个新员工入职时，HR Agent 要处理入职手续，IT Agent 要配置电脑和账号，财务 Agent 要设置薪资账户。三个 Agent 需要协作，但它们互相不认识，也不知道对方会什么、怎么沟通。

MCP 解决不了这个问题——因为 MCP 处理的是「Agent 调用数据库」「Agent 发送邮件」这类 Agent 与工具的交互。Agent 与 Agent 之间的协作，需要一个全新的协议。

这就是 A2A（Agent-to-Agent）协议诞生背景。

A2A 是什么？

A2A 是 Google 在 2025 年 4 月 Google Cloud Next 大会上发布的开放协议，全称 Agent-to-Agent Protocol。联合了超过 50 家合作伙伴共同推出，包括 Atlassian、Salesforce、SAP、MongoDB、LangChain 等。

A2A 定义了一套标准，让不同的 AI Agent 能够互相发现、互相通信、互相委派任务，不管这些 Agent 用什么框架开发、运行在什么平台上。

A2A 的核心概念

Agent Card（智能体名片）：每个支持 A2A 的 Agent 都会发布一个 JSON 格式的"名片”，描述自己的身份、能力、擅长领域、交互方式、认证要求等。其他 Agent 通过读取名片了解「这个 Agent 会什么，我能请它帮什么忙」。这就像 LinkedIn 上的简历，知道对方的技能后才决定要不要合作。

任务（Task）：A2A 中的所有协作都围绕「任务」展开。Client Agent（发起方）创建任务，发送给 Remote Agent（执行方）。任务有完整生命周期——创建 → 处理中 → 完成/失败，每个状态变化都有明确定义，双方能清楚跟踪任务进展。

消息和制品（Message & Artifact）：Agent 之间通过消息沟通过程信息，通过制品传递最终结果。比如研究 Agent 完成分析后，把分析报告作为制品返回给请求方。

A2A 和 MCP 的关系

这个概念非常重要，很多人会搞混。

简单来说：MCP 是「竖向」的，处理 Agent 到工具的连接；A2A 是「横向」的，处理 Agent 到 Agent 的协作。

两者是互补关系，被明确设计为可以共同使用。在一个典型的多 Agent 系统中，编排 Agent 通过 A2A 把任务委派给不同的专业 Agent，而每个专业 Agent 内部通过 MCP 来连接自己需要的工具。协议边界很清晰：Agent 之间通信走 A2A，Agent 调用工具走 MCP。

A2A 的技术特点

• 基于现有 Web 标准：HTTP 传输、JSON 消息格式、SSE 实时流式通信。不需要引入新基础设施，现有 Web 技术栈直接支持。
• 支持异步和长任务：Agent 间协作往往不是一瞬间能完成的，A2A 有完整的任务状态查询、进度更新、断线重连支持。
• 模态无关：Agent 之间不仅能传递文本，还能交换音频、视频、图像、结构化数据等各种格式。

A2A 的生态现状

截至 2026 年初，A2A 已获得相当广泛的业界认可。背后有 Google 和 50 多家合作伙伴推动，填补了 MCP 明确不处理的 Agent 间协作空白，正在快速成为该领域标准。

ACP 是什么协议？

这里的 ACP，需要先澄清一下：本文说的 ACP 指的是 Agent Client Protocol（由 Zed 发起），不是其他同名缩写。

它解决的问题也很明确：让编辑器/IDE 和编码 Agent 可以标准化互联。

ACP 的诞生

ACP 由 Zed 团队提出并开源，目标是把「编辑器接 Agent」这件事做成像 LSP 一样的通用标准。

如果没有 ACP，现实通常是这样：

• 每个编辑器都要给每个 Agent 单独做适配；
• 每个 Agent 也要给每个编辑器实现专有接口；
• 最终形成大量重复集成工作，用户也被生态绑定。

ACP 的核心价值，就是把这种 N × M 的接入关系，变成更可扩展的标准接口关系。

ACP 的核心设计

从官方文档看，ACP 有几个关键特征：

第一，Editor-First 场景。 ACP 假设用户主要在编辑器里工作，Agent 是被拉进来协助编码、审查和修改工程的。

第二，本地与远程双场景。

• 本地 Agent：通常作为编辑器子进程，通过 JSON-RPC over stdio 通信；
• 远程 Agent：可通过 HTTP 或 WebSocket 接入（官方仍在持续完善远程场景支持）。

第三，复用 MCP 的数据表示。 官方明确提到，ACP 在可复用处会沿用 MCP 的 JSON 表示，同时补充了编辑器场景特有能力（比如代码 diff 等交互元素）。

第四，强调互操作生态。 ACP 的定位不是绑定某个模型或某个编辑器，而是让「任意 ACP Agent」与「任意 ACP Client（编辑器/IDE）」可以互通。

ACP 的架构

ACP 可以理解成一个二层结构：

• Client 侧（编辑器/IDE）：负责会话 UI、文件上下文、用户交互入口；
• Agent 侧（本地或远程）：负责推理、工具调用与执行，再把结果回传给编辑器。

一句话类比：MCP 像给 Agent 接外设，ACP 像给编辑器接不同品牌的 Agent。

ACP 与 A2A、MCP 的关系

三者的定位非常清晰，各管一段：

MCP 让 Agent 能调用数据库、搜索引擎、API 等外部工具，属于能力层。

A2A 关注的是 Agent 跟 Agent 协作；ACP 关注的是 编辑器跟 Agent 互联。两者不是替代关系，而是两个正交维度。

从更宏观的视角看，整个 Agent 协议生态正在形成清晰的三层格局：

1. 底层能力层：Function Call，为 LLM 提供调用外部函数的基础能力。
2. 工具连接层：MCP，标准化 Agent 与工具的连接方式。
3. 协作与交互层：A2A 负责 Agent 间协作，ACP 负责编辑器与 Agent 的标准化互联。

三层协议各司其职、互补共存，共同支撑起 Agent 技术的完整基础设施。

总结

到这里，九个核心概念就都讲清楚了。快速回顾一下全文脉络：

从 LLM 到 Agent

LLM 是超级强大的文本生成引擎，但有「不能做事、没有记忆、不会用工具、不会规划」四大弊端。Agent 在 LLM 基础上加入工具、记忆、规划能力，从「回答问题」进化到「完成任务」。Workflow 与 Agent 的区别在于「谁控制流程」——Workflow 由代码控制，Agent 由 LLM 自主决策。

Agent 的工作模式

四种模式：ReAct（边想边做）、Plan-and-Execute（先想后做）、Reflection（做完检查）、Multi-Agent（团队协作）。实际中往往组合使用，选择取决于任务特点和成本考量。

三层技术栈

• Function Call（能力层）：让 LLM 调用外部函数，是 Agent 的「原子操作」。
• MCP（工具连接层）：统一 Agent 与工具的连接标准，被称为「AI 界的 USB-C」。
• Skills（知识层）：教 Agent 做事的方法和规范，解决「怎么做」的问题。

三者分别对应能力层、连接层、知识层，分层互补，缺一不可。

Agent 间协作

• A2A 负责 Agent 与 Agent 的任务协作与通信。
• ACP（Agent Client Protocol） 负责编辑器/IDE 与 Agent 的标准化连接。
• MCP 竖向连接工具，A2A 横向连接 Agent，ACP 横向连接编辑器与 Agent，三者互补。

用一句话串起来

• 一个 Agent 内部通过 Function Call 调用外部函数。
• Agent 通过 MCP 用统一标准连接各种工具和服务。
• Agent 通过 Skills 获得领域专业知识和做事方法论。
• Agent 之间通过 A2A 互相发现、委派任务、协作完成复杂工作。
• 编辑器通过 ACP 接入不同 Agent，把 Agent 能力带进统一的开发工作台。