几周之前，我在Cisco Security Community上发表了一篇文章，题目是“模型上下文协议(MCP)与安全”。很多人都问我能不能比较一下MCP、A2A和AGNCY。那么我们就来谈谈……如果你正在读这篇文章，你大概已经知道，人工智能的世界正在从单一模型快速向相互连接的专精化代理系统转变。这些代理可以被设计用于从客户服务到复杂的网络安全数据解析等各种任务。这种转变承诺了前所未有的自动化和效率。

然而，利用这一潜力的关键在于克服一个基本的挑战：使这些智能代理程序能够安全有效地通信、协作并访问所需的信息，这些代理程序通常由不同的供应商基于多种框架构建。

(Spoiler Alert) Anthropic 的模型上下文协议（MCP）专注于将AI模型与外部工具和数据连接起来。Google 的 Agent2Agent（A2A）协议旨在标准化代理之间的直接通信。AGNTCY 集体正在构建一系列全面的基础设施，展望一个“代理互联网”，构建一个更智能、更互联的世界。

MCP 例子 (MCP 模块)

MCP 是由 Anthropic 引入的。从那时起，它变得极其流行。它旨在成为连接 AI 模型和应用程序（以及智能代理）与外部工具、数据源和技术系统的通用标准。MCP 经常被比作 AI 的“USB-C”。

其主要目标是解决“ M×N 集成难题”。这就是连接 M 个AI模型到 N 个工具的复杂性；提供一个单一、标准化的协议。

MCP 允许任何符合标准的 AI 应用与任何符合标准的数据源或服务端交流，而不需要为每个连接进行专门的集成。

MCP 使用客户端-服务器架构。

1. 主机：用户交互的主要AI应用程序（例如，Claude Desktop，WindSurf，Cursor等IDE）。主机管理整个流程，协调大型语言模型的交互，创建并管理客户端实例，并强制实施安全策略。
2. 客户端：嵌入在主机中的轻量级协议客户端。每个客户端与特定的MCP服务器保持一个独立且有状态的1:1连接，处理协议握手和消息路由。
3. 服务器：符合MCP标准，暴露特定功能（如数据访问、工具、提示）的独立进程（本地或远程）。服务器设计为简单、可组合并专注于特定任务。

MCP 定义了三种主要的基本交互方式，这些方式由服务器提供。

服务器提供的MCP可用的交互基础单元。

• 工具：AI 模型可以调用的可执行的功能或操作（例如，API 响应、数据库查询、脚本执行）。
• 资源：提供给 AI 模型的只读的上下文数据源（例如，文件、日志、数据库记录、API 响应）。
• 提示：用于涉及工具或资源的常用任务的可重复使用的模板指令或工作流。

通信通常通过标准输入输出（stdin/stdout）进行，适用于本地进程的通信；对于网络服务，则通过HTTP和服务器发送事件（SSE）技术进行。

MCP的安全很大程度上依赖于主机应用来实施策略和管理用户的同意。MCP的原则和机制有：

• 用户同意：访问资源或调用工具必须获得用户的明确同意。
• 主机控制：主机作为执行安全的中心点，控制客户端连接、权限和生命周期。除非主机明确允许，服务器不能“窥探”其他服务器或完整的对话历史。
• 本地优先原则：服务器通常默认在本地运行，防止敏感数据在没有得到授权的情况下离开受控环境。
• 传输安全：推荐使用TLS进行远程连接。
• 输入验证：强调在客户端和服务端都需要对输入进行验证和清理，以防止注入攻击或意外执行。
• 访问控制：虽然MCP本身没有强制特定的访问控制，实现时，应在主机或服务器逻辑中采用基于角色的访问控制（RBAC）或访问控制列表（ACL）等机制。
• 潜在风险：包括OAuth令牌被盗（若用于服务器认证）、服务器被攻破导致广泛访问权限、提示注入漏洞，以及授予服务器过多权限的风险。缓解策略包括使用短期令牌、实施最小权限原则、监控提示并隔离基础设施。

注：更多安全方面的考虑可以参考以下文章，“AI模型上下文协议（MCP）及其安全性”。
。

