从LLM到Agent Skill

这篇文档想用一条"因果链"把 AI 应用里最常被提到的几个概念串起来：

因为有了 LLM，所以才有 Token；因为要控制 Token，所以才有 Context 和 Context Window；因为窗口不够、知识不新，所以才有 RAG；因为要让模型听懂人话，所以才有 Prompt；因为模型不能动手，所以才有 Tool；因为每家工具都不一样，所以才有 MCP；因为只会调用工具还不够聪明，所以才有 Agent；因为 Agent 不可能什么都会，所以才有 Agent Skill。

读完这条线，你基本就看懂了今天绝大多数 AI 产品。

先放两张“地图”，略过也没关系，看完全文再回来对照会更有感觉：

LLM

故事要从 LLM（Large Language Model，大型语言模型） 说起。

过去我们想让电脑"懂人话"非常难，得一个规则一个规则去写。后来人们发现：只要喂给神经网络足够多的文本，让它不断玩"猜下一个字"的游戏，它就会慢慢学会语言，甚至学会里面的知识。这种模型一旦参数规模足够大，就叫 LLM。

你可以把它简单理解为：“一个读过几乎整个互联网、非常擅长接话的’超级文科生’”。

它的几个特点值得先记住，后面的问题都从这里衍生：

• 生成式：它不是在数据库里查答案，而是一个字一个字"猜"出来的。
• 概率性：同样的问题，它可能给你不同的答案。
• 无状态：它不会真的"记得"你，每次对话都是重新看一遍历史。
• 知识截止：训练数据截止到某个时间，之后的事它不知道。
• 会幻觉（Hallucination）：因为它是“猜”的，它有时会一本正经地胡说八道——写出根本不存在的 API、编造并不存在的论文。后面的 RAG、Tool 很大程度上也是在治“幻觉”这个毛病。

Temperature 与 Top-p

既然是“猜下一个字”，那到底是“每次都猜最有把握的那个”，还是“偶尔选一下第二、第三名”？这就是 采样参数 控制的事情：

• Temperature（温度）：值越低（如 0）输出越确定、越保守；值越高（如 1.0+）输出越随机、越有“创意”。
• Top-p（核采样）：只从概率累积前 p 的候选词里选，过滤掉长尾里的奇怪词。

经验法则：写代码、抽信息这类“求稳”的任务设低温；写文案、头脑风暴这类“求花样”的任务适当提高温度。

正是因为 LLM 是"猜字"的，我们才需要关心它"一次能看多少字"、“怎么让它猜得更准”。于是下面这些概念就一个接一个冒出来了。

Token

既然模型是在"猜下一个字"，那它眼中的"字"到底是什么？ 答案是 Token。

Token 是大模型处理文本的基本单元。模型看不到"汉字"或"英文单词"，它看到的是一串数字 ID，每个 ID 对应一个 Token。大致规律：

• 英文里，一个 Token ≈ 3～4 个字符，或者 3/4 个单词。
• 中文里，一个汉字通常对应 1～2 个 Token。

为什么你得关心 Token？因为：

• 模型一次能"看"多少、能"说"多少，都是按 Token 算的。
• 调 API 花多少钱，也是按 Token 算的（输入和输出分开计费）。

一句话：Token 就是模型世界里的"字"，也是"时间"和"金钱"的计量单位。

Context

既然每次对话模型都"不记得"之前聊过什么，那它是怎么看起来有记忆的？
秘诀就是：每次请求时，把之前聊过的内容重新塞一份给它。这坨被塞进去的东西，就叫 Context（上下文）。

一次请求里的 Context 一般包括：

• System Prompt（告诉它"你是谁、该怎么做事"）
• 历史对话（之前的一问一答）
• 你这次的新问题
• 工具调用返回的结果
• 通过 RAG 临时塞进来的资料

所以模型的"记忆"其实是假的，它是一个没有记忆的人，每次都靠你把笔记递到它面前。

Context Window

可问题来了：既然每次都要把历史塞进去，那能塞多少？
这就是 Context Window（上下文窗口） —— 它规定了 Context 最多能有多少 Token。

• 早期模型只有 4K、8K，一聊长一点就"忘事"。
• 现在主流模型普遍 128K，甚至有 200K、1M 的。
• 超过这个数，多出来的内容会被截掉，模型根本看不到。

听起来把窗口做大就完事了，但没那么简单：

• 窗口越大，越贵（Token 更多）。
• 窗口越大，越慢。
• 而且还会出现"大海捞针"现象：塞进去一百万字，关键那一句它反而漏看了。

