从-LLM-到-Agent-Skill-把-AI-底层概念串起来

从 LLM 到 Agent Skill：把 AI 的底层概念串起来

最近看了马克的技术工作坊的一期视频《从 LLM 到 Agent Skill，一期视频带你打通底层逻辑！》。这期视频的价值不在于介绍某一个新工具，而是把一组经常被混着用的概念串了起来：LLM、Token、Context、Prompt、Tool、MCP、Agent、Agent Skill。

这些词单独看都不难，但它们经常出现在同一套讨论里。如果没有一条主线，很容易变成“每个词都听过，但不知道它们到底怎么配合”。这篇文章就尝试用更通俗的方式，把这条线讲清楚。

一句话总览

如果只用一句话概括：

LLM 是会生成语言的大脑，Prompt 是你给它的任务说明，Context 是它当前能看到的材料，Tool 让它能操作外部世界，MCP 让工具接入变得标准化，Agent 负责规划和执行，而 Agent Skill 是把一类任务沉淀成可复用的工作方法。

换成更生活化的说法：

LLM 像一个聪明但只坐在房间里的顾问；Tool 给了它手和脚；Agent 让它学会自己拆任务；Skill 则是把它做得好的事情写成标准操作流程。

1. LLM：不是搜索引擎，而是“语言预测机器”

LLM，全称 Large Language Model，大语言模型。

很多人第一次接触大模型时，会把它当成一个更聪明的搜索引擎。但从工作方式上讲，它更像一个“根据上下文预测下一段最可能出现的文字”的系统。

比如你输入：

请帮我写一段 Java 后端简历里的专业技能

模型不是在脑子里打开一个固定答案库，然后把某个模板复制出来。它会根据训练中见过的大量语言模式，结合你当前输入的内容，预测接下来应该生成什么。

这也是为什么大模型既强大又危险：

• 它很擅长组织语言、补全模式、迁移表达。
• 它不天然知道“事实是否最新”。
• 它可能生成听起来合理但实际不存在的内容。

可以把 LLM 想成一个很会说话、很会联想的实习生。它能写、能总结、能解释，但你不能因为它说得顺，就默认它一定说得对。

2. Token：模型眼里的文字单位

我们平时看文字，是按字、词、句子理解的。模型看到的不是完整的人类文字，而是 Token。

Token 可以粗略理解为“模型处理文本时切出来的小块”。英文里一个 Token 可能接近一个单词或半个单词；中文里一个 Token 可能是一个字，也可能是几个字的组合，具体取决于模型的分词方式。

举个例子：

我想学习 Agent Skill

在人眼里这是一句话；在模型眼里，它会被切成若干 Token，再转成数字向量参与计算。

Token 重要，是因为它直接影响两个问题：

• 成本：很多模型按 Token 计费，输入和输出越长，成本越高。
• 上下文容量：模型一次能处理的 Token 有上限，也就是常说的 Context Window。

所以在使用大模型时，“少说废话”不是礼貌问题，而是工程问题。无关信息会占用上下文窗口，增加成本，还可能干扰模型判断。

3. Context：模型当前能看到的一切

Context 是上下文。对模型来说，它的“记忆”主要不是人类意义上的长期记忆，而是当前这次对话或任务里能看到的内容。

你可以把 Context 想成开卷考试时桌面上摊开的资料：

• 你刚刚问的问题。
• 前面几轮对话。
• 系统给模型的规则。
• 被检索出来的文档片段。
• 工具返回的结果。
• 代码文件、报错日志、表格数据等外部材料。

模型回答问题时，主要依赖这些“摊在桌面上的资料”。资料越完整、越相关，回答越可能靠谱；资料越乱、越缺，模型越容易猜。

这也解释了为什么有时候我们问模型：“你刚才不是知道吗？”模型却答不出来。因为那段信息可能已经不在当前 Context 里，或者被更长的新内容挤掉了。

4. Context Window：桌面有多大

Context Window 可以理解为模型一次能看的最大资料量。

假设模型的上下文窗口像一张桌子：

