1. 从一次“模型说会调工具结果啥也没干”说起你大概率遇到过这种场面模型在对话里信誓旦旦地说“我帮你查一下天气”然后……就没有然后了。它只是把“我要调用工具”这句话用自然语言说出来了并没有真的触发任何函数。这不是模型在骗你而是你还没把 Function Call、Agent 调度、MCP 协议这三层拼起来。先把三个词用一句话说清楚。LLM Function Call 是模型输出一段结构化的“调用意图”告诉外部“我想调哪个函数、参数是什么”Agent 调度是真正接住这段意图、校验参数、执行函数、把结果塞回上下文的那个“执行层”MCP 协议则是把工具定义、上下文、调用记录用统一格式组织起来让模型和 Agent 之间不用每次手拼 prompt。适合谁看适合已经能跑通单轮对话、想从零搭一条“模型发起调用 → Agent 路由 → 工具执行 → 结果回传”完整链路的开发者。这篇不空谈概念。我会用 TaoToken 的统一 Key 把模型侧配好然后给你一段可复制的配置、一次端到端的验证请求最后把 401、local proxy failed、reading choices 这些真实报错逐个拆开。你跟着做能亲眼看到模型吐出一个tool_calls结构Agent 解析它、执行它、再把结果喂回去。三层职责边界先记住一句话LLM 只负责“决定调什么”Agent 负责“真的去调”MCP 负责“把调用的上下文标准化”。搞混这三者就会出现“模型说了但没做”或者“Agent 自己瞎调”的问题。下面逐层拆。2. TaoToken 统一 Key 前置配置与 Function Call 工具定义在动手写 Agent 之前得先有一个稳定的模型入口。Function Call 对模型的指令遵循能力有要求不是所有模型都能稳定输出结构化的tool_calls。我用 TaoToken 的统一 Key 来跑这条链路原因是它一个 Key 就能切换不同模型方便你对比哪个模型在工具调用上更靠谱不用为每个模型单独申请和配置。先拿 Key。打开 https://taotoken.net/api-keys 登录后创建一个 API Key复制出来形如sk-...的字符串。这个 Key 就是你后面所有请求的凭证。注意别把它硬编码进要提交到 Git 的文件里用环境变量或者本地.env。Base URL 用https://taotoken.net/api这是 OpenAI 兼容协议的入口。也就是说你原来用 OpenAI SDK 写的代码只需要改base_url和api_key两个地方其余调用方式不变。这一点对 Function Call 特别重要因为工具调用的请求体格式是跟着 OpenAI 的tools字段走的。模型侧我建议先用一个指令遵循较强的模型做验证。你可以在 https://taotoken.net/models 看到可用模型列表选一个支持 function calling 的。Model ID 要写全比如gpt-4o这类别只写个模糊的名字否则请求会报模型不存在。现在定义工具。Function Call 的核心是toolsschema用 JSON Schema 描述函数名、用途、参数类型。下面这个get_weather例子你可以直接抄{ type: function, function: { name: get_weather, description: 获取指定城市在指定日期的天气情况, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如长沙 }, date: { type: string, description: 查询日期例如2025-06-01 或 明天 } }, required: [city, date] } } }这里有个容易踩的坑description不是写给人看的注释它是模型判断“该不该调这个函数”的主要依据。描述写得含糊模型就可能该调不调或者调错函数。参数里的description同理模型靠它决定怎么填参数。所以别偷懒把每个字段的语义写清楚。把 Key、Base URL、Model ID、tools schema 这四样凑齐前置就完成了。接下来写 Agent 调度逻辑。Agent 的职责不是自己判断要不要调函数而是监听模型的输出如果响应里带tool_calls就解析出来执行如果没有就直接把自然语言回复返回给用户。这个判断逻辑是整个链路的分水岭写错了就会出现“模型说了没做”。3. 可复制的 Agent 调度配置与 MCP 上下文组织这一节给你能直接跑的配置。我用 Python 的 OpenAI SDK 演示因为它的tools参数和tool_calls解析是标准化的换成其他语言逻辑一样。先装依赖并设置环境变量pip install openai export TAOTOKEN_API_KEYsk-你的Key然后是 Agent 的核心调度代码。注意看它怎么处理tool_callsimport os import json from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api, api_keyos.environ[TAOTOKEN_API_KEY], ) TOOLS [ { type: function, function: { name: get_weather, description: 获取指定城市在指定日期的天气情况, parameters: { type: object, properties: { city: {type: string, description: 城市名称}, date: {type: string, description: 查询日期}, }, required: [city, date], }, }, } ] def execute_tool(name, args): if name get_weather: return json.dumps({ city: args[city], date: args[date], weather: 多云, temp_high: 30, temp_low: 22, }, ensure_asciiFalse) raise ValueError(f未知工具: {name}) def run_agent(user_input): messages [{role: user, content: user_input}] resp client.chat.completions.create( modelgpt-4o, messagesmessages, toolsTOOLS, tool_choiceauto, ) msg resp.choices[0].message if not msg.tool_calls: return msg.content messages.append(msg) for call in msg.tool_calls: args json.loads(call.function.arguments) result execute_tool(call.function.name, args) messages.append({ role: tool, tool_call_id: call.id, content: result, }) final client.chat.completions.create( modelgpt-4o, messagesmessages, toolsTOOLS, ) return final.choices[0].message.content print(run_agent(帮我查一下明天长沙的天气))这段代码里tool_choiceauto让模型自己决定调不调工具。第一次请求如果模型决定调用msg.tool_calls就有值Agent 把模型这条消息原样 append 回messages再逐条执行工具用role: tool和tool_call_id把结果挂回去。第二次请求模型拿到工具结果生成最终自然语言回答。这就是完整的“发起 → 路由 → 执行 → 回传”闭环。现在说 MCP 的位置。上面这段代码里messages数组其实就是最朴素的上下文组织。当工具变多、多轮任务变复杂手拼messages会越来越乱。MCP 协议做的事是把工具定义、上下文历史、调用记录用统一结构管理起来。你可以把它理解成给 Agent 加了一个“上下文管理层”。一个简化的 MCP 风格配置片段长这样用 TOML 描述工具服务器[mcp_servers.weather] command python args [weather_server.py] transport stdio [mcp_servers.weather.env] API_BASE https://taotoken.net/api如果你用的是 Cline 或 Claude Code 这类支持 MCP 的客户端配置里必须同时写全三件套Base URL、API Key、Model ID。缺一个都会连不上。比如在 Cline 的 MCP 设置里Base URL 填https://taotoken.net/apiKey 填你的sk-...Model ID 填gpt-4o。这三样对齐了Agent 才能通过 MCP 把工具暴露给模型。职责边界再强调一次MCP 不执行工具它只负责“描述和传递”。真正执行get_weather的还是 Agent 里的execute_tool。很多人以为配了 MCP 就自动能调工具结果发现模型还是只说不做就是因为 Agent 调度层没写。4. 端到端验证从 tool_calls 到结果回传的完整请求配置写完得验证它真的跑通了。别只看代码没报错就以为成了要看到模型吐出结构化的tool_calls再看到工具结果回传后模型生成最终回答。最直接的验证方式是用 curl 发一次原始请求看响应体里有没有tool_calls字段。这样能排除 SDK 封装带来的干扰curl 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: 帮我查一下明天长沙的天气}], tools: [{ type: function, function: { name: get_weather, description: 获取指定城市在指定日期的天气情况, parameters: { type: object, properties: { city: {type: string}, date: {type: string} }, required: [city, date] } } }], tool_choice: auto }如果链路正常你会看到响应里finish_reason是tool_callsmessage.tool_calls数组里有一个对象function.name是get_weatherfunction.arguments是类似{city:长沙,date:明天}的字符串。看到这个说明模型侧和工具定义都对了。接着跑第 3 节那段 Python 代码完整走一遍。预期输出是“明天长沙多云最高气温30°C最低气温22°C”这类自然语言。如果输出的是“好的我帮你查”这种空话说明 Agent 没接住tool_calls回去检查if not msg.tool_calls那段逻辑。验证时有个细节arguments是字符串不是对象必须json.loads一次才能取参数。我见过有人直接args[city]结果报TypeError: string indices must be integers就是漏了这步解析。再验证多轮。把第一次的messages保留追加一条新的用户消息再跑一次。观察 Agent 是否能把历史工具调用记录一起带上。这一步能验证你的上下文管理是否稳定也是 MCP 想解决的核心问题。如果多轮之后模型开始“忘记”之前调过什么说明上下文没正确累积。成功结果长这样模型先输出tool_callsAgent 执行后返回role: tool的结果模型再基于结果生成最终回答。整条链路里模型始终只输出“意图”Agent 始终只做“执行”MCP 负责“组织”。三者各司其职链路才稳。5. 本篇常见报错排查401、local proxy failed、reading choices链路跑不通时报错信息往往指向不同层。下面这几个是我实际遇到过的逐个拆。401 Unauthorized。这个最直接Key 不对或没带上。检查三件事Authorization头是不是Bearer sk-...格式中间有空格Key 有没有复制全前后有没有多余换行环境变量有没有真的导出成功用echo $TAOTOKEN_API_KEY确认。如果 Key 是对的还报 401检查是不是把 Base URL 写成了带路径的地址正确写法就是https://taotoken.net/api不要自己加/v1。local proxy failed。这个报错通常出现在你本地配了某些网络层请求根本没发出去。先确认你的请求能直连到https://taotoken.net/api用curl -v看连接建立在哪一步断的。如果是 SDK 报的检查base_url有没有被环境变量覆盖成别的地址。这个错和模型、工具定义都无关纯粹是请求没到达服务端。reading choices 相关报错比如KeyError: choices或NoneType has no attribute choices。这说明响应体里没有choices字段通常是请求本身失败了返回的是错误结构。打印完整resp看error字段。常见原因是 Model ID 写错或者tools格式不合法导致服务端拒绝。还有一种情况是流式请求没处理完就取choices非流式调用不会有这问题。OAuth 相关报错。如果你用的是 Claude Code 或 Codex 这类客户端报 OAuth 失败多半是认证方式选错了。这些客户端有的默认走 OAuth 登录你要在配置里改成 API Key 模式把 Base URL 填https://taotoken.net/apiKey 填sk-...Model ID 填全。三件套缺一个都会卡在认证。模型不调工具只回自然语言。这不是报错但最让人抓狂。排查顺序tool_choice是不是auto或指定了函数tools的description是不是太模糊模型本身是否支持 function calling。换个指令遵循强的模型再试往往就好了。arguments 解析失败。json.loads报错说明模型输出的参数字符串不合法。这在小模型上常见。解决办法是在 Agent 里加一层容错解析失败就把错误信息作为tool结果回传让模型重新生成。别直接抛异常中断链路。排查的核心思路是分层定位401 和 local proxy failed 在“请求到达”层reading choices 在“响应解析”层OAuth 在“客户端认证”层不调工具在“模型决策”层。哪层报错修哪层别混着改。6. 把三层链路固化成你自己的工具调用模板跑通一次不算完把配置固化成模板才能复用。我的做法是建一个agent_config目录里面放三样东西tools.json存所有工具 schemamcp_servers.toml存 MCP 服务器配置agent.py存调度逻辑。换项目时只改tools.json调度代码不动。工具 schema 建议按领域分组别把所有函数塞一个数组。模型面对几十个工具时选择准确率会下降。按“天气类”“数据库类”“文件类”拆开每次只挂当前任务相关的工具tool_choice也可以从auto改成指定函数来强制路由。MCP 配置里把 Base URL、Key、Model ID 抽成环境变量引用别写死。这样本地和线上用同一份配置只换环境变量。如果你用 Cline 或 Claude Code把 MCP 服务器配好后工具会自动暴露给模型你只需要在 Agent 侧写好执行逻辑。长期跑编码或 Agent 任务的话可以考虑用 Coding Plan 这类按量方案避免频繁换 Key。入口在 https://taotoken.net/coding-plan 配置方式和上面一致Base URL 和 Model ID 不变只换 Key 来源。最后留一个实用技巧在 Agent 里加日志把每次的tool_calls和工具返回结果都打出来。链路出问题时看日志比看报错快得多。模型决定调什么、Agent 执行了什么、结果是什么三行日志一目了然。这套模板跑顺之后你再加新工具就是往tools.json里加一段 schema、往execute_tool里加一个分支的事链路本身不用动。
1. 从一次“模型说会调工具结果啥也没干”说起你大概率遇到过这种场面模型在对话里信誓旦旦地说“我帮你查一下天气”然后……就没有然后了。它只是把“我要调用工具”这句话用自然语言说出来了并没有真的触发任何函数。这不是模型在骗你而是你还没把 Function Call、Agent 调度、MCP 协议这三层拼起来。先把三个词用一句话说清楚。LLM Function Call 是模型输出一段结构化的“调用意图”告诉外部“我想调哪个函数、参数是什么”Agent 调度是真正接住这段意图、校验参数、执行函数、把结果塞回上下文的那个“执行层”MCP 协议则是把工具定义、上下文、调用记录用统一格式组织起来让模型和 Agent 之间不用每次手拼 prompt。适合谁看适合已经能跑通单轮对话、想从零搭一条“模型发起调用 → Agent 路由 → 工具执行 → 结果回传”完整链路的开发者。这篇不空谈概念。我会用 TaoToken 的统一 Key 把模型侧配好然后给你一段可复制的配置、一次端到端的验证请求最后把 401、local proxy failed、reading choices 这些真实报错逐个拆开。你跟着做能亲眼看到模型吐出一个tool_calls结构Agent 解析它、执行它、再把结果喂回去。三层职责边界先记住一句话LLM 只负责“决定调什么”Agent 负责“真的去调”MCP 负责“把调用的上下文标准化”。搞混这三者就会出现“模型说了但没做”或者“Agent 自己瞎调”的问题。下面逐层拆。2. TaoToken 统一 Key 前置配置与 Function Call 工具定义在动手写 Agent 之前得先有一个稳定的模型入口。Function Call 对模型的指令遵循能力有要求不是所有模型都能稳定输出结构化的tool_calls。我用 TaoToken 的统一 Key 来跑这条链路原因是它一个 Key 就能切换不同模型方便你对比哪个模型在工具调用上更靠谱不用为每个模型单独申请和配置。先拿 Key。打开 https://taotoken.net/api-keys 登录后创建一个 API Key复制出来形如sk-...的字符串。这个 Key 就是你后面所有请求的凭证。注意别把它硬编码进要提交到 Git 的文件里用环境变量或者本地.env。Base URL 用https://taotoken.net/api这是 OpenAI 兼容协议的入口。也就是说你原来用 OpenAI SDK 写的代码只需要改base_url和api_key两个地方其余调用方式不变。这一点对 Function Call 特别重要因为工具调用的请求体格式是跟着 OpenAI 的tools字段走的。模型侧我建议先用一个指令遵循较强的模型做验证。你可以在 https://taotoken.net/models 看到可用模型列表选一个支持 function calling 的。Model ID 要写全比如gpt-4o这类别只写个模糊的名字否则请求会报模型不存在。现在定义工具。Function Call 的核心是toolsschema用 JSON Schema 描述函数名、用途、参数类型。下面这个get_weather例子你可以直接抄{ type: function, function: { name: get_weather, description: 获取指定城市在指定日期的天气情况, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如长沙 }, date: { type: string, description: 查询日期例如2025-06-01 或 明天 } }, required: [city, date] } } }这里有个容易踩的坑description不是写给人看的注释它是模型判断“该不该调这个函数”的主要依据。描述写得含糊模型就可能该调不调或者调错函数。参数里的description同理模型靠它决定怎么填参数。所以别偷懒把每个字段的语义写清楚。把 Key、Base URL、Model ID、tools schema 这四样凑齐前置就完成了。接下来写 Agent 调度逻辑。Agent 的职责不是自己判断要不要调函数而是监听模型的输出如果响应里带tool_calls就解析出来执行如果没有就直接把自然语言回复返回给用户。这个判断逻辑是整个链路的分水岭写错了就会出现“模型说了没做”。3. 可复制的 Agent 调度配置与 MCP 上下文组织这一节给你能直接跑的配置。我用 Python 的 OpenAI SDK 演示因为它的tools参数和tool_calls解析是标准化的换成其他语言逻辑一样。先装依赖并设置环境变量pip install openai export TAOTOKEN_API_KEYsk-你的Key然后是 Agent 的核心调度代码。注意看它怎么处理tool_callsimport os import json from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api, api_keyos.environ[TAOTOKEN_API_KEY], ) TOOLS [ { type: function, function: { name: get_weather, description: 获取指定城市在指定日期的天气情况, parameters: { type: object, properties: { city: {type: string, description: 城市名称}, date: {type: string, description: 查询日期}, }, required: [city, date], }, }, } ] def execute_tool(name, args): if name get_weather: return json.dumps({ city: args[city], date: args[date], weather: 多云, temp_high: 30, temp_low: 22, }, ensure_asciiFalse) raise ValueError(f未知工具: {name}) def run_agent(user_input): messages [{role: user, content: user_input}] resp client.chat.completions.create( modelgpt-4o, messagesmessages, toolsTOOLS, tool_choiceauto, ) msg resp.choices[0].message if not msg.tool_calls: return msg.content messages.append(msg) for call in msg.tool_calls: args json.loads(call.function.arguments) result execute_tool(call.function.name, args) messages.append({ role: tool, tool_call_id: call.id, content: result, }) final client.chat.completions.create( modelgpt-4o, messagesmessages, toolsTOOLS, ) return final.choices[0].message.content print(run_agent(帮我查一下明天长沙的天气))这段代码里tool_choiceauto让模型自己决定调不调工具。第一次请求如果模型决定调用msg.tool_calls就有值Agent 把模型这条消息原样 append 回messages再逐条执行工具用role: tool和tool_call_id把结果挂回去。第二次请求模型拿到工具结果生成最终自然语言回答。这就是完整的“发起 → 路由 → 执行 → 回传”闭环。现在说 MCP 的位置。上面这段代码里messages数组其实就是最朴素的上下文组织。当工具变多、多轮任务变复杂手拼messages会越来越乱。MCP 协议做的事是把工具定义、上下文历史、调用记录用统一结构管理起来。你可以把它理解成给 Agent 加了一个“上下文管理层”。一个简化的 MCP 风格配置片段长这样用 TOML 描述工具服务器[mcp_servers.weather] command python args [weather_server.py] transport stdio [mcp_servers.weather.env] API_BASE https://taotoken.net/api如果你用的是 Cline 或 Claude Code 这类支持 MCP 的客户端配置里必须同时写全三件套Base URL、API Key、Model ID。缺一个都会连不上。比如在 Cline 的 MCP 设置里Base URL 填https://taotoken.net/apiKey 填你的sk-...Model ID 填gpt-4o。这三样对齐了Agent 才能通过 MCP 把工具暴露给模型。职责边界再强调一次MCP 不执行工具它只负责“描述和传递”。真正执行get_weather的还是 Agent 里的execute_tool。很多人以为配了 MCP 就自动能调工具结果发现模型还是只说不做就是因为 Agent 调度层没写。4. 端到端验证从 tool_calls 到结果回传的完整请求配置写完得验证它真的跑通了。别只看代码没报错就以为成了要看到模型吐出结构化的tool_calls再看到工具结果回传后模型生成最终回答。最直接的验证方式是用 curl 发一次原始请求看响应体里有没有tool_calls字段。这样能排除 SDK 封装带来的干扰curl 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: 帮我查一下明天长沙的天气}], tools: [{ type: function, function: { name: get_weather, description: 获取指定城市在指定日期的天气情况, parameters: { type: object, properties: { city: {type: string}, date: {type: string} }, required: [city, date] } } }], tool_choice: auto }如果链路正常你会看到响应里finish_reason是tool_callsmessage.tool_calls数组里有一个对象function.name是get_weatherfunction.arguments是类似{city:长沙,date:明天}的字符串。看到这个说明模型侧和工具定义都对了。接着跑第 3 节那段 Python 代码完整走一遍。预期输出是“明天长沙多云最高气温30°C最低气温22°C”这类自然语言。如果输出的是“好的我帮你查”这种空话说明 Agent 没接住tool_calls回去检查if not msg.tool_calls那段逻辑。验证时有个细节arguments是字符串不是对象必须json.loads一次才能取参数。我见过有人直接args[city]结果报TypeError: string indices must be integers就是漏了这步解析。再验证多轮。把第一次的messages保留追加一条新的用户消息再跑一次。观察 Agent 是否能把历史工具调用记录一起带上。这一步能验证你的上下文管理是否稳定也是 MCP 想解决的核心问题。如果多轮之后模型开始“忘记”之前调过什么说明上下文没正确累积。成功结果长这样模型先输出tool_callsAgent 执行后返回role: tool的结果模型再基于结果生成最终回答。整条链路里模型始终只输出“意图”Agent 始终只做“执行”MCP 负责“组织”。三者各司其职链路才稳。5. 本篇常见报错排查401、local proxy failed、reading choices链路跑不通时报错信息往往指向不同层。下面这几个是我实际遇到过的逐个拆。401 Unauthorized。这个最直接Key 不对或没带上。检查三件事Authorization头是不是Bearer sk-...格式中间有空格Key 有没有复制全前后有没有多余换行环境变量有没有真的导出成功用echo $TAOTOKEN_API_KEY确认。如果 Key 是对的还报 401检查是不是把 Base URL 写成了带路径的地址正确写法就是https://taotoken.net/api不要自己加/v1。local proxy failed。这个报错通常出现在你本地配了某些网络层请求根本没发出去。先确认你的请求能直连到https://taotoken.net/api用curl -v看连接建立在哪一步断的。如果是 SDK 报的检查base_url有没有被环境变量覆盖成别的地址。这个错和模型、工具定义都无关纯粹是请求没到达服务端。reading choices 相关报错比如KeyError: choices或NoneType has no attribute choices。这说明响应体里没有choices字段通常是请求本身失败了返回的是错误结构。打印完整resp看error字段。常见原因是 Model ID 写错或者tools格式不合法导致服务端拒绝。还有一种情况是流式请求没处理完就取choices非流式调用不会有这问题。OAuth 相关报错。如果你用的是 Claude Code 或 Codex 这类客户端报 OAuth 失败多半是认证方式选错了。这些客户端有的默认走 OAuth 登录你要在配置里改成 API Key 模式把 Base URL 填https://taotoken.net/apiKey 填sk-...Model ID 填全。三件套缺一个都会卡在认证。模型不调工具只回自然语言。这不是报错但最让人抓狂。排查顺序tool_choice是不是auto或指定了函数tools的description是不是太模糊模型本身是否支持 function calling。换个指令遵循强的模型再试往往就好了。arguments 解析失败。json.loads报错说明模型输出的参数字符串不合法。这在小模型上常见。解决办法是在 Agent 里加一层容错解析失败就把错误信息作为tool结果回传让模型重新生成。别直接抛异常中断链路。排查的核心思路是分层定位401 和 local proxy failed 在“请求到达”层reading choices 在“响应解析”层OAuth 在“客户端认证”层不调工具在“模型决策”层。哪层报错修哪层别混着改。6. 把三层链路固化成你自己的工具调用模板跑通一次不算完把配置固化成模板才能复用。我的做法是建一个agent_config目录里面放三样东西tools.json存所有工具 schemamcp_servers.toml存 MCP 服务器配置agent.py存调度逻辑。换项目时只改tools.json调度代码不动。工具 schema 建议按领域分组别把所有函数塞一个数组。模型面对几十个工具时选择准确率会下降。按“天气类”“数据库类”“文件类”拆开每次只挂当前任务相关的工具tool_choice也可以从auto改成指定函数来强制路由。MCP 配置里把 Base URL、Key、Model ID 抽成环境变量引用别写死。这样本地和线上用同一份配置只换环境变量。如果你用 Cline 或 Claude Code把 MCP 服务器配好后工具会自动暴露给模型你只需要在 Agent 侧写好执行逻辑。长期跑编码或 Agent 任务的话可以考虑用 Coding Plan 这类按量方案避免频繁换 Key。入口在 https://taotoken.net/coding-plan 配置方式和上面一致Base URL 和 Model ID 不变只换 Key 来源。最后留一个实用技巧在 Agent 里加日志把每次的tool_calls和工具返回结果都打出来。链路出问题时看日志比看报错快得多。模型决定调什么、Agent 执行了什么、结果是什么三行日志一目了然。这套模板跑顺之后你再加新工具就是往tools.json里加一段 schema、往execute_tool里加一个分支的事链路本身不用动。
