返回文章列表

Skill、Agent、MCP、CLI 到底是什么关系？

河图
2026年04月22日
25 分钟阅读

<callout emoji="bullettrain front" background color="light orange" border color="light orange" CLI、API、MCP 更偏底层连接与调用机制；Tool 和 Skill 更偏能力封装；A

CLI、API、MCP 更偏底层连接与调用机制；Tool 和 Skill 更偏能力封装；Agent 和 Multi-Agent 更偏任务理解、决策与协同。

一、概念分层图

越往下，越偏“怎么连、怎么调、怎么执行”；越往上，越偏“怎么理解目标、怎么组织能力、怎么完成任务”。

  • CLI / API：更像底层的调用入口；
  • MCP：更像连接模型与外部能力的协议层；
  • Tool：更像一个可以被调用的具体工具；
  • Skill：更像把工具、规则、经验、边界封装成“可复用能力模块”；
  • Agent：更像围绕目标组织与调用能力的执行者；
  • Multi-Agent：更像多个有分工的执行者组成的协作系统。

二、CLI和API是啥

1. CLI 是什么

CLI 全称是 Command Line Interface，也就是命令行界面。

它本质上是一种调用入口，不是一种智能架构，也不是一种协议。它的作用是：

  • 让人或程序通过命令行去执行某个能力；
  • 触发脚本、程序、服务或系统动作；
  • 以参数形式把输入传给底层程序。

比如：

  • python run_report.py --date 2026-04-22
  • feishu-doc-cli create --title 周报
  • mcp-server start

这些都属于 CLI 形式。

所以，CLI 更准确的理解应该是：

CLI 不是能力本身，更像能力的调用入口或操作界面。

2. API 是什么

API 全称是 Application Programming Interface，也就是应用程序接口。

它和 CLI 一样，也属于“调用入口”，只是形式不同：

  • CLI 更面向命令行调用；
  • API 更面向程序间调用。

比如一个飞书文档系统，可能同时提供：

  • 一个 CLI：让你在终端里执行创建文档；
  • 一组 API：让程序通过 HTTP 请求创建文档。

所以 CLI 和 API 并不是互相替代的概念，它们往往只是同一能力的两种不同调用形态。

3. CLI 和 API 的边界

最容易误解的一点是：

  • 有人把 CLI 当成“工具本身”；
  • 有人把 API 当成“能力本身”。

其实很多时候：

  • 真正的能力在程序或服务里；
  • CLI 和 API 只是访问这个能力的入口。

所以从抽象层级上，CLI 和 API 通常比 Tool、Skill、Agent 更底层，也更“机械”。

三、MCP 是什么：它更像“模型和工具之间的通用连接协议”

1. MCP 到底是什么

MCP 通常可以理解为一种模型与外部能力之间的标准连接协议。

它最核心的价值，不是提供某个具体业务能力，而是回答一个问题：

模型应该用什么统一方式去发现、理解、调用外部工具？

如果没有这层协议，不同工具、不同系统、不同客户端可能都要用各自的接入方式，模型侧会非常碎片化。

而有了 MCP，这件事就更像“插标准接口”：

  • 工具方按协议暴露能力；
  • 模型方按协议理解能力描述和参数结构；
  • 双方通过统一方式交换调用请求与结果。

2. MCP 是协议层还是能力层

这是很多人最容易搞混的一点。

更准确的答案是：

MCP 更偏协议层，不是业务能力层。

也就是说：

  • MCP 自己通常不等于“读文档”“查报表”“发消息”这些能力；
  • 它更像是让这些能力能够被模型标准化接入与调用的一套协议机制。

打个比方：

  • 电器本身是能力；
  • 插座标准是协议；
  • MCP 更像这个“插座标准”。

所以不要把 MCP 和 Skill、Tool 混成一类。它们不是同一个层级：

  • Tool/Skill 更像“插上去的电器”；
  • MCP 更像“让这些电器能被统一接上的插座标准”。

3. 为什么 MCP 经常和 Tool 混在一起

因为在实际产品中，用户经常看到的是：

  • “这个 MCP 可以读文档”；
  • “那个 MCP 可以操作 Figma”；
  • “某个 MCP 可以访问数据库”。

