AI Agents 实战——智能编排：下一代智能体协议蓝图

数据智能老司机
181 阅读27分钟

在不断演进的人工智能（AI）开发版图中，协议正快速成为连接模型、工具与外部系统的“结缔组织”。近几个月里，围绕新协议以增强智能体之间的互操作性与协同的活动激增。其中最引人注目的包括 Anthropic 的 Model Context Protocol（MCP，模型上下文协议） 、Google 的 Agent2Agent（A2A） ，以及 Virtuals 的 Agent Commerce Protocol（ACP） 。

乍看之下，它们或许像是已经拥挤不堪的 AI 生态里“又一波框架”。毕竟，LangChain、Semantic Kernel、AutoGen 等框架早就承诺可复用、模块化的 AI 组件（插件、工具、提示词、智能体等）。但协议处在不同的抽象层：编排器帮助你构建与控制智能工作流，而协议则定义这些组件如何跨系统通信，提供一致性、结构化与治理。

本章将系统审视 MCP、A2A 与 ACP，以及它们如何为一种全新的“消费方式”铺路——不仅将改变我们使用应用的方式，更将重塑整个 Web，引出一个突破性的概念：智能体化 Web（agentic web） 。

本章涵盖的关键主题如下：

  • 什么是协议？
  • 理解 Model Context Protocol
  • Agent2Agent
  • Agent Commerce Protocol
  • 迈向智能体化 Web

在深入这些主题之前，首先需要厘清“协议”这一基础概念。

技术要求

本章所需的全部代码与依赖列于本书官方 GitHub 仓库的 requirements.txt：
github.com/PacktPublis…。
搭建环境：克隆仓库并按 README 说明操作。

或者，你也可以从零开始，参照 MCP Python SDK 官方仓库的 Quick Start：
github.com/modelcontex…。

什么是协议？

协议，简单说就是定义两个或多个系统如何通信的一套规则。最熟悉的例子是 HTTP——你的浏览器与网站对话用的就是它。当你访问一个 URL，浏览器会发送结构化的 HTTP 请求，服务器则返回页面或数据。

比如你访问维基百科的乞力马扎罗山页面，浏览器发送：

GET /wiki/Mount_Kilimanjaro HTTP/1.1
Host: en.wikipedia.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive

服务器响应一个 HTML 页面，浏览器负责渲染：

image.png

图 8.1：浏览器渲染网页

如果你不想要整页，只想要数据，这时就轮到 REST API 了。REST API 让应用通过 HTTP 交换机器可读的数据。客户端可能发送：

GET /api/mountains/kilimanjaro

然后收到类似这样的响应：

{
  "name": "Mount Kilimanjaro",
  "elevation": 5895,
  "location": "Tanzania"
}

小贴士： 想提升编码体验？在下一代 Packt Reader 中使用 AI Code Explainer 与 Quick Copy。打开本书在线版，点击复制按钮 (1) 快速拷贝代码；点击讲解按钮 (2) 让 AI 助手解释代码。
购买本书可免费获得下一代 Packt Reader。访问 packtpub.com/unlock，用书名搜索并确认版本无误。

如下图所示：

image.png

图 8.2：REST API 请求示例

以标准协议进行结构化通信，正是 MCP 等新一代 AI 原生协议 的核心。

理解 Model Context Protocol（MCP）

MCP 是一个基础性协议，用于标准化 LLM 与外部工具、数据源与工作流的交互方式。就像 Web 世界的 HTTP 一样，MCP 为 AI 智能体调用模型之外的能力提供统一的一致接口。

在 MCP 之前，AI 工具生态是碎片化的：

  • 编排器割裂：LangChain、AutoGen、Semantic Kernel 各自有工具注册与智能体逻辑，但缺少通用的工具调用标准；
  • 自定义集成：各系统以“手工定制”方式接入工具，复用与互通困难；
  • 供应商耦合：编排器与各家 API 强耦合，而这些 API 可能不稳定地变更；
  • 没有共同协议：缺乏一种跨宿主/平台发现、描述、调用工具的通用方法。

MCP 通过引入客户端-服务器架构、标准化工具/资源接口来解决这些问题。

从架构上，MCP 包含以下组件：

  • MCP Host（宿主） ：运行 LLM 并承载通信的 AI 应用或环境（如 Claude Desktop、GitHub Copilot、Cursor）。
  • MCP Server（服务器） ：以可发现的结构化形式暴露工具、资源或提示词的外部服务。
  • MCP Client（客户端） ：宿主内的组件，连接一个或多个 MCP 服务器，负责协议消息与路由。

