第 25 章

Skills vs Plugin 决策框架：能力边界对比与协作模式

第25章　Skills vs Plugin 决策框架：能力边界对比与协作模式

25.1　从第一原理理解两种扩展机制

在做出"用 Skills 还是用 Plugin"的决策之前，先回到第一原理：这两种机制究竟在做什么？

Skills 的本质是知识注入。当 Agent 处理请求时，Skills 将一段精心编写的上下文注入推理循环——告诉 Agent "在这种情况下，应该这样思考，这样行动"。Skills 是文本，它在 Token 消耗的代价下运行，在推理循环的边界内工作。

Plugin 的本质是能力扩展。Plugin 在系统启动时修改 OpenClaw 的能力集——添加新的消息通道、新的工具端点、新的 Provider 接口。Plugin 是可执行代码，它在系统进程的层面工作，不消耗推理 Token。

这两种机制不是竞争关系，而是互补关系。理解这一点是做出正确决策的前提。

25.2　8维度完整对比表

维度	Skills	Plugin
运行层	推理时（inference-time）	启动时（startup-time）
实现形式	Markdown 文本（SKILL.md）	可执行进程（TypeScript/JavaScript）
加载时机	按需加载（Trigger 匹配时）	系统启动时固定加载
Token 消耗	消耗推理 Token（每次推理都注入）	零 Token 消耗（在 Token 循环外运行）
能力上限	受限于 Agent 现有工具集	可添加全新的系统能力
迭代速度	极快（编辑 Markdown 即时生效）	较慢（需要代码编写/编译/重启）
配置位置	Workspace 级或用户级	系统级（openclaw.config.yaml）
安装方式	`openclaw skill install` / 直接放入目录	`openclaw plugin install` / npm 包

维度详解

运行层的含义

这是最重要的维度。Skills 的内容在 Agent 推理时被读取，就像 Agent 在思考前查阅一本参考书。Plugin 的代码在 OpenClaw 进程启动时执行，就像在建筑开放前完成电气安装。

一个 Skill 在 Agent 不处理相关请求时完全不存在于计算资源层面。一个 Plugin 始终处于运行状态，随时准备接收调用。

Token 消耗的战略意义

Skills 的最重要限制是 Token 成本。每次推理，所有激活的 Skills 都会被注入到上下文中，占用有限的上下文窗口，产生真实的 API 调用费用。

一个设计不佳的 Skills 集合（大量宽泛 Trigger + 冗长 SKILL.md 内容）可能让每次推理的 Token 消耗增加 30-50%，在高频使用场景中产生显著的成本差距。

Plugin 完全不参与 Token 消耗——它的工具调用结果作为工具响应进入上下文，但工具定义（schema）是一次性注入的，与 Skill 的每次全量注入本质不同。

迭代速度的实践意义

在开发初期或需求未确定时，Skills 的极快迭代速度是决定性优势：

Skill 迭代：
编辑 SKILL.md → 保存 → 下次 Agent 处理请求时立即生效
（全流程 < 30 秒）

Plugin 迭代（生产模式）：
编辑 src/index.ts → tsc 编译 → 重启 OpenClaw → 验证行为
（全流程 5-15 分钟）

Plugin 迭代（开发模式，jiti）：
编辑 src/index.ts → 触发热重载
（全流程 < 10 秒，接近 Skill）

25.3　Plugin 能做但 Skill 不能做的10个场景

场景1：新增消息通道

需求：让 Agent 能响应 Telegram 消息
Skills：不可能。Skill 无法注册新的消息监听器
Plugin：✓ api.registerChannel({ id: 'telegram', ... })

Skill 只能影响 Agent 在已存在通道中的行为，无法创建新的通道入口。

场景2：暴露 HTTP 端点

需求：为第三方系统提供 /api/agent/invoke 端点
Skills：不可能。Skill 无法注册 HTTP 路由
Plugin：✓ api.registerHttpRoute({ path: '/api/agent/invoke', ... })

场景3：接入新的 LLM Provider

需求：使用公司内部的私有 LLM 服务
Skills：不可能。Skill 无法修改可用的模型列表
Plugin：✓ api.registerProvider({ catalog: ..., createStreamFn: ... })

场景4：后台服务与持续监控

需求：持续监控数据库变更，在特定事件时主动通知 Agent
Skills：不可能。Skill 只在被调用时运行，无法在后台持续运行
Plugin：✓ 在 onInit 中启动后台轮询/CDC 监听

