原文:给 AI 设计“工具”时,不要把 AI 当成“程序”,要把它当成“用户”。
大多数人,是把自己的后端 API 直接封装成工具给 AI。 比如查 Slack,你给了它三个 API 工具:1. 加载对话;2. 用用户 ID 查用户名;3. 用频道 ID 查频道名。 结果 AI 为了看懂一条消息,得手忙脚乱地调用三次工具,然后自己去拼凑。 我最近在思考一个问题,如何不让一个agent的上下文太大,我感觉有些tool call和tool response执行完后就可以在上下文里去掉了,没必要占用着宝贵的上下文空间,但没想明白具体怎么做或遵循什么原则。 我们有一个api,好些参数,有的参数是一个列表,为了确定这个参数用列表中的哪个元素,我得先用一个tool call确定这个参数的值,但确定完后,我需要的信息只是这个参数值用啥,而这过程中的交互信息完全不需要了其实。
中文: 这是一条关于如何为AI设计工具的推文,并附带了一张进一步阐述此观点的图片。
主旨: 为AI设计工具时,应将AI视为“用户”而非“程序”,以提供更高效、更直观的交互方式。
问题阐述:
工具设计误区:
- 许多开发者倾向于将后端API直接封装成独立的工具提供给AI。
- 例如,为了让AI理解一条Slack消息,可能需要AI调用多个细粒度的工具(如“加载对话”、“通过用户ID查用户名”、“通过频道ID查频道名”),导致AI需要多次调用并自行拼凑信息,效率低下且过程繁琐。
上下文管理挑战:
- 作者正在思考如何避免AI代理的上下文(context)过大。
- 他认为某些
tool call和tool response在执行完成后,其结果可以从上下文中移除,以节省宝贵的上下文空间。 - 但对于具体实现方法和应遵循的原则,作者尚未有清晰的思路。
API参数处理的痛点:
- 作者提到他们有一个API,其中包含多个参数,部分参数是列表类型。
- 为了确定使用列表中哪个元素作为参数值,AI需要先执行一个
tool call来获取该参数的值。 - 然而,一旦参数值确定,后续只需要用到这个值本身,而确定过程中产生的交互信息(
tool call和tool response)实际上已不再需要,却仍占用着上下文。
总结: 推文呼吁在为AI设计工具时,要站在AI的“用户”角度思考,提供更集成、更智能的工具接口,并探讨了如何有效管理AI上下文以避免冗余信息占用和提高效率的问题。




