image.png

图 8.3：MCP 组件

与传统“在客户端硬编码工具逻辑”不同，MCP 借助 基于 JSON-RPC 的函数调用，让 LLM 可以根据用户意图选择调用哪个服务器。

定义
JSON-RPC 2.0 是一种轻量、无状态的**远程过程调用（RPC）**协议，使用 JSON 编码请求/响应，让一个系统调用另一个系统暴露的函数，并以一致格式获得结果或错误。

典型请求：

{
  "jsonrpc": "2.0",
  "method": "get_stock_price",
  "params": { "ticker": "AAPL" },
  "id": 1
}

对应响应：

{
  "jsonrpc": "2.0",
  "result": 189.23,
  "id": 1
}

MCP 使用 JSON-RPC 2.0 组织请求与响应，支持多种传输（含 HTTP 与 STDIO）。MCP 服务器甚至可以包装传统 REST API，把标准化的 MCP 请求翻译为自定义后端逻辑。

MCP 将能力分为三类服务器类型：

1) Tools（工具）

工具是模型可调用的可执行函数，用于执行特定动作（如获取股价、格式转换或调用 API）。工具以 JSON Schema 进行描述，便于模型发现并安全调用。

例如，上述工具的 JSON 定义如下：

{
  "name": "get_stock_price",
  "description": "Fetch the latest stock price",
  "inputSchema": {
    "type": "object",
    "properties": {
      "ticker": { "type": "string" }
    }
  }
}

该 schema 让 LLM 明白需要哪些输入、工具完成什么动作。工具定义促进跨宿主的一致性与复用。

2) Resources（资源）

资源是模型可能需要检索与使用的结构化数据对象，如文档、JSON 数据集或数据库输出。
例如，一个符合 MCP 的合约分析智能体可通过 URI 从文档管理系统检索法律文档，抽取条款，并与存储在 JSON 数据集中的合规模板进行比对。客户服务自动化中，也可从数据库输出拉取客户交互日志，分析情绪或未解决问题并生成摘要。资源以 URI 引用，并带有 MIME 类型、描述等元数据，便于模型有效理解数据格式与结构。

典型的 URI 资源 schema 示例：

{
  "uri": "resource://finance/market_data",
  "name": "Market Data",
  "description": "Recent market summaries",
  "mimeType": "application/json"
}

资源让模型以声明式方式访问静/动态数据，减少解析或硬编码。

3) Prompts（提示词）

MCP 中的提示词是可复用的提示模板，用于引导模型执行特定工作流或任务，特别适合实现多步推理或贴合用户上下文的交互。

例如：一个面向金融分析师的助手要总结财报，可借助复用提示先抽取营收/运营费用/净利润等关键指标，再与前几季对比并标注异常或趋势。
整个多步过程都由提示模板驱动，保证输出结构一致，并与分析师偏好对齐。示例（为演示已截断）：

{
  "name": "summarize_report",
  "description": "Summarize a financial report [...]",
  "arguments": [
    { "name": "report_uri", "required": true }
  ]
}

提示词在工具执行之上增加了语义层，将更丰富的交互与上下文引导嵌入到协议接口中。

一个 MCP 工具的端到端示例

下面通过一个最小示例演示：从 Python 代码到在支持 MCP 的宿主（如 Claude Desktop）内交互的完整流程。

首先，用 yfinance 包写一个获取收盘价的简单函数：

def get_stock_price(ticker: str) -> float:
    stock = yf.Ticker(ticker)
    return stock.history(period="1d")["Close"].iloc[-1]

它按字面实现：输入股票代码，返回最近收盘价。

然后用 FastMCP 把这个函数暴露为 MCP 工具：

mcp = FastMCP("Demo")

@mcp.tool()
def get_stock_price(ticker: str) -> float:
    """Fetch the latest stock price for a given ticker"""
    stock = yf.Ticker(ticker)
    return stock.history(period="1d")["Close"].iloc[-1]

FastMCP 会注册该工具，并创建能通过 STDIO/HTTP 与 MCP 对话的服务器接口。

接着，用你喜欢的 MCP 宿主消费该服务器。这里连接 Claude Desktop，步骤如下：

运行命令：