场景5：存储后端扩展

需求：将 Agent 对话历史存储到公司的 Elasticsearch 集群
Skills：不可能。Skill 无法替换系统的存储实现
Plugin：✓ api.registerContextEngine('elasticsearch', factory)

场景6：WebSocket 实时通信

需求：实现 Agent 推理结果的实时推送（WebSocket 连接）
Skills：不可能。Skill 无法管理持久连接
Plugin：✓ 通过 registerHttpRoute 注册 WebSocket 升级端点

场景7：新 CLI 命令

需求：添加 openclaw db:migrate 命令用于数据库迁移
Skills：不可能。Skill 无法扩展 CLI 命令树
Plugin：✓ api.registerCommand({ name: 'db:migrate', ... })

场景8：TTS（文字转语音）Provider

需求：接入 ElevenLabs TTS 服务供语音通道使用
Skills：不可能。Skill 无法注册 TTS Provider
Plugin：✓ api.registerSpeechProvider({ synthesize: ... })

场景9：自定义认证方案

需求：实现基于公司 SSO 的 API 认证
Skills：不可能。Skill 无法参与认证流程
Plugin：✓ 在 resolveExternalAuthProfiles 中实现 SSO 集成

场景10：跨请求状态管理

需求：在多次 Agent 调用之间维护会话级状态（如购物车）
Skills：不可能。Skill 的上下文在每次推理后不持久化
Plugin：✓ 在 Plugin 模块内使用 Map/Redis/数据库维护状态

25.4　Skill 能做但 Plugin 不能做的5个场景

场景1：不重启即生效的知识更新

需求：立即更新 Agent 对某个 API 的调用规范（旧接口已废弃）
Skill：✓ 编辑 SKILL.md，下次推理立即使用新规范
Plugin：需要重新编码、编译、重启 —— 不适合频繁更新的知识

场景2：Workspace 级覆盖

需求：团队 A 的项目使用 Python 风格，团队 B 的项目使用 Go 风格，互不干扰
Skill：✓ 在各自的 Workspace 目录放置不同的编码规范 Skill
Plugin：系统级安装，无法做到 Workspace 粒度的差异化

场景3：精确的触发条件控制

需求：只有当用户提到"部署"并且当前目录包含 k8s/ 时才激活
Skill：✓ 在 Trigger 中定义精确的激活条件
Plugin：工具始终注册，无法做到上下文感知的按需激活

场景4：快速复用社区知识

需求：借鉴 Skill Hub 上某位专家编写的 "AWS CDK 最佳实践" Skill
Skill：✓ openclaw skill install aws-cdk-best-practices（5秒完成）
Plugin：社区 Plugin 需要经历代码审查、安全评估才能生产使用

场景5：无代码扩展（非技术用户）

需求：产品经理想为特定产品添加 Agent 行为规范
Skill：✓ 编写 Markdown 即可，无需编程能力
Plugin：需要 TypeScript 开发能力，不适合非技术人员

25.5　Token 成本是 Skill 最重要的限制因素分析

Token 成本问题值得单独深入分析，因为它往往在早期被忽视，在高频使用后才暴露为严重问题。

Token 注入机制

每次 Agent 推理时，所有 Trigger 匹配的 Skill 内容被拼接注入系统提示（System Prompt）：

实际发送给 LLM 的 context = 
  系统基础提示 (约 500 tokens)
  + Skill A 内容 (若 Trigger 匹配, 约 300 tokens)
  + Skill B 内容 (若 Trigger 匹配, 约 800 tokens)
  + Skill C 内容 (若 Trigger 匹配, 约 200 tokens)
  + 用户对话历史
  + 当前用户消息

成本计算示例

假设场景：

安装了 8 个 Skills，平均每个 400 tokens
每次推理平均 3 个 Skill Trigger 匹配（1200 tokens）
使用 GPT-4o（$5/M input tokens）
每天 1000 次推理

额外 Skill Token 成本：

1200 tokens × 1000 次/天 = 1,200,000 tokens/天
= 1.2M tokens × $5/M = $6/天 = $180/月（仅 Skills 的额外成本）

如果 Skills 设计不良（Trigger 过宽导致所有请求都匹配所有 Skills）：

8 Skills × 400 tokens × 1000 次/天 = 3,200,000 tokens/天
= $16/天 = $480/月（额外成本）

最优化策略