Google的A2A协议是一个开放标准协议，专门设计用于让自主AI代理之间可以直接通信、协调和互操作。它旨在充当代理之间的“通用协议”或“代理之间的HTTP”，使使用不同框架或由不同供应商开发的代理能够发现彼此的能力，协商互动模式，并安全地协作完成任务，即使它们内部的工作原理是不透明的。

A2A GitHub项目: https://github.com/google/A2A

A2A 是基于 JSON-RPC 2.0 协议通过 HTTP(S) 发送请求，并通过 SSE 实时更新构建的。其架构采用直接客户端-服务器模式。

• A2A 客户端应用：一个应用程序或另一个 AI 代理，通过发送请求（例如 tasks/send）来启动与 A2A 服务器的通信。它代表用户或自身流程来制定任务。
• A2A 服务器：一个实现了 A2A 协议方法的 AI 代理，通过 HTTP(S) 端点进行通信。它接收请求，管理任务执行，并将响应或更新回传给客户端。
• 代理卡：一个标准化的 JSON 元数据文件，通常托管在 /.well-known/agent.json，用于发现。它描述了代理的身份、能力（技能）、端点 URL、身份验证要求以及支持的交互模式。
  例如：

{
  "name": "网络威胁情报代理",
  "description": "分析网络日志，检测威胁，并为企业环境提供漏洞评估。",
  "url": "https://cyber-agent.becomingahacker.org",
  "version": "1.2.0",
  "provider": {
    "name": "SecureAI解决方案",
    "contact": "support@becomingahacker.org"
  },
  "capabilities": {
    "streaming": "实时流",
    "pushNotifications": "推送通知"
  },
  "authentication": {
    "schemes": ["Bearer", "APIKey"]
  },
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json", "text/plain"],
  "skills": [
    {
      "id": "threat-detection",
      "name": "威胁检测",
      "description": "识别提供的网络日志中的潜在安全威胁。",
      "tags": ["威胁", "检测", "日志"],
      "examples": [
        "分析这些防火墙日志中的可疑活动。",
        "检测我的网络流量数据中的威胁。"
      ]
    },
    {
      "id": "vulnerability-assessment",
      "name": "漏洞评估",
      "description": "扫描系统配置和软件版本，查找已知漏洞。",
      "tags": ["漏洞", "评估", "扫描"],
      "examples": [
        "检查此服务器配置中的漏洞。",
        "评估已安装软件包的风险等级。"
      ]
    },
    {
      "id": "incident-response",
      "name": "事件响应",
      "description": "提供应对检测到的网络安全事件的分步指导。",
      "tags": ["事件", "响应"],
      "examples": [
        "指导我如何应对勒索软件攻击。",
        "检测到网络钓鱼企图后我该怎么做？"
      ]
    }
  ]
}

任务: 任务是工作或互动的基本单元。每个任务都有客户端生成的唯一ID，并通过一个定义好的生命周期（例如，已提交、处理中、需输入、完成、失败、取消）进行沟通，这些状态通过响应或状态更新来传达。

代理确认任务并将状态改为 working，表示任务现在开始处理了。

代理检测到缺少的信息后，请求更多相关信息，并将状态设为input-required。

客户端回复所需的网络访问权限。

代理服务完成了漏洞评估任务，并将评估结果的状态标记为completed。

消息代表一个任务中的一个通信轮次，其角色是“用户”或“智能代理”。

任务生命周期阶段简介:

• submitted任务已提交并加入队列。
• working任务正在处理中。
• input-required需要客户提供更多信息。
• completed任务完成并生成了结果。
• failed任务因故失败。
• canceled任务被客户或代理取消了。

“部分”是消息或内容中的基本内容单元。定义的类型包括文本部分、内联文件或通过URI链接的文件部分和结构化的JSON数据部分（例如用于表单），从而实现跨媒介的通信。

成果代表了在执行任务时生成的结构化输出或结果，也由若干部分构成。

让我们来看一个恶意软件分析任务的例子，它包括组件和证据。

客户上传一个恶意软件样本文件进行分析，通过 FilePart 上传。