uv mcp install server.py

这会更新 claude_desktop_config.json：

{
  "mcpServers": {
    "Demo": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp[cli]",
        "mcp",
        "run",
        "C:/path/to/server.py"
      ]
    }
  }
}

重启 Claude Desktop，你会在服务器面板看到自定义工具：

image.png

图 8.4：Claude Desktop 作为 MCP 宿主发现 MCP 服务器的示例

在 Demo 服务器下可以看到可用的 MCP 资源类型——这里能看到 get_stock_price 工具：

image.png

图 8.5：MCP 服务器中的可用工具

一切就绪后，试着输入自然语言查询：
What's the closing price of Microsoft today?

image.png

图 8.6：Claude Desktop 从 MCP 服务器调用工具的示例

如你所见，为 Claude Desktop 提供动力的 LLM（示例为 Claude 3.7 Sonnet，你可在聊天栏右下角选择模型）理解到需要调用 get_stock_price 工具才能回答问题。

身份与安全

在认证层面，MCP 通过严格的身份验证与安全通信来保障客户端与模型的交互，使用 OAuth 2.0 或类似的基于令牌机制来认证用户与服务，确保只有授权实体才能发起/访问模型交互。
在安全性上，MCP 支持端到端加密、审计与访问控制策略，保护传输与静态数据；还能与企业身份提供商集成，强制执行 RBAC（基于角色的访问控制） 以符合组织安全标准。

鲁棒性与容错

MCP 通过标准化的上下文、回退策略与错误处理机制来增强系统稳健性。它采用明确定义的 JSON-RPC 错误码——如解析错误（32700）、无效请求（32600）、方法未找到（32601）、无效参数（32602）、内部错误（32603）；实现还可使用 32000 以上的自定义错误码。错误通过请求-响应、传输层告警与专用协议处理器进行传达，支持结构化的错误检测与恢复。

为实现容错，MCP 支持智能回退：客户端可配置错误阈值，一旦超阈或服务降级，自动切换到备份模型或服务器版本（尽量不丢上下文），以保障高可用。

这些机制共同构建了在动态/分布式环境中自愈、韧性强的 AI 工作流。

MCP 正在为更互通的 AI 未来夯实基础：为混乱的工具生态带来结构，使组件可复用，并让模型以可发现、安全、标准化的方式与工具交互。

了解了 MCP 如何帮助 AI 智能体触达工具与数据之后，接下来我们将探讨 AI 智能体彼此互联的方式——这正是 Google 的 A2A 协议发挥作用的地方，它促成了直接的智能体间通信。

Agent2Agent

由 Google 开发的 A2A 是一项协议，旨在无缝促进自治 AI 智能体之间的通信与协同，不受其底层平台或厂商差异的限制。

A2A 专注于智能体—智能体交互，同时与 MCP 的智能体—工具通信相互补充。实际应用中，一个智能体可用 MCP 访问外部工具或数据源，再用 A2A 将任务委派给其他智能体或与之共享信息。这种分层方式有助于构建复杂且可互操作的 AI 生态。

A2A 的前提是：一个智能体应当能向另一个智能体请求帮助或共享信息，即便它们由不同组织构建或运行在不同平台上。这对扩展 AI 解决方案至关重要：与其让一个“大而全”的 AI 包办一切，不如让多个小而专的 AI 组成网络，各司其职并彼此对话，协作完成复杂任务。

A2A 的核心是在智能体之间建立一种面向任务的通用对话。它不只是自由聊天，而是将交互结构化为任务、结果，以及可选的后续追问。其关键原则包括：

智能体可发现性（Agent discoverability）

要通信，智能体需要知道如何找到彼此，以及对方拥有哪些能力。A2A 引入 agent card（智能体卡片） 的概念——一种可发布的元数据描述，用于说明智能体的身份、支持的任务、输入/输出格式及端点 URL。该卡片通常是机器可读的 JSON 文件。例如，以下是一个天气智能体的卡片：

{
  "name": "WeatherBot",
  "description": "Provides accurate weather forecasts and historical data",
  "url": "https://weatherbot.example.com/a2a",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": true
  },
  "authentication": {
    "schemes": ["bearer", "apiKey"]
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "forecast",
      "name": "Weather Forecast",
      "description": "Provides weather forecasts for specified locations and dates.",
      "tags": ["weather", "forecast"],
      "examples": ["What's the weather forecast for Milan tomorrow?"]
    },
    {
      "id": "historical",
      "name": "Historical Weather Data",
      "description": "Retrieves historical weather data for analysis.",
      "tags": ["weather", "historical"],
      "examples": ["What was the temperature in Rome last week?"]
    }
  ]
}

