你在原文第10步把 Function Calling 和流式输出拼在一起日志里却只看到 delta.content 一段段往外吐tool_calls 像被谁吞了重启进程、换网络、甚至怀疑 TaoToken 通道不通。别急着改通道配置先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 核对 Key 和 Base URL再把 stream 里的 tool_call 片段按 index 缓存起来。TaoToken 只提供 Key 和统一 Base URL不替你的 Agent 缓存 tool_calls缓存和工具执行仍照原文写。很多开发者把片段处理问题误判成模型通道故障结果在接入层来回折腾真正该改的循环却一行没动。1. 先看现场流式输出里 tool_calls 为什么像“消失”了1.1 一个常见日志只有 content没有 tool_calls你发一个带 tools 定义的流式请求期望模型先返回一段文字然后吐出 tool_calls。实际日志里只有delta.content: 杭州 delta.content: 今天 delta.content: 多云 finish_reason: stop工具一个都没执行。这时人容易判断模型不调工具。但把同一个请求改成 streamFalsetool_calls 却完整出现。问题不在模型而在流式解析。流式下 tool_calls 不是一次性给一个完整 JSON而是拆成多个 delta分散在若干 chunk 里。你只打印 delta.content当然看不见。1.2 三种“看起来像通道不通”的片段现象第一种tool_calls 的 arguments 分片到达你每个 chunk 都 json.loads前几个 chunk 是{city:直接抛 JSONDecodeError进程挂掉。第二种多个 tool_calls 同时返回index 为 0 和 1你只取第一个第二个被覆盖。第三种stream 结束后才出现 finish_reasontool_calls但你的循环只处理 content结束后没有回头读缓存。这三类都跟 Base URL、Key 没有直接关系却最容易被当成通道故障。1.3 先分清“模型没调工具”和“片段没拼对”分辨方法很直接先用非流式请求跑同一组 messages 和 tools。如果非流式返回 tool_calls说明模型和工具定义都正常通道也通问题在流式片段处理。如果非流式也没有 tool_calls再去查工具 schema 的 description、required 字段或者模型是否支持 Function Calling。这个顺序能省掉大量无效重启。原文第4步说 description 直接影响调用准确率排障时也要把它算进去。2. 回到原文概念Function Calling、Tool Use、Skill、MCP 在流式里的分工2.1 Function Calling 是模型原生能力流式只是传输层原文第1步把 Function Calling 定义为模型原生能力不是框架给的。模型在 API 层识别工具定义决定是否调用。流式输出不改变这个能力只改变结果的到达方式。所以你不能把“流式里没看到完整 tool_calls”等同于“模型没有 Function Calling 能力”。更准确的说法是传输层把一次调用拆成了多个片段你的接收端没有组装。2.2 Tool Use 是上层循环缓存策略属于你的 Agent 代码Tool Use 是上层概念模型输出工具调用代码执行函数结果回送模型。在流式场景里这个循环多了一步——先把片段缓存成完整的 tool_call再执行。缓存逻辑不在模型里也不在统一通道里而在你的 Agent 循环里。原文第10步的策略很明确缓存 tool_call 片段stream 结束后再执行工具工具执行结果不再流式直接送入模型。这句要原样理解成代码结构而不是配置项。2.3 为什么 TaoToken 只负责 Key 通道TaoToken 在接入层提供的是 Key 和 Base URL让请求能走统一通道到达模型。它不会替你的 Agent 维护 tool_calls 缓冲也不会在 stream 中间帮你执行工具。把这点想清楚排障边界就清楚了401、404、模型 ID 不对去查通道配置arguments 拼接失败、工具没执行、结果没回送去查 Agent 循环。两边混在一起查只会越查越乱。3. 模型接入层去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 创建 KeyBase URL 填 https://taotoken.net/api3.1 创建 Key 和确认模型 ID打开 TaoToken 注册并进入控制台创建 API Key。Key 用占位符 YOUR_API_KEY 写进环境变量不要硬编码进仓库。模型 ID 不要凭记忆写以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 模型广场当时的列表为准。原文第3步说接入层要支持 chat、stream、embed 三种模式本文只跑通 stream tools先别把嵌入模型混进来。3.2 最小接入代码下面这段不是完整 Agent只负责把流式请求接到统一通道并把 tool_calls 片段打印出来。你可以先不执行工具只看缓存结果是否正确。import os from openai import OpenAI client OpenAI( api_keyos.environ.get(TAOTOKEN_API_KEY, YOUR_API_KEY), base_urlhttps://taotoken.net/api, ) tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气用户明确问天气时调用, parameters: { type: object, properties: { city: { type: string, description: 城市名例如杭州, } }, required: [city], }, }, } ] stream client.chat.completions.create( modelYOUR_MODEL_ID, # 以模型广场当时列表为准 messages[{role: user, content: 杭州今天天气怎么样}], toolstools, streamTrue, ) for chunk in stream: delta chunk.choices[0].delta if chunk.choices else None if delta is None: continue if delta.content: print(content:, delta.content) if delta.tool_calls: print(tool_calls delta:, delta.tool_calls)跑起来后如果能看到tool_calls delta说明请求已经到达模型并触发了工具调用意图。接下来要做的就是把片段拼起来。3.3 Base URL 不要加 /v1也不要带 UTM填进工具的 Base URL 是https://taotoken.net/api末尾不要加/v1。官网落地页https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content只用于注册、创建 Key、看模型广场和看用量不要把它填进base_url。把 UTM 参数带进接口地址会让请求路径变成错误路径表现为 404 或连接异常。排障时先看一眼配置文件里这一行能排除不少低级问题。4. 原文第10步的缓存实现按 index 归并 tool_call 片段4.1 chunk 里 tool_calls 长什么样流式返回的delta.tool_calls通常是一个列表每个元素带index、id、type、function.name、function.arguments。第一个片段可能只有 id 和 name后面的片段只带 arguments 的一小段。多个工具同时调用时index 用来区分不同工具。你如果只看最后一个 chunk永远拿不到完整参数。正确做法是维护一个字典以 index 为键把 id、name、arguments 逐片追加。4.2 缓存器代码把上一节的循环改成下面这样。注意arguments是字符串追加不是字典合并只有 stream 结束后才json.loads。import json tool_calls_buffer {} for chunk in stream: delta chunk.choices[0].delta if chunk.choices else None if delta is None: continue if delta.content: print(delta.content, end, flushTrue) if delta.tool_calls: for tc in delta.tool_calls: idx tc.index if idx not in tool_calls_buffer: tool_calls_buffer[idx] { id: , type: function, function: {name: , arguments: }, } buf tool_calls_buffer[idx] if tc.id: buf[id] tc.id if tc.function: if tc.function.name: buf[function][name] tc.function.name if tc.function.arguments: buf[function][arguments] tc.function.arguments # stream 结束统一解析 for idx, call in tool_calls_buffer.items(): fn_name call[function][name] raw_args call[function][arguments] or {} try: args json.loads(raw_args) except json.JSONDecodeError as exc: print(ftool_call[{idx}] 参数不完整或拼接错误{raw_args}) raise exc print(f\n工具[{idx}] {fn_name} 参数{args}) # 这里执行你的本地工具例如查询天气 API # 执行结果不要流式输出直接作为 roletool 消息回送模型这段代码的核心就是原文第10步说的先缓存stream 结束后再执行。不要在 chunk 循环里对 arguments 做 JSON 解析也不要在循环里调用工具。工具调用可能依赖完整参数提前执行只会拿到半截内容。4.3 工具执行结果不再流式直接送入模型工具执行完以后把结果作为一条roletool的消息追加到 messages 里再发一次请求。第二次请求可以不开启流式也可以开启但原文的建议是工具执行结果不再流式直接送入模型。这样模型能拿到完整结果继续生成最终回答。注意tool_call_id要对应上否则模型不知道哪条结果属于哪个调用。多个工具并行时每条结果都要带自己的 id。4.4 多个 tool_calls 的并发与依赖原文第4步提到一次返回多个 tool_calls 时可以并发执行但要注意依赖关系。流式缓存同样要处理多 index。比如 index 0 和 index 1 同时出现你不能只保留一个字典。并发执行时先检查工具之间是否有先后依赖没有依赖就并行有依赖就串行。缓存器本身不判断依赖它只负责把片段按 index 拼完整。执行顺序是 Agent 代码的事。5. 排障对照通道配置还是片段处理5.1 通道侧要查的三件事第一Key 是否从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 创建环境变量名和代码里读的是否一致。第二Base URL 是否写成https://taotoken.net/api有没有误加/v1或 UTM 参数。第三模型 ID 是否以模型广场当时列表为准有没有把不存在的 ID 写进请求。这三件事任一不对都可能返回 401、404 或模型不存在但它们不会表现为“content 正常、tool_calls 消失”。5.2 片段侧要查的三件事第一循环里有没有处理delta.tool_calls还是只判断了delta.content。第二arguments 是不是在 chunk 循环里被提前json.loads。第三多个 tool_calls 是否按 index 分别缓存还是用单个变量覆盖。你可以在缓存结束后打印tool_calls_buffer如果里面 arguments 是完整 JSON 字符串说明片段处理正确如果只有半截问题在拼接逻辑。5.3 用最小日志把两类问题分开加两行日志就能分开请求前打印base_url和model响应后打印finish_reason和tool_calls_buffer。如果base_url错请求根本到不了模型如果finish_reason是tool_calls但 buffer 为空说明你没读片段如果 buffer 有内容但 JSON 解析失败说明拼接逻辑有问题。这个顺序比盲改配置快得多。6. 验证与下一步本地跑通一次完整的流式工具调用6.1 本地验证清单先跑非流式请求确认 tools 定义能触发 tool_calls。再跑流式请求确认每个 chunk 的delta.tool_calls被打印。然后启用缓存器确认 stream 结束后 arguments 能被json.loads。最后执行一个安全的本地工具例如查天气或读本地文档把结果作为roletool回送确认模型能生成最终回答。全程不需要让 AI 直接连接生产库或执行系统命令。6.2 去控制台对一下这次调用跑通后回到 TaoToken 控制台看这次流式请求是否记上账、用的哪个模型、有没有异常报错。如果用量里能看到请求说明 Key 和 Base URL 都没问题剩下就是把缓存器并入你的 Agent 循环。原文第15步的评估流程也可以从这里开始为每个工具写 5 到 10 个典型场景记录该调没调、参数对不对。6.3 下一步入口想先用同一把 Key 快速验证模型 ID 和工具调用可以打开 模型对话。如果要长期跑 Agent 开发可以看 Coding Plan 是否够用Key 在 控制台 API Keys 创建Claude Code 环境变量对照见 接入文档。先把一次流式工具调用完整跑通再往上加 Skill、MCP 和多 Agent顺序不要反。
你在原文第10步把 Function Calling 和流式输出拼在一起日志里却只看到 delta.content 一段段往外吐tool_calls 像被谁吞了重启进程、换网络、甚至怀疑 TaoToken 通道不通。别急着改通道配置先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 核对 Key 和 Base URL再把 stream 里的 tool_call 片段按 index 缓存起来。TaoToken 只提供 Key 和统一 Base URL不替你的 Agent 缓存 tool_calls缓存和工具执行仍照原文写。很多开发者把片段处理问题误判成模型通道故障结果在接入层来回折腾真正该改的循环却一行没动。1. 先看现场流式输出里 tool_calls 为什么像“消失”了1.1 一个常见日志只有 content没有 tool_calls你发一个带 tools 定义的流式请求期望模型先返回一段文字然后吐出 tool_calls。实际日志里只有delta.content: 杭州 delta.content: 今天 delta.content: 多云 finish_reason: stop工具一个都没执行。这时人容易判断模型不调工具。但把同一个请求改成 streamFalsetool_calls 却完整出现。问题不在模型而在流式解析。流式下 tool_calls 不是一次性给一个完整 JSON而是拆成多个 delta分散在若干 chunk 里。你只打印 delta.content当然看不见。1.2 三种“看起来像通道不通”的片段现象第一种tool_calls 的 arguments 分片到达你每个 chunk 都 json.loads前几个 chunk 是{city:直接抛 JSONDecodeError进程挂掉。第二种多个 tool_calls 同时返回index 为 0 和 1你只取第一个第二个被覆盖。第三种stream 结束后才出现 finish_reasontool_calls但你的循环只处理 content结束后没有回头读缓存。这三类都跟 Base URL、Key 没有直接关系却最容易被当成通道故障。1.3 先分清“模型没调工具”和“片段没拼对”分辨方法很直接先用非流式请求跑同一组 messages 和 tools。如果非流式返回 tool_calls说明模型和工具定义都正常通道也通问题在流式片段处理。如果非流式也没有 tool_calls再去查工具 schema 的 description、required 字段或者模型是否支持 Function Calling。这个顺序能省掉大量无效重启。原文第4步说 description 直接影响调用准确率排障时也要把它算进去。2. 回到原文概念Function Calling、Tool Use、Skill、MCP 在流式里的分工2.1 Function Calling 是模型原生能力流式只是传输层原文第1步把 Function Calling 定义为模型原生能力不是框架给的。模型在 API 层识别工具定义决定是否调用。流式输出不改变这个能力只改变结果的到达方式。所以你不能把“流式里没看到完整 tool_calls”等同于“模型没有 Function Calling 能力”。更准确的说法是传输层把一次调用拆成了多个片段你的接收端没有组装。2.2 Tool Use 是上层循环缓存策略属于你的 Agent 代码Tool Use 是上层概念模型输出工具调用代码执行函数结果回送模型。在流式场景里这个循环多了一步——先把片段缓存成完整的 tool_call再执行。缓存逻辑不在模型里也不在统一通道里而在你的 Agent 循环里。原文第10步的策略很明确缓存 tool_call 片段stream 结束后再执行工具工具执行结果不再流式直接送入模型。这句要原样理解成代码结构而不是配置项。2.3 为什么 TaoToken 只负责 Key 通道TaoToken 在接入层提供的是 Key 和 Base URL让请求能走统一通道到达模型。它不会替你的 Agent 维护 tool_calls 缓冲也不会在 stream 中间帮你执行工具。把这点想清楚排障边界就清楚了401、404、模型 ID 不对去查通道配置arguments 拼接失败、工具没执行、结果没回送去查 Agent 循环。两边混在一起查只会越查越乱。3. 模型接入层去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 创建 KeyBase URL 填 https://taotoken.net/api3.1 创建 Key 和确认模型 ID打开 TaoToken 注册并进入控制台创建 API Key。Key 用占位符 YOUR_API_KEY 写进环境变量不要硬编码进仓库。模型 ID 不要凭记忆写以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 模型广场当时的列表为准。原文第3步说接入层要支持 chat、stream、embed 三种模式本文只跑通 stream tools先别把嵌入模型混进来。3.2 最小接入代码下面这段不是完整 Agent只负责把流式请求接到统一通道并把 tool_calls 片段打印出来。你可以先不执行工具只看缓存结果是否正确。import os from openai import OpenAI client OpenAI( api_keyos.environ.get(TAOTOKEN_API_KEY, YOUR_API_KEY), base_urlhttps://taotoken.net/api, ) tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气用户明确问天气时调用, parameters: { type: object, properties: { city: { type: string, description: 城市名例如杭州, } }, required: [city], }, }, } ] stream client.chat.completions.create( modelYOUR_MODEL_ID, # 以模型广场当时列表为准 messages[{role: user, content: 杭州今天天气怎么样}], toolstools, streamTrue, ) for chunk in stream: delta chunk.choices[0].delta if chunk.choices else None if delta is None: continue if delta.content: print(content:, delta.content) if delta.tool_calls: print(tool_calls delta:, delta.tool_calls)跑起来后如果能看到tool_calls delta说明请求已经到达模型并触发了工具调用意图。接下来要做的就是把片段拼起来。3.3 Base URL 不要加 /v1也不要带 UTM填进工具的 Base URL 是https://taotoken.net/api末尾不要加/v1。官网落地页https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content只用于注册、创建 Key、看模型广场和看用量不要把它填进base_url。把 UTM 参数带进接口地址会让请求路径变成错误路径表现为 404 或连接异常。排障时先看一眼配置文件里这一行能排除不少低级问题。4. 原文第10步的缓存实现按 index 归并 tool_call 片段4.1 chunk 里 tool_calls 长什么样流式返回的delta.tool_calls通常是一个列表每个元素带index、id、type、function.name、function.arguments。第一个片段可能只有 id 和 name后面的片段只带 arguments 的一小段。多个工具同时调用时index 用来区分不同工具。你如果只看最后一个 chunk永远拿不到完整参数。正确做法是维护一个字典以 index 为键把 id、name、arguments 逐片追加。4.2 缓存器代码把上一节的循环改成下面这样。注意arguments是字符串追加不是字典合并只有 stream 结束后才json.loads。import json tool_calls_buffer {} for chunk in stream: delta chunk.choices[0].delta if chunk.choices else None if delta is None: continue if delta.content: print(delta.content, end, flushTrue) if delta.tool_calls: for tc in delta.tool_calls: idx tc.index if idx not in tool_calls_buffer: tool_calls_buffer[idx] { id: , type: function, function: {name: , arguments: }, } buf tool_calls_buffer[idx] if tc.id: buf[id] tc.id if tc.function: if tc.function.name: buf[function][name] tc.function.name if tc.function.arguments: buf[function][arguments] tc.function.arguments # stream 结束统一解析 for idx, call in tool_calls_buffer.items(): fn_name call[function][name] raw_args call[function][arguments] or {} try: args json.loads(raw_args) except json.JSONDecodeError as exc: print(ftool_call[{idx}] 参数不完整或拼接错误{raw_args}) raise exc print(f\n工具[{idx}] {fn_name} 参数{args}) # 这里执行你的本地工具例如查询天气 API # 执行结果不要流式输出直接作为 roletool 消息回送模型这段代码的核心就是原文第10步说的先缓存stream 结束后再执行。不要在 chunk 循环里对 arguments 做 JSON 解析也不要在循环里调用工具。工具调用可能依赖完整参数提前执行只会拿到半截内容。4.3 工具执行结果不再流式直接送入模型工具执行完以后把结果作为一条roletool的消息追加到 messages 里再发一次请求。第二次请求可以不开启流式也可以开启但原文的建议是工具执行结果不再流式直接送入模型。这样模型能拿到完整结果继续生成最终回答。注意tool_call_id要对应上否则模型不知道哪条结果属于哪个调用。多个工具并行时每条结果都要带自己的 id。4.4 多个 tool_calls 的并发与依赖原文第4步提到一次返回多个 tool_calls 时可以并发执行但要注意依赖关系。流式缓存同样要处理多 index。比如 index 0 和 index 1 同时出现你不能只保留一个字典。并发执行时先检查工具之间是否有先后依赖没有依赖就并行有依赖就串行。缓存器本身不判断依赖它只负责把片段按 index 拼完整。执行顺序是 Agent 代码的事。5. 排障对照通道配置还是片段处理5.1 通道侧要查的三件事第一Key 是否从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 创建环境变量名和代码里读的是否一致。第二Base URL 是否写成https://taotoken.net/api有没有误加/v1或 UTM 参数。第三模型 ID 是否以模型广场当时列表为准有没有把不存在的 ID 写进请求。这三件事任一不对都可能返回 401、404 或模型不存在但它们不会表现为“content 正常、tool_calls 消失”。5.2 片段侧要查的三件事第一循环里有没有处理delta.tool_calls还是只判断了delta.content。第二arguments 是不是在 chunk 循环里被提前json.loads。第三多个 tool_calls 是否按 index 分别缓存还是用单个变量覆盖。你可以在缓存结束后打印tool_calls_buffer如果里面 arguments 是完整 JSON 字符串说明片段处理正确如果只有半截问题在拼接逻辑。5.3 用最小日志把两类问题分开加两行日志就能分开请求前打印base_url和model响应后打印finish_reason和tool_calls_buffer。如果base_url错请求根本到不了模型如果finish_reason是tool_calls但 buffer 为空说明你没读片段如果 buffer 有内容但 JSON 解析失败说明拼接逻辑有问题。这个顺序比盲改配置快得多。6. 验证与下一步本地跑通一次完整的流式工具调用6.1 本地验证清单先跑非流式请求确认 tools 定义能触发 tool_calls。再跑流式请求确认每个 chunk 的delta.tool_calls被打印。然后启用缓存器确认 stream 结束后 arguments 能被json.loads。最后执行一个安全的本地工具例如查天气或读本地文档把结果作为roletool回送确认模型能生成最终回答。全程不需要让 AI 直接连接生产库或执行系统命令。6.2 去控制台对一下这次调用跑通后回到 TaoToken 控制台看这次流式请求是否记上账、用的哪个模型、有没有异常报错。如果用量里能看到请求说明 Key 和 Base URL 都没问题剩下就是把缓存器并入你的 Agent 循环。原文第15步的评估流程也可以从这里开始为每个工具写 5 到 10 个典型场景记录该调没调、参数对不对。6.3 下一步入口想先用同一把 Key 快速验证模型 ID 和工具调用可以打开 模型对话。如果要长期跑 Agent 开发可以看 Coding Plan 是否够用Key 在 控制台 API Keys 创建Claude Code 环境变量对照见 接入文档。先把一次流式工具调用完整跑通再往上加 Skill、MCP 和多 Agent顺序不要反。
