基础知识

什么是 LLM、Prompt、Context、Memory、Tools、Tool Calling、Function Calling、RAG、MCP、Agent、Agent Loop、Workflow？

LLM (核心大脑)

LLM 又称 大语言模型。比如 ChatGPT、文心一言、通义千问。它是一个用海量文本数据训练出来的超级大脑。

它就像一个读了全世界所有书、文章和网页的超级大学毕业生。
他知识渊博，能说会道，但有个致命弱点——他没有任何亲身经历，也无法接触实时世界。
他知道“雨”是什么，但不知道现在外面有没有下雨；他知道“点餐”流程，但他自己没法去厨房做饭或打电话订餐。

下面这些是理解和使用 LLM 时绕不开的概念；后面讲 Context、Agent 时也会反复用到。

大语言模型原理

LLM 的核心能力来自一件事：根据已经出现的文字，预测下一个最可能出现的文字（或 Token），不断重复，就拼成一整段回答。

训练阶段：用互联网、书籍、代码等海量文本，让模型学会“在这种上下文里，下一个词通常是什么”。它不是在背标准答案库，而是在学语言的统计规律和模式。

使用阶段：你把 Prompt 喂给它，它从第一个字开始往后“接龙”，直到写完一句、一段或触发停止条件。所以 LLM 本质是极强的文本续写与模式匹配，而不是真正“理解世界”或“拥有意识”；复杂推理、实时事实要靠 Prompt、RAG、Tools 等外挂补上。

Token

Token 是模型读写文本的最小计费与处理单位，不严格等于一个汉字或一个英文单词。

• 英文里常见一个词 ≈ 1 个 Token；中文往往一个字可能对应 1～2 个 Token（因分词方式而异）。
• 你发的 Prompt、模型回的答案、工具返回塞进 Context 的内容，都会换算成 Token 数量。
• API 按 Token 计费；Context 能装多少，也用 Token 上限衡量。

可以把它想成毕业生读稿用的“字数块”：稿纸总格数有限（上下文窗口），写得太长就要删页；写得越多，出版社（云厂商）收费越高。

上下文窗口

上下文窗口（Context Window）指单次请求里，模型能同时读入的最大 Token 总量（输入 + 输出通常一起算，具体看厂商规则）。

窗口越大，能带的对话历史、系统说明、RAG 检索结果越多；窗口满了，就要截断最旧的内容或做摘要压缩。这和后文 Context（当前工作台） 里说的“桌上资料摞太厚”是同一回事——只是这里强调它是 LLM 的硬限制，不是软件想记就能无限记。

Temperature

Temperature（温度）控制模型生成时的随机性 / 创造性，一般在 0～2 之间（常见默认约 0.7）。

• 低温（如 0～0.3）：更确定、更保守，多次问类似问题答案差不多；适合代码、JSON、事实问答。
• 高温（如 0.8～1.2）：更发散、更有花样，也可能更不靠谱；适合头脑风暴、文案创意。
• 0：在支持的情况下往往接近“总是选概率最高的下一个 Token”，输出最稳定。

比喻：毕业生答题时的“胆子”。温度低像考官严、只许写标准答案；温度高像鼓励多角度发挥，但可能跑题。

推理模型与非推理模型

这是按模型是否擅长、是否内置长链思考来分的用法习惯，不是两个完全不同的物种。

	非推理模型	推理模型
典型代表	GPT-4o、Claude Sonnet（常规模型）	OpenAI o 系列、DeepSeek-R1、带 extended thinking 的型号
行为	收到问题后较快直接生成答案	常在内部先展开多步推理（有时可见“思考过程”），再给出结论
适合	聊天、翻译、简单抽取、格式转换	数学、复杂逻辑、多步规划、难题拆解
代价	通常更快、更省 Token	更慢、更贵，思考部分也可能占 Token

非推理模型并不等于“不能推理”，而是更依赖你在 Prompt 里写“请一步步想”；推理模型把“多想几步”做成了产品能力。选型时：要稳要快用常规模型；题难、步骤多再用推理模型。更多分类见 智能任务模型类别。

流式输出

