1. 从一次“AI 答非所问”说起这七个词到底卡在哪刚接触大模型应用开发时最容易遇到的不是代码报错而是概念打架。你打开一份框架文档满屏都是 Prompt、LLM、Agent、Agent Skills、Workflow、MCP、Tool每个词单看都认识连起来就不知道谁管谁。我见过不少朋友把 MCP 当成某个模型的名字把 Agent Skills 和 Workflow 混着用结果配置写完跑起来模型要么不调用工具要么调用了却传错参数。这篇就按“一个真实请求从发出到完成”的顺序把这七个高频术语拆开。你可以把它当成一份术语对照表加一段可运行的最小示例先搞清楚每个词在链路里的位置再动手发一次请求看它们怎么协作。先给一个生活化类比后面所有解释都围绕它展开。假设你要开一家餐厅LLM 是后厨那位厨艺很好但只会做菜的师傅你给他什么食材和菜谱他就出什么菜。Prompt 是你递给他的点菜单写得越清楚他做得越接近你要的。Tool 是厨房里的烤箱、榨汁机、收银机师傅自己不会凭空变出这些能力得有人给他配。MCP 是厨房统一的插座标准不管什么牌子的电器插上就能用不用每次重新接线。Agent 是餐厅经理他不做菜但他会看订单、安排师傅、调用设备、处理突发情况。Agent Skills 是经理脑子里的“专项经验包”比如“处理客诉的流程”“旺季排班经验”。Workflow 是整条出餐流水线从接单到上菜分几步、哪步并行、哪步要人复核。这七个词不是并列关系而是分层关系。搞混层级配置就会写错地方。下面逐个拆每个都配一个能跑的最小例子。2. TaoToken 前置准备把 LLM 和 Tool 的调用链路先打通在讲概念之前得先有一个能实际发请求的环境否则所有术语都停留在纸面。我用 TaoToken 作为统一入口来演示原因是它把模型对话、API Key 管理、接入文档放在同一个控制台里适合边看概念边验证。你需要先拿到三样东西Base URL、API Key、Model ID。这三件套是后面所有配置的基础缺一个请求就会失败。Base URL 用https://taotoken.net/api注意这里不加任何查询参数。API Key 在控制台的 API Keys 页面创建创建后只显示一次复制保存好。Model ID 根据你要验证的模型填比如对话类模型填对应的模型标识。如果你用的是 Claude Code 这类编码工具配置方式略有不同需要设置 Anthropic 兼容的 Base URL 和 Key。具体路径在接入文档里有说明我建议先按文档把环境变量配好再回来理解概念这样每讲一个词你都能立刻发请求验证。这里有个容易踩的坑很多人把 Base URL 写成带/v1或带 UTM 参数的地址结果请求 404。记住 API 地址就是https://taotoken.net/api不要自己拼路径。另外 Key 不要硬编码在代码里提交到仓库用环境变量或者本地配置文件。准备好这三件套后先别急着写复杂逻辑。我们先用最原始的方式发一次请求看看 LLM 单独工作是什么样再逐步加上 Tool、Agent 这些层。这样你能清楚看到每一层加进去之后请求和响应发生了什么变化。3. 可复制配置Prompt、LLM、Tool 三件套的最小 JSON 与 settings 片段这一节给可直接复制的配置。先看最基础的 LLM 调用它只需要 Base URL、Key、Model ID 和一段 Prompt。curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: your-model-id, messages: [ {role: system, content: 你是一位严谨的代码审查专家逐步指出问题并给出重构代码。}, {role: user, content: 审查这段代码def add(a,b): return ab} ] }这段里messages数组就是 Prompt 的载体。system角色是约束和角色设定user是具体任务。LLM 收到后只做一件事预测下一个 token把回答补全。它不会去查数据库也不会调用外部接口。接下来加 Tool。Tool 的本质是一段 JSON Schema 描述告诉模型“有这么个函数参数是什么”。模型不会真的执行它而是输出一个“我要调用这个函数”的结构化结果由你的代码去执行。{ name: search_web, description: 实时搜索互联网返回摘要结果, parameters: { type: object, properties: { query: {type: string, description: 搜索关键词}, num_results: {type: integer, description: 返回条数默认 5} }, required: [query] } }把这段放进请求的tools字段模型在需要实时信息时就会返回tool_calls。你的后端拿到tool_calls执行真实搜索再把结果作为tool角色消息塞回对话模型继续生成最终回答。这就是 Tool 的完整闭环。如果你用 Claude Code 或 Cline 这类工具配置通常写在 settings 文件里。以 Claude Code 为例需要设置ANTHROPIC_BASE_URL和ANTHROPIC_API_KEYBase URL 指向 TaoToken 的 Anthropic 兼容入口Key 用控制台创建的 KeyModel ID 填你要用的模型。三件套齐全工具才能正常发起请求。MCP 的配置则是另一种形态它通常是一个 JSON 文件描述要连接哪些 MCP Server。比如{ mcpServers: { github: { command: npx, args: [-y, modelcontextprotocol/server-github], env: {GITHUB_TOKEN: your-token} } } }这段配置的意思是启动一个 GitHub MCP ServerAgent 就能通过标准协议读取仓库、提交评论。注意 MCP Server 是独立进程Agent 通过协议和它通信而不是把逻辑写死在 Agent 里。Agent Skills 的配置更轻通常是一个文件夹加一个SKILL.md。文件里写清楚技能名称、描述、触发条件和操作步骤。Agent 在规划任务时先读描述判断要不要加载这个技能需要时才读完整内容这样节省上下文。Workflow 的配置则体现在编排层比如用 LangGraph 定义节点和边或者用 MCP Prompts 定义可复用的流程模板。它管的是“先做什么、再做什么、哪步并行、哪步要人确认”。把这五类配置放在一起看层级就清楚了Prompt 和 LLM 是最内层Tool 和 MCP 是能力接入层Agent Skills 是知识层Workflow 是编排层Agent 是把这些串起来的执行者。4. 验证请求一次真实调用看七个概念各在哪一环配置写完发一次真实请求观察响应结构就能把概念对应到具体字段。假设我们发一个带 Tool 的请求用户问“帮我查一下今天有什么 AI 新闻”。请求体里带上tools定义。响应可能长这样{ choices: [ { message: { role: assistant, content: null, tool_calls: [ { id: call_abc123, type: function, function: { name: search_web, arguments: {\query\:\AI 新闻\,\num_results\:5} } } ] } } ] }看到tool_calls就说明 Tool 这一层生效了。模型没有直接编答案而是决定调用搜索工具。你的代码执行搜索后把结果作为tool消息追加{role: tool, tool_call_id: call_abc123, content: 搜索结果摘要...}再发一次请求模型这次会基于搜索结果生成自然语言回答。整个链路是Prompt 触发 LLM 推理LLM 决定调用 ToolTool 返回结果LLM 整合输出。如果换成 Agent链路会多一层规划。Agent 收到“帮我做一份竞品分析报告”这种模糊目标会先拆成子任务搜索竞品信息、整理功能对比、生成报告。每个子任务可能调用不同 Tool中间结果存到 Memory遇到错误会重试或换策略。你看到的不是一次tool_calls而是一串连续的调用和反思。Agent Skills 在这一环的作用是当 Agent 判断当前任务属于“前端调试”时加载对应的SKILL.md按里面写的检查清单逐项排查而不是漫无目的地试。它提供的是领域知识和流程不直接执行外部操作。MCP 在这一环的作用是Agent 不需要为每个外部系统写适配代码只要连上对应的 MCP Server就能发现可用工具并调用。比如连上 GitHub MCP Server 后Agent 自动知道有“读取 PR”“提交评论”这些能力。Workflow 在这一环的作用是定义整个流程的骨架。比如客服场景先分类问题再并行查订单和库存需要退款时调用支付 Tool最后记录日志并等待人工审批。Workflow 决定节点顺序和分支条件Agent 在节点内自主决策。验证时重点看三件事响应里有没有tool_calls说明 Tool 层通了多轮请求之间上下文有没有正确传递说明 Memory 和 Workflow 在起作用换一个需要领域知识的任务看 Agent 有没有加载对应 Skill。这三件事都正常说明七个概念在链路里各就各位。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 报错对照配置和验证过程中报错是最直接的反馈。下面按真实报错逐条对照。401 Unauthorized最常见的原因是 Key 没传对。检查Authorization头是不是Bearer加 Key中间有空格。如果用的是 Claude Code检查ANTHROPIC_API_KEY环境变量有没有生效有时候在终端里 export 了但 IDE 没继承。还有一种情况是 Key 创建后没复制完整尾部少了字符。重新在控制台创建一个新 Key完整复制再试。local proxy failed这个报错通常出现在本地工具通过代理访问 API 时。检查 Base URL 是不是写成了https://taotoken.net/api不要带多余路径。如果本地有网络层配置确认没有把 API 域名指向错误地址。这个报错和 Key 无关纯粹是地址或网络层配置问题。reading choices 相关报错通常是响应结构解析失败。比如代码里按response.choices[0].message.content取值但实际返回的是tool_callscontent为 null就会报读取失败。处理方式是先判断有没有tool_calls有就先执行工具再继续没有才读content。另外流式响应和非流式响应结构不同别混用解析逻辑。OAuth 报错多出现在 MCP Server 连接第三方服务时。比如 GitHub MCP Server 需要GITHUB_TOKENNotion 需要集成 Token。检查环境变量名是否和 Server 要求的一致Token 权限是否足够。有些 MCP Server 首次连接需要走 OAuth 授权流程按提示在浏览器完成授权即可。如果报 scope 不足去对应平台重新授权并勾选所需权限。模型不调用 Tool不是报错但很常见。检查tools字段的 JSON Schema 是否合法description是否写清楚了工具用途。模型只有在判断“需要外部信息”时才会调用如果 Prompt 里已经包含答案它可能直接回答。可以在 system Prompt 里明确要求“需要实时信息时必须调用工具”。Agent 陷入循环Agent 反复调用同一个 Tool 不停止。这通常是 Workflow 缺少终止条件或者 Observer 没有正确判断任务完成。在编排层加最大步数限制或者在 Skill 里写清楚“什么情况下停止”。MCP Server 启动失败检查command和args是否正确依赖是否安装。比如npx方式需要本地有 Node 环境。有些 Server 需要特定运行时版本按文档要求配置。排查时建议按层定位先确认 LLM 单独能通再加 Tool再加 MCP最后加 Agent 和 Workflow。每加一层发一次请求报错就能定位到具体层。6. 语义一致 CTA把概念落到可运行的接入与验证概念讲完最终要落到能跑起来的配置。如果你要验证模型对话和 Tool 调用先去控制台创建 API Key然后对照接入文档把 Base URL、Key、Model ID 三件套配好。模型对话入口可以直接测试 Prompt 和 LLM 的基础行为接入文档里有各语言的完整示例。如果你要做长期编码或 Agent 类任务Coding Plan 更适合它把编码场景常用的配置和额度打包好了省去反复调参。API Keys 页面管理所有 Key建议按用途分开创建方便排查问题时定位。验证顺序建议这样先用模型对话发一条纯 Prompt 请求确认 LLM 通再加一个 Tool 定义确认能返回tool_calls然后配一个 MCP Server确认能发现工具最后用 Agent 串起来加一个 Skill 和简单 Workflow。每步都发真实请求看响应结构比读十篇文档都管用。这套链路跑通之后你再回头看那七个词就不再是抽象概念而是请求体里的字段、响应里的结构、配置文件里的段落。哪个环节出问题你都知道该去查哪一层。
AI名词Prompt、LLM、Agent、Agent Skills、Workflow、MCP、Tool都是什么意思？深度解析+例子说明
1. 从一次“AI 答非所问”说起这七个词到底卡在哪刚接触大模型应用开发时最容易遇到的不是代码报错而是概念打架。你打开一份框架文档满屏都是 Prompt、LLM、Agent、Agent Skills、Workflow、MCP、Tool每个词单看都认识连起来就不知道谁管谁。我见过不少朋友把 MCP 当成某个模型的名字把 Agent Skills 和 Workflow 混着用结果配置写完跑起来模型要么不调用工具要么调用了却传错参数。这篇就按“一个真实请求从发出到完成”的顺序把这七个高频术语拆开。你可以把它当成一份术语对照表加一段可运行的最小示例先搞清楚每个词在链路里的位置再动手发一次请求看它们怎么协作。先给一个生活化类比后面所有解释都围绕它展开。假设你要开一家餐厅LLM 是后厨那位厨艺很好但只会做菜的师傅你给他什么食材和菜谱他就出什么菜。Prompt 是你递给他的点菜单写得越清楚他做得越接近你要的。Tool 是厨房里的烤箱、榨汁机、收银机师傅自己不会凭空变出这些能力得有人给他配。MCP 是厨房统一的插座标准不管什么牌子的电器插上就能用不用每次重新接线。Agent 是餐厅经理他不做菜但他会看订单、安排师傅、调用设备、处理突发情况。Agent Skills 是经理脑子里的“专项经验包”比如“处理客诉的流程”“旺季排班经验”。Workflow 是整条出餐流水线从接单到上菜分几步、哪步并行、哪步要人复核。这七个词不是并列关系而是分层关系。搞混层级配置就会写错地方。下面逐个拆每个都配一个能跑的最小例子。2. TaoToken 前置准备把 LLM 和 Tool 的调用链路先打通在讲概念之前得先有一个能实际发请求的环境否则所有术语都停留在纸面。我用 TaoToken 作为统一入口来演示原因是它把模型对话、API Key 管理、接入文档放在同一个控制台里适合边看概念边验证。你需要先拿到三样东西Base URL、API Key、Model ID。这三件套是后面所有配置的基础缺一个请求就会失败。Base URL 用https://taotoken.net/api注意这里不加任何查询参数。API Key 在控制台的 API Keys 页面创建创建后只显示一次复制保存好。Model ID 根据你要验证的模型填比如对话类模型填对应的模型标识。如果你用的是 Claude Code 这类编码工具配置方式略有不同需要设置 Anthropic 兼容的 Base URL 和 Key。具体路径在接入文档里有说明我建议先按文档把环境变量配好再回来理解概念这样每讲一个词你都能立刻发请求验证。这里有个容易踩的坑很多人把 Base URL 写成带/v1或带 UTM 参数的地址结果请求 404。记住 API 地址就是https://taotoken.net/api不要自己拼路径。另外 Key 不要硬编码在代码里提交到仓库用环境变量或者本地配置文件。准备好这三件套后先别急着写复杂逻辑。我们先用最原始的方式发一次请求看看 LLM 单独工作是什么样再逐步加上 Tool、Agent 这些层。这样你能清楚看到每一层加进去之后请求和响应发生了什么变化。3. 可复制配置Prompt、LLM、Tool 三件套的最小 JSON 与 settings 片段这一节给可直接复制的配置。先看最基础的 LLM 调用它只需要 Base URL、Key、Model ID 和一段 Prompt。curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: your-model-id, messages: [ {role: system, content: 你是一位严谨的代码审查专家逐步指出问题并给出重构代码。}, {role: user, content: 审查这段代码def add(a,b): return ab} ] }这段里messages数组就是 Prompt 的载体。system角色是约束和角色设定user是具体任务。LLM 收到后只做一件事预测下一个 token把回答补全。它不会去查数据库也不会调用外部接口。接下来加 Tool。Tool 的本质是一段 JSON Schema 描述告诉模型“有这么个函数参数是什么”。模型不会真的执行它而是输出一个“我要调用这个函数”的结构化结果由你的代码去执行。{ name: search_web, description: 实时搜索互联网返回摘要结果, parameters: { type: object, properties: { query: {type: string, description: 搜索关键词}, num_results: {type: integer, description: 返回条数默认 5} }, required: [query] } }把这段放进请求的tools字段模型在需要实时信息时就会返回tool_calls。你的后端拿到tool_calls执行真实搜索再把结果作为tool角色消息塞回对话模型继续生成最终回答。这就是 Tool 的完整闭环。如果你用 Claude Code 或 Cline 这类工具配置通常写在 settings 文件里。以 Claude Code 为例需要设置ANTHROPIC_BASE_URL和ANTHROPIC_API_KEYBase URL 指向 TaoToken 的 Anthropic 兼容入口Key 用控制台创建的 KeyModel ID 填你要用的模型。三件套齐全工具才能正常发起请求。MCP 的配置则是另一种形态它通常是一个 JSON 文件描述要连接哪些 MCP Server。比如{ mcpServers: { github: { command: npx, args: [-y, modelcontextprotocol/server-github], env: {GITHUB_TOKEN: your-token} } } }这段配置的意思是启动一个 GitHub MCP ServerAgent 就能通过标准协议读取仓库、提交评论。注意 MCP Server 是独立进程Agent 通过协议和它通信而不是把逻辑写死在 Agent 里。Agent Skills 的配置更轻通常是一个文件夹加一个SKILL.md。文件里写清楚技能名称、描述、触发条件和操作步骤。Agent 在规划任务时先读描述判断要不要加载这个技能需要时才读完整内容这样节省上下文。Workflow 的配置则体现在编排层比如用 LangGraph 定义节点和边或者用 MCP Prompts 定义可复用的流程模板。它管的是“先做什么、再做什么、哪步并行、哪步要人确认”。把这五类配置放在一起看层级就清楚了Prompt 和 LLM 是最内层Tool 和 MCP 是能力接入层Agent Skills 是知识层Workflow 是编排层Agent 是把这些串起来的执行者。4. 验证请求一次真实调用看七个概念各在哪一环配置写完发一次真实请求观察响应结构就能把概念对应到具体字段。假设我们发一个带 Tool 的请求用户问“帮我查一下今天有什么 AI 新闻”。请求体里带上tools定义。响应可能长这样{ choices: [ { message: { role: assistant, content: null, tool_calls: [ { id: call_abc123, type: function, function: { name: search_web, arguments: {\query\:\AI 新闻\,\num_results\:5} } } ] } } ] }看到tool_calls就说明 Tool 这一层生效了。模型没有直接编答案而是决定调用搜索工具。你的代码执行搜索后把结果作为tool消息追加{role: tool, tool_call_id: call_abc123, content: 搜索结果摘要...}再发一次请求模型这次会基于搜索结果生成自然语言回答。整个链路是Prompt 触发 LLM 推理LLM 决定调用 ToolTool 返回结果LLM 整合输出。如果换成 Agent链路会多一层规划。Agent 收到“帮我做一份竞品分析报告”这种模糊目标会先拆成子任务搜索竞品信息、整理功能对比、生成报告。每个子任务可能调用不同 Tool中间结果存到 Memory遇到错误会重试或换策略。你看到的不是一次tool_calls而是一串连续的调用和反思。Agent Skills 在这一环的作用是当 Agent 判断当前任务属于“前端调试”时加载对应的SKILL.md按里面写的检查清单逐项排查而不是漫无目的地试。它提供的是领域知识和流程不直接执行外部操作。MCP 在这一环的作用是Agent 不需要为每个外部系统写适配代码只要连上对应的 MCP Server就能发现可用工具并调用。比如连上 GitHub MCP Server 后Agent 自动知道有“读取 PR”“提交评论”这些能力。Workflow 在这一环的作用是定义整个流程的骨架。比如客服场景先分类问题再并行查订单和库存需要退款时调用支付 Tool最后记录日志并等待人工审批。Workflow 决定节点顺序和分支条件Agent 在节点内自主决策。验证时重点看三件事响应里有没有tool_calls说明 Tool 层通了多轮请求之间上下文有没有正确传递说明 Memory 和 Workflow 在起作用换一个需要领域知识的任务看 Agent 有没有加载对应 Skill。这三件事都正常说明七个概念在链路里各就各位。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 报错对照配置和验证过程中报错是最直接的反馈。下面按真实报错逐条对照。401 Unauthorized最常见的原因是 Key 没传对。检查Authorization头是不是Bearer加 Key中间有空格。如果用的是 Claude Code检查ANTHROPIC_API_KEY环境变量有没有生效有时候在终端里 export 了但 IDE 没继承。还有一种情况是 Key 创建后没复制完整尾部少了字符。重新在控制台创建一个新 Key完整复制再试。local proxy failed这个报错通常出现在本地工具通过代理访问 API 时。检查 Base URL 是不是写成了https://taotoken.net/api不要带多余路径。如果本地有网络层配置确认没有把 API 域名指向错误地址。这个报错和 Key 无关纯粹是地址或网络层配置问题。reading choices 相关报错通常是响应结构解析失败。比如代码里按response.choices[0].message.content取值但实际返回的是tool_callscontent为 null就会报读取失败。处理方式是先判断有没有tool_calls有就先执行工具再继续没有才读content。另外流式响应和非流式响应结构不同别混用解析逻辑。OAuth 报错多出现在 MCP Server 连接第三方服务时。比如 GitHub MCP Server 需要GITHUB_TOKENNotion 需要集成 Token。检查环境变量名是否和 Server 要求的一致Token 权限是否足够。有些 MCP Server 首次连接需要走 OAuth 授权流程按提示在浏览器完成授权即可。如果报 scope 不足去对应平台重新授权并勾选所需权限。模型不调用 Tool不是报错但很常见。检查tools字段的 JSON Schema 是否合法description是否写清楚了工具用途。模型只有在判断“需要外部信息”时才会调用如果 Prompt 里已经包含答案它可能直接回答。可以在 system Prompt 里明确要求“需要实时信息时必须调用工具”。Agent 陷入循环Agent 反复调用同一个 Tool 不停止。这通常是 Workflow 缺少终止条件或者 Observer 没有正确判断任务完成。在编排层加最大步数限制或者在 Skill 里写清楚“什么情况下停止”。MCP Server 启动失败检查command和args是否正确依赖是否安装。比如npx方式需要本地有 Node 环境。有些 Server 需要特定运行时版本按文档要求配置。排查时建议按层定位先确认 LLM 单独能通再加 Tool再加 MCP最后加 Agent 和 Workflow。每加一层发一次请求报错就能定位到具体层。6. 语义一致 CTA把概念落到可运行的接入与验证概念讲完最终要落到能跑起来的配置。如果你要验证模型对话和 Tool 调用先去控制台创建 API Key然后对照接入文档把 Base URL、Key、Model ID 三件套配好。模型对话入口可以直接测试 Prompt 和 LLM 的基础行为接入文档里有各语言的完整示例。如果你要做长期编码或 Agent 类任务Coding Plan 更适合它把编码场景常用的配置和额度打包好了省去反复调参。API Keys 页面管理所有 Key建议按用途分开创建方便排查问题时定位。验证顺序建议这样先用模型对话发一条纯 Prompt 请求确认 LLM 通再加一个 Tool 定义确认能返回tool_calls然后配一个 MCP Server确认能发现工具最后用 Agent 串起来加一个 Skill 和简单 Workflow。每步都发真实请求看响应结构比读十篇文档都管用。这套链路跑通之后你再回头看那七个词就不再是抽象概念而是请求体里的字段、响应里的结构、配置文件里的段落。哪个环节出问题你都知道该去查哪一层。