于是很容易误以为“MCP 就是能力本身”。

但更准确地说，很多时候其实是：

  • 某个 MCP server 通过 MCP 协议暴露了一组工具；
  • 用户感知到的是这些工具的能力；
  • 于是把协议层、服务层、工具层揉到了一起。

所以在理解上，最好分开：

  • MCP：连接规则；
  • MCP server / 集成服务：按这个规则暴露工具的一端；
  • Tool：被暴露出来的具体能力。

四、Tool 是什么：它是“可以被模型直接调用的具体工具”

1. Tool 的定义

Tool 可以理解为一个可调用的具体工具单元。

它通常有：

  • 明确的名称；
  • 明确的输入参数；
  • 明确的输出结果；
  • 相对清晰的功能边界。

比如下面这些都更像 Tool：

  • read_doc(url)：读取文档；
  • search_knowledge(query)：搜索知识库；
  • create_sheet(title)：创建表格；
  • run_sql(sql)：执行查询；
  • send_message(user, content)：发送消息。

2. Tool 和 API、CLI 的关系

这里也很容易混淆。

一个 Tool 背后，底层实现可能是：

  • 调某个 API；
  • 执行某个 CLI；
  • 调某段本地代码；
  • 访问某个数据库；
  • 操作某个浏览器实例。

所以 Tool 更像是被上层模型感知和调用的能力接口，而不是底层具体怎么执行。

换句话说：

CLI 和 API 是底层入口，Tool 是模型视角下的可调用能力。

同一个 Tool，底层完全可能是 CLI；也可能是 API；也可能两者都不是。

3. Tool 的边界

Tool 更像“一个动作”或“一个明确能力点”。

它通常不负责：

  • 理解用户最终目标；
  • 决定是否应该调用自己；
  • 决定调用顺序；
  • 处理复杂跨步骤任务。

这些通常是更上层的 Agent 或 Skill 在负责。

五、Skill 是什么：它比 Tool 更像“带规则的能力模块”

1. Skill 的定义

Skill 可以理解为 AI 系统中的“技能包”或“专用能力模块”。

它通常具备几个典型特征：

  1. 聚焦某一类明确任务；
  2. 输入输出相对稳定；
  3. 不仅包含能力，还包含调用规则与边界；
  4. 适合被重复触发与复用；
  5. 强调稳定性、一致性和专业深度。

比如下面这些，通常都更接近 Skill：

  • 读取飞书文档并按要求编辑；
  • 查询会议纪要并提炼行动项；
  • 搜索企业知识并生成摘要；
  • 解析 PDF 并抽取关键表格；
  • 在 Figma 中执行一类固定设计操作。

2. Skill 和 Tool 的差别

很多人会问：Skill 和 Tool 不都是“能做事”吗？

是的，但两者仍然有明显差别。

维度 Tool Skill 抽象层级 更低 更高 形态 一个具体工具调用点 一类任务的能力封装 关注点 做一个动作 把一类任务做稳、做深、做规范 是否包含调用规则 一般较少 通常较多 是否可编排多个工具 不一定 常常会

可以简单记成：

Tool 更像一把螺丝刀；Skill 更像“装配螺丝这项工序”。

3. 一个更真实的 skill.md 长什么样

很多人第一次接触 Skill，会以为它只是“一个脚本”或者“一个接口”。但在实际工程里，Skill 往往还包含触发规则、边界说明、调用约束、失败处理和输出规范。

下面是一个更贴近真实工作场景的 skill.md 片段示例：

---
name: merchant-data-analyzer
description: |
  用于电商商家经营分析。当用户提到“店铺诊断”“GMV下滑原因”“流量结构分析”
  “活动复盘”“转化率异常”时触发。擅长读取经营报表、归因问题、输出结构化建议。
---

# 适用场景
- 店铺经营周报分析
- 大促活动复盘
- 流量、转化、客单价拆解
- 找出异常指标并给出优化建议

# 不适用场景
- 用户只想查单个数字，不需要分析
- 没有任何报表、指标或上下文
- 需要直接修改投放系统配置