流式输出（Streaming）指模型生成一个字（或一小段）就立刻推给你，而不是等整篇写完再一次性返回。

• 体验上像 ChatGPT 里字一个个蹦出来。
• 技术上常用 SSE（Server-Sent Events）或类似流式 HTTP；前端边收边渲染。
• 适合长回答、聊天；不适合必须一次性校验的严格 JSON（除非配合流式解析或最后再校验）。

对毕业生比喻：他边想边说，你不用干等到演讲稿全部打印完才听到第一句。

Completion 与 Chat Completion

这是调用 LLM API 时两种常见的接口形态（名字来自 OpenAI，其它厂商有类似概念）：

Completion（文本补全）

• 你给一段未写完的文本，模型接着往下写。
• 早期 GPT-3 风格："请用三句话介绍北京：" → 模型续写后面内容。
• 没有结构化的“角色”，全靠你拼进这一段 Prompt 里。

Chat Completion（对话补全）

• 你给一组带角色的消息列表，例如 system / user / assistant。
• 模型在对话语境下生成下一条助手消息；现代聊天产品、Agent 框架几乎都用这种。
• 便于分开写系统人设、用户问题、历史轮次，也方便 Tool Calling 把工具结果塞回 assistant 或 tool 消息。

	Completion	Chat Completion
输入	一段纯文本	消息数组（多轮、多角色）
典型场景	续写、模板填空	聊天机器人、Agent
现代项目	较少单独用	主流

在 Mastra 等框架里你日常打交道的，本质上都是 Chat Completion 这一套，只是封装成了 agent.generate() 或 stream()。

---

如果你还想从“模型能干什么、怎么部署”角度扩展，可以看 头上的那个上传的资源文件。

Prompt (沟通方式)

Prompt 又称 AI 提示词。你发给 LLM 的那段话，就是 Prompt。

你对那个“超级大学毕业生”提出的问题或指令。
提示词对 LLM 有重要的影响，因为它决定了 LLM 回答问题的精准度和质量。
例如：

• 糟糕的 Prompt：“写点东西。”（毕业生一头雾水）
• 好的 Prompt：“你现在是一位米其林大厨，请为我这个健身人士设计一份高蛋白、低脂肪的周一晚餐食谱，不需要甜品，步骤要简单。”（毕业生立刻清楚自己要做什么）

你的 Prompt 越好，LLM 给出的答案就越精准。

Context (当前工作台)

Context 又称 上下文。指这一次模型“眼前”能看到的全部信息，而不只是你刚发的那一句 Prompt。

可以把它想成毕业生面前摊开的一摞资料：系统设定（你是谁、要遵守什么规则）、历史对话、工具返回的结果、从知识库检索来的文档片段等，都会放进 Context。
模型只能根据 Context 里的内容来思考和回答，看不到的东西，它就当不存在。

Context 有容量上限（上下文窗口 / Context Window）。资料摞得太厚，最老的会被挤掉或截断，所以不是“记得越久越好”，而是要在有限篇幅里放最相关的信息。

例如：

• 只有一句用户消息：Context 很薄，模型不知道你五分钟前说过什么。
• 带上最近 10 轮对话 + 系统角色说明 + 一次天气工具返回：Context 变厚，模型能连续对话、也能引用刚查到的天气。

和 Prompt 的区别：Prompt 通常指你输入的那一段；Context 是模型本次推理时实际读到的整包输入。

Memory (长期记事本)

Memory 又称 记忆。让 Agent 在多次对话、多次任务之间保留有用信息，而不是每次从零开始。

大学毕业生默认“考完就忘”——关掉对话窗口，上次你说过敏、偏好、项目背景，他都不记得。
Memory 相当于给他一本记事本或档案柜：把重要事实写下来，下次见面先翻一眼再回答。

常见分法：

• 短期记忆：当前会话里的聊天记录（往往就是 Context 的一部分）。
• 长期记忆：跨会话保存的用户偏好、项目事实、过往结论（存在数据库、向量库等）。

例如：

• 没有 Memory：每次你都要重复“我是素食、不吃葱”。
• 有 Memory：Agent 记住你的饮食偏好，下次直接按习惯推荐。

