大模型、Agent 与 Skill：三者协作机制与调用原理

1. 先分清三个组件

很多人会把 Agent 和大模型混为一谈，但在 Skill 体系里，必须拆成三个独立组件：

组件	角色定位	核心职责
大模型	思考层 / 推理层	理解用户意图、做任务规划、判断要不要用 skill、决定下一步调用什么
Agent	执行层 / Runtime	扫描 skill、加载文件、执行工具、跑脚本、读写磁盘、把结果回传给大模型
Skill	知识层 / 流程层	提供某类任务的操作手册、规范、脚本、模板和参考资源

三者的关系不是“Agent = 大模型 + Skill”，而是：

大模型负责“想”
Agent 负责“做”
Skill 负责“教”

一个常见误解是：Agent 会自己理解任务、自己选择 skill、自己执行流程。

更准确的说法是：

• 大模型决定“要不要用 skill、用哪个 skill、接下来该做什么”；
• Agent只负责把大模型的决定落地，例如加载 skill 文件、调用 Read/Shell、返回 tool result；
• Skill本身不会运行，它只是被按需加载的一份操作说明和资源包。

---

2. 三者的职责边界

2.1 大模型：思考层

大模型负责所有“需要理解”和“需要判断”的工作：

• 理解用户自然语言任务；
• 阅读当前上下文和历史消息；
• 判断当前任务是否需要 skill；
• 在 skill 索引中做语义匹配；
• 决定调用哪个 skill；
• 拿到 skill 正文后，继续规划后续步骤；
• 决定还要不要再调用 Read、Shell、Grep 等工具。

大模型不直接：

• 扫描磁盘上的 skill 目录；
• 读取 SKILL.md 文件；
• 执行 shell 命令；
• 访问 MCP、浏览器、Git 等外部系统。

这些动作都要通过 Agent 提供的工具接口来完成。

2.2 Agent：执行层

Agent 是大模型的运行时执行环境，也可以理解为 Runtime / Tool Executor。

它负责：

• 启动时扫描 skill 目录，建立 skill 索引；
• 把 skill 元数据和工具列表提供给大模型；
• 接收大模型发出的 tool call；
• 根据参数加载对应 skill 文件；
• 执行 Read、Shell、Grep、MCP 等具体工具；
• 把执行结果封装成 tool result 回传给大模型；
• 维护会话上下文、工具权限、文件路径等运行环境。

Agent 不负责：

• 理解用户真正想要什么；
• 自行决定业务逻辑；
• 自行选择 skill；
• 自行推理下一步计划。

Agent 是“执行器”，不是“决策者”。

2.3 Skill：知识层

Skill 不是运行时组件，也不是会主动执行的程序，而是：

• 一份模块化的任务手册；
• 一套可复用的 SOP；
• 一组配套资源：参考文档、脚本、模板、schema。

Skill 提供的是：

• 元数据索引：name、description；
• 入口说明：SKILL.md；
• 扩展资源：references/、scripts/、assets/。

Skill 自己不会“运行”，只有在大模型决定使用它、Agent 把它加载进上下文之后，才会参与后续任务。

---

3. 三者协作关系

可以用下面这张图理解整体关系：

用户
 ↓
大模型（思考层）
 ├─ 理解任务
 ├─ 看 skill 索引
 ├─ 决定调用哪个 skill / 工具
 └─ 根据返回结果继续推理
 ↓ tool call
Agent（执行层）
 ├─ 扫描并注册 skill
 ├─ 加载 SKILL.md
 ├─ 执行 Read / Shell / MCP
 └─ 返回 tool result
 ↓
Skill（知识层）
 ├─ name / description
 ├─ SKILL.md
 ├─ references/
 ├─ scripts/
 └─ assets/

更直白一点：

大模型：决定“用什么”
Agent：负责“怎么取、怎么跑”
Skill：提供“按什么做”

3.1 一个例子

用户说：“帮我排查 GitHub Actions 为什么挂了。”

