从产品能力到技术实现：用软件开发视角理解人工智能

自 AI 概念火热以来，我陆续看过不少相关书籍和文章，也零散理解过一些名词。但这些理解往往停留在“好像知道”的层面：单个概念能说出几句，概念之间的关系却没有真正连起来。

直到近期参加公司组织的《人工智能专题培训》，再结合自己的软件开发经验重新消化，我才逐渐找到一个更适合自己的理解路径：不要一开始就扎进算法和模型细节，而是先把 AI 当成一个产品、一个智能体，观察它表现出了哪些能力，再反过来追问这些能力背后的技术实现。

本文就是沿着这个思路，对 AI 做一次重新梳理。它不从抽象概念出发，而是从软件开发者更熟悉的“能力功能 → 实现原理 → 技术演进”展开。

这不是一篇 AI 算法教材，也不追求把每个技术细节讲到严格完备。重点是帮助自己建立一套理解框架：当我们说 AI 具备理解、生成、检索、记忆和工具调用能力时，知道它们在工程上大致是如何被拼装出来的。

一、产品视角：从能力理解人工智能

1. 基本定义：人工智能是一组智能能力

用一句话描述，人工智能就是让计算机模拟人类智能的技术。

但如果一上来就从技术名词切入，比如机器学习、深度学习、神经网络、大模型，理解起来会比较吃力。因为这些词描述的是实现方式，而不是我们最直观感受到的东西。

对使用者来说，AI 首先不是一个算法，而是一组能力：它能听懂问题，能组织回答，能进行推理，能查找资料，能记住上下文，也能调用工具完成任务。

2. 产品视角：拆解 AI 能力

所以，我更倾向于先把 AI 看作一个具备多种能力的产品，就像我们日常使用的对话助手或编程助手。它不是单纯返回一段文本，而是在接收输入后，完成理解、判断、生成、检索、记忆、行动等一系列过程。

从这个视角看，AI 就不再是一堆孤立的技术名词，而是一个可以被拆解的产品系统。我们可以先问：它表现出了哪些能力？再继续问：这些能力分别依赖哪些技术？

3. 能力地图：能力与技术的对应关系

本文后续就按这样的关系展开：

AI 能力	背后的核心技术
理解能力	Token、向量、Embedding
生成能力	机器学习、神经网络、大语言模型
检索能力	RAG、向量检索
推理能力	分步生成、反思、验证
记忆能力	上下文窗口、长期记忆
工具调用能力	Tools、ReAct、Skills

这张表不是严格的技术分类，而是一张阅读地图。后面每一章都会围绕一个能力展开：先解释这个能力在产品上表现为什么，再解释它在技术上大致如何实现。

二、理解能力：AI 如何读懂世界

1. 语言转换：从自然语言到数字语言

我们直观感受到的“理解能力”，通常是这样的：输入一句话，AI 能识别出其中的含义，并给出符合预期的反馈。比如你问它“帮我总结这段话”，它知道你不是要翻译、不是要续写，而是要提炼重点。于是我们会说：AI 好像“听懂了”。

但计算机并不能直接理解自然语言。对它来说，“苹果”“apple”“一只猫”“帮我写一段代码”这些内容，本质上都不能直接参与计算。计算机真正能处理的是数字。

所以，AI 理解人类语言的第一步，就是把自然语言转换成数字语言。

这个过程和人学习外语有点像。我们第一次学到 “apple” 时，并不是只记住这几个字母，而是把它和中文里的“苹果”、现实中的苹果，以及它的颜色、味道、形状等经验关联起来。理解的过程，本质上就是建立符号和含义之间的关系。

AI 也是类似的思路。只是在人类世界里，这种关系存在于经验和语境中；在 AI 的数字世界里，这种关系要被转换成一组可以计算的数字表示。

2. 语义表示：向量与 Embedding

上一小节说到，AI 要先把自然语言翻译成“数字语言”。那么，这里的数字语言到底指什么？答案就是向量。

如果只描述一段距离，一个数字就够了，比如 10 米；如果描述一个方向，就需要一组数字，比如二维坐标里的 [3, 4]。这就是向量的直观含义：它不是一个单独的数字，而是一组数字。

