本指南适用于正在决策第二个智能体是否需要与第一个智能体通信（而不仅仅是与系统通信）的CTO或工程负责人，以及正在评估额外协议和委派层是否值得增加审计与审批面的IT治理负责人。我们的MCP服务器指南设计了本页所假设已存在的智能体到工具层；我们的智能体AI架构指南将人工审批节点置于单个智能体自身的控制循环中。本页是两者之上的一层：当第二个智能体加入后，会发生哪些变化。
本指南内容
- MCP与A2A解决的是同一个问题吗？
- 双层模式
- 中型企业现在需要A2A吗？
- 实例：将应收账款流程设计为多智能体
- 第二个智能体成为调用方后的变化
- AI在多智能体设计中的定位
- 现有交付记录与尚无记录的内容
- 替代方案：企业协调多个智能体的其他方式
- 本指南的局限性
- 常见问题
- 下一步
MCP与A2A解决的是同一个问题吗？
不是。MCP（模型上下文协议）将单个智能体连接至其完成工作所需的工具、数据和系统：订单状态查询、CRM更新、文档检索。A2A（Agent2Agent）将一个智能体连接至另一个智能体：它让智能体发现第二个智能体的能力、向其发送任务并追踪任务完成情况，是两个推理系统之间的协议，而非智能体与数据源之间的协议。只有一个智能体和五个工具的企业只需MCP；这种设计中不涉及发现或委派另一个智能体。
双层模式
大多数同时使用两种协议的企业将A2A置于顶层，协调由哪个专属智能体处理任务的哪个部分，并在每个智能体下方使用MCP，将其连接至该部分所需的系统。去掉任何一层，都会有不同的部分出现问题：没有A2A，智能体无法以结构化方式移交工作；没有MCP，接收委派任务的智能体没有受治理的方式来执行任务。
| 层级 | 治理内容 | 移除后的影响 | 归属方 |
|---|---|---|---|
| A2A（智能体到智能体） | 两个或多个专属智能体之间的发现、任务委派与移交 | 智能体无法再以结构化、可追踪的方式移交任务；协调退回至自定义胶水代码或单个过大的智能体 | 设计多智能体工作流的团队 |
| MCP（智能体到工具） | 单个智能体访问其完成任务所需的ERP、CRM、财务或其他系统 | 接收委派任务的智能体没有受治理的方式来执行任务；它可以推理任务，但无法在真实系统中执行 | 拥有工具所封装后端系统的团队（我们的MCP服务器指南覆盖此层） |
中型企业现在需要A2A吗？
大多数拥有一个智能体和若干工具的中型企业目前不需要A2A，因为单智能体设计中没有任何环节将工作委派给第二个推理系统；仅MCP经过适当范围界定和治理，是更简洁的答案。关键问题不是「智能体使用了多少工具」，而是「一个任务在完成之前需要经过多少个由不同团队构建或拥有的独立智能体」。
一个实用的检验：每一次工具调用是否都能追溯到那一个智能体，以及批准它的那一个人？在单智能体设计中，答案始终是肯定的，因为一个智能体承担整个任务。一旦任务拆分到两个智能体之间——一个分类智能体对请求进行分类，一个账单智能体对其采取行动——追踪也必须跨智能体跟随任务，否则一个已批准的行动会失去究竟是哪个智能体发出请求的上下文。这正是A2A发挥作用的时刻：不是在增加第二个工具时，而是在增加第二个智能体时。
实例：将应收账款流程设计为多智能体
我们的应收账款流程指南将订单到回款的子步骤（订单录入、信用审核、开票、催收跟进）映射到智能体适用之处以及人工决策之处。若企业为每个子步骤构建一个智能体，而非为整个流程构建一个大型智能体，正好满足此条件：催收智能体必须将有争议的发票移交给账单智能体，或录入智能体需要先获得信用审核智能体的答复。每个智能体仍然需要自己到各自系统的MCP连接；A2A让它们能够相互发现并传递任务，同时携带足够的上下文以供审计移交。
第二个智能体成为调用方后的变化
-
每个智能体保持独立的MCP连接所有权，绝不跨智能体共享连接。
每个专属智能体以自身身份向其工具进行身份验证，遵循我们MCP服务器指南为单个智能体设定的最小权限原则；共享连接会使有争议的行动无法追溯到触发它的智能体。
-
将追踪延伸至移交环节。
一旦任务跨越到第二个智能体，仅在一个智能体边界内的追踪就不够了；任务ID（而不仅仅是调用ID）必须在A2A移交中传递，以便审核人员能够端到端地跟踪一个任务。
-
明确指定哪个智能体持有移交行动的人工审批门控。
我们的智能体AI架构指南将审批节点置于单个智能体的控制循环中；在多智能体设计中，指定由一个智能体（通常是执行写操作的那个）持有门控，以避免移交时以「另一个智能体已审核」为由让未经批准的行动溜过。
-
将终止开关扩展至整个链路。
一旦任务已被委派，仅停止发起任务的智能体是不够的；多智能体设计中的终止开关必须停止仍持有任务某部分的每一个智能体，而不仅仅是某人正在监控的那一个。
-
从两个智能体开始，而非一个集群。
在添加第三或第四个专属智能体之前，先在一个真实移交上验证发现、委派和扩展追踪。
AI在多智能体设计中的定位
Netbase JSC与主流商业及开源AI工具、模型和协议合作，按项目选型，并以对待第一个智能体的方式对待第二个智能体：范围界定、可追踪、经审批，绝不因另一个智能体的背书而视其为安全。
-
成长能力：在现有MCP工具层之上的多智能体委派设计。
决定工作流的哪些部分拆分到专属智能体，并将追踪、审批和终止开关设计延伸至智能体到智能体的移交；尚未与已发布的A2A案例挂钩。
-
已交付（匿名客户）：带CRM同步的AI聊天机器人。
一个在定义的操作集上读写CRM数据的智能体，客户未具名，作为单个智能体自身范围交付，并非智能体之间相互委派。
现有交付记录与尚无记录的内容
Netbase JSC已构建了多智能体设计中各智能体各自需要受治理访问的系统类型，并设计了本页所依赖的单智能体控制循环和工具暴露层：
- 为美国客户构建的多租户云ERP（未具名）。自2020年起，作为离岸开发及管理合伙人，以SaaS形式交付云ERP；第1阶段涵盖CRM、知识库、工作与项目管理及API集成——正是专属智能体自身MCP连接所要封装的系统类型。
- ERP和CRM咨询（未具名）。Odoo咨询与定制、通过API同步目录、库存、订单和客户数据的电商平台到ERP集成，以及Vtiger到ERP的升级；每项均为单个智能体MCP工具可调用的定义且有边界的操作，而非原始数据库连接。
- 其他已交付AI项目（匿名）：检索增强知识助手、文档AI及MLOps流水线，客户未在此具名（F072）。
尚无记录的内容。目前没有Netbase JSC已发布的记录描述使用A2A协议交付的多智能体系统、在生产中一个智能体委派给另一个智能体，或将A2A与MCP结合使用的可量化结果。上述决策规则、双层模式和排序步骤来自Netbase JSC的ERP/CRM集成和单智能体交付实践（F070、F072、F076、F077）以及所引协议来源，而非某一可量化的多智能体项目；对于任何多智能体或A2A部署，不声明任何时长、成本、准确率或采用率数据。
替代方案：企业协调多个智能体的其他方式
| 方案 | 优势 | 适用场景 |
|---|---|---|
| 单个较大的智能体，无委派 | 最易追踪和审批：一个智能体、一个所有者、一套MCP连接 | 整个任务适合单个智能体的推理和工具范围 |
| 自定义编排代码（无A2A） | 完全控制一个智能体如何直接调用另一个智能体的代码 | 只有一个团队拥有所有智能体，且日后无需替换或发现 |
| 专属智能体之间使用A2A，各自下层使用MCP | 跨可能由不同团队或供应商拥有的智能体的标准发现和委派 | 存在或计划存在多个专属智能体，可能归属不同团队 |
何时不应添加A2A。一个只有若干工具、没有第二个推理系统来移交工作的单一智能体不需要委派协议；添加它只是增加复杂性而无任何可协调的内容。待第二个专属智能体存在或确定计划后，再添加A2A。
在Netbase JSC的定制开发中，客户拥有为其创建的知识产权，大多数项目在发现阶段后以固定总价合同运行。智能体到工具层位于系统与API集成和ERP和CRM开发中，面向智能体的设计位于AI集成中，通过智能体AI自动化和企业AI智能体平台交付，服务行业包括专业服务等。
本指南的局限性
- 两种协议都较新且频繁修订；在将架构提交给任一协议之前，请查阅最新规范。
- 决策规则和双层模式是初始设计，不保证特定多智能体系统是安全的或范围正确。
- 对于任何多智能体或A2A部署，不声明任何时长、成本、准确率或采用率数据。
- 添加A2A并不能取代本集群其他指南所涵盖的单智能体控制（审批、追踪、终止开关）；它是在其上添加一层，而非替代。
常见问题
不是。MCP将智能体连接至其所需的工具和系统；A2A将一个智能体连接至另一个智能体以实现发现和委派。多智能体设计通常在每个智能体下层保留MCP，并在它们之间的移交上层添加A2A。
暂时不需要。在第二个专属智能体存在或确定计划之前，A2A没有任何可协调的内容；只有若干工具的单一智能体只需要一个范围合理的MCP层，正如我们的MCP服务器指南所述。
是移交环节。没有共享的发现和委派协议，智能体要么需要将它们绑定在一起的自定义胶水代码，要么退回为一个过大的单一智能体，而有争议的行动也更难追溯到触发它的智能体和批准它的人。
指定一个智能体——通常是执行写操作的那个——作为该步骤审批门控的持有者，与我们的智能体AI架构指南在单个智能体控制循环中设定的规则相同；移交不应被理解为「另一个智能体已经检查过了」。
下一步
告诉我们您的设计实际需要多少个智能体以及每个智能体需要访问哪些系统，我们将预约方案评审，以界定委派层、工具连接及其间的审批链。您也可以了解智能体AI自动化服务，或浏览更多Netbase JSC洞察。
此指南背后的项目案例
一家未具名的美国软件公司以SaaS形式向中小企业销售多租户云ERP。自2020年起，Netbase JSC作为其离岸开发及管理合作伙伴持续参与开发；第1阶段为面向代理商客户的平台整合了CRM、即时通讯、人力资源管理、知识库、工作管理及API集成。目前无公开数据指标。
Keep Reading相关服务与解决方案
保留人工审批的AI自动化与智能体
Netbase为希望用软件处理重复性多步骤工作的运营团队提供AI自动化与智能体开发服务，同时保留对关键决策的人工审批权。我们将规则自动化与AI结合，构建人工审批环节，并与基线对比衡量回报。
Learn More
企业级AI智能体平台：在审批、审计日志与成本限额下运行AI智能体
企业级AI智能体平台是一个受治理的运行时环境，AI智能体通过已审批的工具规划并执行多步骤任务，同时审批流程、审计日志、访问规则与成本限额确保每个操作可问责。Netbase将其作为前瞻性解决方案提供，部署于您自有环境中，而非以产品形式授权。
Learn More
与 Netbase 远程合作
Netbase 所有项目均远程交付，任何国家、任何行业的客户均可与我们合作；Netbase 已服务全球 80 个国家的客户。合同与发票由 Netbase JSC 开具，款项通过银行转账至 Netbase JSC 公司账户或 PayPal Business 支付。欢迎通过 WhatsApp 或邮件联系 CEO Huy Nguyen（David）。
讨论项目
Netbase JSC 帮助企业设计、构建、现代化和运营数字产品及 AI 驱动的业务系统。project@netbasejsc.com
+84 937 869 689
91 Nguyen Chi Thanh, Dong Da, Hanoi, Vietnam
取得联系
告诉我们您想构建、现代化或运营什么。