mcp a2a acp ai-agents protocols security

实际应用中的MCP、A2A和ACP：银行如何将工具与智能体相互连接。

通过一名银行助理处理欺诈和贷款的案例，展示MCP、A2A和ACP如何分工实现模型与工具、智能体之间的连接。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 17 分钟3911 词

来源: MCP, A2A, and ACP Explained: The Protocols Defining AI Agent Interoperability in 2026

过去几年中，各类模型授权协议的制定都遵循着相同的模式：先是出现更强大的模型，它能编写更优的代码、进行更清晰的推理，并处理更长的上下文信息。但几周之后，人们的热情就会消退，因为仅靠聊天窗口中的智能模型依然无法查询客户的账户余额、冻结可疑交易或调取申请人的信用记录。真正的瓶颈从来不是智能本身，而是连接问题。

工程方面的努力已从单纯提升模型规模转向协议设计。有三项规范专门针对连接问题：MCP（模型上下文协议）、A2A（代理对代理协议）以及ACP（代理通信协议）。这些规范共同决定了模型如何访问工具、一个代理如何与另一个代理交互，以及多个代理如何协作而不陷入混乱。

以下所有内容都可以通过一个例子来说明：某银行正在开发一款人工智能助手，该助手需要能够识别欺诈行为、评估贷款申请并与核心银行系统进行交互，同时还要具备足够的可审计性以满足监管要求。

为何单纯的模型需要协议

单独使用时，语言模型仅能预测文本。如果询问某客户的账户本月是否有可疑活动，它要么会拒绝回答，要么会给出流畅但错误的答案，因为真实的交易记录不在它的视野范围内。

早期的解决方案是将模型直接连接到一个个REST API上。用于欺诈检测的助手需要为核心银行API编写定制代码，CRM系统也需要额外代码，案例管理更是如此。小型系统尚能应付，而大型系统则遇到了三个问题：

没有任何可复用的资源。尽管欺诈检测团队和贷款团队都需要相同的交易数据，但欺诈检测团队的核心银行接口对贷款团队毫无用处，因此每个项目都得从零开始。
请求之间状态会丢失。API按设计就是无状态的。有位分析师先调取了某客户的交易记录，过了一会儿又询问这些“数据”中是否有异常，结果发现，除非工程师手动构建内存层，否则普通的API集成无法在两次请求之间保持关联。
权限管理十分混乱。每项银行操作都需要进行权限检查，并为审计人员留下记录。初级欺诈分析师可以查看交易历史，但却无权批准撤销电汇操作。为每个API单独编写代码使得这类精细的规则很容易出错，也难以向审计人员说明。

一种协议即可完成一次合同结算。由于MCP提供了统一的接口，各银行无需自行设计模型调用欺诈检测引擎的方法。同样，由于A2A提供了相应的机制，各团队也无需自行设计将案件从欺诈处理人员转交给合规处理人员的方式。HTTP为网络应用解决了这一问题，SQL则为数据库解决了同类问题：它们都是让独立开发的系统能够协同工作的通用语言。

设计的五个阶段

在银行业及其他领域，系统设计已经经历了五个阶段。

普通的大型语言模型。该模型仅依据训练数据来回答问题。它能够解释什么是客户身份核实，但却无法判断某个特定客户的资料是否符合银行的客户身份核实规则，因为它从未见过该客户的记录。
检索增强生成。该模型可连接到文档存储系统，如合规手册及过往的监管指南，因此答案基于当前组织内部的专属内容，而非通用的训练知识。
智能体。该模型不仅能检索信息，还能执行操作。现在的合规助手不仅可以引用KYC政策，还能对照存档的客户文件进行核查，并标记出任何不符之处。
多智能体系统。若让一个智能体同时处理欺诈检测、审批及客户沟通等工作，不仅会降低可靠性，还难以进行有效管理。因此这些任务会被分配给不同的专家，比如专门处理欺诈检测的智能体、贷款审批智能体以及客户沟通智能体，每个智能体都专注于某一特定领域。
协议。当存在大量智能体和系统时，就需要一种标准方式让它们能够互相发现、共享上下文并安全地通信。MCP、A2A和ACP正是为满足这一需求而存在的。

目前大多数银行处于第三阶段和第四阶段之间。虽然存在独立的智能体，通常每个用例一个，但由于缺乏统一的协议，每个新智能体仍需要额外的定制化集成。而协议的作用就在于填补这一空白。

工具调用——MCP的基础层

在MCP出现之前，采用的是工具调用，也即函数调用。它允许模型请求执行外部操作而不仅仅是生成文本，MCP正是建立在这一基础之上的。