那么，如果要描述“一只猫”呢？显然一个数字不够。它可能涉及颜色、体型、轮廓、毛发、声音、动作等多个维度。维度越多，表达能力越强。

文本也是一样。一个词不是靠一个数字来表达，而是会被转换成一组数字。比如“苹果”这个词，在模型内部可能对应一个高维向量。这个向量里的每个数字，本身不一定能被人类直接解释成“颜色”“味道”这样的具体含义，但整体上能表达它在语义空间中的位置。

这种把文本转换成向量表示的过程，通常就叫 Embedding。

可以把 Embedding 理解成一种“语义坐标”：意思相近的词，在这个坐标空间里的位置也更接近。也就是说，相近的维度越多，我们就越认为这两个词含义相似。比如“苹果”和“水果”的距离，通常会比“苹果”和“发动机”更近。

3. 文本切分：Token 与 Tokenizer

不过，大语言模型并不是直接把一整句话变成一个向量。它处理文本之前，还会先做一步切分：把文本拆成一个个 Token。

Token 可以简单理解为模型处理文本的最小片段。它可能是一个字、一个词，也可能是一个词的一部分。比如一句话：

我喜欢吃苹果

在进入模型前，可能会被切成类似这样的片段：

我 / 喜欢 / 吃 / 苹果

真实的切分规则不一定完全符合人的分词习惯，因为它取决于模型使用的 Tokenizer。Tokenizer 的作用，就是把自然语言文本切成 Token，并把每个 Token 转换成对应的数字编号，也就是 Token ID。

所以，文本进入大模型前，大致会经历这样一条路径：

自然语言 → Token → Token ID → 向量表示

这一步很重要。因为大模型后续并不是在处理“文字本身”，而是在处理这些 Token 对应的数字和向量。

4. 语义映射：映射关系从哪里来

那么问题来了：文字和向量之间的对应关系是谁建立的？是不是有一个数据库，专门记录“苹果”等于哪组向量、“猫”等于哪组向量？

答案不是简单的人工维护数据库。

语义映射主要来自两个部分：一是 Tokenizer 定义了文本如何被切分，以及每个 Token 对应哪个数字编号；二是 Embedding 和模型训练，让这些 Token 在不同语境中逐渐形成含义和关系。

其中，Embedding 负责把 Token ID 转换成向量表示；训练过程则让这些向量逐渐具备语义关系。

也就是说，模型不是靠人工逐条告诉它“苹果是什么”，而是在海量文本中反复看到“苹果”如何被使用：它可以被吃、可以是水果、也可以是公司名称；它会和“红色”“手机”“乔布斯”等词出现在不同语境里。经过训练后，模型参数中就沉淀了这些统计关系和语义关联。

这里先不展开模型是如何训练出来的，后面讲生成能力时再说。当前只需要先建立一个认识：AI 所谓的“理解”，不是像人一样拥有感官经验和主观意识，而是把自然语言转换成 Token、数字和向量，再依靠训练得到的参数关系进行计算。到这一步，AI 已经把人类语言放进了自己的数字世界。

但“表示出来”还不等于“回答出来”。接下来要看的是：模型拿到这些数字之后，如何一步步生成回复。

三、生成能力：AI 如何组织回答

1. 生成本质：不是逻辑运算，而是概率预测

说完理解能力，再看生成能力。

上一章讲到，AI 会先把自然语言转换成 Token、数字和向量。接下来它要做的事情，就是基于这些输入组织回答。

这里很容易产生一个误解：我们会把 AI 想成传统软件程序，认为用户输入一个问题后，系统按照某个明确算法一步步计算出答案。

但大语言模型不是这样工作的。传统软件更多是逻辑运算，开发者提前写好规则，程序按照规则执行；而大语言模型生成回答的核心动作，是基于已经看到的上下文，预测下一个最可能出现的 Token。

比如你问豆包：“你是谁？”它最终回答：“我是豆包。”从结果看，好像它理解了你的问题，并组织出了一句完整回答。但从模型内部看，这个过程更接近于一次连续预测：

