Ollama ToolCall在C#中的性能优化与解决方案

1. 问题背景：Ollama ToolCall在C#中的"笨拙"表现

最近在端侧部署小参数模型进行自动化操作时，我发现一个有趣的现象：使用Qwen30B-A3B模型时，直接调用阿里百炼API的效果明显优于通过Ollama部署的同模型ToolCall功能。作为长期使用C#进行AI集成的开发者，这个性能差异引起了我的注意。

经过深入测试，当使用OllamaSharp（C#调用Ollama的默认包）进行方法调用时，如果参数涉及引用类型或嵌套结构，模型会完全丢失参数细节上下文。这直接导致ToolCall的准确性和可靠性大幅下降。例如，当传递一个包含多层嵌套的JSON对象时，模型往往无法正确解析参数结构，最终产生错误的输出或直接失败。

关键发现：OllamaSharp在处理复杂参数时存在序列化缺陷，这可能是其ToolCall表现"笨拙"的核心原因

2. 技术解析：OllamaSharp的实现缺陷

2.1 参数序列化机制分析

查看OllamaSharp的源代码（特别是ToolCall相关部分），可以发现其参数处理机制存在明显问题。以下是主要问题点：

1. 扁平化序列化：所有参数被强制转换为扁平化的键值对结构，丢失了原始数据的关系信息
2. 类型擦除：引用类型参数被序列化为纯文本，类型信息完全丢失
3. 嵌套结构截断：对于嵌套超过两层的对象，内部结构会被简化为字符串表示

csharp复制// OllamaSharp中问题代码示例（简化版）
public class ToolParameter {
    public string Name { get; set; }
    public object Value { get; set; } // 问题根源：无类型约束的object
    
    public string ToJsonString() {
        // 简单ToString()转换，无法处理复杂对象
        return $"{{\"{Name}\":\"{Value?.ToString()}\"}}"; 
    }
}

2.2 与阿里百炼的对比测试

通过对比测试相同的Qwen30B-A3B模型在不同平台的表现，可以清晰看到差异：

| 测试场景