**和 Context 的关系：**Memory 负责“存什么、什么时候取出来”；取出来的内容进入 Context，模型才能用上。

Tools (手脚延伸)

Tools 又称 工具。让 LLM 能够调用外部功能的能力。比如给 AI 装上手和脚，它就能做一些事情；给它装上刀，它就能切菜或者砍肉。

我们给那个“大学毕业生”配上的手机和工具箱。
他虽然不会做饭，但我们给了他一个订餐 App（工具），他就拥有了“订餐”这个能力。
例如：

• 没有工具时，你问：“北京今天天气怎么样？” 他说：“抱歉，我无法获取实时信息。”
• 有了“天气查询工具”后：他调用工具查到结果并告诉你：“今天北京晴，25 度。”

工具赋予了 LLM 与现实世界交互和获取实时信息的能力。

Tool Calling (决定动手)

Tool Calling 又称 工具调用。指模型在生成回答时，主动选择并发起对某个 Tool 的调用，而不是只用文字瞎编。

流程可以概括为：

1. 你把可用工具列表告诉模型（工具叫什么、能干什么、需要什么参数）。
2. 模型根据用户问题判断：要不要用工具、用哪一个、参数填什么。
3. 程序在本地或远端真正执行该工具，把结果塞回 Context。
4. 模型再根据工具结果组织最终回复。

例如：

• 用户：“我订单 88392 到哪了？”
• 模型不编造物流信息，而是 Tool Calling：query_order(order_id="88392")。
• 程序查库返回“已发货，预计明天到”，模型再用人话回答你。

Tool Calling 是 Agent 能“动手”的核心机制；没有这一步，Tools 只是摆设。

Function Calling (工具调用的标准说法)

Function Calling 又称 函数调用。本质和 Tool Calling 是一类能力：让模型输出结构化的“要调用哪个函数、传什么参数”，由程序去执行。

之所以有两个名字，主要来自工程习惯：

• Function Calling：早期由 OpenAI 等 API 推广的说法，常和 JSON Schema 形式的 functions / tools 字段一起出现。
• Tool Calling：更通用的说法，强调“工具”而不限于编程里的 function；MCP、各类 Agent 框架里更常见。

可以简单记：Function Calling ≈ Tool Calling 的一种产品/接口命名，在 Mastra 等框架里你配置的都是 Tool，底层同样是“模型选工具 → 运行时执行 → 结果回灌”。

例如（模型返回的结构化意图）：

{
  "name": "get_weather",
  "arguments": { "city": "北京" }
}

你的代码收到后调用真实的 get_weather，再把返回值交给模型。

RAG (先查资料再回答)

RAG 全称 Retrieval-Augmented Generation，又称 检索增强生成。在让模型回答之前，先从你自己的知识库里检索相关片段，再和问题一起交给模型生成答案。

毕业生脑子里的知识是训练时灌进去的，可能过时、也可能没有你公司的内部文档。
RAG 相当于：先让他去图书馆（向量数据库、文档库）按关键词/语义搜几页书，把相关段落复印到 Context 里，再让他读着手头资料回答。

典型步骤：

1. 切分与入库：把 PDF、Wiki、代码说明等切成块，做成可检索的索引（常用向量嵌入）。
2. 检索：用户提问时，找出与问题最相关的若干片段。
3. 增强生成：把片段 + 用户问题一起作为 Context，让 LLM 生成答案（并尽量引用依据）。

例如：

• 没有 RAG：问“我们公司 2025 年假政策？”模型只能泛泛而谈或胡编。
• 有 RAG：从 HR 文档里检索到《休假制度》第 3 条，再基于原文准确回答。

RAG 适合私有、专业、常更新的知识；和 Tool Calling 互补：RAG 偏“读文档”，Tool 偏“办事”（下单、发邮件、改数据库）。

MCP (统一标准)

MCP 又称 模型上下文协议（Model Context Protocol）。它是一个用于 LLM 与外部世界交互的标准协议。

