上下文压缩策略这块我也挺有心得的，之前做法律咨询Agent，各种法律条文、案例堆上来，Token 蹭蹭往上涨。我的选择是组合拳：
* 前期滑动窗口: 保证实时对话体验。
* 中期LLM摘要 (Branch Summarization): 重点保留案件关键决策、未完成任务和约束条件。
* 高频工具结果替换: 比如查询数据库的中间结果，用个简短的“成功”或者“失败”代替。
最大的坑是，别一股脑压缩！要分阶段、有重点。不然，Agent就变成“金鱼记忆”了。
ACI的精髓在于：把Agent当做一个“人”，而不是一个程序。
要设计出符合ACI原则的工具，就要像设计用户界面一样，考虑Agent的“用户体验”。以下几个方面很重要：
* 命名： 工具名称要简洁明了，让Agent一眼就能明白其用途。
* 描述： 工具描述要详细具体，包括输入参数的含义、使用场景、注意事项等。
* 示例： 提供一些工具调用的示例，帮助Agent更好地理解其使用方法。
至于是不是应该优先检查工具描述，我绝对赞同。因为工具描述是Agent理解工具功能的关键，如果描述有问题，Agent肯定会用错。就像我们使用一个新软件时，首先要看帮助文档一样。