博文
Agent 时代的一些术语澄清
||
Agent 时代最容易混淆的，不是技术，而是抽象层级。很多讨论在不知不觉中把不同层的东西混为一谈：
Plugin（插件） 是不是 App？
Special Agent 是不是新时代 App？
API 和 Skill 有什么区别？
General Agent 到底是工具，还是平台？
如果不分层，这些问题会永远纠缠在一起。下面给出一个结构化框架。
一、从高到低的六层结构我们可以把 Agent 时代的软件结构分为六层：
用户意图（Human Intent）
General Agent（入口与调度）
Special Agent（任务专家）
Skill（面向 Agent 的能力声明）
Plugin（面向 Agent 的能力执行模块）
API （面向程序的能力接口）
这是一个从抽象到执行的完整链路。它们之间有包含关系，但不等价。
二、General Agent：入口与调度者General Agent 是新时代的“默认入口”。它负责：
理解自然语言目标
拆解复杂任务
决定调用哪个 Special Agent
决定调用哪些 Skill
管理权限与执行顺序
它不一定是某个具体任务的专家。它是“总调度”。在结构上，它最接近：
浏览器（Web 时代的入口）
操作系统桌面（PC 时代的入口）
SpringBoard（iOS 的用户交互层，移动时代的入口）
General Agent 不是功能工具。它是意图解释权的持有者。
三、Special Agent：任务域专家Special Agent 是针对某一类任务优化的 Agent。
例如：Coding Agent；Math Agent；Legal Agent；Research Agent；Trading Agent etc
它们具备：
特定领域知识
特定工具链
特定执行策略
在功能层面，Special Agent 类似新时代的 App——它围绕某一任务域提供能力。但在系统结构层面，Special Agent 不再是入口。真正的入口是 General Agent。
四、App：面向人的功能单元App 属于移动时代的抽象。
它的特点是：
用户主动打开
UI 驱动操作
功能由菜单组织
由操作系统直接调度
传统逻辑：
用户 → 打开 App → 点击 → 执行
Agent 时代逻辑：
用户 → General Agent → 调度 Special Agent → 调用 Plugin
App 可能会：
退化为后台能力接口
或变成“带 UI 的 Special Agent”
App 不会立刻消失，但会失去入口地位。
五、Skill：能力声明层Skill（技能） 是 Agent 世界里的语义能力单元。
它定义：
能做什么
需要什么参数
返回什么结果
需要什么权限
Skill 类似函数注册。它存在于语言层。模型通过 Skill 描述理解“可以调用什么能力”。Skill 本身不执行代码。
六、Plugin：执行封装层Plugin 是真正的执行单元。
它：
封装 API 调用
或封装本地系统访问
管理权限
处理异常
返回结构化结果
Plugin 是 Agent 可以调用的能力模块。
七、API：底层能力接口API 是能力的协议接口。API 的本质是接口抽象。它把底层复杂系统包装成一个可调用单元：当我们说一个公司“开放 API”，意思是它允许别人以程序化方式访问它的能力。
但 API 本身不思考，不决策，不规划。它只回答：如果有人来调用，我该返回什么。
API 是被动的，这是关键。API 不拥有：调度权、决策权、优先级管理权、权限分配逻辑。它是被调用的。在传统软件时代：
用户通过 UI → 调用 API
在 Agent 时代：
Plugin 或 Special Agent → 调用 API
API 始终处于执行链的末端。它从不主动发起行为。
很多人误以为：API 就是能力。准确地说：API 是能力的接口。API 只是把能力变成可被访问的形式。如果把能力比作电力，API 是插座。
在 Agent 时代，API 的地位发生了变化。
在移动互联网时代：App 是基本单位。API 是隐藏在 App 背后的技术层。在 Agent 时代：API 的重要性上升。因为：Agent 需要通过 API 调度能力。当用户不再直接使用 App，API 成为真正的能力交互层。软件从“UI 产品”变成“能力接口”。
即使在 Agent 时代，API 也不会成为入口。API 只是在执行链最末端响应请求。它回答：给我参数，我返回结果。但它不会问：现在该做什么？该调用谁？哪个任务优先？这些是调度层的问题。执行链路可以写成：
用户→ General Agent→ Special Agent / Plugin （可选）→ API→ 数据 / 系统资源
API 是执行的最后一跳。General Agent 掌握入口权；Special Agent 掌握任务域策略；API 提供底层能力。
八、谁是新时代的“App”？从任务功能角度看：Special Agent ≈ 新时代的 App
从入口结构角度看：General Agent ≈ 新时代的操作系统
从执行单元角度看：Plugin ≈ 新时代的软件基本模块
App 正在被分解为：入口权 + 能力接口 + 执行封装。
在移动时代：App 是基本单位。
在 Agent 时代：Plugin 可能成为基本单位，General Agent 成为默认入口。而真正的商业权力，将集中在：谁控制 General Agent。
Special Agent 看起来像新时代的 App。但如果 General Agent 足够强，它常能直接：
动态组合 Skill
调用 Plugin
绕过 Special Agent
那时，Special Agent 也可能退化为配置文件。
九、从 Plugin 到 Skill在 Agent 发展的早期阶段，整个行业有过一个非常自然的想法：
模型需要真正“做事”，那就给它插件（Plugin）。于是第一代 Agent 架构出现得非常直接：LLM + Plugin = 执行体。
插件可以是：
浏览器自动化模块
数据库访问模块
Gmail 插件
Stripe 支付插件
本地 shell 执行器
逻辑很简单：
模型负责思考，插件负责行动。OpenAI一度尝试构建“Plugin 商店”，希望复制移动时代 App Store 的成功。看起来合理。为什么后来大家觉得插件“没站住”？表面看是生态没爆发，本质却是结构冲突。
第一，安全问题过重。Plugin 是代码。它拥有真实权限：
API 调用权
本地执行权
凭证访问权
一旦被 prompt injection 诱导调用，它就是“真刀真枪”的执行器。插件不是被人点击触发，而是可能被模型自动触发。风险指数级上升。插件商店变成了风险商店。
第二，发现与调度太复杂。移动时代是人选择 App。Plugin 时代是模型选择插件。这带来一个新的难题：
模型如何判断插件质量？
如何判断安全性？
如何处理插件冲突？
如何管理优先级？
插件市场不是人类浏览的市场，而是模型调度的市场。
第三，插件解决的是“能做什么”，不是“该做什么”。Plugin 是执行层。但 LLM 的真正瓶颈在于：
理解任务
拆解任务
选择工具
规划步骤
插件扩展了能力，却没有解决调度。于是产业开始意识到：问题不在执行层，问题在决策层。
于是出现了 Skill 这一层抽象。Plugin 是代码。Skill 是语义能力声明。Plugin 告诉系统“如何做”。Skill 告诉模型“可以做什么”。Skill 更轻量，更标准化，更适合被模型理解和规划。
架构也发生了变化：早期结构：LLM → Plugin → API
演化后结构：LLM → Skill → 安全调度层 → Plugin / API
多出了一层：调度与治理。插件没有消失。它只是被压到了底层。
那 Plugin 是不是 App？很多人会产生一个直觉：Plugin 不就是 App 吗？是不是 Agent 时代把 App 改造了一下？
这个直觉有一半是对的。因为早期很多 Plugin 确实是把现有 App 的 API 包装成 Agent 可调用模块。Gmail Plugin 本质上连接 Gmail。Slack Plugin 本质上连接 Slack。看起来像“App 的 Agent 版本”。但本质上不完全一样。
移动时代：
App = 功能 + 入口 + 执行
Agent 时代：
General Agent = 入口
Special Agent = 任务聚合
Plugin = 执行封装
API = 底层能力
App 被拆解了。入口被抽离。执行被封装。能力被抽象。
Plugin 继承了“执行部分”。General Agent 继承了“入口部分”。
Plugin 没失败，是被降级。Plugin 商店没有成为移动时代那样的爆炸式生态，不是因为插件无用。而是因为：
Agent 时代真正的价值不在能力扩展，而在能力调度。
Plugin 是 App 被解构后的执行组件。Skill 是对 Plugin 的语义抽象。General Agent 是对 App 入口权的重新定义。这不是插件失败。这是软件基本单位的迁移。
https://wap.sciencenet.cn/blog-362400-1522107.html
上一篇：当 Agent 成为默认入口，App Store 模式是否崩塌？
