工具集设计关键因素?

这道题其实问的是，怎么让大模型安全、高效地调用外部能力，核心是在灵活性和可控性之间找平衡。

先说工具粒度。我做的时候会遵循一个原则：每个工具只做一件事，但这件事要做得完整。比如搜索工具，我不会拆成search_web和parse_results两个，因为模型调用两次成本高，容易出错。但也不建议写一个do_everything的大工具，那样模型很难判断什么时候该用。真正落地时，我倾向于把常用操作封装成中等粒度的工具，比如search_flights、book_flight，复杂任务再通过[[ReAct]]或[[Chain-of-Thought]]组合调用。

再一个关键是工具描述。模型能不能正确调用，百分之八十靠描述。我一般会在description里写清楚触发场景和参数含义，比如“当用户问房贷月供时调用，本金单位是万元，利率是年化百分比”。如果参数有默认值或边界，我也会写进去，比如“贷款年限不超过30年”。这样能减少模型瞎填参数的情况。

调用机制上，我会分三块。先说意图识别，我一般用[[Function Calling]]机制，模型自己选工具，但我会在system prompt里给一些few-shot例子，比如“用户说查天气，优先调用get_weather”。接着说参数校验，模型填的参数不一定是合法的，我会做一层JSON Schema校验，缺失的让模型追问用户，不合法的报错让模型重试。再补充执行安全，敏感操作比如发邮件、扣款，我会放到沙箱里执行，或者加一道人工确认。

这里有个常见的坑：工具调用失败怎么办？比如天气API超时了。我会把错误信息原样返回给模型，让它自己决定是重试、换工具还是告诉用户稍后再试。但得设个超时熔断，防止一个工具卡死整个[[Agent]]。

结果回传也要注意。工具返回的数据可能很长，比如搜索返回100条结果，直接塞回上下文会浪费token，还可能冲淡模型对用户问题的注意力。我会做摘要或只取前几条，同时保留工具调用的轨迹，也就是thought-action-observation，这样模型能回顾自己做过什么，方便多轮规划。