解析各种AI概念

LLM、Prompt、Agent、RAG、Function Calling、MCP、LangChain、Workflow、Skill……这几个词儿你认识多少？这就是这几个词儿，你又真正认识多少？

如果你全都不认识，或者被这些漫天飞舞的新概念搞得头晕脑胀，那么恭喜你，来对地方了。今天这篇文章，我就为你扒开所有这些唬人概念的底裤。

你会发现：所谓智能体（Agent），其实就是所有“不需要智能的部分”构成的躯壳；这一切，不过是新瓶装旧酒的一场“名词诈骗”。

最后，我还会交给你一套“通杀”现在甚至未来所有AI新概念的统一方法论，让你瞬间秒懂。现在，请清空大脑，忘掉你所有知道和不知道的概念，跟我一起进入这场拆解之旅。

01 混乱的起点：一个只会“文字接龙”的智障

整个混乱的起点，就是古老的语言模型。

小的语言模型一开始还是个“智障”，但随着模型的参数越来越大，居然在某个临界点“涌现”出了智能。为了和之前那个智障模型做个区分，你在前面加了个“大”字，这就构成了现在常说的大语言模型（Large Language Model，简称 LLM）。

🎉 恭喜你，发明了今天的第一个新词。

大模型本身只能做一件事：文字接龙（不断预测并输出下一个字）。如果只是这么用，它看起来仍然像个智障。但如果人为划分出“一问一答”两个角色，就实现了它第一个有点智能的使用方式——对话。

现在，立刻把自己想象成一个老板。LLM就是你的员工，我们叫他小L。

他服务你的方式有点特别：只能一问一答，然后就结束了。不能追问，这个非常重要。

接下来的任务，就是你要想尽办法压榨这个只会一问一答的小L，榨干他的全部剩余价值。你会怎么做呢？

首先，你给自己每次对小L说的内容起了个洋气的名字，叫 Prompt（提示词）。
🎉 恭喜，第二个新词诞生。
然后你发现，给小L说的内容可以进一步拆分：一部分是背景信息，一部分是最终指示。
于是你把背景信息单独命名为 Context（上下文）。
🎉 第三个新词达成。
你需要对小L进行追问，但他只能一问一答怎么办？你灵机一动：每次沟通前，把你们之前的“对话历史”作为前情提要塞进Context里，伪装成多轮对话！你迫不及待地给这些特殊的上下文起了个新词叫 Memory（记忆）。如果记忆太长，还可以再找大模型总结压缩一下。
🎉 一不小心，第四个新词也有了。

此时，一个原本只会文字接龙的底层代码，成功被你玩出了“可以对话、可以追问”的优秀牛马员工拟人感。

02 给“牛马”配电脑：Agent与RAG的诞生

不久之后，你不满足了。你发现小L没有上网查资料的能力，遇到不懂的要么瞎编（幻觉），要么说些过时的消息。

给小L配台电脑行吗？不行，小L只会文字接龙，其他任何逻辑都无法独立完成。

那怎么办？你心生一计：你告诉小L，“如果你需要上网，你就用特定格式告诉我，我帮你查完再把结果喂给你。”

但很快你发现：这样显得自己有点蠢。到底谁才是牛马？！

于是，你写了一段程序代码，让这个程序去“代理”你和小L沟通，并且自动去完成搜索、抓取网页的任务。在外人看来，你仍然是一问一答就拿到了结果，只不过中间多了一个神秘的程序。

太妙了！这个发明可不得了。这个神秘的程序似乎拥有了操作工具的高级智能。你给它取了个极具科幻感的名字：智能体（Agent）。

💡 别有心理负担，早期很多所谓的Agent，底层逻辑仅仅就是多加了一段Prompt外加一个网络请求脚本而已。从现在的视角回看，简直就是一种诈骗。

既然Agent能上网搜索了，那搜索本地文档和数据库行不行？当然行。
只是搜索方式变了，需要用“向量数据库”把语义相近的片段找出来，然后塞进上下文里给大模型参考。你给这种“检索外部信息+增强生成结果”的办法，起了个贼拉风的名字：RAG（检索增强生成）。

顺便，你把联网搜索叫 Web Search（后来觉得格局小了，直接叫Search）。从广义上讲，RAG和Search都属于一类东西：获取模型参数以外的信息的能力。

给Ai打小抄的过程

🎉 看看，这么一会儿功夫，已经发明了八个新词了。

03 规矩与协议：Function Calling 与 MCP

好戏还在后头。

现在的架构是：你 <–> Agent程序 <–> 大模型（小L）。Agent是传话筒兼杂活总管。