其机制相当简单。对于每一种可用的工具，开发者都会编写一个 JSON Schema，其中包含工具名称、描述以及参数类型，然后将其与提示词一同发送给模型。当模型判断需要使用某工具时，它不会执行任何操作。模型的输出是一个结构化的 JSON 对象，其中列出了工具名称并提供了参数，随后上层应用程序会调用该函数并将结果返回给模型。一个银行相关工具的 JSON Schema 长这样：

{
  "name": "get_customer_transactions",
  "description": "Returns transactions for a customer above a given amount, within a date range",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string"},
      "min_amount": {"type": "number"},
      "start_date": {"type": "string", "format": "date"},
      "end_date": {"type": "string", "format": "date"}
    },
    "required": ["customer_id", "start_date", "end_date"]
  }
}

假设欺诈分析师要求查看某客户近期的大额交易，即过去一个月内金额超过五千美元的交易。系统不会依赖内存来回答此请求，而是会调用get_customer_transactions函数，传入客户ID、金额阈值以及时间范围。随后应用程序会查询核心银行数据库以获取真实数据，将查询结果返回，模型再将这些数据转化为易于理解的摘要。

简单的工具调用方式适用于仅包含少数固定功能模块的单一模型。但当核心银行系统、欺诈检测系统、CRM系统以及文档系统中散布着数十种工具时，问题就出现了——要么需要在不重新部署每个客户端的情况下添加新工具，要么欺诈检测与贷款审批助手必须安全地共享同一工具。MCP正是为解决这些问题而设计的。

MCP详解

MCP于2024年底由Anthropic推出，作为一种将人工智能应用与外部系统相连的开放标准。可以将其视为一种通用适配器。此前，要将银行助手与核心银行系统、欺诈检测引擎以及客户关系管理系统连接起来，需要三次互不兼容的集成操作。而现在，任何符合MCP标准的客户端都能与任何符合MCP标准的服务器进行通信，就如同任何USB设备都能插入任何USB端口一样。

M乘以N的运算

其背后的问题属于组合数学范畴。将M种工具与N种应用连接起来会形成一张矩阵，而随着这两个数字的增大，这张矩阵会变得难以管理。如果一家银行拥有五个内部系统以及四种助手（欺诈检测、贷款处理、客户服务、合规管理），那么就需要多达二十个定制化的连接器。而标准协议则将这一数字降至五加四，因为每个系统及每个助手只需实现一次MCP标准即可。

三种角色

主机：用户实际看到的AI应用程序，例如欺诈分析助手界面。
客户端：主机内的一个组件，负责管理与单个MCP服务器的连接并处理协议层通信。
服务器：提供功能的一方，即数据或操作。银行可能在核心银行系统前部署一台服务器，在欺诈检测引擎前部署另一台，在文档存储库前再部署一台，每台服务器都由负责对应系统的团队维护。

服务器可提供的三种基本功能

资源：包含模型可纳入上下文的只读数据，例如账户对账单或身份验证文档的状态。与GET请求类似，它们仅用于提供信息而不会改变任何内容。

工具用于执行特定操作，比如冻结账户的某部分功能或将案件转交合规官员处理。与POST请求类似，它们会改变系统状态，正因如此，在银行系统中这类工具最需要人工审批环节。

提示词是可重复使用的参数化模板，用于引导模型生成结构完整的请求。例如，有一种标准的欺诈升级提示词，所有分析助手都会以相同方式使用它，因此无需每个团队都维护略有差异的版本。

采样、发现与传输

采样功能允许服务器向主机上的大语言模型请求内容补全，借助模型的推理能力完成子任务。文档存储服务器可能会利用这一功能让模型先总结冗长的贷款协议，然后再将其返回，由人工分析师在采取行动前对总结内容进行审核。

当客户端连接并询问服务器提供哪些资源、工具及提示时，就会产生交互，这使得MCP保持动态性。一旦反欺诈团队发布了用于检查客户设备历史的新工具，所有已连接的助手都能立即使用它，而无需修改客户端代码。

其通信格式为JSON-RPC 2.0，通过两种常见传输方式之一进行传输。Stdio适用于运行在客户端本地机器上的服务器；而带有Server-Sent Events或流式HTTP的HTTP则适用于远程服务器。位于数据中心内、处于防火墙之后的核心银行服务器，则需要通过经过适当身份验证的远程HTTP来访问，而非Stdio。

安全性