{
  "taskId": "task-malware-5678",
  "messageId": "msg-m001",
  "role": "user",
  "timestamp": "2025-05-04T01:30:00Z",
  "content": {
    "parts": [
      {
        "type": "FilePart",
        "mimeType": "application/octet-stream",
        "name": "suspicious-file.exe",
        "content": "base64-encoded-binary-data",
        "disposition": "inline"
      },
      {
        "type": "TextPart",
        "text": "检查这个文件是否有恶意行为。"
      }
    ]
  }
}

代理人返回了一个包含多个组件的原件。

{
  "taskId": "task-malware-5678",
  "status": "completed",
  "artifacts": [
    {
      "artifactId": "report-xyz",
      "type": "malware-analysis",
      "description": "详尽的恶意软件分析报告",
      "parts": [
        {
          "type": "TextPart",
          "text": "恶意软件分析摘要:",
          "mimeType": "text/plain"
        },
        {
          "type": "DataPart",
          "mimeType": "application/json",
          "data": {
            "verdict": "判定",
            "malwareType": "木马",
            "severity": "严重",
            "indicatorsOfCompromise": [
              "C2: 94.130.12.45:8080",
              "MD5: abcd1234...",
              "创建注册表项 HKLM\\恶意键"
            ]
          }
        },
        {
          "type": "FilePart",
          "mimeType": "text/plain",
          "name": "行为日志.txt",
          "uri": "https://cyber-agent.example.com/logs/行为日志-xyz.txt",
          "disposition": "uri"
        }
      ]
    }
  ]
}

用户消息中的部分：

1. FilePart：文件部分，内联的 base64 编码恶意软件样本
2. TextPart：自然语言说明

代理的回复中有这样一个项目，它由三个相互关联的部分组成。

1. TextPart：人类可读的摘要
2. DataPart：结构化的JSON数据，包含技术发现
3. FilePart：指向详细行为日志的URI链接

交互模式有请求-响应、使用SSE的服务器到客户端流流、以及使用webhook的异步通知推送。

（注：A2A为特定术语或缩写，此处保留原文）

A2A的安全模型遵循了标准的网络实践：

• 认证：依赖于 Agent Card 中声明的标准机制。它支持常见的 HTTP 方案（Basic、Bearer），API 密钥（在头部、查询参数或 cookie 中），OAuth 2.0 和 OpenID Connect，符合 OpenAPI 规范。身份验证本身不在协议内部处理。
• 加密：主要依赖于 HTTPS（TLS）提供的传输层安全来加密传输中的数据，
• 安全发现功能：Agent Card 可以指定访问代理端点所需的认证要求。
• 任务完整性：使用唯一的任务 ID 可帮助保持上下文并防止不同交互之间的干扰。不过，关于额外的任务完整性检查的具体细节并未详细说明。
• 速率限制：协议设计承认需要诸如速率限制（例如，令牌桶、漏桶）之类的机制来防止滥用，不过，具体的实现细节则由服务器端决定。

AGNTCY（发音为“agency”）是一个开源集体（包括思科、LangChain、Galileo 等在内的许多公司），旨在构建“一个智能体互联网”（IoA）的基础架构。它的愿景远远超出了MCP或A2A本身；它旨在创建一个开放且互操作的生态系统，在其中可以发现大量的智能体并将其组成工作流程，实现大规模安全部署，并对其进行评估。它类似于互联网的基础协议（如HTTP、DNS、TCP/IP）。

核心部分和架构:

AGNTCY 不是一个单一的协议，而是一系列相互关联的标准、协议和参考实现，旨在覆盖代理应用的整个生命周期。

来源: https://docs.agntcy.org/_images/ioa_arch.png,

代理连接协议 (ACP): 定义了调用和与代理交互的标准接口。它指定了 RESTful 端点，用于配置、调用（同步或异步）、输出检索（包括流式传输）、中断处理（当代理需要输入的场合）、获取功能/架构，以及通过会话管理有状态的上下文。ACP 侧重于代理间的交互和协作。提供了一个 ACP SDK（Python）。更多详情请参见 GitHub: https://github.com/agntcy/acp-spec

ACP统一代理交互

