这篇文章试图用一篇文档讲清楚 plugin、tool、skill、MCP、ACP 的概念、区别、联系与选型。
OpenClaw 里这几个词经常一起出现,但它们并不在同一层。
最容易记住的一版是:
•tool 是能力本身,是一个可以被 agent 调用的动作
•skill 是说明书,告诉 agent 什么时候用、怎么用这些能力
•plugin 是扩展包,用来把一组能力接进 OpenClaw
•MCP 是外部工具协议,用来把“OpenClaw 体外”的工具接进来
•ACP 是外部代理协议,用来把“OpenClaw 体外”的 agent 会话接进来
如果只先记一句:
tool解决“能不能做”,skill解决“会不会做”,plugin解决“怎么装进 OpenClaw”,MCP解决“怎么接外部工具”,ACP解决“怎么接外部 agent”。
它们容易混,是因为它们都和“扩展 OpenClaw 能力”有关,但关注点不同:
•有的关注“能力是什么”,比如 tool
•有的关注“模型如何学会使用能力”,比如 skill
•有的关注“能力如何被打包和安装”,比如 plugin
•有的关注“外部能力如何接入”,比如 MCP
•有的关注“外部 agent 如何作为会话接入”,比如 ACP
所以它们不是简单的并列替代关系,而是几层机制叠在一起。
可以把它们理解成下面这几层:
class="language-text">用户意图 ↓ agent 推理 ↓ skill
- 告诉 agent 如何理解任务
- 告诉 agent 什么时候调用什么能力 ↓ tool
- 真正执行查询、写入、搜索、调用接口等动作 ↓ 能力来源
- OpenClaw 内建工具
- plugin 注册的工具
- MCP server 暴露的外部工具
- ACP backend 提供的外部 agent 会话
换句话说:
•
skill更像认知层•
tool更像执行层•
plugin更像封装和集成层•
MCP和ACP更像协议接入层tool是最小的“可执行能力单元”。它通常表现为一个带参数定义的动作,agent 可以像调用函数一样调用它。例如:
•查询某个订单
•搜索网页
•读取文件
•发送消息
•调用你的业务接口
在 OpenClaw 里,工具既可以是内建的,也可以来自插件。
Tool 的核心特征
•它是“动作”,不是说明
•它通常有输入参数和返回结果
•它是 agent 真正落地执行任务的抓手
Tool 不负责什么
tool本身通常不负责告诉模型:•什么时候该调用它
•遇到什么场景优先调用哪个工具
•失败后是否应该重试
这些通常更适合由
skill来补充。skill是给 agent 的说明书和使用手册。它的重点不是“增加一个新动作”,而是:
•教 agent 识别什么场景适合某种处理方式
•教 agent 正确调用现有工具
•给出步骤、约束、注意事项和**实践
Skill 最适合做什么
•规范一个复杂工作流
•告诉模型应该先后调用哪些工具
•告诉模型哪些风险场景需要确认
•把领域知识、经验规则、话术约束注入给 agent
Skill 和 Tool 的关系
一个好记的比喻是:
•
tool是扳手•
skill是维修手册只有扳手,没有手册,模型可能不会用、乱用、或者用得不稳。只有手册,没有扳手,模型知道该怎么做,但没有执行能力。
plugin是 OpenClaw 的原生扩展机制。它不是单一能力,而是一个“能力容器”。一个 plugin 可以向 OpenClaw 注册很多东西,例如:
•
tool•
skill•
channel•
provider•
speech•
hook•
service从设计上看,plugin 解决的是“如何把一组能力集成进 OpenClaw”。
Plugin 的核心价值
•把多项相关能力打成一个整体
•提供配置入口
•提供生命周期管理
•让能力以 OpenClaw 原生方式工作
Plugin 和 Tool 的关系
plugin不是tool的同义词。更准确地说:•
tool是插件里可能注册的一种能力•
plugin是装这些能力的扩展包Plugin 和 Skill 的关系
plugin 可以带 skill。这意味着你可以把“能力”与“使用说明”一起发布:
•tool 负责做事
•skill 负责教 agent 用这些 tool
MCP指 Model Context Protocol,用来把外部工具接进宿主。在 OpenClaw 里,它更接近“外部工具服务器接入方式”。
MCP 解决的核心问题
它解决的是:
•这个能力不一定要写成 OpenClaw 原生 plugin
•我可以把它做成一个独立的外部工具服务
•OpenClaw 再通过协议把它接进来
MCP 最适合的场景
•你有一个已经独立存在的工具服务
•你希望这套工具不只给 OpenClaw 用
•你还想给其他 MCP 客户端复用
MCP 的本质
MCP 接进来的通常还是“工具能力”。
也就是说,它和
tool是同一类能力视角,只是来源不同:•原生 tool:OpenClaw 内建或 plugin 注册
•MCP tool:外部 MCP server 提供
所以可以把 MCP 理解为:
MCP不是能力类型本身,而是外部工具接入协议。ACP指 Agent Client Protocol。它不是“外部工具协议”,而是“外部 agent 运行时协议”。
在 OpenClaw 里,ACP 用来把外部 coding harness 或 agent runtime 接进来,例如:
•Codex
•Claude Code
•Gemini CLI
•Pi
•OpenCode
ACP 解决的核心问题
它解决的是:
•我不是只想调用一个工具
•我是想接入一个外部 agent 会话
•这个 agent 可以持续接收任务、保留上下文、继续协作
ACP 最适合的场景
•你要运行一个外部 agent
•你要让它在某个线程里持续工作
•你要对这个会话做
spawn、status、steer、cancel、closeACP 的本质
MCP 接进来的是“工具”,ACP 接进来的是“agent 会话”。这是它和 MCP 最大的区别。
Tool 与 Skill
区别:
•
tool是动作•
skill是说明联系:
•
skill常常是为了让 agent 更好地使用toolPlugin 与 Tool
区别:
•
tool是一个具体能力•
plugin是能力容器和扩展机制联系:
•plugin 可以注册多个 tool
Plugin 与 Skill
区别:
•
skill是提示与工作流说明•
plugin是安装与集成单元联系:
•plugin 可以打包并分发 skill
Plugin 与 MCP
区别:
•
plugin是 OpenClaw 体内的原生扩展机制•
MCP是 OpenClaw 体外的外部工具接入协议联系:
•两者最终都可能给 agent 提供“工具能力”
•只是一个偏原生集成,一个偏协议接入
一句话理解:
plugin是把能力做进 OpenClaw,MCP是把外部能力接进 OpenClaw。MCP 与 ACP
区别:
•
MCP接入的是外部工具•
ACP接入的是外部 agent 会话联系:
•它们都是 OpenClaw 与外部系统协作的协议层
•但一个面向 tool,一个面向 agent runtime
一句话理解:
MCP是“把外部工具接进来”,ACP是“把外部 agent 接进来”。组合 1:
plugin + tool + skill这是最常见、也最符合 OpenClaw 原生体验的一种组合。
•
plugin负责安装、注册、配置和集成•
tool负责真正执行动作•
skill负责教 agent 何时、如何、安全地使用这些 tool组合 2:
MCP + skill•
MCP负责把外部工具服务接进来•
skill负责告诉 agent 这个 MCP 工具该怎么用组合 3:
ACP + thread/session binding•
ACP提供外部 agent 会话•线程绑定或 session 绑定负责让后续消息继续路由到同一个外部 agent
组合 4:
plugin + MCP更高级的混合方案是:
•你写一个 plugin 负责登录、配置、包装
•再由它桥接到一个 MCP server
可以先问自己两个问题:
1你接入的是“工具能力”,还是“代理会话”?
2你是想深度集成到 OpenClaw,还是想做一个跨生态复用的外部服务?
常见结论
•给 OpenClaw 增加一个具体动作能力:先建模成
tool•给 OpenClaw 增加一整套能力并原生集成:优先考虑
plugin•教模型正确使用一组能力:加
skill•把外部工具服务标准化接入 OpenClaw,且希望跨客户端复用:选
MCP•把 Codex、Claude Code 这类外部 agent 接入为持续会话:选
ACPclass="language-text">如果是外部 agent 会话 -> ACP
如果是工具能力 -> 先看是否主要服务 OpenClaw -> 是:plugin + tool -> 否:MCP
如果能力很复杂、容易误用 -> 再补 skill
假设你有一个数据服务:
•里面有很多 API
•这些 API 需要先登录后才能调用
•你希望 agent 能调用这些接口完成查询和操作
这时最推荐的是:
推荐原因:
•你的本质需求是“给 OpenClaw 增加一组业务能力”
•这些能力适合暴露成多个 tool
•登录、鉴权、token 刷新、错误翻译、权限约束都适合封装在 plugin 内部
•再加一个 skill,可以教 agent 什么时候调用哪个接口
建议做法:
•把登录逻辑封装成统一 client
•暴露少量高价值 tool,不要把每个底层接口都直接暴露
•用 skill 说明“什么意图对应什么 tool”
当你明确希望这套能力被多个 AI 客户端复用时,这个方案更合适。
推荐原因:
•你的数据服务本来就是独立的
•你希望 OpenClaw 之外的客户端也能调用
•你希望它成为统一的“AI 工具接入层”
对于这种“登录后调用很多业务接口”的数据服务,通常不应该选 ACP。
原因很简单:
•你的服务不是一个外部 agent runtime
•它更像一组业务能力
•所以它应该落在 tool / plugin / MCP 这条线上,而不是 ACP
对于大多数业务系统接入,推荐顺序通常是:
1只想服务 OpenClaw:plugin + tool + skill
2明确要跨 AI 客户端复用:MCP
3只有外部 agent 会话场景才考虑:ACP
强烈建议配 Skill 的情况
如果插件符合下面任意几条,就应该认真考虑把 skill 一起做上:
•插件里注册了多个 tool
•tool 名称和业务意图之间不是天然一一对应
•有登录、鉴权、token 刷新、权限边界等前置条件
•有写操作、删除、外呼、支付等高风险动作
•有明确业务流程或 SOP
•某些工具必须按顺序调用,顺序错了就容易失败
•某些失败场景需要特定处理,例如重试、降级、重新登录、请求确认
•你已经发现模型会误用、漏用或乱用这些工具
可以先不配 Skill 的情况
•插件只提供 1 个或极少数几个非常直观的能力
•tool 的用途非常直接,模型几乎不可能理解错
•没有复杂前置条件
•没有明显风险动作
•不依赖严格调用顺序
•不需要复杂异常处理策略
一个最简判断法
•插件只是在提供能力:可以先不配 skill
•插件已经在承载流程和规则:应该配 skill
很多人会问:
Skill 不就是一段更长、更复杂的 prompt 吗?
从纯能力上看,如果你把 SKILL.md 的正文完整复制出来,当作一段 prompt 发给一个具备工具能力的 agent,很多事情当然也能做到。
但从工程上看,skill 的价值在于它把 prompt 工程化、产品化、可复用化。
Skill 的几个关键改进点
1从一次性指令变成可复用能力包
2从单条文本变成结构化封装
3从全量塞进上下文变成按需渐进加载
4从人手工触发变成 agent 可自动发现和调用
5从孤立 prompt 变成可组合模块
6从难以维护变成可迭代、可版本化
7从只会说,更自然地过渡到能动手做
如果你只需要一句判断规则,可以记这个:
•需要一个“动作能力”,先想 tool
•需要把一组能力原生装进 OpenClaw,选 plugin
•需要教 agent 如何使用这些能力,加 skill
•需要把外部工具服务接进来并跨生态复用,选 MCP
•需要把外部 agent 会话接进来,选 ACP
这五个概念看起来经常一起出现,但其实它们分属不同层:
•tool 是执行动作
•skill 是使用说明
•plugin 是原生扩展容器
•MCP 是外部工具接入协议
•ACP 是外部 agent 接入协议
真正好记的一句话是:
tool决定“能不能做”,skill决定“会不会做”,plugin决定“怎么装进去”,MCP决定“怎么接外部工具”,ACP决定“怎么接外部 agent”。
这样再回头看,就不会把它们混成一层了。
本文由山行原创,如果对您有帮助,请帮忙点赞、关注、收藏,谢谢~
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/253965.html