关于AI的一些名词:从LLM、Prompt到Agent、RAG、MCP,一次理清TaoToken统一Key/API通道 1. 从一次 401 报错说起LLM、Prompt、Agent、RAG、MCP 到底谁管谁刚接触 AI 开发那阵子我最常干的事不是写业务代码而是对着一个 401 报错发呆。明明 Key 填了Base URL 也改了请求发出去却告诉我invalid api key。后来才想明白问题不在 Key 本身而在于我没搞清楚这些名词各自站在哪一层LLM 是发动机Prompt 是方向盘Agent 是司机RAG 是随车资料库MCP 是标准化的工具箱接口。它们不是并列关系而是一条调用链上的不同环节。这篇文章想做的事很简单用一条主线把这五个高频词串起来让你知道每个词解决什么问题、在项目里处于哪一层最后用 TaoToken 的统一 Key/API 通道跑一次真实请求把整条链路验证一遍。适合刚接触 AI 开发、被各种缩写绕晕的读者。你不需要先学完 Transformer也不需要背完向量数学只要能发一个 HTTP 请求就能跟着走完。先说结论性的认知地图你写的代码调用的是统一 API 通道通道背后路由到某个 LLM你发给 LLM 的那段文字是 Prompt如果让 LLM 自己决定调用哪些工具、分几步完成任务它就成了 Agent如果它在回答前先去你的文档库里检索相关片段那就是 RAG而 MCP 是让 LLM 和外部工具之间用统一格式对话的约定。五个词一条链各司其职。我试过把这五个词拆开单独学结果越学越乱因为每个词都牵扯出一堆新概念。后来换成按调用顺序理解反而清晰了。下面按这个顺序展开每一步都给出可复制的配置和验证方法。2. TaoToken 统一 Key/API 通道一个 Base URL 打通所有模型调用在讲具体名词之前得先把「通道」这件事说清楚否则后面的验证请求没法落地。TaoToken 在这里扮演的角色是统一入口你不需要为每个模型厂商分别申请 Key、分别记 Base URL、分别处理不同的请求格式而是用一套 Key 和一套 API 地址通过改 Model ID 来切换背后的模型。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置时直接写这个就行。这个通道兼容 OpenAI 风格的请求格式所以大部分现成工具和 SDK 只要改 Base URL 和 Key 就能接上。为什么这件事对理解那五个名词有帮助因为 LLM、Prompt、Agent、RAG、MCP 这五层最终都要落到一次或多次 API 请求上。你把通道配通了就能在真实请求里看到每一层留下的痕迹Prompt 出现在 messages 字段里Agent 的多步决策表现为多次请求RAG 的检索结果被拼进上下文MCP 的工具调用体现在 tools 参数和返回的 tool_calls 里。没有通道这些全是纸上谈兵。配置上你只需要准备三样东西Base URL、API Key、Model ID。Base URL 填 https://taotoken.net/api API Key 在控制台的 API Keys 页面生成Model ID 填你要用的模型标识。这三件套是后面所有验证的基础建议先配好再往下读。如果你用的是 Claude Code 这类工具配置方式略有不同需要设置 ANTHROPIC_BASE_URL 和 ANTHROPIC_AUTH_TOKEN 两个环境变量Model ID 也要对应填对。Cline 的 MCP 配置、Codex 的 auth.json 也是同样的三件套逻辑只是字段名不一样。下面第三节会给出具体的可复制片段。3. 可复制配置片段settings.json、auth.json 与 MCP 三件套这一节给出实际能用的配置片段路径和字段名尽量贴近真实工具你复制后改掉 Key 就能跑。先说明一点不管哪个工具核心都是 Base URL、Key、Model ID 三件套区别只在字段名和文件位置。先看通用的环境变量方式适合大多数 SDK 和命令行工具export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEYsk-你的Key export OPENAI_MODEL你的ModelID如果你用 Claude Code它读的是 Anthropic 风格的变量配置如下export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENsk-你的Key export ANTHROPIC_MODEL你的ModelIDCodex 的 auth.json 通常放在用户目录下的 .codex 文件夹里内容结构大致是这样{ base_url: https://taotoken.net/api, api_key: sk-你的Key, model: 你的ModelID }Cline 的 MCP 配置走的是另一套结构在 settings 里声明 MCP server 时同样要把三件套填全{ mcpServers: { taotoken: { command: npx, args: [-y, 你的MCP服务包], env: { BASE_URL: https://taotoken.net/api, API_KEY: sk-你的Key, MODEL_ID: 你的ModelID } } } }注意上面三个片段里Base URL 都是 https://taotoken.net/api 没有多余路径也没有 UTM 参数。Key 和 Model ID 按你控制台里的实际值填。这三件套一旦配错任何一个最常见的表现就是 401 或者 model not found。配置完成后建议先用一个最小请求验证通道是否通再往上叠加 Agent、RAG、MCP 的逻辑。这样出问题时能快速定位是哪一层的事而不是一上来就怀疑整个链路。4. 一次请求验证五层链路从 Prompt 到 tool_calls 的完整回包配置好了现在跑一次真实请求看看那五个名词在回包里长什么样。用 curl 发一个最简单的对话请求curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的Key \ -d { model: 你的ModelID, messages: [ {role: system, content: 你是一个简洁的助手。}, {role: user, content: 用一句话解释什么是向量数据库。} ] }这个请求里messages 数组就是 Prompt 的载体。system 消息设定角色user 消息是具体问题两者合起来构成这次调用的提示词。LLM 收到后生成回答回包里的 choices[0].message.content 就是结果。到这一步你已经验证了 LLM 和 Prompt 两层。接下来验证 Agent 和 MCP。在请求体里加上 tools 参数声明一个可调用的工具{ model: 你的ModelID, messages: [ {role: user, content: 北京现在天气怎么样} ], tools: [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } } ] }如果模型决定调用这个工具回包里会出现 finish_reason 为 tool_calls以及 message.tool_calls 数组里面包含函数名和参数。这就是 Agent 的雏形模型不再只是被动回答而是主动决定调用哪个工具、传什么参数。MCP 在这里的作用是把这种工具调用约定标准化让不同工具用统一格式描述自己模型不用为每个工具写一套适配。验证 RAG 稍微麻烦一点因为检索发生在你的应用侧。典型流程是用户提问后你先去向量数据库检索相关片段把片段拼进 system 或 user 消息再发给 LLM。回包里看不出检索过程但你能看到回答明显基于你提供的片段。判断 RAG 是否生效看回答里有没有引用你文档里的专有信息。跑完这几个请求你应该能感觉到五个名词不是五个独立技术而是同一条链上的五个位置。通道通了剩下的就是按需往对应位置加逻辑。5. 常见报错排查401、local proxy failed 与 reading choices 怎么解配置和验证过程中最容易撞上的几个报错这里逐个拆解。401 invalid api key 是最常见的。原因通常有三个Key 复制时带了空格或换行、Key 已经失效或被删除、Authorization 头格式写错。正确格式是Bearer sk-xxxBearer 和 Key 之间一个空格。如果你用的是环境变量方式检查变量名有没有拼错比如把 OPENAI_API_KEY 写成了 OPENAI_KEY。local proxy failed 一般出现在工具侧说明工具尝试走本地代理但没起来。这时候先确认你的 Base URL 是不是写成了本地地址应该直接写 https://taotoken.net/api 。如果工具本身有代理设置项把它关掉或设为直连。这个报错和网络环境有关但不需要额外配置代理直连即可。reading choices 报错通常意味着回包结构和你代码里解析的字段对不上。比如你按 OpenAI 格式解析 choices[0].message.content但实际回包可能是流式格式或者模型返回的是 tool_calls 而不是 content。先打印完整回包看结构再改解析逻辑。流式请求时每个 chunk 的 choices 数组可能为空要判断后再取。OAuth 相关报错多出现在 Claude Code 这类工具上说明它还在走 OAuth 认证而不是 API Key。检查 ANTHROPIC_AUTH_TOKEN 是否设置正确有些版本需要同时清掉 OAuth 缓存。如果工具支持 API Key 模式优先用 Key 模式少一层认证少一层问题。model not found 也常见多半是 Model ID 填错。Model ID 区分大小写且不同通道支持的模型列表可能不同去控制台确认可用模型再填。排查顺序建议从下往上先确认通道通不通发最小请求再确认 Prompt 格式对不对然后看工具调用参数最后查 RAG 检索结果。一层一层来比一上来就怀疑整个链路高效得多。6. 把五个名词装进一张认知地图后续怎么继续深入走到这里你应该能用自己的话把这五个词串起来了。LLM 是生成能力本身Prompt 是你和它沟通的方式Agent 是让它自主决策多步任务的框架RAG 是给它外挂知识库的手段MCP 是它和外部工具对话的标准接口。五层各管一段合起来才是一个能用的 AI 应用。后续想继续深入建议按这个顺序先把通道和 Prompt 玩熟能稳定拿到想要的回答再试 Agent让它调用一两个工具完成多步任务然后接 RAG把私有文档接进去最后了解 MCP把工具调用标准化。每一步都跑一次真实请求别只看文档。如果你还没配好通道先去 https://taotoken.net/api-keys 生成 Key再对照 https://taotoken.net/doc 的接入文档把三件套填上。想先感受模型对话效果可以直接用 https://taotoken.net/chat 如果打算长期做编码或 Agent 类项目Coding Plan 会更省心地址是 https://taotoken.net/coding-plan 。Claude Code 用户看 https://taotoken.net/claude-code-anthropic 这份接入说明控制台在 https://taotoken.net/console 。最后留一个实用习惯每次遇到新名词先问它在调用链的哪一层再问它解决什么问题。想清楚这两点大部分缩写都不会再让你焦虑。