MCP主要在受监管的行业领域中发挥作用，但它并不会自动提供任何控制功能。它为工程师提供了一个统一的地方来构建和实施这些控制措施，而无需在每次集成时都重新设计安全机制。生产环境中的银行系统部署应满足以下要求：

当客户端向服务器认证时，必须使用OAuth 2.1协议；
仅为每个工具授予其所需的权限，这样初级分析员的访问令牌就无法获取如approve_wire_transfer这样的功能；
为每一次工具调用记录日志；
在执行会改变系统状态的操作（如冻结账户或解除冻结）之前，必须要求人工明确确认。

MCP部署的实际形态

典型的银行系统部署由三层组成。主机即用户所看到的聊天界面或代理运行环境，例如调查助手。主机内的MCP客户端会与服务器建立会话，发送发现请求，并在各方之间传递工具调用。这些服务器各自负责一个独立的记录系统，比如核心银行系统、欺诈检测引擎以及文档存储系统，每个系统都由其对应的团队负责维护与安全保障。

以一次欺诈调查为例，其请求路径如下：

分析师需要获取该客户过去30天内所有金额超过1万美元的交易记录，同时检查其设备指纹是否近期发生过变化。
主机中的大型语言模型判断需要发起两次工具调用，于是指示客户端在核心银行服务器上执行get_transactions操作，在欺诈检测引擎服务器上执行get_device_history操作。

客户端通过 HTTPS 向两个服务器发送 JSON-RPC 请求。

每个服务器都会验证分析人员的 OAuth 权限及其查看该客户数据的权限，随后查询自身的后台系统并给出回复。

客户端将两个服务器的回复传递给模型，模型再将它们整合成一份汇总报告。

所有的操作，包括请求、回复以及分析人员的身份信息，都会被记录到审计日志中。

一个使用官方 SDK 模式的简易 Python 服务器展示了该工具所需的代码量其实非常少：

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("core-banking-server")
@mcp.tool()
def get_transactions(customer_id: str, min_amount: float, days: int) -> list:
    """Fetch transactions above a threshold for a customer, scoped to the caller's authorization."""
    # In production this calls the real core banking API,
    # scoped and logged, never queried directly by the model.
    return query_core_banking(customer_id, min_amount, days)
@mcp.tool()
def place_transaction_hold(transaction_id: str, reason: str) -> dict:
    """Places a temporary hold on a transaction pending review. Requires human confirmation before execution."""
    return execute_hold(transaction_id, reason)
if __name__ == "__main__":
    mcp.run(transport="stdio")

实际应用中，这两个工具需要采用不同的处理方式。get_transactions属于读取操作，类似资源对象，无需确认步骤即可运行。place_transaction_hold则会改变真实金融系统中的状态，因此绝不能仅因模型要求就自动执行，应用层应先通过明确的分析师确认后再进行处理。

以下习惯有助于保持生产服务器的稳定运行：

让每台服务器仅负责处理一个系统，而非同时涵盖核心银行业务、欺诈检测和客户关系管理功能的庞大系统。
编写工具描述时需如同为新分析师准备的文档那样清晰，因为模型完全依据这些描述来判断何时使用某个工具。
为工具架构版本控制。若在未提前通知的情况下更改get_transactions的必填参数，将会影响所有依赖该功能的助手，包括那些不属于欺诈检测团队的工具。

应将每次工具调用视为下游系统接收的不可信输入并对其进行验证，因为被篡改的模型输出可能会尝试发起未经授权的调用。

A2A，即智能体之间的交互

MCP负责处理模型与工具之间的连接。而Google在2025年推出、现由Linux基金会维护的A2A则处理另一种类型的连接：即一个自主智能体向另一个智能体发起请求，尤其是当这两个智能体由不同的团队或供应商开发时。

仅靠一个智能体是不够的，因为负责处理欺诈检测、风险审核和沟通工作的单一智能体会逐渐发展成一个难以管理的庞大系统，而且要向审计人员证明是何种逻辑决定了具体决策也会变得极为困难。由不同专家相互协作的架构更为简洁且安全。

任务委派依赖于代理卡片，这是一种机器可读的说明，用于描述代理能够执行的任务。它类似于MCP服务器的工具列表，但描述的是整个代理的能力而非单个功能。协调型的客户助理代理会读取欺诈处理代理的卡片，从而得知其可以核查有争议的交易；再读取贷款处理代理的卡片，了解其能够判断再融资的资格，随后为客户的请求选择合适的代理来处理。

