1. 从一堆名词到一张架构图LLM、Agent、RAG、MCP 到底怎么串起来如果你最近在给团队做 AI 应用选型大概率会被这几个词轮番轰炸LLM、Agent、RAG、MCP。单独看每个词都能搜到一堆解释但真正落到架构设计时问题就来了——它们之间是什么关系谁依赖谁一个企业级 AI 系统到底该分几层我先把结论摆出来LLM 是能力底座RAG 是知识供给Agent 是执行主体MCP 是连接协议。四者不是并列关系而是从下往上的支撑关系。你可以把它们想象成一家公司LLM 是聪明但没记忆、没手脚的顾问RAG 是给顾问配的资料室Agent 是让顾问变成能自己排计划、跑流程的项目经理MCP 则是公司统一的接口规范让项目经理能安全地调用财务、CRM、工单这些外部系统。为什么这个认知很重要因为很多团队在选型时容易犯一个错把 LLM 当成产品直接交付。结果上线后发现模型答得挺流畅但一问具体业务数据就胡编一让执行操作就抓瞎。这不是模型不行而是架构缺层。一个能跑通的企业级链路至少要有模型服务层、知识增强层、智能体协调层、工具集成层和接入网关层。这篇文章面向正在做 AI 应用选型与架构设计的开发者我会沿着 LLM、Agent、RAG、MCP 四个热词给出一套可复制的分层清单和关键组件对照表并且用统一的 Key/API 通道把多模型调用串起来让你能按图索骥完成一次端到端链路自测。读完你至少能回答三个问题我的场景该用哪几层每层选什么组件怎么用一套凭证把整条链路验证通先说清楚适用边界。如果你只是做个内部问答小工具可能 LLM 加简单 RAG 就够了不必上 Agent 和 MCP。但如果你要做的是能对接业务系统、能自主完成多步任务、还要满足权限和审计要求的企业级应用那这四层基本都得考虑。选型的第一步不是比模型跑分而是先画清楚你的架构分层。2. 企业级 AI 架构分层清单与关键组件对照表这一节是全文的骨架。我把企业级 AI 系统拆成六层从下往上分别是模型服务层、知识增强层、智能体协调层、工具与集成层、AI 网关接入层、前端业务层。每一层我都给出职责、关键组件和选型建议。模型服务层是核心智能引擎。这里要区分模型职能对话模型负责通用问答和写作嵌入模型负责把文本转成向量重排模型负责对检索结果精排推理模型专攻多步逻辑多模态模型处理图文混合。企业里常见做法是对话模型用云端 API嵌入和重排模型可以本地部署以控制成本和数据边界。关键组件包括模型路由、配额管理、失败重试。知识增强层就是 RAG 的主场。它包含文档加载器、切分器、嵌入模型、向量数据库、检索器和重排器。向量数据库选型要看规模小规模可以用 pgvector中等规模用 Milvus 或 Qdrant超大规模再考虑专用方案。这里有个容易忽略的点切分策略比向量库选型更影响效果。按固定长度切会把语义切断按标题层级切通常更稳。智能体协调层负责把 LLM 包装成能规划、能记忆、能调工具的执行体。核心组件是规划器、记忆模块、工具注册表和执行循环。规划器决定任务怎么拆记忆分短期会话记忆和长期向量记忆工具注册表管理可调用的能力清单。工具与集成层是 Agent 连接现实世界的出口。MCP 在这里扮演标准化协议的角色。传统做法是每个工具写一套适配代码MCP 把这套调用规范统一了模型通过协议描述就能发现和调用工具权限边界也更清晰。AI 网关接入层负责鉴权、路由、限流、监控和成本统计。这一层是多模型统一调用的关键。如果你同时接了好几家模型没有网关就会变成一堆散落的 Key 和 SDK。前端业务层就是用户实际接触的入口App、Web 或者内部系统。下面这张对照表把四层核心概念和组件对应起来方便你选型时快速定位概念架构层核心职责典型组件选型关注点LLM模型服务层语言理解与生成对话/推理/嵌入/重排模型上下文长度、并发、成本RAG知识增强层检索增强生成向量库、切分器、重排器召回率、切分策略、更新频率Agent智能体协调层规划与执行规划器、记忆、工具注册表任务成功率、循环控制MCP工具与集成层标准化工具调用MCP 服务端、工具描述权限边界、协议兼容性选型时我建议按这个顺序决策先确定业务是否需要自主执行决定要不要 Agent再确定知识是否私密且需溯源决定 RAG 的形态然后确定要接哪些外部系统决定 MCP 工具清单最后才是选具体模型。反过来先选模型很容易做出一个跑分漂亮但落不了地的系统。还有一个实操建议把模型调用统一到一个 API 通道上。多模型场景下如果每个模型一套凭证和 SDK网关层会非常难维护。用统一的 Base URL 加统一 Key切换模型只改 Model ID这样架构的模型服务层就解耦了。下一节我会给出具体配置。3. 用统一 Key/API 通道串联多模型调用的可复制配置这一节给你可以直接复制的配置。核心思路是所有模型调用都走同一个 Base URL用同一个 Key通过 Model ID 区分具体模型。这样你的代码里只需要维护一套客户端初始化逻辑。先准备凭证。访问 https://taotoken.net/api 对应的控制台创建 API Key然后在模型列表里确认你要用的 Model ID。注意 Base URL 用 https://taotoken.net/api不要带多余路径。下面是一个通用的环境变量配置放在项目根目录的.env文件里# .env TAOTOKEN_BASE_URLhttps://taotoken.net/api TAOTOKEN_API_KEYsk-你的实际Key TAOTOKEN_CHAT_MODEL你的对话模型ID TAOTOKEN_EMBED_MODEL你的嵌入模型ID如果你用的是 OpenAI 兼容的 SDKPython 侧初始化长这样import os from openai import OpenAI client OpenAI( base_urlos.environ[TAOTOKEN_BASE_URL], api_keyos.environ[TAOTOKEN_API_KEY], ) resp client.chat.completions.create( modelos.environ[TAOTOKEN_CHAT_MODEL], messages[ {role: system, content: 你是一个严谨的企业知识助手。}, {role: user, content: 用三句话解释 RAG 和微调的区别。}, ], temperature0.3, ) print(resp.choices[0].message.content)Node.js 侧同理import OpenAI from openai; const client new OpenAI({ baseURL: process.env.TAOTOKEN_BASE_URL, apiKey: process.env.TAOTOKEN_API_KEY, }); const resp await client.chat.completions.create({ model: process.env.TAOTOKEN_CHAT_MODEL, messages: [{ role: user, content: 列出 MCP 的三个核心价值。 }], }); console.log(resp.choices[0].message.content);如果你用 Claude Code 这类编码工具配置方式是通过 settings 文件指定 Base URL 和 Key。在项目或用户级 settings 里写入{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的实际Key, ANTHROPIC_MODEL: 你的模型ID } }这里三件套必须齐全Base URL、Key、Model ID。少任何一个都会在启动时报鉴权或模型找不到的错。我见过最常见的坑是只配了 Key 没配 Base URL结果请求打到了默认端点直接 401。如果你用 Cline 或类似的 MCP 客户端配置里同样要写全三件套。以 Cline 的 MCP 配置为例在cline_mcp_settings.json里{ mcpServers: { my-tool: { command: npx, args: [-y, your-mcp-server], env: { BASE_URL: https://taotoken.net/api, API_KEY: sk-你的实际Key, MODEL_ID: 你的模型ID } } } }Codex 用户则在auth.json里配置{ base_url: https://taotoken.net/api, api_key: sk-你的实际Key, model: 你的模型ID }配置完成后建议先跑一个最小验证脚本确认通道通了再往上叠 RAG 和 Agent。验证脚本就是上面那段 Python能打印出正常回答就说明模型服务层通了。这一步别跳过很多后续报错其实都是凭证或 Base URL 的问题提前隔离掉能省大量排查时间。4. 端到端链路自测从一次请求到 RAG 加 Agent 的完整验证配置好通道后我们来做一次端到端自测。目标是验证四层链路模型服务层能调通、知识增强层能召回、智能体协调层能规划、工具集成层能执行。第一步验证模型服务层。用上一节的脚本发一次请求观察返回。成功标志是choices[0].message.content有正常文本且usage字段有 token 统计。如果这里就失败先别往下走回到凭证排查。第二步验证嵌入和检索。把一段业务文档切分后做嵌入存进向量库再检索回来。这里给一个最小示例用内存列表模拟向量库import numpy as np from openai import OpenAI client OpenAI(base_urlos.environ[TAOTOKEN_BASE_URL], api_keyos.environ[TAOTOKEN_API_KEY]) def embed(texts): resp client.embeddings.create( modelos.environ[TAOTOKEN_EMBED_MODEL], inputtexts, ) return [d.embedding for d in resp.data] docs [ 设备报修流程员工提交工单后由运维主管审批。, 物业维修响应时限为四小时。, 会议室预订需提前一天申请。, ] doc_vecs embed(docs) query 维修要多久 q_vec embed([query])[0] scores [np.dot(q_vec, v) / (np.linalg.norm(q_vec) * np.linalg.norm(v)) for v in doc_vecs] best int(np.argmax(scores)) print(召回文档, docs[best])成功标志是召回结果和查询语义相关而不是字面匹配。如果召回的是「会议室预订」说明嵌入模型或切分有问题。第三步验证 Agent 规划。给模型一个需要多步的任务看它是否能拆解。比如「查一下报修流程然后告诉我响应时限」。观察它是否先检索再回答。这一步不需要真的接工具先看规划文本是否合理。第四步验证 MCP 工具调用。如果你有 MCP 服务端让 Agent 通过协议调用一个只读工具比如查询工单状态。成功标志是工具返回结构化结果且模型能基于结果生成回答。整个链路跑通后你会得到一条完整的请求轨迹用户输入 → 网关鉴权 → Agent 规划 → RAG 检索 → 模型生成 → MCP 工具调用 → 结果返回。任何一环断了都能通过日志定位到具体层。这里有个经验自测时把每层的输入输出都打日志。模型层打 token 用量检索层打召回文档 ID 和分数Agent 层打规划步骤工具层打调用参数和返回。这样出问题时不用猜。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节对照真实报错给排查路径。这些错我都实际遇到过按顺序排查基本能解决。401 Unauthorized。最常见的原因是 Key 无效或 Base URL 配错。先确认 Key 没有多余空格再确认 Base URL 是https://taotoken.net/api而不是带其他路径。如果你用的是 Claude Code检查 settings 里ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY是否都写了。只写 Key 不写 Base URL 会打到默认端点导致 401。还有一种情况是 Key 权限不足去控制台确认这个 Key 是否绑定了你要调的模型。local proxy failed。这个错通常出现在本地工具通过代理访问 API 时。排查方向是网络连通性和代理配置。先确认你的机器能直接访问 Base URL可以用 curl 测一下curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d {model:你的模型ID,messages:[{role:user,content:ping}]}如果 curl 通但工具报 proxy failed说明是工具自身的代理设置问题检查工具的 proxy 配置是否指向了不可用的地址。注意不要配置任何非法的网络访问方式企业环境应使用合规的网络出口。reading choices 相关报错。典型表现是Cannot read properties of undefined (reading choices)。这说明返回体结构和你代码里取值的路径不一致。原因通常是请求根本没成功返回的是错误对象而不是正常响应。先打印完整响应体看error字段。常见触发是 Model ID 写错或者请求体格式不对。确认model字段用的是控制台里的准确 IDmessages是数组且每条有role和content。OAuth 相关报错。如果你用 Claude Code 或 Codex 这类工具可能会遇到 OAuth 流程失败。这类工具优先走 OAuth但如果你已经配了 API Key需要确认工具是否强制走 OAuth。排查方法是检查工具的认证模式配置确保它读取的是你的 API Key 而不是尝试刷新 OAuth token。Codex 的auth.json里如果同时有 OAuth 字段和 api_key 字段可能会冲突建议只保留 api_key 配置。排查通用原则先隔离层级。用 curl 测模型层通了再测工具层。每层单独验证比在整条链路上猜要快得多。另外所有配置里的三件套——Base URL、Key、Model ID——必须同时存在且一致缺一个就会报错。6. 按场景选型什么时候只用 LLM什么时候必须上 RAG 和 Agent最后聊聊选型决策。不是所有场景都需要全套架构过度设计会增加维护成本。只用 LLM 的场景内容生成、文案润色、代码补全、通用问答。这类任务不需要私有知识也不需要执行操作。选型重点是模型能力和成本用统一通道切换模型对比效果即可。LLM 加 RAG 的场景企业知识问答、客服辅助、文档检索、合规审查。核心需求是答案有依据、可溯源、知识可更新。选型重点是切分策略和重排质量。嵌入模型和重排模型建议单独选不要和对话模型混为一谈。LLM 加 Agent 的场景需要多步任务执行、需要调用外部系统、需要自主决策。比如自动化工单处理、数据分析流程、跨系统操作。选型重点是规划稳定性和工具调用的可靠性。Agent 的循环控制很关键要设置最大步数防止死循环。全套 LLM 加 RAG 加 Agent 加 MCP 的场景企业级智能助手、复杂业务流程自动化、需要对接多个内部系统的场景。这时候 MCP 的价值就体现出来了它把工具调用标准化让 Agent 能以统一方式访问不同系统权限边界也更清晰。一个实用的判断方法问自己三个问题。答案需要私有知识吗需要执行操作吗需要对接多个系统吗三个都是否只用 LLM。第一个是加 RAG。第二个是加 Agent。第三个是加 MCP。选型完成后用统一 API 通道把模型调用收敛到一处这样后续换模型、加模型都不影响上层架构。你可以从模型对话开始验证基础通道再逐步叠加检索和工具调用。整条链路自测通过后再考虑性能和成本优化。架构分层清晰了后面每一步迭代都有明确的落点。 一次性搞懂 AI 大模型生态：从 LLM、Agent、RAG 到 MCP 的企业级架构全景
1. 从一堆名词到一张架构图LLM、Agent、RAG、MCP 到底怎么串起来如果你最近在给团队做 AI 应用选型大概率会被这几个词轮番轰炸LLM、Agent、RAG、MCP。单独看每个词都能搜到一堆解释但真正落到架构设计时问题就来了——它们之间是什么关系谁依赖谁一个企业级 AI 系统到底该分几层我先把结论摆出来LLM 是能力底座RAG 是知识供给Agent 是执行主体MCP 是连接协议。四者不是并列关系而是从下往上的支撑关系。你可以把它们想象成一家公司LLM 是聪明但没记忆、没手脚的顾问RAG 是给顾问配的资料室Agent 是让顾问变成能自己排计划、跑流程的项目经理MCP 则是公司统一的接口规范让项目经理能安全地调用财务、CRM、工单这些外部系统。为什么这个认知很重要因为很多团队在选型时容易犯一个错把 LLM 当成产品直接交付。结果上线后发现模型答得挺流畅但一问具体业务数据就胡编一让执行操作就抓瞎。这不是模型不行而是架构缺层。一个能跑通的企业级链路至少要有模型服务层、知识增强层、智能体协调层、工具集成层和接入网关层。这篇文章面向正在做 AI 应用选型与架构设计的开发者我会沿着 LLM、Agent、RAG、MCP 四个热词给出一套可复制的分层清单和关键组件对照表并且用统一的 Key/API 通道把多模型调用串起来让你能按图索骥完成一次端到端链路自测。读完你至少能回答三个问题我的场景该用哪几层每层选什么组件怎么用一套凭证把整条链路验证通先说清楚适用边界。如果你只是做个内部问答小工具可能 LLM 加简单 RAG 就够了不必上 Agent 和 MCP。但如果你要做的是能对接业务系统、能自主完成多步任务、还要满足权限和审计要求的企业级应用那这四层基本都得考虑。选型的第一步不是比模型跑分而是先画清楚你的架构分层。2. 企业级 AI 架构分层清单与关键组件对照表这一节是全文的骨架。我把企业级 AI 系统拆成六层从下往上分别是模型服务层、知识增强层、智能体协调层、工具与集成层、AI 网关接入层、前端业务层。每一层我都给出职责、关键组件和选型建议。模型服务层是核心智能引擎。这里要区分模型职能对话模型负责通用问答和写作嵌入模型负责把文本转成向量重排模型负责对检索结果精排推理模型专攻多步逻辑多模态模型处理图文混合。企业里常见做法是对话模型用云端 API嵌入和重排模型可以本地部署以控制成本和数据边界。关键组件包括模型路由、配额管理、失败重试。知识增强层就是 RAG 的主场。它包含文档加载器、切分器、嵌入模型、向量数据库、检索器和重排器。向量数据库选型要看规模小规模可以用 pgvector中等规模用 Milvus 或 Qdrant超大规模再考虑专用方案。这里有个容易忽略的点切分策略比向量库选型更影响效果。按固定长度切会把语义切断按标题层级切通常更稳。智能体协调层负责把 LLM 包装成能规划、能记忆、能调工具的执行体。核心组件是规划器、记忆模块、工具注册表和执行循环。规划器决定任务怎么拆记忆分短期会话记忆和长期向量记忆工具注册表管理可调用的能力清单。工具与集成层是 Agent 连接现实世界的出口。MCP 在这里扮演标准化协议的角色。传统做法是每个工具写一套适配代码MCP 把这套调用规范统一了模型通过协议描述就能发现和调用工具权限边界也更清晰。AI 网关接入层负责鉴权、路由、限流、监控和成本统计。这一层是多模型统一调用的关键。如果你同时接了好几家模型没有网关就会变成一堆散落的 Key 和 SDK。前端业务层就是用户实际接触的入口App、Web 或者内部系统。下面这张对照表把四层核心概念和组件对应起来方便你选型时快速定位概念架构层核心职责典型组件选型关注点LLM模型服务层语言理解与生成对话/推理/嵌入/重排模型上下文长度、并发、成本RAG知识增强层检索增强生成向量库、切分器、重排器召回率、切分策略、更新频率Agent智能体协调层规划与执行规划器、记忆、工具注册表任务成功率、循环控制MCP工具与集成层标准化工具调用MCP 服务端、工具描述权限边界、协议兼容性选型时我建议按这个顺序决策先确定业务是否需要自主执行决定要不要 Agent再确定知识是否私密且需溯源决定 RAG 的形态然后确定要接哪些外部系统决定 MCP 工具清单最后才是选具体模型。反过来先选模型很容易做出一个跑分漂亮但落不了地的系统。还有一个实操建议把模型调用统一到一个 API 通道上。多模型场景下如果每个模型一套凭证和 SDK网关层会非常难维护。用统一的 Base URL 加统一 Key切换模型只改 Model ID这样架构的模型服务层就解耦了。下一节我会给出具体配置。3. 用统一 Key/API 通道串联多模型调用的可复制配置这一节给你可以直接复制的配置。核心思路是所有模型调用都走同一个 Base URL用同一个 Key通过 Model ID 区分具体模型。这样你的代码里只需要维护一套客户端初始化逻辑。先准备凭证。访问 https://taotoken.net/api 对应的控制台创建 API Key然后在模型列表里确认你要用的 Model ID。注意 Base URL 用 https://taotoken.net/api不要带多余路径。下面是一个通用的环境变量配置放在项目根目录的.env文件里# .env TAOTOKEN_BASE_URLhttps://taotoken.net/api TAOTOKEN_API_KEYsk-你的实际Key TAOTOKEN_CHAT_MODEL你的对话模型ID TAOTOKEN_EMBED_MODEL你的嵌入模型ID如果你用的是 OpenAI 兼容的 SDKPython 侧初始化长这样import os from openai import OpenAI client OpenAI( base_urlos.environ[TAOTOKEN_BASE_URL], api_keyos.environ[TAOTOKEN_API_KEY], ) resp client.chat.completions.create( modelos.environ[TAOTOKEN_CHAT_MODEL], messages[ {role: system, content: 你是一个严谨的企业知识助手。}, {role: user, content: 用三句话解释 RAG 和微调的区别。}, ], temperature0.3, ) print(resp.choices[0].message.content)Node.js 侧同理import OpenAI from openai; const client new OpenAI({ baseURL: process.env.TAOTOKEN_BASE_URL, apiKey: process.env.TAOTOKEN_API_KEY, }); const resp await client.chat.completions.create({ model: process.env.TAOTOKEN_CHAT_MODEL, messages: [{ role: user, content: 列出 MCP 的三个核心价值。 }], }); console.log(resp.choices[0].message.content);如果你用 Claude Code 这类编码工具配置方式是通过 settings 文件指定 Base URL 和 Key。在项目或用户级 settings 里写入{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的实际Key, ANTHROPIC_MODEL: 你的模型ID } }这里三件套必须齐全Base URL、Key、Model ID。少任何一个都会在启动时报鉴权或模型找不到的错。我见过最常见的坑是只配了 Key 没配 Base URL结果请求打到了默认端点直接 401。如果你用 Cline 或类似的 MCP 客户端配置里同样要写全三件套。以 Cline 的 MCP 配置为例在cline_mcp_settings.json里{ mcpServers: { my-tool: { command: npx, args: [-y, your-mcp-server], env: { BASE_URL: https://taotoken.net/api, API_KEY: sk-你的实际Key, MODEL_ID: 你的模型ID } } } }Codex 用户则在auth.json里配置{ base_url: https://taotoken.net/api, api_key: sk-你的实际Key, model: 你的模型ID }配置完成后建议先跑一个最小验证脚本确认通道通了再往上叠 RAG 和 Agent。验证脚本就是上面那段 Python能打印出正常回答就说明模型服务层通了。这一步别跳过很多后续报错其实都是凭证或 Base URL 的问题提前隔离掉能省大量排查时间。4. 端到端链路自测从一次请求到 RAG 加 Agent 的完整验证配置好通道后我们来做一次端到端自测。目标是验证四层链路模型服务层能调通、知识增强层能召回、智能体协调层能规划、工具集成层能执行。第一步验证模型服务层。用上一节的脚本发一次请求观察返回。成功标志是choices[0].message.content有正常文本且usage字段有 token 统计。如果这里就失败先别往下走回到凭证排查。第二步验证嵌入和检索。把一段业务文档切分后做嵌入存进向量库再检索回来。这里给一个最小示例用内存列表模拟向量库import numpy as np from openai import OpenAI client OpenAI(base_urlos.environ[TAOTOKEN_BASE_URL], api_keyos.environ[TAOTOKEN_API_KEY]) def embed(texts): resp client.embeddings.create( modelos.environ[TAOTOKEN_EMBED_MODEL], inputtexts, ) return [d.embedding for d in resp.data] docs [ 设备报修流程员工提交工单后由运维主管审批。, 物业维修响应时限为四小时。, 会议室预订需提前一天申请。, ] doc_vecs embed(docs) query 维修要多久 q_vec embed([query])[0] scores [np.dot(q_vec, v) / (np.linalg.norm(q_vec) * np.linalg.norm(v)) for v in doc_vecs] best int(np.argmax(scores)) print(召回文档, docs[best])成功标志是召回结果和查询语义相关而不是字面匹配。如果召回的是「会议室预订」说明嵌入模型或切分有问题。第三步验证 Agent 规划。给模型一个需要多步的任务看它是否能拆解。比如「查一下报修流程然后告诉我响应时限」。观察它是否先检索再回答。这一步不需要真的接工具先看规划文本是否合理。第四步验证 MCP 工具调用。如果你有 MCP 服务端让 Agent 通过协议调用一个只读工具比如查询工单状态。成功标志是工具返回结构化结果且模型能基于结果生成回答。整个链路跑通后你会得到一条完整的请求轨迹用户输入 → 网关鉴权 → Agent 规划 → RAG 检索 → 模型生成 → MCP 工具调用 → 结果返回。任何一环断了都能通过日志定位到具体层。这里有个经验自测时把每层的输入输出都打日志。模型层打 token 用量检索层打召回文档 ID 和分数Agent 层打规划步骤工具层打调用参数和返回。这样出问题时不用猜。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节对照真实报错给排查路径。这些错我都实际遇到过按顺序排查基本能解决。401 Unauthorized。最常见的原因是 Key 无效或 Base URL 配错。先确认 Key 没有多余空格再确认 Base URL 是https://taotoken.net/api而不是带其他路径。如果你用的是 Claude Code检查 settings 里ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY是否都写了。只写 Key 不写 Base URL 会打到默认端点导致 401。还有一种情况是 Key 权限不足去控制台确认这个 Key 是否绑定了你要调的模型。local proxy failed。这个错通常出现在本地工具通过代理访问 API 时。排查方向是网络连通性和代理配置。先确认你的机器能直接访问 Base URL可以用 curl 测一下curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d {model:你的模型ID,messages:[{role:user,content:ping}]}如果 curl 通但工具报 proxy failed说明是工具自身的代理设置问题检查工具的 proxy 配置是否指向了不可用的地址。注意不要配置任何非法的网络访问方式企业环境应使用合规的网络出口。reading choices 相关报错。典型表现是Cannot read properties of undefined (reading choices)。这说明返回体结构和你代码里取值的路径不一致。原因通常是请求根本没成功返回的是错误对象而不是正常响应。先打印完整响应体看error字段。常见触发是 Model ID 写错或者请求体格式不对。确认model字段用的是控制台里的准确 IDmessages是数组且每条有role和content。OAuth 相关报错。如果你用 Claude Code 或 Codex 这类工具可能会遇到 OAuth 流程失败。这类工具优先走 OAuth但如果你已经配了 API Key需要确认工具是否强制走 OAuth。排查方法是检查工具的认证模式配置确保它读取的是你的 API Key 而不是尝试刷新 OAuth token。Codex 的auth.json里如果同时有 OAuth 字段和 api_key 字段可能会冲突建议只保留 api_key 配置。排查通用原则先隔离层级。用 curl 测模型层通了再测工具层。每层单独验证比在整条链路上猜要快得多。另外所有配置里的三件套——Base URL、Key、Model ID——必须同时存在且一致缺一个就会报错。6. 按场景选型什么时候只用 LLM什么时候必须上 RAG 和 Agent最后聊聊选型决策。不是所有场景都需要全套架构过度设计会增加维护成本。只用 LLM 的场景内容生成、文案润色、代码补全、通用问答。这类任务不需要私有知识也不需要执行操作。选型重点是模型能力和成本用统一通道切换模型对比效果即可。LLM 加 RAG 的场景企业知识问答、客服辅助、文档检索、合规审查。核心需求是答案有依据、可溯源、知识可更新。选型重点是切分策略和重排质量。嵌入模型和重排模型建议单独选不要和对话模型混为一谈。LLM 加 Agent 的场景需要多步任务执行、需要调用外部系统、需要自主决策。比如自动化工单处理、数据分析流程、跨系统操作。选型重点是规划稳定性和工具调用的可靠性。Agent 的循环控制很关键要设置最大步数防止死循环。全套 LLM 加 RAG 加 Agent 加 MCP 的场景企业级智能助手、复杂业务流程自动化、需要对接多个内部系统的场景。这时候 MCP 的价值就体现出来了它把工具调用标准化让 Agent 能以统一方式访问不同系统权限边界也更清晰。一个实用的判断方法问自己三个问题。答案需要私有知识吗需要执行操作吗需要对接多个系统吗三个都是否只用 LLM。第一个是加 RAG。第二个是加 Agent。第三个是加 MCP。选型完成后用统一 API 通道把模型调用收敛到一处这样后续换模型、加模型都不影响上层架构。你可以从模型对话开始验证基础通道再逐步叠加检索和工具调用。整条链路自测通过后再考虑性能和成本优化。架构分层清晰了后面每一步迭代都有明确的落点。