1. 从“调用黑盒”到“成本可见”LLM 应用可观测的真实痛点做 LangChain 或 Agent 应用的朋友大概率遇到过这种场景本地跑一个多轮对话 Agent日志里只看到HTTP 200但用户反馈“回答变慢了”“这个月账单怎么涨了”你打开代码一看ChatOpenAI、ChatAnthropic、某个国产模型混着调每个请求的 Token 消耗、首 Token 延迟、重试次数全散落在不同 SDK 的日志里。这就是 LLM 应用可观测要解决的核心问题——不是“能不能调通”而是“每一次调用花了多少 Token、慢在哪一步、哪个 Prompt 在偷偷烧钱”。AI 可观测AI Observability这个词这两年从 APM 圈延伸过来落到 LLM 场景至少要覆盖三层调用链追踪哪次 Agent 决策触发了哪次模型请求、Token 与成本归因按模型、按会话、按 Prompt 模板拆、质量与延迟指标首 Token 延迟、端到端耗时、错误率。传统 Prometheus Grafana 能监控 QPS 和 P99但拿不到prompt_tokens和completion_tokens这种业务级指标因为模型网关那层你没接进去。我试过直接在 LangChain 里挂CallbackHandler打日志问题是每个模型供应商的返回结构不一样OpenAI 的usage字段和 Anthropic 的usage.input_tokens对不上写一堆 if-else 之后代码比业务逻辑还长。更麻烦的是多模型混用——你不可能给每个供应商单独维护一套 Key 和监控。所以这篇要讲的落地路径是用 TaoToken 做统一 Key 入口把模型调用收敛到一个 Base URL再通过 LangChain 回调把 Token 和延迟指标接出来形成一条端到端可验证的可观测链路。适合谁看正在用 LangChain / LangGraph / 自研 Agent 框架已经过了“能跑通”阶段、开始关心成本和稳定性的开发者。如果你还在纠结选哪个模型这篇也能帮你把“选型”和“观测”解耦——模型可以换观测链路不用重写。2. TaoToken 统一 Key 前置把多模型调用收敛到一个入口在讲配置之前先说清楚 TaoToken 在这个链路里的角色。它提供的是兼容 OpenAI 接口规范的 API 入口你可以把它理解成一个“模型调用的统一网关”Base URL 固定为https://taotoken.net/api用同一个 API Key 就能调用不同厂商的模型模型 ID 通过请求参数区分。对 LangChain 来说这意味着你不需要为每个供应商装不同的langchain-xxx包统一用ChatOpenAI指向 TaoToken 的 Base URL 即可。这一步的价值在可观测上很直接所有模型请求都经过同一个出口Token 用量、延迟、错误码的采集点就统一了。否则你在 LangChain 里挂三个 Callback每个供应商的字段名还不一样归因逻辑会写得很痛苦。前置准备分三件事第一拿到 API Key。访问https://taotoken.net/api-keys带 UTM?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content在控制台创建一个 Key。建议按环境分 Key比如dev-langchain、prod-agent这样后面做成本归因时能直接按 Key 维度拆。第二确认模型 ID。TaoToken 的模型列表在文档里能查到常见的有gpt-4o、claude-3-5-sonnet、deepseek-chat这类命名。注意模型 ID 是请求参数不是 Base URL 的一部分所以切换模型不用改配置结构。第三环境变量约定。我习惯用TAOTOKEN_API_KEY和TAOTOKEN_BASE_URL两个变量避免 Key 硬编码进代码。.env文件这样写TAOTOKEN_API_KEYsk-你的实际Key TAOTOKEN_BASE_URLhttps://taotoken.net/api这里有个容易踩的坑Base URL 末尾不要带/v1。LangChain 的ChatOpenAI内部会拼/chat/completions如果你写成https://taotoken.net/api/v1最终请求路径会变成/api/v1/chat/completions部分模型会返回 404。实测下来https://taotoken.net/api是正确写法。另外如果你用的是 Claude Code 这类工具配置方式不一样需要走 Anthropic 兼容入口文档里有单独说明https://taotoken.net/doc。但 LangChain 场景统一用 OpenAI 兼容接口就行不用折腾两套。前置做完后你的调用链应该是LangChain Agent → ChatOpenAI(Base URLTaoToken) → TaoToken 网关 → 实际模型。可观测的采集点就落在 ChatOpenAI 的回调和 TaoToken 的用量返回上。3. 可复制配置LangChain TaoToken 的 settings 与回调接入这一节给可直接复制的配置片段。先装依赖pip install langchain langchain-openai python-dotenv如果你用 LangGraph 或 AgentExecutor额外装langchain-community即可核心的ChatOpenAI在langchain-openai里。3.1 基础模型配置Pythonimport os from dotenv import load_dotenv from langchain_openai import ChatOpenAI load_dotenv() llm ChatOpenAI( modelgpt-4o, # 换成 claude-3-5-sonnet / deepseek-chat 都行 api_keyos.getenv(TAOTOKEN_API_KEY), base_urlos.getenv(TAOTOKEN_BASE_URL), temperature0.3, max_tokens1024, timeout60, max_retries2, )这段配置的关键参数说明参数作用可观测相关model模型 ID决定路由到哪个厂商成本归因的第一维度base_url固定为 TaoToken 入口统一采集点max_retries失败重试次数重试会放大 Token 消耗需监控timeout单次请求超时配合延迟指标定位卡顿3.2 自定义 Callback 采集 Token 与延迟LangChain 的BaseCallbackHandler提供了on_llm_end和on_llm_error钩子response对象里能拿到token_usage。下面是一个最小可用的采集器import time from langchain_core.callbacks import BaseCallbackHandler class ObservabilityCallback(BaseCallbackHandler): def __init__(self): self.start_time {} def on_llm_start(self, serialized, prompts, run_idNone, **kwargs): self.start_time[run_id] time.time() def on_llm_end(self, response, run_idNone, **kwargs): latency time.time() - self.start_time.pop(run_id, time.time()) usage response.llm_output.get(token_usage, {}) prompt_tokens usage.get(prompt_tokens, 0) completion_tokens usage.get(completion_tokens, 0) total usage.get(total_tokens, 0) model response.llm_output.get(model_name, unknown) print(f[LLM] model{model} latency{latency:.2f}s fprompt{prompt_tokens} completion{completion_tokens} total{total}) def on_llm_error(self, error, run_idNone, **kwargs): print(f[LLM ERROR] run_id{run_id} error{error})挂到调用上callback ObservabilityCallback() result llm.invoke(用一句话解释什么是 AI 可观测, config{callbacks: [callback]}) print(result.content)跑一次你会看到类似输出[LLM] modelgpt-4o latency1.83s prompt18 completion42 total60这就是可观测链路的最小闭环模型名、延迟、Token 三个核心指标都出来了。生产环境里把print换成打点到 Prometheus 或写入 ClickHouse 即可。3.3 Agent 场景的配置差异如果你用AgentExecutorCallback 要挂在executor.invoke的 config 上而不是单个 llm 上否则拿不到工具调用和多次 LLM 请求的完整链路from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain_core.prompts import ChatPromptTemplate prompt ChatPromptTemplate.from_messages([ (system, 你是一个助手可以调用工具。), (human, {input}), (placeholder, {agent_scratchpad}), ]) agent create_openai_tools_agent(llm, tools[], promptprompt) executor AgentExecutor(agentagent, tools[], verboseFalse) result executor.invoke( {input: 帮我查一下今天的天气}, config{callbacks: [callback]} )Agent 场景下一次invoke可能触发多次 LLM 调用Callback 的on_llm_start/on_llm_end会成对出现用run_id区分。这样你就能看到“Agent 决策花了 2 次模型调用第一次 800ms第二次 1.2s”这种粒度。4. 验证请求用 Token 用量与延迟指标跑通端到端检查配置写完不算完得验证链路真的通了。这一节给一个可执行的检查清单按顺序跑一遍每步都有预期结果。4.1 第一步裸请求验证 Key 和 Base URL先不挂 LangChain用curl直接打 TaoToken确认 Key 有效、模型可调curl -s https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o, messages: [{role: user, content: ping}], max_tokens: 10 }预期返回里包含choices和usage字段usage.total_tokens应该是个小数字10 以内。如果返回 401说明 Key 有问题返回 404检查 Base URL 是不是多写了/v1。4.2 第二步LangChain 单次调用验证跑 3.2 节的代码预期看到[LLM]日志latency在 1-3 秒之间取决于模型total等于prompt completion。如果token_usage是空字典说明该模型没返回 usage 字段需要换模型或检查 TaoToken 的响应格式。4.3 第三步多模型切换验证把model改成claude-3-5-sonnet再跑一次预期日志里model字段变化Token 计数逻辑不变。这一步验证的是“统一 Key 下多模型可观测的一致性”——不用改采集代码换模型后指标照常出来。4.4 第四步Agent 多轮调用验证跑 3.3 节的 Agent 代码预期看到多条[LLM]日志每条有独立run_id。统计一下总 Token 和总延迟这就是一次 Agent 交互的真实成本。4.5 检查清单汇总检查项预期结果不通过时的排查方向curl 裸请求返回 choices usage401 查 Key404 查 Base URLLangChain 单次调用日志有 model/latency/tokentoken_usage 空则换模型多模型切换model 字段变化指标正常模型 ID 拼写Agent 多轮多条日志run_id 不同Callback 挂载位置延迟基线首 Token 1-3s 可接受超时参数、网络成本归因按 model 聚合 total_tokens采集器字段映射跑完这六项你的可观测链路就算端到端验证过了。后面接 Grafana 或自建看板数据源就是 Callback 里那几个字段。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节按真实报错来。以下四个是我在接入过程中实际遇到过的每个都给现象、原因、修复。5.1 401 Unauthorized现象curl 或 LangChain 调用返回{error: {message: Invalid API key, type: invalid_request_error}}。原因通常有三个Key 复制时带了空格或换行.env文件没被load_dotenv()加载Key 被删除或过期。修复先echo $TAOTOKEN_API_KEY确认变量有值且无空格。如果用的是 IDE 的 Run 配置检查环境变量有没有覆盖.env。Key 本身的问题去https://taotoken.net/api-keys重新生成一个。5.2 local proxy failed现象LangChain 报APIConnectionError: Connection error或local proxy failed。这个报错关键词是“proxy”但原因不一定是代理。常见情况是base_url写错导致请求打到了本地某个端口或者系统环境变量里有HTTP_PROXY/HTTPS_PROXY指向了一个不可用的地址。检查方式env | grep -i proxy如果有输出且不是你预期的临时清掉再跑unset HTTP_PROXY HTTPS_PROXY另外确认base_url是https://taotoken.net/api不是http://localhost:xxxx。5.3 reading choices 相关报错现象KeyError: choices或reading choices报错通常出现在自定义解析代码里。原因是响应结构和你预期的不一致。比如模型返回了错误对象而不是正常 completion你的代码直接取response[choices][0]就会炸。修复方式是先判断response里有没有error字段data response.json() if error in data: raise RuntimeError(fAPI error: {data[error]}) choices data.get(choices, []) if not choices: raise RuntimeError(fEmpty choices: {data})LangChain 内部已经做了这层判断所以如果你用ChatOpenAI还遇到这个报错大概率是自己写了requests调用。5.4 OAuth 相关报错现象报OAuth token expired或invalid_grant。TaoToken 的 API Key 是静态 Bearer Token不走 OAuth 流程。如果你看到 OAuth 报错说明请求打到了别的服务或者代码里混入了其他 SDK 的认证逻辑。检查base_url和api_key参数有没有被其他配置覆盖。Claude Code 场景下走的是 Anthropic 兼容入口配置方式不同参考https://taotoken.net/doc里的说明。5.5 三件套检查法遇到任何接入问题先核对三件套Base URLhttps://taotoken.net/api不带/v1API Keysk-开头无空格Model ID从文档模型列表里复制别手打这三项对了90% 的报错能排除。6. 从可观测到可行动把指标接进你的日常流程链路跑通之后指标怎么用才是关键。我自己的做法是分三层第一层实时日志。Callback 里的print换成结构化日志JSON 格式打到 stdout容器环境里直接被日志系统收走。这样出问题时能快速 grep 某个run_id的完整调用链。第二层聚合看板。把total_tokens按model和session_id聚合每天看一次趋势。异常点通常是某个 Prompt 模板改坏了导致 Token 暴涨或者某个模型延迟劣化。这一步用 Prometheus 的 Counter 和 Histogram 就能做不需要上重型平台。第三层成本告警。给total_tokens设日环比阈值超过 30% 触发告警。Agent 场景下特别有用因为多轮调用容易失控。如果你还在选型阶段建议先用 TaoToken 的统一 Key 把调用收敛再挂一个最小 Callback 采集器跑一周拿到真实数据后再决定要不要上完整的可观测平台。这样避免一开始就陷入工具对比而是先有数据、再有决策。需要长期跑 Agent 或编码任务的可以看下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content按用量计费比按次调用更适合高频场景。验证模型效果直接去模型对话页https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content试。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentKey 管理在https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。最后留一个实用技巧Callback 里的run_id建议和你的业务session_id做关联比如在on_llm_start时从metadata里取。这样排查问题时能从“用户反馈慢”直接定位到“哪次模型调用慢”而不是翻一堆日志。这个关联字段设计好了后面接任何可观测后端都不用改采集逻辑。