Semantic Kernel中的ChatHistory重复工具调用结果问题解析

背景介绍

在Semantic Kernel的对话式AI开发中，开发者经常会使用GetStreamingChatMessageContentsAsync()方法来获取聊天消息内容。当这个方法调用插件或工具时，系统会在ChatHistory中添加工具调用的结果。然而，一些开发者发现这些结果在ChatHistory的Items集合中出现了重复存储的情况。

问题现象

通过观察ChatHistory的内容结构，可以发现在工具调用完成后，系统会同时存储两种形式的内容：

1. 工具调用的文本表示形式
2. 代表调用本身的内容类型对象

这种双重存储机制让开发者担心会增加后续LLM调用的token消耗，特别是在频繁使用工具调用的场景下，可能导致token使用量急剧上升。

技术原理

实际上，虽然ChatHistory中确实存在看似重复的内容，但系统在向LLM发送请求时，只会包含其中一种形式的内容——即FunctionResultContent类型的项目。这种设计主要考虑了以下技术因素：

1. 向后兼容性：新版本的Semantic Kernel引入了FunctionCallContent和FunctionResultContent类，为了保持与旧版本的兼容性，保留了文本形式的存储

2. 调试与日志：文本形式的存储有助于开发者调试和查看历史记录

3. 功能扩展：不同类型的存储可能在未来支持不同的使用场景

优化建议

对于确实遇到token使用量过高问题的开发者，可以考虑以下几种优化方案：

1. 使用聊天历史缩减技术：Semantic Kernel提供了ChatHistorySummarizationReducer等工具，可以有效减少历史记录的大小

2. 调整缩减参数：通过合理设置targetCount和threshold等参数，平衡历史信息的完整性和token消耗

3. 自定义摘要提示：利用SummarizationInstructions属性提供自定义的摘要提示，获得更适合业务场景的缩减效果

未来展望

开发团队表示，在确保安全性的前提下，未来可能会考虑移除这种重复存储机制。同时，系统也在不断完善各种历史记录优化工具，帮助开发者更好地控制token使用量。

对于开发者而言，理解这种设计背后的技术考量，合理使用系统提供的优化工具，就能在保持功能完整性的同时，有效控制token消耗成本。