ACP 协议定义解析（详解两个最常见含义：智能体通信 vs 智能体商业结账）

“ACP”在 2025-2026 年的 AI 圈同时承载着两个主流含义：一个是 IBM Research 提出的 Agent Communication Protocol（智能体通信协议），用于让 AI 代理彼此发现、委派任务、共享上下文；另一个是 OpenAI 与 Stripe 联合推出的 Agentic Commerce Protocol（智能体商业结账协议），用于让 AI 代理在用户授权下安全下单支付。两者名字相同但解决的是不同层的问题：前者属于”代理之间怎么对话”，后者属于”代理怎么替用户付钱”。理解这条分界，可以避免在协议选型时把通信层与支付层错配。

一、为什么同一个缩写会撞车

2025 年起 AI 代理生态进入”协议化”阶段，MCP、ACP、A2A、AP2、x402 等缩写密集出现。这些协议大多由不同主体在相近时间窗提出，又都被开源或捐赠给中立基金会，于是缩写复用几乎不可避免。ACP 之所以被两个不同阵营同时使用，是因为”Agent”+”C”+”P”三个字母在”通信”和”商业”两个语境下都很自然。截至 2026 年初，并存的两个 ACP 都进入了生产或大规模公测阶段——任何人在工程文档里看到 ACP 缩写，都必须先确认语境。

二、含义一：IBM 的 Agent Communication Protocol（智能体通信）

2.1 它解决什么问题

IBM Research 在 2025 年 3 月随开源平台 BeeAI 一起推出 ACP，目的是让不同框架、不同语言写的 AI 代理能像浏览器和网页那样通过标准协议彼此协作。在 ACP 出现之前，每个代理框架（LangChain、CrewAI、Autogen、自研系统）都自带一套 JSON 消息格式、鉴权方式和流式协议——N 个代理之间需要 N×(N-1)/2 个手工连接器。ACP 把这个二次方成本压缩成线性：每个代理实现一次协议，新加入者只需要再写一个适配器。

2.2 核心设计

• REST + JSON 载荷，OpenAPI 描述：用最常见的 Web 语义承载代理通信，curl/Postman/浏览器可直接调用。
• Agent Card 发现机制：每个代理发布 JSON 清单描述自己接受什么、返回什么、支持哪些 MIME 类型。
• 任务生命周期：统一建模为状态机——submitted → working → input-required → completed / failed / canceled，可流式推送进度。
• 本地优先（local-first）：能在隔离网络、边缘设备、气隙环境中跑，适合金融、医疗、军工等强合规场景。

下面给出一段发起任务的最小化示例，体现 ACP 与一般 REST API 的差别在于结构化”任务信封”：

POST /tasks HTTP/1.1
Host: agent.example.com
Content-Type: application/json

{
  "task": "解析本季度的销售 CSV 并生成执行摘要",
  "context": { "files": ["q3.csv"], "deadline": "PT30M" },
  "requestedCapabilities": ["data-analysis", "report-generation"]
}

服务器返回的是结构化任务对象而不是单次响应——客户端可以轮询、订阅 SSE 流或异步等待回调。需要注意的点：调用前要确认目标代理的 Agent Card 描述了哪些能力，避免发出去的任务落入”未声明能力”的拒绝路径；调用后要把 task_id 持久化，因为 ACP 的长任务模型意味着结果可能在数分钟后才返回。

2.3 与 MCP、A2A 的关系

ACP 不是孤立存在，常被拿来与 Anthropic 的 MCP、Google 的 A2A 并列。粗略分工如下：

值得注意的是，IBM 的 ACP 在 2025 年 8 月宣布与 A2A 合并，规范层面 ACP 的设计被并入 A2A；但 BeeAI 平台仍以 ACP 风格运行，并通过适配器桥接到 A2A 生态。引用协议名时务必注明时间窗。

三、含义二：OpenAI × Stripe 的 Agentic Commerce Protocol（智能体商业结账）

2.1 它解决什么问题