# 工作原则
1. 先判断用户要的是“查数”还是“诊断问题”
2. 如需诊断，优先按“流量 -> 点击 -> 转化 -> 客单价”结构分析
3. 若信息不足，优先追问缺失指标，而不是直接下结论
4. 输出建议时，必须区分“现象、原因判断、建议动作”三层

# 默认调用工具
- sales_report_reader
- campaign_data_fetcher
- merchant_knowledge_search
- feishu_doc_writer

# 输出格式
1. 核心结论
2. 关键指标变化
3. 原因拆解
4. 优先级最高的3条建议
5. 需要补充的数据

# 风险控制
- 不得编造经营数据
- 不得把相关性直接写成因果结论
- 当样本不足时必须明确标注“待进一步验证”

从这个例子里，你会发现 Skill 不是“只能做一个按钮动作”的东西。它更像是把某类任务的经验、边界和调用规范封装起来，变成一个长期稳定可复用的能力模块。

六、Agent 是什么：它更像一个围绕目标工作的智能执行者

1. Agent 的定义

Agent 可以理解为一个“面向目标工作的智能执行者”。

它的核心不在于自己会某一个动作，而在于它能够：

  1. 理解用户意图；
  2. 把目标拆成步骤；
  3. 判断需要哪些 Skill 或 Tool；
  4. 在执行过程中根据结果调整策略；
  5. 最终把多个阶段结果汇总成用户真正需要的成果。

所以如果说 Tool 是“可调用动作”，Skill 是“可复用能力模块”，那么：

Agent 更像一个围绕目标调度这些能力的人。

2. Agent 的实现思路

一个常见的 Agent，通常至少包含这些部分：

  • 目标理解：用户到底要什么；
  • 任务规划：把大目标拆分成步骤；
  • 能力选择：决定调用哪个 Skill、Tool 或系统；
  • 上下文与状态管理：记住当前进度和中间结果；
  • 动态调整：遇到失败、信息不足或结果不佳时切换策略；
  • 结果整合：把不同步骤的结果组合成最终交付物。

所以 Agent 的关键能力，不是“执行某个动作”，而是围绕目标组织能力、编排流程、推动结果落地。

七、把这些概念摆在一起：它们最容易混淆的边界到底在哪

1. CLI 和 Tool 容易混淆

误区：

  • “我有个 CLI，所以我有个 Tool。”

更准确地说：

  • CLI 只是调用方式；
  • Tool 是模型可调用的能力接口；
  • 一个 Tool 底层可以是 CLI，但 CLI 不天然等于 Tool。

2. API 和 Tool 容易混淆

误区：

  • “这个系统有 API，所以模型就能直接用。”

更准确地说：

  • API 是程序接口；
  • Tool 是给模型调用时封装好的能力入口；
  • API 往往需要再包装成 Tool，模型才更容易稳定使用。

3. MCP 和 Tool 容易混淆

误区：

  • “MCP 就是工具。”

更准确地说：

  • MCP 更像工具连接协议；
  • Tool 是通过这个协议暴露给模型的具体能力；
  • 用户感知到能力时，经常把二者混为一谈。

4. Tool 和 Skill 容易混淆

误区：

  • “Skill 不就是很多 Tool 吗？”

更准确地说：

  • Tool 是更小、更具体的调用点；
  • Skill 是对一类任务的能力封装，常常会附带经验、规则、边界、输出格式与默认工具组合；
  • 一个 Skill 可能调用一个 Tool，也可能组织多个 Tool。

5. Skill 和 Agent 容易混淆

误区：

  • “Skill 也会做复杂任务，那它和 Agent 还有什么差别？”

更准确地说：

  • Skill 更像“把一类任务封装成标准能力”；
  • Agent 更像“面对开放目标时的执行者”；
  • Skill 强调某类任务的稳定完成，Agent 强调整体任务的自主推进。

6. 主 Agent 和 Sub-Agent 容易混淆

误区：

  • “只要有多个 Skill 就算 Multi-Agent。”

更准确地说：

  • 如果只有一个中心做所有理解、规划、调度，那通常还是单 Agent；
  • 只有当多个执行体都拥有一定独立判断和局部闭环能力时，才更接近 Multi-Agent。

八、放到业务任务里看：什么时候是 Tool，什么时候是 Skill，什么时候是 Agent

