13 家 LLM 提供商，一台本地服务器全仿真：.NET 测试的新解法

今天在 GitHub 上闲逛，刷到一个挺有意思的仓库：managedcode/LlmTestServer。

Star 只有 2 个，一个还是我star的，但我把代码翻完之后觉得，这可能是今年 .NET 圈最被低估的一个工具。它做的事情一句话就能说清：在本地跑一个假的 LLM 服务商，OpenAI、Anthropic、Gemini 全都能演，但你测试里的应用根本分不出来。

先说说痛点

如果你写过调用大模型的应用，一定被测试折磨过。

调真实 API 吧，又慢又烧钱，更致命的是模型每次回答都不一样------你永远没法写 assert reply == "xxx"，测试 CI 跑十次挂三次，挂的还是不同的三次。

那 mock 掉 HTTP 客户端？也行，但你的测试就绕过了官方 SDK 的序列化、重试、流式解析------恰恰是这些地方最容易出线上事故。至于限流 429、内容过滤拦截、SSE 流中途断掉这种异常路径，想在真实 API 上复现，基本靠缘分。

这个项目的思路很直接：既然问题是"模型不确定"，那就把模型换成一个完全听你指挥的服务器。

它是怎么工作的

启动方式就一行：

sh 复制代码

docker run --rm -p 8080:8080 \
  -e LlmTestServer__RequiredBearerToken=test-key \
  ghcr.io/managedcode/llm-test-server:1.0.0

然后用客户端把"剧本"灌进去------第一个请求回什么、第二个请求回什么、什么时候该报 429、流式响应在哪个分片断掉，全都由你的测试脚本决定：

csharp 复制代码

await control.ConfigureAsync(config => config
    .RequireBearerToken("test-key")
    .UseChatModel("gpt-6.1-sol")
    .UseChatScenario("delivery", scenario => scenario
        .ForModel("gpt-6.1-sol")
        .Responds("Your order arrives on Friday.")
        .Responds("Delivery is free.")));

应用侧呢？什么都不用改，只把 base URL 从 api.openai.com 换成 http://localhost:8080/openai/v1。官方 SDK 照常用，流式照常流，工具调用照常调------只是对面坐着的从 GPT 换成了一个绝对听话的演员。

这个演员的演技覆盖面相当广：13 家提供商，包括 OpenAI、Azure OpenAI、Anthropic、Gemini、Bedrock、Groq、Mistral、Ollama、Cohere 等等。像 Anthropic 的 Messages 协议、Gemini 的 generateContent、Bedrock 的 Converse 这些非 OpenAI 系的协议，它都实现了原生模拟，不只是套一层 OpenAI 兼容皮。甚至连图像生成、语音转写、视频生成这些多模态接口都覆盖了。

整体架构一张图能看明白：左边是你的测试和官方 SDK，右边是这个假服务器，中间只隔一个 base URL。服务器内部三件事------按剧本回答、把每次请求记进日志、用仪表盘给你看------而真实 API，永不调用。

让我眼前一亮的三个设计

第一个是会话步图。 测客服机器人这类多轮对话时，光有"回答队列"是不够的------用户说"退款"和说"物流"，机器人该走的路完全不同。这个项目允许你把对话定义成一个状态机：用户消息匹配什么条件、跳到哪个步骤、什么时候结束，都能编排。每个测试会话有独立的状态，并行跑互不干扰。

第二个是 token 账本。 它内置了真实的分词器，能把每次请求的输入拆成系统提示、工具 schema、历史消息各占多少 token，还能模拟各家提示缓存的读写规则。配着自带的 Blazor 仪表盘，你能亲眼看到"这轮对话的钱到底花在哪了"。等于把成本工程也变成了可以写断言、可以回归的东西------这个我在别的 mock 工具里真没见过。

第三个，也是我最佩服的：防漂移机制。 假服务器最怕什么？怕真 API 改了而它还活在昨天。这项目的解法是：每个提供商包里都存着一份契约，记录官方文档的 URL 和检索日期，超过 180 天没复核，契约测试直接挂红灯。用 CI 强迫自己跟上 API 的演变，这个设计值得所有做 mock 工具的人抄作业。

顺手扒了扒背后的团队

维护者是 Konstantin Semenenko，乌克兰出身、现在法国的 Managed Code 公司的 CTO，21 年 .NET 老兵。项目今年 7 月 7 日第一次提交，10 月 20 日发 1.0.0，之后 8 天连发 6 个修复版------节奏快得不像一个人。

看了仓库根目录我才明白为什么快：这是一个彻头彻尾的 AI 代理驱动开发的项目。仓库里内置了 80 个给 AI 编程代理用的技能包，6 篇架构决策记录，484 个测试，还有一套他们自研的方法论叫 MCAF，核心就三条：上下文必须活在仓库文档里、能不能交付由测试说了算、规矩要写进 AGENTS.md 里持久化。

一个教人"确定性地测试 AI 应用"的工具，自己就是用"让 AI 确定性地写代码"的方式造出来的。这个闭环，比工具本身更值得琢磨。

冷静一下，说点风险

新项目该有的毛病它都有。2 个 star，网上搜不到任何第三方讨论；所有提交出自一个人，bus factor 为 1；13 家提供商的协议跟踪是个长期苦力活，一个人能不能扛住要打个问号。部分文档还诚实地标着"已实现，公开发布待决"------能力面比交付面稍微画大了一点。

所以我的建议是：.NET 团队，特别是已经在用 Aspire 的，现在就可以拿去试 ，一行 builder.AddLlmTestServer() 就能接入，几乎零摩擦。其他栈的团队可以先观望，或者看看同类选手------JS 生态有 CopilotKit 的 AIMock，Java 系有 MockServer 的 LLM 模块。

另外不管用什么 mock，都请保留一小撮定期跑真实 API 的契约测试。Mock 决定你测试跑得多快多稳，真实调用决定你的测试是不是真的------这俩谁也不能替谁。