1. 精确 Trigger：让 Skill 只在真正需要时激活
   × 差的 Trigger: "When the user asks anything"
   ✓ 好的 Trigger: "When the user asks about Kubernetes deployment or k8s"

2. 简洁内容：SKILL.md 只包含 Agent 行动所需的最小信息
   × 冗长：背景介绍 + 历史 + 最佳实践全文 + 代码示例
   ✓ 简洁：关键步骤 + 必要约束 + 最重要的代码示例

3. 分层设计：将通用知识和专项知识拆分为不同 Skill
   通用 Skill（宽泛 Trigger，短内容）→ 引导 Agent 方向
   专项 Skill（精确 Trigger，较长内容）→ 在特定场景提供详细指导

25.6　协作模式：Plugin 提供数据管道 + Skill 教 Agent 如何使用

Skills 和 Plugin 的最强使用方式不是二选一，而是协作。最典型的协作模式：

Plugin 提供数据管道；Skill 教 Agent 如何在这条管道上工作

协作示意图

用户请求
    ↓
[Skill] 激活：检测到相关意图
    ↓ 注入知识：如何使用 Plugin 提供的工具
    ↓
[Agent 推理] 理解任务，选择工具
    ↓
[Plugin 工具] 执行实际操作（数据库查询/API调用/文件操作）
    ↓
[Skill 知识] 指导 Agent 如何解释工具结果，做出下一步决策
    ↓
用户响应

25.7　典型案例：Slack Plugin + GitHub Skill 协作完成 PR 审查

系统配置

Slack Channel Plugin（Plugin）：

监听 Slack 消息频道
当用户在 #code-review 频道 @ 机器人时触发 Agent 推理
将 Agent 响应发回 Slack 线程

GitHub PR 审查 Skill（Skill）：

Trigger：当请求涉及"code review"、"PR"、"pull request"时激活
内容：GitHub PR 审查的工作流知识、代码质量标准、评论格式规范

GitHub Tool Plugin（Plugin）：

提供 github.getPR 工具（获取 PR 详情）
提供 github.listFiles 工具（列出修改文件）
提供 github.getFileDiff 工具（获取文件差异）
提供 github.submitReview 工具（提交审查意见）

实际工作流

1. 用户在 Slack #code-review 频道发送：
   "@bot 帮我审查这个 PR：https://github.com/myorg/myrepo/pull/1234"

2. [Slack Plugin] 接收消息 → 触发 Agent 推理

3. [GitHub PR 审查 Skill] Trigger 匹配 "review" + "PR"
   → 注入知识：
     - 审查应关注：功能正确性/安全漏洞/性能问题/代码可读性
     - 必须检查：测试覆盖率/文档更新/Breaking Changes
     - 评论格式：使用 "Suggestion:"/"Issue:"/"Nitpick:" 前缀
     - 安全红线：硬编码凭证/SQL注入/XSS/不安全反序列化

4. [Agent 推理] 基于 Skill 知识规划审查步骤：
   a. 获取 PR 元信息
   b. 列出修改文件
   c. 逐文件获取差异
   d. 综合分析并生成审查意见

5. [GitHub Tool Plugin] 执行工具调用：
   → github.getPR(1234) → PR 标题/描述/作者
   → github.listFiles(1234) → 修改的文件列表
   → github.getFileDiff(1234, "src/auth.ts") → 具体代码差异

6. [Agent 推理 + Skill 知识] 分析差异，发现：
   - auth.ts 第 47 行：密码明文比较（安全 Issue）
   - user.ts 第 123 行：缺少输入验证（安全 Issue）
   - api.ts 第 89 行：可以用 async/await 优化（Suggestion）

7. [GitHub Tool Plugin] github.submitReview({
     prId: 1234,
     event: 'REQUEST_CHANGES',
     body: '整体代码质量良好，但有2个安全问题需要修复：...',
     comments: [
       { path: 'src/auth.ts', line: 47, body: 'Issue: 明文密码比较存在安全风险...' },
       { path: 'src/user.ts', line: 123, body: 'Issue: 用户输入需要验证...' },
       { path: 'src/api.ts', line: 89, body: 'Suggestion: 可以改用 async/await...' },
     ]
   })

8. [Slack Plugin] 将审查摘要发回 Slack 线程：
   "已完成 PR #1234 的代码审查。发现 2 个安全问题（已在 GitHub 上评论）..."

为什么这个分工是最优的

