[{"content":"刚接触 AI 时，很容易听到这些说法：\n“我在用 DeepSeek。” “豆包也是一个大模型。” “Codex 和 Claude Code 哪个模型更强？” “Agent 和大模型有什么区别？” “GPT、Claude、DeepSeek 都属于 LLM 吗？” 这些说法有时正确，有时又不够准确。根本原因是：我们经常把公司、模型、应用、开发平台和 Agent 产品混在一起讨论。\n本文尝试把这些概念放回各自的位置。\n一、先记住这五个层次 理解 AI 产品，最重要的不是背名字，而是先分清下面五层：\n厂商或品牌 ↓ 研发 模型 ↓ 提供 API / 模型服务 ↓ 被集成到 应用或 Agent ↓ 使用 工具、文件、浏览器、代码仓库和业务系统 以 OpenAI 为例：\nOpenAI 厂商 ├── GPT 系列 模型 ├── OpenAI API 模型服务接口 ├── ChatGPT 通用 AI 应用 └── Codex 编程 Agent 同理，字节跳动、DeepSeek、Anthropic 等厂商，也分别提供模型、API 和面向用户的应用。\n二、什么是 AI 模型？ 模型可以理解为 AI 系统中的“能力引擎”。它经过大量数据训练，可以根据输入计算并生成输出。\n不同模型可能擅长不同任务：\n文本理解与生成 逻辑推理 编写代码 识别图片 生成图片或视频 语音识别与合成 向量化和语义检索 因此，“模型”是一个大类，LLM 只是模型中的一种。\n三、什么是 LLM？ LLM 是 Large Language Model 的缩写，中文通常称为“大语言模型”。\n它主要处理语言相关任务，例如：\n回答问题 总结文章 翻译文本 编写代码 提取结构化信息 根据上下文推理 GPT、Claude、DeepSeek、Gemini、Qwen 等模型系列，都可以包含 LLM。\n不过现在很多模型已经不只处理文字，还可以理解图片、音频和视频。这类模型通常称为多模态模型。日常交流中，人们仍然可能宽泛地把它们称为“大模型”或 LLM。\n可以简单理解为：\nAI 模型 ├── 大语言模型 ├── 多模态模型 ├── 图像生成模型 ├── 视频生成模型 ├── 语音模型 └── Embedding 等其他模型 四、模型和 AI 应用有什么区别？ 模型是底层能力，AI 应用是用户真正使用的软件。\n模型 ≈ 发动机 AI 应用 ≈ 一辆完整的汽车 仅有模型通常还不够。一个完整应用还可能提供：\n聊天界面 文件上传 联网搜索 历史会话 知识库 语音交互 图片生成 工具调用 账号、权限和计费 同一个应用也不一定永远只使用一个模型。它可以根据任务、套餐或用户选择切换不同模型。\n反过来，同一个模型也可以被多个不同应用通过 API 调用。\n五、豆包到底是什么？ “豆包”在不同语境中可能指两类东西。\n1. 豆包应用 普通用户手机或网页上使用的“豆包”，是一个完整的 AI 助手应用。它提供聊天、搜索、语音、创作等用户功能。\n2. 豆包大模型 开发者讨论的“豆包模型”，通常指字节跳动的模型系列。企业或开发者可以通过火山引擎的模型服务平台调用这些模型。\n因此，下面两句话可能分别指不同对象：\n“我打开豆包问了一个问题” → 豆包应用 “系统后端接入了豆包模型” → 豆包大模型或模型 API 豆包不是单纯等于一个模型名称，而是同时覆盖了面向用户的产品品牌和一系列底层模型服务。\n六、DeepSeek 到底是什么？ “DeepSeek”同样是一个多义名称，可能表示：\n公司或品牌：研发并提供相关模型与服务的团队。 模型系列：不同用途和能力的 DeepSeek 模型。 网页或手机应用：普通用户直接聊天的 AI 助手。 API 服务：开发者通过 API Key 调用模型的接口。 所以“使用 DeepSeek”至少可能有三种方式：\n在 DeepSeek App 中聊天 通过 DeepSeek API 调用模型 在 Dify、Codex 等其他工具中配置 DeepSeek 作为底层模型 第三种情况尤其重要：上层应用和底层模型可以来自不同厂商。\n例如，一个编程 Agent 的界面和工具能力由 A 公司提供，但底层推理模型可能来自 B 公司。此时，不能只看到模型名称就把整个应用也当成该模型厂商的产品。\n七、什么是 Agent？ 普通的模型调用通常是：\n用户输入 → 模型生成回答 Agent 则会在模型外面增加目标、工具、上下文和执行循环：\n接收目标 ↓ 分析与规划 ↓ 选择并调用工具 ↓ 观察工具结果 ↓ 继续执行或调整计划 ↓ 完成任务 一个 Agent 通常由这些部分组成：\n模型：理解需求、推理并作出决策。 指令：规定目标、角色、规则和边界。 工具：搜索网页、读写文件、执行代码、调用 API 等。 上下文或记忆：保存任务过程中的信息。 编排逻辑：控制模型与工具之间的循环。 权限与安全机制：限制 Agent 可以执行的动作。 因此：\nAgent 不是另一种和 LLM 并列的模型，而是以模型为核心，组合工具和执行流程形成的任务系统。\n可以用一个简单类比：\nLLM：会思考和表达的大脑 工具：可以操作外部世界的手脚 Agent：带着目标，能调动大脑和手脚完成任务的系统 八、聊天机器人和 Agent 有什么区别？ 传统聊天机器人主要目标是“给出回答”，Agent 更强调“完成任务”。\n对比项 普通聊天应用 Agent 主要产物 一段回答 一个完成的任务或可验证结果 工具使用 可能没有或较少 通常可以调用多种工具 执行过程 一问一答 可以多步骤规划、执行和调整 外部操作 通常较弱 可以操作文件、代码、网页或业务系统 自主程度 相对较低 相对较高，但仍应受权限控制 不过二者并没有绝对边界。现在很多聊天应用也逐渐加入搜索、文件分析和工具调用能力，开始具备 Agent 特征。\n九、什么是编程 Agent？ 编程 Agent 是专门面向软件开发任务的 Agent。\n它不仅能在聊天框中生成代码，还可以在获得权限后：\n阅读整个代码仓库 搜索函数和调用关系 修改多个文件 执行命令 运行测试和分析错误 查看 Git 差异 修复缺陷 进行代码审查 与 GitHub、GitLab 或其他开发工具协作 普通代码模型更像“告诉你代码应该怎么写”，编程 Agent 更像“进入项目后直接把任务做完并验证结果”。\n十、Codex 是什么？ Codex 是 OpenAI 面向软件开发的编程 Agent，而不是某一个固定模型的同义词。\n它可以通过桌面应用、命令行、IDE 等形态工作，结合模型与工具来完成代码阅读、编辑、调试、测试和审查等任务。\n可以把 Codex 拆成两层理解：\nCodex：编程 Agent / Agent 运行与工具环境 ↓ 使用 OpenAI 模型或其他已配置模型：负责理解和推理 这也是为什么“Codex 用什么模型”和“Codex 是什么”是两个不同问题：\nCodex 是执行软件工程任务的 Agent 产品和工作环境。 模型是 Codex 在某次任务中使用的推理引擎。 在不同配置、版本或使用方式下，Codex 可以使用不同模型，因此不宜简单地说“Codex 就是某个模型”。\n十一、Claude Code 是什么？ Claude Code 是 Anthropic 提供的编程 Agent。它可以在开发环境中读取代码、编辑文件、执行命令，并围绕软件工程任务持续工作。\n同样需要区分：\nClaude：Anthropic 的模型系列或 AI 品牌 Claude 应用：面向用户的通用 AI 助手 Claude Code：面向软件开发的编程 Agent 因此，Claude Code 也不等于某一个 Claude 模型。它是一个使用模型、工具和 Agent 循环完成编程任务的产品。\n十二、Codex 和 Claude Code 属于模型吗？ 不应把它们简单归类为模型。\n更准确的分类是：\n名称 更准确的类别 说明 LLM 模型类别 处理和生成语言的大型神经网络 GPT 模型系列 OpenAI 的模型系列名称 Claude 模型系列与产品品牌 具体含义取决于上下文 DeepSeek 公司、模型系列、应用或 API 品牌 同一个名字覆盖多个层次 豆包 AI 应用与模型品牌 既有用户产品，也有底层模型服务 Agent 系统形态 使用模型、工具和流程完成目标 Codex 编程 Agent OpenAI 的软件开发 Agent Claude Code 编程 Agent Anthropic 的软件开发 Agent Dify AI 应用开发平台 用于编排模型、知识库、工作流和 Agent MCP 协议 让 AI 应用以标准方式连接外部能力 十三、模型、Agent、工具和 MCP 如何组合？ 把上一篇 MCP 的内容接进来，完整关系可以表示为：\n用户 ↓ AI 应用 / Agent Host（Dify、Codex、Claude Code 等） ├── 调用模型：理解、推理、选择动作 ├── 管理上下文：保存任务相关信息 └── 调用工具：执行具体操作 ↓ MCP Client ↓ MCP 协议 MCP Server ↓ GitLab、数据库、本地文件等外部系统 这里每一层解决的问题不同：\n模型解决“怎么理解和推理”。 Agent解决“怎么围绕目标持续行动”。 工具解决“怎么真正执行操作”。 MCP解决“怎么用统一协议连接外部能力”。 应用界面解决“用户怎么方便地使用这些能力”。 十四、API 和 API Key 又是什么？ 如果把模型集成到自己的程序中，通常不会直接使用厂商的聊天网页，而是调用模型 API。\n自己的应用 ↓ API 请求 模型服务平台 ↓ 模型 API 是程序之间约定的调用接口。 API Key 是调用服务时的身份凭证。 模型名称或 Model ID 用于指定本次想调用哪个模型。 例如，在 Dify 中配置 DeepSeek 时，需要填写 DeepSeek API Key，并选择有权限使用的模型。这并不意味着 Dify 变成了 DeepSeek，而是 Dify 把 DeepSeek 作为底层模型服务之一。\n十五、几个常见误区 误区一：所有 AI 产品都是大模型 不准确。豆包 App、ChatGPT、Codex、Claude Code 等都是包含模型在内的完整产品或 Agent，不只是裸模型。\n误区二：Agent 是一种更强的大模型 不准确。Agent 是系统形态。它可能使用一个或多个模型，并组合工具、记忆和执行流程。\n误区三：Codex 就是一个代码模型 不准确。Codex 更适合被理解为编程 Agent；它使用模型完成推理，同时具备读取项目、修改文件和执行工具的能力。\n误区四：Claude 和 Claude Code 是同一个东西 不准确。Claude 通常指模型系列或通用 AI 品牌，Claude Code 是面向开发工作的 Agent 产品。\n误区五：一个应用只能使用一个模型 不一定。很多 AI 应用和开发平台都支持选择或配置多个模型。\n误区六：模型越强，Agent 就一定越好 不一定。Agent 的效果还取决于工具设计、提示词、上下文管理、权限、编排逻辑和验证机制。\n十六、如何快速判断一个新名词属于哪一层？ 遇到新的 AI 名称时，可以依次问五个问题：\n它是一家公司或品牌吗？ 它是一个可以通过 Model ID 调用的模型吗？ 它是一个有界面、账号和功能的应用吗？ 它能否自主调用工具并执行多步骤任务？ 它是用于连接、开发或部署模型的平台与协议吗？ 同一个名字可能同时对应多个答案，这时必须结合上下文判断。\n例如：\n“DeepSeek 发布了新模型” → 公司或品牌 “接口使用 DeepSeek 模型” → 模型或 API 服务 “我在 DeepSeek 里问了一下” → 网页或手机应用 “Claude 的推理能力不错” → Claude 模型 “用 Claude Code 修改项目” → 编程 Agent 十七、一句话总结 如果只记住一套关系，可以记住下面这段：\nLLM 是负责理解和生成语言的模型；模型是 AI 系统的能力引擎；豆包和 DeepSeek 等名称可能同时指品牌、模型、应用或 API；Agent 是组合模型、工具和执行流程来完成目标的系统；Codex 与 Claude Code 是面向软件开发的编程 Agent，而不是单一模型。\n最终，现代 AI 应用往往是这样工作的：\n用户提出目标 ↓ Agent 调用模型进行理解与决策 ↓ Agent 调用工具执行操作 ↓ 根据结果继续行动或完成任务 模型决定“能不能想明白”，工具决定“能不能做得到”，而 Agent 决定“能不能围绕目标把事情做完”。\n参考资料 OpenAI：Code generation 与 Codex Anthropic：Claude Code 文档 DeepSeek API 文档 火山引擎产品列表：豆包大模型与相关 AI 产品 ","permalink":"https://raaan.com.cn/blog/posts/ai-glossary/","summary":"一张图分清 LLM、Agent、MCP、Codex、Claude Code 这些高频 AI 名词——它们各自是什么、谁包含谁、怎么协作。","title":"AI 名词扫盲：LLM、Agent、豆包、DeepSeek、Codex、Claude Code 到底是什么？"},{"content":"在使用 Dify、Claude、Cursor 等 AI 应用时，我们经常会看到“配置 MCP”“添加 MCP Server”“选择 MCP 工具”等概念。\n这些名字看起来很复杂，但 MCP 解决的核心问题其实很简单：\n让 Agent 能够用统一的方式发现和调用外部工具。\n本文从实际使用场景出发，梳理 Agent、MCP Client、MCP Server、外部工具以及 API Key 之间的关系。\n一、为什么 Agent 需要外部工具？ 大模型擅长理解语言、分析问题和生成内容，但它本身通常无法直接操作现实中的业务系统。\n例如，仅靠大模型本身无法可靠地完成这些事情：\n查询 GitLab 项目中的 Issue 创建 Jira 缺陷 查询数据库中的订单 获取实时天气 读取企业内部文档 调用业务系统创建退款单 这些能力需要由外部系统提供。对于 Agent 来说，可以调用的具体能力就是“工具”。\n例如，一个 GitLab 工具集合可能包含：\nlist_issues：查询 Issue create_issue：创建 Issue get_merge_request：查询合并请求 create_merge_request：创建合并请求 大模型负责判断“什么时候该用哪个工具”，真正的数据查询或业务操作则由工具完成。\n二、外部工具和 MCP Server 是什么关系？ 可以把 MCP Server 理解成一个工具箱，外部工具则是工具箱中的具体工具。\nMCP Server（工具箱） ├── list_issues（查询 Issue） ├── create_issue（创建 Issue） ├── get_project（查询项目） └── create_merge_request（创建合并请求） MCP Server 主要负责：\n告诉客户端自己提供了哪些工具。 描述每个工具的用途和参数格式。 接收工具调用请求。 执行背后的函数或调用第三方 API。 将执行结果返回给客户端。 因此，外部工具是具体能力，MCP Server 是按照 MCP 标准对外发布和执行这些能力的服务。\n三、Agent 是怎么调用 MCP 工具的？ 严格来说，并不是大模型直接连接 MCP Server，而是 Agent 所在的宿主应用提供 MCP Client。\n完整调用链如下：\n用户 ↓ 自然语言指令 Agent / 大模型 ↓ 判断需要调用哪个工具 MCP Client（位于 Dify、Claude、Cursor 等宿主应用中） ↓ 使用 MCP 协议通信 第三方 MCP Server ↓ 调用函数、数据库或第三方 API GitLab、Jira、数据库等外部系统 各组件的职责分别是：\n1. 大模型 大模型负责理解用户意图、选择合适的工具、生成调用参数，以及把工具返回的数据整理成自然语言。\n2. Agent Agent 负责组织整个执行过程，包括模型推理、工具选择、工具调用、结果观察以及必要时的重复调用。\n3. MCP Client MCP Client 通常是 Dify、Claude、Cursor 等宿主应用中的组件。它负责：\n连接 MCP Server 获取工具列表及工具定义 向 MCP Server 发送工具调用请求 接收 MCP Server 返回的结果 4. MCP Server MCP Server 把现有函数、服务或第三方 API 封装成符合 MCP 标准的工具，并负责执行这些工具。\n5. 外部系统 外部系统是真正保存数据或完成业务操作的地方，例如 GitLab、Jira、数据库、文件系统和企业内部平台。\nMCP Host、MCP Client、MCP Server 的三层关系 MCP 的完整架构还可以概括为三个角色：\nMCP Host：承载 AI 和 Agent 的应用，例如 Dify、Claude Desktop、Cursor。 MCP Client：内嵌于 Host，负责按照 MCP 协议连接 Server、发现并调用能力。 MCP Server：向 Client 提供 Tools、Resources、Prompts，并对接本地或远程系统。 需要注意：MCP Client 主要负责协议通信；理解用户意图和决定调用哪个工具，通常由大模型及 Agent 编排逻辑完成。\n四、以 GitLab MCP 为例 假设 GitLab 官方或第三方提供了一个 GitLab MCP Server，它对外暴露查询 Issue、创建 Issue、读取项目等工具。\n用户向 Agent 提出：\n帮我查询项目中尚未关闭的 Issue。\n背后的过程大致如下：\nMCP Client 连接 GitLab MCP Server，并获取其工具列表。 GitLab MCP Server 返回 list_issues 等工具的名称、说明和参数定义。 大模型根据用户的问题，选择 list_issues 工具。 大模型生成项目名称、Issue 状态等调用参数。 MCP Client 按照 MCP 协议把请求发送给 GitLab MCP Server。 GitLab MCP Server 使用 GitLab Access Token 调用 GitLab API。 GitLab API 返回 Issue 数据。 MCP Server 将数据返回给 MCP Client。 Agent 再让大模型把数据整理成用户容易理解的回答。 因此，可以准确地描述为：\nAgent 通过宿主平台中的 MCP Client，按照 MCP 协议调用第三方提供的 MCP Server；MCP Server 再通过 API 或内部代码操作第三方系统。\n五、已有工具时，是否需要编写 MCP Server？ 如果已经有一个函数或业务接口，并希望多个 AI 客户端都能以统一方式调用它，可以在外面封装一层 MCP Server。\n例如已有函数：\ndef query_order(order_id): return {\u0026#34;order_id\u0026#34;: order_id, \u0026#34;status\u0026#34;: \u0026#34;paid\u0026#34;} 将它包装成 MCP 工具后，可以表示为：\n订单 MCP Server └── query_order ├── 用途：根据订单号查询订单状态 ├── 参数：order_id └── 实际执行：调用原有 query_order 函数 之后，支持 MCP 的 Agent 就能发现并调用 query_order。\n通常没有必要为每一个工具单独启动一个 MCP Server。更常见的方式是按照业务领域分组：\n订单 MCP Server ├── query_order ├── cancel_order ├── query_refund └── create_refund 是否需要封装成 MCP Server，要根据使用场景判断：\n现有能力 推荐接入方式 已经是 MCP Server 直接配置连接 Python、Java 等本地函数 可封装为 MCP Server 已有 HTTP API 可封装为 MCP Server，也可直接通过 HTTP/OpenAPI 工具接入 只给一个 Dify 应用使用 使用 Dify 自定义工具可能更简单 希望同时供 Dify、Claude、Cursor 等使用 更适合封装为 MCP Server MCP 不是唯一的工具接入方案。它最大的价值是提供统一标准，减少不同 AI 平台重复适配的成本。\n六、MCP 中为什么还会出现 API Key？ 配置 MCP 时经常也会看到 API Key，需要注意它可能和大模型 API Key 完全不同。\n大模型 API Key 用于授权 Dify 等应用调用模型服务，例如：\nGemini API Key OpenAI API Key DeepSeek API Key 通义千问 API Key 它解决的是“能不能调用大模型”的问题。\nMCP 服务的 API Key 或 Token 用于授权 MCP Client 访问 MCP Server，或者让 MCP Server 访问背后的第三方系统。\n例如，GitLab MCP Server 可能需要 GitLab Access Token，才能读取对应项目或创建 Issue。\n它解决的是“能不能访问和操作外部工具”的问题。\n可以简单记忆：\n大模型 API Key：进入模型的钥匙 MCP API Key：连接 MCP 服务的钥匙 GitLab Token：操作 GitLab 资源的钥匙 具体实现中，MCP Server 的访问凭证和第三方系统的访问凭证可能是同一个，也可能是两层不同的凭证，取决于服务的架构设计。\n七、Function Calling 和 ReAct 有什么区别？ 在 Dify Agent 中配置 MCP 工具时，通常还需要选择工具调用策略。\nFunction Calling 模型直接返回要调用的工具和结构化参数，平台执行工具后再将结果交给模型。\n适合：\n单步骤任务 工具和参数比较明确 更关注速度和稳定性 ReAct 模型按照“判断—行动—观察结果”的方式循环执行，可以根据上一次工具结果继续选择下一个工具。\n适合：\n多步骤任务 需要组合多个工具 需要根据中间结果调整计划 可能需要重试的任务 初次接入时通常可以先使用 Function Calling；当任务需要多步推理和连续调用工具时，再考虑 ReAct。\n八、在 Dify 中接入 MCP 的整体过程 以 Dify 为例，整体配置过程可以概括为：\n准备一个可访问的 MCP Server。 确保部署 Dify 的主机能够访问 MCP Server 的地址和端口。 在 Dify 中安装支持 MCP 的连接插件和 Agent 策略。 新建 Chatflow，并添加 Agent 节点。 给 Agent 配置一个已经接入的大模型。 配置 MCP Server 地址及认证信息。 从 MCP Server 提供的工具列表中选择需要授权给 Agent 的工具。 在系统提示词中说明什么场景下应该调用什么工具。 运行并验证 Agent 能否正确选择工具、传递参数并获得结果。 需要特别注意：配置成功不仅要求页面上填写正确，还要求 Dify 所在网络能够访问 MCP Server。\n九、总结 理解 MCP，可以抓住下面几句话：\n外部工具是某项具体能力，例如查询 Issue 或查询订单。 MCP Server 是提供这些工具的标准化服务。 MCP Client 位于 Agent 的宿主应用中，负责连接和调用 MCP Server。 Agent 和大模型负责理解用户需求并决定调用哪个工具。 MCP Server 负责真正执行工具，并访问 GitLab、数据库等外部系统。 大模型 API Key 和 MCP/第三方系统的认证凭证不是一回事。 最后，可以用一句话概括整个调用链：\n用户向 Agent 提出需求，大模型决定调用工具，宿主应用中的 MCP Client 按照 MCP 协议请求 MCP Server，MCP Server 操作外部系统并把结果返回给 Agent。\n如果把大模型比作“大脑”，那么外部工具就是“手脚”，MCP Server 是“标准化工具箱”，MCP Client 则是 Agent 打开和使用工具箱的方式。\n","permalink":"https://raaan.com.cn/blog/posts/mcp-getting-started/","summary":"MCP 是什么？用一条调用链讲清 Agent、MCP Client、MCP Server 与外部工具之间的关系。","title":"MCP 入门：Agent、MCP Client、MCP Server 和外部工具到底是什么关系？"},{"content":"欢迎来到我的博客。这是第一篇文章，用来验证整条写作流程是否顺畅。\n这套博客的技术选型 环节 用什么 写作 Markdown 生成静态页面 Hugo + PaperMod 主题 源码存放 GitHub 仓库 构建 GitHub Actions 托管 阿里云 ECS + Nginx 选这套的原因很简单：服务器只有 2 核 2G 内存、3 Mbps 带宽，跑不动也不必要跑数据库和动态程序。静态站几乎不占资源，而且页面体积小，3M 带宽下打开很快。\n几个当初容易误解的点 \u0026ldquo;部署\u0026quot;发生在服务器上，不在本地电脑上。 本地只负责写和推，服务器负责对外提供服务。\nSwap 不是内存扩容。 它是磁盘上的一块应急区域，速度比内存慢好几个数量级，作用是在内存峰值时避免进程被系统直接杀掉。\n安全组和系统防火墙是两层。 前者在云平台层面（楼栋门禁），后者在系统里面（入户门锁），两层都放行才能访问。\n写作流程 以后每写一篇，只需要三步：\n在仓库的 content/posts/ 目录新建一个 .md 文件 顶部写上 front matter（标题、日期、标签） 提交，等自动构建完成 就这么多。\n","permalink":"https://raaan.com.cn/blog/posts/hello-world/","summary":"从一台阿里云 ECS 开始，用 Hugo + GitHub Actions + Nginx 搭起这个站点。","title":"第一篇文章：这个博客是怎么搭起来的"}]