为了更容易理解，我们还是用一个更具体的业务场景：电商商家经营。

1. Tool 层

例如：

  • 拉取店铺日报数据；
  • 查询某场活动明细；
  • 搜索知识库中的经营策略；
  • 写入飞书文档；
  • 发送通知消息。

这些都是很具体、边界清晰的动作。

2. Skill 层

例如：

  • 店铺经营分析 Skill；
  • 大促复盘 Skill；
  • 商品评价归因 Skill；
  • 周报生成 Skill。

这些已经不只是单个动作，而是一类任务的稳定能力封装。

3. Agent 层

例如用户说：

“帮我分析一下为什么这周店铺 GMV 下滑，并给出下周优化建议。”

这时一个 Agent 需要：

  1. 先理解这是“经营诊断”任务；
  2. 判断重点应该看流量、转化还是客单价；
  3. 再调用相应 Skill 或 Tool；
  4. 最后汇总成完整判断和建议。

这里 Agent 的价值，就在于它能把底层零散能力组织起来，变成一个完整结果。

九、单 Agent 多 Skill：这是最常见、也最实用的一种架构

在很多真实产品里，最常见的不是一上来就做 Multi-Agent，而是先做单 Agent 多 Skill。

1. 什么是单 Agent 多 Skill

它的结构很简单：

  • 上层有一个主 Agent；
  • 下层挂很多 Skill；
  • Skill 里再去调用具体 Tool；
  • Tool 底层再通过 MCP、API、CLI 等方式连接执行系统。

可以把它理解为：

一个“大脑”，调度很多“专业工种”，而这些工种再去调用具体工具和底层系统。

2. 单 Agent 多 Skill 架构图

这张图的重点在于：决策中心只有一个。Skill 和 Tool 再多，也仍然是单 Agent 架构。

十、Multi-Agent 是什么：当一个“大脑”不够时，就会出现多个“角色化大脑”

1. 什么是 Multi-Agent

Multi-Agent 指的是：系统中不只有一个 Agent，而是有多个具有不同职责的 Agent 协同工作。

这些 Agent 可能在角色上有所分工，例如：

  • 有的负责总控和任务编排；
  • 有的负责检索和资料收集；
  • 有的负责数据分析；
  • 有的负责写作与结构化表达；
  • 有的负责执行系统操作。

可以把它理解为：

不再是一个人调用很多工具，而是一支分工明确的 AI 团队一起完成任务。

2. 主 Agent 和 Sub-Agent 一般如何配合

最直观的理解是：

  • 主 Agent 更像总负责人、任务经理、总控中枢；
  • Sub-Agent 更像某个专业方向的执行负责人。

主 Agent 通常负责：

  1. 理解用户目标；
  2. 判断任务是否需要拆分；
  3. 决定拆成哪些子任务；
  4. 把任务分发给合适的 Sub-Agent；
  5. 处理冲突、做最终汇总与交付。

Sub-Agent 通常负责：

  • 在某个领域内完成局部闭环；
  • 调用自己需要的 Skill 与 Tool；
  • 返回阶段性高质量结果。

3. Multi-Agent 主从协同架构图

这张图想表达的重点是：决策不再只有一个层级。主 Agent 管总控，Sub-Agent 管局部闭环，而 Skill、Tool、MCP、CLI 继续往下分层存在。

十一、一个完整例子：用户请求是怎么一路传到最底层执行的

这一部分最有助于把所有概念真正串起来。

假设一个用户提出请求：

“帮我分析一下为什么这周店铺成交下滑，并生成一个给老板汇报的复盘文档。”

我们从上往下看，这个请求可能是怎么被执行的。

第一步：用户把“目标”交给 Agent

用户给的不是步骤，而是结果期待：

  • 找原因；
  • 形成判断；
  • 输出复盘文档。

所以首先接住任务的，通常是 Agent，而不是 Tool、CLI 或 MCP。

第二步：Agent 理解目标并做任务拆解

Agent 可能会判断：

  1. 先做经营诊断；
  2. 再做问题归因；
  3. 最后生成一份给老板看的文档。

如果是单 Agent 架构，这个 Agent 自己继续往下调 Skill。