这里有个致命问题：大模型怎么告诉Agent它想用工具？如果大模型用人类大白话提需求，Agent这种死板的程序代码根本解析不了。

所以，必须定个规矩：让大模型按照死板的格式（比如 JSON）来回复。你给这种“约定好的工具调用对话格式”，叫做 Function Calling（函数调用）。
说白了，这就跟前端和后端约定接口格式一模一样。

再看另一边，各种工具（比如计算器、查天气、查日历）如果单独写成独立的服务，Agent主程序怎么发现并调用它们？每个程序员写工具的习惯不一样，又该怎么对接？

为了解决混乱，必须制定一套规范。比如约定用 tools_list 获取列表，用 task_call 调用具体工具。你给这套“Agent和工具服务之间的万能插座标准”，起了个名字叫 MCP（模型上下文协议）。

给ai赋能，加上各种MCP工具

至此，终极架构成型了：

大模型 = 只会说话不会干活的智者
MCP服务 = 提供各种干活工具的工具箱
Agent = 传话筒（把大模型的话转成调用MCP的代码，再把工具的返回结果传回给大模型）

Agent主打一个：“我不生产信息，我只是信息的搬运工”。

04 效率至上：从 LangChain 到 Skill 的演进

不管你的Agent长什么样（命令行、IDE插件、还是最近爆火的各种桌面AI助手），只要给它配上了各种工具，马上就会暴露一个统一的缺点：太自由，反而不稳定，且浪费Token。

假设任务是：读取英文PDF -> 提取内容 -> 翻译成中文 -> 保存为Markdown。
如果你一股脑把所有能力都丢给Agent（纯MCP狂热派），它可能每次想的步骤都不一样，甚至在中间迷失方向。

为了解决这个问题，技术圈分化出了“给AI提供工具的五大门派”：

直接编程派（LangChain）：干脆剥夺AI的自由。在代码里写死什么时候运行程序，什么时候请求大模型。虽然死板，但绝对稳定。
低代码派（Workflow/工作流）：为了照顾不懂代码的普通人，把复杂的流程做成了页面连线拖拽。像 Coze 一样，本质上依然是固定的流水线。
全量提供派（Agent+MCP）：像小智AI等产品，把MCP接好的所有工具全告诉AI，让AI自己看着办。极其自由，但也极容易耗尽上下文（Token）。
按需加载派（Agent+Skill）：为了解决上下文爆满，你写一堆脚本放进文件夹并贴上说明书。遇到特定任务时，只把对应的那一类工具告诉AI。完美兼顾了自由度与成本。
外包分工派（SubAgent/子智能体）：如果任务实在太复杂，即便按需加载工具，主Agent的上下文还是会被各种冗长的中间步骤塞满，Token疯狂燃烧。于是你一拍大腿：搞几个隔离的、甚至是用更便宜模型运行的“小弟”，把细碎的脏活累活外包给它们，主Agent只当包工头负责分派任务和听汇报。这些干脏活的小弟，就叫 SubAgent（子智能体）。

现在我们来回顾一下之前的概念：


LLM 大语言模型	Function Calling AI输出代码调用程序
Prompt 提示词	MCP 模型上下文协议
Context 上下文	Langchain 程序中调用AI
Memory 记忆	workflow 工作流，拖拽编程
Agent 智能体	SKILL 技能，给ai一套代码，按需加载
RAG 检索增强生成	SubAgent 子智能体，新开一个上下文干脏活
Search 搜索	Claude CodeX Cursor Trae OpenClaw Manus 都是各种Agent程序

05 统一方法论：撕开包装看本质

新概念出来时，满天都是极其夸张的营销吹捧。但在我看来，它们不仅不神秘，甚至有些“拉垮”，全都是技术发展过程中的“中间产物”。

让我们把下面这些概念再次理清：

理清概念：

Function Calling vs MCP：前者是“大模型和Agent程序”的沟通约定，后者是“Agent程序和外部工具箱”的调用接口。
Skill vs MCP：两个不是一个层次。Skill是解决Token浪费的应用层方案（向一本字典，每次给ai看目录，ai根据目录按需加载一类工具），而MCP是直接让ai调用的一个程序。常用的工具未来一定都会内化到Agent主程序里，MCP对普通用户来说会变得完全透明。
Skill vs SubAgent：两者都是为了省Token。Skill 是从“工具箱”层面做减法（只给用得上的工具）；SubAgent 是从“脑容量”层面做隔离（另起一个干净的上下文环境去跑繁琐任务，不污染主Agent的记忆）。

理清约束等级：
回顾上面讲过的门派，为了完成多步骤任务，技术演进其实就是在刚性到柔性上找平衡点：