OpenAI 与 Anthropic 的.NET SDK 对比

1. 摘要

随着生成式人工智能（Generative AI）从实验性技术迈向企业级核心基础设施，.NET 生态系统正在经历一场深刻的架构转型。在过去二十四个月中，C# 开发人员与前沿大语言模型（LLM）的交互方式，已从依赖社区维护的非官方封装库，彻底转向了由模型厂商官方提供的一方软件开发工具包（SDK）。本文旨在针对当前市场上两个最具统治力的官方.NET SDK——openai/openai-dotnet（OpenAI 官方库）与 anthropics/anthropic-sdk-csharp（Anthropic 官方库）——进行详尽的、技术深度的对比分析。

openai/openai-dotnet 是微软与 OpenAI 深度战略合作的产物，其底层构建于微软最新的 System.ClientModel 架构之上，旨在与 Azure 云服务生态实现无缝且严格的统一，但在灵活性和抽象层透明度上有所妥协。相比之下，anthropics/anthropic-sdk-csharp 虽然刚刚完成从社区项目（原 tryAGI）到官方产品的身份转换，但它展现出了更符合现代.NET 开源精神的敏捷性，率先原生实现了微软推崇的 Microsoft.Extensions.AI 抽象标准，并成为模型上下文协议（MCP）在 C# 领域的先行者。

2. 生态定位与发展沿革

理解这两个 SDK 的起源与演进轨迹，对于评估其长期支持生命周期（LTS）、社区活跃度以及技术债风险至关重要。

2.1 OpenAI.NET SDK：微软战略协同的产物

openai/openai-dotnet 的诞生并非孤立事件，而是微软与 OpenAI 紧密联盟在开发者工具层的直接体现。在官方库发布之前，.NET 社区主要依赖 Betalgo.OpenAI 或 RageAgainstThePixel 等高质量的第三方库。官方库的推出标志着这种分散局面的终结，并带来了标准化的 API 契约。

  • 协同开发模式：该库的代码并非完全由人工手写，而是主要基于 OpenAI 的 OpenAPI 规范自动生成。这一生成过程由 OpenAI 与微软 Azure SDK 团队深度协作完成。这种合作模式确保了 OpenAI 官方库在命名规范、错误处理和异步模式上与 Azure SDK for.NET 保持高度一致。
  • 双重身份与伴生关系：该 SDK 实际上承载了双重使命。它既是访问 platform.openai.com（原生 OpenAI API）的官方客户端，又是 Azure.AI.OpenAI 库的核心底层依赖。微软采用了一种“伴生库”（Companion Library）的架构策略：Azure.AI.OpenAI 继承并扩展了 openai/openai-dotnet 的功能，增加了 Azure Active Directory (Entra ID) 身份验证和特定于 Azure 的终结点路由逻辑。这意味着，掌握了 OpenAI 官方 SDK 的开发者，可以零成本迁移到 Azure OpenAI 服务。
  • 成熟度与发布节奏：截至 2026 年初，该库已进入稳定维护期，但其更新频率极高，通常在 OpenAI 发布新模型（如 o1 系列或 GPT-4.5）后的数小时至数天内即发布对应的 NuGet 包更新，展现了极强的敏捷性。

2.2 Anthropic C# SDK：从社区到官方的华丽转身

与 OpenAI 库含着“金汤匙”出生不同，Anthropic 的 C# SDK 走过了一条典型的开源社区进化之路。在很长一段时间内，Anthropic 官方并未提供 C# 支持，这导致了 tryAGI.Anthropic 等社区库的蓬勃发展。

  • 官方化进程：随着版本号跨越至 10.0，Anthropic 正式接管了该 GitHub 仓库，将其重新品牌化为官方 SDK。这一举措消除了企业用户对“第三方库停更风险”的合规顾虑，是 Claude 模型进入企业核心业务系统的关键一步。
  • Beta 状态的内涵：与 OpenAI SDK 相对稳定的 API 表面不同，Anthropic C# SDK 目前明确标记为 Beta 状态。这不仅仅是一个版本标签，更暗示了其架构仍在快速迭代中，特别是在配合模型上下文协议（MCP）和新一代代理工作流方面，API 可能会发生破坏性变更（Breaking Changes）。
  • 社区基因的保留：尽管已官方化，该代码库仍保留了浓厚的社区基因。例如，它在配置 HTTP 客户端、处理超时和重试策略时，提供了比微软生成的代码更直观、更符合传统.NET 习惯的接口，赋予了开发者更大的底层控制权。