Slack Plugin（Plugin）：因为需要在系统启动时就监听 Slack WebSocket 连接，Skills 做不到
GitHub Tool Plugin（Plugin）：因为需要维护 GitHub API 客户端状态和认证，这是运行时能力，Skills 做不到
GitHub PR 审查 Skill（Skill）：因为"如何审查代码"是知识性内容，随时可能需要更新（修改安全红线、调整评论格式），用 Skill 可以快速迭代；如果放在 Plugin 里，每次更新都需要重新部署

25.8　决策树

根据需求特征，按以下决策树选择实现方式：

你的需求是什么？
│
├─ 需要新增消息通道（Slack/Discord/Telegram）？
│   └─ → Plugin (registerChannel)
│
├─ 需要注册 HTTP 端点？
│   └─ → Plugin (registerHttpRoute)
│
├─ 需要接入新的 LLM Provider？
│   └─ → Plugin (registerProvider with catalog + createStreamFn)
│
├─ 需要启动后台服务/持续监控？
│   └─ → Plugin (onInit 中启动后台任务)
│
├─ 需要添加 CLI 命令？
│   └─ → Plugin (registerCommand)
│
├─ 需要接入 TTS/图像生成 Provider？
│   └─ → Plugin (registerSpeechProvider / registerContextEngine)
│
├─ 需要提供可复用的领域知识（编码规范/工作流/最佳实践）？
│   └─ 这些知识更新频率高吗？
│       ├─ 高（每周或更频繁）→ Skill
│       └─ 低（每季度以下）→ Skill 仍然更合适（维护代价低）
│
├─ 需要为 Agent 添加新工具（调用外部 API/数据库/系统命令）？
│   └─ 这个工具是否需要维护运行时状态（连接池/认证会话）？
│       ├─ 是 → Plugin (registerTool)
│       └─ 否 → 两者均可，Skill 更快速
│
├─ 需要在不重启的情况下立即生效？
│   └─ → Skill
│
└─ 需要 Workspace 级别的差异化配置？
    └─ → Skill

快速判断法则

用 Plugin 的信号（满足任意一项）：

需要注册新的消息通道 / HTTP 端点
需要在 Token 循环外运行（后台服务/持续连接）
需要接入全新的 Provider（LLM/TTS/图像生成）
工具需要维护跨请求的运行时状态

用 Skill 的信号（满足任意一项）：

内容是"知识"而不是"能力"
需要 Workspace 级别的差异化
更新频率高，需要快速迭代
受众包含非技术人员（不需要写代码）

两者协作的信号：

Plugin 提供工具/通道，但 Agent 需要领域知识才能正确使用这些工具

25.9　边界案例分析

边界案例1："我需要让 Agent 知道如何使用我们的 API"

如果只需要知识（API 文档、调用规范）：→ Skill
如果还需要实际调用该 API（HTTP 请求）：→ Plugin (Tool) + Skill
- Plugin：提供 HTTP 工具
- Skill：提供使用规范知识

边界案例2："我需要一个代码审查功能"

如果 Agent 只需要知道"如何评估代码质量"：→ Skill
如果还需要与 GitHub/GitLab 交互：→ Plugin (Tool) + Skill
- Plugin：提供 GitHub API 工具（getPR、submitReview）
- Skill：提供代码审查标准和评论格式规范

边界案例3："我需要一个销售助手，知道我们的产品规格"

产品规格（文档知识）：→ Skill（可以快速更新，每次产品迭代都可能变化）
CRM 系统集成（查询客户数据）：→ Plugin (Tool)
报价计算逻辑：→ Plugin (Tool)（业务规则是代码，需要准确计算）

25.10　本章小结

Skills 和 Plugin 是互补而非竞争的两种扩展机制。它们的根本区别在于：

Skills 在推理时运行，用知识影响 Agent 行为，有 Token 成本，更新快
Plugin 在启动时运行，扩展系统底层能力，无 Token 成本，功能无上限

Token 成本是 Skill 最重要的限制因素。设计良好的 Skill 系统（精确 Trigger + 简洁内容）对成本影响可控；设计不良的 Skill 系统可能让推理成本增加 50% 以上。

协作模式是最优解：Plugin 提供能力基础设施（工具、通道、Provider），Skill 提供如何使用这些基础设施的领域知识。Slack Plugin + GitHub Skill 的案例完美诠释了这种分工——每种扩展机制都做自己最擅长的事情。

决策的最简单原则：如果你能用 Markdown 表达它，就用 Skill；如果需要代码才能实现，就用 Plugin。

本章评分

4.7 / 5 (5 评分)