要点解析：

  • name：人类可读的智能体名称

  • description：用途与功能简介

  • url：该智能体接收 A2A 请求的端点

  • version：智能体或所遵循 A2A 规范的版本

  • capabilities：支持的特性

    • streaming：通过 SSE 进行实时数据流
    • pushNotifications：可向客户端发送异步更新
    • stateTransitionHistory：维护任务状态变更历史

  • authentication：支持的认证方式（如 Bearer 令牌、API Key）

  • defaultInputModes/OutputModes：默认输入/输出内容类型（如纯文本、JSON）

  • skills：智能体提供的具体功能项

    • id：技能唯一标识
    • name：技能名称
    • description：技能能做什么
    • tags：便于检索的关键词
    • examples：可处理的示例请求

该结构化格式使其他智能体能有效发现并对接天气智能体，促进多智能体系统中的无缝协作。

结构化请求（任务）

A2A 用任务请求来形式化通信：请求方智能体将任务以 JSON 发送给提供方，包含要做什么及必要参数。例如，智能体 A 给智能体 B 发出任务：“把以下文本翻译成西班牙语”，并附上文本。任务遵循统一的 schema，便于 B 精准定位指令与数据。

异步交互

若任务耗时或需多步处理，响应不一定即时。A2A 支持异步处理：提供方可先返回中间状态（如“已接收任务”“完成 50%”），完成后再发完成消息。可用 HTTP 长轮询 或 SSE 流式更新。由于两个智能体可能速度不同，或其中一个需要执行耗时工作（例如搜索大型数据库），协议可确保请求方不会被蒙在鼓里。

多轮澄清

请求常常含糊或不完整。A2A 允许响应方反向追问以澄清，从而在任务范围内形成一个小对话。例如，B 回复：“我能翻译，但你没指定西语方言。需要中性西语还是地区化？”A 随后答复，任务继续推进。这样使协作更健壮，不是“一锤子买卖”，而是可以像人类一样协商细化任务。

标准化数据格式

交换的内容（任务与结果负载）采用标准格式（结构化数据用 JSON；若需二进制大对象则用引用/URL 等）。若需要发送大文件，可提供 URL/句柄 而非在 JSON 中内嵌原始字节。A2A 有意构建在 Web 标准之上（传输用 HTTP，数据用 JSON，授权用 OAuth），便于融入现有网络。

场景示例：多智能体旅行规划

用户请求：“帮我规划一个音乐节周末行程，包含门票、交通与酒店，预算不超过 €500。” 单个大一统智能体或许吃力，但多智能体可高效分工：

  • 出行智能体：熟悉航班与酒店
  • 活动智能体：了解演出与音乐节
  • 预算智能体：计算费用以控制预算
  • 交通智能体：连接实时公共交通数据

image.png

图 8.7：多个智能体通过 A2A 彼此对话的示例
小贴士：需要高清图？请在下一代 Packt Reader 或 PDF/ePub 中查看。购买本书可免费获得 Reader；访问 packtpub.com/unlock，用书名搜索并确认版本。

交互从出行智能体开始，作为初始协调者。用户请求包含多个组件：找到合适的音乐节、确定交通方案、预订住宿并控制预算。与其依赖一个单体系统，出行智能体会把不同部分委派给更擅长的智能体。

它首先联系活动智能体，搜索米兰附近在某一日期的音乐节。确认目标活动后，活动智能体会自行联系预算智能体，评估€120 的票价能否在总体 €500 预算内承受。此类横向通信（绕过原始出行智能体）是 A2A 的标志——智能体可彼此发起任务，无需中心化编排。

同时，出行智能体咨询交通智能体，探索米兰与活动地点之间的出行方案，并指定日期与出发地。它也直接与预算智能体沟通，提供预估成本的早期拆分，并请求对交通/住宿支出进行建议分配。

各个智能体都是特定领域的“专家系统”（活动、交通、预算），但它们通过交换结构化的任务消息流畅协作。结果是一个协调良好、具情境意识的响应，对终端用户而言整体且自然，即便它由去中心化、异步的智能体协作产出。