1. 大模型理解这是 CI 故障排查任务；
2. Agent事先已经把 skill 索引提供给大模型，大模型看到 ci-investigator 的 description 可能相关；
3. 大模型决定调用 Skill 工具，参数为 skill-name=ci-investigator；
4. Agent收到 tool call，从磁盘加载 ci-investigator/SKILL.md；
5. Agent把 skill 正文作为 tool result 回传给大模型；
6. 大模型阅读 skill 内容，继续决定调用 Shell 看 workflow 日志、Read 看配置文件；
7. Agent继续执行这些工具；
8. 大模型汇总结果，输出排查结论。

这里可以看到：

• “要不要用 skill”是大模型决定的；
• “skill 文件怎么加载”是 Agent 做的；
• “具体排查步骤是什么”来自 Skill。

---

4. Skill 解决什么问题

Skill 的核心思想，是把某一类任务的操作知识、规范、手册模块化；平时只保留轻量索引，真正需要时再展开完整说明。

它和 Workflow 的区别在于：

对比项	Workflow	Skill
驱动方式	固定流水线	大模型理解任务后按需调用
灵活性	低	高
上下文成本	往往整段流程常驻	渐进式披露，命中后才加载详情

Skill 的工程价值：

1. 减少上下文膨胀：不是每个任务都加载全部规则，只在匹配时展开。
2. 把流程资产化：SOP、团队规范、领域知识可版本管理、评审、复用。
3. 把确定性步骤外包给脚本：大模型负责理解和决策，机械操作交给 scripts/。
4. 适合团队协作：Skill 是目录和文件，可进 Git、做 CI、做 Code Review。

OpenAI Codex 文档中也明确提到：Skill 使用 Progressive Disclosure（渐进式披露）——系统先只看元数据，只有判断当前任务匹配时，才加载完整 SKILL.md。

---

5. Skill 是什么

Skill 不是普通提示词片段，而是：

操作手册 + 参考文档 + 脚本 + 模板约束

组成结构：

• 入口文件：SKILL.md
• 参考文档：references/
• 脚本资源：scripts/
• 模板与约束：assets/

Skill 被加载后，大模型按 SKILL.md 的步骤继续规划；Agent 按大模型的 tool call 去读取参考文档、执行脚本、应用模板。

---

6. Skill 的典型目录结构

skills/
└── my-skill/
    ├── SKILL.md          # 必需：元数据 + 执行说明（入口文件）
    ├── scripts/          # 可选：可执行脚本
    │   ├── run.sh
    │   └── parse.py
    ├── references/       # 可选：参考文档
    │   ├── API.md
    │   └── examples.md
    ├── assets/           # 可选：模板、schema、静态资源
    │   ├── template.md
    │   └── output_schema.json
    └── agents/
        └── openai.yaml   # 可选：平台额外配置

6.1 SKILL.md 最少要有什么

---
name: your-skill-name
description: 这个 skill 做什么，以及什么时候该用它
---

这两个字段是整个 Skill 体系的路由索引：

• name：唯一标识，供显式调用或 tool 参数使用；
• description：隐式匹配时的核心依据，相当于 skill 的“路由规则”。

description 必须同时写清：

• WHAT：这个 skill 能做什么；
• WHEN：什么任务、关键词、场景下该用它。

---

7. Skill 的触发方式

7.1 显式触发

用户直接指定 skill：

• “用 create-skill 帮我写一个 skill”
• “按 code-review skill 的标准 review 这次改动”

此时通常是大模型直接识别用户点名，再让 Agent 加载对应 skill。

7.2 隐式触发

用户没有点名 skill，但大模型根据任务语义，在 skill 索引中匹配 description，判断某个 skill 可能相关。

Codex 文档说得很直白：隐式触发主要依赖 description。

因此 description 不是简介，而是路由规则。

---

8. 三者协作的完整生命周期

可以把整个流程拆成 5 步：

注册 → 暴露索引 → 大模型匹配 → Agent 加载 → 大模型继续规划并驱动 Agent 执行

8.1 注册：Agent 扫描 Skill

Agent 启动或会话初始化时，会扫描 skill 目录，递归查找所有 SKILL.md，解析出：

• name
• description
• skill 路径

然后建立 skill 索引。

Cursor 中常见位置：

类型	路径	作用范围
个人 skill	~/.cursor/skills/	所有项目
项目 skill	.cursor/skills/	当前仓库
内置 skill	~/.cursor/skills-cursor/	Cursor 内置

