AI 概念大扒皮：从 LLM 到 Agent，一次说清楚
🤖 AI 概念大扒皮：从 LLM 到 Agent，一次说清楚
这些词你认识几个？不管认识多少，今天都给你扒个底朝天。所谓智能体，其实是由所有"不需要智能"的部分拼凑而成的；那些花里胡哨的新概念，大多不过是新瓶装旧酒。
涉及关键词：LLMPromptContextMemoryAgentRAGFunction CallingMCPSkillSub-Agent
💡 先清空大脑
忘掉你已知的一切，跟着故事线走——你会发现这些概念都是从同一个起点，一步步生长出来的。
🧠 第一步：语言模型长大了
一切混乱的起点，是这个古老的东西——语言模型。早期的小模型基本上是个智障，只会简单的文字接龙。但随着参数规模不断膨胀，在某个临界点，它突然"涌现"出了真正的智能。
为了和之前的小模型做区分，我们在前面加了个"大"字：
🆕 词汇① 大语言模型（LLM）
LLM 本质上只做一件事：根据上文，预测下一个字。如果只是这么用，它看起来仍然是个智障。
小模型\n（智障阶段）
参数不断增大
🌟 大语言模型 LLM\n（涌现出智能）
把 LLM 想象成你的员工
把自己想象成一个老板，LLM 是你的员工，就叫他「小 L」。小 L 服务你的方式很特别：只能一问一答，问完就结束，不能追问。这个特点非常关键，后面还会用到。
你们每次的对话，你给它起了个洋气的名字：
🆕 词汇② Prompt（提示词）
仔细观察每次对话，你发现里面的内容可以细分：有的是背景信息，有的是最终指令。于是背景信息那部分，你单独起名叫：
🆕 词汇③ Context（上下文）
🔁 第二步：让小 L 记住你
问题来了：小 L 只能一问一答，如何追问？
你想了个聪明的办法——把历史对话塞进 Context，每次提问前带上之前的所有交流记录，伪装成连续对话。
🆕 词汇④ Memory（记忆）
随着对话越来越长，Memory 会越来越大，占用大量上下文空间。于是你又让 LLM 对历史记录进行压缩总结，减少长度，提高效率。
追加到
你的第 N 次问题（Prompt）
📦 拼装后发给 LLM
历史对话记录（Memory / Context）
小 L 回答
小结： 到目前为止，你已经发明了 4 个新词：LLMPromptContextMemory。一个原本只会词语接龙的小 L，现在已经可以进行有记忆的连续对话了。🤖 第三步：给小 L 配上工具
你很快发现小 L 有个致命缺陷：它不会上网查资料，给的信息要么过时，要么是瞎编的。
最简单的解法是：你帮它查，查完再告诉它。但这样一来，到底谁是牛马？
于是你把"上网搜索"这个动作写成了一段程序，让程序替你跑腿，自动完成搜索然后把结果喂给小 L。
🆕 词汇⑤ Agent（智能体）
⚠️ 别被这个名字唬住。早期很多所谓"智能体"，实现逻辑不过是多加了一段 Prompt 而已——换个名字就敢叫智能体，说是诈骗也不为过。
RAG：让 Agent 搜索本地文档
既然 Agent 能联网搜索，那搜索本地文档、数据库是不是也可以？当然，只不过要用向量数据库做语义匹配，把语义相近的内容片段找出来，再塞进 Context 里。
这套方法叫做：
🆕 词汇⑥ RAG（检索增强生成，Retrieval-Augmented Generation）
联网搜索只是 RAG 的一个变种，本质都是「获取模型参数之外的信息」。
👤 用户（你）
🤖 Agent 程序（传话筒）
🧠 LLM 小 L\n（只会说话的智者）
🔍 联网搜索
📄 本地文档 RAG
🛠 其他工具...
🔌 第四步：约定暗语，接入工具
Function Calling：Agent 和 LLM 的约定
Agent 和 LLM 之间通过自然语言沟通，有个问题：程序读不懂 LLM 随意输出的文字。于是双方需要约定一个格式（比如 JSON），让 LLM 按指定格式回复，这样 Agent 才能直接解析。
🆕 词汇⑦ Function Calling（函数调用协议）
就像前后端开发约定接口格式一样，没有任何神秘之处。
MCP：Agent 和工具服务的约定
如果把各种工具写成独立的服务，Agent 就需要一套标准来「发现」和「调用」这些服务——比如约定 tools/list 返回工具列表、tools/call 执行具体工具。
🆕 词汇⑧ MCP（模型上下文协议，Model Context Protocol）
| Function Calling | MCP | |
|---|---|---|
| 连接对象 | Agent ↔ LLM | Agent ↔ 工具服务 |
| 解决问题 | 让 LLM 按固定格式输出 | 标准化工具的发现与调用 |
| 类比 | 前后端接口约定 | 微服务调用规范 |
⚠️ 常见混淆： 有人问「MCP 能取代 Function Calling 吗？」这是无稽之谈——两者根本不在同一层，解决的也不是同一个问题。
自然语言
Function Calling\nJSON 格式约定
MCP\n工具调用协议
👤 用户
🤖 Agent
🧠 LLM
🛠 工具服务\n搜索 / 文件 / 数据库…
⚙️ 第五步：流程固化，各显神通
假设你有个稳定任务：英文 PDF → 翻译 → 保存为 Markdown。每次都让 Agent 自由发挥？不但结果不稳定，还白白浪费 Token。更好的做法是把流程固化。
四种方式，从刚性到柔性
📝 LangChain\n纯编程 / 硬编码\n最稳定
🖱 Workflow\n低代码拖拽\n门槛低一点
🎯 Skill\n脚本+说明文档\n半自动
🌀 纯 Agent\n完全自主\n最灵活但最难控
| 方式 | 特点 | 适合谁 |
|---|---|---|
| LangChain | 硬编码，极其稳定，几乎无容错 | 程序员 |
| Workflow | 低代码拖拽，改起来方便一点 | 半技术用户 |
| Skill | 说明文档 + 可调用脚本，兼顾稳定与弹性 | 普通用户 |
| 纯 Agent | 完全自主，随机应变，费 Token 难预测 | 对结果要求宽松时 |
Skill 是什么？
Skill 的核心就一个文件：SKILL.md，里面写清楚流程说明，并指向可调用的脚本目录。Agent 被要求在执行任务前先读这份说明，再按需调用脚本。
🆕 词汇⑨ Skill（智能体技能）
本质上，Skill 就是一个「把 Prompt 换个地方存」的加载器。
⚠️ 有人问「Skill 和 MCP 有什么区别？」答：完全不是一个维度的东西。Skill 是 Prompt 加载器，MCP 是工具调用协议，两者不存在谁取代谁的问题。
🪆 第六步：套娃——Sub-Agent
当任务足够复杂，单个 Agent 的上下文会变得极其庞大。于是你把相对独立的子任务拆出去，交给专门的子 Agent 处理。
🆕 词汇⑩ Sub-Agent（子智能体）
子 Agent 产生的上下文不会污染主 Agent，本质上就是上下文隔离，如此而已。
结果
结果
结果
🤖 主 Agent
Sub-Agent A\n子任务 1
Sub-Agent B\n子任务 2
Sub-Agent C\n子任务 3
📦 你一共发明了多少新词？
| # | 中文 | 英文 | 一句话概括 |
|---|---|---|---|
| ① | 大语言模型 | LLM | 参数足够大后涌现出智能的语言模型 |
| ② | 提示词 | Prompt | 你和 LLM 每次对话的完整输入 |
| ③ | 上下文 | Context | Prompt 中的背景信息部分 |
| ④ | 记忆 | Memory | 塞进 Context 的历史对话记录 |
| ⑤ | 智能体 | Agent | 代替你跑腿、调用工具的中间程序 |
| ⑥ | 检索增强生成 | RAG | 把外部检索到的信息塞进 Context |
| ⑦ | 函数调用协议 | Function Calling | Agent 和 LLM 之间的格式约定 |
| ⑧ | 模型上下文协议 | MCP | Agent 和工具服务之间的调用规范 |
| ⑨ | 智能体技能 | Skill | Prompt 加载器，兼顾灵活与可控 |
| ⑩ | 子智能体 | Sub-Agent | 隔离上下文的独立子任务处理器 |
🔭 通杀所有新概念的方法论
回到最本质的问题：为什么说「Agent 是由所有不需要智能的部分构成的」？
一个流程中，所有能用固定程序解决、不需要问 LLM 的地方，就是 Agent 发挥作用的地方。模糊的分流逻辑交给 LLM，确定的执行逻辑交给程序。
所有这些技术——Search、RAG、Skill……本质上都在做同一件事：
自动往 Prompt 里塞上下文，或者通过代理减少你和 LLM 直接沟通的次数。
看透这一点，任何新概念出来，你只需要问两个问题：
- 它是在帮 LLM 获取更多信息？（→ 属于 RAG / Search 这条线）
- 它是在替代某段固定的程序逻辑？（→ 属于 Agent / Workflow 这条线）
未来会怎样？
方便性永远胜出。 Token 会越来越便宜，配置门槛会越来越低。未来一定会有开箱即用的超级 Agent，把 MCP、Skill、Workflow 统统内置好，普通人啥都不用配置就能上手。
谁让用户觉得「它就是个会干活的 AI」，而不是「一堆需要折腾的配置」，谁就赢了。
下次再看到新名词，别慌，顺着这条故事线找它的位置，瞬间秒懂。
