微软AI库Microsoft.Extensions.AI的发展历史和背景介绍

---

一、一句话定义

Microsoft.Extensions.AI 是一个"AI 能力抽象层（Abstraction Layer）"，
目标是把大模型（LLM / Embedding / Image / Audio 等）统一为 .NET 标准接口，并深度融入 Microsoft.Extensions.* 生态。

它不是：

• ❌ 一个具体的大模型
• ❌ 一个 AI 框架（不像 SK 那样有 Planner / Memory / Skills）
• ❌ 一个 UI 或 Agent 框架

它是：

• ✅ .NET 官方的 AI 接口规范 + 适配层
• ✅ 像 ILogger、IConfiguration 一样的"基础设施"

库地址：

NuGet Gallery | Microsoft.Extensions.AI.OpenAI 10.2.0-preview.1.26063.2

![[3_1Microsoft.Extensions.AI.png]]

---

二、它出现的历史背景（为什么 Microsoft 要做它）

1️⃣ 背景 1：.NET 世界"AI SDK 碎片化"

在 2023--2024 年之前，.NET 使用 AI 大致是这样：

场景	做法
OpenAI	各种非官方 SDK
Azure OpenAI	Azure.AI.OpenAI
HuggingFace	HTTP 手写
本地模型	Ollama / LM Studio 自定义
Embedding	每家一套 API
重试 / 日志	自己封装

👉 完全没有统一抽象

👉 无法像 HttpClientFactory 一样切换 Provider

👉 无法自然接入 DI / Logging / Metrics

---

2️⃣ 背景 2：Semantic Kernel 的"重"和"侵入性"

Semantic Kernel（SK）在早期承担了 太多职责：

• Prompt 管理
• Function Calling
• Planner
• Memory
• Connector
• Agent

问题是：

• 对很多企业项目来说过重
• 很难只"用一下 LLM"
• 不适合底层基础库 / SDK

👉 Microsoft 需要一个 比 SK 更底层、更像 Microsoft.Extensions.* 的东西

---

3️⃣ 背景 3：Microsoft 内部统一 AI 基础设施的需要

微软内部（Azure / Office / GitHub / Copilot）已经形成共识：

AI 就像 Logging、Caching、Config 一样，是"基础设施能力"，不是应用逻辑

所以他们要的是：

• 统一接口
• 可插拔 Provider
• DI 原生支持
• 可观测性（Logging / Metrics / Tracing）
• 与 ASP.NET / Worker / Console / Blazor 通用

👉 Microsoft.Extensions.AI 就是在这个背景下诞生的

---

三、发展历史（时间线）

📅 2023 Q4 -- 2024 Q1

• Microsoft 内部开始讨论 "AI Abstractions for .NET"
• Semantic Kernel 团队拆分职责
• IChatCompletionService 等接口被认为不够通用

---

📅 2024 Q2

• Microsoft.Extensions.AI.Abstractions 内部原型

• 对齐 Microsoft.Extensions.Logging 的设计哲学

• 明确：

  • 不做 Prompt 工程
  • 不做 Agent
  • 不做 Memory

---

📅 2024 Q3

• 开源仓库公开（GitHub）

• 发布早期 Preview

• 引入核心接口：

  • IChatClient
  • IEmbeddingGenerator
  • IImageGenerator

---

📅 2024 Q4 -- 2025

• 开始提供官方 Provider：

  • OpenAI
  • Azure OpenAI

• 明确定位：

  "AI = 一个可注入的服务能力"

• Semantic Kernel 开始基于它构建，而不是反过来

---

四、设计哲学（非常关键）

1️⃣ 完全遵循 Microsoft.Extensions.* 体系

你可以把它类比为：

领域	对应
日志	ILogger<T>
配置	IConfiguration
HTTP	HttpClientFactory
AI	IChatClient / IEmbeddingGenerator

核心思想：

应用代码只依赖接口，不依赖模型、不依赖厂商

---

2️⃣ "能力抽象"，不是"模型抽象"

Microsoft 刻意避免这种接口：

IGpt4Client
IClaudeClient
IQwenClient

而是：

IChatClient
IEmbeddingGenerator

👉 你关心的是 "我需要聊天能力"