这一步是 Agent 做的，不是大模型做的。

8.2 暴露索引：Agent 把 Skill 清单交给大模型

Agent 不会一开始就把所有 skill 全文塞给大模型，而是只提供索引。

在 Cursor 中，类似下面这种 skill 清单会进入大模型上下文：

<available_skills>
  <agent_skill fullPath=".../create-skill/SKILL.md">
    Create Cursor Agent Skills. Use when authoring a new skill...
  </agent_skill>
  <agent_skill fullPath=".../sdk/SKILL.md">
    Guide users building apps on top of the Cursor SDK...
  </agent_skill>
</available_skills>

此时大模型只知道：

• 有哪些 skill；
• 每个 skill 是干什么的；
• 文件路径在哪里。

此时还没有加载任何 skill 正文。

8.3 匹配：大模型决定要不要用 Skill

用户任务进入后，由大模型做语义理解和 skill 匹配，判断：

1. 当前任务是否需要 skill；
2. 如果需要，哪个 skill 最相关；
3. 是用户显式指定，还是隐式命中。

匹配依据主要是：

• 用户是否直接点名某个 skill；
• skill 的 description 是否匹配当前任务；
• 当前上下文是否已经进入某个特定工作流。

这一步发生在大模型思考层，不是 Agent 自主判断。

8.4 加载：Agent 按大模型指令读取 Skill

大模型决定使用某个 skill 后，会通过 tool call 告诉 Agent 去加载它。

常见两种方式：

方式 A：Skill 被包装成一个 Tool

在 OpenCode / Codex 风格实现里，Agent 会提供一个 Skill 工具给大模型：

{
  "tool": "Skill",
  "arguments": {
    "skill-name": "ci-investigator"
  }
}

Agent 收到后：

1. 根据 skill-name 查找本地 skill 目录；
2. 读取 SKILL.md 全文；
3. 必要时准备 references / scripts / assets 路径；
4. 把 skill 内容作为 tool result 回传给大模型。

方式 B：大模型直接调用 Read 工具

在 Cursor 中，大模型也可能直接发起：

Read(path=".../create-skill/SKILL.md")

这本质上仍然是：

大模型下指令 → Agent 读文件 → 把内容回传给大模型

无论哪种方式，读磁盘、加载正文的动作都在 Agent 执行层，不在大模型内部。

8.5 执行：大模型规划，Agent 落地

Skill 正文进入大模型上下文后，后续流程变成：

1. 大模型阅读 skill 中的步骤和约束；
2. 大模型决定下一步调用什么工具；
3. Agent执行 Read / Shell / Grep / MCP 等工具；
4. Agent把结果回传给大模型；
5. 大模型继续推理，直到任务完成。

如果 skill 中还有二级资源，也是同样模式：

• 需要参考文档 → 大模型决定 Read → Agent 读取；
• 需要脚本 → 大模型决定 Shell → Agent 执行；
• 需要模板 → 大模型决定 Read → Agent 读取 → 大模型按模板组织输出。

---

9. 重点：Skill 是如何被调用和加载的

这一节专门回答：“到底谁调用 skill？到底谁加载 skill？”

9.1 调用 Skill 的是大模型，不是 Agent

“调用 skill”指的是：决定使用哪个 skill。

这个动作发生在 function calling / tool calling 的推理阶段，属于大模型行为。

例如：

{
  "tool": "Skill",
  "arguments": {
    "skill-name": "ci-investigator"
  }
}

含义不是“Agent 自己要用 skill”，而是：

大模型：我现在需要 ci-investigator 这份手册，请执行层帮我取过来。

9.2 加载 Skill 的是 Agent，不是大模型

“加载 skill”指的是：从磁盘读取 skill 文件，并把内容送回上下文。

这个动作属于 Agent 执行层。

Agent 会做：

• 查 skill 注册表；
• 定位 skill 目录；
• 读取 SKILL.md；
• 必要时继续读取 references / scripts / assets；
• 封装 tool result；
• 附带 tool_use_id 回传给大模型。

大模型自己不能直接访问本地文件系统，它只能通过 Agent 提供的工具间接获取 skill 内容。

9.3 使用 Skill 的仍然是大模型

Skill 被加载进上下文后，真正理解并遵循 skill 步骤的仍然是大模型。