你是谁？ → 我
你是谁？我 → 是
你是谁？我是 → 豆包
你是谁？我是豆包 → 。

每生成一个 Token，模型都会把新生成的内容追加到上下文里，再继续预测下一个 Token。如此反复，就形成了我们看到的一整段回答。

最终输出哪个 Token，取决于模型的概率分布和采样策略。因此，AI 的输出不是精确计算出的唯一答案，而是在概率世界中的一次落点。

这也是为什么你多次问同一个问题，AI 往往会给出相似但不完全相同的回答。它们背后的方向一致，但措辞、结构和细节可能不同。

所以，AI 生成回答的本质，不是传统软件中的逻辑运算，而是基于大模型的概率预测。

2. 预测原理：模型训练与机器学习

既然 AI 的回答来自概率预测，那么下一个问题就是：这种预测能力是从哪里来的？

答案是训练出来的。

大模型并不是一开始就知道如何回答问题。它需要先接触大量文本数据，在训练过程中不断调整内部参数，让自己越来越擅长根据已有上下文预测后续内容。

这个训练模型的过程，就是机器学习。

所谓机器学习，可以简单理解为：让模型从大量历史数据中总结规律，从而具备对新数据做预测的能力。它是数据驱动的，开发者不是把所有判断规则都写进代码里，而是提供数据、设计训练方法，让模型自己从数据中学习规律。

机器学习中有不同的模型和算法。比如决策树会通过树形结构学习判断规则，神经网络会通过大量参数学习复杂模式。前者适合理解“模型如何从数据中学规则”，后者则更接近大语言模型的核心技术路线。

3. 简单模型：用决策树理解模型训练

决策树是一种比较容易理解的机器学习模型。它像一棵树，通过一层层条件判断，把复杂问题拆成多个简单问题，最后在叶子节点给出预测结果。

以电影票房爆款预测为例。我们可能会收集一些历史数据：演员阵容、导演影响力、宣发投入、上映档期、题材类型、最终票房等。人可以大致知道这些因素会影响票房，但很难手写出一套准确规则：宣发多少算高？演员影响力和题材之间怎么组合？什么情况下更可能成为爆款？

决策树要学习的，就是这样一套判断规则。

它会从历史数据中寻找合适的分裂条件，比如“宣发投入是否超过某个阈值”“主演影响力是否足够高”，然后不断把数据分成更纯的子集。训练完成后，模型得到的就是一棵确定的树。

当新电影的数据进来时，只需要从根节点开始，根据每个节点的判断条件往下走，最后抵达某个叶子节点。叶子节点的结果，就是模型给出的预测。

这个例子说明了一件事：模型训练不是把答案背下来，而是从数据中学出一套可用于预测的结构。

当然，训练出一棵树还不代表模型就可靠。通常我们会把历史数据拆成训练集和测试集：训练集用来让模型学习规则，测试集则用来检查模型在“没见过的数据”上表现如何。

如果模型只是在训练数据上表现好，但遇到新数据就不准，说明它并没有真正学到可泛化的规律。这也是模型训练中非常关键的一步：不能只看它有没有学会历史样本，还要看它能不能预测未来样本。

不过，决策树这类传统机器学习模型还有一个明显限制：它通常依赖人工特征工程。前面说模型要从历史数据中学习，这里的历史数据可以理解为一条条样本。每条样本通常包含两部分：一部分是用于判断的输入信息，也就是特征；另一部分是希望模型预测出来的正确答案，也就是标签。所谓人工特征工程，就是人先帮模型决定“应该看哪些特征、这些特征应该怎么表达”。

比如电影票房预测中，人要先把“主演影响力”“宣发投入”“上映档期”“题材类型”等信息整理成模型可用的特征。对于电影票房、垃圾邮件识别这类问题，这还能处理；但如果是图片、语音、自然语言这种复杂数据，人工很难把所有有效特征都列出来。

这就引出了神经网络。

4. 神经网络：让模型自己学习特征