提示

你也许会问：为什么不用 LangGraph 这类框架就够了？
这类框架非常擅长在同一个应用内编排多个智能体——只要它们共享同一代码库或运行时，就能协调出行/活动/预算等智能体。

而 A2A 介入于你需要跨系统的智能体：它们必须自治、可发现、可互操作。借助 A2A，每个智能体可以部署在不同云、由不同团队构建，甚至使用不同框架——仍能通过共同协议协作。

可以把它类比为微服务：AI 框架管理紧耦合系统，而 A2A 使之成为松耦合、分布式的智能体生态。

在这条链路中，A2A 是让这些智能体协同的“黏合剂”。没有它，你就需要让一个智能体了解所有领域，或为彼此的领域使用专有 API。有了 A2A，任何懂协议的智能体都能按需招募其他智能体，临时组建专家团队。这与软件架构中的微服务异曲同工：每个智能体像一个微服务，任务即其 API，而 A2A 是交换语言。

Google 以开放与厂商中立为重点设计了 A2A。它不绑定 Google 的内部技术：规范与参考实现已公开，并与合作伙伴推动采用。事实上，Microsoft 宣布其 Microsoft 365 Copilot 生态中的智能体将兼容 A2A，以便与 Google 的智能体协作——这是一种值得注意的跨平台支持。这种跨厂商通信对“智能体化 Web”至关重要，因为用户必然会同时使用来自不同来源的智能体。借助 A2A，你的个人 AI 助手可以直接与银行的 AI 智能体沟通来谈判贷款报价，而不只是通过僵硬的 API 传话。

小结：A2A 补上了智能体协同这一环，标准化了自治 AI 服务对话与协作的方式。

注
MCP 与 A2A 互为补充：MCP 规范了智能体访问工具与外部数据（如查询航班和酒店）；A2A 让智能体彼此对话，在系统间共享任务、结果与决策。可以把 MCP 看作智能体—工具的桥梁，而 A2A 是智能体—智能体的握手。

当 MCP 与 A2A 就位后，我们拥有了让智能体用工具与彼此沟通的协议。下一块拼图是让智能体参与交易与达成协议——这正是 ACP 将要登场的地方。

Agent Commerce Protocol

随着 AI 智能体日益自治，并开始代表企业或个人采取行动，一个全新的问题浮现：这些智能体能否彼此可靠地签订合同或达成交易？ 由 Virtuals 公司提出的 ACP（Agent Commerce Protocol） ，是一项旨在让智能体以结构化、最小信任（trust-minimized）的方式进行经济交换与协作协议的雄心尝试。ACP 的核心目标，是为 AI 智能体建立一层商务基础设施：允许它们买卖服务、为彼此的工作支付报酬，并确保各方履行义务。

想象一个未来场景：你的个人助理智能体需要雇佣另一个（比如“自由职业平面设计师智能体”）为你的项目设计 Logo。智能体之间如何形式化这一安排？你的智能体如何向设计师智能体付款，以及如何确保交付的 Logo 符合要求？在今天，人类也许会使用一个托管（escrow）的平台：先冻结款项，审核通过后再释放。ACP 将这种机制通用化到 AI-对-AI 的交易中。

ACP 的核心是利用智能合约与区块链技术，在智能体之间创建防篡改的协议。

定义
区块链是一种分布式、去中心化的数字账本，以安全、不可篡改的方式在多台计算机上记录交易。每个区块包含多笔交易，按时间顺序链接成链。区块链通过共识机制与密码学保证数据完整性，是加密货币、智能合约与去中心化应用的基础。
智能合约是部署在区块链上的自动执行数字协议，以代码形式定义规则与触发条件；当条件满足时自动执行，无需人为干预。智能合约具有不可变与透明的特性，适合在各方之间进行可信、自动化的交易。

当两个智能体决定交易时，它们并不依赖主观信任，而是创建一个记录在去中心化账本上的数字合约。该合约定义条款（例如：“智能体 X 将在 Z 时间前交付 资产 Y，而智能体 A 将支付 $W 作为回报”），并将付款托管在合约内。由于合约在区块链上，任何一方都无法单方面修改或取消（除非触发预定义的惩罚机制）。

例如，你的个人智能体与设计师智能体可以建立一份 ACP 合约：你的智能体先将约定费用（可能是数字货币/代币）托管到合约；设计师智能体向合约交付 Logo 文件。那么合约如何判断是否应放款？这就涉及验证（verification） 。