3. 核心架构设计哲学对比

两个 SDK 最本质的区别在于其底层 HTTP 管道（Pipeline）的构建方式以及类层次结构的设计。

3.1 OpenAI 与 System.ClientModel：标准化与黑盒化

OpenAI SDK 构建在微软推出的 System.ClientModel 基础之上。这是一个旨在统一所有.NET 客户端库行为的底层原语集。

  • 管道架构（Pipeline Architecture）：当开发者实例化一个 ChatClient 时，实际上是在配置一个复杂的 ClientPipeline。这个管道负责处理 HTTP 请求的序列化、重试逻辑、日志记录和分布式追踪。这种设计的优点是一致性——OpenAI 客户端的行为与 Azure Storage 或 KeyVault 客户端完全一致，都能自动接入 Azure Monitor 等可观测性工具。
  • 黑盒化的代价：然而，这种高度抽象也带来了“黑盒化”的副作用。System.ClientModel 内部封装了大量的策略（Policies），例如重试策略。如果开发者需要实现一些非标准的需求（例如：在重试前修改某些 Header，或者根据特殊的 HTTP 状态码进行熔断），往往发现难以切入，因为标准的 HttpClient 处理器链（Handler Chain）被 ClientPipeline 屏蔽了部分细节。
  • 分散的客户端层级：OpenAI SDK 遵循“关注点分离”原则，没有提供一个包罗万象的“OpenAIClient”来处理所有请求。相反，它强迫开发者针对不同功能实例化不同的客户端：
    • ChatClient：处理文本对话。
    • ImageClient：处理 DALL-E 图像生成。
    • AudioClient：处理 Whisper 语音转录。
    • RealtimeClient：处理实时语音流（Beta）。
      这种设计有利于依赖注入的颗粒度控制和 Tree-Shaking（死代码消除），但在需要多模态交互（例如：先语音转文本，再文本对话，最后生成图片）的场景下，增加了对象生命周期管理的复杂度。

3.2 Anthropic 与 IChatClient：拥抱原生抽象

Anthropic SDK 在架构上选择了一条更贴近.NET 新兴标准的道路，特别是对 Microsoft.Extensions.AI 的拥抱。

  • 原生实现抽象接口：Anthropic SDK 的 AnthropicClient 及其子属性原生实现了 IChatClient 接口。这是微软近期推出的统一 AI 交互标准。这意味着，任何设计为接受 IChatClient 的上层应用（如语义内核 Semantic Kernel 或自定义的 RAG 框架），都可以直接注入 Anthropic 客户端，而无需编写任何适配代码。
  • OpenAI 的适配器悖论：具有讽刺意味的是，作为微软“亲儿子”的 OpenAI SDK，目前并未原生实现 IChatClient。开发者如果想在 Microsoft.Extensions.AI 体系下使用 OpenAI，必须引入一个额外的 NuGet 包 Microsoft.Extensions.AI.OpenAI，并通过 .AsChatClient() 扩展方法将原生的 ChatClient 包装一层适配器。这种架构上的“迂回”，使得 OpenAI SDK 在使用微软自己的最新抽象层时，显得比 Anthropic 还要繁琐。
  • 集中式客户端结构：Anthropic SDK 采用了一个集中式的入口点 AnthropicClient，通过属性访问不同领域的 API（如 .Messages）。这种风格更接近于早期的 OpenAI-API-dotnet 社区库，对于习惯了“一个 Client 走天下”的开发者来说，认知负担更小。

4. 依赖注入与配置模式

在现代 ASP.NET Core 微服务架构中，SDK 如何注册到依赖注入（DI）容器，直接影响到应用程序的性能（连接池管理）和可测试性。

4.1 OpenAI SDK 的配置模式

OpenAI SDK 的客户端被设计为线程安全（Thread-Safe），官方强烈建议将其注册为单例（Singleton）。

标准注册模式：

// 注册标准 OpenAI 客户端
builder.Services.AddSingleton<ChatClient>(sp =>
new ChatClient(model: "gpt-4o", apiKey: Environment.GetEnvironmentVariable("OPENAI_API_KEY")));