OpenAI 与 Stripe 在 2025 年下半年联合发布了 Agentic Commerce Protocol（同样缩写 ACP），目标是让 AI 代理在用户授权下完成真实下单与支付，而不把商家锁死在某个平台。ChatGPT 的 Instant Checkout 是早期落地形态。

2.2 核心机制

• 结构化订单：用 JSON Schema / OpenAPI 描述商品、价格、履约条款，AI 看到的是机器可读合同而不是自然语言。
• 共享支付凭证（Shared Payment Token）：Stripe 把用户的支付方式抽象成一次性令牌发给代理，代理只能用于指定订单、不留存卡号。
• 商家保留控制权：AI 调用的是商家 checkout 接口，履约、退款、客服仍由商家系统负责，避免 AI 直接”成为商家”。
• 兼容现有电商后端：通过 REST 或 MCP 暴露能力，商家不必重写系统即可接入。

下面给出一段代理下单的最小化代码骨架，体现”用户授权→代理下单→商家确认”的链路：

# Agentic Commerce Protocol: 代理代用户下单的最小链路
def agent_checkout(user_intent, payment_token, merchant_endpoint):
    order = build_structured_order(
        user_intent,                # 用户原话："买一本《深入理解 ACP》"
        schema=ACP_ORDER_SCHEMA,    # JSON Schema 描述订单结构
    )
    response = requests.post(
        f"{merchant_endpoint}/acp/checkout",
        json=order,
        headers={"Authorization": f"Bearer {payment_token}"},
    )
    if response.status_code == 402:
        return require_user_confirmation(response)   # 需用户再次确认
    return response.json()["confirmation"]

这一段解决的核心问题是”AI 不能越权下单”。前向要校验用户意图与订单结构是否一致，避免代理把”看看”理解成”买”；后向要处理 402 Payment Required 等需要用户再次确认的分支——任何绕过用户授权的自动扣款都应被协议层拒绝。

四、两套 ACP 的关键差异

虽然名字一样，但两套协议的设计目标、技术栈、治理模式完全不同：

落到工程层面，区分方法很简单：看”主语”是代理对代理还是代理对商家——前者是 IBM ACP，后者是 OpenAI×Stripe ACP。文档里若提到 Shared Payment Token、Instant Checkout、Stripe Issued 字段，几乎可以确定是商业结账协议；若提到 BeeAI、Agent Card、任务信封，指向的就是通信协议。

五、选型与落地步骤

工程团队把 ACP 落地通常分四步走，顺序错了后续会反复返工：

1. 明确问题域：先判断是”代理对代理”还是”代理对商家”，再决定接入哪一套 ACP，不要为同名协议反复纠结。
2. 做协议适配器：在现有代理框架外层包一层 ACP SDK（IBM 官方提供 Python/TypeScript 实现，OpenAI×Stripe 一侧走 Stripe 提供的 API 包装）。
3. 接好鉴权与状态：通信版接入 Capability Token 与 RBAC 桥接；商业版接入 Shared Payment Token 与订单状态机。
4. 跑端到端联调：用一个最小可下单场景（如多代理联合生成报告、ChatGPT 即时结账测试）跑通，验证任务信封、回调、回调失败回滚三条路径都正常。

补充几条更细的选型指引：

到这里，两个 ACP 的差异就清晰了：名字是历史巧合，问题域才是真正的分水岭。引用时把”ACP（通信）/ ACP（商业）”的限定语写全，可以省掉 80% 的沟通成本。

常见问题（FAQ）

Q1：ACP 是哪个组织定义的？

两个：IBM Research 的通信协议已捐给 Linux Foundation；商业结账协议由 OpenAI 与 Stripe 联合发布。

Q2：ACP 和 MCP 怎么配合？

MCP 把代理连到工具与数据，ACP（通信）把代理连到代理，二者常在同一多代理系统中叠加使用。

Q3：ACP 会被 A2A 取代吗？

通信版的 ACP 在 2025 年 8 月与 A2A 合并，但商业结账版的 ACP 与 A2A 没有替代关系。