如果是 Multi-Agent 架构，它可能会拆给：

  • 数据分析 Sub-Agent；
  • 资料检索 Sub-Agent；
  • 报告写作 Sub-Agent。

第三步：Agent 或 Sub-Agent 选择合适的 Skill

比如：

  • 调用“经营分析 Skill”；
  • 调用“知识检索 Skill”；
  • 调用“文档生成 Skill”。

这一步意味着：系统已经从“开放目标”进入“某类任务能力模块”。

第四步：Skill 再调用具体 Tool

例如经营分析 Skill 内部，可能会调用：

  • 报表读取 Tool；
  • 活动明细查询 Tool；
  • 指标计算 Tool；
  • 图表生成 Tool。

而文档生成 Skill 内部，可能会调用：

  • 文档创建 Tool；
  • 文档写入 Tool；
  • 标题格式化 Tool。

这里 Tool 已经非常接近具体执行动作。

第五步：Tool 通过 MCP、API 或 CLI 触发底层系统

接下来才进入更底层：

  • 某个 Tool 可能通过 MCP 调用一个文档系统能力；
  • 某个 Tool 可能直接请求一个 API；
  • 某个 Tool 也可能执行一个 CLI 命令来触发脚本。

例如：

  • read_report Tool 底层调用经营数据 API；
  • write_doc Tool 底层通过 MCP 访问文档编辑能力；
  • generate_chart Tool 底层执行一个 CLI 脚本生成图表文件。

第六步：底层结果逐层返回

执行完成后，结果会逐层往回返回：

  • CLI / API / MCP 返回原始结果；
  • Tool 把结果封装成可理解输出；
  • Skill 把多个 Tool 结果整合成阶段结果；
  • Agent 再把多个阶段结果汇总成最终交付物。

最终用户看到的是：

  • 一份完整的经营诊断；
  • 一份老板能直接看的复盘文档；
  • 也许还附带 3 条优先优化建议。

这个例子里每一层分别做了什么

层级 在这个例子里的职责 Multi-Agent / Agent 理解目标、拆任务、调度能力、汇总结果 Skill 承接一类任务能力，如经营分析、文档生成 Tool 做具体动作，如拉数据、写文档、生成图表 MCP 作为模型与工具连接协议，统一暴露和调用外部能力 API 给程序调用的系统接口 CLI 给命令行调用的执行入口

所以一次真实任务，通常不是“某一个概念单独完成”，而是多层概念共同完成。

十二、哪种更好？不要只盯着 Agent，更要看分层是否清楚

很多团队一听到 Multi-Agent，就会下意识觉得它更先进；一听到底层有 MCP、CLI，又会觉得系统更“工程化”。

但真正决定系统质量的，不是你堆了多少名词，而是：

这些概念有没有放在正确的层级，用在正确的位置。

1. 大多数时候，先做清楚单 Agent 多 Skill 就已经很好

对于很多产品来说，更现实的优先级往往是：

  1. 先把底层 Tool 接通；
  2. 再把高频能力封装成 Skill；
  3. 再让一个 Agent 把它们组织起来；
  4. 当复杂度足够高时，再升级到 Multi-Agent。

2. 常见错误不是能力不够，而是层级混乱

最常见的问题通常不是“没有 MCP”或者“没有 Multi-Agent”，而是：

  • 把 CLI 当能力本身；
  • 把 MCP 当业务能力；
  • 把 Tool 和 Skill 混成一层；
  • 把单 Agent 包装成伪 Multi-Agent；
  • 让主 Agent、Sub-Agent、Skill 重复承担相同职责。

一旦分层混乱，系统就会出现：

  • 责任边界不清；
  • 复用性差；
  • 成本和时延上升；
  • 问题难排查；
  • 后续难扩展。

所以真正成熟的系统，不是概念越多越好，而是：

  • 底层连接层足够标准；
  • 中层能力层足够稳定；
  • 上层智能层足够清晰。

十三、最后总结：把所有概念放回一句话里

如果你只想记住最核心的内容，可以记住下面这段：

CLI 和 API 更像调用入口，MCP 更像工具连接协议。

Tool 是模型可调用的具体工具，Skill 是带规则和边界的能力封装。