// 注册 Azure OpenAI 客户端
builder.Services.AddSingleton<ChatClient>(sp => {
var endpoint = new Uri(Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT"));
var credential = new AzureKeyCredential(Environment.GetEnvironmentVariable("AZURE_OPENAI_KEY"));
// 注意：AzureOpenAIClient 在此仅作为工厂使用
return new AzureOpenAIClient(endpoint, credential).GetChatClient("deployment-name");
});

此处可以明显看到 Azure SDK 的设计痕迹。AzureOpenAIClient 实际上充当了一个工厂类，用于根据部署名称（Deployment Name）生产具体的 ChatClient。这种模式虽然灵活，但初学者容易混淆“资源客户端”与“功能客户端”的区别4。

与 Microsoft.Extensions.AI 的集成：
如前所述，为了利用统一抽象，必须进行额外的封装：

builder.Services.AddChatClient(sp =>
new ChatClient("gpt-4o", apiKey).AsChatClient());

这个 .AsChatClient() 适配器不仅转换了接口，还在内部处理了数据模型的映射，将 OpenAI 特有的 ChatCompletion 转换为通用的 ChatResponse10。

4.2 Anthropic SDK 的配置模式

Anthropic SDK 同样支持单例模式，但它在 HTTP 客户端的配置上展现了更高的透明度，允许开发者直接利用.NET 的 IHttpClientFactory 机制。

构造函数注入 HttpClient：
Anthropic SDK 的构造函数明确接受一个可选的 HttpClient 实例。这使得开发者可以利用 Polly 策略轻松配置超时、重试或断路器，而无需深入 SDK 内部。

// 1. 配置命名的 HttpClient，绑定 Polly 策略
builder.Services.AddHttpClient<AnthropicClient>(client => {
client.BaseAddress = new Uri("https://api.anthropic.com");
client.Timeout = TimeSpan.FromSeconds(120);
})
.AddTransientHttpErrorPolicy(builder =>
builder.WaitAndRetryAsync(3, retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt))));

// 2. 注册 SDK，它会自动使用上述配置好的 HttpClient
builder.Services.AddSingleton<AnthropicClient>();

// 3. 如果需要 IChatClient 抽象
builder.Services.AddSingleton<IChatClient>(sp =>
sp.GetRequiredService<AnthropicClient>().Messages);

这种设计（Constructor Injection of HttpClient）是.NET 推荐的最佳实践，相比之下，OpenAI SDK 虽然也支持通过 OpenAIClientOptions.Transport 自定义传输层，但其实现方式较为晦涩，不如 Anthropic 这种直接暴露 HttpClient 的方式来得直观7。

5. API 表面与功能深度对比

SDK 的核心价值在于释放模型的能力。在此部分，我们将对比两者在文本生成、流式传输、工具调用及多模态支持上的实现细节。

5.1 聊天补全（Chat Completions）与消息（Messages）

  • OpenAI SDK：
    核心方法是 CompleteChat 和 CompleteChatAsync。SDK 将对话历史建模为 List<ChatMessage>，并利用强类型的子类（UserChatMessage, SystemChatMessage, AssistantChatMessage）来区分角色。这种强类型设计不仅提供了 IntelliSense 支持，还在编译期就在一定程度上规避了角色错乱的问题（例如：System Message 通常只能放在首位）。BinaryData 类型被广泛用于处理非文本内容，这虽然灵活，但也增加了一定的使用门槛2。
  • Anthropic SDK：
    核心入口是 .Messages 属性，提供 Create 和 CreateStreaming 方法。Anthropic 的 API 设计有一个显著特点：系统提示词（System Prompt）不仅可以作为消息列表的一部分，更推荐作为顶层参数（Top-level Parameter）传递。在 SDK v10+ 中，这一点被强化。此外，Anthropic SDK 对消息角色的交替（User -> Assistant -> User）有着比 OpenAI 更严格的校验逻辑。如果开发者试图发送连续两条 User 消息而没有 Assistant 回复（例如在某些 Few-Shot Prompting 场景下），SDK 可能会抛出验证异常，要求开发者手动合并消息内容13。

5.2 流式传输范式（Streaming Paradigms）

