OllamaSharp：把 Ollama 的每个 HTTP 端点包成 .NET 可等待方法

它解决的是绑定层问题，不是推理问题

Ollama 本身是一个常驻服务，默认监听 http://localhost:11434，对外暴露一组 HTTP 端点。在 .NET 里用它，最朴素的做法是拿 HttpClient 拼 JSON 请求体，再手动反序列化响应。单次调用还行，一旦涉及流式响应、模型拉取进度、多轮对话历史，样板代码会迅速膨胀。OllamaSharp 要消掉的就是这一层。README 的定位写得很直白：提供 Ollama API 的 .NET bindings，简化本地与远程的交互。

它的目标读者是有 C# 代码库、打算把本地模型接进现有应用的工程师。README 里提到它被 Microsoft Semantic Kernel、.NET Aspire 和 Microsoft.Extensions.AI 使用，NuGet 页面也标注了 Recommended by Microsoft，这些是采用信号，不是质量证明。判断它是否合适，还是要看你需要的端点是否都被覆盖，以及你的 Ollama 版本是否落在库的测试范围内。

每个端点一个可等待方法，Chat 类负责记住上下文

从 README 的用法示例能看出这层绑定的形状：OllamaApiClient 接收一个 Uri，然后通过 SelectedModel 属性指定后续操作使用的模型。模型管理、生成、对话分别对应不同的方法，ListLocalModelsAsync 返回本地模型列表，PullModelAsync 返回一个可异步枚举的进度流，每一项带 Percent 和 Status 两个字段。

生成和对话是两个不同层次的入口。GenerateAsync 映射到 /api/generate 端点，README 明确说它适合单轮、无上下文的补全。真正用于对话的是 Chat 类，构造函数接收客户端，SendAsync 返回逐 token 的可异步枚举序列。关键差异在状态管理：README 说明 Chat 会自动跟踪完整的消息历史，包括工具调用及其结果，跨轮次保留，并通过 Messages 属性暴露出来。也就是说上下文维护的责任从调用方转移到了 Chat 对象内部。这个设计让简单场景的代码极短，但也意味着长会话下 Messages 会持续累积，什么时候裁剪、什么时候重建 Chat 实例，是使用方要自己想清楚的问题。

工具调用、视觉与结构化输出都挂在 Chat 上

README 的功能列表里，工具引擎被单独列出来，描述是 sophisticated tool support with source generators，指向文档中的 tool-support 页面。这里用 source generator 而不是运行时反射来做工具定义，对 Native AOT 场景是有意义的，因为反射式序列化在裁剪后的程序集里往往不可用。

多模态方面，README 提到支持 vision models，并链接到 Ollama 官方的视觉模型公告。Chat 类除了 SendAsync，还可以设置 system prompt、发送图像、请求结构化 JSON 输出、为推理模型开启 thinking 模式，这些能力的具体参数名和调用方式在 README 里没有展开，只给了指向 chat-and-generate 文档的链接。这一点值得注意：功能列表列得比示例详细，实际接入时文档页面才是主要依据。

最小可运行路径与 Native AOT 的额外一步

常规场景的初始化是两行：构造 OllamaApiClient 传入 http://localhost:11434，然后设置 SelectedModel。README 示例里用的模型名是 qwen3.5:35b-a3b，这只是示例值，实际要换成你本地已经拉取的模型。

Native AOT 需要换一条构造路径。README 给出的做法是定义一个带 JsonSerializable 特性的 partial 类，继承 JsonSerializerContext，然后调用接收 JsonSerializerContext 的静态工厂方法，把上下文传进去。这一步不能省，因为 AOT 编译后的程序集没有运行时反射生成序列化器的能力。README 把细节指向 docs/native-aot-support.md。

云端模型走的是另一条路：用接收 HttpClient 的构造函数，把 API key 加进 DefaultRequestHeaders。README 的这段代码在截断处结束，header 的键名没有给出，需要查 Ollama 云端文档确认。

Microsoft.Extensions.AI 抽象带来的可替换性