Agent 是面向目标组织这些能力的执行者，Multi-Agent 是多个有分工的执行者协同系统。

再进一步说：

  • 越往下，越偏执行与连接；
  • 越往上，越偏理解、决策与协同。

所以，真正成熟的 AI 系统，从来不是只谈 Agent，也不是只堆 Tool，更不是把 MCP、CLI 当成“更高级的能力”。

更准确的理解应该是：

CLI / API / MCP 负责“接得上、调得动”；Tool / Skill 负责“能力能用、稳定复用”；Agent / Multi-Agent 负责“围绕目标把事情做成”。

这才是把这些概念真正放回同一张地图里之后，最值得记住的一件事。

十四、如果真的要开发：开发一个 Skill 和开发一个 Agent，分别需要做什么

讲到这里，很多人会自然追问一个更落地的问题：

如果我不是只是理解这些概念，而是真的要开始做，一个 Skill 和一个 Agent 分别应该怎么开发？两者到底差在哪？

如果先用一句话概括：

开发 Skill，更像是在做一个稳定、可复用、边界清晰的能力模块；开发 Agent，更像是在做一个能够围绕目标组织能力、推进任务、处理不确定性的执行系统。

所以两者都需要设计、接入、测试和治理，但关注重点并不一样。

1. 开发一个 Skill，通常需要做哪些事情

Skill 更像一项“专门工种”或一类“标准工序”，所以开发 Skill 时，重点不是让它什么都会，而是让它在一个明确边界内稳定可用。

一个比较典型的 Skill 开发清单，可以这样理解：

  1. 定义这个 Skill 的目标与适用场景
  • 它到底负责什么；
  • 它不负责什么；
  • 什么样的请求应该触发它；
  • 什么样的请求不应该触发它。
  1. 定义输入输出
  • 它需要哪些输入参数；
  • 输出应该长什么样；
  • 输出是原始结果、结构化结果，还是面向用户的结果。
  1. 设计调用规则与触发描述
  • 什么关键词、什么场景触发；
  • 是自动触发还是显式调用；
  • 与相邻 Skill 怎么避免互相抢触发。
  1. 接入底层能力
  • 它底层需要调用哪些 Tool；
  • 这些 Tool 背后走 API、MCP、CLI 还是本地代码；
  • 是否依赖数据库、知识库、文档系统等。
  1. 设计执行流程
  • 先做什么，后做什么；
  • 信息不足时怎么办；
  • 工具失败时怎么处理；
  • 输出前要不要做格式化或校验。
  1. 定义边界与风险控制
  • 不能编造什么；
  • 哪些输入要拒绝；
  • 哪些操作不能自动执行；
  • 哪些结果要显式标注不确定性。
  1. 设计评估方式
  • 触发准不准；
  • 成功率高不高；
  • 输出是否稳定；
  • 是否容易被复用。

你会发现，开发 Skill 的核心目标是：

把某一类任务做成一个可靠、清晰、可复用的能力模块。

2. 开发一个 Agent，通常需要做哪些事情

Agent 的重点和 Skill 不一样。它面对的不是一个固定动作，而是一个更开放的目标。

所以开发 Agent 时，通常要考虑的不只是“它能不能做”，而是“它能不能把事情真正做成”。

一个比较典型的 Agent 开发清单，可以这样理解：

  1. 定义 Agent 的目标、角色与责任范围
  • 它服务谁；
  • 它解决什么问题；
  • 它可以做到哪一步；
  • 它什么时候应该停下来交给人。
  1. 梳理高频用户场景
  • 用户最常见会给它什么目标；
  • 输入是问题、文档、表格、链接还是数据；
  • 用户期待的是结论、报告、动作还是自动执行结果。
  1. 设计能力分层
  • 哪些事情由 Agent 自己判断；
  • 哪些能力下沉成 Skill；
  • 哪些进一步下沉成 Tool；
  • 底层如何通过 API、MCP、CLI 接入。
  1. 设计任务拆解与执行逻辑
  • Agent 如何理解目标；
  • 如何拆成多个步骤；
  • 什么时候调用什么 Skill；
  • 失败时如何重试、降级、追问或中止。
  1. 设计状态与上下文管理
  • 要不要记住当前任务进度；
  • 是否需要记录阶段结果；
  • 是否要记住用户偏好、历史选择、长期背景。
  1. 设计结果整合与交互方式
  • 如何把多步结果整理成最终交付；
  • 什么时候直接执行，什么时候先确认；
  • 什么时候追问，什么时候给建议；
  • 怎样表达不确定性和风险。
  1. 设计安全、权限与治理机制
  • 哪些动作能自动做；
  • 哪些动作必须人工确认；
  • 哪些数据不能访问；
  • 如何保留日志、支持审计、避免误操作。
  1. 建立评估与迭代机制
  • 任务成功率；
  • 用户满意度；
  • 工具调用成功率；
  • 时延、成本、安全性；
  • 哪些问题来自 Prompt，哪些来自 Tool，哪些来自架构。