Agent 网关协议 (AGP): 作为底层网络传输层或“消息传递 SDK”。基于 gRPC（基于 HTTP/2 和 Protocol Buffers（或可能的 Protocol Buffers）），AGP 设计用于安全、高效、低延迟通信。它支持多种消息模式：请求/响应、单向和双向流式、发布/订阅（Pub/Sub）和一次性的消息发送。GitHub: https://github.com/agntcy/agp

AGNTCY 代理协议（AGP）

Agent网关（https://github.com/agntcy/agp）：一个关键的基础设施组件之一，使得AGP通信得以实现，提供诸如安全路由、消息转发（通过数据和控制平面）、发布/订阅中介服务以及策略执行功能等服务。GitHub：https://github.com/agntcy/agp

代理网关 AGNTCY

开放代理框架（OASF）：描述代理、它们的能力、依赖项、性能指标等的标准元数据格式。项目主页：https://github.com/agntcy/oasf

开放代理框架（OASF）

代理目录服务：一个类似于DNS的分布式服务，用于发布及发现符合OASF标准的代理声明文件。

代理目录

Agent工作流服务器: 一个用于部署和运行代理工作流（可能涉及多个代理）并通过ACP暴露这些工作流的参考实现方案。

注意：其他AGNTCY组件包括API桥接代理（通过ACP连接API）、I/O映射代理（语义数据转换）、计划中的人工介入代理、语义路由，以及用于评估、可观测性、安全性和身份的框架。

AGNTCY将安全视为其基本支柱和技术目标，力求采取稳健的基础设施级别方法。

• AGP 安全 : AGP 文档明确提到了使用端到端加密技术、认证和授权。它还提到使用 MLS（消息层安全）和“量子安全加密”等高级目标，这些功能可能在 Agent Gateway 组件中实现。
• ACP 认证 : ACP 要求代理需要认证呼叫者，并定义了代理支持的认证方案，尽管具体的机制超出了 ACP 规范本身。
• 代理身份 : 计划中的一个系统将利用去中心化的技术来管理和验证代理身份，以增强信任。
• 代理安全框架 : 一个计划中的组件专注于识别、跟踪并缓解多代理系统中未经授权的操作、数据泄露和政策违规行为等安全风险。

AGNTCY 采用了一种在其各个组件中集成的分层安全模型，旨在为大规模的“代理网络”提供更高水平的安全保障，可能通过网关基础设施进行管理和实施。

《Getting Started: Build Your First Multi-Agent Software》教程带领您使用AGNTCY的LangGraph框架和Agent Connect Protocol (ACP) 构建一个名为“市场营销活动管理器”的分布式多代理系统（MAS）。它从搭建一个基础的工作流结构开始，通过ACP节点将远程代理如‘邮件组成器’和‘邮件审查器’集成进来，管理复杂的状态模型和协调数据流，并使用语言模型转换代理之间的输出，实现数据流的智能协调。系统还包含一个API Bridge节点，将自然语言输出转换成结构化的API调用，通过_SendGrid_发送邮件，实现自主代理与外部服务之间无缝交互。

出处: https://docs.agntcy.org/pages/如何操作指南/mas-creation-tutorial/mas-tutorial.html.

通过按照教程操作，你可以学会如何从清单文件中生成代理模型，构建一个可以根据用户输入做出条件判断的动态工作流，并生成整个MAS系统的可部署清单文件。最后的步骤会教你如何使用工作流服务器管理器来部署应用程序，这个管理器负责管理依赖项、环境配置和编排等工作。这个流程将教会你如何设计、集成和部署灵活且可组合的多智能体系统。这些系统通过标准化协议有效协作，从而实现复杂且高效的营销活动管理自动化。

下表展示了MCP、A2A和AGNTCY的高层次比较。

表1：MCP、A2A（自动交易）和AGNTCY

MCP 提供了一个标准化的桥梁，连接AI模型与它们所需外部工具和数据，重点在于通过主机控制和用户同意来保障安全。A2A 提供了一种实用的、基于网络标准的协议，以实现不同 AI 代理之间的直接协作和任务协调能力。AGNTCY 展示了最雄心勃勃的愿景，旨在通过一系列相互连接的协议和服务，如 ACP 和 AGP，构建一个全面、安全和可扩展的‘代理互联网’基础设施。