在 AI 应用中，为了降低用户的感知延迟（Perceived Latency），流式传输是必不可少的功能。

  • OpenAI SDK：
    返回 CollectionResult<StreamingChatCompletionUpdate>。这是一个自定义的可枚举类型。开发者使用 await foreach 进行迭代。
    C#
    await foreach (StreamingChatCompletionUpdate update in client.CompleteChatStreamingAsync("Hello")) {
    Console.Write(update.ContentUpdate.Text);
    }

    OpenAI 的流式更新非常细粒度，最近还新增了在流式过程中推送 Token 使用量统计（Usage Stats）的功能，这对于计费和监控至关重要2。

  • Anthropic SDK：
    直接返回标准的 IAsyncEnumerable<MessageResponse>。这使得它能与 C# 的 LINQ to Async 扩展库（System.Linq.Async）无缝配合。
    C#
    await foreach (var chunk in client.Messages.CreateStreaming(parameters)) {
    if (chunk.Delta!= null) Console.Write(chunk.Delta.Text);
    }

    Anthropic 的流式处理在处理“内容块”（Content Blocks）时表现得更为透明。当模型在同一个流中混合输出文本和工具调用指令时，SDK 能够清晰地分离不同类型的 Delta 事件，但在处理复杂的并发流时，开发者可能需要手动聚合碎片数据5。

5.3 工具调用（Function Calling）与代理基础

这是构建智能体（Agents）的核心能力。

  • OpenAI SDK：
    支持 ChatTool 定义。ChatCompletion 响应对象包含 ToolCalls 属性。
    手动循环：默认情况下，SDK 不会自动执行工具。开发者必须编写循环：检查 ToolCalls -> 解析参数 -> 执行本地代码 -> 创建 ToolChatMessage -> 再次调用 API。
    自动化扩展：然而，如果使用了 Microsoft.Extensions.AI.OpenAI 适配器，开发者可以使用 .UseFunctionInvocation() 扩展方法。这个方法极其强大，它在内部实现了一个自动化的执行循环，能够自动反射调用.NET 本地函数并回传结果，极大地简化了代码量。这是原生 SDK 与适配器版本之间的一个巨大功能鸿沟15。
  • Anthropic SDK：
    原生支持工具调用。其结构将工具视为一种特殊的内容块。
    MCP 集成：Anthropic SDK 的杀手锏在于对 模型上下文协议（MCP） 的深度支持。与 OpenAI 倾向于将工具定义硬编码在客户端不同，Anthropic SDK 旨在连接到远程或本地的“MCP 服务器”。这些服务器动态地宣示其拥有的工具（例如：“读取文件”、“查询数据库”）。SDK 充当了模型与这些 MCP 服务器之间的通用连接器。这意味着开发者可以编写通用的代码来处理任何 MCP 兼容的工具，而无需为每个工具编写特定的 C# 胶水代码16。

5.4 多模态支持（Multimodality）

  • OpenAI SDK：
    是一个“全能选手”。除了文本，它还包含：
    • ImageClient：封装了 DALL-E 3，支持文本生成图像。
    • AudioClient：封装了 Whisper（语音转文本）和 TTS（文本转语音）。
      这使得 OpenAI SDK 成为构建多模态应用的一站式解决方案。
  • Anthropic SDK：
    目前主要聚焦于文本和视觉理解（Vision）。虽然 Claude 3.5 Sonnet 具有极强的图片理解能力，但它本身不具备图片生成（Image Generation）或语音生成（Audio Generation）的能力。因此，SDK 中不存在 ImageClient 或 AudioClient。视觉功能是通过在 Message 的内容块中传递 Base64 编码的图像数据或 URL 来实现的7。

6. 弹性工程与可靠性设计

在构建企业级应用时，SDK 如何处理网络抖动、限流和故障恢复，比其正常路径的功能更为关键。

6.1 重试逻辑与“Retry-After”争议

  • OpenAI SDK (System.ClientModel)：
    内置了 ClientRetryPolicy，默认采用指数退避算法（Exponential Backoff），初始延迟 0.8秒，最多重试 3 次。
    架构隐患：该 SDK 存在一个备受争议的设计决策——严格遵守服务端的 Retry-After 响应头。如果 Azure OpenAI 服务端因为故障返回了一个长达数小时甚至数天的 Retry-After 值（这在偶发的服务 Bug 中确有发生），SDK 的重试逻辑会无条件地挂起线程等待这段时间，导致调用端看似“死锁”。虽然可以通过传递 CancellationToken 来强制取消，但在默认配置下，这种行为对高并发系统极具破坏性。要修改这一行为，开发者必须继承并重写底层的 ClientRetryPolicy，这对普通开发者来说门槛极高8。

  • Anthropic SDK：
    默认重试 2 次。
    配置透明度：Anthropic SDK 在重试配置上显得更加务实和开放。它直接在客户端对象上暴露了 MaxRetries 属性，并且允许通过 .WithOptions() 方法针对单个请求覆盖重试设置。
    C#
    // 针对本次调用禁用重试，快速失败
    await client.WithOptions(o => o.MaxRetries = 0).Messages.CreateAsync(...);

    这种设计允许开发者根据业务场景灵活调整。例如，在用户实时交互的场景下，快速失败往往比长时间重试体验更好；而在后台批处理场景下，则可以增加重试次数5。

