1. 从一次 JSON 解析失败说起工具调用链路到底难在哪如果你正在做 Agent 或者工具调用相关的开发大概率遇到过这种场景模型明明该返回一个干净的 JSON结果它先给你来一段“好的我来分析一下”再吐两个重复的 JSON 对象最后json.loads直接抛Extra data。这不是模型不行而是工具调用链路缺少统一约束。大模型的工具调用能力其实经历了三层演进。第一层是function call解决的是“模型怎么把自然语言意图翻译成结构化调用”的问题核心是 schema 定义和参数传递。第二层是思维链 COT解决的是“复杂任务怎么拆成可执行步骤”的问题让模型先规划再动手。第三层是MCP 协议解决的是“上下文怎么标准化接入、多轮对话怎么维护状态”的问题把函数调用、对话历史、多步骤计划统一到一套消息格式里。这三层不是替代关系而是叠加关系。你完全可以在 MCP 的消息结构里跑 COT 的步骤分解每一步再落到具体的 function call 上。本文要做的就是用TaoToken 统一 Key/API 通道把这三层串起来给你一套可复制的settings.json和config.toml配置骨架再逐层验证 function call、COT、MCP 是否真的生效。适合正在搭 Agent、写工具调用、被 JSON 解析折磨过的开发者。2. TaoToken 前置统一 Key 与 API 通道怎么接在动手写调用链路之前先把通道打通。TaoToken 在这里的角色是统一的模型接入层你不需要为每个模型单独维护一套 Key 和 endpoint用一个 Key 就能切换不同模型这对调试工具调用特别重要——因为不同模型对 JSON 格式的遵循程度不一样你需要快速对比。先拿到 API Key。访问控制台创建https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite创建完 Key 之后基础接入信息如下项目值API Basehttps://taotoken.net/api鉴权方式Authorization: Bearer 你的Key对话接口/v1/chat/completions模型列表/v1/models这里有个坑要提前说API Base 不要加 UTM 参数只有官网和控制台链接才带。很多人在配置里把带参数的完整 URL 填进去结果请求 404。正确的做法是 base 只填https://taotoken.net/api路径在代码里拼。如果你用的是 Claude Code 这类编码工具或者要跑长期的 Agent 任务建议直接看 Coding Plan它把额度和通道都打包好了https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite接入文档在这里遇到参数问题先查它https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite3. 可复制配置settings.json 与 config.toml 骨架配置分两种场景。一种是给编辑器/编码工具用的settings.json一种是给 Python 项目或 CLI 用的config.toml。两个都给你按需取用。3.1 settings.json编辑器与工具链接入这个文件适合放在项目根目录或者工具的配置目录下。核心是把 base URL、Key、模型名分开管理方便切换。{ provider: taotoken, api_base: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, default_model: claude-sonnet-4-20250514, timeout_seconds: 60, max_retries: 2, tool_calling: { enabled: true, strict_json: true, max_tool_rounds: 5, parallel_tool_calls: false }, logging: { level: INFO, file: function_call.log, log_raw_response: true } }几个参数值得单独说。strict_json打开后会在提示词里强制约束模型只输出 JSON这是解决Extra data报错的第一道防线。max_tool_rounds限制工具调用的最大轮数防止 COT 递归调用时无限循环。log_raw_response一定要开调试工具调用时原始响应比解析后的结果更有价值。3.2 config.tomlPython 项目与 CLI 接入如果你用 Python 直接调或者用支持 TOML 的 CLI 工具用这份[provider] name taotoken api_base https://taotoken.net/api api_key ${TAOTOKEN_API_KEY} default_model claude-sonnet-4-20250514 [request] timeout 60 max_retries 2 temperature 0.7 max_tokens 1024 [tool_calling] enabled true strict_json true max_tool_rounds 5 [cot] enabled true max_steps 6 require_step_description true [mcp] enabled true message_roles [system, user, assistant, function] keep_history true[cot]段控制思维链的行为max_steps防止模型把简单任务拆成十几步。[mcp]段定义消息角色这是 MCP 协议标准化的关键——所有交互都通过messages列表传递而不是拼字符串。环境变量这样设export TAOTOKEN_API_KEYsk-你的Key4. 逐层验证function call、COT、MCP 是否真的生效配置只是骨架真正要确认的是三层能力有没有跑通。下面按 function call → COT → MCP 的顺序每层给一个可执行的验证动作。4.1 第一层验证 function call 是否生效先定义一个最简单的工具 schema然后发一个明确需要调用工具的请求。关键观察点是模型返回里有没有结构化的tool_calls字段参数对不对。import os import json from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlhttps://taotoken.net/api ) tools [ { type: function, function: { name: search_product, description: 根据名称在数据库中搜索产品, parameters: { type: object, properties: { product_name: { type: string, description: 要搜索的产品名称 } }, required: [product_name] } } } ] resp client.chat.completions.create( modelclaude-sonnet-4-20250514, messages[ {role: user, content: 帮我查一下 iPhone 14 的信息} ], toolstools, tool_choiceauto ) msg resp.choices[0].message print(finish_reason:, resp.choices[0].finish_reason) print(tool_calls:, msg.tool_calls)如果 function call 生效你会看到finish_reason是tool_calls并且msg.tool_calls里有search_product和{product_name: iPhone 14}。如果finish_reason是stop说明模型选择直接回答没走工具——这时候检查你的tool_choice和提示词或者换个对工具调用支持更好的模型。拿到tool_calls之后执行本地函数把结果以role: tool塞回消息列表再发一次请求tool_call msg.tool_calls[0] args json.loads(tool_call.function.arguments) result search_product_in_db(args[product_name]) messages [ {role: user, content: 帮我查一下 iPhone 14 的信息}, msg, { role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) } ] final client.chat.completions.create( modelclaude-sonnet-4-20250514, messagesmessages, toolstools ) print(final.choices[0].message.content)这一步跑通说明 function call 的完整闭环没问题模型决策 → 参数提取 → 本地执行 → 结果回填 → 最终回答。4.2 第二层验证 COT 是否真的在拆步骤COT 的验证不能只看最终答案要看中间步骤。做法是加一个reason_step_by_step工具让模型把复杂查询拆成步骤计划然后你检查返回的steps数组。tools.append({ type: function, function: { name: reason_step_by_step, description: 将复杂查询分解为多个推理步骤可调用其他函数, parameters: { type: object, properties: { query: { type: string, description: 要分析的用户查询 } }, required: [query] } } }) resp client.chat.completions.create( modelclaude-sonnet-4-20250514, messages[ {role: user, content: 对比 iPhone 14 和 Galaxy S23} ], toolstools, tool_choiceauto ) msg resp.choices[0].message if msg.tool_calls: for tc in msg.tool_calls: print(tc.function.name, tc.function.arguments)如果 COT 生效模型应该调用reason_step_by_step参数里带上完整查询。然后你在本地实现这个函数时让它返回一个步骤计划比如{ steps: [ {description: 查询 iPhone 14 信息, function_call: {name: search_product, arguments: {product_name: iPhone 14}}}, {description: 查询 Galaxy S23 信息, function_call: {name: search_product, arguments: {product_name: Galaxy S23}}}, {description: 对比两者参数, function_call: null} ] }验证要点步骤数量是否合理别超过max_steps、每步的function_call是否指向真实存在的工具、最后一步是不是汇总而非继续调用。如果模型把简单查询也拆成五步说明提示词约束不够加一句“简单查询直接回答不要拆步骤”。4.3 第三层验证 MCP 消息结构是否标准化MCP 的核心是用 messages 列表维护完整上下文而不是每次拼新字符串。验证方法是跑一个多轮任务检查对话历史里 role 是否规范、函数结果有没有正确回填。messages [ {role: system, content: 你是一个支持工具调用的助手。}, {role: user, content: 对比 iPhone 14 和 Galaxy S23} ] for round_idx in range(5): resp client.chat.completions.create( modelclaude-sonnet-4-20250514, messagesmessages, toolstools ) msg resp.choices[0].message messages.append(msg) if not msg.tool_calls: print(最终回答:, msg.content) break for tc in msg.tool_calls: fn tc.function.name args json.loads(tc.function.arguments) print(f[round {round_idx}] 调用 {fn} 参数 {args}) if fn search_product: result search_product_in_db(args[product_name]) elif fn reason_step_by_step: result {steps: [...]} else: result {error: unknown function} messages.append({ role: tool, tool_call_id: tc.id, content: json.dumps(result, ensure_asciiFalse) })跑完之后打印messages检查三件事role是否只有system/user/assistant/tool四种、每个tool消息有没有对应的tool_call_id、assistant消息里的tool_calls和后续tool结果是否一一对应。这三条都满足MCP 的消息结构就算标准化了。5. 本篇常见错排查工具调用链路的报错集中在几个地方按出现频率排一下。JSON 解析报Extra data。这是最常见的。模型在 JSON 后面又跟了一段解释或者返回了两个 JSON 对象。解决分两步提示词里明确加“只输出一个 JSON 对象不要包含任何解释或重复内容”解析时用re.findall取最后一个完整 JSON而不是re.search取第一个。取最后一个的原因是模型有时会先输出一个草稿再输出正式版最后一个通常才是完整的。Invalid response structure。模型返回的 JSON 里没有role和content而是直接给了{name: ..., arguments: ...}。这是格式兼容问题加一层转换如果检测到name和arguments字段就包装成标准的 function call 结构。别指望模型每次都严格遵循格式代码要能兜底。工具调用死循环。COT 递归调用时模型可能反复调用reason_step_by_step而不收敛。两个措施设置max_tool_rounds硬上限在reason_step_by_step的返回里明确告诉模型“这是最后一步请直接汇总”。参数类型不对。模型有时把arguments返回成字符串而不是对象json.loads一下就好。但要注意如果字符串本身不是合法 JSON就得走修复逻辑单引号转双引号、补全缺失的右括号。模型不调用工具直接回答。检查tool_choice是不是auto检查工具描述是否清晰检查用户 query 是否真的需要工具。有时候是模型判断不需要工具这时候别硬逼换个更明确的 query 再测。请求 404 或 401。404 通常是 base URL 拼错了确认是https://taotoken.net/api加上/v1/chat/completions。401 是 Key 问题去控制台重新生成一个https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite6. 把三层串起来一个可调试的调用链路回到最开始的问题怎么让 function call、COT、MCP 协同工作而不是各管各的。我的做法是用 MCP 的消息结构做容器用 COT 做规划层用 function call 做执行层。具体流程是这样用户 query 进来先走reason_step_by_step让模型拆步骤返回一个steps数组。然后遍历每个 step如果 step 里有function_call就执行对应的本地函数把结果以role: tool回填到 messages。所有步骤执行完再发一次请求让模型汇总。整个过程 messages 列表始终维护着完整上下文这就是 MCP 标准化的价值。调试的时候把log_raw_response打开每次请求的原始响应都记下来。对比“模型返回了什么”和“你解析出了什么”大部分问题一眼就能定位。如果模型返回的格式总是不稳定换个模型试试——不同模型对工具调用的遵循度差异很大这也是用 TaoToken 统一通道的好处切换成本低。想直接看模型对话效果可以在这里试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite长期跑编码或 Agent 任务Coding Plan 更划算https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite接入细节和参数说明都在文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite最后给一个实用建议先把 function call 单独跑通再加 COT最后套 MCP 的消息结构。三层一起上出问题你根本不知道是哪层的锅。逐层验证每层留好日志链路自然就稳了。