Qwen-Agent项目中的工具调用优化策略分析

背景介绍

在Qwen-Agent项目中，Assistant作为核心组件之一，负责处理用户请求并调用各种工具完成任务。然而，在实际应用中，开发者发现当前实现存在一个潜在的性能问题：当Assistant调用工具获取结果后，会再次通过大语言模型(LLM)处理工具返回的结果，导致两次LLM调用，这不仅增加了响应时间，也提高了计算成本。

问题本质

这种设计源于Qwen-Agent的默认工作流程：

1. 首先由LLM决定调用哪个工具并生成调用参数
2. 工具执行后返回结果
3. 再次由LLM处理工具返回的结果并生成最终响应

对于某些场景，特别是当工具本身已经能够生成格式良好的响应时，第二次LLM调用就显得冗余了。

解决方案探讨

方案一：修改FnCallAgent循环逻辑

Qwen-Agent的核心开发者指出，可以通过修改FnCallAgent父类中的_run方法中的while循环来实现优化。具体来说，可以调整MAX_LLM_CALL_PER_RUN参数，将其设置为1，限制每次运行最多只调用一次LLM。

这种方法的优势在于：

• 保持现有架构不变
• 只需简单参数调整即可实现
• 对现有代码侵入性小

方案二：直接使用底层LLM接口

社区成员提出了另一种思路：绕过Agent层，直接使用底层的LLM接口。通过get_chat_model获取模型实例后，直接调用chat方法并传入functions参数，这样可以获得原始的函数调用结果。

这种方法的特点：

• 更接近底层实现
• 完全避免Agent层的额外处理
• 需要开发者自行处理函数调用和结果解析

方案三：自定义Assistant实现

一位开发者贡献了CustomAssistant的实现代码，通过继承Assistant类并重写_run方法，增加了num_llm_calls_available参数来控制LLM调用次数。这种方案提供了更灵活的配置选项，同时保持了Agent架构的完整性。

技术实现细节

在CustomAssistant的实现中，关键点包括：

1. 通过ChatConfig类封装配置参数
2. 重写_run方法时引入调用次数控制
3. 保持原有工具调用流程但限制LLM二次处理
4. 使用yield实现流式响应

最佳实践建议

根据不同的应用场景，可以考虑以下策略：

1. 简单工具调用场景：直接使用底层LLM接口，效率最高
2. 复杂工作流场景：使用修改后的CustomAssistant，平衡功能与性能
3. 需要严格控制的场景：限制MAX_LLM_CALL_PER_RUN参数

未来优化方向

从技术讨论中可以预见几个可能的优化方向：

1. 将MAX_LLM_CALL_PER_RUN参数开放给用户配置
2. 提供更灵活的结果处理策略选项
3. 支持工具标记是否需要进行二次LLM处理
4. 优化Agent架构，减少不必要的LLM调用

总结

Qwen-Agent项目中的工具调用优化是一个典型的性能与功能平衡问题。通过本文分析的各种方案，开发者可以根据具体需求选择最适合的优化策略。无论是简单的参数调整、底层接口调用还是自定义实现，都能有效减少不必要的LLM调用，提升系统响应速度和运行效率。