AI 应用API网关LLM 网关后端前端【免费下载链接】axonhub⚡️ Open-source AI Gateway — Use any SDK to call 100 LLMs. Built-in failover, load balancing, cost control end-to-end tracing.项目地址https://gitcode.com/gh_mirrors/ax/axonhub点击查看免费下载导读本文以 AxonHub 仓库中integration_test/openai/chat/qa_simple目录下的简易问答Simple QA测试用例为主体完整讲解如何基于官方 OpenAI Go SDKgithub.com/openai/openai-go/v3对接 AxonHub 的 Chat Completions 能力覆盖单条提问、不同模型切换、多问题顺序请求三种典型场景并深入剖析其背后的testutil测试工具链、AH-Trace-Id/AH-Thread-Id追踪头注入与响应校验逻辑。读完本文你将能独立配置环境变量、运行这些集成测试并理解 AxonHub 任意 SDK → 任意模型 这一核心能力在真实请求链路中的落地方式。测试用例总览这个目录在测什么integration_test/openai/chat/qa_simple是 OpenAI Go SDK 集成测试中最基础的入口目录 README 明确将其定位为演示基础聊天补全功能basic chat completion functionality的简单问答用例。其测试目标集中在四个方面基础 Chat Completions API调用是否可用不同模型使用如 GPT-4o、GPT-3.5-turbo是否切换正常响应校验Response validation是否覆盖空响应、无 choices 等异常多请求顺序执行是否互不干扰。README 中列出的三个测试函数如下注意README 第 8 行写的是TestSimpleQAWithDifferentModel而测试源码中的实际函数名为TestSimpleQAWithDifferentQuestion实现为换一个问题而非换一个模型——这是文档与代码的一处细微出入下文以源码为准展开TestSimpleQA—— 提问基础算术题 What is 2 2?TestSimpleQAWithDifferentQuestion—— 提问 What is the capital of France?使用同一配置模型TestMultipleQuestions—— 顺序发送三个独立问题太阳系最大行星、罗密欧与朱丽叶作者、黄金化学符号。从源码结构看这三个用例覆盖了单次请求 → 换题请求 → 批量顺序请求三个递进层次是后续多轮对话、流式输出、工具调用 等复杂集成测试的公共基础。运行前的环境准备在跑go test之前需要先完成环境配置。相关要求集中在 integration_test/openai/README.md 的 Prerequisites 一节Go 1.25integration_test/openai/go.mod声明go 1.25.2模块名为github.com/looplj/axonhub/openai_test并依赖github.com/openai/openai-go/v3 v3.10.0AxonHub API Key通过TEST_AXONHUB_API_KEY环境变量注入依赖安装进入测试目录后执行go mod tidy。核心环境变量定义在 integration_test/openai/internal/testutil/config.go 的DefaultConfigWithPrefix中均有默认值兜底export TEST_AXONHUB_API_KEYyour-api-key-here # 必填缺失时测试被跳过/panic export TEST_OPENAI_BASE_URLhttp://localhost:8090/v1 # 可选默认指向本地 AxonHub 网关 export TEST_MODELdeepseek-chat # 可选默认模型 export TEST_TRACE_IDtrace-xxx # 可选默认随机生成 export TEST_THREAD_IDthread-xxx # 可选默认随机生成 export TEST_DISABLE_TRACEfalse # 可选置 true 可关闭追踪头 export TEST_DISABLE_THREADfalse # 可选置 true 可关闭线程头几个值得注意的默认值BaseURL 默认是http://localhost:8090/v1即本地部署的 AxonHub 网关地址与快速入门指南中 Python 客户端示例使用的地址完全一致。若你的网关部署在其他位置请通过TEST_OPENAI_BASE_URL覆盖默认模型是deepseek-chat而非 README 提到的 gpt-4o说明这套测试天然具备OpenAI SDK 调用非 OpenAI 模型的 AxonHub 网关转换能力Config.NewClient()在 APIKey 为空时会直接panic而NewTestHelper在ValidateConfig()失败时会t.Skipf跳过测试——两者行为不同前者用于主动断言配置后者保证未配置环境下测试优雅跳过。ValidateConfig()的校验规则见 config.goAPIKey 必填未禁用 Trace/Thread 时其 ID 必填Model 必填。深入源码三个测试用例的请求链路TestSimpleQA最小可用性验证TestSimpleQA 是整套测试的冒烟用例其请求构造完全遵循 OpenAI Go SDK 的标准写法helper : testutil.NewTestHelper(t, TestSimpleQA) helper.PrintHeaders(t) // 打印当前注入的 AxonHub 请求头调试用 ctx : helper.CreateTestContext() // 携带 trace_id / thread_id 的 context question : What is 2 2? params : openai.ChatCompletionNewParams{ Messages: []openai.ChatCompletionMessageParamUnion{ openai.UserMessage(question), }, Model: helper.GetModel(), // 从环境变量读取默认 deepseek-chat } completion, err : helper.CreateChatCompletionWithHeaders(ctx, params) helper.AssertNoError(t, err, Failed to get chat completion) helper.ValidateChatResponse(t, completion, Simple QA) response : completion.Choices[0].Message.Content if !containsNumber(response) { // 期望响应中出现 4/four/Four t.Errorf(Expected response to contain a number, got: %s, response) }关键点模型不是硬编码而是通过helper.GetModel()从配置读取——这正是 README 中Different model usage特性的源码级体现同一份测试代码靠环境变量即可切换模型。TestSimpleQAWithDifferentQuestion换题验证TestSimpleQAWithDifferentQuestion 在同一个helper模式下提问 What is the capital of France?随后用自实现contains(response, Paris)断言答案中必须出现 Paris。它验证了两件事一是测试框架对任意问题的泛化支持二是即使答案来自不同模型核心事实校验依然成立。TestMultipleQuestions顺序批量请求TestMultipleQuestions 用for循环顺序发送三个问题每个请求独立构造params、独立调用CreateChatCompletionWithHeaders、独立做校验并用t.Logf输出每题问答内容。它验证了多次请求之间无共享状态、互不干扰每次只携带单条 user 消息无历史上下文在同一个ctx即同一个 trace/thread下连续请求是允许的符合 追踪指南 中1 个 Thread 可包含多个 Trace的层级模型。响应校验与自实现字符串匹配ValidateChatResponse 定义了统一的响应校验规则响应为 nil → 直接t.FatalfChoices为空 → 失败Message.Content为空且无ToolCalls→ 失败注释明确说明OpenAI 模型在做工具调用时常返回空 content故对工具调用场景放行。而qa_simple_test.go末尾自实现的containsNumber/contains/containsMiddle三个辅助函数见 qa_simple_test.go没有使用strings.Contains而是手写了前缀匹配 后缀匹配 中间匹配的逻辑且contains会先比较长度。从代码结构看这是为了在无额外依赖的测试包内实现朴素的子串匹配实际断言效果与strings.Contains等价但更具教学示意性。运行测试命令与 Makefile 目标README 给出了目录内的三种运行方式# 运行该目录下全部测试 go test -v # 运行单个测试 go test -v -run TestSimpleQA # 运行指定测试verbose 输出 go test -v -run TestMultipleQuestions注意该测试目录go test -v需要在integration_test/openai/chat/qa_simple目录内执行因其依赖internal/testutil与独立的go.mod模块。README 中的命令在当前工作目录仓库根直接执行会找不到模块正确姿势是进入模块目录或从integration_test/openai顶层用包路径运行cd integration_test/openai go test -v ./qa_simple cd integration_test/openai go test -v -run TestSimpleQA ./qa_simple此外integration_test/openai/chat/Makefile 提供了一组封装好的目标其中与 qa_simple 强相关的有make test-qa # go mod tidy 后执行 go test -v ./qa_simple make test-simple # go test -v -run TestSimple ./qa_simple只跑 Simple 前缀用例 make quick # go test -short -v ./qa_simple快速验证 make check-env # 检查 OPENAI_API_KEY、BASE_URL、TRACE/THREAD ID 等环境配置make test-all/make test则会以--count1 -v ./...运行整个 OpenAI 测试套件qa_simple 是其中最先被执行的轻量用例之一。底层原理测试工具链与追踪头注入所有 qa_simple 用例都不是裸调 SDK而是统一经由 integration_test/openai/internal/testutil/helper.go 的TestHelper。它封装了四件事客户端创建config.NewClient()用option.WithAPIKeyoption.WithBaseURL构造指向 AxonHub 网关的 OpenAI 客户端追踪头注入CreateChatCompletionWithHeaders在调用时把GetHeaderOptions()即AH-Trace-Id/AH-Thread-Id作为option.RequestOption追加进请求——见 config.go。这两个头正是 追踪指南 中定义的标准头AH-Trace-Id代表一条用户消息及其触发的所有 agent 请求AH-Thread-Id代表完整对话会话模型读取GetModel()/GetModelWithFallback()从环境变量或默认值解析模型断言与校验AssertNoError、ValidateChatResponse等统一测试工具。从请求链路看一次 qa_simple 测试的完整路径是OpenAI Go SDK → (APIKey BaseURL) → AxonHub 网关/v1/chat/completions→ 上游模型与 OpenAI API 参考 中POST /v1/chat/completions端点的标准用法一一对应。也就是说这个测试目录本质上是在验证 AxonHub 的 OpenAI 兼容入口而非直接连接 OpenAI 官方。扩展到其他场景qa_simple 的定位在 integration_test/openai/README.md 的整体测试矩阵中qa_simple 是能力金字塔的底座测试目录验证能力qa_simple基础 Chat Completions、多模型、响应校验conversation多轮对话、上下文保持、System Prompttool_single单工具调用tool_multiple多工具顺序/并行调用streaming流式响应trace_multiple_requests单 Trace 内多请求thread_multiple_traces单 Thread 内多 Trace同一套internal/testutil工具链也被 anthropic 与 gemini 的集成测试复用这从侧面印证了 AxonHub用任意 SDK 调任意模型的设计——测试框架本身就是 SDK 中立、模型可配置的。常见问题与排错要点结合 config.go 的校验逻辑与 openai README 的 Troubleshooting 一节运行 qa_simple 时的典型问题如下报错API key is required (set TEST_AXONHUB_API_KEY environment variable)说明未配置密钥测试被跳过t.Skipf路径请先export TEST_AXONHUB_API_KEY...panic: TEST_AXONHUB_API_KEY environment variable is required出现在NewClient()阶段说明配置未生效就试图建客户端404 / 连接失败确认TEST_OPENAI_BASE_URL指向的 AxonHub 网关正在运行默认是http://localhost:8090/v1断言失败如答案未包含 Paris / 4多为上游模型回答不稳定所致可先t.Logf查看实际响应再判断依赖缺失在integration_test/openai目录执行go mod tidy后重试。结语qa_simple虽然只有三个用例却是理解 AxonHub 集成测试体系的最佳起点它完整演示了 OpenAI Go SDK 如何在零代码改动的前提下指向 AxonHub 网关、如何通过环境变量切换模型默认甚至直接就是deepseek-chat、如何注入AH-Trace-Id/AH-Thread-Id实现低侵入可观测以及统一的响应校验如何落地。在此基础上继续阅读多轮对话、流式输出与工具调用用例即可逐步搭建起完整的网关能力验证矩阵。赞分享AI 应用API网关LLM 网关后端前端【免费下载链接】axonhub⚡️ Open-source AI Gateway — Use any SDK to call 100 LLMs. Built-in failover, load balancing, cost control end-to-end tracing.项目地址https://gitcode.com/gh_mirrors/ax/axonhub点击查看免费下载相关推荐基于 AxonHub 的 Anthropic Go SDK 简单问答集成测试实战指南基于 AxonHub 的 Anthropic Go SDK 简单问答集成测试实战指南 本文以 AxonHub 仓库中 integration_test/anthAI 应用API网关LLM 网关后端前端AxonHub 同线程多 Trace 集成测试实战基于 Anthropic Go SDK 验证追踪与线程隔离AxonHub 同线程多 Trace 集成测试实战基于 Anthropic Go SDK 验证追踪与线程隔离 AxonHub 通过 AH Thread IdAI 应用API网关LLM 网关后端前端AxonHub 会话集成测试实战基于 Anthropic Go SDK 的多轮对话、工具调用与上下文保持AxonHub 会话集成测试实战基于 Anthropic Go SDK 的多轮对话、工具调用与上下文保持 本文围绕 AxonHub 仓库中 integratiAI 应用API网关LLM 网关后端前端上一篇openEuler镜像刷写完全指南openeuler/rockchip工具实现SD卡与EMMC双模式下一篇react-final-form 提交错误处理实战Promise resolve 与 FORM_ERROR 的正确用法创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考