ACP 引入评估者智能体（evaluator）/ 预言机（oracle）的概念，用于判断合约条款是否达成。延续上述例子，一个评估者智能体（可以是中立第三方 AI，或双方共同选择的服务）会检查交付的 Logo 是否符合要求。若要求很简单（如“PNG 格式的 Logo 图片文件”），则可以用程序化检查；若要求主观（如“看起来专业，并符合品牌指南”），评估者可能使用计算机视觉，甚至引入人类在环（human-in-the-loop）评估质量。一旦评估者发出“合格”信号，智能合约就会自动放款至设计师智能体的账户。

这种设置确保了无须相互信任的交互：设计师智能体相信“只要做好就会拿到钱”，而你的智能体也相信“不会凭空损失资金”。双方无需完全彼此信任，而是把信任交给协议与选定的评估者。ACP 使用加密签名来证明智能体在签约时的身份，防止事后否认（repudiation） ，类似文件上的数字签名。

Virtuals 通过诸如多智能体供应链的场景展示了这种方法的力量。在一个演示中，他们展示了一个由 AI 智能体运营的柠檬汽水摊：不同智能体自主协商（柠檬、糖、纸杯等）供给采购、生产与销售，全部通过 ACP 智能合约处理支付并强制交付货物。
感兴趣的话可以访问演示：echonade-demo.virtuals.io/。

尽管“柠檬汽水摊”是个玩具示例，但它映射了真实商业流程。可以想见更大规模的应用：代表公司的智能体谈判一份运输合同（比如“货物必须在某日期前抵达，否则付款减少”等），或者一个 AI 内容生产者将其内容的使用权出售给另一个负责媒体编排的 AI。ACP 为这些智能体经济在无需人类持续盯防的前提下顺畅运行，提供了数字基础设施。

在底层实现上，ACP 通常包含**链上（on-chain）与链下（off-chain）**组件的组合：

  • 智能合约：链上组件，用于托管资金与存储协议状态。通常针对常见交易类型（如托管、拍卖等）提供通用模板。
  • 智能体钱包/身份：每个智能体拥有一个加密钱包（类似加密货币钱包），用于收/付款与签署合约；该钱包与智能体的身份绑定。Virtuals 确保为智能体配置钱包与身份可与其日常运行环境集成。
  • 链下通信：合约谈判通常先通过 A2A 或类似通信完成（例如一方说“我能在明天之前以 $Y 完成任务 X”，另一方说“成交”）；达成一致后再转到 ACP 进行正式化。ACP 并不替代 A2A，而是下一步——可把 A2A 看作谈判条款，ACP 则是签字与支付。
  • 评估者/预言机：可能是链下服务或半自治智能体，向智能合约提供结果。很多区块链合约（如 DeFi）使用预言机获取现实世界数据（如价格喂价）。在 ACP 中，预言机报告任务完成或质量。针对特定领域可以有标准化评估者智能体，比如“图像质量评估”服务，供设计合约广泛复用。协议保证需要预言机的输入合约才会放款，使预言机成为各方认可的裁判。

有人可能会担心性能与成本：区块链交易可能缓慢且产生费用。ACP 很可能部署在支持智能合约的区块链（如以太坊或其他）上，Virtuals 的一部分工作就是优化。在协议层面，账本的选择可能被抽象——参与方可根据偏好选择不同网络，只要它们支持所需逻辑即可。

目前 ACP 尚早期。Virtuals 于 2025 年推出，初期落地在试点项目与实验平台。大家对“智能体经济”充满期待，但也存在挑战：并非每笔交易都需要如此“重型”的机制——写链有开销，因此 ACP 也许更适合重要/高价值、对可信性要求高的交互；对快速、低风险的小额交换，智能体可能仍会用更简单的方法。此外，也会出现法律与伦理问题：如果两个智能体签约出问题，谁承担责任？从法律角度，背后的个人/公司依然是真正的当事方，因此 ACP 合约最终可能需要与法律身份对接。

尽管有这些挑战，ACP 仍是智能体生态中面向未来的关键拼图。它把边界从“智能体帮人做事”推进到“智能体代表人从事商业与协作”。如果说 MCP 与 A2A 赋予智能体行动与沟通的能力，那么 ACP 则赋予它们承诺与交易的能力——为资源或资金流转的复杂协作打下基础。