神经网络可以理解为一种更强的模式学习结构。它由大量简单的计算单元连接而成，数据从输入层进入，经过多层计算，最终得到输出结果。

它和传统机器学习方法的一个重要区别是：神经网络不完全依赖人工定义特征，而是能够从大量数据中自动学习出有效的特征表示。

回到文本生成场景。比如让模型预测“今天天气很好，我们一起去”后面应该接什么。人当然可以设计一些特征：前面出现了“天气很好”，说明可能适合户外活动；出现了“我们一起”，说明后面可能是一个动作或地点。

但真实语言远比这复杂。上下文、语气、词语搭配、句法结构、常识背景都会影响下一个词是什么。如果靠人工特征工程，我们几乎不可能把这些因素都列出来。

神经网络的价值就在于，它可以从大量文本中自动学习这些复杂关系。它不需要人手写“什么情况下该接公园，什么情况下该接吃饭”，而是在海量语料中反复训练，逐渐学到词语之间、句子之间、上下文之间的统计规律。

训练神经网络的大致过程可以简化为：

1. 初始化参数：先搭好网络结构，参数一开始通常是随机的。
2. 前向传播：输入一条训练数据，模型根据当前参数计算预测结果。
3. 计算损失：比较预测结果和真实答案，得到偏差。
4. 反向传播：根据偏差反推每个参数应该如何调整。
5. 更新参数：小幅修改参数，让下次预测更接近真实答案。
6. 重复训练：不断循环，直到模型效果达到预期。

如果说决策树训练出来的是一棵可解释的判断树，那么神经网络训练出来的核心产物，就是一大组参数。在工程里，这些参数通常会被保存成模型文件，比如 .safetensors。

这些参数很难逐条解释，但它们共同决定了模型如何处理输入、如何做出预测。模型训练完成后，实际使用时不会重新学习一遍。当新的会话输入进来，模型会先把文本转换成 Token 和向量，再带着这组已经训练好的参数进行计算，得到下一个 Token 的概率分布，并据此生成结果。

使用大量文本数据，经过神经网络训练后，得到的是基础语言模型，也就是后续生成回答的基础。

5. 进阶训练：从基础模型到领域模型

到这里，我们已经知道，大语言模型来自大量文本数据和神经网络训练。但这通常还只是基础模型。它具备语言能力，却不一定擅长按照人的指令完成任务，也不一定熟悉某个具体领域。

为了让模型能力更接近实际使用需求，通常还需要在基础模型之上继续训练和对齐。

第一阶段是预训练。模型在海量文本上学习语言规律，目标通常就是预测下一个 Token。通过这个过程，模型获得了基础语言能力，也积累了大量世界知识和语义关联。

第二阶段是监督微调。人们会准备一些高质量的问答、指令和示例，让模型学习如何按照用户指令组织回答。经过这一步，模型从“会续写文本”变得更像“会回答问题”。

第三阶段是偏好对齐。模型可能会生成多个回答，人类或评价模型会判断哪个更好。通过这种反馈，模型逐渐学习什么样的回答更有帮助、更安全、更符合人的偏好。

在具体业务场景中，还可能继续做领域增强，比如用企业知识库、行业语料、代码仓库或业务文档，让模型更熟悉特定领域。

所以，大模型并不是一次训练完成后就结束了。它通常会经历从基础模型、通用指令模型到领域模型的演进过程。每一阶段都在原有能力上继续增强：先学会语言规律，再学会按照人的指令回答，最后适配具体领域和业务场景。

到这里，我们可以先得到一个阶段性结论：AI 能组织回答，本质上是因为它通过训练学会了在上下文中预测下一个 Token，并通过连续预测生成完整内容。

但仅仅会生成，还不等于能回答所有问题。尤其当问题涉及最新信息、企业内部资料或专业领域知识时，模型还需要先找到可靠依据。下一章我们就看检索能力如何补足生成能力。

四、检索能力：AI 如何使用外部知识

1. 检索动机：概率预测不等于事实查询

前面讲过，大模型生成回答的本质是概率预测。它会根据训练中学到的语言规律和上下文，生成一个看起来最合理的回答。