6.2 异常处理体系

  • OpenAI SDK：
    主要抛出 ClientResultException。这是一个通用的异常类，包含 HTTP 状态码和原始响应内容。要区分“余额不足”、“内容审查拦截”还是“服务器过载”，开发者往往需要解析异常消息中的字符串，这是一种脆弱的编程方式。
  • Anthropic SDK：
    提供了一套完整的强类型异常层次结构：
    • AnthropicRateLimitException
    • AnthropicBadRequestException
    • AnthropicUnauthorizedException
      这种设计使得 try/catch 代码块非常清晰，开发者可以针对特定的错误类型编写精确的恢复逻辑（例如：捕获 AnthropicRateLimitException 并触发熔断器）5。

7. 智能体（Agent）的未来：Assistants API vs. MCP

两个 SDK 在支持构建自主智能体（Autonomous Agents）方面，展现了截然不同的战略方向。

7.1 OpenAI Assistants API：服务端状态管理

OpenAI SDK 完整封装了 Assistants API（包括 Threads, Runs, Vector Stores）。这是一个服务端（Server-Side） 的智能体模型。

  • 机制：对话的历史状态、上下文窗口的管理、RAG 文档的检索以及代码解释器的运行，全部由 OpenAI 的服务器托管。SDK 仅仅是一个遥控器，用于发送“创建线程”、“添加消息”、“运行”等指令。
  • 优势：极大地减轻了客户端的状态管理负担；能够处理超过客户端内存限制的超长上下文。
  • 劣势：厂商锁定（Vendor Lock-in） 严重。一旦使用了 Assistants API，迁移到其他模型几乎需要重写所有逻辑。此外，将所有对话数据和文档上传到 OpenAI 服务器，对某些行业存在数据隐私合规风险2。

7.2 Anthropic 与模型上下文协议 (MCP)：客户端/协议驱动

Anthropic SDK，特别是结合 ModelContextProtocol 库，推动的是一种客户端（Client-Side） 或 协议驱动 的智能体模型。

  • 机制：SDK 不维护服务端的 Thread 状态。相反，它鼓励应用连接到本地或远程的 MCP Server。例如，一个运行在本地的“文件系统 MCP 服务器”或“PostgreSQL MCP 服务器”。Anthropic SDK 负责协调 Claude 模型与这些 MCP 服务器之间的交互。模型决定调用哪个工具，SDK 将请求转发给 MCP 服务器执行，并将结果回传。
  • 战略意义：这种架构将编排逻辑（Orchestration Logic） 保留在.NET 应用程序内部，而将模型视为无状态的推理引擎。这对于希望构建“私有化 RAG”或“本地数据代理”的企业极具吸引力，因为它避免了将敏感文档库整体上传到云端向量数据库的必要性16。

8. 总结

OpenAI SDK (openai/openai-dotnet) 是平台化思维的极致体现。它不仅仅是一个 API 客户端，更是 Azure 云服务生态的一块拼图。它适合：

  • 深度绑定 Azure 基础设施的企业。
  • 依赖 Assistants API 进行服务端状态管理的应用。
  • 需要多模态（画图、语音）一体化能力的场景。

Anthropic SDK (anthropics/anthropic-sdk-csharp) 是协议化思维的代表。它更轻量、更透明，并且通过 MCP 协议引领着代理开发的新方向。它适合：

  • 追求架构灵活性，希望采用 Microsoft.Extensions.AI 标准的应用。
  • 构建基于 MCP 的本地化或私有数据智能体。
  • 需要利用 Claude 3.5 Sonnet 卓越的代码与逻辑推理能力，且希望对 HTTP 行为有精细控制的开发者。

在未来的.NET AI 架构中，最明智的做法可能不是“二选一”，而是通过 Microsoft.Extensions.AI 的 IChatClient 接口，将具体的 SDK 实现隔离开来。这使得上层业务逻辑可以保持中立，而在底层根据任务需求（例如：用 Claude 写代码，用 GPT-4o 生成报表）动态切换不同的 SDK 实现。

