从 LLM 到 Agent 扫盲，大白话串联全套大模型技术栈
刚接触 AI 那阵子，我的状态跟你现在可能差不多：LLM、Prompt、RAG、Agent、Function Calling、MCP…… 一堆名词砸过来，每个都好像很重要，单独看又不知道它们之间到底有什么关系。
看着别人用 AI 写代码、做软件、自动处理任务，都已经赚到第一桶金了，搞得我心里痒痒的，后来我花了半个月时间，把整个大模型技术栈从头到尾捋了一遍，终于搞明白了从只会进行 "概率性文字接龙" 的AI模型，究竟是如何一步步进化，最终成为一个能自主检索、调用工具、规划并执行复杂流程的"智能体"的。
所以今天我将回归工程师最朴素的思维方式单，就从 需求驱动 的视角，看看 AI 是怎么一步步从"人工智障"进化成能自己干活儿的智能体的。
早期的尝试：人工智"能"
最开始的 AI 很简单，都是程序员 if-else 手写规则，比如 "用户说退款 → 回复请提供订单号"，确实能跑，但你能写 100 条规则，写不了 10 万条。用户换个说法"我想把钱拿回来"，程序直接傻眼了，这条路很快就到头了。
后来换了个思路：别写规则了，让机器自己从数据里学。
比如认猫。你给机器看一万张猫照片，每张告诉它"有猫"或"没猫"，这就需要机器自己慢慢摸出规律：尖耳朵、圆脸盘、胡须，当下次见到新图片，能判断"90% 概率是猫"。这个过程就像你拿着一个放大镜在图片上滑动，每次只看放大镜里那一小块部分，像耳朵的边缘、脸部的纹理、毛发的颜色等等，然后把这些局部发现一层层拼起来，从细节到整体，逐步看懂整张图，这的过程就是 卷积神经网络（CNNs） 的技术。
现在程序学会了认图，接下来就该学习学习认字了。
当你读一句话："我今天很生气，因为老板又画大饼"，你瞬间就知道"生气"和"画大饼"虽然是句子的两头，但意思连着，如果还用 CNN 的话是不行的，它只能看局部，看不见这么远的关系。
于是有了另一种做法：读一个词，脑子记一笔，带着记忆读下一个。就像玩传话游戏，第一个人小声告诉第二个人，第二个人转告第三个，一路传下去。机器每读一个词就更新一次内部记忆，这个记忆装着前面读过的所有内容，这就是 循环神经网络（RNNs） 的处理过程。
其实传话游戏还有一个非常明显的毛病：传着传着就变味了，传到最后一个人的时候，开头说了什么早忘了。RNN 也一样的，总结来说就是 记性短、算得慢，只要句子一长就崩，而且必须一个词一个词排队处理，GPU 几千个核心干等着帮不上忙。
这个阶段的 AI 算是原汁原味的"人工智障"，简单的事能做，稍微复杂就露馅，能用，但不好用。
初识 AI 的大脑：LLM（大语言模型）
自从2022年11月，OpenAI 发布了对话式 AI 模型 ChatGPT，很多人第一次用它时，都会觉得 "这AI太聪明了，它是不是真的理解我在说什么？" 自此也正式的从互联网时代进入了 AI 时代。
相信很多人看到过下面的图片，但应该不知道它的出处：
这其实来自于中国人民大学高瓴人工智能学院（RUCAIBox）《A Survey of Large Language Models》一文，写的关于大语言模型的调研论文 论文仓库，有大概50页，介绍了大语言模型的背景、关键发现和主流技术，回顾了LLMs的最新进展，感兴趣可以下载阅读一下 中文版下载
回归主题，现在的 LLM（大语言模型）这个词现在谁都能聊两句，但你要让我用一句话解释它到底是什么，那我就会告诉你：
LLM 本质上就是个超级复杂的 "文字接龙" 程序，它是一个概率模型，工作方式是：你输入一串文本，它预测下一个最可能出现的 Token，然后把预测出的 Token 接到输入后面，继续预测再下一个，如此反复，直到输出一个结束符。
这种"逐个预测、循环生成"的方式叫 自回归（Autoregressive）。它不像人类那样"想好了再说"，而是在输出第一个字的时候，对后面要说什么只有模糊的概率倾向。
整套文字预测、语义计算，底层完全是基于 Transformer 架构运行，那 Transformer 到底是如何""预测下一个词语"的？
大模型如何实现 "预测下一个词语" 的？
想象一下，你给一个程序喂了整个互联网的文本数据 —— 书籍、网页、代码、对话，这个程序本身并不会像人类一样 "阅读" 并 "理解" 其中的含义。 这个就像做了海量样本训练，通过 if 语句让程序记住文字和文字之间的搭配规律、语序逻辑、语义关联，你尝试问了一个问题，程序能精确的回答上来，看似是有了智能一样。
实际上大模型所做的是通过 Transformer 的神经网络架构，在海量数据中统计文字序列之间的共现规律。
Transformer 登场：一切都变了
2017 年，Google 发了一篇论文《Attention Is All You Need》论文阅读，标题翻译过来就是：注意力就是一切，有兴趣可以阅读一下。
这篇论文提出了 Transformer 架构，它的核心是 自注意力机制，直接改变了整个 AI 行业的走向，我们今天所有的主流大模型，底层跑的全是 Transformer。
你可以把它理解成一套多层级、多节点的巨型神经网络，每一段输入的文字，都会先转换成数字向量（文本数字化），再依次经过网络里的各个节点做加权计算。整个过程就是不断分析：在当前这段前文之后，历史数据里出现频率最高、语义最通顺的下一个词是什么。
自注意力机制与多头注意力
自注意力本质上就是让每个词都跟句子里其他所有词"握个手"，动态地计算这个词与句中所有其他词（包括它自己）的关联权重，从而捕获长距离的语法和语义的关系，然后按亲疏程度把其他词的信息融合进来。
Transformer 不是只做一次自注意力，而是同时做很多次，这就是"多头"的意思。不同的"头"关注不同的关系：有的头关注语法结构（谁是主语谁是谓语），有的头关注语义关联（哪些词意思相近），有的头关注位置关系（前后文的因果逻辑），最后把所有头的结果拼在一起，信息就非常丰富了。正是这种机制，让模型能够生成语法正确、逻辑连贯的文本，尽管它并不真正理解这些文本。
从 Transformer 到大模型：参数的力量
Transformer 是个架构，它规定了"数据怎么流转、怎么计算"。但光有架构不够，你得往里面填入具体的内容，这就是 参数。
参数是训练出来的，而训练过程不复杂，就像刚才说的：把互联网上能扒到的文本全喂进去（维基百科、GitHub 代码、书籍、论文、论坛帖子……），然后让模型做一个极其简单的任务 —— 预测下一个词。
比如输入"哪只股票今天会"，模型输出"涨"——猜对了，奖励；猜错了，惩罚。通过反向传播，把奖惩信号一层一层传回网络的每个参数，做微小的数值调整。这个过程重复几万亿次，参数就从一开始的随机数，逐渐收敛到"能捕捉语言规律"的数值。
我们常听到 "GPT-4 有 1.8 万亿参数"、"Llama3 有 700 亿参数"，就是说的大模型的参数规模。这些参数不是"存了文字"，而是存了语言中各种模式的统计规律。什么时候该用"的地得"，什么句式是疑问句，代码里 if 后面大概率跟什么，全是这些参数在管。
打个比方：你写 Java 写多了，不需要查文档就知道 @RestController 后面大概率跟 @RequestMapping 或 @GetMapping。模型也一样，只不过它不是在记语法规则，而是用几千亿参数捕捉了远比"注解后面跟什么"复杂得多的规律。
这就是 预测 的核心逻辑，整个预测并不是靠 "理解语义"，而是靠 海量数据总结规律 + 多层网络加权运算 实现的。
常说的基座大模型
日常 AI 开发中需要进行模型部署，就是采用训练好的 基座大模型，本质就是这套 「基于 Transformer 架构、拥有完整规则化参数集」 的基础模型。
参数多了，突然就"开窍"了 涌现
有一个现象到现在也没完全解释清楚：当参数规模突破某个临界点（大概百亿到千亿级别），模型会突然表现出一些训练时没有明确教过的能力。
比如逻辑推理：你训练它的时候只是让它"预测下一个词"，从来没教过它三段论推理。但参数多了之后，你问"所有猫都怕水，Tom 是一只猫，Tom 怕水吗？"，这个时候它能推论出"怕水"。
再比如代码生成：训练数据里有代码不假，但模型能根据自然语言描述写出功能完整的函数，甚至能跨文件理解项目结构，这已经超出了简单的"模式匹配"。
这就是涌现（Emergence）。
为什么会这样？目前没有标准答案。一个比较主流猜测是：语言本身就是思维的压缩载体。人类几千年的知识、逻辑、推理过程，都沉淀在了文字里。当参数多到足以编码这些隐含的因果关系和逻辑链条时，推理行为就自然出现了。
用通俗的话说：少量参数只能记住字词搭配，相当于只会"组词造句"；参数规模上去之后，原本独立的字词、短句、知识点开始互相串联，量变引起质变。
涌现不是什么玄学，它是复杂系统的自然现象。参数少的时候，模型只能学到"局部规律"（字词搭配）；参数多了，不同规律之间开始交叉联动，形成了"全局模式"（逻辑推理、代码生成）。选模型就是在能力和成本之间做权衡，模型越大，能力越强，但成本也越高。
学会跟模型"好好说话" Prompt 提示词
现在我们知道 LLM 是个"文字接龙"高手了，但怎么让它接出我们想要的文字，快速识别我们的意图呢？这就是 Prompt Engineering 提示词工程要解决的问题。
Prompt 提示词：跟 AI 的"交流"
我们可以把提示词理解为给 AI 写的 "接口文档"，主要是为了更好地下达指令让计算机识别而已，它决定了大模型输出的质量和方向。很多人把提示词工程想得太玄乎，其实它的本质就是：通过文本引导，让 AI 理解你的意图。
提示词主要分为 2 种类型：
User Prompt（用户提示词）：用户的具体请求。示例："用 Java 写一个单例模式的线程安全实现，包含懒汉式和饿汉式。"System Prompt（系统提示词）：定义模型的 "人设" 和 "规则"。示例："你是一位资深 Java 架构师，回答需附带代码示例、性能分析和最佳实践。"
提示词技巧：如何让 AI 更"听话"
给 AI 的指令越清晰、结构越规范，它就越容易理解你的意图，给出你想要的输出。下面是几种常用的提示词技巧，由浅入深：
零样本提示（Zero-shot）
直接给出指令，不给任何示例，完全靠模型自身能力理解意图。这就像你跟同事说"写个排序算法"，对方靠经验就知道你要什么。
示例："用 Java 实现快速排序，要求原地排序。"
简单任务用零样本就够了，但遇到复杂需求或特定格式要求时，模型容易"跑偏"。
少量样本提示（Few-shot）
在 Prompt 中加入少量示例，让模型通过"举一反三"理解你期望的输出格式和逻辑。这就像我们写单元测试时，先写几个测试用例，告诉程序"输入 A 应该输出 B，输入 C 应该输出 D"，AI 看到示例，就明白了你的期望格式。
示例：
输入：[1,3,2] → 输出：[1,2,3]
输入：[5,1,4] → 输出：[1,4,5]
输入：[3,2,1] → 输出：？模型看到前面两组示例，就知道你要做升序排序，自然输出 [1,2,3]。Few-shot 的关键在于：示例要覆盖典型场景，且格式与真实输入保持一致。
思维链提示（Chain of Thought, CoT）
对于需要多步推理的复杂任务（数学计算、逻辑分析），直接问模型要答案，它很容易"拍脑袋"给个错误结果。思维链的做法是：引导模型把推理过程一步步写出来，而不是只给最终答案。
零样本思维链只需在指令末尾加一句："让我们一步一步地思考。"
普通提示：
问：一个商店有 23 个苹果，卖了 17 个，又进了 10 个，现在有几个？
答：16 个。
思维链提示：
问：一个商店有 23 个苹果，卖了 17 个，又进了 10 个，现在有几个？让我们一步一步地思考。
答：初始有 23 个苹果。卖了 17 个后，剩下 23 - 17 = 6 个。又进了 10 个，所以 6 + 10 = 16 个。现在有 16 个苹果。模型在"展示推理过程"时，每一步的中间结果会作为后续推理的上下文，大幅降低跳步导致的错误率。这就像我们要求初级开发在写代码前先写设计文档，逼他把逻辑想清楚再动手。
思维树提示（Tree of Thoughts, ToT）
思维链是"一条路走到底"，思维树则更进一步：让模型在每一步推理时生成多个候选方案，像树形结构一样展开探索，再对每条分支做评估，剪掉走不通的路，最终选出最优路径。
这就像我们做技术方案评审时，不只准备一个方案，而是列出方案 A、方案 B、方案 C，分别评估优缺点，再选最优的落地。思维树特别适合需要"探索 + 回溯"的复杂任务，如数学证明、游戏策略、复杂代码设计。
角色设定（Role Playing）
在 System Prompt 里给 AI 定义一个明确的角色，让它在回答时"代入"这个角色的专业视角和语气。
示例："你是一位有 10 年经验的 Java 架构师，擅长高并发、高可用系统设计，回答时请附带代码示例、性能分析和最佳实践。"
角色设定本质上是在"收窄"模型的输出空间，让它从一个"什么都懂一点的通才"变成"某个领域的专家"，回答更聚焦、更专业。
技巧不是互斥的，而是可组合的
以上技巧可以叠加使用。比如：角色设定 + 少量样本 + 思维链，先让 AI 扮演资深架构师，再给几个代码评审的示例，最后要求它"一步一步分析代码中的问题"。组合得越好，输出质量越高。
这就像我们写接口文档时，既定义了接口规范（角色），又给了示例请求（Few-shot），还要求详细设计说明（思维链），三者配合才能拿到最好的结果。
Token：AI 眼中的"文字"
我们人类看文字，看到的是 "今天股票会大涨"，AI 看同样的文字，看到的却是一串数字。这个转换的第一步，就是 Token。
Token 是大模型处理文本的最小单元，不是单词，也不是汉字，而是模型自己学会的一种 文本切分规则，经过特定分词器 Tokenizer 切分后的最小文本单位。
比如：
- 中文短语 "程序员"，在大模型的 Token 切分中可能被拆为 "程序" + "员" 两个 Token；
- 英文单词 "helpful"，可能被拆为 "help" + "ful" 两个 Token；
- 特殊符号 "😊"，甚至可能需要 3 个 Token 才能表示。
每个模型切分的规则不同，结果也不同，具体要看模型的实现。
理解 Token 的实际意义在于：大模型按 Token 计费、按 Token 限制上下文长度。你发给模型的 Prompt 越长，消耗的 Token 越多，费用越高，同时也会挤压上下文窗口中能放下的历史对话内容。
向量：AI 理解世界的数学语言
Token 只是把文字切成了小块，但计算机还是没法"计算"这些小块。所以在 Token 切分后，每个 Token 会被转换成一个向量，本质就是一组固定长度的数字数组。
例如：今天 → 转为 [0.21, 0.78, -0.33, 0.91 ...] 这一串数字，就是该文本对应的向量。
为什么需要向量呢，直接文字不行吗？ 这其实是因为计算机只能处理数字，要让 AI "理解"文字，必须先把文字转换成它能计算的数学形式。而向量的妙处在于：语义相近的词，其向量在空间中的距离也相近。
比如 "猫" 和 "狗" 的向量距离很近（都是动物），"猫" 和 "汽车" 的向量距离很远。正是因为这种"语义空间"的存在，模型才能做语义匹配、相似度计算，这也是后面 RAG（检索增强生成）能"语义检索"的底层基础。
从文字到 AI "理解"的完整链路是：文本 → Token 切分 → 向量化 → 多层网络加权计算 → 输出预测。这条链路，就是 AI 感知世界的全部基础。
微调：让通才变专才 Fine-tuning
基座大模型是个通才，什么都知道一点，但你要让它在你特定领域里特别厉害，比如医疗问诊、法律咨询、代码审查，这些光靠 Prompt 引导有时候是不够的，这就需要 微调（Fine-tuning）。
微调说白了就是：拿一个已经训练好的基座模型，用你自己的领域数据再训它一遍。就像招了一个名校毕业生，通用底子不错，但来了公司还得做岗前培训，让他熟悉你们的业务规范和术语。
打个比方，基座模型就像一个刚毕业的 Java 通才，会写 CRUD、懂基础框架，但你让他做金融级的高频交易系统，他两眼一抹黑。微调就是给他补课：喂大量交易系统相关的文档、代码、业务规则进去，让他在这个方向上"加练"，之后遇到相关问题就特别准。
微调的方式有很多种，常见的有：
- 全量微调：把模型所有参数都重新训一遍。效果最好，但成本极高，需要大量算力和数据，一般企业玩不起。
- LoRA（低秩适配）：不碰基座参数，只在旁边加一小撮可训练参数。就像你不让动核心代码，只允许在上面写插件来适配业务。训练成本低、效果接近全量微调，是目前主流选择。
那微调和后面要讲的 RAG 是什么关系？很多人搞混，说简单点：
- RAG 是"考试带小抄"，模型本身没变，你临时把资料塞给它；
- 微调 是"考前复习"，把知识烙进模型参数里，变成它自己的"肌肉记忆"。
两者不是非此即彼，很多场景配合着用：微调让模型具备领域风格和专业表达，RAG 负责补充实时变化的具体数据。
什么时候该上微调？
别上来就微调，按这个顺序试：
- 先调提示词：换角色设定、加 Few-shot 示例、用思维链引导推理，很多时候 Prompt 调好了问题就解决了，成本几乎为零；
- 再加工具和 Skill：模型不会算数就给它接计算器，不会查数据就给它接 API，能力不够工具来凑；
- 然后上 RAG：模型不知道你公司的私有知识，把文档塞进知识库让它现查现答，改个文档就生效；
- 再试试换模型：当前用的 7B 小模型扛不住，先试试 70B 或者换个更强的基座模型，可能直接解决问题，比微调便宜得多；
- 最后才考虑微调：前面全试过了还是不行，比如医疗诊断、法律推理这类需要模型"骨子里"就懂的东西，才值得花钱去微调。
一句话：能用提示词解决就别上 RAG，能用 RAG 解决就别上微调。微调是重武器，别拿它当锤子使。
模型虽强，但硬伤不少
现在我们有了一个强大的基座模型，它能聊天、能写代码、能翻译、能写诗，但一旦你想把它接到真实业务系统里，有些问题马上暴露出来：
- 失忆问题：模型本身没有记忆，每次 API 调用都是独立的，上次对话的数据早没了；
- 知识断网：训练完成之后直接断网，知识库永久固定，无法获取任何实时信息、无法读取本地私有数据；
- 无法动手：大模型只会"文字接龙"，不会自己调用 API、操作数据库，无法与业务系统协作。
这三大硬伤，恰恰就是大模型从"聊天玩具"走向"生产工具"必须翻过的三座大山。好在，每一座山都有对应的解法。
硬伤一：AI 失忆问题 Memory 会话记忆
了解了 LLM 预测的实现原理以后，就会发现它毕竟不是真正大脑，它本身是没有记忆的。就像我们写 Java 代码，每一次 API 调用都是独立的，模型内部不保留上次对话的任何信息，就像你每次调一个 Controller 的 REST 接口，上次请求的数据早没了。
既然 LLM 天生失忆，那 ChatGPT 怎么记住对话的呢？其实解决方案很简单，每次将所有对话都告诉大模型不就得了，这样大模型就拥有了"记忆"：
第一轮：User: "北京今天天气怎么样？" → AI: "晴天，25度"
第二轮：User: "上海呢？"
→ 后端实际发给模型的：User: "北京今天天气怎么样？" + AI: "晴天，25度" + User: "上海呢？"模型看到完整的上下文，就知道"上海呢"是在问天气，不是问人口，这样 AI 就"以为"自己记得之前的对话了。
你以为这样就万事大吉了吗？no，no，no，实际上当对话长了之后 Token 消耗会爆炸级增长，所以要做截断：保留最近 N 轮原始内容，更早的对话用摘要模型压缩成一段简述。长期记忆就是 用户画像，"用户说过不吃香菜"、"默认地址是北京市朝阳区"，这些存数据库里，每次对话前查出来注入上下文。
硬伤二：大模型断网，知识库永久固定 Search / RAG
模型的训练数据有截止日期，2023 年训练完的模型，不知道 2024 年发生了什么，你问它"最新版 Java 有哪些新特性"，它能一本正经编一堆不存在的特性，不是它坏，是它真的不知道，那怎么办呢？
其实这简单啊，我们不是有百度、有谷歌嘛，让后端程序自动去搜索，把实时结果塞进 Prompt 上下文，再让大模型基于最新搜索结果整理答案回复用户，这就是 Search 全网搜索。
整个逻辑就跟 Java 后端调用第三方搜索接口一样：
用户发起实时问题→后端调用搜索接口抓取网页数据→搜索结果拼进 Prompt→LLM 基于这些材料生成回答，大模型本身没有任何升级，只是后端多了一层搜索工具，帮 AI 补齐实时外网信息。
这只解决了公网实时数据的问题，如果换成企业内部的私有数据呢？ 公司有上万份接口文档、业务手册、运维台账，这些数据不能上传公网，大模型也早就训练完了，不可能为了你的公司重新训一遍。要怎么办？
这就轮到 RAG（检索增强生成） 登场了，它的思路跟 Search 一模一样，只不过不是搜公网，而是搜你自己手里的文档。每次提问时，先去知识库里搜出相关内容，塞进 Prompt，再让模型基于这些内容回答。模型本身不变，只是在每次输入前多了一道"翻资料"的工序。
要不说怎么叫做 ”检索增强生成“，你细品？
但搜文档有个难点：用户问"加班费怎么算"，你文档里写的是"超时工作酬劳的计算标准如下"，关键词完全对不上，这个时候就需要 Embedding，去把文字转成向量，语义相近的句子，向量在数学空间里距离很近：
"Java 面向对象编程" → [0.12, -0.34, 0.78, ...]
"Java OOP 概念" → [0.13, -0.32, 0.76, ...] ← 向量距离近
"Spring Boot 启动流程" → [-0.56, 0.23, -0.11, ...] ← 向量距离远用一个专门的 Embedding 模型，把用户问题和知识库里的文档都转成向量，然后算余弦相似度，找距离最近的那几个文档片段，拼起来塞给 LLM，完整流程分两条线：
离线：把所有文档解析成纯文本 → 按段落切成 Chunk（通常 300-500 Token 一块，相邻块之间留 10%-20% 重叠）→ 每个 Chunk 用 Embedding 模型转成向量 → 向量 + 原始文本一起存入向量数据库（Qdrant、Milvus、Pgvector 都行）。
在线：用户提问 → 把问题向量化 → 拿向量去向量数据库做相似度搜索 → 取最相似的 K 个 Chunk → 把这些 Chunk 的原文拼进 Prompt → 连同用户问题一起发给 LLM → LLM 基于这些材料生成回答。
Embedding 模型 ≠ LLM
Embedding 模型是一个独立的模型，它只管把文字转成向量，不会生成文本，不参与对话。跟 LLM 是两套完全不同的东西，就像 JDBC 驱动和你的业务代码是两回事。
硬伤三：不会用工具，无法与业务系统协作 Function Calling / MCP
现在的模型只能对话，你说"帮我把订单 12345 的状态改成已发货"，它只能回复"您可以在系统中手动修改"，没法真去调你的后端接口。
而这个时候，我们就需要去给 AI 装上手脚 —— Tool 就是为模型补上的 "延伸手臂"，本质是可被大模型触发的函数。
- 信息查询工具：查询天气（→ 调用天气 API）、查股票（→ 调用财经 API）；
- 数据操作工具：查询数据库（→ 执行 SQL）、修改数据（→ 执行更新操作）；
- 逻辑计算工具：数学计算（→ 调用计算器函数）、语法检查（→ 调用检查工具）。
开发的关键是工具的输入参数和输出结果需严格定义格式，让大模型能清晰理解如何调用。
但光有工具还不够，还得让大模型能"读懂"用户意图、自动发出调用指令，这就需要 Function Calling。
你需要提前定义好工具的元信息：工具名称、用途描述、参数 schema，跟着 Prompt 一起发给模型，模型如果判断需要调工具，不输出正常文本，而是输出一段结构化的 JSON：
{"tool": "get_orders", "params": {"userId": "12345", "limit": 10}}你的代码收到这个 JSON，去实际执行——调 DAO 查数据库、调第三方 API、发邮件，然后把结果拼回上下文，模型再根据结果生成最终回复。
但 Function Calling 有个问题：每接一个新工具，都要单独写一套适配代码，跨语言或者团队共享时很难复用，这个时候就轮到 MCP（Model Context Protocol） 登场了。
它定义了一套 Client-Server 交互模式：所有工具遵循 MCP 协议开发一个 MCP Server，AI 应用通过 MCP Client 直接发现和调用。关键在于 MCP 不只是传输协议，它定义了"工具发现"的语义——Client 连上 Server 后 listTools() 就能拿到所有工具定义，不需要手写元信息。Server 端升级新增工具，Client 端不用改一行代码。
Function Calling 和 MCP 是两个不同层面的问题
- Function Calling：是 LLM 和 Agent 之间的约定（"你要调哪个工具，传什么参数"），通常是 JSON 格式，就像前后端接口约定。
- MCP：是 Agent 和工具之间的连接标准（"所有工具按统一接口接入"），解决的是工具耦合问题，让工具可插拔、可扩展、可共享。
一个是说话的方式，一个是插头的规格。两者不冲突，配合使用。
从"能力扩展"到"自主干活"：Agent 智能体
上面三座大山翻过了，我们手里已经有了：补记忆的 Memory、补数据的 Search/RAG、补工具的 Function Calling 和 MCP。但这些能力散着放还是一堆零件，需要一个"总调度"把它们串起来 —— 这就是 Agent 智能体。
Agent 的本质，就是把工具调度的决策权从你的代码手里交到模型手里。不是你安排"第一步调 A，第二步调 B"，而是你把一堆工具和目标任务丢给模型，模型自己判断每一步该干什么。
核心运行机制叫 ReAct（Reasoning + Acting）：
Thought（思考）：当前状态是什么，下一步该做什么？
Action（行动）：调用哪个工具，传什么参数？
Observation（观察）：工具返回了什么？
→ 回到 Thought，根据结果决定继续还是结束举个例子，你跟 Agent 说"帮我生成上周的销售报告，发邮件给张总"：先调销售数据接口 → 拿到原始数据 → 发现需要做环比分析 → 调用计算工具 → 拿到分析结果 → 格式化邮件内容 → 发邮件 → 结束。全程你只给了一个目标，中间所有步骤都是 Agent 自己规划的。
Agent Loop：让 Agent 学会反思
Agent 跑着跑着容易走偏，不是模型笨，是谁连续做十步推理中间没有检查点也会偏。
Agent Loop 就是在 ReAct 循环里插入"停下来反思"的环节。不是每一步都反思，而是在关键节点或结果异常时触发自检：当前结果合理吗？有没有方向性错误？要不要调整计划？
自检不是魔法，就是多调一次 LLM，把已完成步骤和结果摘要放进 Prompt，让模型判断继续还是换策略。一轮反思花不了多少 Token，但能显著降低"一条道走到黑"的概率。
但 Agent 有三个绕不开的问题：
- 不稳定：同样的输入可能走不同的执行路径，因为每步决策都是概率性的。
- 错误传播：第三步错了，第四步基于错误结果继续，到最后可能全歪。
- 成本不可控：每一步都是一次 LLM 请求，Token 消耗是单次问答的十几倍。
生产环境不要放养 Agent
至少要做三件事：设最大步数上限防止死循环烧钱、关键步骤加人工确认节点、高风险操作必须配沙箱 + 审批流。Agent 的自主性是双刃剑，用好了省心，用不好就是个自动烧钱机。
流程编排：为 Agent 装上"企业级大脑"
Agent 虽然能自主干活，但纯自由发挥容易出问题，像逻辑错乱、重复调用、浪费 Token等等，这就像写 Java 后端，所有业务逻辑都塞在一个 main 方法里，不分层、不引入设计模式，代码很快就会变得臃肿且无法维护。
那怎么办呢？答案是结合现有的 Agent 框架，去做流程编排。就像 Java 有 Spring Boot，AI 领域也有自己的开发框架，它已经把 Prompt 管理、记忆、工具调用等核心组件封装成"积木"，我们要做的，就是用这些积木搭出稳定可控的业务流程。
流程编排的到底是什么？ 编排的是 Agent 的行为路径：什么场景该调哪个工具、什么条件下走分支、什么节点需要人工确认、什么步骤允许 AI 自由发挥。
但流程编排到一定程度后，新的问题又来了：当一个单体 Agent 要处理的上下文越来越长、工具越来越多时，就会遇到和"单体巨石应用"一样的问题 —— 上下文过载、任务互相干扰、一个点出问题整个 Agent 崩掉。
解决方案也出奇地一致：按单一职责拆分为多个子 Agent，一个负责意图识别，一个负责订单查询，一个负责营销话术，各司其职、互不干扰，这就是微服务"分而治之"思想在 AI 领域的完美复刻。
你看，不管是框架封装、流程编排、模板方法还是微服务拆分，全程没有哪个技术是从零发明的，全是后端工程师熟悉的那套东西。
AI 应用开发工程师做的事情，本质上就是用软件工程的成熟方法论，去驯服大模型的随机性，让 Agent 既能发挥自主性，又能遵循稳定、可控的业务路径。
知道 AI 的"能力边界"很重要
了解了 AI 能做什么，我们还得知道它不能做什么，这是避免踩坑的关键。
上下文窗口：AI 的"工作内存"与工程挑战
刚才我们聊到跟 AI 对话是有记忆的，那你有没思考过这样一个问题，当对话 Context 内容越来越多，Memory 记忆越来越长，会发生怎样的问题呢？我们会发现，计算成本、内存成本、网络成本、训练成本等等都成倍增长，那我们如何解决呢？
其实很多大模型的做法是在当前聊天窗口中，做了"容量限制"，会自动把最早的内容"忘了"，这就是模型单次处理 Token 数的硬性上限，它不是刻意设限，而是当下技术的一个物理瓶颈，这就是我们常说的 上下文窗口（Context Window）。
说白了就是：文档太长它看到后面就忘了前面，聊天轮数太多它就不记得你最初问了什么。
那如何解决上下文超长的问题呢？
其实解决思路有很多，例如：
- 滑动窗口摘要：仅保留最近 N 轮对话的原始内容，将更早的对话压缩成一段由模型生成的"摘要"，再将摘要加入上下文。在保证核心信息不丢失的前提下，节省 Token。
- 向量检索记忆：将所有历史对话的片段转换成向量存入向量数据库。每次新请求时，不是简单拼接所有历史，而是用新问题去向量库中检索最相关的几条历史片段，只将这些片段加入上下文。这种方法更智能，但对架构要求更高。
- 分层/分级记忆：模仿人类记忆系统，区分短期记忆（最近对话）和长期记忆（关键事实、用户画像）。短期记忆完整保留，长期记忆通过检索或摘要方式按需激活。
- 外部存储+检索：将历史对话存入外部数据库，每次查询时从数据库中检索相关片段加入上下文。
- 记忆玩法的进阶优化：大模型会自动总结历史对话，精简之后再存入上下文，达到节省 Token 和接口调用成本的目的。
模型幻觉：AI 为什么会"编故事"？
你肯定遇到过这种情况：问 AI 一个问题，它答得头头是道，引经据典，结果一查询全是瞎编的，这就是 模型幻觉。
说白了，AI 不知道自己在说什么，它只是在猜"下一个词填什么最通顺"。它不是在查数据库，而是在做概率题，猜对了看着像专家，猜错了就是一本正经胡说八道。
比如你问它某篇论文的结论，它可能直接给你编一篇不存在的论文出来，作者、期刊、页码全有，看着特别真，但你去搜根本没有。
为什么会这样？因为 AI 的知识来自训练数据，训练数据里有错的，它就学错了，而且它没有"这话说得对不对"的判断能力，它只知道"这么说通不通顺"。
就像你写了个算税率的函数，边界条件没处理好，某些输入下算出负数税率，程序不报错，结果也出来了，用户看着以为是对的，其实是错的。
怎么应对呢？ 说白了就四招
- 重要信息多找几个来源核对；
- 让 AI 说清楚信息从哪来的；
- 用 RAG 把真实资料塞给它让它基于资料回答；
- 关键决策别全信 AI，必须人来把关。
总结：AI 开发，一场与后端设计思想的伟大重逢
我们来从头梳理一遍，看看 AI 是怎么从一个只会"接话茬"的文字游戏，一步步变成能自己动手干活儿的智能体 Agent 的:
最原始的大模型本质上就是个"词语接龙高手"，它读遍了海量文本，学会了根据上文推测下文。但它没有真正的理解能力，也不知道自己在说什么，更致命的是，知识永远停在训练截止那天，断网了。
断网是硬伤，所以人们给它装了两条"手臂"：一条叫搜索，帮它在网上找最新信息；另一条叫 RAG，帮它在企业私有文档里查资料。找到相关内容就塞给大模型，它就能给出靠谱的回答。大模型本身没变，只是多了帮忙翻资料的外挂。
光会查不够，还得让它能操作外部系统。于是有了函数调用，相当于一套标准口令，大模型想查天气、算个数、发个邮件，就按约定格式发出指令，系统自动去执行对应的 API。大模型终于能"喊人帮忙"了。
工具越来越多，每接一个都要写一套适配代码，太麻烦。MCP 出现了，它就像一个统一接口标准，所有工具照着做，就能即插即用。大模型的可扩展性一下子打开了。
大脑有了，资料能查了，工具会用了，插头也统一了，把这些全打包在一起，再加一个规划能力，智能体 Agent 就诞生了。你说"帮我订张机票"，它能自己拆成查航班、比价格、选座位、完成支付，全程不用你操心。
任务一复杂，完全放手的 Agent 容易出错。于是有了流程编排，把固定步骤写成规范流程，把灵活部分留给 AI 自己发挥，甚至把一个大智能体拆成好几个各司其职的子智能体。既保证了稳定性，又保留了自主性。
到这里，我们从最基础的 LLM 出发，一路见证了 AI 如何因为"需求驱动"，层层叠加能力，最终从会接话，到能查资料，到会用工具，到统一工具接口，再到自主规划和接受管控 —— 这就是 AI 从"只会聊天"到"能帮你干活"的完整进化过程。