正因为窗口有限、塞太多又容易"走神"，我们才要想办法：“哪些信息值得塞进去？”——这就为下一个概念 RAG 埋下了伏笔。

RAG

模型的知识是"训练时就冻住"的，而且你公司内部的文档它根本没见过。 要是每次有新知识都重新训练一次模型，成本高到离谱。

于是有人想到一个聪明办法：
干脆不改模型，而是在提问前，先去资料库里把相关内容捞出来，拼到 Prompt 里一起发给模型。
这就是 RAG（Retrieval-Augmented Generation，检索增强生成）——“先检索，再生成”。

典型流程：

1. 把文档切成小块，转成向量，存进向量数据库。
2. 用户提问时，把问题也转成向量，去库里找最相似的几块。
3. 把这几块内容 + 用户问题一起发给 LLM。
4. LLM 基于这些"临时参考资料"作答。

这里的关键是 Embedding（向量化）：用一个专门的模型把一段文字变成一串数字（一个高维向量），语义越相近的文本，向量之间的距离就越近。“语义搜索”本质上就是在比这些向量的距离。

RAG 一举解决了两个老大难：

• 知识过时 → 更新向量库就行，不用重训模型。
• 私有数据 → 公司内部资料不进训练集，也能被模型"用上"。

顺便说说微调（Fine-tuning）

和 RAG 并列的另一条路子叫 微调：用自己的数据再训练一次模型，让它的“本能”里就带上你的知识或风格。两者常被拿来对比：

维度	RAG	Fine-tuning
适合	知识类、经常更新	风格/格式/行为定制
成本	低，随用随改	高，需数据和训练
露出源文	可以	不行
效果	贴得准	更融合、更流畅

实际项目里更常见的答案是：能 RAG 解决的就不微调，两者也可以混用。

Prompt

不管是 Context 还是 RAG，最后都要变成文字喂给模型。那"怎么说话"模型才听得最懂？
这就是 Prompt（提示词） 关心的问题。

Prompt 就是你发给模型的那段话——问题、指令、背景统统算。
一个好的 Prompt 基本原则就三个字：清楚、具体、明确。

常见技巧：

• 给它一个角色（“你是一位资深的 Python 工程师……”）
• 举几个例子（Few-shot）
• 让它"一步步想"（Chain-of-Thought）
• 规定输出格式（JSON、Markdown、表格）
• 划清边界（“不许编造、不知道就说不知道”）

Prompt 一般分两类：

System Prompt

由开发者在幕后预设，相当于给这个 AI 发的"员工手册"：你是谁、能干什么、不能干什么、说话什么风格。用户通常看不到。

User Prompt

用户每轮对话实际输入的内容，是模型这次要回应的"具体任务"。

一句话记住区别：System Prompt 定"人设"，User Prompt 提"需求"。

Tool

会说话还不够，很多事光靠"说"根本完不成。
你问模型"今天天气怎么样"、“帮我查一下数据库”、“现在几点”——它其实完全不知道，因为它不能上网、不能读文件、不能执行代码。

于是人们给模型加了一双"手"，这双手叫 Tool（工具）。

做法是这样的：

1. 开发者提前告诉模型：“我这有几个工具，名字叫 X，作用是 Y，参数长这样。”
2. 模型遇到解决不了的事，就输出一个"我要调用工具 X，参数是 …"。
3. 应用层真去执行这个工具，拿到结果。
4. 把结果塞回 Context，再让模型基于结果继续回答。

有了 Tool，LLM 就从"只会聊天"升级成"能做事"：查天气、查数据库、发邮件、跑代码、调 API……它终于能对真实世界产生影响了。

这套机制在各家 API 里有个官方名字，叫 Function Calling。很多人把“函数调用”和“工具调用”混着用，指的是同一件事。

需要注意的是：模型自己并不真的执行工具，它只是输出“我想调工具 X、参数是 …”这样的指令，真正跑工具的是你的应用程序。模型、应用层、工具三者的职责分工如下：

MCP

Tool 很好，但每家产品都自己设计一套工具接入方式，结果就是：
A 产品写的工具，B 产品用不了；换个模型，又得全部重写一遍。非常像 USB 出现之前的各种乱七八糟的接口。

为了解决这个"插头不统一"的问题，Anthropic 提出了 MCP（Model Context Protocol，模型上下文协议）。

你可以把 MCP 理解为"AI 世界的 USB-C"：