附录：核心特性对比矩阵

特性维度 OpenAI.NET SDK (openai/openai-dotnet) Anthropic C# SDK (anthropics/anthropic-sdk-csharp)
官方状态 官方 (Microsoft & OpenAI 联合开发) 官方 (Beta, 前身为社区项目)
核心架构 System.ClientModel (Azure SDK 风格) 标准 HttpClient / IChatClient 原生实现
统一抽象支持 需适配器 (Microsoft.Extensions.AI.OpenAI) 原生支持 (Microsoft.Extensions.AI)
身份验证 API Key, Azure Entra ID (托管标识) API Key
流式处理 CollectionResult<StreamingUpdate> IAsyncEnumerable<Message>
智能体模式 Assistants API (服务端托管状态) Model Context Protocol (客户端/协议驱动)
重试策略 内置指数退避，严格遵守 Retry-After 可配置 MaxRetries，支持单次请求覆盖
异常类型 ClientResultException (通用封装) 强类型异常体系 (AnthropicRateLimitException 等)
多模态能力 文本, 视觉, 语音 (Whisper/TTS), 绘图 (DALL-E) 文本, 视觉 (Vision)
依赖注入 推荐单例，配置较为封闭 推荐单例，支持 IHttpClientFactory 深度配置

引用的链接

  1. Announcing the official OpenAI library for .NET - Microsoft Dev Blogs, https://devblogs.microsoft.com/dotnet/openai-dotnet-library/
  2. openai/openai-dotnet: The official .NET library for the OpenAI API https://github.com/openai/openai-dotnet
  3. OpenAI Releases Official .NET Library https://www.infoq.com/news/2024/06/openai-microsoft-dotnet/
  4. Azure OpenAI client library for .NET - Azure for .NET Developers https://learn.microsoft.com/en-us/dotnet/api/overview/azure/ai.openai-readme?view=azure-dotnet
  5. anthropics/anthropic-sdk-csharp: Access to Anthropic's safety-first language model APIs in https://github.com/anthropics/anthropic-sdk-csharp
  6. Client SDKs - Claude Docs, https://platform.claude.com/docs/en/api/client-sdks
  7. tghamm/Anthropic.SDK: An unofficial C#/.NET SDK for accessing the Anthropic Claude API. This package is not affiliated with, endorsed by, or sponsored by Anthropic. Anthropic and Claude are trademarks of Anthropic, PBC https://github.com/tghamm/Anthropic.SDK
  8. [QUESTION] No delay for first retry · Issue #857 · openai/openai-dotnet - GitHub, https://github.com/openai/openai-dotnet/issues/857
  9. Best way to check for breaches of rate limit using the Assistants API? #66 - https://github.com/openai/openai-dotnet/issues/66
  10. Introducing Microsoft.Extensions.AI Preview - Unified AI Building Blocks for .NET https://devblogs.microsoft.com/dotnet/introducing-microsoft-extensions-ai-preview/
  11. Microsoft.Extensions.AI.OpenAI 10.1.1-preview.1.25612.2 https://www.nuget.org/packages/Microsoft.Extensions.AI.OpenAI
  12. How to stream Claude response with SignalR and Claudia in .Net 6 https://stackoverflow.com/questions/78485372/how-to-stream-claude-response-with-signalr-and-claudia-in-net-6
  13. Quickstart - Extend OpenAI using Tools and execute a local Function with .NET https://learn.microsoft.com/en-us/dotnet/ai/quickstarts/use-function-calling
  14. Microsoft partners with Anthropic to create official C# SDK for Model Context Protocol, https://developer.microsoft.com/blog/microsoft-partners-with-anthropic-to-create-official-c-sdk-for-model-context-protocol
  15. What's new in Azure OpenAI in Azure AI Foundry Models? - https://learn.microsoft.com/en-us/azure/ai-foundry/openai/whats-new?view=foundry-classic
  16. [ClientModel] RetryPolicy does not sanity check `Retry-After` value · Issue #50949 https://github.com/Azure/azure-sdk-for-net/issues/50949
  17. The "Rate limit exceeded" error causes an excessively long retry delay. #404 - https://github.com/openai/openai-dotnet/issues/404
  18. Anthropic 12.0.1 - NuGet, https://www.nuget.org/packages/Anthropic/
posted @ 2026-01-14 06:57  张善友  阅读(0)  评论(0)    收藏  举报