CycleUser

大模型相关的场景有很多新名词，有的时候这些新名词会被一些别有用心之徒拿来四处忽悠人。 想要不被忽悠，就有必要先对基本概念有一个简单的了解。 本文以尽量简单易懂的语言，来粗略介绍一下比较基础的术语。

1. LLM（大语言模型）

解释：全称 Large Language Model，是一种基于深度神经网络的“概率预测机”。它阅读了互联网上几乎所有的文本，通过数学计算掌握了语言的规律，核心能力是根据上文预测下一个最可能出现的字或词。
例子：你向 Qwen3-coder 提问：“用 PySide6 写一个统计文本行数的 GUI 程序...”。模型接收到这些字符后，并不是像人类一样“理解”了你的需求，而是开始计算：在“用 PySide6 写一个”后面，接什么词概率最高？在生成了代码框架后，接 import sys 的概率是多少？通过亿万次的这种概率计算，最终拼接出了一段完整的、可运行的代码。
真相：所谓的 LLM 实际上就是一个 “单字接龙高手”。它并不懂逻辑，也不懂编程，它只是看过太多的代码，知道在当前语境下，写出 class MainWindow(QMainWindow): 的概率比写一段菜谱的概率大得多。

2. Prompt（提示词）

解释：提示词，即用户与大模型交互的“指令语言”。因为模型是基于概率预测的，Prompt 的作用就是通过特定的措辞，限定模型的预测范围，使其输出符合预期的结果。
例子：在上述请求中，你写下的“仅使用系统默认主题”、“必须包含注释”、“单文件输出”等要求，就是 Prompt。如果你只说“写个程序”，模型预测的可能性太广，可能会给你一个网页版或者命令行版。加上这些限定词，就像给导弹设定了制导参数，强制模型只能在“PySide6 GUI”和“单文件”这个极窄的概率空间内生成内容。
真相：所谓的 Prompt 实际上就是 “自然语言编程”。以前我们用 C++ 或 Python 给电脑下指令，现在我们用英语或中文给模型下指令。你是程序员，Prompt 就是你的源代码。

3. Context（上下文）

解释：上下文，或者叫“上下文窗口”（Context Window），是模型在每一次生成回答时，能够“看见”和“参考”的信息总量。它包含了之前的对话历史、你上传的文件内容以及当前的 Prompt。
例子：在对话中，你第一轮让它写了代码，第二轮你说“运行报错了，提示找不到模块”。模型之所以知道你说的“运行”是指刚才那个 PySide6 程序，而不是去运行一个跑步机，就是因为它把第一轮的对话作为 Context 一并输入了进去。如果超出了上下文长度限制，模型就会“忘记”最开始的内容。
真相：所谓的 Context 实际上就是模型的 “短期工作记忆” (RAM)。就像金鱼的记忆，或者电脑的内存，断电（会话结束）或者存满了（超出 Token 限制），旧的信息就会被挤出去，模型就再也想不起你十分钟前说过什么了。

4. Memory（记忆）

解释：长期记忆，是为了解决 Context 容量有限且易丢失问题而引入的外部存储机制。它允许模型将关键信息持久化保存，并在需要时检索出来。
例子：假设你是一个偏好“代码必须加类型注解”的用户。如果没有 Memory，你每次开新对话都要强调一遍。有了 Memory，系统会把这条偏好存入数据库。当你下个月再来要求写 PySide6 程序时，模型会先去查库，发现你有这个偏好，于是自动在生成的代码里加上了类型注解，尽管你这次的 Prompt 里并没有提。
真相：所谓的 Memory 实际上就是一个 “外挂数据库”。它不是模型脑子里的东西，而是像我们在电脑里存的记事本文件。模型在回答前先去翻一下记事本，假装自己记得你，其实是现查的。

5. Agent（智能体）

