从原理到实践：Agent工具调用实现与排错全解析-北京尧图网络

最早做Agent的时候一直觉得模型像个嘴强王者你说什么它都接得上逻辑也清楚但真要它干点实事——查个天气、翻一下数据库、调个外部API——它就只会给你出主意然后让你自己去操作。后来我把工具调用接上之后整个Agent才算是真正长了手脚。这一篇我就把这块内容完整展开从原理到一次完整实现再到我实际踩过的坑都给捋一遍。这篇适合两类人一类是刚接触Agent开发想把只会聊天的Demo变成能办实事的助手的人另一类是已经接上了工具调用但发现模型老是不按预期选工具、经常报错、不知道从哪里排查的人。全文不涉及某个特定平台代码风格以目前主流大模型都支持的 Function Calling工具调用)协议为准你换成自己用的平台SDK基本能直接平移。1. 为什么Agent必须长出手脚1.1 聊天机器人与Agent的分界线其实就是工具调用很多人对Agent有一个误解觉得它能自己思考所以它就是Agent。但实际上大模型本身做的事情非常单一——根据输入文本预测下一个Token输出一段文字。它没有真正执行任何外部动作不会真的发起网络请求不会真的去查数据库更不会帮你订票或者删文件。你问它北京今天冷不冷它可以告诉你建议穿羽绒服但它没法替你确认现在到底几度。那什么才是能干活儿的Agent我的理解是它能对外部世界产生真实影响。它读取了一个文件、写入了一条记录、调用了一个搜索接口、操作了一次表格……这些动作全部需要通过工具调用这个口子去完成。所以我说它是聊天机器人和Agent之间的分界线没有工具的模型只能提供建议有工具的Agent才能提供结果。一个很直观的对比。纯聊天场景下用户问我们部门的项目周报该写了模型能输出一篇周报模板但如果这个Agent接上了一个读取本月项目进度的工具它就能先把真实进度拉出来再基于真实数据生成周报草稿。后者才是做事的形态。判断一个Agent雏形成不成熟先别问它聊得好不好先问它能不能自己把一件事做完——这个能力基本取决于工具调用设计得怎么样。1.2 工具调用的本质模型负责点菜应用负责做菜这里有一个必须理清的概念工具调用并不是模型自己去执行工具而是模型按照一种约定好的格式输出我要调用哪个工具、传什么参数的结构化决定。真正去执行函数的是模型之外的代码。打个比方。你去一家餐厅你不认识后厨的人也不需要亲自生火做饭。你只需要看清楚菜单告诉服务员我要一道鱼香肉丝少辣剩下的事情由后厨完成最后菜端上来。在工具调用的架构里模型就是那个点菜的顾客它读到用户的请求后对照工具清单菜单输出一个我想点这个的结构化指令应用层的代码就是后厨它解析这个指令真正运行对应的函数最后把函数的执行结果做好的菜再传回给模型模型基于结果组织语言回复用户。这个设计巧妙的地方在于模型的强项是理解语义、拆解意图而不是稳定执行一段精确的程序。如果让模型直接输出一大段代码去运行出错的概率太高但如果让模型只是从有限工具集合里挑一个并传几个键值对参数可靠性和安全性就可控多了。所以工具调用的本质是把决策和执行彻底分离。模型负责判别需要什么信息、选哪个工具、参数填什么代码负责真正执行、获取真实数据、返回结果。这两者通过一套标准化的消息结构完成衔接。理解这一点之后你再看后面所有的代码和报错都会清晰很多。各种诡异问题的根源大多是模型以为点了一个菜后厨却找不到这道菜或者后厨做出来的东西没有按规范端回给服务员。2. 核心机制拆解一次工具调用如何完成2.1 完整生命周期从提问到答案的6个环节一次标准的工具调用完整链路如下应用把用户消息、工具定义清单一起发送给模型模型阅读消息判断是否需要用工具。如果不需要直接正常回答如果需要返回一个名为tool_calls的字段里面包含工具名和 JSON 格式的参数应用收到tool_calls后解析出函数名和参数并在自己的代码里执行对应的函数应用把函数执行结果以tool角色的消息回传给模型模型结合最初的问题和工具返回的真实结果生成面向用户的最终回答应用把最终回答展示给用户。这个流程里最容易被忽略的是第 5 步。你绝对不能在第 4 步往消息列表里塞一条tool内容就算完事——你需要再发起一次模型请求让模型看着工具结果说话。换句话说工具调用实际上是一个多次请求-响应的循环而不是一次搞定。为什么非要再问一次模型因为函数返回的是结构化数据比如天气接口返回的是 JSON 里的一堆温度、湿度、风力字段。这些字段直接抛给用户会非常难懂必须由模型整理成自然的回答北京当前气温 5 度湿度 40%西北风 3 级体感偏冷建议穿羽绒服。这个整理过程只能交给模型完成。我见过新手最容易犯的错就是把工具返回结果print出来就不管了用户看到一堆 JSON体验瞬间崩掉。2.2 工具定义的JSON Schema先写好菜单模型是怎么知道有哪些工具可以选的答案是我们给它一份菜单——通常在 API 请求里通过tools参数传递一组 JSON Schema 结构。每个工具的基本结构如下{ type: function, function: { name: get_weather, description: 查询指定城市当前天气情况适合用户询问气温、降雨、风力时使用, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如北京、上海、广州 } }, required: [city] } } }别小看这几行 JSON其中每个字段都有讲究。name是函数名模型会拿它跟用户的需求做语义匹配。起名尽量语义化get_weather就比fn01好一万倍。description是给模型看的说明书写清什么时候该用这个工具这句话直接影响触发率。比如上面例子里的适合用户询问气温、降雨、风力时使用模型看到下雨吗这类问题就会大概率联想到这个工具。如果你只写查询天气触发率会差很多。parameters里的properties定义了参数格式。参数名要语义清晰类型和描述要准确。模型不理解业务逻辑它唯一的依据就是参数名和说明文字。你在里面写一个字段叫city描述城市名称它就会老老实实把城市名填进去如果你写的是c或者p1模型生成的参数就很容易是垃圾值。有一类非常实用的写法是补充enum枚举来约束参数取值比如温度单位限定为celsius或fahrenheit。枚举能明显降低模型自由发挥的空间。但注意枚举不能写得过于死板如果用户问的是北京今天好穿什么模型还是得根据城市判断温度它需要的是一个城市参数而不是一个固定选项。工具参数能设计得宽松就宽松宁可少一点限制让函数内部做校验也不要让 Schema 把模型的路堵死——这个话题后面单独展开。3. 从零到一实现一个会调用工具的最小Agent3.1 环境准备与基础调用骨架在动笔之前先说清楚代码的假想环境。现在各家大模型平台的 SDK 虽然品牌名不同但接口风格基本都统一到了 Function Calling 这套协议创建客户端、发 messages、带 tools、收 tool_calls。下面的示例里我用client.chat.completions.create(...)这套调用方式演示你换成自己平台对应的 SDK 写法就行。第一步先包装一个最基础的对话函数它负责接收消息和工具列表返回模型响应。这是后面所有例子的地基import json MODEL_NAME your-model-name def call_model(client, messages, toolsNone): kwargs { model: MODEL_NAME, messages: messages, } if tools: kwargs[tools] tools resp client.chat.completions.create(**kwargs) return resp.choices[0].message然后我定义一套工具分发的入口函数。所有工具函数统一收一个**kwargs字典这样模型返回的参数字典可以直接传进去def dispatch_tool(function_name, arguments): 根据模型选择的工具名调用本地的实际函数 if function_name get_weather: return get_weather(**arguments) if function_name get_onboard_date: return get_onboard_date(**arguments) # 还有其他工具就继续加分支 raise ValueError(f未知工具: {function_name})实际的工具函数写在下面。这种统一入口的做法好处是主流程代码不用改每加一个新工具只需要在dispatch_tool里多一行分支。工具多了以后可以考虑用注册表模式但最早期没必要上框架多几个if完全够用且好排查。3.2 第一个工具查询天气这是最经典的示例覆盖了工具调用的所有核心环节。先写工具函数本身def get_weather(city: str): 模拟查询天气真实场景这里会调天气API # 这里只是演示数据结构不要把这个结果当真实天气 weather_map { 北京: {temperature: 5, humidity: 40, wind: 西北风3级, desc: 晴}, 上海: {temperature: 12, humidity: 65, wind: 东风2级, desc: 多云}, 广州: {temperature: 20, humidity: 80, wind: 南风1级, desc: 小雨}, } return weather_map.get(city, {temperature: None, desc: 暂不支持该城市})工具函数本身很简单但在真实项目里这里应该是调用外部天气 API、解析返回结果、再提炼出必要字段。这里有个设计原则工具的返回值要尽量简洁、结构化。等下我们会在第 4 章详细讲。现在先把完整流程跑通。给模型发送请求时的tools定义就是我在 2.2 节写的那份 JSON Schema。把整个流程串起来tools [ { type: function, function: { name: get_weather, description: 查询指定城市当前天气情况适合用户询问气温、降雨、风力时使用, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如北京、上海、广州 } }, required: [city] } } } ] messages [ {role: system, content: 你是一个生活助手回答用户问题时尽量简洁自然。}, {role: user, content: 北京现在天气怎么样要不要穿羽绒服} ] # 第一轮拿到模型消息 assistant_message call_model(client, messages, tools) print(模型初步响应:, assistant_message)如果模型判定需要调用天气工具assistant_message.tool_calls就会有内容。我们把工具名和参数打印出来看tool_call assistant_message.tool_calls[0] print(工具名:, tool_call.function.name) print(参数:, tool_call.function.arguments)正常情况下输出是工具名: get_weather 参数: {city: 北京}注意arguments是一个字符串形式的 JSON不是字典对象。需要用json.loads解析。很多踩坑场景都是漏了这一步直接拿去调用函数导致类型报错。接着执行工具把结果拼装成tool响应消息再让模型生成最终回答messages.append(assistant_message) parsed_args json.loads(tool_call.function.arguments or {}) tool_result dispatch_tool(tool_call.function.name, parsed_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(tool_result, ensure_asciiFalse) }) final_message call_model(client, messages, tools) print(最终回答:, final_message.content)两个细节必须强调。第一要给消息列表里追加assistant_message也就是模型那条带tool_calls的消息本身。如果我们不把它放进去后一次请求时模型就不知道刚才它自己已经决定调用过工具了它的上下文是断裂的。第二content字段必须传字符串所以工具返回的字典要用json.dumps序列化。直接把 Python dict 塞进去会让大部分 SDK 直接报错。到这里一个工具调用的最小闭环就完成了。第一轮模型决策应用执行第二轮模型总结。之后每次需要工具重复这个循环即可。3.3 多工具与路由分发模拟一个内部信息助手天气示例能跑通之后多工具的挑战就来了。我拿一个模拟场景来说做一个 HR 助手的雏形它需要支持查询员工入职日期、计算工龄、查询当前项目进度。用户问的问题往往需要串联多个工具才能回答。先定义三个工具函数def get_onboard_date(employee_name: str): 模拟查询员工入职日期 employees { 张三: 2021-03-15, 李四: 2019-07-01, 王五: 2023-01-10, } date employees.get(employee_name) if not date: return {error: 查无此人} return {employee_name: employee_name, onboard_date: date} def calculate_years_of_service(employee_name: str): 模拟根据入职日期计算工龄真实场景应该查库或调用HR系统 date_str get_onboard_date(employee_name).get(onboard_date) if not date_str: return {error: 查无此人无法计算工龄} # 简化演示以固定日期计算工龄 from datetime import date, datetime onboard datetime.strptime(date_str, %Y-%m-%d).date() today date(2025, 1, 1) years today.year - onboard.year - ((today.month, today.day) (onboard.month, onboard.day)) return {employee_name: employee_name, years_of_service: years} def get_project_status(project_name: str): 模拟查询项目状态 projects { 某跨平台系统: {status: 开发中, progress: 65%, owner: 李四}, 某图像处理Demo: {status: 已完成, progress: 100%, owner: 王五}, 模拟项目X: {status: 测试中, progress: 85%, owner: 张三}, } return projects.get(project_name, {error: 找不到该项目})然后把这些工具都放进tools列表里每个都写清楚 name、description、parameters。在这个模拟助手的使用场景里我实际调过这样的多工具链路用户问某跨平台系统这个项目谁负责的他入职多久了这个问题的完整处理路径应该是先用get_project_status查出项目负责人再拿负责人名字去调get_onboard_date或者calculate_years_of_service。模型在第一个回答里可能只调用了get_project_status然后我们继续推送结果模型又发现负责人有了但还缺他的入职日期于是发起第二次工具调用。所以主流程必须做成一个循环而不是只调一次就结束。伪代码如下def run_agent_loop(client, messages, tools, max_rounds5): for _ in range(max_rounds): assistant_message call_model(client, messages, tools) messages.append(assistant_message) if not getattr(assistant_message, tool_calls, None): # 没有工具调用说明模型已经可以直接回答用户了 return assistant_message.content for tool_call in assistant_message.tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments or {}) tool_result dispatch_tool(fn_name, fn_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(tool_result, ensure_asciiFalse) }) return 已达到最大工具调用轮次提前结束。循环是关键。没有这个循环模型只能做一步到位的工具调用一旦遇到需要连查两个工具的场景就废了。同时max_rounds必须存在防止模型进入死循环——比如它反复调用某个工具但参数总不对或者工具结果没有消除它的疑问它就会一直在那转圈。我一般把最大轮次设在 5 到 8 之间既能解决真实的连续推理需求又不会让成本和延迟失控。3.4 并行调用一次同时查多个城市工具调用发展到后期模型不再满足于一次只调一个工具。用户问北京和上海穿什么衣服合适时明明两个城市的天气互不影响完全可以同时查。如果应用还是一次只能处理一个工具第二轮如果还有别的信息需求那延迟就会线性增加体验很差。现在的协议普遍支持一个响应里返回多个tool_calls。在代码上只需要把for tool_call in assistant_message.tool_calls:这个循环换成先批量执行、再统一回传结果# 第一遍先执行所有工具得到结果 results [] for tool_call in assistant_message.tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments or {}) tool_result dispatch_tool(fn_name, fn_args) results.append((tool_call.id, tool_result)) # 第二遍把所有结果按 id 回传 for tool_call_id, tool_result in results: messages.append({ role: tool, tool_call_id: tool_call_id, content: json.dumps(tool_result, ensure_asciiFalse) })注意回传时必须保持tool_call_id和模型给出的值一一对应。一个响应里可能有call_01、call_02两个工具调用你回传结果时把结果挂错 ID模型就会分不清哪个结果对应哪个城市最后给出的回答大概率是张冠李戴。我在前期踩过这个坑当时查两个城市第一个城市的湿度被安到了第二个城市头上用户一眼就看出来不对。4. 工具设计的原则与进阶技巧4.1 描述是隐性提示词直接决定触发率和准确率很多人都把精力花在系统提示词上反复调教但忽略了工具列表其实就是一份非常关键的隐性提示词。模型在你给它的一大堆工具里筛选用哪个完全靠 name 和 description 做语义匹配。description 写得好不好直接决定了该调用的时候它会不会乱掉、不该调用的时候它会不会硬来。我的经验是第三方工具的 description 要回答三个问题这个工具是干嘛的一句话说清能力边界什么时候该用它给出典型的用户问题示例主要参数是什么、有没有特殊要求举个例子。一个查订单状态的工具description 如果只写查询订单模型触发准确率会很不稳定如果写成查询订单的当前状态、物流进度、预计送达时间。当用户询问订单到哪了、发货没有、什么时候能到时使用。参数 order_id 为订单号支持 20 位数字形式效果明显更好。我见过某个项目里模型老是把查天气工具用在查空气质量的问题上。排查下来发现天气工具的 description 写了查询城市天气和空气指数把空气质量这个场景也包进去了模型自然觉得它能干这个事。后来把空气相关的描述从天气工具里拆出去模型才停止误用。所以工具之间的描述边界一定要清晰别让两个工具在语义上重叠否则模型的选择就是随机行为。4.2 参数放得宽返回值收得紧工具的参数 Schema 有两个相反方向的要求。对输入要宽松对输出要紧凑。输入宽松的意思是能用string就尽量别搞复杂结构能用简单枚举就别搞正则表达式。模型生成参数字段本来就容易出现不确定性你若在 Schema 里写一个嵌套三层的对象它很容易生成缺字段、类型错误的结构函数一收到就是AttributeError。宁可让它传一个自由字符串然后在你的工具函数内部去解析、校验、容错你会发现整体成功率反而更高。返回值紧凑的意思是工具函数不要返回一坨完整的业务对象给模型。还是那句话模型的上下文窗口是有限的而且注意力会被大量无用字段稀释。比如查一个用户信息数据库里有 40 个字段但模型只需要知道部门、入职时间、状态那你就在工具函数里先取这三个字段再返回别把 40 个字段全塞回去。真实项目中我遇到过工具返回一段 8000 字的日志文本模型收到之后直接开始看不懂、复述、瞎编而且那一次请求的费用因为输入 token 暴增而变得很难看。从那以后我所有工具的返回逻辑都会有一个提炼层要么只返回核心字段要么截断超长文本并附上摘要要么允许调用方传参控制返回条数。工具是给模型供给信息的管道不是 dump 数据的仓库。4.3 安全边界把能调用和能授权分开工具调用赋予 Agent 的实际执行能力同时也意味着安全风险。一个能调数据库的工具、一个能发文件的工具、一个能执行系统命令的工具一旦被恶意提示词诱导影响范围可能远超预期。在给任何 Agent 加工具之前先想清楚权限边界。我的固定做法是三条最小权限只给它需要的最小操作集。如果一个工具只需要读就不要用有写权限的账号来执行。数据库账号给只读权限、文件目录用独立工作区、外部 API 用专用 Token。白名单化在dispatch_tool里只允许转向预先登记过的函数凡是没登记的一律报错。不要写一个反射机制结果模型传进来的os.system你也能调那等于敞开了大门。高危操作确认涉及删除、覆盖、转账、发布这类动作要先让 Agent 生成计划由用户或人工审核确认后再执行。这一点在自动化流程里很容易被省掉但省掉的代价是后来哭着补。工具调用和普通函数调用不一样普通函数调用是程序内部可控的工具调用则是模型在替你决定要不要触发某个外部动作。模型的决策天生有陌生场景下不够稳定的问题所以高风险动作必须引入人类确认环节这是实操层面最值得遵守的一条纪律。5. 常见问题与排错实录5.1 模型该调用时不调用不该调用时乱调用先看两个我遇到的典型表现。该调用时不调用用户问上海天气如何模型直接回答根据我了解到的情况……然后编造一个温度。不该调用时乱调用用户就问了一句你好模型非要调天气工具结果拿到上海温度然后回答你好上海今天 12 度。排查顺序我一般这么走看工具描述。描述是否覆盖了用户问题里的关键词有没有明确什么时候不适用看参数 Schema。是不是某个必填参数模型无法从问题里推断出来导致它干脆放弃调用举个例子工具必须有city但用户说的是帮我看看这里天气没有明确城市名模型就倾向不调用。此时应该允许city为空并在函数内部做默认值处理。看多工具之间的重叠。是不是有两个工具的 description 高度相似模型挑花了眼看系统提示词。如果你在 system 里写了不要使用不必要的工具之类的话模型会更加保守想让它积极用工具需要在提示词里显式授权。改 description 是最快见效的。我调过的大多数误用问题最后都落在描述太笼统或边界不清上。你在描述里把适用场景和排除场景都写出来模型的选择会稳定很多。5.2 解析tool_calls时报JSON错误模型返回的arguments是字符串形式的 JSON一般可以json.loads直接解析。但在非主流模型或特殊字符场景下可能遇到解析失败引号反了、布尔值大小写不对、多了尾逗号等。我写了一个带兜底的解析函数遇到异常时先把字符串里的危险片段打印出来人工确认同时让工具函数收到一个空字典而不是直接崩溃def safe_parse_arguments(raw_args): try: return json.loads(raw_args or {}) except json.JSONDecodeError: # 打印原始内容方便定位问题真实项目中接入日志系统 print(JSON解析失败原始内容, raw_args) return {}这个方法不算完美但它保证了主流程不崩。更彻底的办法是如果某个模型平台的工具调用结构经常坏优先换一个协议更稳定的主流模型而不是在解析层做越来越多的修补。5.3 上下文越滚越大Agent死循环循环调用是工具调用里很隐蔽的效率杀手。模型连续多轮都在调用工具但每轮执行结果都没有真正促进回答推进比如某工具连续返回空结果模型却还在固执地再试一次。死循环的防护手段我做了三件事设置绝对最大轮次比如 5~8 轮超了就强制退出并告诉用户当前问题太复杂建议拆分每轮调用前打印tool_call的函数名和参数摘要放到日志里。一旦发现某工具被重复调用且参数几乎没变化基本可以断定模型走进了死胡同在工具返回结果里加上是否真的找到答案的标记。模型面对空结果时要能收到一条明确消息没有找到匹配记录请向用户说明现状不要再次尝试。有时候模型反复循环就是因为工具结果模棱两可它不知道算不算成功。上下文膨胀还有一个来源每轮工具结果都很大几轮下来几千 token 就没了。尤其是工具返回一个长列表的场景会话第 3 轮开始模型可能已经忘了初始指令。解决方案我在 4.2 里提过——工具内部先做提炼返回紧凑结果。5.4 工具结果喂回模型的格式错误最后记录一个看着简单但很常见的低级错误把工具结果回传给模型的时候格式不对。协议要求的是tool角色的消息并且包含正确的tool_call_idcontent必须是一个字符串。容易犯的问题有三个忘记把原来的assistant_message追加到messages模型上下文断裂tool_call_id拷贝错了或者被复用导致模型无法关联工具结果与先前的调用直接把dict对象传给content忘了序列化SDK 直接抛异常。我后来把所有消息组装逻辑集中到一个函数里避免在业务代码里反复手拼消息列表。这在项目变大以后非常重要因为 Agent 的可靠程度很大程度上取决于消息历史是否干净、合规、不串味。最后再说两句实操体会工具调用做久了最大的感受是它不只是加一个函数那么简单更像是在给模型设计一套可用的外部器官。我把这个项目里积累的习惯分享给各位参考工具一开始先加最刚需的三五个别急着铺一大堆因为工具列表越多模型的选择负担越大误用率也越高每加一个工具都要自问一句——能不能复用已有的工具其次每一次误用都要当成一次数据反馈去改 description 而不是改提示词硬压我调过最明显的案例只是把描述里加了不包括XX场景一句话误用率直接降了一半多。我给自己的调试流程固定成这样一个习惯每次 Agent 输出异常时先开日志把模型的tool_calls原始返回打出来看它到底选了什么、参数填了什么再决定改哪里。很多事情不是模型笨是我们给它提供的工具没有说清楚。下一篇我会接着聊聊 Agent 的上下文窗口与记忆管理怎么让工具调用结果在长对话里不丢失、不混乱。如果你在落地工具调用时还有别的怪问题也欢迎随时交流。

从原理到实践：Agent工具调用实现与排错全解析

相关推荐

Windows本地PyCharm远程连接Linux服务器Anaconda环境配置指南

Mac上Edge多版本并存排查与安全清理实操指南

网络安全防御：构建纵深防御体系的实践指南

更多资讯

AIO Sandbox：单进程多界面开发沙箱架构解析

企业智能体直连数据库的6种落地方案对比

微信小程序web-view内H5分享功能实现与避坑指南

Qt多线程实战指南：QThread、moveToThread与线程池全解析

Debian/Ubuntu Linux常用命令速查手册：从系统初始化到故障排查的实战指南

Java报PKIX validity check failed：证书有效期校验失败排查与修复

今日更新

NetSpot 实战：用信道分析与频宽优化解决 Wi-Fi 卡顿

C++ split() 字符串分割的五种实现与性能实测

R语言坐标轴范围设置：从xlim/ylim到coord_cartesian的完整指南

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？