协调机制规定了各智能体如何通过标准传输方式交接任务、传递部分结果以及报告成功或失败情况。各方都将对方视为黑箱。客户助理智能体无需了解欺诈检测智能体的构建方式、它是否调用了核心银行系统的MCP工具、由何种模型驱动，或是其处理流程包含多少步骤。它只需知道该智能体的功能以及如何向其分配任务即可。

两个银行案例可以很好地说明这一点。首先，有客户报告了一笔陌生的500美元扣款，同时询问更优惠的抵押贷款利率。助理智能体不会自行处理这两件事，而是将争议处理任务转交给欺诈检测智能体，将抵押贷款相关问题转交给贷款处理智能体，让两者同步处理，最后再将两者的回复整合成一份答复。

其次，欺诈检测员会核查该交易，通过调用核心银行系统的MCP服务器以及欺诈检测引擎来获取交易记录和设备信息。当其对欺诈判定的置信度较低时，它会避免随意猜测，而是通过A2A机制将案件转交给合规审查员，后者会应用更严格的监管规则，必要时还会将其交由人工合规官处理。客户助理、欺诈检测员、合规审查员、人工审核员——这就是A2A机制所设计的结构化任务分配方式。

ACP：消息传递层

虽然A2A侧重于任务分配，但ACP则专注于多智能体对话中的消息传递，尤其是在长时间交互中的状态管理、内存处理及错误处理方面。

架构。对话表现为一系列输入的文字消息。每条消息不仅包含内容，还带有关于发送者、对话线程以及预期回复的元数据。因此，从欺诈处理升级到合规处理的流程会包含比案件本身更多的信息：包括案件编号、申请代理人、紧急程度以及预期回复类型等结构化字段。
消息传递。结构化设计取代了原始文本，就像电子邮件有主题、发送者和正文，而非一团杂乱的字符。在十几名代理人共同处理同一笔贷款业务时，每条消息都必须准确送达对应的代理人及其负责的处理人员手中。

状态。通过资格审核代理、风险评估代理和审批代理的处理流程中，需要在多次交互中保持状态的一致性。ACP制定了用于添加和更新共享状态的规范，例如已通过的审核项和待处理的文件，这样即便处理过程持续数天，各代理也不会遗漏申请信息。

内存。与当前申请相关的短期对话内存与会在不同会话之间保留的长期内存分开存储，例如客户已明确的固定利率抵押贷款偏好，这类信息可用于指导后续对话，避免重复提问。

错误处理。银行业务中的代理调用失败后不能就此消失。比如，当下游系统出现故障时，风险评估代理可能无法获取信用报告。ACP规定了结构化的错误类型，使协调工作的资格评估代理能够选择重新尝试、将任务转交给人工审核员或暂时暂停处理，从而避免部分错误或不当决策在无人察觉的情况下被使用。

五种技术的对比

将它们放在一起对比，会发现它们在几个方面存在差异：

连接的对象。普通API用于连接不同的应用程序。工具调用则用于将模型与函数相连。MCP则可将模型或应用程序与工具、数据及提示词相连接。A2A用于连接不同的代理。而ACP则在消息层面上实现代理间的连接。
供应商间的标准化程度。普通API没有标准化。工具调用有部分标准化。而MCP、A2A和ACP则实现了标准化。

功能发现能力。普通 API 和工具调用不具备此功能；MCP 通过代理卡片实现动态发现，A2A 也具备一定能力，而 ACP 的该功能较为有限。

内置的状态与内存规范。普通 API 和工具调用没有相关规范，MCP 和 A2A 仅有部分规范，ACP 则将此作为核心重点。

银行业务示例。核心银行系统与 CRM 系统交互；助手调用预定义的余额查询函数；助手能够统一发现并调用核心银行、欺诈检测及文档处理相关工具；欺诈处理代理将任务委托给合规审查代理；多日贷款审批流程的状态在三个代理之间传递。

这些选项是互补关系，而非竞争关系。实际的银行助理很可能会结合使用MCP将各代理人与核心系统连接起来，利用A2A在专家之间进行任务分配，同时运用ACP规范来全程管理诸如承销这类涉及多个代理人的复杂工作流程。

一条客户消息，端到端处理

以一条消息为例：客户不理解500美元的收费项目，同时还想了解更优惠的抵押贷款利率。整个系统会逐步对此作出响应。

客户将消息发送给AI助手，即银行应用内的主机程序。
通过A2A，助手将欺诈相关问题转交给欺诈处理专员，将抵押贷款相关问题转交给贷款处理专员，两者会同时开始处理。

