
下面我按工程视角,把 MCP / Agent / Skills / Rules 这几个概念的区别、作用、落地形态,以及它们与传统 API 调用的本质差异系统性说明清楚。整体偏向你熟悉的平台级 / 基础设施级理解,而不是营销式解释。
概念 | 本质角色 | 解决什么问题 | 是否参与推理 | 是否有状态 |
|---|---|---|---|---|
API | 远程函数 | 功能调用 | ❌ | ❌ |
MCP | 工具接入协议 | 如何把外部能力安全、标准化接给 LLM | ❌ | ❌ |
Skill | 可执行能力 | LLM 能“做什么” | ❌ | ❌ |
Rule | 约束与策略 | LLM 不该/必须怎么做 | ❌ | ⚠️(弱) |
Agent | 自主执行体 | 目标 → 计划 → 行动 → 校验 | ✅ | ✅ |
核心分界线只有一个: 是否具备“自主决策 + 多步执行”的能力 → 有:Agent → 没有:其他全是“被调用的能力组件”
业务代码 → SDK / HTTP → API → 返回结果特点:
MCP 不是“功能”,而是:
一套“让 LLM 能理解并安全调用外部工具”的协议
LLM
├─ tools list (schema)
├─ tool description (自然语言)
├─ auth / permission
└─ invoke tool (JSON)问题 | 传统 API | MCP |
|---|---|---|
LLM 怎么知道有什么能力 | 不知道 | tools schema |
LLM 怎么构造参数 | 做不到 | JSON Schema |
怎么防止越权 | 业务代码 | MCP sandbox / auth |
一句话:
API 是给“人写的程序”用的 MCP 是给“模型”用的
非常关键的一点:
MCP 只负责“接工具” 不负责“什么时候用 / 怎么用 / 用几次”
这件事永远是 Agent 的职责
Skill = Agent 可调用的一次性能力
通常是:
例如:
Skill | 实际背后 |
|---|---|
query_order_status | HTTP API |
restart_pod | kubectl |
get_cpu_usage | PromQL |
create_ticket | ITSM API |
Skill 的关键特征:
Skill(能力定义)
↓
MCP(暴露给模型的协议)
↓
LLM / Agent(使用者)Skill 是“业务抽象” MCP 是“技术封装”
Rule 不是 if/else,不是工作流,也不是 DSL。
Rule 的作用只有一个:
限制 Agent 的行为空间
典型 Rule:
Rule 更像:
❌ 不负责任务拆解 ❌ 不决定调用顺序 ❌ 不做推理 ❌ 不处理异常恢复
这些全是 Agent 的事
Agent = LLM + 状态 + 目标 + 反馈闭环
最小 Agent Loop:
while not goal_done:
observe()
think()
plan()
act()
verify()这一步是传统 API / 脚本 / 工作流都做不到的
维度 | 传统系统 | Agent |
|---|---|---|
控制流 | 人写死 | 模型生成 |
执行路径 | 确定性 | 非确定性 |
容错 | 代码 | 推理 + retry |
扩展方式 | 加代码 | 加 skill |
应对未知 | 很差 | 很强 |
告警 → Agent
├─ 查询指标(skill)
├─ 分析趋势(LLM)
├─ 判断风险(rule)
├─ 执行动作(skill)
└─ 回写结果为什么不用脚本?
比如:
传统方式: → 大量 if/else + 流程引擎 Agent: → 目标驱动 + 约束执行
结合你之前的判断,其实非常准确。
单纯 LLM + 知识库 = 高级搜索 没有 Agent = 没有闭环 = 没有业务价值
真正有价值的是:
Agent
├─ Skill(能干活)
├─ Rule(不乱来)
└─ MCP(能接系统)API 是“函数” Skill 是“能力” MCP 是“适配层” Rule 是“护栏” Agent 是“执行体”