👉 而不是 "我调用的是哪个模型"

---

3️⃣ 明确反对"大一统框架"

它不提供：

• Prompt 模板系统
• Memory
• Planner
• Agent
• Workflow

这些全部留给：

• Semantic Kernel
• LangChain.NET
• AutoGen.NET
• 你自己

---

五、核心组件结构（技术层面）

1️⃣ 核心包

🔹 Microsoft.Extensions.AI.Abstractions

这是最核心的包，只包含接口和基础类型。

主要接口：

IChatClient
IEmbeddingGenerator
IImageGenerator
IAudioTranscriber（后续）

示例：IChatClient（简化）

public interface IChatClient
{
    Task<ChatResponse> CompleteAsync(
        ChatRequest request,
        CancellationToken cancellationToken = default);
}

---

2️⃣ 模型无关的数据结构

ChatMessage

new ChatMessage(ChatRole.User, "你好")

ChatRequest / ChatResponse

• 标准化 message

• 支持：

  • Tool calls
  • Metadata
  • Usage
  • Streaming（未来）

---

3️⃣ Provider 实现包

包	作用
Microsoft.Extensions.AI.OpenAI	OpenAI 官方
Microsoft.Extensions.AI.AzureOpenAI	Azure OpenAI
（未来）Ollama / HuggingFace	规划中

---

4️⃣ DI + Builder 风格

services.AddChatClient(builder =>
{
    builder.UseOpenAI(o =>
    {
        o.ApiKey = "...";
        o.Model = "gpt-4o-mini";
    });
});

👉 你应该觉得 非常像 AddHttpClient()

---

六、一个完整使用示例（典型 .NET 风格）

public class AiService
{
    private readonly IChatClient _chat;

    public AiService(IChatClient chat)
    {
        _chat = chat;
    }

    public async Task<string> AskAsync(string question)
    {
        var response = await _chat.CompleteAsync(
            new ChatRequest(
                new[]
                {
                    new ChatMessage(ChatRole.User, question)
                }
            )
        );

        return response.Message.Content;
    }
}

👉 完全没有 OpenAI / Azure / Model 的概念泄漏

---

七、与 Semantic Kernel 的关系（你一定关心）

维度	Microsoft.Extensions.AI	Semantic Kernel
定位	基础设施	应用框架
抽象层级	很低	很高
Prompt	❌	✅
Memory	❌	✅
Planner	❌	✅
Agent	❌	✅
是否依赖对方	SK 依赖它	❌

👉 正确姿势：

你的应用
  ↓
Semantic Kernel（可选）
  ↓
Microsoft.Extensions.AI
  ↓
OpenAI / Azure / 本地模型

---

八、与 OpenAI SDK 的关系

对比	OpenAI SDK	Extensions.AI
是否厂商绑定	是	否
接口稳定性	变动快	稳定
DI 支持	一般	原生
日志 / Metrics	无	原生
企业友好	一般	很强

👉 Microsoft 的态度很明确：

企业级 .NET 项目，推荐 Microsoft.Extensions.AI

---

九、它在 .NET AI 生态中的战略位置

可以用一张分层图来理解：

┌─────────────────────────┐
│  应用层（Web / Worker） │
├─────────────────────────┤
│  Agent / Workflow 框架  │  ← SK / AutoGen
├─────────────────────────┤
│  AI 抽象层              │  ← Microsoft.Extensions.AI
├─────────────────────────┤
│  模型 / Provider        │  ← OpenAI / Azure / Ollama
└─────────────────────────┘

---

十、未来发展方向（判断）

结合 Microsoft 最近一年动作，非常明确：

1. 它会成为 .NET AI 的"ILogger"

2. Semantic Kernel 会越来越"可选"

3. 所有 Microsoft 自家 AI SDK 会向它靠拢

4. 未来会补充：

   • Streaming
   • Tool Calling 统一模型
   • Metrics / OpenTelemetry 深度集成
   • Local LLM Provider（高度可能）

---

十一、总结评价

Microsoft.Extensions.AI 是一个"迟到但非常正确"的设计：
不炫技、不抢风头，只做一件事------
把 AI 变成 .NET 的基础能力。