尧图网页设计 
1. 三件套联调为什么总在 Base URL 上翻车LangChain、MCP Server、Qwen-Agent 放在同一条链路里跑最容易出问题的不是模型本身而是「谁在跟谁说话、走的是哪个 Base URL」。我这次的目标很明确让 LangGraph 编排的 Agent 通过 MCP 协议调用工具模型侧统一改到 TaoToken 的 OpenAI 兼容入口同时保留本地 vllm 和 Ollama 的对照测试。适合正在做多模型 Agent 联调、被 401 和超时反复折磨的人。先说清楚这三个东西各自扮演什么角色。LangChain 是编排层负责把消息、工具、状态串起来LangGraph 是 LangChain 之上的状态机用节点和边描述「模型思考→调用工具→再思考」的循环MCP Server 是工具协议层把工具以标准接口暴露出去客户端通过 stdio 或 HTTP 连接Qwen-Agent 则是面向 Qwen 系列的 Agent 框架支持 DashScope 和 OpenAI 兼容两种接入方式。三者能拼在一起的关键是它们都认 OpenAI 风格的/v1/chat/completions接口。问题就出在这里。LangChain 的ChatOpenAI、Qwen-Agent 的 OpenAI 模式、以及langchain-mcp-adapters里加载出来的工具最终都会去读base_url和api_key。只要有一个地方还指向旧的地址或者 Key 没传进去链路就会在某个节点断掉。我实测下来最常见的三种表现是401 认证失败、请求卡住直到超时、以及流式返回时reading choices解析报错。这三种背后对应的配置点完全不同所以排查必须分层做不能一上来就怀疑模型。还有一个容易被忽略的点vllm 本地部署时--enable-auto-tool-choice和--tool-call-parser必须成对出现缺一个直接启动报错。这和 Base URL 无关但很多人会把启动失败误判成接口问题。把这两类问题分开排查效率会高很多。这篇记录按「先统一入口再逐项验证最后对照报错」的顺序写。你可以直接复制配置片段也可以跟着验证动作一步步确认链路是否通。核心检索词就是 LangChain MCP Server Qwen-Agent 联调 Base URL 配置下面所有步骤都围绕它展开。2. TaoToken 前置把 Base URL 和 Key 统一到一处在动 LangChain 代码之前先把模型入口固定下来。我这次所有云端调用都走 TaoToken 的 OpenAI 兼容接口Base URL 用https://taotoken.net/apiKey 在控制台生成。这样做的好处是LangChain、Qwen-Agent、MCP 适配层三处只需要维护同一组地址和密钥改一处即可全局生效不用在每个框架里各配一遍。具体操作路径是先到官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册并进入控制台然后在 API Keys 页面创建一个新 Key。创建时建议按用途命名比如langgraph-mcp-test方便后面区分是哪个链路在用。Key 只在创建时完整显示一次复制后先存到环境变量里不要直接硬编码进代码。环境变量这样设Linux/macOS 用 exportWindows 用 setexport TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api设完之后用echo $TAOTOKEN_API_KEY确认一下有没有生效。我踩过的坑是在 IDE 的终端里设了变量但运行脚本用的是另一个 shell结果代码里读到空值直接 401。所以验证环境变量这一步别省。模型 ID 这块要注意TaoToken 的模型列表里 Qwen 系列和通用模型是分开列的。做工具调用测试时优先选支持 Function Calling 的模型比如qwen-max或qwen2.5-72b-instruct。如果你不确定某个模型支不支持工具调用可以先在模型对话页面发一条带工具描述的消息试一下能正常返回tool_calls字段就说明支持。注意Base URL 末尾不要多加/v1。TaoToken 的接口路径已经包含版本段写成https://taotoken.net/api/v1反而会 404。这一点和某些自建网关的习惯不同容易搞混。Key 和地址准备好之后先别急着写完整 Agent。用一条最简单的 curl 确认连通性能返回正常响应再往下走。这一步花两分钟能省掉后面半小时的瞎猜。curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: qwen-max, messages: [{role: user, content: 回复 ok}] }返回里能看到choices数组和content字段就说明入口是通的。如果这里就报 401先检查 Key 有没有复制完整、有没有多余空格如果报模型不存在去模型列表核对 ID 拼写。连通性确认之后再进入 LangChain 侧的配置。3. 可复制配置LangChain、MCP、Qwen-Agent 三处对齐这一节给可直接复制的配置片段。三处配置的核心都是同一组 Base URL 和 Key区别只在字段名和传参方式。先看 LangChain 侧用ChatOpenAI指向 TaoTokenimport os from langchain_openai import ChatOpenAI llm ChatOpenAI( modelqwen-max, base_urlos.environ[TAOTOKEN_BASE_URL], api_keyos.environ[TAOTOKEN_API_KEY], temperature0.7, streamingTrue, )这里base_url传的是https://taotoken.net/apiChatOpenAI会自动补上/v1/chat/completions。如果你用的是ChatTongyi它走的是 DashScope 协议不能直接改 Base URL 到 TaoToken所以联调统一用ChatOpenAI更省事。接下来是 MCP 适配层。用langchain-mcp-adapters把 MCP Server 的工具加载进来再交给 LangGraph 的create_react_agentimport asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client from langchain_mcp_adapters.tools import load_mcp_tools from langgraph.prebuilt import create_react_agent from langchain_openai import ChatOpenAI import os async def main(): model ChatOpenAI( modelqwen-max, base_urlos.environ[TAOTOKEN_BASE_URL], api_keyos.environ[TAOTOKEN_API_KEY], ) server_params StdioServerParameters( commandpython, args[server.py], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools await load_mcp_tools(session) agent create_react_agent(model, tools) resp await agent.ainvoke( {messages: whats (3 5) x 12?} ) print(resp) if __name__ __main__: asyncio.run(main())Qwen-Agent 侧如果也要接同一入口用它的 OpenAI 兼容模式配置写成这样import os from qwen_agent.agents import Assistant llm_cfg { model: qwen-max, model_server: os.environ[TAOTOKEN_BASE_URL] /v1, api_key: os.environ[TAOTOKEN_API_KEY], } bot Assistant(llmllm_cfg)注意 Qwen-Agent 的model_server需要带/v1后缀这和 LangChain 的base_url写法不同。这是两套框架对路径拼接的处理差异不是配置错误。三处配置对齐之后可以用一张表对照关键字段框架字段名值是否带 /v1LangChain ChatOpenAIbase_urlhttps://taotoken.net/api否Qwen-Agentmodel_serverhttps://taotoken.net/api/v1是MCP 适配层复用 ChatOpenAI同上否如果你用的是 Codex 或 Cline 这类工具配置写在auth.json或 MCP 的 settings 里同样要保证 Base URL、Key、Model ID 三件套齐全。缺任何一个工具调用都会失败。特别是 Model ID写错成不支持的模型名返回的报错往往不是「模型不存在」而是工具调用字段为空容易误判成协议问题。配置写完后先跑一个不带工具的纯对话确认模型能正常返回。再跑带工具的用例观察是否出现tool_calls。分两步走能把「模型入口问题」和「工具协议问题」分开定位。4. 逐项验证连通性、工具调用、流式返回配置对齐之后按三个层次验证。第一层是连通性第二层是工具调用第三层是流式返回。每层都有明确的成功标志不要跳步。连通性验证用上一节的 curl 就够。成功标志是返回 JSON 里有choices[0].message.content。如果返回 401检查 Key如果返回 404检查 Base URL 路径如果连接超时检查网络出口和地址拼写。这一层不涉及工具纯粹确认模型入口可用。工具调用验证用 LangGraph 的create_react_agent。成功标志是返回消息里出现tool_calls字段并且工具执行后有对应的ToolMessage。我实测下来qwen-max对(3 5) x 12这类计算会稳定触发工具调用。如果模型直接给出答案而不调工具说明工具描述不够清晰或者模型本身对工具调用支持较弱换qwen2.5-72b-instruct再试。流式返回验证要单独做因为流式和工具调用叠加时最容易出问题。用streamingTrue发起请求逐块读取async for chunk in llm.astream(用一句话介绍你自己): if chunk.content: print(chunk.content, end, flushTrue)成功标志是内容逐字输出没有卡顿到超时。如果中途报reading choices相关错误通常是响应体被截断或格式不符合预期先关掉流式用普通请求确认模型返回正常再排查流式解析。工具调用和流式叠加时建议先关流式跑通工具再开流式。两者同时开报错信息会混在一起定位成本翻倍。我这次就是先跑通非流式的工具调用再逐步打开流式问题范围小很多。还有一个验证动作是并发。LangGraph 默认可能触发并行工具调用如果你的工具实现不支持并行会看到assert len(message.tool_calls) 1这类断言失败。解决办法是在工具节点里限制并行或者改用支持多工具绑定的模型。ChatTongyi可以绑定多个工具同时使用而 Ollama 部署的 qwen2.5 需要显式指定单个工具多工具会报错。这个差异在联调时要注意。三层验证都通过后再回到完整链路跑一遍端到端用例。这时候如果还有问题基本就是配置细节或网络环境而不是框架本身。5. 常见报错对照401、超时、reading choices、OAuth这一节把真实遇到的报错和定位步骤列出来。每个报错都给出触发条件和排查顺序照着做能快速缩小范围。401 认证失败。触发条件Key 为空、Key 错误、Key 过期、或者请求头没带Authorization。排查顺序先echo $TAOTOKEN_API_KEY确认环境变量有值再用 curl 直接测排除框架干扰最后检查代码里api_key有没有被覆盖成空字符串。我遇到过一次是.env文件里 Key 后面多了个换行复制时带进去了肉眼看不出来用cat -A才看到。超时。触发条件网络不通、Base URL 写错、模型响应慢、或者流式读取卡住。排查顺序先用 curl 测连通性确认不是网络问题再检查 Base URL 有没有多余路径然后关掉流式用普通请求测响应时间。如果普通请求正常、流式超时问题在流式解析不在网络。reading choices报错。触发条件响应体不是预期的 JSON 结构或者流式分块解析时字段缺失。排查顺序打印原始响应体确认返回的是 JSON 而不是 HTML 错误页检查 Base URL 是否指向了错误的端点确认模型 ID 在服务端存在。这个报错经常和 404 混在一起因为错误页被当成响应体解析了。OAuth 相关报错。触发条件某些工具或 MCP Server 需要 OAuth 认证但没配置凭据。排查顺序确认该工具是否必须 OAuth如果是按工具文档配置如果只是测试先用不需要 OAuth 的工具替代。MCP 协议本身在传输层有过调整早期 HTTPSSE 和现在的 Streamable HTTP 不兼容连接方式选错也会报认证类错误。vllm 启动报错。触发条件--enable-auto-tool-choice和--tool-call-parser没成对出现。报错信息是--enable-auto-tool-choice requires --tool-call-parser。解决方法是两个参数一起加并且--tool-call-parser要指定具体解析器比如hermes。只加一个必然启动失败这和 Base URL 无关别混在一起排查。报错首要排查点快速验证401Key 与环境变量curl 直测超时Base URL 与网络关流式测reading choices响应体结构打印原始返回OAuth工具认证配置换无认证工具vllm 启动参数成对加 tool-call-parser排查时记住一个原则先确认模型入口通再确认工具协议通最后确认流式解析通。顺序反了报错会互相掩盖。6. 联调稳定后的下一步链路跑通之后我建议把配置固化成环境变量加配置文件两层。环境变量放 Key配置文件放 Base URL 和模型 ID这样换环境时只改变量不动代码。LangGraph 的 checkpointer 用MemorySaver做测试够用上生产要换成持久化存储否则重启后状态丢失。工具调用这块MCP 协议还在演进传输层从 HTTPSSE 改到 Streamable HTTP 之后客户端和服务端的版本要对齐。如果你用的是langchain-mcp-adapters注意它的版本和 MCP 协议版本的对应关系版本不匹配会出现连接建立但工具加载为空的情况。模型选择上qwen-max在工具调用上比较稳qwen2.5-72b-instruct在多工具场景下表现更好。本地 vllm 部署适合做离线验证但工具调用参数要配对Ollama 则适合单工具快速测试。三种方式各有适用场景不用强求统一。最后留一个实用技巧每次改完配置先跑 curl 连通性再跑纯对话最后跑工具调用。三步都过再提交代码。这个习惯能挡掉大部分低级错误。需要生成新 Key 或查看模型列表去控制台和 API Keys 页面操作想先试模型对话效果直接在模型对话页面发消息验证长期跑编码和 Agent 任务用 Coding Plan 更省心。 LangChain、MCP Server、Qwen-Agent 联调测试记录：把 Base URL 改到 TaoToken 的排查清单
1. 三件套联调为什么总在 Base URL 上翻车LangChain、MCP Server、Qwen-Agent 放在同一条链路里跑最容易出问题的不是模型本身而是「谁在跟谁说话、走的是哪个 Base URL」。我这次的目标很明确让 LangGraph 编排的 Agent 通过 MCP 协议调用工具模型侧统一改到 TaoToken 的 OpenAI 兼容入口同时保留本地 vllm 和 Ollama 的对照测试。适合正在做多模型 Agent 联调、被 401 和超时反复折磨的人。先说清楚这三个东西各自扮演什么角色。LangChain 是编排层负责把消息、工具、状态串起来LangGraph 是 LangChain 之上的状态机用节点和边描述「模型思考→调用工具→再思考」的循环MCP Server 是工具协议层把工具以标准接口暴露出去客户端通过 stdio 或 HTTP 连接Qwen-Agent 则是面向 Qwen 系列的 Agent 框架支持 DashScope 和 OpenAI 兼容两种接入方式。三者能拼在一起的关键是它们都认 OpenAI 风格的/v1/chat/completions接口。问题就出在这里。LangChain 的ChatOpenAI、Qwen-Agent 的 OpenAI 模式、以及langchain-mcp-adapters里加载出来的工具最终都会去读base_url和api_key。只要有一个地方还指向旧的地址或者 Key 没传进去链路就会在某个节点断掉。我实测下来最常见的三种表现是401 认证失败、请求卡住直到超时、以及流式返回时reading choices解析报错。这三种背后对应的配置点完全不同所以排查必须分层做不能一上来就怀疑模型。还有一个容易被忽略的点vllm 本地部署时--enable-auto-tool-choice和--tool-call-parser必须成对出现缺一个直接启动报错。这和 Base URL 无关但很多人会把启动失败误判成接口问题。把这两类问题分开排查效率会高很多。这篇记录按「先统一入口再逐项验证最后对照报错」的顺序写。你可以直接复制配置片段也可以跟着验证动作一步步确认链路是否通。核心检索词就是 LangChain MCP Server Qwen-Agent 联调 Base URL 配置下面所有步骤都围绕它展开。2. TaoToken 前置把 Base URL 和 Key 统一到一处在动 LangChain 代码之前先把模型入口固定下来。我这次所有云端调用都走 TaoToken 的 OpenAI 兼容接口Base URL 用https://taotoken.net/apiKey 在控制台生成。这样做的好处是LangChain、Qwen-Agent、MCP 适配层三处只需要维护同一组地址和密钥改一处即可全局生效不用在每个框架里各配一遍。具体操作路径是先到官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册并进入控制台然后在 API Keys 页面创建一个新 Key。创建时建议按用途命名比如langgraph-mcp-test方便后面区分是哪个链路在用。Key 只在创建时完整显示一次复制后先存到环境变量里不要直接硬编码进代码。环境变量这样设Linux/macOS 用 exportWindows 用 setexport TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api设完之后用echo $TAOTOKEN_API_KEY确认一下有没有生效。我踩过的坑是在 IDE 的终端里设了变量但运行脚本用的是另一个 shell结果代码里读到空值直接 401。所以验证环境变量这一步别省。模型 ID 这块要注意TaoToken 的模型列表里 Qwen 系列和通用模型是分开列的。做工具调用测试时优先选支持 Function Calling 的模型比如qwen-max或qwen2.5-72b-instruct。如果你不确定某个模型支不支持工具调用可以先在模型对话页面发一条带工具描述的消息试一下能正常返回tool_calls字段就说明支持。注意Base URL 末尾不要多加/v1。TaoToken 的接口路径已经包含版本段写成https://taotoken.net/api/v1反而会 404。这一点和某些自建网关的习惯不同容易搞混。Key 和地址准备好之后先别急着写完整 Agent。用一条最简单的 curl 确认连通性能返回正常响应再往下走。这一步花两分钟能省掉后面半小时的瞎猜。curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: qwen-max, messages: [{role: user, content: 回复 ok}] }返回里能看到choices数组和content字段就说明入口是通的。如果这里就报 401先检查 Key 有没有复制完整、有没有多余空格如果报模型不存在去模型列表核对 ID 拼写。连通性确认之后再进入 LangChain 侧的配置。3. 可复制配置LangChain、MCP、Qwen-Agent 三处对齐这一节给可直接复制的配置片段。三处配置的核心都是同一组 Base URL 和 Key区别只在字段名和传参方式。先看 LangChain 侧用ChatOpenAI指向 TaoTokenimport os from langchain_openai import ChatOpenAI llm ChatOpenAI( modelqwen-max, base_urlos.environ[TAOTOKEN_BASE_URL], api_keyos.environ[TAOTOKEN_API_KEY], temperature0.7, streamingTrue, )这里base_url传的是https://taotoken.net/apiChatOpenAI会自动补上/v1/chat/completions。如果你用的是ChatTongyi它走的是 DashScope 协议不能直接改 Base URL 到 TaoToken所以联调统一用ChatOpenAI更省事。接下来是 MCP 适配层。用langchain-mcp-adapters把 MCP Server 的工具加载进来再交给 LangGraph 的create_react_agentimport asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client from langchain_mcp_adapters.tools import load_mcp_tools from langgraph.prebuilt import create_react_agent from langchain_openai import ChatOpenAI import os async def main(): model ChatOpenAI( modelqwen-max, base_urlos.environ[TAOTOKEN_BASE_URL], api_keyos.environ[TAOTOKEN_API_KEY], ) server_params StdioServerParameters( commandpython, args[server.py], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools await load_mcp_tools(session) agent create_react_agent(model, tools) resp await agent.ainvoke( {messages: whats (3 5) x 12?} ) print(resp) if __name__ __main__: asyncio.run(main())Qwen-Agent 侧如果也要接同一入口用它的 OpenAI 兼容模式配置写成这样import os from qwen_agent.agents import Assistant llm_cfg { model: qwen-max, model_server: os.environ[TAOTOKEN_BASE_URL] /v1, api_key: os.environ[TAOTOKEN_API_KEY], } bot Assistant(llmllm_cfg)注意 Qwen-Agent 的model_server需要带/v1后缀这和 LangChain 的base_url写法不同。这是两套框架对路径拼接的处理差异不是配置错误。三处配置对齐之后可以用一张表对照关键字段框架字段名值是否带 /v1LangChain ChatOpenAIbase_urlhttps://taotoken.net/api否Qwen-Agentmodel_serverhttps://taotoken.net/api/v1是MCP 适配层复用 ChatOpenAI同上否如果你用的是 Codex 或 Cline 这类工具配置写在auth.json或 MCP 的 settings 里同样要保证 Base URL、Key、Model ID 三件套齐全。缺任何一个工具调用都会失败。特别是 Model ID写错成不支持的模型名返回的报错往往不是「模型不存在」而是工具调用字段为空容易误判成协议问题。配置写完后先跑一个不带工具的纯对话确认模型能正常返回。再跑带工具的用例观察是否出现tool_calls。分两步走能把「模型入口问题」和「工具协议问题」分开定位。4. 逐项验证连通性、工具调用、流式返回配置对齐之后按三个层次验证。第一层是连通性第二层是工具调用第三层是流式返回。每层都有明确的成功标志不要跳步。连通性验证用上一节的 curl 就够。成功标志是返回 JSON 里有choices[0].message.content。如果返回 401检查 Key如果返回 404检查 Base URL 路径如果连接超时检查网络出口和地址拼写。这一层不涉及工具纯粹确认模型入口可用。工具调用验证用 LangGraph 的create_react_agent。成功标志是返回消息里出现tool_calls字段并且工具执行后有对应的ToolMessage。我实测下来qwen-max对(3 5) x 12这类计算会稳定触发工具调用。如果模型直接给出答案而不调工具说明工具描述不够清晰或者模型本身对工具调用支持较弱换qwen2.5-72b-instruct再试。流式返回验证要单独做因为流式和工具调用叠加时最容易出问题。用streamingTrue发起请求逐块读取async for chunk in llm.astream(用一句话介绍你自己): if chunk.content: print(chunk.content, end, flushTrue)成功标志是内容逐字输出没有卡顿到超时。如果中途报reading choices相关错误通常是响应体被截断或格式不符合预期先关掉流式用普通请求确认模型返回正常再排查流式解析。工具调用和流式叠加时建议先关流式跑通工具再开流式。两者同时开报错信息会混在一起定位成本翻倍。我这次就是先跑通非流式的工具调用再逐步打开流式问题范围小很多。还有一个验证动作是并发。LangGraph 默认可能触发并行工具调用如果你的工具实现不支持并行会看到assert len(message.tool_calls) 1这类断言失败。解决办法是在工具节点里限制并行或者改用支持多工具绑定的模型。ChatTongyi可以绑定多个工具同时使用而 Ollama 部署的 qwen2.5 需要显式指定单个工具多工具会报错。这个差异在联调时要注意。三层验证都通过后再回到完整链路跑一遍端到端用例。这时候如果还有问题基本就是配置细节或网络环境而不是框架本身。5. 常见报错对照401、超时、reading choices、OAuth这一节把真实遇到的报错和定位步骤列出来。每个报错都给出触发条件和排查顺序照着做能快速缩小范围。401 认证失败。触发条件Key 为空、Key 错误、Key 过期、或者请求头没带Authorization。排查顺序先echo $TAOTOKEN_API_KEY确认环境变量有值再用 curl 直接测排除框架干扰最后检查代码里api_key有没有被覆盖成空字符串。我遇到过一次是.env文件里 Key 后面多了个换行复制时带进去了肉眼看不出来用cat -A才看到。超时。触发条件网络不通、Base URL 写错、模型响应慢、或者流式读取卡住。排查顺序先用 curl 测连通性确认不是网络问题再检查 Base URL 有没有多余路径然后关掉流式用普通请求测响应时间。如果普通请求正常、流式超时问题在流式解析不在网络。reading choices报错。触发条件响应体不是预期的 JSON 结构或者流式分块解析时字段缺失。排查顺序打印原始响应体确认返回的是 JSON 而不是 HTML 错误页检查 Base URL 是否指向了错误的端点确认模型 ID 在服务端存在。这个报错经常和 404 混在一起因为错误页被当成响应体解析了。OAuth 相关报错。触发条件某些工具或 MCP Server 需要 OAuth 认证但没配置凭据。排查顺序确认该工具是否必须 OAuth如果是按工具文档配置如果只是测试先用不需要 OAuth 的工具替代。MCP 协议本身在传输层有过调整早期 HTTPSSE 和现在的 Streamable HTTP 不兼容连接方式选错也会报认证类错误。vllm 启动报错。触发条件--enable-auto-tool-choice和--tool-call-parser没成对出现。报错信息是--enable-auto-tool-choice requires --tool-call-parser。解决方法是两个参数一起加并且--tool-call-parser要指定具体解析器比如hermes。只加一个必然启动失败这和 Base URL 无关别混在一起排查。报错首要排查点快速验证401Key 与环境变量curl 直测超时Base URL 与网络关流式测reading choices响应体结构打印原始返回OAuth工具认证配置换无认证工具vllm 启动参数成对加 tool-call-parser排查时记住一个原则先确认模型入口通再确认工具协议通最后确认流式解析通。顺序反了报错会互相掩盖。6. 联调稳定后的下一步链路跑通之后我建议把配置固化成环境变量加配置文件两层。环境变量放 Key配置文件放 Base URL 和模型 ID这样换环境时只改变量不动代码。LangGraph 的 checkpointer 用MemorySaver做测试够用上生产要换成持久化存储否则重启后状态丢失。工具调用这块MCP 协议还在演进传输层从 HTTPSSE 改到 Streamable HTTP 之后客户端和服务端的版本要对齐。如果你用的是langchain-mcp-adapters注意它的版本和 MCP 协议版本的对应关系版本不匹配会出现连接建立但工具加载为空的情况。模型选择上qwen-max在工具调用上比较稳qwen2.5-72b-instruct在多工具场景下表现更好。本地 vllm 部署适合做离线验证但工具调用参数要配对Ollama 则适合单工具快速测试。三种方式各有适用场景不用强求统一。最后留一个实用技巧每次改完配置先跑 curl 连通性再跑纯对话最后跑工具调用。三步都过再提交代码。这个习惯能挡掉大部分低级错误。需要生成新 Key 或查看模型列表去控制台和 API Keys 页面操作想先试模型对话效果直接在模型对话页面发消息验证长期跑编码和 Agent 任务用 Coding Plan 更省心。