但概率预测不等于事实查询。

如果你问的是通用知识，模型可能回答得不错；但如果问题涉及最新信息、企业内部资料、专业领域知识，或者训练数据中没有覆盖的内容，模型就容易给出看似合理但并不准确的回答。这类情况通常被称为幻觉。

幻觉并不一定是模型“故意胡说”，更多时候是因为它在缺少可靠依据时，仍然按照语言模式继续生成了答案。

所以，解决这类问题的关键，不是让模型凭空变得什么都知道，而是给它提供可靠的外部知识。

2. RAG 思想：先查资料，再生成回答

RAG，全称是 Retrieval-Augmented Generation，通常翻译为检索增强生成。

它的核心思想很简单：不要让模型只凭训练时学到的内容回答，而是在回答前先去指定知识库中检索相关资料，再把检索到的内容作为上下文交给模型，让模型基于这些资料生成回答。

可以把它理解成开卷考试。

闭卷时，模型只能依赖自己训练时学到的内容；开卷时，模型可以先查资料，再组织答案。这样回答会更贴近指定知识范围，也更容易追溯依据。

一个典型的 RAG 流程大致是：

用户提问
→ 检索相关文档
→ 把文档片段放入上下文
→ 大模型基于上下文生成回答

这里的重点是：RAG 并不是重新训练模型，而是在生成回答之前，给模型补充一段更可靠的上下文。

3. 向量检索：语义匹配相关资料

那么，系统如何从大量文档中找到和问题相关的内容？

如果是传统搜索，我们可能会想到关键词匹配。比如用户搜索“密码重置”，系统就去找包含“密码”“重置”这些词的文档。

但自然语言有一个问题：同一个意思可以用很多不同表达。比如“忘记密码怎么办”和“如何重置登录凭证”语义接近，但字面关键词并不完全相同。只靠字符串匹配，很容易漏掉相关内容。

这时就需要向量检索。

第二章已经讲过，文本可以被转换成向量，而向量之间越相似，通常就表示语义越接近。RAG 中也是类似思路：先把知识库里的文档切成片段，再把每个片段转换成向量，存入向量数据库。当用户提问时，也把问题转换成向量，然后计算“问题向量”和“文档向量”之间的相似度。

流程可以简化为：

文档片段 → 向量化 → 存入向量数据库
用户问题 → 向量化 → 相似度计算 → 召回相关片段

相似度计算可以理解为：两个向量在语义空间里越接近，就说明它们表达的意思越相关。常见方式包括欧氏距离和余弦相似度。

欧氏距离可以理解为看两个点之间的距离，距离越短，越相似。

余弦相似度则更关注两个向量方向是否接近，方向越接近，语义越相似。

通过这种方式，系统不只是找“字面相同”的内容，而是找“语义相近”的内容。

简单说，检索能力本质上就是通过向量相似度比较，匹配出相似度高的资料，再让模型基于这些资料生成答案，从而降低幻觉问题。

不过，找到资料只是第一步。当问题本身比较复杂时，模型还需要进一步拆解任务、组织步骤、检查结论。接下来，我们再看推理能力。

五、推理能力：AI 如何处理复杂问题

1. 能力定义：什么是推理能力

前面讲到，AI 生成回答的本质，是基于上下文做概率预测。对于简单问题，这种能力已经足够用了。比如问一句“Python 如何读取文件”，模型可以直接生成一段回答。

但复杂问题往往不是一次生成就能解决的。

比如让 AI “分析一个系统为什么变慢，并给出优化方案”，它不能只凭第一反应直接下结论。它需要先理解现象，再拆分可能原因，比如数据库、缓存、网络、代码逻辑、资源瓶颈；然后逐项分析，最后再形成结论。

本文所说的推理能力，指的就是 AI 面对复杂问题时，能够进行任务拆解、步骤组织、关系判断、结果验证和修正的能力。

它不是说模型内部多了一个独立的“思考模块”，而是在生成能力之上，把复杂问题组织成一连串更小、更明确的处理步骤。比如用户提出：

帮我设计一个用户登录系统。