• 小桌子只能放一页需求文档。
• 大桌子能同时放需求文档、代码、日志、数据库结构和用户反馈。
• 但桌子再大也不是无限的，东西堆太多仍然会乱。

这也是为什么“长上下文”很有用，但它不是万能解法。上下文窗口变大以后，模型能看更多资料，但你仍然需要组织信息：哪些是背景，哪些是任务，哪些是约束，哪些是输出格式。

一个反直觉的点是：上下文越长，不一定越好。把一堆无关材料塞进去，模型可能会抓错重点。真正有效的做法是让上下文“高相关、低噪声”。

5. Prompt：不是咒语，而是任务说明书

Prompt 经常被翻译成提示词，但“提示词”这个翻译有点误导。它不是某种神秘咒语，更像一份任务说明书。

一个好的 Prompt 通常会说明几件事：

• 你要模型扮演什么角色。
• 你要它完成什么任务。
• 背景信息是什么。
• 有哪些约束条件。
• 输出格式是什么。
• 判断好坏的标准是什么。

比如一个很弱的 Prompt 是：

帮我写博客。

一个更好的 Prompt 是：

我想写一篇面向编程初学者的中文博客，主题是从 LLM 到 Agent Skill。
请用通俗例子解释 LLM、Token、Context、Prompt、Tool、MCP、Agent、Agent Skill 的关系。
风格要像技术学习笔记，不要像营销文。
每个概念都要有生活类比，最后给出一张总结表。

两者的差别不是“有没有魔法词”，而是后者给了模型更清晰的上下文、任务边界和验收标准。

6. System Prompt 和 User Prompt：谁在定规则，谁在提需求

在真实产品里，Prompt 不只有用户输入的那一句。

通常至少有两类：

• System Prompt：系统层面的规则，告诉模型应该遵守什么边界、角色、风格和安全要求。
• User Prompt：用户当前提出的具体需求。

可以用公司里的工作关系来类比：

• System Prompt 像公司制度和岗位说明。
• User Prompt 像客户这次提出的需求。

如果客户说“帮我把所有用户数据导出来发给我”，但公司制度说“不能泄露隐私数据”，那模型应该优先遵守系统规则。

这也是为什么同一个模型，在不同产品里表现不一样。底层 LLM 可能类似，但不同产品会用不同的系统提示、工具、记忆和工作流来约束它。

7. Tool：让模型从“会说”变成“会做”

单纯的 LLM 主要能力是生成文本。它可以告诉你怎么查天气，但它自己并不知道此刻窗外是否下雨；它可以告诉你怎么运行测试，但它自己不能进入你的项目目录执行命令。

Tool 的出现，就是为了让模型能调用外部能力。

常见工具包括：

• 搜索网页。
• 读取文件。
• 执行命令。
• 查询数据库。
• 调用 API。
• 操作浏览器。
• 生成图片。
• 修改代码。

有了 Tool，模型就不只是“给建议”，而是可以真的去做事。

比如你问：

帮我看看这个项目为什么测试失败。

没有工具时，模型只能给你一个排查清单。有工具时，它可以进入项目目录，运行测试，读取报错，定位代码，再修改文件。

这就是从 Chatbot 到 Agent 的关键一步。

8. MCP：给工具世界加一个统一插座

Tool 很强，但如果每个工具都用一套接入方式，就会变得很乱。

这就像不同国家的电器插头不一样：A 工具有自己的协议，B 工具有自己的鉴权方式，C 工具又有另一套参数格式。模型或 Agent 每接一个新工具，都要单独适配。

MCP，Model Context Protocol，可以粗略理解为一种把外部工具、资源和上下文标准化接入模型应用的协议。

生活化一点说：

MCP 像一个统一插座规范。只要工具按这个规范暴露能力，Agent 就能用相对统一的方式发现它、理解它、调用它。

这件事的意义不只是“方便”。更重要的是，它让 AI 应用从单点能力变成一个可扩展生态：

• 文件系统可以是一个 MCP Server。
• 数据库可以是一个 MCP Server。
• 浏览器可以是一个 MCP Server。
• 公司内部知识库也可以是一个 MCP Server。