在 MCP 出现前，让 LLM 连接一个新工具很麻烦，开发者需要为不同的 LLM 和工具做专门适配，好比每买一个电子设备，就得配一个专用充电器。
MCP 定义了一个通用标准：只要工具和客户端都支持 MCP，它们之间就可以“即插即用”。

例如：

• 你的 LLM / Agent 运行时就像一个带 USB-C 接口的电脑。
• 各种支持 MCP 的服务（如 Gmail、Slack、数据库、浏览器调试）就像 U 盘、鼠标、显示器。
• 你随时可以把一个 MCP 服务“插”到 Agent 上，Agent 立刻多一批标准化工具可用。

MCP 极大地降低了 AI 连接万物的成本，是构建复杂 Agent 的关键基础设施。

Agent (自主行动者)

Agent 又称 智能体。它是一个能够根据目标自主规划、调用工具、多步执行直到完成任务的实体。

你可以理解：给“大学毕业生”配上了厨具、食谱、手机 App 和记事本，他就相当于一位能上岗的厨师兼管家。
你跟他说“小伙子，帮我做一盘美味的鱼香肉丝！”，他会自己查食谱、买食材、按步骤操作、装盘端上来。

例如：

• 你的 Prompt：“小伙子，帮我做一盘美味的鱼香肉丝！”
• Agent 的自主操作：
  • 查食谱，找到鱼香肉丝的做法。
  • 调用购物工具购买鱼、肉、调料等。
  • 按步骤处理食材、烹饪。
  • 把结果（完成报告或成品说明）交给你。

Agent 就是让 LLM 从只会回答的“参谋”，变成能完成任务的“智能管家”。它通常 = LLM + Prompt/Context + Tools +（可选）Memory + RAG + 循环执行逻辑。

Agent Loop (思考—行动—再思考)

Agent Loop 又称 智能体循环。Agent 不是“想一次就结束”，而是反复：想一步 → 调工具或查资料 → 看结果 → 再想下一步，直到任务完成或达到步数上限。

像管家做菜：

1. 想：先查有没有鱼香肉丝食谱。
2. 动：调用搜索工具 / RAG 拿到食谱。
3. 观察：食谱里缺木耳，家里没有。
4. 再想再动：调用购物工具下单，或问你“能否用香菇代替？”
5. 重复直到菜做好或他判断无法继续。

和一次性问答的区别：

• 普通聊天：用户一句 → 模型一句，结束。
• Agent Loop：用户一个目标 → 多轮内部推理与 Tool Calling → 最终给你一个结论或交付物。

框架（如 Mastra）里的 maxSteps、停止条件，就是在限制 Loop 别无限跑下去。

Workflow (事先画好的流程图)

Workflow 又称 工作流。把完成任务拆成多个有顺序的步骤（甚至分支、并行），由程序按既定编排执行；每一步可以是固定逻辑，也可以交给 Agent/LLM。

和 Agent Loop 的对比：

• Agent Loop：目标导向，路径不固定，模型自己决定下一步调用什么工具。
• Workflow：路径相对固定，像工厂流水线：先审核 → 再生成 → 再发邮件，步骤和顺序在代码里写清楚。

例如“新员工入职”Workflow：

1. 从 HR 系统拉取员工信息（工具/API）。
2. 用 LLM 根据模板生成欢迎邮件草稿。
3. 人工或规则节点审批。
4. 调用邮件工具发送。

适合流程稳定、要审计、要强控制的场景；复杂探索型任务更适合 Agent + Agent Loop。实际项目里二者常组合：大流程用 Workflow，某一步里嵌一个带 Agent Loop 的子任务。

---

总结（一张关系图）：

你是老板；Prompt 是你下达的任务；Context 是经理桌上本次能看到的全部材料；Memory 是经理的档案柜（跨天还能翻）；LLM 是经理的智慧脑袋；Tools 是办事用的软件和电话；Tool Calling / Function Calling 是经理真正拨号、下单的动作；RAG 是动手前先派人去图书馆复印资料；MCP 保证各种软件都是统一接口、即插即用；Agent 是能自己规划干活的经理；Agent Loop 是经理反复“想—干—再看”的工作方式；Workflow 是公司事先定好的标准流程，和经理的即兴发挥配合使用。