C#中OllamaSharp工具调用优化与OpenAI兼容方案

1. 问题背景：Ollama在C#中的ToolCall为何表现不佳

最近在端侧部署小参数模型进行自动化操作时，我发现一个有趣的现象：同样的Qwen30B-A3B模型，通过阿里百炼平台直接调用时，其ToolCall功能的表现明显优于通过Ollama部署的版本。作为C#开发者，我们通常会使用OllamaSharp这个NuGet包来与Ollama交互，但实际使用中发现它在处理复杂参数时存在明显缺陷。

具体表现为：当方法调用的参数涉及引用类型或嵌套结构时，OllamaSharp生成的上下文会完全丢失参数细节。这直接导致模型无法正确理解调用意图，最终表现为"笨拙"的响应。通过分析OllamaSharp的源码可以看到，其参数序列化逻辑存在设计缺陷，无法妥善处理复杂对象结构。

2. 问题根源分析：OllamaSharp的实现缺陷

2.1 参数序列化机制的问题

深入研究OllamaSharp的源码后，我发现其ToolCall参数处理的核心问题在于：

1. 扁平化序列化策略：对于复杂对象，它采用简单的ToString()或基础类型转换，导致嵌套结构信息丢失
2. 类型信息缺失：生成的提示词中不包含参数的类型定义，模型无法理解数据结构
3. 引用处理不当：对引用类型参数的处理过于简单，没有考虑循环引用等常见场景

例如，当传递一个包含嵌套列表的对象时：

csharp复制var param = new {
    Name = "test",
    Items = new List<string> { "A", "B" }
};

实际生成的提示词可能简化为：

code复制调用方法X(参数: System.Object)

而不是理想的：

code复制调用方法X(参数: {Name: string, Items: string[]})

2.2 与阿里百炼的对比

阿里百炼平台的处理则更加完善：

1. 保持完整的类型信息
2. 支持递归序列化嵌套结构
3. 提供参数schema定义
4. 自动处理特殊类型(如DateTime、Guid)

这种差异解释了为什么同样的模型在不同平台上表现迥异。OllamaSharp的简化处理虽然降低了实现复杂度，但严重影响了模型的理解能力。

3. 解决方案：转向OpenAI兼容接口

3.1 使用Microsoft.Extensions.AI.OpenAI

Ollama实际上提供了OpenAI兼容的API端点，我们可以直接使用官方的OpenAI客户端：

csharp复制services.AddOpenAIClient(options => {
    options.BaseUrl = "http://localhost:11434/v1"; // Ollama的OpenAI兼容端点
    options.ApiKey = "ollama"; // 任意非空字符串
});

这种方式的优势在于：

1. 使用标准的OpenAI ToolCall规范
2. 参数序列化更加规范
3. 支持完整的类型系统
4. 与Azure