一文讲清 .NET AI 核心技术选型： OpenAI/Anthropic SDK、MEAI、Copilot SDK 还有 Agent Framework
咱们先承认一个现实：你搜“Agent in .NET 10”，会同时看到 Copilot SDK、Microsoft Agent Framework、OpenAI/Anthropic SDK、Microsoft.Extensions.AI——名字都像“能让我接大模型”。
但你一动手就会发现：有的像 HTTP 客户端、有的像 DI 生态里的抽象、有的像工作流编排框架，还有的干脆像“把 Copilot CLI 那套东西塞进你的应用”。
所以这篇文章我们不绕弯子，直接给结论：它们不是互斥替代关系，而是分属不同层。你选错层，就会把“平台能力”当“SDK”，或者把“抽象层”当“编排框架”。带着这个问题思考，我们就会更接近真相。
0. 先画分层图：四样东西各在哪一层、谁依赖谁
先把话说清楚：这四类东西更适合按“从下到上”的依赖方向来读——上层通常建立在下层之上。L1（抽象/管线）可以适配多个 L0（provider）；L2（编排框架）消费模型能力并补上运行保障；而 Copilot SDK（L3）之所以放在最上层，是因为它更像“带着既定执行循环的运行时平台”，不是单纯给你一个可自由拼装的编排库。它和 L2 确实会在“多轮对话、工具调用”上出现能力重叠，但关注点不同：L2 更偏“你来定义流程/治理与韧性”，L3 更偏“我把 Copilot CLI 那套生产验证过的 loop（外加认证、模型管理、MCP 等）直接交付给你来跑”。
我们先画一张最粗的分层图：
到这里你可能会问：那我到底该停在哪一层？用三个设问把预期对齐：
“我只是想调用模型生成文本/结构化输出。”
优先停在 L0/L1：L0 负责把请求发出去；L1 负责把调用方式变成 .NET 里可注入、可组合、可治理。 “我需要多步流程、并发/交接/人类介入、可恢复运行。”
往上走到 L2：你要的已经不是一次 chat，而是一个可编排、可观测、可运营的 agent/workflow 系统。 “我想直接复用 Copilot CLI 那套 agentic loop，并且用 Copilot 的认证/模型管理/MCP。”
才看 L3：这时你要的不是“一个 SDK”，而是“一个带默认执行循环的运行时平台”。
总的来说：L0 是“怎么请求模型”，L1 是“.NET 里怎么治理调用”，L2 是“怎么把多步/多 Agent 跑成可运营系统”，L3 是“把成熟的执行循环直接嵌进来（因此和 L2 会有局部重叠）”。
1. 回归本质：你到底在解决哪类“麻烦”？（把概念翻译成工程问题）
“Agent Framework/SDK”这俩词很飘。咱们不背名词，直接把它们翻译成工程麻烦——你遇到的到底是哪一类？
痛点 A：换模型/换云/换兼容端点要改一堆调用代码
问题：今天用 OpenAI，明天要上 Azure OpenAI，后天又来一个 OpenAI-compatible endpoint；如果业务层到处都是 new XClient(...) 和请求 DTO，你就会被“改一处炸一片”支配。
答案/原因：这不是“再写一个封装类”能彻底解决的，关键在于把业务依赖收敛到一个稳定抽象。
结论：这是 L1（Microsoft.Extensions.AI） 的典型价值——IChatClient 这类接口让调用方不必绑定某个 provider。
痛点 B：工具调用、缓存、遥测、重试/限流等横切关注点散落在业务里
问题：你很快会想要 tool calling（函数调用/工具调用）、统一日志与 tracing、缓存相同 prompt 的响应……如果每个 endpoint/handler 都手写一遍，维护成本会指数级上升。
答案/原因：在 .NET 世界里，这类问题最自然的解法是：DI + pipeline/middleware。
结论：这还是 L1 的地盘——ChatClientBuilder 让你用类似中间件的方式把 UseFunctionInvocation()、UseDistributedCache(...)、UseOpenTelemetry(...) 这类能力“叠上去”。
痛点 C：单次 chat 不够，要“计划→多工具→多 Agent 协作→可恢复运行→可观测”
问题：当你的需求变成：一个请求要跨多个步骤（甚至跨多个服务/队列），需要并发/交接/群组协作，还要支持失败恢复、checkpoint、human-in-the-loop……这已经不是“在一个 controller 里 while-loop 调模型”能兜住的。
答案/原因：这类系统的复杂度在“编排与运行保障”，而不是“模型调用怎么写”。
结论：上到 L2（Microsoft Agent Framework）：它明确面向 production-grade 的 agents 和 multi-agent workflows，并把 orchestration/workflows、durability/restartability、observability 等作为核心能力。
痛点 D：你不想自建 planner/tool loop/runtime，希望直接“拿来一套成熟执行循环”
问题：你可能会纳闷：我都上框架了，为什么还要 Copilot SDK？
答案/原因：因为 Copilot SDK 卖的不是“通用 LLM 客户端”，而是复用 Copilot CLI 的 agentic core：planning + tool use + multi-turn execution loop，外加 GitHub authentication、模型管理、MCP 集成、实时流式等生态能力。
结论：这是 L3（execution platform） 的定位。
类比一句（用你熟悉的工程语言）：
事件总线这个概念对你来说可能很陌生；但你一说发布-订阅就懂。同理：‘Agent Framework/SDK’这俩词很飘，咱们把它们还原成‘谁负责调用、谁负责管线、谁负责编排、谁负责执行循环’就清楚了。
2. Demo 第一步：只用 OpenAI/Anthropic SDK 跑通“最小可用聊天”——然后我们会立刻撞墙
下面我们按“从能跑到能用”的顺序走一遍 Demo。先从最朴素的方式开始：直接用 provider SDK（L0）跑通一次聊天。
这里用 OpenAI 举例；Anthropic 在结构上也是同一类：都是“通用模型服务 SDK”，负责把请求发到模型服务。
2.1 最小可用（L0）伪代码
跑通之后，你会很快撞上三堵墙——而且都是 ASP.NET Core/DI 语境下的“老熟人”：
“我想把 client 注入到 ASP.NET Core。”
生命周期怎么管？配置怎么注入？密钥怎么加载/轮换？ “我想统一做日志/遥测/缓存/工具调用。”
难道每个 endpoint 都 copy 一段‘记录耗时 + trace + tool dispatch’？ “我想以后换 Azure OpenAI / OpenAI compatible endpoint。”
业务层能不能别知道 provider 的请求对象长什么样？
至此结论很明确：L0 解决的是“跟模型服务对话”，但解决不了“在 .NET 应用里可组合、可治理地对话”。
下面我们就来做第一步重构：把“模型调用”抬升成 .NET 里可注入的抽象（L1）。
3. Demo 第二步：接入 Microsoft.Extensions.AI——把“模型调用”变成可注入、可插拔的 .NET 管线
现在我们来解决刚才那三堵墙。思考一下：在 .NET 里，解决“可替换 + 可治理 + 可测试”的惯用套路是什么？通常就是两件事：
抽象
：业务依赖接口（而不是具体 client）。 管线
：横切能力用 middleware/pipeline 叠加（而不是散落在业务代码）。
Microsoft.Extensions.AI（L1）干的就是这件事。
3.1 适配：把 provider client 落到 IChatClient
你可能会问：“那我是不是不用 OpenAI SDK 了？”——不是。
更准确的说法是：OpenAI（L0）提供具体实现；Microsoft.Extensions.AI（L1）把它适配成统一接口 IChatClient，并提供可组合的管线能力。
代码骨架（来自官方 README 语义）：
这一步的收益很直接：你的业务层只要面向 IChatClient，以后换 provider 或换 endpoint，不再是“全项目改类型”。
3.2 管线：把 tool invocation / caching / telemetry 变成中间件
接下来是关键：把横切关注点从业务代码里抽走。
如果你在 ASP.NET Core 里，更“正宗”的姿势是交给 DI：
你看，这就很 .NET：
endpoint 只依赖 IChatClient；缓存/日志/遥测/工具调用由管线统一治理； 以后换 provider，大概率只是换 DI 注册那一行。
说了这么多，无非是想透过现象看本质——Microsoft.Extensions.AI 解决的是 .NET 应用内的抽象与治理，而不是帮你“变成 Agent”。
当你下一步确实需要“多步、多 Agent、可恢复、可观测”的编排时，我们才上 L2。
4. Demo 第三步：当“多轮+多工具+多 Agent+可恢复/可观测”成为刚需——上 MAF 做编排
到这里，我们已经把“模型调用”在 .NET 里治理好了。但你可能会继续遇到下一类问题：
单次 chat 不够用了。一个请求要跑好几步；要并发；要交接；要失败可恢复；要能观测、能治理。
这时候再硬塞进 controller/service 里，就会变成“业务代码里长出一个小平台”。所以我们需要一个问题门槛：满足下面任意一条，就该认真考虑 L2。
4.1 升级条件清单（满足其一就考虑 L2）
一个请求要跨多个步骤/多个工具/多个角色协作 需要顺序/并发/交接/群组协作等图式编排 需要 checkpointing、restartability、human-in-the-loop、time-travel（先点名，不展开） 需要生产化运维：observability、治理、provider flexibility
这些词听起来抽象，但你把它翻译成工程动作就很好理解：要把“流程”当一等公民来管理。
4.2 工作流伪代码：关注结构，不纠结 API
（这里我们不强行写死某个具体 API，以免误导；重点是你要的系统结构。）
MAF 的价值不在于“再包一层模型调用”，而在于它把很多你最终都会补的能力前置到框架层：
orchestration / workflows（图式编排：sequential、concurrent、handoff、group collaboration） durability、restartability（以及 checkpointing） observability（内建 OpenTelemetry 集成） provider flexibility（架构不被某个模型/云绑死）
4.3 它与 L1 的关系：不是替代，而是分工
你可能会再问一句：“那我上了 MAF，是不是就不需要 Microsoft.Extensions.AI 了？”
多数情况下：不是替代关系，而是分工。
L1 负责“在 .NET 里怎么调用与治理模型能力”（统一接口 + 中间件）。 L2 负责“把多步、多 Agent、可运营的流程跑起来”（编排 + 运行保障）。
至此我们已经有了一个相对完整的工程路径：先把调用抽象好，再把流程编排好。那最后的 Copilot SDK（L3）到底怎么理解？下面我们做一次反直觉澄清。
5. 最后一层：Copilot SDK 为啥不是“通用 LLM SDK”？——它卖的是 execution loop（以及什么时候你才需要它）
最后我们把最容易误会的一点讲清：你看到“SDK”第一反应可能是‘用它来调用模型’，但 Copilot SDK 的核心卖点其实是 execution loop。
GitHub 的表述很直接：Copilot SDK 让你把“Copilot CLI 的 agentic core”嵌进任何应用——也就是那套 planning、tool use、multi-turn execution loop；并且提供“programmatic access to the same production-tested execution loop that powers GitHub Copilot CLI”。换句话说，它交付的不是一个 provider client，而是一套已经跑通的“代理执行内核”。
那它和常见的 Agent Framework 怎么区分？可以先用一句话抓住定位：**Copilot SDK 更偏“把现成的 Copilot 执行循环嵌进来用”（execution runtime），而 Agent Framework 更偏“在你的平台里搭建/编排可治理的 agent 与 workflow”（orchestration framework）。**前者强在复用 Copilot CLI 的执行能力与生态能力；后者强在把流程、状态、可观测与治理放进你自己的生产体系里。你选哪个，取决于你是想“直接接入一套跑过的 loop”，还是想“自己掌控一套可演进的编排层”。
所以它更像什么？更像一个“可嵌入的运行时平台”，而不是一个通用模型服务 SDK。
5.1 什么时候你才需要它（适用场景）
你要的是“让系统替我 plan 并执行”，而不是自己写 planner/loop/runtime 你希望直接利用 Copilot 生态能力：GitHub authentication、模型管理、MCP server integration、实时流式 你做的是开发者工具/内部自动化/需要强工具链能力的 agent
5.2 什么时候别急着上（不适用场景）
只是把 LLM 当 API：优先 L0/L1 已经在自家平台有完善的工作流/可观测/治理体系：优先 L2（或 L1 + 自研编排）
Copilot SDK 更像“执行平台/运行时”，不是“通用模型服务 SDK”。
6.最后
最后我们把选型落地成“决策树一句话版”，你可以直接贴到团队 wiki：
我只要调用模型（聊天/结构化输出/embedding）
→ 先用 L0（OpenAI/Anthropic 等 provider SDK）；在 .NET 应用里通常会很快补上 L1。 我想要 .NET 抽象 + DI + 中间件治理（工具调用/缓存/遥测）
→ 用 L1（Microsoft.Extensions.AI），让业务统一依赖 IChatClient。我需要生产级编排与多 Agent 工作流（多步、并发、交接、可恢复、可观测）
→ 上 L2（Microsoft Agent Framework）。 我想直接复用 Copilot CLI 的执行循环与生态能力（auth/MCP/model management）
→ 才考虑 L3（GitHub Copilot SDK）。
行动路径建议也很务实：先把业务依赖收敛到 IChatClient（把可替换性做出来），再决定要不要上 MAF 做编排；Copilot SDK 留给“确实需要 execution loop 平台化”的场景再引入。