直接回答当然也可以，但更好的方式是先拆成几个步骤：

1. 明确登录方式：账号密码、手机号验证码、第三方登录
2. 设计核心流程：注册、登录、退出、忘记密码
3. 设计数据结构：用户表、凭证表、登录日志
4. 考虑安全机制：密码加密、验证码、防暴力破解
5. 输出接口设计和异常处理

拆解之后，每个小问题都变得更清晰，模型也更容易逐步生成可靠答案。

2. 形成机制：推理能力如何形成

推理能力不是靠一句提示词“请你认真思考”凭空产生的。它首先来自模型训练。

在训练语料中，模型会见到大量分析、证明、代码、方案设计、故障排查、数学推导等文本。这些文本本身就包含了很多问题解决过程：如何提出假设，如何拆分步骤，如何根据条件推导结论，如何解释原因。

经过训练后，模型不只是学会了词语之间的统计关系，也学到了一些常见的问题解决结构。比如：

先明确目标
再拆分条件
然后逐项分析
最后给出结论

所以，推理能力仍然建立在生成能力之上。区别在于，简单生成更像是直接给出回答，而推理是在生成过程中组织出更清晰的中间步骤，让模型能够处理更长链路的问题。

3. 增强方式：推理能力如何增强

基础模型已经具备一定推理能力，但在复杂任务中，它仍然可能遗漏条件、跳过步骤、前后矛盾，或者生成看似合理但并不可靠的结论。

因此，在实际应用中，我们通常会通过一些工程手段增强推理过程。

第一种是提示词和系统指令。比如要求模型先拆解问题，再逐步分析，最后检查答案。这不是创造推理能力，而是把模型已经学到的问题解决模式更稳定地组织起来。

第二种是多轮调用。可以先让模型生成初稿，再让它检查遗漏，最后根据检查结果修正答案。这样比一次性生成更容易发现问题。

第三种是工具和外部验证。比如让模型调用搜索工具补充信息，调用代码执行工具验证结果，或者用规则和评估模型检查输出是否符合要求。

当这些能力被进一步组合起来，模型就不只是“回答问题”，而是开始具备“执行任务”的形态：它可以理解目标、拆解步骤、调用工具、观察结果，再根据结果继续调整下一步。

因此，AI 的推理能力可以理解为：训练让模型具备问题解决的基础模式，任务拆解和分步生成让过程更清晰，提示词、多轮调用和工具验证则让这种能力在实际应用中更稳定。这也为后面理解记忆、工具调用和智能体打下基础。

六、记忆能力：AI 如何保留上下文

1. 短期记忆：历史对话进入上下文

我们和 AI 对话时，会感觉它记得刚才说过的话。比如你先说“我正在写一篇介绍人工智能的文章”，后面再说“帮我优化第二章”，它通常知道“第二章”指的是这篇文章里的第二章。

但这并不是因为模型像人一样在脑子里留下了记忆。

它的实现其实很简单：每次会话请求并不只包含你最新输入的一句话，还会携带当前会话里的历史消息。模型同时看到当前问题和前面的对话内容，就能基于这些上下文继续回答。我们通常把这种会话内的上下文保留，称为短期记忆。

可以简单理解为：

当前问题 + 历史对话 → 一起放进上下文 → 模型生成回答

所以，短期记忆的本质，就是把历史对话放进当前上下文。

这也带来一个很实用的启示：同一个会话聊得越久，携带的历史内容就越多，消耗的 Token 也越多。如果前面的上下文已经和当前任务关系不大，及时开启一个新会话，反而能让对话更轻、更聚焦。

这种方式有两个限制。

第一，上下文窗口有限。模型一次能处理的内容不是无限的，对话越长，能放进去的历史就越多，也越容易触达窗口上限。

第二，短期记忆通常只在当前会话里有效。换一个新会话，如果应用没有额外保存和注入历史信息，模型就不知道之前发生过什么。

2. 长期记忆：持久化存储与按需检索

如果希望 AI 跨会话记住一些信息，比如用户偏好、项目背景、长期目标，就不能只依赖短期记忆。