OllamaSharp 实现了 Microsoft.Extensions.AI 的两个接口：IChatClient 用于模型推理，IEmbeddingGenerator<string, Embedding<float>> 用于向量生成。README 说明它是这套抽象的第一个完整实现。

这个抽象解决的是供应商锁定问题。示例代码里有一个 CreateChatClient 方法，根据 provider 参数决定返回 OllamaApiClient 还是 OpenAIChatClient，两者的返回类型都是 IChatClient。调用方只依赖接口，切换后端时改动集中在工厂方法里。对需要同时支持本地模型和云端 API 的应用，这个层次的分隔比直接依赖 OllamaApiClient 更划算。代价是抽象层只暴露各家能力的交集，Ollama 特有的端点，比如模型拉取进度、模型复制删除，仍然要通过 IOllamaApiClient 访问。

什么时候不该用它

最明显的一条：如果你的程序只调用 /api/generate 一个端点，引入一个绑定库换来的收益接近于零。手写一个 HttpClient 请求加一次反序列化，代码量不会比配置 OllamaApiClient 更多，还少一个依赖。

第二条与版本有关。OllamaSharp 的策略是把每个 Ollama API 端点逐个包起来，README 的原话是 covers every single Ollama API endpoint。这个覆盖度是优势，也是耦合点。Ollama 服务端端点语义发生变化时，库需要跟着发版。从提供的发布记录看，5.4.28、5.4.29、5.4.30 三个版本集中在同一天发布，说明维护节奏很快，但也说明版本号变动频繁。如果你的生产环境对依赖升级有严格窗口，需要评估这个节奏能否接受。

第三条关于抽象层本身。IChatClient 只覆盖推理和嵌入两类操作，模型管理能力不在其中。如果你的应用核心是模型生命周期管理而不是推理，这个抽象帮不上忙，直接用 IOllamaApiClient 更直接。

许可证与维护成本

OllamaSharp 使用 MIT 许可证。MIT 是宽松型许可，允许在闭源产品中使用和修改，通常只需要保留版权声明和许可文本。这里不做法律建议，具体义务以仓库中的 LICENSE 文件为准。

维护成本主要来自两处。一是库本身的升级频率，发布记录显示版本迭代密集，跟进意味着持续的依赖更新工作。二是它与 Ollama 服务端的版本对应关系，README 没有给出兼容性矩阵，所以升级库之前需要自己确认目标 Ollama 版本是否被覆盖。如果你把 OllamaSharp 用在长期维护的产品里，把库版本和 Ollama 版本一起固定下来，比单独升级其中一侧更可控。

采用判断

需要流式输出、模型拉取进度、多轮对话历史管理，或者需要在多个 AI 供应商之间切换的 .NET 项目，OllamaSharp 覆盖了这些场景的常规路径，Chat 类自动维护消息历史这一点能省掉不少状态管理代码。

只需要调用单个端点、或者对依赖升级节奏敏感的项目，直接使用 HttpClient 更简单。决定采用之前，先确认三件事：目标 Ollama 版本是否在库的支持范围内，长会话下 Chat 的 Messages 增长是否需要自己处理，以及如果走 Native AOT，JsonSerializerContext 是否已经按文档配置好。

编辑结论

如果你在 .NET 里调用 Ollama，并且需要流式输出、模型拉取进度、工具调用或 Microsoft.Extensions.AI 的 IChatClient 抽象，OllamaSharp 省掉了自己写 HTTP 客户端和 JSON 映射的工作。如果你只需要调用一两个端点，或者你的 Ollama 版本比库支持的版本更新，直接发 HTTP 请求反而更省事。上手前先确认三件事：nuget 上 5.4.x 的发布日期与你本地 Ollama 的版本是否对得上，因为库按 Ollama 端点逐个封装，端点语义变化会直接反映到方法签名；再确认你是否真的需要 Chat 类自动累积历史，长会话下 Messages 会持续增长；最后如果目标是 Native AOT，先按文档写一个 JsonSerializerContext 并走静态工厂方法，否则序列化路径不成立。

官方来源

1. awaescher/OllamaSharp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases