上周帮一个朋友看他的C# AI项目，他在周末用一天时间把一个大模型Demo跑通了：控制台里敲一句话，回车，模型乖乖吐出结构化JSON，他兴奋地给我看效果。但我翻了翻代码，问他三个问题——并发50时会不会把限流打穿？模型偶发吐出不合法JSON你能怎么兜底？如果这个月账单翻了三倍你能从日志里找到原因吗？他沉默了。
C#做AI在这两年确实是黄金窗口：官方把统一的AI集成层补进了基础库，社区的编排框架越来越成熟，本地推理运行时的选择也多了，C#开发者第一次不用跨界写Python就能端到端完成AI功能。但Demo跑通与生产稳定之间，隔着大量工程功课。这篇文章就把我团队从原型到上线过程中踩过的坑、做过的取舍、最后沉淀下来的方法一次性讲清楚，给正在用C#接大模型的你做个参考。
1. C#这个生态为什么突然适合搞AI了
1.1 三块拼图同时到位
其实C#做AI不是今天才开始。早年间有传统的机器学习框架，能做推荐、预测这类事儿，但到了大语言模型时代，主流工具链几乎全在Python那边，C#开发者多少有点"局外感"。转机出现在最近两年，准确说是三件事同时发生。
第一，.NET官方把AI抽象层直接做进了基础库。原来你要自己去拼HTTP请求、处理流式响应、维护不同的供应商协议，现在官方提供了一套统一的聊天补全、向量化、工具调用接口。你写业务代码时不再关心后面接的是哪家的模型，换供应商往往只是改配置。对一家以C#为主力语言的公司来说，这是决定性的。
第二，社区里的编排框架成熟了。所谓编排，就是让AI不只是"一问一答"，而是能调用你的业务函数、按步骤完成多阶段任务。之前这些能力基本是Python生态专属，现在C#这边也有了几套被广泛使用的方案。我做过的几个Agent类项目，稳定性和可调试性已经不比Python差。
第三，本地推理的选项越来越多。有些场景数据不能出内网，或者延迟敏感，需要在本机跑小模型。C#在这块的绑定能力比一般人想象的要顺，嵌入模型和分类模型跑起来非常快。
1.2 Demo满足的是好奇心，生产满足的是SLA
Demo和生产不是量变，是质变。模型的接口没变，但周围环境全变了。我用一张表来说明两者差距：
| 维度 | Demo阶段 | 生产阶段 |
|---|---|---|
| 调用频率 | 手动触发、几分钟一次 | 每秒几十上百次请求 |
| 错误容忍 | 失败重跑一次就行 | 需要自动重试、降级、熔断、告警 |
| 数据安全 | 测试数据随便写 | 涉及用户数据、权限、脱敏、审计 |
| 成本 | 几乎没人算 | 每一千Token都在烧钱 |
| 延迟预期 | 等30秒没问题 | 超过10秒用户就流失 |
这表里每一行，背后都是一整套工程措施。更麻烦的是，模型输出的"非确定性"会渗透到所有原本你认为确定的地方：解析不老老实实给你JSON、偶尔答非所问、同一个Prompt不同模型表现天差地别。所以做C# AI生产化，绝不能只把它当成一个普通HTTP服务来治理。
2. 第一道分水岭：把模型调用请进"网关"
2.1 网关模式：换供应商不慌
我在不少项目里见过这种写法：业务Service里直接new一个供应商的客户端，页面上调用一次就在业务代码里裸调一次模型接口。Demo非常痛快，到了生产就是灾难——想换一个模型供应商，得把整个代码库翻一遍；想统一加日志和成本统计，根本找不到切入点。
正确做法是先定义一个极薄的网关接口：
public interface IChatGateway { Task<ChatResult> CompleteAsync( ChatRequest request, CancellationToken ct); }业务层只依赖这个接口。网关的实现内部去对接具体的供应商，解析供应商特有响应、统一返回业务模型。这样切开之后有四个立竿见影的好处：换供应商只改一个类；重试、超时、日志、指标全部集中在一处；做A/B测试时可以直接在网关里切流量比例；写测试时可以注入桩件，不用真调模型。
但我也要提醒一句：别一上来就抽象过度。某些团队把网关做成了七八层接口、四个工厂，结果是没人能改代码。一个接口加一个实现类，顶多再针对流式输出加一个StreamAsync方法，够用就行。
2.2 密钥、模型、Prompt：三层配置分开管
生产环境的第一个低级事故，往往是把API密钥写在代码里或者签进代码仓库。
- 密钥类秘密信息：走环境变量或托管密钥服务，禁止进配置文件。
- 模型名和供应商Endpoint：属于环境配置，放配置文件并用配置中心管理，让升级模型、切换部署变成改配置而不是发版。
- Prompt模板：这也是配置，但它有自己的生命周期，需要版本管理。我把Prompt拆成了独立的资源文件，带版本号，部署时和代码一起发布，线上可以直接查当前用的是哪个版本的Prompt。
三层分开后，运维和研发心里都会踏实很多：改Prompt不用动代码，改模型不用动Prompt，改密钥不用动模型。下面是一个简化配置示意：
{ "Ai": { "Provider": "cloud", "Model": "chat-large-2", "Deployment": "prod-cn", "MaxTokens": 2048, "Temperature": 0.3 } }读取时用框架自带的配置绑定（IConfiguration + IOptions），不要把整份配置当字典传来传去。
2.3 输出校验：别相信模型的格式承诺
大模型供应商大多提供了结构化输出能力，你可以规定它返回JSON，甚至给它一个JSON Schema。但生产经验告诉我：结构化输出能大幅降低错误率，却不能消除错误。原因多种多样：输出被max_tokens截断、偶尔混入Markdown代码围栏、供应商在边缘情况下的schema违例。
所以网关内部必须做一道校验和修复：
public async Task<T?> CompleteJsonAsync<T>( ChatRequest request, int retryTimes = 2, CancellationToken ct = default) { for (var i = 0; i <= retryTimes; i++) { var raw = await _inner.CompleteAsync(request, ct); var cleaned = StripCodeFence(raw.Content); try { return JsonSerializer.Deserialize<T>(cleaned, JsonOptions); } catch (JsonException) { request.Conversation.Add(new ChatMessage( Role: "user", Content: "上一条回复不符合JSON格式。请只输出JSON，不要包含任何解释或代码围栏。")); } } return default; }这个方法我称为"JSON自救循环"。第一次解析失败，把错误信息反馈给模型，让它重新生成一次，配合限定输出结构，成功率能拉到99%以上。注意，这种重试消耗的是Token，不是免费重试，所以次数要克制，一般两到三次封顶。
3. 从"跑通"到"扛住"：连接、超时与重试的工程细节
3.1 客户端生命周期：单例是标准答案，别每次new
很多第一次接触AI的C#开发者会踩同一个坑：每个请求都new一个供应商客户端，或者干脆在Controller里new一个HttpClient。前者的代价是每请求都创建新客户端、新连接池，在高并发下socket端口快速耗尽，也就是常说的socket耗尽；后者的代价是TCP连接得不到复用，延迟和资源占用都上来了。
正确姿势是用依赖注入把客户端注册为单例：
services.AddSingleton(sp => { var client = new HttpClient { Timeout = TimeSpan.FromMinutes(2) }; return CreateChatClient(client, options); });供应商SDK里的客户端对象本身就设计成线程安全的，单例完全没问题。记住一个简单判断：如果你的代码里出现了"每个请求都new网络客户端"，那基本可以断定上线后会出连接问题。把创建逻辑收敛到启动阶段，所有请求共享同一批连接，这是生产化的第一课。
3.2 超时与取消：给"慢"画一条红线
模型推理的特点是"可快可慢"，一个复杂输出可能30秒还没吐完。生产环境不能无限等。区分三种超时：
| 超时类型 | 建议策略 | 说明 |
|---|---|---|
| 连接超时 | 5-10秒 | 建立TCP/HTTPS连接的上限 |
| 首Token超时 | 10-20秒 | 用户能接受的最长"等待开始输出"时间 |
| 整体超时 | 60-120秒 | 大输出任务的最长执行时间 |
实际编码时，除了在配置里设置客户端超时，还应该在调用点创建链路的CancellationTokenSource：
using var cts = CancellationTokenSource.CreateLinkedTokenSource(userCancellationToken); cts.CancelAfter(TimeSpan.FromSeconds(90)); var result = await _gateway.CompleteAsync(request, cts.Token);这里的关键是"响应式取消"：前端断开、用户切换页面、请求被网关熔断，都要能立刻中断模型调用。流式场景下尤其重要，客户端一旦断开，服务端还在生成内容烧钱，Token就白花了。
3.3 重试要有策略，但不能只会无脑重试
模型服务有它自己的可用性特征：偶尔5xx、偶发网络抖动、限流返回429。常见错误是"一失败就重试，重试还立刻再打一次"，结果是把限流打成雪崩。
我的重试准则：
- 只有网络异常、5xx、429值得重试。
- 400、401、403、404这类错误重试一百次也是白费，直接抛出。
- 429必须看服务端返回的Retry-After头，至少等这个时间再试。
- 重试要有退避和抖动。退避让流量分开，抖动防止多个请求在同一时刻一起重试形成脉冲。
- 每次重试都记日志，因为重试意味着Token消耗翻倍。
实现上我会在网关内部包一层带退避的循环：
private async Task<ChatResult> SendWithRetryAsync( ChatRequest request, CancellationToken ct) { var attempt = 0; while (true) { try { return await _inner.CompleteAsync(request, ct); } catch (Exception ex) when (IsRetryable(ex)) { attempt++; if (attempt > 3) throw; var delay = ComputeBackoff(attempt); Logger.LogWarning("模型调用第{Attempt}次重试，原因：{Reason}", attempt, ex.Message); await Task.Delay(delay, ct); } } } private static TimeSpan ComputeBackoff(int attempt) => TimeSpan.FromMilliseconds( Math.Min(8000, 1000 * Math.Pow(2, attempt - 1)) + Random.Shared.Next(0, 500));看到没有，真正起作用的是"退避+抖动+限次+日志"，而不是简单的while循环重试。
3.4 客户端限流：别让并发把自己打崩
模型供应商都有每分钟请求数和每分钟Token数的配额。生产环境初期最容易出现的翻车就是：线上流量一起来，瞬间触发429，然而重试又把这些429请求再打一遍。
我一般会在网关内部加一个信号量做并发闸门：
public sealed class ConcurrencyGate { private readonly SemaphoreSlim _gate = new(16); public async Task<T> ExecuteAsync<T>( Func<CancellationToken, Task<T>> action, CancellationToken ct) { await _gate.WaitAsync(ct); try { return await action(ct); } finally { _gate.Release(); } } }配合供应商返回的限流信息，动态调整闸门宽度，效果更好。核心思路是：把模型供应商当成一个"配额极其有限、单次极慢"的下游系统来治理，你的架构就不会出大问题。
3.5 流式输出：体验好，治理要求也高
如果要做聊天机器人、逐字输出这类体验，流式接口是必选项。C#的异步迭代（IAsyncEnumerable）处理流式响应非常顺手：
await foreach (var chunk in _gateway.StreamAsync(request, cts.Token)) { await client.SendAsync( "ReceiveToken", new { content = chunk.Text, requestId }, cts.Token); }但流式有几个坑：一是网络异常只会出现在枚举过程中，重试不再简单；二是Token用量需要自行累加，很多供应商的流式响应并不会每个chunk都带usage，通常要在最后一个chunk才给，不能漏记；三是如果用户中途断开，必须立刻取消枚举，否则后端还会继续生成。
4. 内存、成本与性能：三个容易看漏的黑洞
4.1 上下文膨胀是成本失控的第一元凶
这个坑几乎每个团队都会踩。聊天类应用最自然的实现是"每次请求把整个会话历史都带上"，因为大模型需要上下文。但对话轮数一多，成本增长非常夸张。
假设每轮用户输入平均1000Token，模型回答500Token，单轮开销1500Token。到第N轮时，光是历史上文就有大约1500×(N-1)个Token，再叠加当前输入和输出，累计Token消耗是平方级增长的。做个简化计算：
| 对话轮数 | 当次请求的输入Token（约） | 累计Token消耗（约） |
|---|---|---|
| 1 | 1000 | 1500 |
| 10 | 10000 | 82500 |
| 30 | 30000 | 697500 |
我见过最典型的案例：内部知识库机器人上线两周，平均每次请求携带的历史信息已经接近模型上下文上限，账单直接乘了三倍，响应还明显变慢。
控制上下文是个系统工程。常用的手段有：
- 滑动窗口：只保留最近N轮对话，旧的裁剪掉，这是最简单有效的。
- 分层摘要：对更早的历史做一次摘要，把摘要当作一条消息放进上下文。
- RAG注入：先按问题检索相关片段，只把命中的知识放进提示词，而不是把所有文档全塞进去。
关键要记住：上下文长度不只是成本问题，还是延迟问题。输入Token越多，首Token出来的时间越长。把"省Token"当成性能优化来做，方向就对了。
4.2 内存里的幽灵：缓存、事件与巨大的字符串
模型返回的内容动辄几千字符，如果服务里还叠加了会话缓存、静态字典、事件订阅，内存泄漏会来得很隐蔽。
排查顺序我一般是：先看托管堆有没有持续增长的巨大对象。
- 某些团队为了做"会话快照"，把原始响应字符串整个存进ConcurrentDictionary，还不设过期，几天下来就是GB级内存。
- 有人为了让前端能实时统计Token，把事件处理器挂到静态事件上，服务重启前永远不会回收——这不是AI独有的问题，但AI场景下因为调用频繁，泄漏速度会放大很多倍。
- 解析大JSON时，如果到处用字符串截取和拼接，也会产生大量临时对象，压榨GC。
诊断时建议先用官方命令行工具看关键计数器（托管堆大小、GC次数、线程池饥饿指标），如果GC频率持续偏高且堆只涨不降，再抓内存转储做对象类型统计。90%的情况都能在对象统计里一眼定位到那个无人清理的缓存。
4.3 延迟优化：先算好"首字时间"
生产环境评价AI接口，最直观的体验指标是首Token时间，而不是整体响应时间。用户看到"正在生成"的动画，等待焦虑会大幅下降。
优化的顺序也有讲究：
- 优先确认请求是否走了流式，非流式在生成完才返回，体验天然差。
- 检查是否存在"同步转异步"的写法。C#里最常见的是用Task.Result去等一个异步方法，这在并发上来以后会拖垮线程池。必改。
- 看业务逻辑里有没有串行调多个模型接口。比如一个请求里既要做意图识别又要做摘要生成，如果两者没有依赖关系，完全可以并行。
- 信不信由你，很多延迟问题最后定位出来是"上下文太长"而不是"模型太慢"。把历史消息裁剪后，首Token时间能下降一个数量级。
5. 可观测性：让每次AI调用都能被审计
5.1 日志里必须有的AI专属字段
普通请求日志记录URL、状态码、耗时就够了，AI调用还得多记几个字段，不然出了问题你根本没法复盘。
| 字段 | 作用 |
|---|---|
| RequestId | 串联业务请求与模型调用 |
| ModelName | 出问题时确认用的哪个模型 |
| PromptVersion | 辨析Prompt变更造成的影响 |
| InputTokens / OutputTokens | 成本核算的直接依据 |
| LatencyMs / TtftMs | 性能分析依据 |
| RetryCount | 区分一次成功和重试成功的调用 |
| ProviderTraceId | 供应商侧排查的凭证 |
日志还有一个特殊风险：Prompt里可能包含用户隐私数据。生产日志系统必须有脱敏机制，比如手机号、地址、证件号自动打码。建议默认不打印完整Prompt，只打印截断后的摘要，需要排查时再从带权限的存储里按RequestId检索原文。
5.2 指标告警：延迟、错误、429、成本四件套
指标层面，我会给每个功能模块、每个模型分别打点。重点盯四类：
- 延迟：看P50/P95/P99，P95比平均值重要得多。一个慢调用会把平均拉高，但P95能反映真实用户体感。
- 错误率：按状态码分类，尤其把429单列，它代表限流而不是模型挂了。
- 429占比：一旦持续升高，说明客户端限流没生效，或是配额不够，需要扩容配额或收紧闸门。
- Token消耗：按功能、按模型、按用户维度统计，设置每日预算阈值。这个指标最容易被忽略，因为它不是"故障"，顶多算"流失"，但流失也是真金白银。
告警规则别贪多，先设三条最核心的：错误率持续5分钟超5%、P95延迟超阈值上限、日Token消耗超预算80%。我见过一上来配二十条告警的团队，结果真正出大事时反而被告警噪音淹没。
5.3 全链路追踪：从用户点击到模型响应的完整链路
一旦AI功能被嵌入复杂的业务流程（先检索、再调用模型、再落库、再通知），没有链路追踪会很难排查。.NET生态里标准做法是用Activity创建追踪跨度，每次调用模型时把业务TraceId传给供应商请求头，这样两端日志可以对上。
实操上我会要求：业务请求入口生成TraceId；网关每次调用模型时，把TraceId、RequestId都写进日志上下文；如果供应商支持传递自定义标识，一并传过去。排查问题时，拿到一个用户投诉，顺着TraceId就能看到"检索用了多少毫秒、模型调用等待了多少毫秒、在哪个环节重试了一次"，效率提升不止一倍。
6. 测试与发布：把"不稳定"关进笼子里
6.1 单元测试：用桩件隔离模型
单元测试阶段，千万别调真实的模型服务。原因很直接：模型输出不稳定，测试用例就没法稳定；而且测一次烧一次钱。
做法是给IChatGateway注入桩件：
public sealed class StubChatGateway : IChatGateway { public Task<ChatResult> CompleteAsync( ChatRequest request, CancellationToken ct) => Task.FromResult(new ChatResult($"桩件响应: {request.UserText}")); }这样业务逻辑的分支、异常路径、格式解析都能确定性验证。真实模型的正确性验证放到集成测试或回归评测阶段，而不是单元测试阶段。
6.2 黄金样本集：模型功能的回归基线
AI功能最大的痛点是"这周还好好的，下周怎么就不对劲了"。原因通常是供应商悄悄更新了模型、或者你改了Prompt。
解决思路是搞一个黄金样本集：准备几十到几百条有代表性的输入，每条都定义好"通过标准"，比如JSON结构是否合法、关键字段是否非空、是否包含必需的关键词。每天晚上用当前配置的模型跑一遍，记录通过率、平均延迟、Token消耗。
这个回归基线能帮你抓住两类问题：
- 模型升级后的质量退化（通过率下降）；
- Prompt改动引发的连锁副作用（之前能过的样例开始不过）。
相关阈值一跌，立刻报警，然后在灰度环境中排查是哪个因素导致的。这套东西一开始会有点繁琐，但它是我见过的性价比最高的AI质量保障手段。
6.3 灰度发布与快速回滚：让模型版本变更可控
模型部署和代码交付一样，要讲发布策略。不要某天早上直接把生产环境全部切到新模型，哪怕新模型看起来表现更好。
我的标准流程是：
- 先用配置中心把新模型、新Prompt只放给5%的白名单用户。
- 对比这5%和95%的黄金样本通过率、P95延迟、Token消耗。
- 确认没问题后再逐步放量，10%、30%、50%、100%。
- 一旦发现异常，通过配置中心一键切回旧模型，代码不需要发版。
记住，"回滚"在AI系统里往往不是回滚代码，而是回滚配置。所以从第一天起，模型名、供应商、Prompt版本都要做成可配置项，这一条怎么强调都不过分。
7. 三个真实踩坑实录：教训比经验更值钱
7.1 坑一：JSON偶发不合法，线上反序列化崩溃
某内部服务上线第一周，就出现了一个诡异的错误：用户反馈解析失败，异常信息指向JSON反序列化的第127行。Demo阶段测试了20个样例全部通过，生产线上却有约2%的请求失败。
排查过程还原一下：网关没有校验层，拿到的原始响应直接JsonSerializer.Deserialize。出错集中在两种场景：一是答案被max_tokens截断，JSON结构不完整；二是模型偶尔把JSON包进了Markdown代码围栏json。
修复分三步：在网关里先剥离代码围栏；解析失败后把错误提示喂回模型，让它重新生成；把max_tokens上调，留出格式合规的余量。修复后错误率从2%降到0.01%以下。这个经历后来被我写进了团队规范：所有模型输出，进业务代码之前必须过一层格式校验。
7.2 坑二：并发一上去，429和超时一起爆炸
某对外服务在压测时重现过经典雪崩：客户端不加限流地并发调用，一个批任务同时发起30个请求，瞬间打到限流上线，返回一堆429。而重试策略又是"失败后立即重试"，30个429又各自重试，把下行的请求数放大成了60、90，服务端直接进入熔断状态。
根因有两个：没有客户端侧并发闸门；重试没有退避。修复后我们在网关加了SemaphoreSlim限制并发为8，重试改为指数退避加抖动，并且把429的Retry-After纳入等待时间。再压测，请求曲线平滑了，429大幅减少，整体吞吐反而因为少了一堆无效重试而变高。
这个案例说明一个反直觉的事实：对限流系统来说，你越"努力"重试，吞吐反而越低。控制住重试和并发，才是对吞吐最大的尊重。
7.3 坑三：上下文没裁剪，账单翻了三倍
某客服机器人，上线时一切正常，两周后账单陡增。查日志发现，平均每次请求的输入Token从3000涨到了近3万。
真相很简单：会话历史全部保留，没有任何裁剪。用户聊了50轮，机器人就把50轮的历史全部发给模型。聊天体验没变好，反而因为输入太长，响应开始变慢。
修复方案是三层：滑动窗口只保留最近20轮；更早的内容用摘要压缩成一条记忆；为每个会话设置累计Token预算，超了强制触发摘要或结束会话。修完之后的指标很直接：账单回落，P95延迟下降40%。
现在我把"上下文管理"列进所有AI项目的架构评审必查项，凡是看到全量历史直传的，一律先做裁剪再放行。
最后再分享一点我个人的体会。C#做AI最值钱的地方，恰恰是那些在Python Demo里被省略的工程能力：类型安全、依赖注入、诊断工具、完善的测试框架。Demo帮你验证的是"模型能不能做这件事"，而生产要做的是"这件事在真实流量下能不能一直做下去"。这两者之间差的那一大截，就是这篇文章想帮你填上的。如果你现在正处于从Demo走向生产的阶段，我建议你从三件事开始：把模型调用收进网关、给所有调用加上超时和取消、把Token消耗和错误率打点接上。做完这三件事，再往前走，你会轻松很多。