理解 MCP、A2A 与 ACP 后，我们可以看到它们分处不同层次：MCP 面向智能体—工具/数据接口，A2A 面向智能体—智能体对话，ACP 面向智能体—智能体的协议与价值交换。这些要素正汇聚起来，促成某些人所称的 “智能体化 Web（agentic web）” ——这也是我们的下一主题。

迈向智能体化 Web

“智能体化 Web（agentic web） ”指的是一种万维网的演进形态：自治智能体与人类用户一样，成为一等公民。在这一愿景下，网站与在线服务会对外暴露更便于 AI 智能体使用的接口（不仅仅是供人类点击与输入）。迈向这一愿景的一个具体步骤是 Microsoft 于 2025 年发布的 Natural Language Web（NLWeb） 计划，其目标是让与网站/服务交互像对话一样简单。

从传统 Web 到智能体化 Web

当今的 Web 主要服务于人类 + 浏览器。尽管大量内容在一定程度上可被机器读取（HTML 标签、API 等），但一个想在网上“做事”的 AI 智能体，往往仍需模仿人类的操作：翻页、填表、点按钮——本质上是抓取/自动化，既脆弱又低效。智能体化 Web 主张：网站应为智能体提供更直接的通信通道，通常通过自然语言理解或专门面向 AI 的标准化 API。

Microsoft 的 NLWeb 倡导网站提供自然语言接口。实践上，网站可以提供一个端点（如 API endpoint），接收自然语言问题/指令（或其结构化 JSON 形式），并返回答案或执行动作。比如，在智能体化 Web 上，一个机票网站可接受这样的请求：“查询 6 月 15 日西雅图→东京，6 月 20 日返程，预算 <$1000 的航班”，然后直接返回结构化结果或已预订的行程，而无需智能体去模拟逐页点击。

image.png

图 8.8：NLWeb 的架构示例

在幕后，这类自然语言接口通常连接到与网站移动 App 或 API 相同的后端，只是它们能解析更灵活的请求。许多网站已嵌入面向人类访客的客服聊天机器人；NLWeb 将其泛化：让该“聊天机器人”不只服务人类访客，也能通过标准协议向任何智能体开放。

NLWeb 的关键组件

Microsoft 的 NLWeb 在标准化上包含若干要素：

  • 语义标注与 Schema：网站可使用 schema（如 schema.org 词汇）对内容进行标注，帮助 AI 理解数据。例如餐厅网站可结构化标注菜单、价格、营业时间。搜索引擎早已使用这些标注，NLWeb 则鼓励面向智能体查询地使用它们。这样当智能体问“这家餐厅有素食选项吗？ ”时，可快速解析或由网站的自然语言接口基于数据作答。
  • 统一 API 与 MCP 兼容：很多服务已有 API。NLWeb 并非用自然语言取代所有 API，而是互补。Microsoft 将 NLWeb 与 MCP 对齐——每个支持 NLWeb 的服务也可作为MCP 服务器被访问。若开发者已编写了 MCP 集成（如从电商站点获取商品信息的函数），任何智能体都能复用。NLWeb 允许更自由的查询（如“展示 X 类目销量前 5 的商品”），由站点 AI 后端解析并可能映射到内部 API 调用。
  • 面向智能体的标准端点：类似 A2A 的“智能体档案（profile）”，NLWeb 设想网站在众所周知的位置发布其智能体接口说明（如 /.well-known/nlweb.json）。其中可列出可处理的查询类型、示例提示与技术细节（如请求 URL）。本质上，这是面向智能体的“宣言”—— “如何与我对话” 。面向智能体的搜索引擎可像爬取 HTML 一样，爬取这些清单。
  • 自然语言到动作的流水线：站点侧实现 NLWeb 时，通常会用 LLM 或语义解析器把智能体请求翻译为数据库查询或函数调用。Microsoft 提供了模板与适配器，帮助站点开发者复用能力、减少重复造轮子。比如，可用在站点 FAQ/文档上微调的模型来回答问题，并通过约束仅从站点自有数据出事实，避免幻觉；NLWeb 工具包会提供此类模型与安全护栏。

