MCP、A2A 与智能体互联网：协议竞争下的产品与开发机会
一个客服 Agent 接到用户问题：订单到哪了？如果订单在 ERP，物流在快递 API，退款要风控，过去常见做法是给每个模型写一套 function calling。换模型、换云、加一个工具，都要重写。2026 年更现实的做法是：工具侧用 MCP 暴露能力，Agent 之间用 A2A 传递任务。协议本身开源，要做的工程在协议之间。
一张图看 MCP 和 A2A 的分工
MCP 解决 Agent 到工具/数据。A2A 解决 Agent 到 Agent。两者可以同时出现：客服 Agent 通过 MCP 查订单，通过 A2A 找风控 Agent 判断是否可退款。
协议层：MCP、A2A 和 function calling 怎么选
| 方案 | 连接对象 | 发现方式 | 常见传输 | 适用阶段 |
|---|---|---|---|---|
| MCP | 工具、数据源 | Host 配置或注册表 | stdio、Streamable HTTP | 把内部系统接到多个 AI 客户端 |
| A2A | 另一个 Agent | Agent Card | JSON-RPC over HTTP、SSE | 跨团队、跨厂商 Agent 协作 |
| function calling | 模型到工具 | 模型厂商 schema | 随模型 API | 单应用快速验证 |
选型时按问题边界走：
- 只差一个内部 API：先用 function calling 或直接写一个 MCP Server，不要上 A2A。
- 要让 Claude Desktop、Cursor、VS Code 等不同 Host 都能调同一个内部工具：优先 MCP。
- 任务要跨越两个团队维护的 Agent，且各自有独立权限：考虑 A2A。
- 写操作、退款、发邮件：无论用哪个协议，先加人工确认和审计。
开发机会：工具市场、网关、权限、审计、评测
协议统一后，值钱的是脏活。下面五个方向可以直接做产品，也可以在企业内部立项。
| 方向 | 谁付钱 | 最小可用版本 | 关键指标 |
|---|---|---|---|
| MCP 工具市场 | 垂直 SaaS、企业 IT | 5 个只读工具 + 凭证托管 + 调用日志 | 周活跃工具调用、次周留存 |
| 协议网关 | 安全团队、Agent 中台 | 鉴权、限流、协议转换、审计 | 越权拦截率、P95 延迟 |
| 权限代理 | 合规、安全 | OAuth 2.1 资源服务器 + 策略引擎 | 非法调用拦截率、审批时长 |
| 审计与回放 | 运维、风控 | 全链路 trace + 脱敏 + 告警 | 可回放率、误报率 |
| Agent 评测 | Agent 团队 | 100 条黄金任务 + 自动打分 | 工具选择准确率、跨 Agent 完成率 |
网关可以先用 Envoy、Kong 或 FastAPI 写一层。MCP 的 Streamable HTTP 和 A2A 的 HTTP 入口都走这里，统一做 OAuth 2.1、租户隔离、请求日志。这里最容易踩的坑是把用户 token 直接透传给下游 Server，正确做法是网关换票，Server 只拿到短期、限定范围的凭证。
权限要管到工具参数级。比如“退款”工具允许调用，但金额超过 500 元必须走审批；“查订单”只能查当前用户所在租户。策略引擎可以用 OPA 或 Cedar，规则写在代码外，方便审计。
审计记录至少包含：时间、用户、Host、Agent ID、协议、工具名、参数摘要、返回摘要、耗时、是否命中策略。参数里的手机号、地址、身份证要脱敏，原始值加密存储。
评测不要只测“回答像不像人”。Agent 的工具选择准确率、参数完整率、越权拦截率、跨 Agent 任务完成率、单任务成本，才是上线前要看的数。黄金任务集从真实工单里抽，100 条起步。
产品机会：跨应用 Agent 和企业 Agent 中台
跨应用 Agent 的入口放在一个高频流程里，别从聊天框开始。比如报销：收邮件、查差旅订单、核对发票、生成报销单、提交审批。先做只读聚合，再把写操作一个一个加人工确认。
企业 Agent 中台负责四件事：Agent 注册、工具注册、凭证与策略、审计与评测。它不该先自研大模型。先把公司里已有的 API 编目，选出 10 个高频只读接口，做成 MCP Server，再决定哪些流程需要 A2A。
| 产品 | 入口 | 先做 | 不要先做 |
|---|---|---|---|
| 跨应用 Agent | 一个高频流程 | 只读聚合 + 人工确认 | 全自动写操作 |
| 企业 Agent 中台 | 内部平台 | Agent/工具注册 + 审计 | 自研大模型 |
风险：安全、锁定、标准碎片化
安全风险里最急的是提示注入。工具返回的网页、邮件、工单内容可能夹带指令。处理方式：工具输出标记为不可信，不把返回文本当系统指令执行；写操作二次确认；对高风险工具加人工审批。
第二是工具投毒和身份冒用。MCP Server 可能返回伪造数据，A2A 的 Agent Card 也可能被冒充。内部市场要审核来源，远程 Server 用 mTLS 或签名，Agent Card 做签名校验，调用链保留身份。
第三是锁定。托管平台会帮你省掉鉴权、伸缩和监控，但工具 schema、日志字段、评测数据可能导不出来。选型时先问：能不能导出调用日志？能不能换 Host？能不能本地跑一个兼容 Server？
第四是碎片化。MCP 和 A2A 都在更新，扩展字段、授权细节、Agent Card 路径可能变。工程上只依赖核心原语，版本号 pin 住，升级前跑回归。不要在没有评测集的情况下追最新草案。
最小验证：写一个只读 MCP Server
下面用 MCP Python SDK 跑一个订单查询工具。代码只做示例，实际接内部 API 时要加超时、重试和脱敏。
# 需要 Python 3.10+，先安装 mcp：pip install mcp
from mcp.server.fastmcp import FastMCP
mcp = FastMCP('订单查询')
@mcp.tool()
def get_order_status(order_id: str) -> dict:
# 换成你的内部 API，不要返回完整手机号
return {'order_id': order_id, 'status': '已发货'}
if __name__ == '__main__':
mcp.run()
跑通后，把它挂到支持 MCP 的 Host，比如 Claude Desktop、Cursor 或 VS Code 的 Copilot Chat。只给只读凭证。观察一周日志，记录四件事：哪个工具被调用最多、参数错误长什么样、有没有越权尝试、平均耗时多少。
如果一周后要接第二个 Agent，再考虑 A2A。先写清楚 Agent Card 里的能力边界，退款这类写操作必须带审批。A2A 的消息方法按 a2a-protocol.org 上的最新规范实现，版本不同方法名可能调整。
今天就能做的一件事
列出你手头三个最常查的内部系统，选一个只读接口，按上面的代码写一个 MCP Server。不要先做 UI，也不要先接大模型。先让不同 Host 能稳定调用它，再谈跨应用 Agent。