综述文档 · ACP / MCP / Spec / Skills HTML

ACP 和 MCP 的区别，以及“Spec & Skills 是否是未来”的多角度综述

面向：产品/架构决策、Agent 工程落地与生态判断。生成时间：2026-01-04 02:20:55

一句话结论：
  • MCP 更像“模型连接外部工具/数据的标准接口”（连接层）。
  • ACP 更像“智能体之间的通信与协作协议”（通信层）。
  • Spec 是“模型行为与安全规范”（治理/对齐层）。
  • Skills 是“可复用的能力/流程包”（能力/流程层），常与 MCP/ACP 协同，不是简单替代。

1) 关键概念定位

  • MCP（Model Context Protocol）：统一模型与外部数据源、工具的接入方式（例如数据库、SaaS、文件系统、内部服务等）。
  • ACP（Agent Communication Protocol）：统一智能体之间的身份、发现、路由、授权等通信机制，面向多智能体协作与“Agent 网络”。
  • Spec（Model Spec）：描述模型在冲突情境下的决策优先级、安全边界、表达风格等。
  • Skills（Agent Skills）：把完成任务的 SOP、提示、工具调用流程、资源依赖封装为可移植能力包。

2) MCP vs ACP：核心差异

维度 MCP ACP
解决的问题 模型如何安全、标准地连到工具/数据 智能体之间如何发现彼此、通信协作、交易/结算
对象 模型 ↔ 工具/数据源 智能体 ↔ 智能体
类比 “USB/驱动接口” “网络协议 + 身份/寻址/路由”
典型场景 单体 Agent 接入企业系统、知识库、运维工具等 多 Agent 协作、跨组织协同、Agent 市场化服务

3) “MCP 已经过时”是否准确？

更准确的表述是：MCP 目前仍然是“连接层”的重要标准之一；而 Skills/Spec 主要覆盖“能力/流程层”和“治理层”， 二者更多是叠加补位而非替代关系。

为什么不是替代？

  • 层级不同：MCP 解决“怎么接”，Skills 解决“怎么做”，Spec 解决“该不该/怎么表述”。
  • 工程复用不同：把业务流程做成 Skills，仍需要 MCP 去连接所依赖的数据源与工具。
  • 协同更强：当系统演进到多智能体协作，ACP 负责“互联互通”，MCP 负责“各自接入外部能力”，Skills 负责“协作流程的模块化”。

4) “Spec & Skills 才是未来”如何更严谨？

建议改成：Spec 与 Skills 更像是未来 Agent 栈的重要上层拼图，但不会消灭底层的连接/通信协议， 反而需要与 MCP/ACP 组成分层体系。

更可能的“未来栈”分层

连接层：MCP（工具/数据接入）
通信层：ACP（多智能体通信协作）
能力层：Skills（SOP/脚本/资源包）
治理层：Spec（行为、安全、表达规范）

5) 选型建议（按落地场景）

  • 单体 Agent + 企业系统集成：MCP + Skills；用 Spec 统一边界与风格。
  • 多 Agent 协作 / 跨团队：在上面基础上引入 ACP 做身份/发现/路由/授权。
  • 对外开放服务 / 市场化：ACP（通信与身份）+ MCP（对外能力接入）+ Skills（标准化服务包）+ Spec（合规与一致性）。

6) 风险与局限（客观视角）

  • 标准迭代快：版本与兼容需要治理策略（锁版本、迁移计划、回归评测）。
  • 生态差异：ACP 目前更偏特定生态推动，跨生态互通需要评估合作方与部署环境。
  • 安全与审计：无论 MCP/ACP/Skills，最终都要落到权限、审计、数据分级、提示注入防护等工程细节。

7) 可直接复用的沟通话术（更准确）

“我不认为 MCP 过时。MCP 是连接层标准，解决模型如何接入工具/数据；
Spec 约束模型行为与安全，Skills 负责把流程模块化复用；
如果我们走向多智能体协作，再用 ACP 做智能体间通信与身份发现。
未来更像分层协同，而不是互相替代。”

备注：本 HTML 为根据你当前对话中的“综述回答”整理成可下载文档的版本；若你希望加入引用链接/参考资料清单、或按你公司内部栈（如权限/网关/审计）补充“落地架构图”，我也可以继续扩展此文档。