这时需要长期记忆。

长期记忆的做法，是把重要信息持久化保存到外部存储中，比如数据库、文件、向量库等。之后当用户再次对话时，系统再根据当前问题，把相关记忆取出来，放回上下文里。

流程可以简化为：

识别重要信息 → 保存到外部存储
新的问题到来 → 检索相关记忆 → 放入上下文 → 模型生成回答

你会发现，它和前面讲过的 RAG 很像。RAG 检索的是外部知识库，长期记忆检索的是和用户、会话、项目相关的历史信息。两者本质上都是：在生成回答前，按需取回相关上下文。

3. 记忆策略：记什么、何时记、如何用

真正困难的不是“能不能存”，而是“应该怎么记”。

如果什么都记，记忆会变得混乱，甚至把临时闲聊、错误信息、过期信息也带进后续回答。这样不仅不能提升效果，还可能干扰模型判断。

所以，记忆能力需要一套策略。

首先是记什么。通常更适合保存的是长期稳定、未来可能复用的信息，比如用户偏好、项目背景、业务规则、长期目标、明确事实等。临时情绪、一次性闲聊、未经确认的信息，则不一定适合进入长期记忆。

其次是什么时候记。可以由用户明确要求，比如“记住我喜欢用中文回答”；也可以由系统根据规则判断，比如用户多次提到同一个项目背景，就把它整理成一条长期记忆。

最后是如何用。记忆不是每次都全部塞给模型，而是要根据当前问题检索相关内容，再把最有帮助的部分放入上下文。否则记忆太多，也会占用上下文窗口，甚至带来干扰。

在实际使用中，通常不需要我们从零设计这些记忆策略。社区里已经有很多现成的 memory 类工具或 Skill，可以负责记忆的保存、更新和检索。我们只需要理解它的核心机制：记忆并不在模型本身，而是由外部能力管理，并在需要时重新放回上下文。

七、工具调用能力：AI 如何连接外部系统

1. 工具动机：为什么大模型需要工具

到目前为止，我们讲的能力大多还停留在“理解信息、组织回答”这一层。

但真实任务往往不只是回答一句话。比如：

查询今天的天气
读取一个文件并修改内容
运行一段代码并检查结果
调用接口创建一条订单
从数据库里查询用户信息

这些事情仅靠大模型本身是做不到的。模型可以生成文本，但它不能天然访问实时数据，不能直接操作文件，也不能自己执行代码或调用业务系统。

所以，如果希望 AI 从“会回答”变成“会做事”，就需要让它具备工具调用能力。

这里就引出了智能体的概念。智能体可以理解为一个围绕目标执行任务的系统，它会把大模型、系统提示词、工具列表和运行机制组织起来，让模型不只是生成答案，还能在需要时调用外部工具完成任务。

2. 调用机制：智能体如何实现工具调用

智能体实现工具调用，可以从两个关键词理解：Tools 和 ReAct。

Tools 是智能体可以调用的外部能力。一个工具通常会包含三类信息：

工具名称：这个工具叫什么
工具描述：它能做什么
参数结构：调用它需要传什么参数

这些工具会作为工具列表提供给模型。模型看到工具列表后，就知道当前有哪些外部能力可以使用，以及调用这些能力时需要传入什么参数。

从接口层面看，工具就是随请求一起发给模型的一张“能力清单”。比如一次对话请求里，除了系统消息、用户消息和历史消息，还可以附带一个 tools 列表，告诉模型：你现在可以调用哪些工具、每个工具能做什么、调用时需要哪些参数。模型判断需要使用工具时，不是自己直接执行，而是返回一个工具调用请求；外部系统真正执行工具，再把执行结果传回模型。

但只有工具列表还不够。智能体还需要一种运行机制，决定什么时候调用工具、调用哪个工具、拿到结果后下一步做什么。这就是 ReAct。

ReAct 可以简单理解为 Reason + Act，也就是“推理 + 行动”。它让智能体在解决任务时形成一个循环：

思考当前目标
→ 决定下一步行动
→ 调用工具
→ 观察工具结果
→ 根据结果继续推理