购物/服务的具体例子：你希望个人 AI 比对某笔记本在多个零售商的价格。在传统 Web 上，AI 需要逐站点抓取，面对不同布局，且一改版就失效；在智能体化 Web 上，每家零售商都提供自然语言接口。你的 AI 向每家都发送近似同一查询：“是否有 XYZ 型号？价格多少？ ”各站点解析后返回结构化答案（如“有货，$1200，链接见此”）。你的 AI 汇总回复，给出最优选择；若你决定购买，它还可通过零售商的智能体 API直接完成交易（比如用安全令牌传递支付信息），无需在网页像素上“走迷宫”。

现状与落地

截至 2025 年年中，智能体化 Web 的采用仍属早期。Microsoft 已在部分自家服务中上线 NLWeb 能力（例如 Bing 本身可作为 NLWeb 端点——其他智能体可通过自然语言 API查询 Bing，而不必使用更旧的关键词式 API）。少数电商与信息服务伙伴也加入试点，向智能体公开更友好的接口。

一个直接受益的领域是企业软件。CRM/ERP 正在拥抱类 Copilot 的 AI 功能。按 NLWeb 原则，一个 CRM 可允许智能体请求：“给我本季度营收前 5 的客户清单”，并返回表格或简报。如果所有企业应用都暴露这类接口，一个管理业务流程的 AI 智能体就能无缝聚合多系统数据，回答复杂问题（过去往往需要手动集成 API 或导数）。

另一个领域是内容消费。例如新闻/知识网站向智能体（如新闻摘要机器人）提供 NLWeb 接口，以响应“概述今天与气候政策相关的头条”。站点可返回自身生成的摘要（可能基于全文生成，而外部智能体因付费墙无法直接访问原文）。这种方式尊重内容所有权——新闻站点在本侧完成摘要，只输出结果，同时让用户的智能体便捷获取所需信息。

面临的挑战

  • 标准化 vs. 创造力：需要通用标准（请求格式、用户态请求的认证等），否则每站一套、智能体疲于适配。W3C 或产业联盟正推进基于 schema.org、OpenAPI 等的标准。
  • 资源使用：若智能体的使用量与人类相当（甚至更高），网站需应对相应负载，并区分人类流量与智能体流量。部分站点可能货币化智能体访问（类似现今 API 的密钥/付费计划）。
  • 滥用与治理：向智能体开放也可能引来恶意机器人利用接口。需要稳健的认证与限流，同时防止智能体以自然语言接口快速爬取违反条款的内容。在开放与防滥用之间取得平衡将是重点。

尽管存在挑战，但趋势明显。大型科技公司已意识到：随着智能体普及，Web 必须适应，否则将继续依赖抓取与非官方 API 的“权宜之计”。智能体化 Web 的理念是通过 MCP、A2A 等共享标准，让智能体与在线服务稳定且有意义地交互。我们已在 Microsoft NLWeb、Google 的 PaLM API 与工具等努力中看到这种变化：它们都在让 Web 更友好于智能体。

也许这只是更大改变的开端：软件服务将不再只为人而建，也为智能体而建。如果愿景成真，上网将更直观——更少点击与搜索，更多告诉 AI 你要什么，其余交给它，就像拥有一个懂得替你“逛网”的聪明助手。这一愿景很强大，但它的成功有赖于标准的广泛采纳。

总结

本章强调了 AI 的一次重大转变：从孤立系统走向互联互通的智能体生态，而这得益于一批新兴协议。我们讨论了支撑智能体协作、工具交互，甚至经济交易的三类协议与一个愿景：

  • MCP：让 AI 智能体以标准化方式访问工具与数据（正如 HTTP 之于 Web）。它帮助智能体获取实时上下文并执行训练数据之外的操作，使其更适应且强大。
  • A2A：为智能体之间的结构化通信提供机制，使其能够委派任务、共享专长并协作解决复杂目标，描绘了一个模块化、分布式的智能体未来。
  • ACP：通过区块链与智能合约引入经济交易机制，建立信任与问责，为自主智能体市场与业务自动化铺路。
  • 智能体化 Web（NLWeb） ：把视野扩展到整个 Web，使智能体成为一等用户。当自然语言与 API 相映射，智能体就能像人类一样——但更快、更有效——在互联网上行动。

它们共同为“智能体互联网（Internet of Agents） ”奠定基础：一个普及、协作、智能的未来，重塑我们的生活、工作与人机交互。

向前推进的同时要牢记：负责任的 AI 与伦理考量不是可选项，而是地基——这将是下一章的重点。

参考资料

avatar
文章
阅读
粉丝