欺诈检测模块通过MCP调用CRM服务器以获取联系人和投诉记录，同时调用核心银行服务器查询有争议的交易信息。在应用其欺诈检测规则后，它会再次通过MCP调用核心银行服务器的place_transaction_hold功能。由于该操作会改变交易状态，因此在执行前需由人工分析师进行确认。

贷款处理模块通过MCP从核心银行获取当前的抵押贷款条款和信用档案，将其与现有的利率表进行对比后形成建议。若要提供再融资利率，则需要审批人的签字确认，因此该模块不会执行任何操作，而是将建议及相关数据提交给供人工查看的汇总报告。

这两个模块均通过A2A机制向助手反馈信息，使用ACP格式的结构化消息来传递案件状态、待处理的人工审批事项及分析结果。

助手通过MCP向客户发送确认暂停服务的邮件，并将每一次工具调用、任务交接及决策节点记录在审计系统中，因为一旦案件被审查，监管机构就会要求提供这样的完整记录。

因此，银行中的互操作性表现为：没有试图包揽所有工作的单一巨型模型，而是由拥有受控工具访问权限的专用智能体各自负责特定任务，同时配有清晰的审计轨迹。

智能体与协议之间的安全性

提示注入。隐藏在文档、邮件或上传文件中的恶意指令可能会试图控制智能体的下一步操作。想象一下，一封欺诈性纠纷邮件中包含隐藏文本，命令欺诈处理智能体在未经核实的情况下批准索赔。由于MCP工具能够改变实际状态，这种危险是真实存在的。应对措施：将所有获取的内容视为不可信的，绝不允许模型输出在未经策略检查的情况下触发诸如place_transaction_hold这类高风险工具，并限制模型在特定上下文中能够使用的工具范围。
身份认证。每条MCP客户端-服务器连接以及每次A2A交互都需要进行身份认证，通常采用OAuth 2.1机制，这样匿名调用者就无法使用核心银行工具或向合规审查智能体分配任务。

授权机制。身份认证用于确认来电者是谁，而授权机制则规定该来电者可执行哪些操作。即便经过身份验证的欺诈处理代理的推理看似合理，它仍无权使用可批准调整房贷利率的工具，因为这超出了其职责范围。

零信任原则。链条中的任何环节默认都不被信任，无论是模型、其他代理还是下游服务器。每次调用执行时都会进行政策检查，而不会仅因调用源自银行自身的人工智能系统就直接通过。

人工审批。涉及财务、安全或监管层面的操作，如冻结账户、解除限制或批准贷款，都必须经过人工确认。这是根据风险程度做出的设计决策，而非技术上的缺陷。

审计追踪。需详细记录每一次工具调用、权限委托以及状态变更，以便还原事件经过及其原因。如果监管机构询问为何某个账户被冻结了六小时，银行必须能够出示具体的操作决策链和工具调用记录，而非仅提供估算结果。

发展前景

行驶方向一目了然。像MCP这样的协议正在成为人工智能的设备驱动层，为任何模型与任何工具之间的交互提供标准路径，无需额外的适配代码。未来人工智能操作系统将成为一个独立的类别，其中MCP风格的服务器将如同数据库和消息队列一样成为基础基础设施，而核心银行服务器则会成为每个内部人工智能项目直接接入的对象，无需重新开发。预计会出现经过预先审核和验证的服务器市场，这样银行就可以直接使用符合合规要求的身份验证服务器，而无需自行开发。此外，随着合规与风控团队需要在相关操作涉及真实资金之前掌握详细情况，用于审核MCP调用及点对点授权的治理工具也将不断涌现。同样的模式还将延伸到银行业以外的各个领域，凡是需要具备标准化、可审计的决策方式的推理系统应用场景都将受到影响。

简述版

仅靠模型本身无法核对余额、实施冻结或评估抵押贷款。MCP规范了如何访问工具、数据及提示信息，从而使反欺诈助手与贷款助手能够共享同一核心银行服务器，而无需重复集成。A2A则规范了专业代理人之间如何交接工作，而无需了解对方的内部机制。ACP则规范了在诸如多日贷款审批这类复杂工作流程中的消息传递、状态管理及错误处理。对银行而言，这些协议并非仅仅是便利工具，它们才是实现大规模授权、审计追踪及人工审批的基础。

由此可得出两条设计原则：MCP将只读资源与会改变状态的工具分开，授权设计也应遵循这一分离方式，因为检查余额与发送信号所涉及的风险截然不同。此外，针对每次协议调用的人工审批机制及审计追踪是核心要求，因此应直接写入代码初始部分，而非放在后续的补丁中。