解释：智能体，是一种能够自主感知环境、规划任务、使用工具并执行行动的 AI 系统。它不再是单纯的“问答机器”，而是变成了“办事员”。
例子：当你下达“写一个行数统计器并保存到桌面”的任务时，Agent 不会只吐出代码，而是会进行如下思考循环：
1. 思考: 用户要写代码 -> 我需要调用代码生成工具。
2. 行动: 生成 PySide6 代码。
3. 观察: 代码生成完毕。
4. 思考: 用户要保存文件 -> 我需要调用文件写入工具。
5. 行动: 将代码写入 counter.py。
6. 观察: 写入成功。
7. 回答: “任务完成，文件已在桌面。”
真相：所谓的 Agent 实际上就是一个 “循环脚本” (Loop)。它的核心逻辑是 While (任务未完成) { 思考 -> 调用工具 -> 检查结果 }。它把大模型的智力用在了流程控制上，而不仅仅是文本生成上。

6. RAG（检索增强生成）

解释：检索增强生成 (Retrieval-Augmented Generation)。当模型面对它没学过的私有数据或最新知识时，先去外部知识库里“搜”一下答案，再结合搜到的内容生成回答。
例子：假设 PySide6 昨天刚发布了一个新特性 QNewFeature，模型训练时肯定没见过。当你问“怎么用 QNewFeature？”时，RAG 系统会先去 PySide6 的官方文档库里检索包含 QNewFeature 的段落，把这些段落粘贴到 Prompt 里告诉模型，模型再根据这些现成的资料，“伪装”成它懂的样子给你写出代码。
真相：所谓的 RAG 实际上就是 “开卷考试”。模型本身不会做这道题，但系统允许它先翻书（知识库），找到答案抄在草稿纸上，整理一下再交卷。

7. Search（搜索）

解释：联网搜索。这是一种特殊的“工具”，允许模型通过搜索引擎获取互联网上的实时信息。
例子：你在写程序时问：“PySide6 最新版本是多少？”模型自己是不知道的（它的训练数据截止于过去）。通过 Search 工具，它在后台向 Google 或 Bing 发起请求，抓取搜索结果页面，读取到“6.8.1”这个数字，然后告诉你：“最新版是 6.8.1”。
真相：所谓的 Search 实际上就是 “AI会用搜索引擎”。它把你的问题转换成搜索关键词，把搜索引擎返回的网页文字当作阅读材料，阅读理解后总结给你。

8. Function Calling（函数调用）

解释：函数调用。这是模型输出的一种特殊格式，它不直接输出自然语言，而是输出一个结构化的 JSON 对象，告诉系统“去执行某个函数”。
例子：当你说“运行这个程序”时，模型并不是真的去运行了程序（它只是个文本生成器）。它输出了一行类似 {"function": "run_python_script", "args": {"path": "main.py"}} 的指令。系统的后台代码捕获到这个 JSON，才真正去调用 Python 解释器运行了文件。
真相：所谓的 Function Calling 实际上就是 “API 转换器”。它把人类的口语（“帮我跑一下”）翻译成了电脑能听懂的函数名和参数（JSON），让只会聊天的模型拥有了按按钮的手。

9. MCP（模型上下文协议）

解释：Model Context Protocol（模型上下文协议）。这是一个旨在标准化的“接口规范”，用于连接 AI 模型和各种数据源/工具。
例子：以前，如果你想让 Claude 读取你电脑里的文件，你需要专门写一套代码；想让 ChatGPT 读取，又要写另一套。有了 MCP，你电脑上运行一个“文件系统 MCP 服务器”，无论是 Claude 还是 IDE 里的 AI，只要支持 MCP 协议，插上就能直接读取文件，不用重复造轮子。在我们的 PySide6 例子中，可能有一个 "LocalDev MCP"，直接把本地 Python 环境暴露给 AI，让它可以直接检查语法错误。
真相：所谓的 MCP 实际上就是 AI 界的 “USB 接口标准”。以前连接鼠标、键盘、打印机各有各的接口，现在统统用 USB。MCP 就是让所有的 AI 都能用统一的标准去连接数据和工具，即插即用。

10. LangChain

