《深入理解LangChain多智能体》里那段ChatOpenAI(modelos.getenv(LLM_MODEL_ID), api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://api.openai.com/v1))如果原样搬进 LangGraph 的 understand→search→answer 链路最容易在 search 节点或 answer 节点抛出 401。报错信息通常只写 Unauthorized 或 invalid_api_key智能体之间的状态传递又不会告诉你到底是哪一步的 Key 失效。遇到这种情况先把模型通道换掉打开 TaoToken https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 API Key把代码里的base_url改成https://taotoken.net/apiapi_key换成YOUR_API_KEY再重跑多智能体流程。原文把 5 种架构模式和搜索智能体实战讲得很细但模型初始化一旦卡在默认 OpenAI 地址或旧 Key 上后面的架构设计再漂亮也跑不起来。这篇就沿着原文的搜索智能体实战往下走把 401 排掉再让 understand→search→answer 三个节点真正跑通。1. 复现《深入理解LangChain多智能体》里的 ChatOpenAI 4011.1 原文方式一的 ChatOpenAI 初始化长什么样原文在讲搜索智能体实战时方式一用的是环境变量加ChatOpenAI的组合LLM_MODEL_ID放模型名LLM_API_KEY放密钥LLM_BASE_URL放接口地址默认值是https://api.openai.com/v1。这个写法本身没问题问题在于它假设你手里有一把能直连默认地址的 Key并且这个 Key 在当前网络、当前额度、当前模型权限下都有效。很多读者是把这段代码从文章里复制到自己的.env和agent.py里然后直接运行。单链调用可能还能撑一会儿一旦进入多智能体工作流understand节点先调一次模型search节点可能再调一次answer节点还要调一次。每次调用都重新走一遍ChatOpenAI的鉴权只要其中某个环节的 Key 或 base_url 不一致401 就会在中间某个节点爆出来。更麻烦的是LangGraph 的节点之间通过状态传递search节点拿到的是understand节点写进 state 的内容而不是原始环境变量。你看到 401 时很难一眼判断是understand没跑完还是search里的工具调用触发了额外模型请求还是answer节点用了另一个 Key 实例。所以第一步不是改智能体逻辑而是把模型通道统一掉。1.2 401 出现在 understand→search→answer 的哪一步按照原文的搜索智能体实战understand节点通常做意图识别或问题改写search节点负责调用搜索工具answer节点把搜索结果整理成最终回答。三个节点如果共用同一个llm实例理论上只需要初始化一次。但实际项目里常见两种写法第一种是全局初始化一个llm然后传给各个节点函数。这种写法下 401 一般出现在第一次模型调用也就是understand节点。因为全局实例创建时就会校验 Key 格式运行invoke时如果 Key 无效直接抛 401。第二种是在每个节点内部各自ChatOpenAI(...)方便不同节点用不同温度或不同模型。这种写法下 401 可能出现在search或answer节点尤其是你只在understand节点改了环境变量另外两个节点还在读旧的.env文件或硬编码 Key。还有一种隐蔽情况search节点用了某个搜索工具搜索工具内部又调用了一次模型做结果摘要。你明明只配了一个llm但搜索工具自带了一个默认 OpenAI 客户端结果它在后台用默认 base_url 发请求401 就出现在你完全没注意的第三方工具里。1.3 为什么多智能体里报错比单链更难看懂单链调用报 401堆栈通常指向一行llm.invoke()改环境变量就能解决。多智能体工作流里堆栈会穿过 LangGraph 的节点调度、状态合并、条件边最后才落到某一次 HTTP 请求。你看到的是openai.AuthenticationError但调用栈里可能同时出现understand、search、answer三个函数名分不清是谁触发的。再加上原文的搜索智能体实战里search节点可能返回结构化结果answer节点再把这些结果塞进提示词。如果 401 发生在answer节点search_results已经写进 state 了你会误以为搜索成功了只是最后生成失败。其实搜索工具可能只是返回了缓存或空结果真正的模型调用在最后一步才发生。把 base_url 统一到 TaoToken 的https://taotoken.net/api并且让三个节点共用同一个 Key 和模型 ID这类“到底哪一步挂了”的问题会少很多。因为通道只有一个鉴权失败就集中在一处排查范围从三个节点缩小到一个客户端配置。2. 把 LLM_BASE_URL 指到 TaoToken 的 https://taotoken.net/api2.1 在官网创建 Key、确认模型 ID打开 TaoToken 注册并登录进入控制台创建 API Key。Key 只会完整显示一次复制后先放到密码管理器或临时环境变量里不要直接提交到 Git。接着去模型广场看当前可用的模型 ID。原文里的LLM_MODEL_ID不要继续沿用旧值也不要凭记忆写gpt-4或带日期后缀的名字。模型 ID 以模型广场当时列表为准复制哪个就填哪个。如果你只是先跑通 understand→search→answer可以先选一个通用对话模型把temperature设为 0保证节点输出稳定。搜索智能体实战里understand节点需要判断意图answer节点需要归纳搜索结果两者都可以用同一个模型 ID。等流程跑通后再考虑给search节点换更便宜或更快的模型。这里要注意官网落地页https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end只用来注册、创建 Key、看模型广场和看用量。真正填进ChatOpenAI的base_url是https://taotoken.net/api末尾不要带/v1。这两个地址一个给人点一个给代码用不要混。2.2 .env 三个变量的正确写法原文用.env管理LLM_MODEL_ID、LLM_API_KEY、LLM_BASE_URL这个结构可以保留只改值。不要写死到 Python 文件里也不要在节点函数里硬编码 Key。下面是一个可以直接复制的.env示例LLM_MODEL_ID在模型广场复制的模型 ID LLM_API_KEYYOUR_API_KEY LLM_BASE_URLhttps://taotoken.net/apiLLM_API_KEY必须保留YOUR_API_KEY这个占位符不要把你的真实 Key 写进文章或截图。真实 Key 从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建创建后填到本地.env。LLM_BASE_URL不要加/v1也不要写成https://taotoken.net/api/v1。LangChain 的ChatOpenAI会自己拼接聊天补全路径额外加/v1容易导致 404 或路径重复。如果你用python-dotenv在入口文件第一行加载from dotenv import load_dotenv load_dotenv()加载顺序要早于任何ChatOpenAI初始化。如果某个节点模块在导入时就创建了llm而load_dotenv()写在后面环境变量还没进来api_key会是None同样触发 401。把加载逻辑放在main.py或agent.py最顶部其他模块通过函数参数接收llm避免导入时初始化。2.3 ChatOpenAI 初始化代码的替换原文方式一的初始化可以改成下面这样。核心变化只有两处base_url默认值改成 TaoToken 的接口地址api_key明确从环境变量读取。不要保留https://api.openai.com/v1作为默认回退否则哪天.env没加载成功代码会悄悄走回旧通道401 又会出现。import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI load_dotenv() llm ChatOpenAI( modelos.getenv(LLM_MODEL_ID), api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://taotoken.net/api), temperature0, )这段代码创建出来的llm可以同时给understand、search、answer三个节点使用。如果你的搜索工具内部也会调用模型检查它的初始化参数把同一个base_url和api_key传进去。不要让搜索工具自己读默认配置否则你改完主流程401 会从工具内部冒出来。还有一个细节ChatOpenAI的api_key参数在不同版本里可能是openai_api_key的别名。如果你用的 LangChain 版本较老写成openai_api_keyos.getenv(LLM_API_KEY)也可以。关键是值来自同一个环境变量不要在一个地方写LLM_API_KEY在另一个地方写OPENAI_API_KEY多智能体里环境变量一乱排查成本会翻倍。3. 重跑 LangGraph 的 understand→search→answer 搜索智能体3.1 understand 节点意图识别不再 401understand节点是整条链路的入口通常接收用户问题输出意图、关键词或改写后的查询。原文的搜索智能体实战里这个节点可以用一次简单的llm.invoke()完成。改成 TaoToken 通道后节点代码不需要大改只要确保它用的是上面那个全局llm。from langchain_core.messages import HumanMessage def understand_node(state: dict) - dict: question state[question] prompt f你是一个搜索智能体请判断用户问题的意图并输出一句最适合搜索的查询。 用户问题{question} 只输出查询本身不要解释。 response llm.invoke([HumanMessage(contentprompt)]) return {intent: response.content.strip()}这里容易踩的坑是response.content在部分模型里可能返回列表或多段文本。如果你的模型 ID 返回的是列表直接.strip()会报错。可以先判断类型或者打印一次原始响应看结构。401 解决后下一个常见问题就是响应格式解析不要把它和鉴权错误混在一起。另外understand节点如果失败LangGraph 可能不会继续走search但错误信息会被包装成节点异常。你可以在节点函数外面加一层try/except把原始异常类型和base_url一起打出来。这样下次再遇到 401日志里能直接看到是不是通道问题。3.2 search 节点工具调用与模型选择search节点负责调用搜索工具。原文可能使用 Tavily 或其他搜索 API具体工具按你的项目替换。这个节点本身不一定要调用llm但如果你的实现里包含“搜索关键词扩展”或“结果摘要”就会用到模型。建议把搜索工具和模型分开搜索工具只负责拿原始结果摘要交给answer节点做。def search_node(state: dict) - dict: query state.get(intent) or state[question] try: results search_tool.invoke({query: query}) except Exception as exc: return {search_results: f搜索失败{exc}} return {search_results: str(results)}如果你的search_tool内部需要模型配置在创建工具时传入llm或显式传入base_url和api_key。不要把https://taotoken.net/api只配在主模型上搜索工具走默认 OpenAI 地址的情况并不少见。检查方法很简单在search_node里打印llm._client.base_url或搜索工具的客户端配置确认它指向https://taotoken.net/api。这个节点还有一个隐藏问题搜索工具返回的内容可能很长直接塞进answer节点的提示词会超出上下文。原文的搜索智能体实战可能对结果做了截断。你可以先保留前几条结果或者在answer节点里做摘要。不要因为 401 解决了就把所有原始结果无脑拼进 prompt那样会变成 400 或上下文超限。3.3 answer 节点汇总生成answer节点拿到question和search_results用模型生成最终回答。这个节点通常最耗 token也最容易暴露 Key 问题。如果前面两个节点都用了同一个llm这里直接复用即可。def answer_node(state: dict) - dict: prompt f请根据以下搜索结果回答用户问题。 用户问题{state[question]} 搜索结果 {state[search_results]} 要求回答简洁引用搜索结果中的关键信息。 response llm.invoke([HumanMessage(contentprompt)]) return {answer: response.content.strip()}如果你的多智能体架构里answer节点还会调用其他子智能体确保子智能体也使用同一个llm实例或同一套环境变量。LangGraph 的节点可以嵌套调用其他图但模型配置不会自动继承。子图里如果重新ChatOpenAI()它可能读不到父进程的环境变量从而导致 401。3.4 LangGraph 状态图组装与运行把三个节点组装成状态图跑一次完整流程。下面是一个最小可运行示例状态字段和节点名对应原文的 understand→search→answerfrom typing import TypedDict from langgraph.graph import StateGraph, END class AgentState(TypedDict): question: str intent: str search_results: str answer: str workflow StateGraph(AgentState) workflow.add_node(understand, understand_node) workflow.add_node(search, search_node) workflow.add_node(answer, answer_node) workflow.set_entry_point(understand) workflow.add_edge(understand, search) workflow.add_edge(search, answer) workflow.add_edge(answer, END) app workflow.compile() if __name__ __main__: result app.invoke({question: LangChain 多智能体有哪些常见架构模式}) print(result[answer])运行前先单独测试llm.invoke([HumanMessage(content你好)])确认模型通道可用。如果这一步就 401不要继续跑 LangGraph先回到第 2 节检查.env和base_url。如果单次调用成功但状态图跑到search节点报 401重点检查搜索工具是否用了另一个客户端。如果状态图跑到answer报 401检查子图或嵌套智能体是否重新初始化了模型。4. 401 消失后的验证与排障4.1 用模型对话发一条测试消息配置保存后不要只看终端有没有报错。先在 TaoToken 模型对话 里用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 没填错。模型对话里能正常返回说明 Key 有效、模型 ID 存在、通道可达。回到代码里再跑understand节点如果仍然 401问题大概率在环境变量加载顺序或代码里硬编码了旧 Key。测试时注意区分“模型对话能用”和“代码能用”。模型对话走的是网页端代码走的是https://taotoken.net/api。两者共用同一把 Key但代码里的base_url如果写成https://taotoken.net/api/v1网页端正常代码仍然会 404 或 401。所以测试通过后再打印一次代码里的llm._client.base_url确认它和预期一致。4.2 常见错误对照401、404、base_url 多 /v1401 通常有三种原因Key 复制不完整、.env没加载、代码里还残留https://api.openai.com/v1。检查os.getenv(LLM_API_KEY)是否返回None再检查base_url是否指向https://taotoken.net/api。404 多数是路径问题。ChatOpenAI会自动拼接/chat/completions如果你把base_url写成https://taotoken.net/api/v1最终请求可能变成/api/v1/chat/completions和实际路径不匹配。保持base_url为https://taotoken.net/api不要在末尾加/v1。还有一种 401 是模型 ID 写错。某些通道在模型不存在时也会返回鉴权类错误避免被误导。去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场复制准确的模型 ID不要用旧文章里的示例值。模型广场会随可用模型变化以当时列表为准。4.3 看用量与日志多智能体跑通后去控制台看这次调用是否记上账。重点看三件事调用时间是否对应你刚才的运行时间模型 ID 是否是你配置的那个token 消耗是否落在合理范围。如果调用记录里只有一次但你的状态图有三个节点说明可能只有understand节点真正调用了模型search和answer走了缓存或没触发模型请求。日志方面建议在ChatOpenAI初始化后打印一次非敏感信息model、base_url的前缀、api_key是否存在。不要打印完整 Key。这样每次跑多智能体终端里都能确认通道没变。如果某天突然 401看日志第一行就能判断是环境变量丢了还是 Key 过期了。5. 下一步把同一把 Key 接到更多 LangChain 多智能体架构5.1 五种架构模式里模型统一走 TaoToken原文讲了 5 种架构模式搜索智能体只是其中一种落地方式。无论你后面试 Network、Supervisor、Hierarchical 还是自定义多智能体模型初始化都可以复用同一套环境变量。把ChatOpenAI的创建封装成一个函数所有架构从同一个入口拿llm这样切换架构时不用反复改 base_url。def build_llm() - ChatOpenAI: return ChatOpenAI( modelos.getenv(LLM_MODEL_ID), api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://taotoken.net/api), temperature0, )封装之后搜索智能体、监督者智能体、层级智能体都调用build_llm()。如果某个架构需要不同温度可以加参数覆盖但base_url和api_key保持统一。多智能体项目里最怕的就是每个 Agent 各自读一份配置最后 401 出现时不知道是哪份配置失效。5.2 去控制台核对这次多智能体调用配完并跑通 understand→search→answer 之后打开 控制台 API Keys 确认 Key 状态再去 模型对话 用同一把 Key 发一条测试消息最后看用量页面对应时间段的调用记录。如果打算长期跑多智能体工作流可以打开 Coding Plan 看套餐是否覆盖你的 token 消耗。需要把这些配置写进 Claude Code 或其他命令行工具时参数对照见 Claude Code 接入文档。回到代码本身401 解决后真正要盯的是节点之间的状态传递和搜索结果格式。多智能体不是把三个函数串起来就完事understand输出的查询质量、search返回的结果长度、answer的提示词结构都会影响最终回答。先把通道跑稳再逐个节点调提示词比一开始就怀疑架构设计要省时间。