工具颗粒度设计在设计工具函数时每个函数的职能需要适当把控如果工具写得很碎分成了很多个函数Agent在使用时就需要调用很多次工具每个都单独调用轮次会变多成本也高。如果很多个都写在一起比如一个工具一次返回几百个字段Agent 又很难读懂重点。 最好的方式是按照需求去写如果是项目要求就直接针对模块设计就好如果是做的通用工具就需要想好一般用到工具时的思路便可也就是说关键是在于将工具函数封装为Agent容易理解和选择的单元这也符合“工具”的设计初衷适合、好用的才是最好的。工具函数的提示词虽然工具函数由代码构成很多人喜欢像写注释一样把其描述形式往自己理解的方向靠但是事实上工具描述的最好是写成这个工具能做什么什么时候要调用参数填写说明返回什么类型的信息等需要比较详细全面的说明目的也是为了让Agent能够容易理解该工具的作用提示词边界agent的提示词确实给agent提供了方向所写的功能和逻辑思路可以告诉agent应该怎么去解决对应的问题同时我们也可以在提示词里加入言语来避免agent的幻觉行为。事实上这是一个很有必要的做法因为我们无法保证是否可以百分百把所有的用户问题都考虑进来这个时候结合集合的思想反过来让agent不要去做某些事情既能节省token又能避免答案出错进入过多不必要的轮次缓存处理在调用搜索工具时、网页抓取类工具时可能会遇到因为api或者网络波动问题导致响应有延迟甚至即便做了并发处理也还是会有堵塞现象的发生这个时候就可以做缓存处理比如把最近十次或者一百次的查询作为缓存存储遇到相同的查询内容短时间内就走缓存这样用户在使用时就不会频繁遇到波动导致体验不佳