Agent 不会“理解 skill 然后自己执行完整个流程”，它只负责：

• 单次工具调用；
• 单次文件读取；
• 单次脚本执行；
• 单次结果返回。

是否进入下一步、是否继续读 reference、是否运行 script，依然由大模型决定。

9.4 一次完整时序

用户提出任务
  ↓
Agent 预先扫描 skill 目录，建立索引
  ↓
Agent 把 skill 索引 + 工具列表交给大模型
  ↓
大模型理解任务，并判断是否需要 skill
  ↓
大模型命中某个 skill
  ↓
大模型发起 tool call（Skill / Read）
  ↓
Agent 加载 SKILL.md 全文
  ↓
Agent 通过 tool result 把 skill 内容回传给大模型
  ↓
大模型阅读 skill，继续规划后续步骤
  ↓
大模型继续发起 Read / Shell / MCP 等 tool call
  ↓
Agent 逐项执行并回传结果
  ↓
大模型汇总并输出最终结果

9.5 Progressive Disclosure 在三层架构中的体现

Skill 的“渐进式披露”也要按三层来理解：

层级	谁参与	看到什么
第一层	Agent → 大模型	仅 skill 元数据：name、description、路径
第二层	Agent 加载 → 大模型阅读	SKILL.md 正文
第三层	大模型决定 → Agent 执行	references/、scripts/、assets/

所以：

• Agent 负责“把正确的内容在正确的时机送给大模型”；
• 大模型负责“判断什么时候需要更深一层内容”；
• Skill 负责“把知识按层次组织好”。

---

10. 和普通 Tool 调用有什么相同与不同

Skill 本质上是一种特殊工具或特殊资源加载机制，但它和普通 Tool 的关系可以这样理解：

10.1 相同点

• 都是大模型通过 tool call 触发；
• 都由 Agent 执行；
• 都以 tool result 形式回传给大模型；
• 大模型拿到结果后再决定下一步。

10.2 不同点

对比项	普通 Tool	Skill
返回内容	单次执行结果	一份完整操作手册
作用	完成一个动作	提供一套流程和知识
后续行为	通常一步结束	往往会触发多轮 Read / Shell / MCP
生命周期	一次性	加载后持续指导后续多步执行

所以 Skill 不是普通工具的简单替代品，而是：

先用 Skill 加载“做法”
再反复用普通 Tool 完成“动作”

---

11. Skill 相比普通提示词的优势

11.1 降低上下文成本

不是每个任务都加载全部规则，只在匹配时展开。

11.2 把经验沉淀成可复用资产

团队规范、排查手册、发布流程、Review 标准都可以 skill 化。

11.3 把机械步骤交给脚本

大模型负责理解、判断、编排；脚本负责稳定执行。

11.4 更适合长期维护

Skill 是文件，不是散落在聊天记录里的临时提示词，可以版本管理、评审、共享。

---

12. 设计 Skill 时的关键原则

12.1 description 就是给大模型看的路由规则

不要写：

description: 帮助处理文档

要写：

description: Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.

因为真正做路由判断的是大模型，不是 Agent。

12.2 入口文件保持精简

SKILL.md 只放大模型决策和执行规划所需的核心步骤，细节拆到 reference 文件。

12.3 渐进式披露

先给索引，再给正文，最后给附属资源。

12.4 明确哪些步骤由 Agent 执行

在 skill 里写清楚：

• 哪些内容只要 Read；
• 哪些命令应该 Shell；
• 哪些校验应该跑 script；
• 哪些输出必须套 template / schema。

---

13. 总结

三者关系可以压缩成三句话：

1. 大模型负责理解、判断、规划；
2. Agent负责加载、执行、回传；
3. Skill负责提供按需展开的操作手册和资源。

Skill 机制的关键不是“Agent 会 skill”，而是：

Agent 先注册 skill 索引
大模型决定何时调用哪个 skill
Agent 再按需加载 skill 内容
大模型再基于 skill 继续驱动 Agent 执行

如果要抓住最重要的一点，就是：

Skill 的调用发生在思考层，Skill 的加载发生在执行层，Skill 的使用又回到思考层。

这也是 Skill 比普通长提示词更适合 Agent 工程化的根本原因。