你会发现，开发 Agent 的核心目标是：

让系统能围绕用户目标，稳定地组织能力、推进任务、交付结果。

3. 两者最大的差别，不在“复杂度”，而在“职责层级”

很多人会觉得：Skill 简单一点，Agent 复杂一点。这么理解不算错，但还不够准确。

更本质的说法是：

Skill 和 Agent 的真正差别，不只是复杂度高低，而是职责层级不同。

  • Skill 更像“能力模块”；
  • Agent 更像“执行主体”。

一个 Skill 可以很复杂，比如一个经营分析 Skill 可能内部也会调用多个 Tool；一个 Agent 也可能很轻，比如一个只负责任务分发和结果汇总的主 Agent。

所以不要简单把它们理解成“小能力”和“大能力”的关系，而要看：

  • 它是在封装一类任务能力；
  • 还是在围绕目标组织多个能力。

4. 放在一张表里看：开发 Skill 和开发 Agent 的差别

维度 开发 Skill 开发 Agent 核心目标 把一类任务做成稳定能力模块 把一个目标做成完整结果 关注重点 边界清晰、输入输出稳定、易复用 目标理解、任务拆解、能力编排、结果交付 目标定义 明确某类任务负责范围 明确用户目标和整体责任范围 能力边界 更强调“做什么 / 不做什么” 更强调“如何组织不同能力完成目标” 底层接入 更关注需要哪些 Tool、API、MCP、CLI 更关注如何选择和协调这些能力 流程设计 通常是相对固定的执行流程 通常是更动态的任务拆解与调度流程 状态管理 通常较轻，很多 Skill 不需要长期状态 通常更重，要管理上下文、阶段结果、偏好 安全治理 强调边界、权限、拒绝条件 强调权限、确认机制、过程可控与审计 评估方式 看触发准确率、成功率、稳定性、复用性 看任务完成率、质量、时延、成本、满意度 更像什么 一个专业工种 一个项目负责人或执行型同事

5. 一个很实用的判断方法

如果你在做系统设计时拿不准某个东西应该做成 Skill 还是 Agent，可以先问自己三个问题：

  1. 它主要是在做一个明确动作，还是在完成一个开放目标？
  • 明确动作：更像 Skill；
  • 开放目标：更像 Agent。
  1. 它的核心价值来自“稳定执行”，还是来自“判断与编排”？
  • 稳定执行：更像 Skill；
  • 判断与编排：更像 Agent。
  1. 它是被上层调度的能力模块，还是在调度别的能力模块？
  • 被调度：更像 Skill；
  • 负责调度：更像 Agent。

6. 最后一句总结

如果把这部分内容压缩成最值得记住的一句话，可以记成：

开发 Skill，重点是把一类任务做深、做稳、做清楚；开发 Agent，重点是把一类目标接住、拆开、推进并最终做成。

所以在真实系统里，很多时候并不是“先选 Skill 还是 Agent”，而是：

  • 先把高频能力做成 Skill；
  • 再让 Agent 去组织这些 Skill；
  • 当任务复杂度继续上升时，再决定是否演进到 Multi-Agent。

这也是为什么一个成熟的 AI 系统，往往不是只靠一个 Agent 就能解决问题，而是要同时把 Skill、Tool、MCP、CLI、Agent 这些层都放在正确的位置上。