这个循环中，大模型负责判断和生成调用意图，智能体框架负责真正执行工具调用，并把工具结果重新放回上下文。模型再基于新的上下文继续推理、回答，或者发起下一次工具调用。

比如排查一个接口报错，智能体可以先让模型分析可能原因，然后调用日志查询工具；看到日志后，再判断是参数问题还是数据库问题；如果信息还不够，再继续调用其他工具。

所以，Tools 和 ReAct 是一组配合关系：Tools 定义智能体能做什么，ReAct 负责把“思考、调用工具、观察结果、继续思考”的过程运行起来。

3. 工具形态：API、MCP 与 Skills

从本质上看，工具就是智能体可以调用的外部能力。只是根据来源、组织方式和使用场景不同，工具会呈现出不同形态。

最常见的是普通工具，也就是应用系统提前定义好的 API。这些 API 可能是内部程序方法，也可能是业务系统接口。比如读取文件、执行命令、查询数据库、调用订单接口，本质上都是把某个确定能力包装成一个可调用工具。

MCP 可以理解为一种更标准化的工具连接方式。普通工具往往由当前应用自己定义，而 MCP 的特殊之处在于，它提供了一套统一协议，让智能体可以连接外部服务提供的方法。比如文件系统、浏览器、数据库、设计工具，都可以通过 MCP 暴露成智能体可调用的能力。

Skills 则更像是一种提示词和资料组织机制。它本质上不是 API，而是围绕某类任务准备好的操作说明、提示词、参考资料，必要时也可以附带脚本。它的核心特征是按需加载，也叫渐进式披露：平时只暴露名称和简短描述，等模型判断当前任务需要某个 Skill 时，再把完整说明加载进上下文。

比如一个 memory Skill，平时只需要告诉模型“这是一个用于保存和检索记忆的能力”。当任务真的需要记忆管理时，再加载它的具体使用规则：什么时候保存，如何更新，如何检索，如何避免记录敏感信息。

一个典型的 Skill 目录大致可以长这样：

memory/
├── SKILL.md          # 技能说明、触发条件、执行步骤
├── references/       # 参考资料、规则、示例
│   └── memory-rules.md
└── scripts/          # 可选脚本，用于执行具体辅助动作
    └── summarize_memory.py

其中 SKILL.md 是核心，负责告诉模型这个 Skill 什么时候该用、怎么用；references 用来放更详细的背景资料；scripts 则用于放一些可复用的辅助脚本。

简单说，工具调用能力让 AI 从“生成答案”走向“执行任务”。智能体是整体，Tools 是能力列表，ReAct 是运行机制；普通 API、MCP 和 Skills 都在扩展智能体可用的能力，只是组织形式不同。

八、总结：从软件开发视角重新看 AI

回到文章开头的问题：人工智能到底应该如何理解？

如果只从技术名词出发，很容易陷入机器学习、神经网络、大模型、RAG、智能体这些概念里，越看越散。但如果从能力视角看，AI 会清晰很多。

它的理解能力，来自文本被切分成 Token，再转换成向量表示；它的生成能力，来自大模型基于上下文做概率预测；它的检索能力，是通过向量相似度从外部知识库中找到相关资料，降低幻觉；它的推理能力，是在生成能力之上，通过任务拆解、步骤组织和结果检查，让模型能够处理复杂问题；它的记忆能力，是把历史信息保存下来，并在需要时重新放回上下文；它的工具调用能力，则让智能体能够连接外部系统，从生成答案走向执行任务。

所以，AI 并不是某一个单点技术带来的结果，而是一组能力的组合：

理解 = Token + 向量 + Embedding
生成 = 神经网络 + 模型训练 + 概率预测
检索 = 向量化 + 相似度计算 + RAG
推理 = 任务拆解 + 分步生成 + 结果检查
记忆 = 外部存储 + 按需检索 + 上下文注入
工具 = Tools + API + MCP + Skills + ReAct + 智能体框架

这些在人类身上习以为常的能力，被拆解、建模并组合起来，就构成了我们今天所说的人工智能。