AI SDK ai-functions 示例仓库实战跨 Provider 验证、测试与迭代 AI 函数【免费下载链接】aiThe AI Toolkit for TypeScript. From the creators of Next.js, the AI SDK is a free open-source library for building AI-powered applications and agents项目地址: https://gitcode.com/GitHub_Trending/ai/aiexamples/ai-functions是 AI SDK 仓库中专用于「快速验证、测试与迭代ai函数」的脚本与测试套件目录覆盖文本生成、流式输出、结构化输出、Embedding、图片/语音/视频生成、转写、工具调用、Agent 与 Harness 等能力并横跨 OpenAI、Anthropic、Google、Amazon Bedrock、xAI、Groq、Mistral 等数十个 Provider。本文以该目录的 README 为主体结合 package.json 脚本、feature-test-suite 源码与典型示例脚本讲解如何从零跑通基础示例、如何手动执行端到端 Provider 集成测试以及如何理解并扩展这套能力矩阵测试机制。目录定位它是做什么的该目录的核心使命非常明确为 AI SDK 开发者提供一套低门槛的脚本与测试用于在不同 Provider 上快速验证、测试和迭代ai函数。它由两类内容组成基础示例脚本Basic Examples以脚本形式pnpm tsx直接执行演示各ai函数的用法覆盖 generate-text、stream-text、embed、generate-image、generate-speech、generate-video、transcribe、rerank 等子目录端到端 Provider 集成测试End-to-end Provider Integration Tests位于src/e2e下用于对 Provider 的常见能力做冒烟测试smoke test。从 package.json 可以看到这个示例工程以workspace:*方式依赖仓库内全部 Provider 包ai-sdk/openai、ai-sdk/anthropic、ai-sdk/google、ai-sdk/amazon-bedrock、ai-sdk/xai、ai-sdk/mistral等数十个同时引入ai核心包与dotenv、tsx、vitest、zod、valibot、arktype等工具链天然适合作为「多 Provider 能力对照试验场」。快速开始运行基础示例脚本README 给出了一条标准的「三步走」使用路径完整继承如下。第一步创建 .env 并填入 API Key在examples/ai-functions目录下创建.env文件至少包含你要使用的 Provider 的密钥内容形如OPENAI_API_KEYYOUR_OPENAI_API_KEY # 按需继续追加其他 Provider 的配置例如 # ANTHROPIC_API_KEYYOUR_ANTHROPIC_API_KEY # GOOGLE_GENERATIVE_AI_API_KEYYOUR_GOOGLE_API_KEY # XAI_API_KEYYOUR_XAI_API_KEY # GROQ_API_KEYYOUR_GROQ_API_KEY # ...这里的关键机制是所有示例脚本都通过 lib/run.ts 中的import dotenv/config加载环境变量因此密钥统一从当前工作目录的.env读取。使用的 Provider 越多需要配置的环境变量就越多README 原文即强调 and more settings, depending on the providers you want to use。第二步在仓库根目录安装与构建pnpm install pnpm build必须在 AI SDK 仓库根目录即examples/ai-functions的上级执行。由于示例工程通过workspace:*引用仓库内的ai核心包与各 Provider 包安装后还需构建这些 workspace 包脚本才能正确解析到本地源码实现。第三步运行任意示例脚本在examples/ai-functions目录下用tsx直接运行任意脚本pnpm tsx src/path/to/example.ts例如运行 OpenAI 的基础文本生成示例pnpm tsx src/generate-text/openai/basic.tsrun() 辅助函数统一错误处理与夹具录制绝大多数示例脚本都通过run(...)包装执行逻辑。查看 lib/run.ts 的实现可以发现几个关键约定脚本顶层引入dotenv/config完成环境变量加载若执行结果为可记录结果isRecordableResult会自动调用recordFixture录制夹具fixture若抛出APICallError会额外打印请求体error.requestBodyValues与响应体error.responseBody这对调试 Provider 返回的原始报文非常有价值支持FAIL_ON_ERROR1环境变量设置后任何错误都会以退出码 1 结束进程方便在 CI/脚本化场景中把「示例跑通」当作硬性检查。辅助的 lib/print.ts 则在打印结果前递归剔除undefined字段让控制台输出更干净。典型示例脚本解析下面结合几个有代表性的脚本说明各ai函数的实际调用形态。文本生成 generateTextgenerate-text/openai/basic.tsimport { openai } from ai-sdk/openai; import { generateText } from ai; import { run } from ../../lib/run; import { print } from ../../lib/print; run(async () { const result await generateText({ model: openai(gpt-6-astra), prompt: Invent a new holiday and describe its traditions., maxRetries: 0, }); print(Content:, result.content); print(Usage:, result.usage); print(Finish reason:, result.finishReason); print(Raw finish reason:, result.rawFinishReason); });可以看到示例会打印content生成内容、usagetoken 用量、finishReason与rawFinishReason结束原因及其 Provider 原始值maxRetries: 0则关闭重试以便暴露真实错误。流式输出 streamTextstream-text/openai/basic.tsrun(async () { const result streamText({ model: openai(gpt-5-nano), prompt: Invent a new holiday and describe its traditions., maxRetries: 0, }); printFullStream({ result }); print(Usage:, await result.usage); print(Finish reason:, await result.finishReason); print(Raw finish reason:, await result.rawFinishReason); });流式结果通过printFullStream逐步打印usage、finishReason等元信息则以 Promise 形式在消费完流后获取——这正是streamText返回结果对象的核心异步语义。Embeddingembed/openai/basic.tsrun(async () { const { embedding, usage, warnings } await embed({ model: openai.embedding(text-embedding-3-small), value: sunny day at the beach, }); console.log(embedding); console.log(usage); console.log(warnings); });图片生成 generateImagegenerate-image/openai/basic.tsrun(async () { const prompt A blue cream Persian cat in Kyoto in the style of ukiyo-e; const result await generateImage({ model: openai.image(gpt-image-1.5), prompt, n: 3, }); await presentImages(result.images); console.log( Provider metadata:, JSON.stringify(result.providerMetadata, null, 2), ); });n: 3表示一次生成 3 张图presentImages负责在终端展示结果providerMetadata则保留 Provider 返回的原始元信息。结构化输出 Output.objectgenerate-text/openai/output-object.tsconst result await generateText({ model: openai(gpt-4o-mini), providerOptions: { openai: { strictJsonSchema: true, } satisfies OpenAILanguageModelResponsesOptions, }, tools: { weather: weatherTool, }, stopWhen: isStepCount(5), output: Output.object({ schema: z.object({ elements: z.array( z.object({ location: z.string(), temperature: z.number(), condition: z.string(), }), ), }), }), prompt: What is the weather in San Francisco, London, Paris, and Berlin?, }); print(Output:, result.output); print(Request:, result.request.body);这个示例同时演示了 Provider 专属选项strictJsonSchema、工具注册weather、步骤上限stopWhen: isStepCount(5)与 Zod 模式约束的结构化输出最后还能通过result.request.body检查实际发出的请求体——非常适合验证 Provider 侧的 JSON Schema 行为。端到端 Provider 集成测试除了基础脚本src/e2e下还有一套端到端 Provider 集成测试。README 明确了两点关键定位这些测试不跑在 CI 流水线上只能手动运行——它们是留给 AI SDK 开发者做冒烟测试smoke test用的失败不一定代表 SDK 有 bug配额限制quota restrictions、Provider 侧的变更vendor-side changes、密钥缺失或过期missing or stale credentials等外部因素都可能导致失败。从目录清单看e2e 下已覆盖openai、anthropic、google、google-vertex、amazon-bedrock、amazon-bedrock-anthropic、azure、baseten、cerebras、cohere、deepinfra、deepseek、fireworks、gateway、groq、huggingface、luma、mistral、perplexity、togetherai、xai以及raw-chunks等测试文件。运行全部 e2e 测试pnpm run test:e2e:all该命令映射到 package.json 中的vitest run src/e2e/*.test.ts即一次性跑完src/e2e下所有*.test.ts。运行单个测试文件pnpm run test:file src/e2e/google.test.ts对应脚本为vitest run后面直接跟目标测试文件路径即可只跑该 Provider 的套件。按测试名过滤子集pnpm run test:file src/e2e/google.test.ts -t stream-t是 Vitest 的按名称过滤参数这里只执行名称匹配stream的用例如 should stream text、流式结构化输出等。测试用例命名带有清晰的前缀因此可以通过-t精确切分到某一能力子集——这正是 README 所说 Test filtering can allow slicing to a subset of tests。feature-test-suite能力矩阵测试机制src/e2e下所有 Provider 测试都建立在 feature-test-suite.ts 提供的createFeatureTestSuite之上。理解这个机制就理解了整套 e2e 的骨架。Capability 能力声明测试套件先用Capability联合类型声明 Provider 模型可能具备的能力feature-test-suite.ts#L24-L33export type Capability | audioInput | embedding | imageGeneration | imageInput | objectGeneration | pdfInput | searchGrounding | textCompletion | toolCalls;并提供了「模型 能力列表」的包装结构与工厂函数createLanguageModelWithCapabilities默认携带imageInput、objectGeneration、pdfInput、textCompletion、toolCalls见 feature-test-suite.ts#L42-L52、createEmbeddingModelWithCapabilities默认[embedding]、createImageModelWithCapabilities默认[imageGeneration]。条件化测试注册describeIfCapabilityfeature-test-suite.ts#L145-L154会在模型能力列表满足所需能力时才注册对应的describe块shouldRunTests则要求所需能力全部存在于声明列表中。这意味着模型声明了哪些能力套件就自动只跑哪些测试未声明的能力对应用例会被整体跳过——同一份测试套件可以安全地复用于不同能力组合的模型。套件签名与覆盖范围createFeatureTestSuite({ name, models, timeout, customAssertions })feature-test-suite.ts#L156-L161接收models配置其中可包含languageModels带能力的语言模型数组embeddingModels/imageModels带能力的 Embedding / 图片模型数组invalidModel/invalidImageModel用于错误处理测试的无效模型customAssertions可配置skipUsage跳过 token 用量断言与errorValidator自定义错误校验。从套件内部结构看它覆盖了以下测试分组Basic Text Generation普通文本生成、带 system prompt 的生成、streamText流式生成feature-test-suite.ts#L172-L233Object GenerationOutput.object结构化输出涵盖简单对象、数组、嵌套对象、字段描述.describe()、system prompt 组合、跨引用 Schema 等十余个用例Tool Calls工具调用、流式工具调用、多步顺序工具调用如「查温度 → 播放匹配音乐」的串联场景Image Input图片 URL 与 base64 两种输入方式配合type: file消息块PDF Input读取./data/ai.pdf的 base64 做文档摘要Audio Input读取./data/galileo.mp3生成带时间戳的转写文本Search Grounding校验 Google 系模型返回的groundingMetadatawebSearchQueries、searchEntryPoint、groundingSupports与safetyRatingsChat/Image Model Error Handling用无效模型 ID 触发APICallError验证错误类型与错误信息feature-test-suite.ts#L1034-L1048Embedding Generationembed单条与embedMany批量feature-test-suite.ts#L1090-L1127Image GenerationgenerateImage返回 base64 且解码后大于 10KBfeature-test-suite.ts#L1134-L1156。测试套件所需的图片comic-cat.png、PDFai.pdf、音频galileo.mp3等样本文件统一放在 examples/ai-functions/data 目录中。以 openai.test.ts 为例解读 Provider 接入方式每个 Provider 的 e2e 文件只需做「声明模型 调用套件」两件事。openai.test.ts 展示了标准写法createFeatureTestSuite({ name: OpenAI, models: { invalidModel: provider.chat(no-such-model), languageModels: [ createChatModel(gpt-4.1), createChatModel(gpt-4.1-mini), createChatModel(o3), createChatModel(gpt-4o-mini), createChatModel(gpt-5), // ... ], embeddingModels: [ createEmbeddingModelWithCapabilities( provider.embeddingModel(text-embedding-3-small), ), ], }, timeout: 30000, customAssertions: { skipUsage: false, errorValidator: (error: APICallError) { expect(error.message).toMatch(/The model .* does not exist/); }, }, })();要点包括languageModels可以一次登记同一 Provider 的多个模型从gpt-3.5-turbo到gpt-5系列套件会用describe.each对每个模型分别执行能力用例invalidModel声明为provider.chat(no-such-model)错误处理用例据此断言APICallError且错误信息匹配/The model .* does not exist/timeout: 30000覆盖默认 10 秒超时为慢模型留出余量。从 e2e 用例到基础脚本的映射README 还点明了一个重要设计大多数 e2e 用例都能在src下对应子目录的基础示例脚本中找到某种形式的等价实现。从目录结构看确实如此——例如e2e 的文本生成/流式/结构化输出用例对应src/generate-text/openai/下的basic.ts、output-object.ts、output-json.ts、output-array.ts等脚本e2e 的图片输入用例对应src/generate-text/openai/下的image-url.ts、image-base64.ts、image-data-tagged.ts等脚本e2e 的 Embedding 用例对应src/embed/*、src/embed-many/*脚本。这种「脚本 测试」双轨结构的好处是基础脚本适合快速迭代验证改一行、跑一次、看输出e2e 测试适合回归式冒烟一条命令覆盖全部能力。开发者可以先跑脚本确认某个新 Provider 能力可用再把它固化为 e2e 用例长期守护。排错与注意事项结合 README 说明与 lib/run.ts 的实现实际使用中需要注意e2e 失败先查外部因素配额不足、Provider 侧接口变更、密钥缺失或过期是最高频的失败原因并不一定代表 SDK 或测试本身有问题密钥配置不全脚本依赖.env中的 API Key缺 key 会直接导致调用失败使用哪些 Provider 就配置哪些变量先在仓库根目录pnpm install pnpm build跳过构建直接跑示例会因 workspace 包未编译而报错善用错误输出APICallError会自动打印请求体与响应体配合FAIL_ON_ERROR1可以让示例脚本在 CI 脚本化场景中以失败退出码暴露问题按需切片e2e 支持按文件test:file与按名称-t过滤不必每次都跑全量。总结examples/ai-functions是 AI SDK 仓库中一块「高频试验田」基础示例脚本提供了数十个 Provider × 数十种ai函数的可运行样本端到端测试套件则通过能力矩阵机制CapabilitydescribeIfCapabilitycreateFeatureTestSuite实现了「一份套件、多 Provider 复用」的冒烟测试模式。无论你是要验证某个 Provider 的新能力、排查某个函数的异常输出还是为仓库新增 Provider 做回归保障都可以按照「配置.env→ 仓库根目录构建 →pnpm tsx跑脚本 /pnpm run test:e2e:all跑测试」的路径快速上手。【免费下载链接】aiThe AI Toolkit for TypeScript. From the creators of Next.js, the AI SDK is a free open-source library for building AI-powered applications and agents项目地址: https://gitcode.com/GitHub_Trending/ai/ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
AI SDK ai-functions 示例仓库实战跨 Provider 验证、测试与迭代 AI 函数【免费下载链接】aiThe AI Toolkit for TypeScript. From the creators of Next.js, the AI SDK is a free open-source library for building AI-powered applications and agents项目地址: https://gitcode.com/GitHub_Trending/ai/aiexamples/ai-functions是 AI SDK 仓库中专用于「快速验证、测试与迭代ai函数」的脚本与测试套件目录覆盖文本生成、流式输出、结构化输出、Embedding、图片/语音/视频生成、转写、工具调用、Agent 与 Harness 等能力并横跨 OpenAI、Anthropic、Google、Amazon Bedrock、xAI、Groq、Mistral 等数十个 Provider。本文以该目录的 README 为主体结合 package.json 脚本、feature-test-suite 源码与典型示例脚本讲解如何从零跑通基础示例、如何手动执行端到端 Provider 集成测试以及如何理解并扩展这套能力矩阵测试机制。目录定位它是做什么的该目录的核心使命非常明确为 AI SDK 开发者提供一套低门槛的脚本与测试用于在不同 Provider 上快速验证、测试和迭代ai函数。它由两类内容组成基础示例脚本Basic Examples以脚本形式pnpm tsx直接执行演示各ai函数的用法覆盖 generate-text、stream-text、embed、generate-image、generate-speech、generate-video、transcribe、rerank 等子目录端到端 Provider 集成测试End-to-end Provider Integration Tests位于src/e2e下用于对 Provider 的常见能力做冒烟测试smoke test。从 package.json 可以看到这个示例工程以workspace:*方式依赖仓库内全部 Provider 包ai-sdk/openai、ai-sdk/anthropic、ai-sdk/google、ai-sdk/amazon-bedrock、ai-sdk/xai、ai-sdk/mistral等数十个同时引入ai核心包与dotenv、tsx、vitest、zod、valibot、arktype等工具链天然适合作为「多 Provider 能力对照试验场」。快速开始运行基础示例脚本README 给出了一条标准的「三步走」使用路径完整继承如下。第一步创建 .env 并填入 API Key在examples/ai-functions目录下创建.env文件至少包含你要使用的 Provider 的密钥内容形如OPENAI_API_KEYYOUR_OPENAI_API_KEY # 按需继续追加其他 Provider 的配置例如 # ANTHROPIC_API_KEYYOUR_ANTHROPIC_API_KEY # GOOGLE_GENERATIVE_AI_API_KEYYOUR_GOOGLE_API_KEY # XAI_API_KEYYOUR_XAI_API_KEY # GROQ_API_KEYYOUR_GROQ_API_KEY # ...这里的关键机制是所有示例脚本都通过 lib/run.ts 中的import dotenv/config加载环境变量因此密钥统一从当前工作目录的.env读取。使用的 Provider 越多需要配置的环境变量就越多README 原文即强调 and more settings, depending on the providers you want to use。第二步在仓库根目录安装与构建pnpm install pnpm build必须在 AI SDK 仓库根目录即examples/ai-functions的上级执行。由于示例工程通过workspace:*引用仓库内的ai核心包与各 Provider 包安装后还需构建这些 workspace 包脚本才能正确解析到本地源码实现。第三步运行任意示例脚本在examples/ai-functions目录下用tsx直接运行任意脚本pnpm tsx src/path/to/example.ts例如运行 OpenAI 的基础文本生成示例pnpm tsx src/generate-text/openai/basic.tsrun() 辅助函数统一错误处理与夹具录制绝大多数示例脚本都通过run(...)包装执行逻辑。查看 lib/run.ts 的实现可以发现几个关键约定脚本顶层引入dotenv/config完成环境变量加载若执行结果为可记录结果isRecordableResult会自动调用recordFixture录制夹具fixture若抛出APICallError会额外打印请求体error.requestBodyValues与响应体error.responseBody这对调试 Provider 返回的原始报文非常有价值支持FAIL_ON_ERROR1环境变量设置后任何错误都会以退出码 1 结束进程方便在 CI/脚本化场景中把「示例跑通」当作硬性检查。辅助的 lib/print.ts 则在打印结果前递归剔除undefined字段让控制台输出更干净。典型示例脚本解析下面结合几个有代表性的脚本说明各ai函数的实际调用形态。文本生成 generateTextgenerate-text/openai/basic.tsimport { openai } from ai-sdk/openai; import { generateText } from ai; import { run } from ../../lib/run; import { print } from ../../lib/print; run(async () { const result await generateText({ model: openai(gpt-6-astra), prompt: Invent a new holiday and describe its traditions., maxRetries: 0, }); print(Content:, result.content); print(Usage:, result.usage); print(Finish reason:, result.finishReason); print(Raw finish reason:, result.rawFinishReason); });可以看到示例会打印content生成内容、usagetoken 用量、finishReason与rawFinishReason结束原因及其 Provider 原始值maxRetries: 0则关闭重试以便暴露真实错误。流式输出 streamTextstream-text/openai/basic.tsrun(async () { const result streamText({ model: openai(gpt-5-nano), prompt: Invent a new holiday and describe its traditions., maxRetries: 0, }); printFullStream({ result }); print(Usage:, await result.usage); print(Finish reason:, await result.finishReason); print(Raw finish reason:, await result.rawFinishReason); });流式结果通过printFullStream逐步打印usage、finishReason等元信息则以 Promise 形式在消费完流后获取——这正是streamText返回结果对象的核心异步语义。Embeddingembed/openai/basic.tsrun(async () { const { embedding, usage, warnings } await embed({ model: openai.embedding(text-embedding-3-small), value: sunny day at the beach, }); console.log(embedding); console.log(usage); console.log(warnings); });图片生成 generateImagegenerate-image/openai/basic.tsrun(async () { const prompt A blue cream Persian cat in Kyoto in the style of ukiyo-e; const result await generateImage({ model: openai.image(gpt-image-1.5), prompt, n: 3, }); await presentImages(result.images); console.log( Provider metadata:, JSON.stringify(result.providerMetadata, null, 2), ); });n: 3表示一次生成 3 张图presentImages负责在终端展示结果providerMetadata则保留 Provider 返回的原始元信息。结构化输出 Output.objectgenerate-text/openai/output-object.tsconst result await generateText({ model: openai(gpt-4o-mini), providerOptions: { openai: { strictJsonSchema: true, } satisfies OpenAILanguageModelResponsesOptions, }, tools: { weather: weatherTool, }, stopWhen: isStepCount(5), output: Output.object({ schema: z.object({ elements: z.array( z.object({ location: z.string(), temperature: z.number(), condition: z.string(), }), ), }), }), prompt: What is the weather in San Francisco, London, Paris, and Berlin?, }); print(Output:, result.output); print(Request:, result.request.body);这个示例同时演示了 Provider 专属选项strictJsonSchema、工具注册weather、步骤上限stopWhen: isStepCount(5)与 Zod 模式约束的结构化输出最后还能通过result.request.body检查实际发出的请求体——非常适合验证 Provider 侧的 JSON Schema 行为。端到端 Provider 集成测试除了基础脚本src/e2e下还有一套端到端 Provider 集成测试。README 明确了两点关键定位这些测试不跑在 CI 流水线上只能手动运行——它们是留给 AI SDK 开发者做冒烟测试smoke test用的失败不一定代表 SDK 有 bug配额限制quota restrictions、Provider 侧的变更vendor-side changes、密钥缺失或过期missing or stale credentials等外部因素都可能导致失败。从目录清单看e2e 下已覆盖openai、anthropic、google、google-vertex、amazon-bedrock、amazon-bedrock-anthropic、azure、baseten、cerebras、cohere、deepinfra、deepseek、fireworks、gateway、groq、huggingface、luma、mistral、perplexity、togetherai、xai以及raw-chunks等测试文件。运行全部 e2e 测试pnpm run test:e2e:all该命令映射到 package.json 中的vitest run src/e2e/*.test.ts即一次性跑完src/e2e下所有*.test.ts。运行单个测试文件pnpm run test:file src/e2e/google.test.ts对应脚本为vitest run后面直接跟目标测试文件路径即可只跑该 Provider 的套件。按测试名过滤子集pnpm run test:file src/e2e/google.test.ts -t stream-t是 Vitest 的按名称过滤参数这里只执行名称匹配stream的用例如 should stream text、流式结构化输出等。测试用例命名带有清晰的前缀因此可以通过-t精确切分到某一能力子集——这正是 README 所说 Test filtering can allow slicing to a subset of tests。feature-test-suite能力矩阵测试机制src/e2e下所有 Provider 测试都建立在 feature-test-suite.ts 提供的createFeatureTestSuite之上。理解这个机制就理解了整套 e2e 的骨架。Capability 能力声明测试套件先用Capability联合类型声明 Provider 模型可能具备的能力feature-test-suite.ts#L24-L33export type Capability | audioInput | embedding | imageGeneration | imageInput | objectGeneration | pdfInput | searchGrounding | textCompletion | toolCalls;并提供了「模型 能力列表」的包装结构与工厂函数createLanguageModelWithCapabilities默认携带imageInput、objectGeneration、pdfInput、textCompletion、toolCalls见 feature-test-suite.ts#L42-L52、createEmbeddingModelWithCapabilities默认[embedding]、createImageModelWithCapabilities默认[imageGeneration]。条件化测试注册describeIfCapabilityfeature-test-suite.ts#L145-L154会在模型能力列表满足所需能力时才注册对应的describe块shouldRunTests则要求所需能力全部存在于声明列表中。这意味着模型声明了哪些能力套件就自动只跑哪些测试未声明的能力对应用例会被整体跳过——同一份测试套件可以安全地复用于不同能力组合的模型。套件签名与覆盖范围createFeatureTestSuite({ name, models, timeout, customAssertions })feature-test-suite.ts#L156-L161接收models配置其中可包含languageModels带能力的语言模型数组embeddingModels/imageModels带能力的 Embedding / 图片模型数组invalidModel/invalidImageModel用于错误处理测试的无效模型customAssertions可配置skipUsage跳过 token 用量断言与errorValidator自定义错误校验。从套件内部结构看它覆盖了以下测试分组Basic Text Generation普通文本生成、带 system prompt 的生成、streamText流式生成feature-test-suite.ts#L172-L233Object GenerationOutput.object结构化输出涵盖简单对象、数组、嵌套对象、字段描述.describe()、system prompt 组合、跨引用 Schema 等十余个用例Tool Calls工具调用、流式工具调用、多步顺序工具调用如「查温度 → 播放匹配音乐」的串联场景Image Input图片 URL 与 base64 两种输入方式配合type: file消息块PDF Input读取./data/ai.pdf的 base64 做文档摘要Audio Input读取./data/galileo.mp3生成带时间戳的转写文本Search Grounding校验 Google 系模型返回的groundingMetadatawebSearchQueries、searchEntryPoint、groundingSupports与safetyRatingsChat/Image Model Error Handling用无效模型 ID 触发APICallError验证错误类型与错误信息feature-test-suite.ts#L1034-L1048Embedding Generationembed单条与embedMany批量feature-test-suite.ts#L1090-L1127Image GenerationgenerateImage返回 base64 且解码后大于 10KBfeature-test-suite.ts#L1134-L1156。测试套件所需的图片comic-cat.png、PDFai.pdf、音频galileo.mp3等样本文件统一放在 examples/ai-functions/data 目录中。以 openai.test.ts 为例解读 Provider 接入方式每个 Provider 的 e2e 文件只需做「声明模型 调用套件」两件事。openai.test.ts 展示了标准写法createFeatureTestSuite({ name: OpenAI, models: { invalidModel: provider.chat(no-such-model), languageModels: [ createChatModel(gpt-4.1), createChatModel(gpt-4.1-mini), createChatModel(o3), createChatModel(gpt-4o-mini), createChatModel(gpt-5), // ... ], embeddingModels: [ createEmbeddingModelWithCapabilities( provider.embeddingModel(text-embedding-3-small), ), ], }, timeout: 30000, customAssertions: { skipUsage: false, errorValidator: (error: APICallError) { expect(error.message).toMatch(/The model .* does not exist/); }, }, })();要点包括languageModels可以一次登记同一 Provider 的多个模型从gpt-3.5-turbo到gpt-5系列套件会用describe.each对每个模型分别执行能力用例invalidModel声明为provider.chat(no-such-model)错误处理用例据此断言APICallError且错误信息匹配/The model .* does not exist/timeout: 30000覆盖默认 10 秒超时为慢模型留出余量。从 e2e 用例到基础脚本的映射README 还点明了一个重要设计大多数 e2e 用例都能在src下对应子目录的基础示例脚本中找到某种形式的等价实现。从目录结构看确实如此——例如e2e 的文本生成/流式/结构化输出用例对应src/generate-text/openai/下的basic.ts、output-object.ts、output-json.ts、output-array.ts等脚本e2e 的图片输入用例对应src/generate-text/openai/下的image-url.ts、image-base64.ts、image-data-tagged.ts等脚本e2e 的 Embedding 用例对应src/embed/*、src/embed-many/*脚本。这种「脚本 测试」双轨结构的好处是基础脚本适合快速迭代验证改一行、跑一次、看输出e2e 测试适合回归式冒烟一条命令覆盖全部能力。开发者可以先跑脚本确认某个新 Provider 能力可用再把它固化为 e2e 用例长期守护。排错与注意事项结合 README 说明与 lib/run.ts 的实现实际使用中需要注意e2e 失败先查外部因素配额不足、Provider 侧接口变更、密钥缺失或过期是最高频的失败原因并不一定代表 SDK 或测试本身有问题密钥配置不全脚本依赖.env中的 API Key缺 key 会直接导致调用失败使用哪些 Provider 就配置哪些变量先在仓库根目录pnpm install pnpm build跳过构建直接跑示例会因 workspace 包未编译而报错善用错误输出APICallError会自动打印请求体与响应体配合FAIL_ON_ERROR1可以让示例脚本在 CI 脚本化场景中以失败退出码暴露问题按需切片e2e 支持按文件test:file与按名称-t过滤不必每次都跑全量。总结examples/ai-functions是 AI SDK 仓库中一块「高频试验田」基础示例脚本提供了数十个 Provider × 数十种ai函数的可运行样本端到端测试套件则通过能力矩阵机制CapabilitydescribeIfCapabilitycreateFeatureTestSuite实现了「一份套件、多 Provider 复用」的冒烟测试模式。无论你是要验证某个 Provider 的新能力、排查某个函数的异常输出还是为仓库新增 Provider 做回归保障都可以按照「配置.env→ 仓库根目录构建 →pnpm tsx跑脚本 /pnpm run test:e2e:all跑测试」的路径快速上手。【免费下载链接】aiThe AI Toolkit for TypeScript. From the creators of Next.js, the AI SDK is a free open-source library for building AI-powered applications and agents项目地址: https://gitcode.com/GitHub_Trending/ai/ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
