ChatGLM3项目函数调用功能失效问题分析与解决方案

问题背景

在ChatGLM3项目的开发过程中，近期出现了一个影响较大的技术问题：官方提供的所有基于AI服务API实现的函数调用功能突然全部失效。这一问题直接影响了项目中两个关键示例脚本（api_request.py和api_demo.py）的正常运行，只有基于HuggingFace的composite_demo仍能正常工作。

问题根源分析

经过技术团队深入排查，发现问题源于一次代码提交（6c0afae6e4cf6a24143c67d976d295cd1869de50）。该提交本意是改进agent chat功能，但在实现过程中出现了两个关键问题：

1. 路由变更问题：开发者原本计划使用新的web endpoint /agent/chat，但实际修改的却是/v1/chat/completions接口，导致功能路径错位。

2. 工具调用限制：代码中错误地将所有外部传入的tools声明完全屏蔽，只允许使用tools包下预定义的函数，这与项目最初设计的开放性原则相违背。

技术影响评估

这一变更对项目产生了多方面影响：

1. 功能兼容性破坏：原本支持的外部工具集成功能突然失效，导致依赖此功能的用户无法正常使用。

2. 设计原则冲突：项目最初遵循"API对接时不处理工具执行部分"的原则，但此次变更却将工具执行强制纳入项目内部管理。

3. 用户体验下降：用户突然面临功能不可用的情况，且缺乏明确的错误提示，增加了排查难度。

解决方案演进

技术团队针对此问题提出了多阶段的解决方案：

临时解决方案

建议用户回退到早期版本（7bd44df08d1476a264724bff59010bede3f79fbf），该版本函数调用功能正常。

最终解决方案

经过社区讨论和代码审查，技术团队提交了新的PR，实现了：

1. 恢复默认配置下外部tools的传入功能
2. 添加了相关的环境变量配置
3. 确保两种模式兼容：
   • 标准AI服务接口模式（适用于有API key的场景）
   • 自定义路由模式（适用于无API key等特殊场景）

技术实现细节

最终的解决方案体现了以下技术特点：

1. 双模式兼容设计：

   • 标准模式保持AI服务接口的流式体验优势
   • 自定义模式提供更强的灵活性和适应性

2. 增强的调度能力：

   • 内置工具调度异常的自修复机制
   • 允许用户自定义接口路由参数

3. 开发者友好性：

   • 用户可专注于工具箱(tools)开发
   • 无需关心底层调度算法实现

经验总结

此次事件为开源项目管理提供了宝贵经验：

1. 变更影响评估：即使是改进性变更，也需要全面评估对现有功能的影响。

2. 设计原则坚守：应当坚持项目最初的设计理念和接口约定。

3. 兼容性保障：新功能的引入不应破坏现有功能的正常使用。

4. 及时响应机制：社区成员发现问题后能够快速响应并提出解决方案。

通过这次问题的解决，ChatGLM3项目的函数调用功能不仅得到了恢复，还在可用性和灵活性方面获得了提升，为后续的功能扩展奠定了更坚实的基础。