解释：一个著名的开源开发框架，专门用于开发 LLM 应用。它提供了一套“胶水”代码，把模型、Prompt、内存、索引等组件粘合在一起。
例子：如果你要手写那个 PySide6 生成器，你可能需要写很多代码来管理对话历史、调用 API、解析结果。用 LangChain，你可以写成一条链：Chain = PromptTemplate + LLM + OutputParser。它帮你封装了底层的繁琐逻辑，让你像搭积木一样构建应用。
真相：所谓的 LangChain 实际上就是 “胶水库” (Glue Code)。它没啥黑科技，就是把大家常用的操作封装成了 Python/JS 类库。虽然方便，但有时候也会被吐槽封装得太厚，把简单的问题复杂化了。

11. Workflow（工作流）

解释：工作流。这是将复杂任务拆解成既定的、可视化的步骤序列。与 Agent 的自主规划不同，Workflow 通常是人为设计好的固定流程。
例子：针对“生成 GUI 应用”这个任务，我们可以设计一个 Workflow：第一步【用户输入需求】 -> 第二步【LLM 生成代码】 -> 第三步【代码格式化工具清洗】 -> 第四步【写入文件】。无论用户怎么问，系统都严格按这个 1-2-3-4 的顺序执行，不会跑偏。
真相：所谓的 Workflow 实际上就是 “可视化流程图”。它就像工厂的流水线，每个节点做什么都规定死了。虽然不够灵活，但比 Agent 更稳定、更可控，适合处理标准化的生产任务。

12. Skill（技能）

解释：Skill 是智能体可调用的原子化能力单元，通常以一个独立文件夹中的 SKILL.md 文件进行声明和描述。该文件定义了技能的用途、触发条件、执行规范及约束，使 LLM 能在需要时准确理解并使用它。

例子：系统的配置目录，比如\Home\.opencode\skills中存在一个名为 pyside6-default-gui 的 Skill，其 SKILL.md 内容如下：

---
name: pyside6-default-gui
description: 生成符合以下全部要求的单文件 PySide6 GUI 应用程序：
  - 仅使用 PySide6，不引入其他 GUI 框架；
  - 界面为单一主窗口，不含子窗口或多页面；
  - 所有控件（按钮、文本框、标签等）使用操作系统默认主题；
  - 不设置任何自定义颜色、字体、样式表（即不调用 setStyleSheet、QPalette 等）；
  - 所有类、函数、关键语句必须配有清晰的中文注释；
  - 模块、类和函数需包含 docstring 文档说明；
  - 输出为一个完整的、可直接运行的 .py 文件。
version: 1.0
---

当用户请求“用 PySide6 写一个简单的 GUI 工具”且未指定样式时，应优先使用本技能。

所谓的 Skill 实际上就是一段文档，你来交代清楚让模型做一件事情要如何做，做到什么样子，符合什么规范。 上面这个例子中就是明确限定了代码风格、技术栈与文档标准，确保生成的 GUI 应用简洁、合规、可维护，且无需额外配置即可在各平台原生运行。 智能体在接收到相关任务时，会依据此描述生成符合规范的代码，而非自由发挥。

13. SubAgent（子智能体）

解释：子智能体。为了解决单个 Agent 能力过于泛化的问题，将复杂任务拆分给多个拥有特定人设和工具的“专家”Agent。
例子：在开发这个 PySide6 程序时，主 Agent 觉得自己一个人搞不定，于是它招募了两个手下：一个“产品经理 Agent”负责把你的模糊需求细化成功能列表；一个“资深程序员 Agent”只负责写代码。主 Agent 负责协调，先让产品经理分析，把结果传给程序员写，最后自己验收。
真相：所谓的 SubAgent 实际上就是 “层级化外包”。大模型也是术业有专攻的，通过 Prompt 赋予不同的角色（专家），让它们各司其职，往往比一个“全能神”做得更好。

这玩意并没有什么玄学的，拿这些东西糊弄人的都比较坑，大家都先了解一下，就可以避免被人忽悠。