Agent 的工具怎么设计？为什么工具越多效果反而越差？
面试怎么回答
工具是写给模型看的接口，工具越多效果越差，主要是因为功能相近的工具让模型选择困难、工具描述占用上下文、细粒度工具串起来每一步都可能出错。我设计工具的原则是按任务而不是按接口设计，把常见任务封装成一个粗粒度工具；描述写清楚什么时候用、什么时候不用；参数少、类型严，能枚举就枚举；返回结果精简；错误信息写成模型能据此修正的提示；写操作单独成工具并做确认和幂等。工具多了就按意图按需加载、按领域分给子 Agent。最后用一组真实任务评测选对工具的比例、参数正确率和任务完成率，改工具描述也要跑回归。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
很多团队做 Agent 的第一反应是「把能接的接口都接上」，结果工具从 10 个加到 60 个，Agent 选错工具、参数填错的次数反而越来越多。面试官问这道题，想看的是：你知不知道工具是写给模型看的接口，设计好坏直接决定 Agent 的效果。
为什么工具越多效果越差
- 选择困难：工具描述都会放进上下文，几十个功能相近的工具（
query_order、get_order_detail、search_orders）让模型很难分辨该用哪个； - 上下文被占满：每个工具的名称、描述、参数 Schema 都要消耗 Token，工具多了，留给任务本身的上下文就少了；
- 组合爆炸：一个任务需要串 5 个细粒度工具，每一步都可能出错，整体成功率是每步成功率的乘积。
好工具的几个原则
- 按任务设计，不按接口设计：不要把后端 API 一比一暴露出去。与其提供「查用户」「查订单」「查物流」三个工具让模型自己拼，不如提供一个「查询某个订单的完整状态」；
- 名字和描述写清楚边界：描述里写清楚「什么时候用」「什么时候不要用」「和哪个工具的区别」，就像给新同事写的接口文档；
- 参数尽量少、类型尽量严：能用枚举就不用自由文本，日期统一格式，必填项明确；
- 返回结果要精简：只返回模型需要的字段，大结果分页或者截断，并告诉模型「还有更多」；
- 错误信息要可行动：不要只返回异常栈，而是返回「参数 date 格式错误，应为 YYYY-MM-DD」，模型才能自己修正；
- 区分读和写：写操作单独成工具，加确认和幂等键。
工具多了怎么办
- 按需加载：先根据用户意图选出相关的一组工具，再放进上下文，而不是每次全量加载；
- 分组和分层：把工具按领域分给不同的子 Agent，主 Agent 只负责分派；
- 定期清理：通过调用日志看哪些工具从没被用、哪些经常被误用，合并或者下线。
怎么验证工具设计得好不好
准备一组真实任务做评测，统计：选对工具的比例、参数一次填对的比例、平均调用步数、任务完成率。改工具描述和改代码一样，要跑回归。