2025 开发者 AI 扫盲:从 LLM 到 Agent
0X00 Intro
现在是 2025 年末,所有人都在聊 AI,不管是一线科研人员还是开发者甚至是楼下卖瓜的大叔。但是在我的观察中,即便是很多开发者也其实对 AI 的了解也比较肤浅,仅限于使用成品的豆包、Deepseek 等产品,对时下热门的技术关键词并不了解。所以我自己重新整理了一下,假设目标用户是不懂什么是 LLM、Agent、MCP、Function Call 的我自己,写了一篇介绍文章。远远算不上由浅入深,但勉强可以做一个纯粹的介绍。
0X01 LLM
首先 LLM 的意思是大语言模型(Large Language Model),重点是语言和模型。所以我们搞清楚一个问题就是很多玩家自己部署的 Stable Diffusion 并非 LLM,因为它并不是语言模型。另外我们常用的 Deepseek 和豆包 App 也并非 LLM,因为它们并非语言模型。
最常被人们接触到的其实都不是模型,而是在模型上构建的产品,例如:ChatGPT 和豆包。模型指的是给这些产品提供 AI 能力的诸如 GPT-5.2、Claude Sonnet 4.5、GLM 4.7 等。以 OpenAI 为例,我们在使用 ChatGPT 的 App 时能调整的参数极其有限,但是如果通过 API 来直接调用模型能力,那可以修改的参数会多达几十上百个,并且可以区分 System Prompts 和 User Prompts。
总的来说 LLM 是本次 AI 浪潮中最重要也是最基石的存在。
0X02 Function Call
Function Call 的概念其实非常直观,本质上就是一个函数调用接口。我们在写代码时定义的函数通常是给程序内部逻辑调用的,而 Function Call 允许我们将这些函数注册给 LLM,让模型根据对话上下文自主决定是否触发某个函数以及传什么参数。
不过在早期的工程实践中,虽然各家模型都支持 Function Call,但痛点非常明显:定义格式不统一。比如 OpenAI 用的是特定的 JSON Schema,其他模型可能又有各自的规范。这就导致你想写一个通用的“查天气工具”,需要针对每个模型单独适配一套接口,开发成本高,工具难以在不同模型间复用。
0X03 MCP
MCP (Model Context Protocol) 的出现就是为了终结这种“方言”乱象。它是由 Anthropic(开发 Claude 系列模型的公司) 提出的一个开放标准协议,统一规定了 AI 应用与外部数据源、工具之间如何交互。
只要模型端和工具端都遵循 MCP 协议,它们就能无缝对接。简单类比,以前各家是各自搞一套私有 RPC 协议,现在 MCP 就像是 AI 界的 HTTP 或者 RESTful API 标准一样。它解决了连接器的标准化问题,让一个工具可以轻松地在不同的 AI 客户端(如 Claude Desktop、IDE 插件)中即插即用。
0X04 Agent
Agent 就是现在比较流行的智能体,它的本质是一个程序。我自己听过的说法包括但不限于:
- “Agent 和大模型不一样,Agent 能直接操作你的电脑”
- “Agent 比大模型厉害多了,肯定是大语言模型的替代品”
- “Agent 就是个骗人的噱头,没什么用,泡沫迟早要爆炸”
其实都不太对劲,因为 Agent 是一个至少集成了 LLM 和 MCP/Function Call 的集合体程序。如果逐一反驳的话,Agent 确实和大模型不一样毕竟你不能说汽车和发动机一样,但 Agent 能否操作电脑也是看它具体集成了哪些 MCP/Function Call;其次 Agent 比大模型厉害就更是无稽之谈了,因为 LLM 是 Agent 的一部分,总不能说汽车比发动机强吧;说 Agent 是骗人的噱头的其实也不至于,Agent 只是 LLM 发展的一个方向而已。
最近我正在使用的 Claude Code 其实就是一个 Agent,给没有用过的朋友简单介绍一下 Claude Code 的使用流程
在目录中打开 Claude Code(是一个 CLI 工具),发送:“检查这个代码仓库,并向我介绍它”。 此时 Claude Code 会理解我的意图,然后调用系统的 find、cat、tree 等命令尽可能的获取这个项目的信息,比如目录结构、入口位置甚至是 README.md。在它获取到信息之后会继续传输给 LLM,让 LLM 来理解并输出内容。如果我继续下发指令:“为这个项目新增一个 XX 功能”,那 Claude Code 会继续先把我的内容发送给 LLM 然后列出一个 TODO List,再根据 todo 的内容一项一项执行,中间就会涉及到创建编辑文件、执行测试代码、甚至是安装依赖的三方库等。





