一、函数调用能不能用，取决于描述写得好不好
模型不读你的代码，它读你给的工具描述。
描述含糊，它就会乱选工具、乱填参数。问题通常不在模型，在文档。
函数调用成功率低，八成不是模型笨，是描述没写清。
模型不知道你的函数干什么，它只能读描述。描述写得含糊，它就会乱猜参数，或者该调不调。
我改过一组工具描述，成功率从六成上到九成，没换模型，只改了文字。
二、描述要写四件事
一、这个工具做什么，一句话说清。
二、什么时候该用，什么时候不该用。这一条大部分人都漏了。
三、参数含义与格式，包括取值范围和单位。
四、返回什么，成功与失败分别长什么样。
第三、四项最影响成功率。
资产按三类准备：地形、物件、以及装饰。三类分开，排图时才好调比例。
地形决定骨架，物件决定玩法，装饰决定氛围。
很多人的问题是装饰给太多，地形给太少，排出来像贴纸拼的。
三、参数设计的三条原则
原则一，必填参数越少越好。每多一个必填项，多一次填错机会。
原则二，用枚举代替自由文本。能列出来的，就给固定选项。
原则三，日期、金额这类，明确写格式。别让模型去猜是毫秒还是秒。
描述要写四件事：这个工具干什么、什么时候该用、参数是什么意思、返回什么。
四件事里最关键的是第二件。只写功能不写时机，模型就会在不该用的时候用。
比如「查询订单状态」这种描述不够，要补一句「当用户询问物流进度或订单是否发货时使用」。这一句能挡掉大量误调用。
参数描述要带例子。写「date: 日期」不如写「date: 格式 YYYY-MM-DD，例如 2026-11-14」。模型对例子的敏感度远高于对说明的敏感度。
还有一条容易忘：把参数的取值范围写出来。枚举值写全，模型就不会编一个不存在的值。
四、工具太多怎么办
给模型三十个工具，它会挑花眼。
三个处理办法：
一、按场景分组，每次只暴露相关工具箱。
二、提供一层路由，先判断意图再决定暴露哪些工具。
三、合并相似工具，把三个只差一个参数的接口合成一个。
两阶段来做：先灰度排版，再加细节。
灰度阶段只关心层次和可玩性，不关心好看。这一步做完，地图好不好玩基本就定了。
加细节阶段最容易推翻前面的判断。所以要先把灰度版本存档，改坏了能回去。
五、出错之后怎么修
一、把失败原因结构化返回，不要只给"失败"两个字。
二、允许重试，但限制次数，通常两次就够。
三、记录每次调用的参数，出问题时能复盘。
工具太多怎么办？我的做法是分两批：常用工具常驻，冷门工具按需加载。
一次给模型二三十个工具，它会开始挑错。控制在十个以内，准确率明显上升。
另一个办法是给工具分组，先让模型判断属于哪一组，再只给那一组工具。多一步，但错得少。
分组还有个副作用：描述会被逼着写清楚，因为同组内必须能区分。这对整体质量是好事。
六、一个自测清单
拿十个真实请求跑一遍，问自己三句：
工具选对了吗？
参数填全了吗？
不该调用的时候，它停住了吗？
第三句最能暴露问题。很多系统会滥用工具，明明问一句话就能答，非要调三个接口。
出错之后怎么修，别看整体成功率，看失败样本。
把失败案例按类型分：参数错、时机错、该调不调、不该调乱调。四类各有各的改法。
参数错改描述，时机错补触发条件，该调不调加示例，乱调就收窄适用范围。分类之后，修改就有针对性了。
我一般会留一个自测清单：十个典型问法，每次改完跑一遍。清单不长，但能挡住改一处坏一处的情况。
排图避坑的三条：别让可走区域和装饰混在一起、别让高低差超过三格、别让视线被完全遮挡。
第一条影响操作，第二条影响体验，第三条影响节奏。
第三条尤其重要。全遮挡的地图，玩家会迷路，然后就不玩了。
延伸参考
推理和模型相关的名词，前端 Wiki 里的解释短而准。
留一句：函数调用的上限，是你把接口文档写到多清楚。