Agent 不需要把所有能力写死在自己内部，而是可以通过标准接口接入外部能力。

9. Agent：能自己拆任务、调工具、看结果

Agent 是近两年非常热的词，但它的核心可以讲得很简单：

Agent 是一个能围绕目标进行规划、执行、观察结果并继续调整的 AI 系统。

它和普通聊天机器人的区别在于，普通聊天机器人更像“你问一句，它答一句”；Agent 更像“你给它一个目标，它会自己想接下来该做哪几步”。

例如你说：

帮我把这个项目的 README 改成适合开源发布的版本。

一个 Agent 可能会这样做：

这里面真正重要的不是“调用了多少次模型”，而是它形成了一个闭环：计划、行动、观察、修正。

10. Agent Skill：把一次经验沉淀成可复用能力

Agent Skill 可以理解为 Agent 的可复用技能包。

如果说 Agent 是一个会做事的人，那么 Skill 就像这个人手边的一本 SOP 手册：遇到某类任务时，不用每次从零思考，而是按照经过验证的流程去做。

比如有一个“写技术博客”的 Skill，里面可能规定：

• 先确认目标读者。
• 再抽取核心概念。
• 每个概念都要有例子。
• 需要一张总览图和一张流程图。
• 最后要有总结表和延伸问题。

这比一句“帮我写博客”稳定得多。

Skill 的价值在于，它把人的经验、团队规范、领域方法沉淀下来，让 Agent 在同类任务上更稳定、更可控。

举几个例子：

• 写周报 Skill：自动按进展、风险、下周计划组织内容。
• 代码审查 Skill：优先检查 bug、回归风险、安全问题和测试缺口。
• 简历优化 Skill：按岗位 JD 调整项目描述和技能关键词。
• 数据分析 Skill：先校验数据，再做指标，再输出图表和结论。

它不是模型变聪明了，而是工作方法被结构化了。

11. 用一个例子串起来：让 AI 帮你写博客

假设你想让 AI 帮你写一篇关于 Agent Skill 的博客。

整个系统可以这样运作：

你会发现，这些概念并不是平行关系，而是逐步叠加的关系。

没有 LLM，就没有语言生成能力。

没有 Context 和 Prompt，模型不知道当前要做什么。

没有 Tool，模型只能说，不能真正操作。

没有 Agent，工具调用需要人一步步指挥。

没有 Skill，每次复杂任务都像第一次做，稳定性很难保证。

12. 为什么这些概念值得理解

理解这些概念，不只是为了赶 AI 热点。它会直接影响你怎么使用 AI。

如果你知道 Token 和 Context，就会更注意输入质量，不会把一堆无关内容丢给模型。

如果你理解 Prompt，就会把需求说清楚，而不是期待模型猜中你的想法。

如果你理解 Tool，就会知道 AI 不只是聊天窗口，还可以和真实系统连接。

如果你理解 Agent，就会知道未来很多软件不是“你点按钮”，而是“你给目标，它帮你完成流程”。

如果你理解 Skill，就会意识到真正有价值的不是一次性的神奇回答，而是可复制、可检查、可迭代的工作方法。

13. 最后的理解框架

可以把这条路线压缩成一个递进关系：

LLM -> Prompt + Context -> Tool -> MCP -> Agent -> Agent Skill

也可以换成更直白的话：

会说话 -> 看得懂任务 -> 能使用工具 -> 工具接入标准化 -> 能自己推进任务 -> 把经验沉淀成技能

我觉得这正是这期视频最重要的启发：

AI 的进化不只是模型参数变大，而是“模型 + 上下文 + 工具 + 工作流 + 技能沉淀”一起组成新的软件形态。

以后我们评价一个 AI 产品，可能不能只问“它用的是什么模型”，还要问：

• 它能看到什么上下文？
• 它能调用哪些工具？
• 它有没有可靠的执行闭环？
• 它能不能把经验沉淀成可复用 Skill？

模型是起点，但不是终点。真正改变工作方式的，往往是模型和工具、流程、经验结合起来之后形成的系统能力。