最近在写 Agent 那一章时，很多读者问我一个问题：
Skill 是什么？
Plugin 是不是就是 App？
Plugin 是不是就是 API？
这些词在同一个语境里频繁出现，但其实它们属于不同抽象层级。如果不拆清楚，很容易误判 Agent 时代的软件结构。今天我们系统梳理一下。
一、先讲结论：它们不是同一层的东西
在 Agent 架构中，大致可以分为四个层级：
-
-
App：面向人的应用单元
-
API：面向程序的能力接口
-
Skill：面向 Agent 的能力声明
-
Plugin：面向 Agent 的能力执行模块
-
四个词，分别代表四种抽象单位。它们之间有包含关系，但不等价。
二、App：面向人的应用单元
App 是移动互联网时代的核心抽象。
它的特点是：
-
-
有 UI
-
有图标
-
有前台交互
-
用户主动打开
-
由操作系统调度
-
传统模式是：
用户 → 打开 App → 点击功能 → 执行任务
App 是入口。App Store 的商业模式也建立在“入口权”之上。
三、API：面向程序的能力接口
API 是软件工程的抽象。
它的特点是：
-
-
定义输入输出
-
暴露远程调用能力
-
不直接面向用户
-
比如：
POST /send_email
GET /user_profile
API 是能力的“通道”。它本身不提供完整功能，只是能力的暴露形式。在互联网时代，API 是企业间协作的基础。
四、Skill：面向 Agent 的能力声明
Skill 是 Agent 时代的新抽象。
它是：
-
-
能力的语义定义
-
带有参数结构的能力说明
-
模型可以理解并调用的能力单元
-
例如：
Skill: send_email
参数：recipient, subject, content
Skill 更接近“函数签名”。
它告诉模型：
“如果你需要发送邮件，可以调用这个能力。”
Skill 属于语言层。
它存在于模型提示和工具描述之中。
五、Plugin：面向 Agent 的执行封装
Plugin 是执行层。
它通常包含：
-
权限声明
-
参数适配逻辑
-
API 调用代码
-
本地执行逻辑
-
错误处理机制
Plugin 是实际运行的代码单元。
如果说 Skill 是“能力说明书”，
Plugin 是“能力引擎”。
Plugin 可能调用 API，也可能直接访问本地系统。
它是执行权的持有者。
六、四者之间的关系
我们用一个简单结构表示：
用户 → Agent → Skill → Plugin → API / 本地系统
-
用户表达意图
-
Agent 规划任务
-
Skill 提供能力声明
-
Plugin 执行具体操作
-
API 或系统完成底层动作
App 在这个结构里，开始退居后台。
它可能变成一个带 UI 的 Plugin。
七、为什么这个区分重要？
因为在 Agent 时代：
-
App 的入口价值下降
-
API 的接口价值上升
-
Skill 的标准化价值增强
-
Plugin 的安全风险扩大
真正决定系统能力的，不是 UI。
真正决定风险与权力边界的，是 Plugin 层。
Prompt Injection 攻击的本质，不是攻击 API。
而是诱导 Agent 调用 Plugin。
执行风险发生在 Plugin 层。
八、一个关键趋势
在移动互联网时代：
App 是基本单位。
在 Agent 时代：
Plugin 可能成为基本单位。
App 会逐渐被抽象为“带 UI 的能力包”。
API 会成为能力的底层协议。
Skill 会成为能力的语言标签。
Plugin 会成为执行单元。
软件从“产品形态”转向“能力形态”。
九、最后一个判断
如果未来：
模型可以自动生成 Skill，
甚至自动生成 Plugin，
那么软件开发的抽象层级将再次上移。
到那时：
我们写的可能不是“应用”，
而是“能力约束规则”。
Agent 时代真正稀缺的，不是 API。
而是：
可控的执行边界。
一句话总结：
App 是面向人的能力封装。
API 是面向程序的能力接口。
Skill 是面向 Agent 的能力声明。
Plugin 是面向 Agent 的能力执行单元。
当 Agent 成为默认入口，
软件的基本单位，将从 App 迁移到 Plugin。
这不是词汇变化。
这是抽象层级的迁移。