• 以前：每家 AI 应用都要为自己的工具写私有协议。
• 现在：只要你按 MCP 写一个 Server，任何支持 MCP 的客户端（Claude Desktop、IDE、各种 Agent）都能直接接上用。

MCP 标准化了三类东西：

• Tools：模型可以调用的函数。
• Resources：模型可以读取的数据（文件、API 数据等）。
• Prompts：可以复用的提示词模板。

一句话：MCP 让工具生态从"一家一个样"变成"一次实现、处处可用"。

Agent

现在模型能说、能查、能动手，还能插各种工具。但它还差一样东西：自己决定下一步该干什么。
一般聊天机器人是"你问一句，我答一句"；而很多真实任务需要连续好几步：先想、再查、再做、再看结果、再改。

能够自主规划 → 调用工具 → 观察结果 → 继续迭代，直到把一个复杂任务搞定的系统，就叫 Agent（智能体）。

它和传统 Chatbot 的区别：

维度	Chatbot	Agent
交互	一问一答	多轮自主执行
工具	很少或没有	大量工具调用
目标	回答问题	完成任务
控制流	用户驱动	模型驱动

最经典的 Agent 工作循环是 ReAct：

1. Thought：我现在该干嘛？
2. Action：那我调用哪个工具、传什么参数？
3. Observation：工具返回了什么？
4. 回到第 1 步，直到任务完成。

Claude Code、Cursor、Devin、各种"深度研究"功能，本质上都是 Agent。

从单 Agent 到多 Agent

当任务复杂到一个 Agent 快处理不过来时，一个自然的演进就是 多 Agent 协作：一个主 Agent 负责拆解任务和協调，调用多个专家 Sub-Agent（代码小弟、查资料小弟、写作小弟…）并行干活，最后汇总。Claude Code 的 Sub-Agent、OpenAI 的 Swarm、各种“深度研究”本质都是这个思路。

多 Agent 的好处是：每个 Agent 的上下文更短、职责更单一，不容易“走神”。代价是：协调成本更高，对调度系统的要求更高。

Agent Skill

Agent 很强，但有个新麻烦：任务一多，它的 System Prompt 就会变成一本又臭又长的"百科全书"。
你既要教它怎么写代码，又要教它怎么查资料、怎么做 PPT、怎么发邮件……全塞在一个 Prompt 里，又贵又乱，还互相干扰。

那能不能**“要用哪块能力，才加载哪块”**？
于是就有了 Agent Skill（技能） 这个概念。

Skill 的核心机制是渐进式披露（Progressive Disclosure）：一开始只把“有哪些 Skill、各自干嘛用”的索引卡片塞给 Agent；相关场景出现时，Agent 再主动把对应的 Skill 详细内容读进来。

一个 Skill 就是把"做好某一类任务所需的一切"打包起来：

• 触发条件（什么场景应该加载它）
• 领域知识与最佳实践
• 推荐的工作流
• 要用到的工具或子 Agent
• 输入 / 输出规范和示例

可以这样理解三者的层级关系：

• Tool：一个原子动作（读文件、发请求）。
• MCP：把一堆 Tool / Resource / Prompt 用标准协议打包对外。
• Skill：面向"某类任务"的专家手册，教 Agent 在这种场景下该怎么思考、怎么动手。

Skill 的好处很直观：

• 按需加载：不用一次把所有知识塞进 Context，省 Token 也更聚焦。
• 可复用：同一个 Skill 可以跨项目、跨 Agent 共享。
• 易演进：要加新能力，就加一个新 Skill，而不是改核心 Prompt。
• 可组合：复杂任务可以同时挂多个 Skill 协作完成。

总结

回过头看，这一整套东西其实就是一条**“发现问题 → 打补丁 → 再发现问题 → 再打补丁”** 的演进链：

1. 有了 LLM，AI 终于会说话了。
2. 为了让它说得准、算得清钱，出现了 Token。
3. 因为它没有记忆，我们用 Context 手动喂它历史。
4. Context 不能无限塞，所以有了 Context Window 这道红线。
5. 窗口有限、知识会过时，于是有了 RAG 按需补资料。
6. 要让它更好地理解任务，我们钻研 Prompt。
7. 光会说不够，得能动手，于是加上了 Tool。
8. 工具标准不统一太乱，MCP 把接口统一了。
9. 把"说 + 做 + 思考 + 迭代"合起来，就成了 Agent。
10. Agent 不可能什么都会，于是再用 Agent Skill 把能力模块化、可复用。

理解了这条"因为…所以…"的链条，你看今天几乎所有 AI 产品的架构图，都会有一种"原来如此"的感觉。