big-AGI 三大 AI 提供商 API 能力对比Anthropic / Gemini / OpenAI 功能矩阵全解析【免费下载链接】big-AGIAI suite powered by state-of-the-art models and providing advanced AI/AGI functions. Includes AI personas, AGI functions, world-class Beam multi-model chats, text-to-image, voice, response streaming, code highlighting and execution, PDF import, presets for developers, much more. Deploy on-prem or in the cloud.项目地址: https://gitcode.com/GitHub_Trending/bi/big-AGI本指南基于 big-AGI 仓库内维护的 2024-AI-APIs-Comparison.md数据截止 2024-07-09系统对比 Anthropic、Gemini、OpenAI 三大 AI API 在消息结构、多模态支持、图像处理、函数调用Function Calling、生成参数、流式传输、用量统计与安全合规等维度的完整差异。文中同时结合 big-AGI 的 AIX dispatch server 源码wiretypes 与适配器实现进行交叉印证帮助你在选择模型、设计兼容层或排查多提供商接入问题时快速定位各家 API 的边界与坑点。为什么需要这份对比AIX dispatch server 的统一接入背景big-AGI 的 AI 能力接入层是AIX见 kb/modules/AIX.md一个基于 tRPC 构建的客户端/服务器库负责把上层对话请求统一派发到不同 AI 提供商并将各家差异化的流式/非流式响应归一化为统一的AixWire_Particles粒子流回传给前端。在其服务端目录 src/modules/aix/server/dispatch/ 下可以清楚看到一协议一适配器一解析器的分层设计适配器adapters把统一请求转换为各家协议包括 anthropic.messageCreate.ts、gemini.generateContent.ts、openai.chatCompletions.ts、openai.responsesCreate.ts 等wiretypes协议类型定义用 Zod schema 精确建模每家上游协议的请求/响应结构见 src/modules/aix/server/dispatch/wiretypes/解析器parsers把各家流式事件解析回统一粒子格式派发器dispatchchatGenerate.dispatch.ts 按提供商组装出完整请求管线。因此理解本文的对比表就等于理解了 AIX 适配器层为何要为各家写方言代码以及协议差异最终如何在 wiretypes 中被建模。消息结构对比角色模型是第一个分水岭Feature CategorySpecific FeatureAnthropicGeminiOpenAIMessage StructureRole typesuser, assistantuser, modeluser, assistant, system, toolNamed participantsNoNoYesContent arrayYesYesYes三家在**角色Role**设计上就存在根本分歧AnthropicMessages API 只有user/assistant两种角色系统提示通过顶层system参数传入而不是消息数组中的角色。在 anthropic.wiretypes.ts 的AnthropicWire_API_Message_Create.Request_schema中可看到system: z.array(TextBlock_schema)并且源码注释明确写道There is no system role for input messages in the Messages API且当前实现强制 system 使用文本块数组表示// NOTE: we force ourselves to always write the array representation。该文件还特意把system角色从输入消息枚举中注释掉以保持与其它提供商在高层 AIX 部件上的统一。Gemini对话角色是user/model系统指令通过systemInstructionparts 数组传递gemini.generateContent.ts 中将其构建为systemInstruction: { parts: [...] }。OpenAI角色最丰富除user/assistant外还有独立的system角色、tool角色用于回填函数调用结果并支持命名参与者nameopenai.wiretypes.ts 中OpenAIWire_Messages明确定义了SystemMessage_schema、UserMessage_schema、AssistantMessage_schema且注释指出 2024-12-17 起还引入了developer角色o 系列推理模型用developer替代system。对兼容层设计的影响任何统一消息模型都必须支持系统指令、多角色、命名参与者、内容数组这四类能力才能无损映射三家协议。AIX 正是通过统一内部格式AixMessages_SystemMessageAixMessages_ChatMessage后由各家适配器做方言化转换来解决这一问题的。内容类型与多模态支持Feature CategorySpecific FeatureAnthropicGeminiOpenAIContent Types and Multimodal SupportText generationYesYesYesImage understandingYesYesYesAudio processingNoYesNoVideo processingNoYesNo三家的文本生成与图像理解都是标配真正的差异化在于Gemini 是唯一原生支持音频与视频处理的 API。这一结论在 gemini.wiretypes.ts 的ianaStandardMimeType_schema中得到完整佐证——该枚举同时覆盖了图片image/png、image/jpeg、image/webp、image/heic、image/heif、音频audio/wav、audio/mp3、audio/aiff、audio/aac、audio/ogg、audio/flac、视频video/mp4、video/mpeg、video/mov、video/avi、video/x-flv、video/mpg、video/webm、video/wmv、video/3gpp以及大量文本/文档格式text/plain、text/html、text/csv、application/json、text/x-python等。对应的Gemini 的内容部件Content Part体系也最丰富InlineDataPart_schema内联 base64 多模态数据inlineData.mimeType dataFileDataPart_schema文件引用fileData.fileUri支持 YouTube URL、直链或 Files API URI并支持videoMetadatastartOffset/endOffset/fps做视频切片与帧采样ExecutableCodePart_schema/CodeExecutionResultPart_schema代码执行输入/输出部件。而 OpenAI 侧openai.wiretypes.ts 的ContentPart_schema判别联合只包含text、image_url、input_audio2024-10-17 起的实验性音频输入仅 wav/mp3以及 OpenRouter 扩展的video_url——音频/视频远未达到 Gemini 的系统级支持程度。图像处理细节对比Feature CategorySpecific FeatureAnthropicGeminiOpenAIImage HandlingSupported formatsJPEG, PNG, GIF, WebPJPEG, PNG, WebP, HEIC, HEIFPNG, JPEG, WebP, non-animated GIFMax image size5MB per image(20MB per prompt)20MB per imageImage detail levelN/AN/ALow, high, autoImage resolutionmax: 1568x1568min: 768x768, max: 3072x3072min: 512x512, max: 2048 x 2048Token calculation for images(width * height)/750; max 1,600258 tokens85 170 * {patches}Image retentionDeleted after processingNot specifiedDeleted after processing图像输入侧的差异要点格式与尺寸Anthropic 支持 JPEG/PNG/GIF/WebP单图上限 5MB、最大分辨率 1568x1568tokens 按(宽 × 高)/750计算、单图封顶 1600 tokensGemini 额外支持 HEIC/HEIF单次提示上限 20MB分辨率范围 768x7683072x3072图像固定折算约 258 tokensOpenAI 支持 PNG/JPEG/WebP/非动图 GIF单图 20MB分辨率范围 512x5122048x2048tokens 按85 170 × {patches}计算。唯一提供图像细节级别detail控制的 API 是 OpenAIlow/high/auto三档。这一点在 openai.wiretypes.ts 的ImageContentPart_schema中落地为detail: z.enum([auto, low, high]).optional()其构造器ImageContentPart(url, detail?)可直接传档位。big-AGI 的 OpenAI Chat 适配器甚至默认强制detail high见 openai.chatCompletions.ts 中的hotFixForceImageContentPartOpenAIDetail: high以保证图像理解质量。图像保留策略Anthropic 与 OpenAI 均声明处理后即删除Gemini 未明确说明——涉及敏感图像数据时需注意这一合规差异。音频与视频处理Feature CategorySpecific FeatureAnthropicGeminiOpenAIAudio and Video HandlingAudio formatsN/AWAV, MP3, AIFF, AAC, OGG, FLACN/AVideo formatsN/AMP4, MPEG, MOV, AVI, MPG, WebM, WMV, 3GPPN/A本维度几乎是一边倒音频与视频处理目前只有 Gemini 支持Anthropic 与 OpenAI 均为 N/A。音频格式覆盖 WAV、MP3、AIFF、AAC、OGG、FLAC视频格式覆盖 MP4、MPEG、MOV、AVI、MPG、WebM、WMV、3GPP——与上文 Gemini wiretypes 中的 MIME 枚举一一对应。在 big-AGI 中音频类能力语音输入/输出、语音通话等正是通过 speex 与 asrx 模块对接各提供商而 Gemini 侧还专门实现了音频处理工具链 gemini.audioutils.ts含 PCM 转 WAV 等工具用于处理流式音频数据。若你的业务需要音视频直读Gemini 目前是唯一原生选项。系统指令与工具使用Tool UseFeature CategorySpecific FeatureAnthropicGeminiOpenAISystem Instructions and Tool UseSystem instructionsYes (array of text blocks)Yes (parts array)Yes (as system message)三家均支持系统指令但承载形态不同Anthropic 用文本块数组顶层system参数可带cache_control做提示词缓存断点Gemini 用systemInstruction.parts数组OpenAI 用独立的system消息角色。big-AGI 在把 AIX 统一格式的系统消息方言化时也体现了各家约束Anthropic 适配器会把 doc 部件近似转成文本块approxDocPart_To_String并对meta_cache_control部件调用blockSetCacheControl(..., ephemeral)设置缓存断点同时强制禁止图像出现在系统消息中images have to be in user messages, not in system messageGemini 适配器同样拒绝系统消息中的内联图像并直接忽略meta_cache_control缓存断点// ignore this breakpoint hint - Anthropic only说明提示词缓存是 Anthropic 体系特有的能力OpenAI 适配器则通过 system 消息承载系统提示并在 OpenRouter 方言下把缓存断点映射为文本块尾部的cache_control字段OpenAI wiretypes 的TextContentPart_schema中已为 OpenRouter 方言预留该字段。函数调用Function Calling深度对比Feature CategorySpecific FeatureAnthropicGeminiOpenAIFunction/Tool HandlingParallel tool callsNoNoYesTool DeclarationDefined intoolsarrayDefined intoolsarrayDefined intoolsarrayFC name restrictionsYesYes (max 63 chars)Yes (max 64 chars)FC declarationname, description, input_schemaname, description, parametersname, description, parametersFC options structureJSON Schema for inputObject with propertiesJSON Schema for parametersFC Force invocationViatool_choiceparameterViatoolConfigparameterViatool_choiceparameterFC Model invocationModel generates atool_useblock with predicted parametersGenerates afunctionCallpart with predicted parametersGenerates a message.tool_callsitem with predicted argumentsFC ExecutionClient-sideClient-sideClient-sideFC Result injectionClient appends ausermessage with atool_resultcontent blockClient appends afunctionmessage withfunctionResponsepartClient sends a newtoolmessage withtool_call_idandcontentBuilt-in Code executionNoYesNoTool use with visionYesYesYes函数调用是本文对比表中最值得展开的一行因为它直接决定了同一套工具调用逻辑要写多少种方言。AIX 的 wiretypes 精确复刻了这三种方言1. 声明Declaration三家都在tools数组里声明工具但 schema 字段名不同Anthropic 用input_schemaJSON SchemaGemini 与 OpenAI 用parametersGemini 是Object with propertiesOpenAI 是 JSON Schema。名称限制上 Gemini 为 63 字符、OpenAI 为 64 字符。在 anthropic.wiretypes.ts 的AnthropicWire_Tools命名空间中_CustomToolDefinition_schema完整定义了name、description、input_schematype: objectpropertiesrequired并额外支持cache_control、defer_loading延迟加载、allowed_callers程序化调用限制、strictStructured Outputs 严格模式、input_examples示例调用等进阶字段。2. 模型调用Invocation模型发起工具调用的载体截然不同Anthropic模型在回复内容块中生成tool_use块含id、name、input预测参数。其ToolUseBlock_schema要求input是字典对象big-AGI 甚至为此写了一个 hotfix——把null/空串输入替换为{}因为 Anthropic 会以Input should be a valid dictionary拒绝非法输入见ToolUseBlock()构造器注释Gemini模型生成functionCall部件nameargs对应 gemini.wiretypes.ts 的FunctionCallPart_schemaOpenAI模型在消息的tool_calls数组中产出function调用项idfunction.namefunction.arguments字符串对应 openai.wiretypes.ts 的PredictedFunctionCall_schema。注意OpenAI 的arguments是JSON 字符串而非对象解析时必须自行JSON.parse且官方注释提醒模型不总是生成合法 JSON可能臆造 schema 之外的参数调用前必须校验。3. 结果回填Result Injection三家回填工具执行结果的方式差异最大是兼容层最容易写错的点Anthropic客户端追加一条user角色消息内含tool_result内容块tool_use_id对应调用 IDcontent为结果文本或内容块数组is_error标记错误——见ToolResultBlock_I_schemaGemini客户端追加一条function角色消息内含functionResponse部件id/name/response。有趣的是big-AGI 源码注释引用了 Google 文档原话吐槽role should only be user or model. FIXME GOOGLE!并特别指出functionResponse的parts字段只支持inlineData图片/音频文本必须走response字段——这是多模态函数响应的一个重要细节OpenAI客户端发送一条新的tool角色消息携带tool_call_id与content以及可选的name。4. 并行调用与代码执行并行工具调用Parallel tool calls2024-07-09 时间点只有 OpenAI 原生支持。不过这是 AIX 层面的已知演进点kb 中 AIX.md 的提供商支持矩阵显示后续 Anthropicdisable_parallel_tool_use字段已出现在 wiretypes 中与 Gemini 均已支持并行调用内置代码执行Built-in Code execution只有 Gemini 提供其ExecutableCodePart_schema定义了language: PYTHONPython 3.10附 numpy/simpy与code字段对应CodeExecutionResultPart_schema输出。big-AGI 的 kb/modules/AIX.md 支持矩阵中 Gemini 一栏也明确标注 Code ex.: ✅。生成配置参数对比Feature CategorySpecific FeatureAnthropicGeminiOpenAIGeneration ConfigurationtemperatureYesYesYesmax_tokensYesYesYesstop_sequencesYesYesYestop_kYesYesNotop_pYesYesYesseedNoNoYesMultiple candidatesNoNoYes (with n parameter, breaks streaming?)生成参数矩阵中三个关键不对称点top_kAnthropic 与 Gemini 支持OpenAI 不支持。Gemini 适配器中generationConfig预留了topK字段默认不发送并且实现了一个值得注意的降级逻辑当设置了topP时删除 temperatureTop-P instead of temperature见 gemini.generateContent.tsseed随机种子只有 OpenAI 支持用于复现采样结果多候选Multiple candidates只有 OpenAI 支持n参数但对比表明确提示可能破坏流式传输breaks streaming?。big-AGI 的 OpenAI Chat 适配器直接选择不支持 n1hotFixOnlySupportN1 true注释整个下游生态只支持 N1多候选无实际消费方。另外注意一个 2024-07-09 之后的重要演进OpenAI 已把max_tokens弃用、改为max_completion_tokens该文件头注释记录了 2024-09-12 o1 的变更big-AGI 适配器对 OpenAI/Azure 方言会自动使用max_completion_tokens字段。流式传输与响应结构Feature CategorySpecific FeatureAnthropicGeminiOpenAIStreaming and Response StructureStreaming supportYesYesYesStreaming initiationstreamtruestreamGenerateContent pathstreamtrueStreaming event typesMultiple specific typesNot specifiedSingle delta typeResponse containercontent (array)candidates (array)choices (array)三家都支持流式但流式事件协议截然不同Anthropic流式事件类型最丰富message_start、content_block_start、content_block_delta、content_block_stop、message_delta、message_stop、ping等且各事件携带结构化元数据。AIX 为 Anthropic 专门实现了 anthropic.parser.ts逐事件消费并转换成统一粒子其 wiretypes 甚至对未知/未来内容块类型做了弹性解析ContentBlockOutputResilient_schemaisKnownContentBlockOutput保证未知块不会杀死流。Gemini通过streamGenerateContent路径流式返回响应容器为candidates数组。OpenAI流式协议是单一 delta 类型的增量块chunk-based。openai.parser.ts 头注释精确描述了其消息架构每个 chunk 含choices数组通常单项delta携带增量——delta.content是文本增量delta.tool_calls是函数调用增量首块含完整 id/name 与空参数后续块只给参数增量文本流结束由sse:[DONE]事件标记且不可依赖finish_reason。响应容器差异Anthropic 用content数组Gemini 用candidates数组OpenAI 用choices数组。所有适配器/解析器的核心工作就是把这三种容器归一化。用量统计与错误处理Feature CategorySpecific FeatureAnthropicGeminiOpenAIUsage Metrics and Error HandlingToken countsYesYesYesDetailed token breakdowninput, outputprompt, cached, candidates, totalprompt, completion, totalUsage in streamNoNoOptionalError handling in responseNot specifiedNot specifiedYes (undocumented)Error handling in streamNot specifiedNot specifiedYes (undocumented)三家都返回 token 统计但口径不同Anthropic 拆分为 input/outputGemini 拆分为 prompt/cached/candidates/total注意 cached——对应其语义缓存能力OpenAI 拆分为 prompt/completion/total。流式过程中返回 usage 目前只有 OpenAI 可选支持stream_options: { include_usage: true }big-AGI 的 OpenAI 适配器在流式请求中始终开启该选项见 openai.chatCompletions.ts。错误处理方面对比表标注 OpenAI 在响应与流式中均有未文档化的错误处理机制AIX 服务端为不同提供商实现了差异化的容错timeout/retry 机制见 AIX.md 的时序图以及 chatGenerate.operation-retry.ts 等文件并在 OpenAI 侧专门实现了 openai.error-severity.ts 来做错误严重级别分类。高级特性JSON 模式、语义缓存、前缀填充Feature CategorySpecific FeatureAnthropicGeminiOpenAIAdvanced FeaturesJSON modePartial (via structured prompts)Yes (responseMimeType)YesOutput consistency techniquesYes (multiple methods)Not specifiedNot specifiedLogprobsNoNoYes (disabled in schema)System fingerprintNoNoYesSemantic cachingNoYesNoAssistant prefillYesNoNoPreferred formattingXML tags, JSONNot specifiedMarkdown高级特性矩阵的实战要点JSON 模式OpenAI 与 Gemini 是原生支持——Gemini 通过generationConfig.responseMimeType application/json可附带responseSchema做结构化约束OpenAI 通过response_format。big-AGI 的 Gemini 适配器在开启strictJsonOutput时会同时设置responseMimeType与responseSchema见 gemini.generateContent.tsOpenAI 适配器则设置response_format。Anthropic 只有部分支持——需通过结构化提示词structured prompts约束输出没有专门的 JSON mode 参数语义缓存Semantic caching只有 Gemini 支持对应其 usage 中的 cached tokensAssistant prefill助手前缀填充只有 Anthropic 支持——利用最后一条消息使用 assistant 角色时响应会从该消息内容继续的特性来约束模型输出方向。AIX 的 Anthropic wiretypes 注释明确记录了这一用法If the final message uses the assistant role, the response content will continue immediately from the content in that messageLogprobs 与 System fingerprint仅 OpenAI 具备但 logprobs 在 big-AGI 的 schema 中被禁用对比表标注 disabled in schema且 openai.wiretypes.ts 头注释明确写有 ignoring logprobs。安全与合规Feature CategorySpecific FeatureAnthropicGeminiOpenAISafety and ComplianceSafety settings in requestStop sequencesDetailed category-basedModeration APISafety feedback in responseYesYesNot specified安全策略是三家理念差异最大的维度Anthropic请求侧安全机制依赖停止序列stop_sequences响应侧返回安全反馈Gemini提供细粒度的按类别category-based安全设置。big-AGI 的 Gemini 适配器会为每个请求注入safetySettings阈值由GeminiWire_Safety.HarmBlockThreshold控制见 gemini.generateContent.ts 与 gemini.wiretypes.ts 中的GeminiWire_Safety命名空间OpenAI依赖独立的Moderation API做内容审核响应侧未明确说明安全反馈字段。从对比表到源码如何用这份矩阵指导接入实践综合整张对比表与 big-AGI 源码可以沉淀出几条可直接落地的工程结论统一消息模型是前提三家角色体系user/assistant、user/model、user/assistant/system/tool与系统指令承载方式顶层参数/parts 数组/system 消息都不同必须先有统一的内部消息格式再为每家写方言适配器——这正是 AIX 在 api/aix.wiretypes.ts 中建模AixMessages_*、在 chatGenerate/adapters/ 下按协议实现转换的原因多模态选型看 Gemini音频、视频、HEIC/HEIF、内置代码执行、细粒度安全设置、语义缓存都是 Gemini 独占或显著领先的能力OpenAI 的优势在并行工具调用、n参数、seed、原生 JSON 模式与 Moderation APIAnthropic 的特色是 assistant prefill、基于文本块的缓存控制cache_control: ephemeral与结构化提示词工具调用回填是最高危代码路径同样执行一个函数Anthropic 追加user消息 tool_result块Gemini 追加function消息 functionResponse部件OpenAI 发送tool消息 tool_call_id且 OpenAI 的arguments是 JSON 字符串、Gemini 的文本结果必须走response字段而非parts——任何一处写错都会导致多轮对话或工具循环失效流式协议按家适配Anthropic 是多事件类型协议、Gemini 走streamGenerateContent、OpenAI 是单 delta 类型 sse:[DONE]终止统一解析层需要分别实现 parser如 anthropic.parser.ts、gemini.parser.ts、openai.parser.ts并通过 stream.demuxers.ts 解复用不同流格式对比数据是时间快照本表数据截止 2024-07-09而 big-AGI 的 wiretypes 持续在同步上游演进如 OpenAI 的max_completion_tokens、developer角色Anthropic 的并行工具调用、Structured Outputs、各类服务端工具等接入时务必以目标 API 当前文档与仓库中最新 wiretypes 为准。【免费下载链接】big-AGIAI suite powered by state-of-the-art models and providing advanced AI/AGI functions. Includes AI personas, AGI functions, world-class Beam multi-model chats, text-to-image, voice, response streaming, code highlighting and execution, PDF import, presets for developers, much more. Deploy on-prem or in the cloud.项目地址: https://gitcode.com/GitHub_Trending/bi/big-AGI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 19:31:33 · 阅读 1.2k big-AGI 三大 AI 提供商 API 能力对比：Anthropic / Gemini / OpenAI 功能矩阵全解析
big-AGI 三大 AI 提供商 API 能力对比Anthropic / Gemini / OpenAI 功能矩阵全解析【免费下载链接】big-AGIAI suite powered by state-of-the-art models and providing advanced AI/AGI functions. Includes AI personas, AGI functions, world-class Beam multi-model chats, text-to-image, voice, response streaming, code highlighting and execution, PDF import, presets for developers, much more. Deploy on-prem or in the cloud.项目地址: https://gitcode.com/GitHub_Trending/bi/big-AGI本指南基于 big-AGI 仓库内维护的 2024-AI-APIs-Comparison.md数据截止 2024-07-09系统对比 Anthropic、Gemini、OpenAI 三大 AI API 在消息结构、多模态支持、图像处理、函数调用Function Calling、生成参数、流式传输、用量统计与安全合规等维度的完整差异。文中同时结合 big-AGI 的 AIX dispatch server 源码wiretypes 与适配器实现进行交叉印证帮助你在选择模型、设计兼容层或排查多提供商接入问题时快速定位各家 API 的边界与坑点。为什么需要这份对比AIX dispatch server 的统一接入背景big-AGI 的 AI 能力接入层是AIX见 kb/modules/AIX.md一个基于 tRPC 构建的客户端/服务器库负责把上层对话请求统一派发到不同 AI 提供商并将各家差异化的流式/非流式响应归一化为统一的AixWire_Particles粒子流回传给前端。在其服务端目录 src/modules/aix/server/dispatch/ 下可以清楚看到一协议一适配器一解析器的分层设计适配器adapters把统一请求转换为各家协议包括 anthropic.messageCreate.ts、gemini.generateContent.ts、openai.chatCompletions.ts、openai.responsesCreate.ts 等wiretypes协议类型定义用 Zod schema 精确建模每家上游协议的请求/响应结构见 src/modules/aix/server/dispatch/wiretypes/解析器parsers把各家流式事件解析回统一粒子格式派发器dispatchchatGenerate.dispatch.ts 按提供商组装出完整请求管线。因此理解本文的对比表就等于理解了 AIX 适配器层为何要为各家写方言代码以及协议差异最终如何在 wiretypes 中被建模。消息结构对比角色模型是第一个分水岭Feature CategorySpecific FeatureAnthropicGeminiOpenAIMessage StructureRole typesuser, assistantuser, modeluser, assistant, system, toolNamed participantsNoNoYesContent arrayYesYesYes三家在**角色Role**设计上就存在根本分歧AnthropicMessages API 只有user/assistant两种角色系统提示通过顶层system参数传入而不是消息数组中的角色。在 anthropic.wiretypes.ts 的AnthropicWire_API_Message_Create.Request_schema中可看到system: z.array(TextBlock_schema)并且源码注释明确写道There is no system role for input messages in the Messages API且当前实现强制 system 使用文本块数组表示// NOTE: we force ourselves to always write the array representation。该文件还特意把system角色从输入消息枚举中注释掉以保持与其它提供商在高层 AIX 部件上的统一。Gemini对话角色是user/model系统指令通过systemInstructionparts 数组传递gemini.generateContent.ts 中将其构建为systemInstruction: { parts: [...] }。OpenAI角色最丰富除user/assistant外还有独立的system角色、tool角色用于回填函数调用结果并支持命名参与者nameopenai.wiretypes.ts 中OpenAIWire_Messages明确定义了SystemMessage_schema、UserMessage_schema、AssistantMessage_schema且注释指出 2024-12-17 起还引入了developer角色o 系列推理模型用developer替代system。对兼容层设计的影响任何统一消息模型都必须支持系统指令、多角色、命名参与者、内容数组这四类能力才能无损映射三家协议。AIX 正是通过统一内部格式AixMessages_SystemMessageAixMessages_ChatMessage后由各家适配器做方言化转换来解决这一问题的。内容类型与多模态支持Feature CategorySpecific FeatureAnthropicGeminiOpenAIContent Types and Multimodal SupportText generationYesYesYesImage understandingYesYesYesAudio processingNoYesNoVideo processingNoYesNo三家的文本生成与图像理解都是标配真正的差异化在于Gemini 是唯一原生支持音频与视频处理的 API。这一结论在 gemini.wiretypes.ts 的ianaStandardMimeType_schema中得到完整佐证——该枚举同时覆盖了图片image/png、image/jpeg、image/webp、image/heic、image/heif、音频audio/wav、audio/mp3、audio/aiff、audio/aac、audio/ogg、audio/flac、视频video/mp4、video/mpeg、video/mov、video/avi、video/x-flv、video/mpg、video/webm、video/wmv、video/3gpp以及大量文本/文档格式text/plain、text/html、text/csv、application/json、text/x-python等。对应的Gemini 的内容部件Content Part体系也最丰富InlineDataPart_schema内联 base64 多模态数据inlineData.mimeType dataFileDataPart_schema文件引用fileData.fileUri支持 YouTube URL、直链或 Files API URI并支持videoMetadatastartOffset/endOffset/fps做视频切片与帧采样ExecutableCodePart_schema/CodeExecutionResultPart_schema代码执行输入/输出部件。而 OpenAI 侧openai.wiretypes.ts 的ContentPart_schema判别联合只包含text、image_url、input_audio2024-10-17 起的实验性音频输入仅 wav/mp3以及 OpenRouter 扩展的video_url——音频/视频远未达到 Gemini 的系统级支持程度。图像处理细节对比Feature CategorySpecific FeatureAnthropicGeminiOpenAIImage HandlingSupported formatsJPEG, PNG, GIF, WebPJPEG, PNG, WebP, HEIC, HEIFPNG, JPEG, WebP, non-animated GIFMax image size5MB per image(20MB per prompt)20MB per imageImage detail levelN/AN/ALow, high, autoImage resolutionmax: 1568x1568min: 768x768, max: 3072x3072min: 512x512, max: 2048 x 2048Token calculation for images(width * height)/750; max 1,600258 tokens85 170 * {patches}Image retentionDeleted after processingNot specifiedDeleted after processing图像输入侧的差异要点格式与尺寸Anthropic 支持 JPEG/PNG/GIF/WebP单图上限 5MB、最大分辨率 1568x1568tokens 按(宽 × 高)/750计算、单图封顶 1600 tokensGemini 额外支持 HEIC/HEIF单次提示上限 20MB分辨率范围 768x7683072x3072图像固定折算约 258 tokensOpenAI 支持 PNG/JPEG/WebP/非动图 GIF单图 20MB分辨率范围 512x5122048x2048tokens 按85 170 × {patches}计算。唯一提供图像细节级别detail控制的 API 是 OpenAIlow/high/auto三档。这一点在 openai.wiretypes.ts 的ImageContentPart_schema中落地为detail: z.enum([auto, low, high]).optional()其构造器ImageContentPart(url, detail?)可直接传档位。big-AGI 的 OpenAI Chat 适配器甚至默认强制detail high见 openai.chatCompletions.ts 中的hotFixForceImageContentPartOpenAIDetail: high以保证图像理解质量。图像保留策略Anthropic 与 OpenAI 均声明处理后即删除Gemini 未明确说明——涉及敏感图像数据时需注意这一合规差异。音频与视频处理Feature CategorySpecific FeatureAnthropicGeminiOpenAIAudio and Video HandlingAudio formatsN/AWAV, MP3, AIFF, AAC, OGG, FLACN/AVideo formatsN/AMP4, MPEG, MOV, AVI, MPG, WebM, WMV, 3GPPN/A本维度几乎是一边倒音频与视频处理目前只有 Gemini 支持Anthropic 与 OpenAI 均为 N/A。音频格式覆盖 WAV、MP3、AIFF、AAC、OGG、FLAC视频格式覆盖 MP4、MPEG、MOV、AVI、MPG、WebM、WMV、3GPP——与上文 Gemini wiretypes 中的 MIME 枚举一一对应。在 big-AGI 中音频类能力语音输入/输出、语音通话等正是通过 speex 与 asrx 模块对接各提供商而 Gemini 侧还专门实现了音频处理工具链 gemini.audioutils.ts含 PCM 转 WAV 等工具用于处理流式音频数据。若你的业务需要音视频直读Gemini 目前是唯一原生选项。系统指令与工具使用Tool UseFeature CategorySpecific FeatureAnthropicGeminiOpenAISystem Instructions and Tool UseSystem instructionsYes (array of text blocks)Yes (parts array)Yes (as system message)三家均支持系统指令但承载形态不同Anthropic 用文本块数组顶层system参数可带cache_control做提示词缓存断点Gemini 用systemInstruction.parts数组OpenAI 用独立的system消息角色。big-AGI 在把 AIX 统一格式的系统消息方言化时也体现了各家约束Anthropic 适配器会把 doc 部件近似转成文本块approxDocPart_To_String并对meta_cache_control部件调用blockSetCacheControl(..., ephemeral)设置缓存断点同时强制禁止图像出现在系统消息中images have to be in user messages, not in system messageGemini 适配器同样拒绝系统消息中的内联图像并直接忽略meta_cache_control缓存断点// ignore this breakpoint hint - Anthropic only说明提示词缓存是 Anthropic 体系特有的能力OpenAI 适配器则通过 system 消息承载系统提示并在 OpenRouter 方言下把缓存断点映射为文本块尾部的cache_control字段OpenAI wiretypes 的TextContentPart_schema中已为 OpenRouter 方言预留该字段。函数调用Function Calling深度对比Feature CategorySpecific FeatureAnthropicGeminiOpenAIFunction/Tool HandlingParallel tool callsNoNoYesTool DeclarationDefined intoolsarrayDefined intoolsarrayDefined intoolsarrayFC name restrictionsYesYes (max 63 chars)Yes (max 64 chars)FC declarationname, description, input_schemaname, description, parametersname, description, parametersFC options structureJSON Schema for inputObject with propertiesJSON Schema for parametersFC Force invocationViatool_choiceparameterViatoolConfigparameterViatool_choiceparameterFC Model invocationModel generates atool_useblock with predicted parametersGenerates afunctionCallpart with predicted parametersGenerates a message.tool_callsitem with predicted argumentsFC ExecutionClient-sideClient-sideClient-sideFC Result injectionClient appends ausermessage with atool_resultcontent blockClient appends afunctionmessage withfunctionResponsepartClient sends a newtoolmessage withtool_call_idandcontentBuilt-in Code executionNoYesNoTool use with visionYesYesYes函数调用是本文对比表中最值得展开的一行因为它直接决定了同一套工具调用逻辑要写多少种方言。AIX 的 wiretypes 精确复刻了这三种方言1. 声明Declaration三家都在tools数组里声明工具但 schema 字段名不同Anthropic 用input_schemaJSON SchemaGemini 与 OpenAI 用parametersGemini 是Object with propertiesOpenAI 是 JSON Schema。名称限制上 Gemini 为 63 字符、OpenAI 为 64 字符。在 anthropic.wiretypes.ts 的AnthropicWire_Tools命名空间中_CustomToolDefinition_schema完整定义了name、description、input_schematype: objectpropertiesrequired并额外支持cache_control、defer_loading延迟加载、allowed_callers程序化调用限制、strictStructured Outputs 严格模式、input_examples示例调用等进阶字段。2. 模型调用Invocation模型发起工具调用的载体截然不同Anthropic模型在回复内容块中生成tool_use块含id、name、input预测参数。其ToolUseBlock_schema要求input是字典对象big-AGI 甚至为此写了一个 hotfix——把null/空串输入替换为{}因为 Anthropic 会以Input should be a valid dictionary拒绝非法输入见ToolUseBlock()构造器注释Gemini模型生成functionCall部件nameargs对应 gemini.wiretypes.ts 的FunctionCallPart_schemaOpenAI模型在消息的tool_calls数组中产出function调用项idfunction.namefunction.arguments字符串对应 openai.wiretypes.ts 的PredictedFunctionCall_schema。注意OpenAI 的arguments是JSON 字符串而非对象解析时必须自行JSON.parse且官方注释提醒模型不总是生成合法 JSON可能臆造 schema 之外的参数调用前必须校验。3. 结果回填Result Injection三家回填工具执行结果的方式差异最大是兼容层最容易写错的点Anthropic客户端追加一条user角色消息内含tool_result内容块tool_use_id对应调用 IDcontent为结果文本或内容块数组is_error标记错误——见ToolResultBlock_I_schemaGemini客户端追加一条function角色消息内含functionResponse部件id/name/response。有趣的是big-AGI 源码注释引用了 Google 文档原话吐槽role should only be user or model. FIXME GOOGLE!并特别指出functionResponse的parts字段只支持inlineData图片/音频文本必须走response字段——这是多模态函数响应的一个重要细节OpenAI客户端发送一条新的tool角色消息携带tool_call_id与content以及可选的name。4. 并行调用与代码执行并行工具调用Parallel tool calls2024-07-09 时间点只有 OpenAI 原生支持。不过这是 AIX 层面的已知演进点kb 中 AIX.md 的提供商支持矩阵显示后续 Anthropicdisable_parallel_tool_use字段已出现在 wiretypes 中与 Gemini 均已支持并行调用内置代码执行Built-in Code execution只有 Gemini 提供其ExecutableCodePart_schema定义了language: PYTHONPython 3.10附 numpy/simpy与code字段对应CodeExecutionResultPart_schema输出。big-AGI 的 kb/modules/AIX.md 支持矩阵中 Gemini 一栏也明确标注 Code ex.: ✅。生成配置参数对比Feature CategorySpecific FeatureAnthropicGeminiOpenAIGeneration ConfigurationtemperatureYesYesYesmax_tokensYesYesYesstop_sequencesYesYesYestop_kYesYesNotop_pYesYesYesseedNoNoYesMultiple candidatesNoNoYes (with n parameter, breaks streaming?)生成参数矩阵中三个关键不对称点top_kAnthropic 与 Gemini 支持OpenAI 不支持。Gemini 适配器中generationConfig预留了topK字段默认不发送并且实现了一个值得注意的降级逻辑当设置了topP时删除 temperatureTop-P instead of temperature见 gemini.generateContent.tsseed随机种子只有 OpenAI 支持用于复现采样结果多候选Multiple candidates只有 OpenAI 支持n参数但对比表明确提示可能破坏流式传输breaks streaming?。big-AGI 的 OpenAI Chat 适配器直接选择不支持 n1hotFixOnlySupportN1 true注释整个下游生态只支持 N1多候选无实际消费方。另外注意一个 2024-07-09 之后的重要演进OpenAI 已把max_tokens弃用、改为max_completion_tokens该文件头注释记录了 2024-09-12 o1 的变更big-AGI 适配器对 OpenAI/Azure 方言会自动使用max_completion_tokens字段。流式传输与响应结构Feature CategorySpecific FeatureAnthropicGeminiOpenAIStreaming and Response StructureStreaming supportYesYesYesStreaming initiationstreamtruestreamGenerateContent pathstreamtrueStreaming event typesMultiple specific typesNot specifiedSingle delta typeResponse containercontent (array)candidates (array)choices (array)三家都支持流式但流式事件协议截然不同Anthropic流式事件类型最丰富message_start、content_block_start、content_block_delta、content_block_stop、message_delta、message_stop、ping等且各事件携带结构化元数据。AIX 为 Anthropic 专门实现了 anthropic.parser.ts逐事件消费并转换成统一粒子其 wiretypes 甚至对未知/未来内容块类型做了弹性解析ContentBlockOutputResilient_schemaisKnownContentBlockOutput保证未知块不会杀死流。Gemini通过streamGenerateContent路径流式返回响应容器为candidates数组。OpenAI流式协议是单一 delta 类型的增量块chunk-based。openai.parser.ts 头注释精确描述了其消息架构每个 chunk 含choices数组通常单项delta携带增量——delta.content是文本增量delta.tool_calls是函数调用增量首块含完整 id/name 与空参数后续块只给参数增量文本流结束由sse:[DONE]事件标记且不可依赖finish_reason。响应容器差异Anthropic 用content数组Gemini 用candidates数组OpenAI 用choices数组。所有适配器/解析器的核心工作就是把这三种容器归一化。用量统计与错误处理Feature CategorySpecific FeatureAnthropicGeminiOpenAIUsage Metrics and Error HandlingToken countsYesYesYesDetailed token breakdowninput, outputprompt, cached, candidates, totalprompt, completion, totalUsage in streamNoNoOptionalError handling in responseNot specifiedNot specifiedYes (undocumented)Error handling in streamNot specifiedNot specifiedYes (undocumented)三家都返回 token 统计但口径不同Anthropic 拆分为 input/outputGemini 拆分为 prompt/cached/candidates/total注意 cached——对应其语义缓存能力OpenAI 拆分为 prompt/completion/total。流式过程中返回 usage 目前只有 OpenAI 可选支持stream_options: { include_usage: true }big-AGI 的 OpenAI 适配器在流式请求中始终开启该选项见 openai.chatCompletions.ts。错误处理方面对比表标注 OpenAI 在响应与流式中均有未文档化的错误处理机制AIX 服务端为不同提供商实现了差异化的容错timeout/retry 机制见 AIX.md 的时序图以及 chatGenerate.operation-retry.ts 等文件并在 OpenAI 侧专门实现了 openai.error-severity.ts 来做错误严重级别分类。高级特性JSON 模式、语义缓存、前缀填充Feature CategorySpecific FeatureAnthropicGeminiOpenAIAdvanced FeaturesJSON modePartial (via structured prompts)Yes (responseMimeType)YesOutput consistency techniquesYes (multiple methods)Not specifiedNot specifiedLogprobsNoNoYes (disabled in schema)System fingerprintNoNoYesSemantic cachingNoYesNoAssistant prefillYesNoNoPreferred formattingXML tags, JSONNot specifiedMarkdown高级特性矩阵的实战要点JSON 模式OpenAI 与 Gemini 是原生支持——Gemini 通过generationConfig.responseMimeType application/json可附带responseSchema做结构化约束OpenAI 通过response_format。big-AGI 的 Gemini 适配器在开启strictJsonOutput时会同时设置responseMimeType与responseSchema见 gemini.generateContent.tsOpenAI 适配器则设置response_format。Anthropic 只有部分支持——需通过结构化提示词structured prompts约束输出没有专门的 JSON mode 参数语义缓存Semantic caching只有 Gemini 支持对应其 usage 中的 cached tokensAssistant prefill助手前缀填充只有 Anthropic 支持——利用最后一条消息使用 assistant 角色时响应会从该消息内容继续的特性来约束模型输出方向。AIX 的 Anthropic wiretypes 注释明确记录了这一用法If the final message uses the assistant role, the response content will continue immediately from the content in that messageLogprobs 与 System fingerprint仅 OpenAI 具备但 logprobs 在 big-AGI 的 schema 中被禁用对比表标注 disabled in schema且 openai.wiretypes.ts 头注释明确写有 ignoring logprobs。安全与合规Feature CategorySpecific FeatureAnthropicGeminiOpenAISafety and ComplianceSafety settings in requestStop sequencesDetailed category-basedModeration APISafety feedback in responseYesYesNot specified安全策略是三家理念差异最大的维度Anthropic请求侧安全机制依赖停止序列stop_sequences响应侧返回安全反馈Gemini提供细粒度的按类别category-based安全设置。big-AGI 的 Gemini 适配器会为每个请求注入safetySettings阈值由GeminiWire_Safety.HarmBlockThreshold控制见 gemini.generateContent.ts 与 gemini.wiretypes.ts 中的GeminiWire_Safety命名空间OpenAI依赖独立的Moderation API做内容审核响应侧未明确说明安全反馈字段。从对比表到源码如何用这份矩阵指导接入实践综合整张对比表与 big-AGI 源码可以沉淀出几条可直接落地的工程结论统一消息模型是前提三家角色体系user/assistant、user/model、user/assistant/system/tool与系统指令承载方式顶层参数/parts 数组/system 消息都不同必须先有统一的内部消息格式再为每家写方言适配器——这正是 AIX 在 api/aix.wiretypes.ts 中建模AixMessages_*、在 chatGenerate/adapters/ 下按协议实现转换的原因多模态选型看 Gemini音频、视频、HEIC/HEIF、内置代码执行、细粒度安全设置、语义缓存都是 Gemini 独占或显著领先的能力OpenAI 的优势在并行工具调用、n参数、seed、原生 JSON 模式与 Moderation APIAnthropic 的特色是 assistant prefill、基于文本块的缓存控制cache_control: ephemeral与结构化提示词工具调用回填是最高危代码路径同样执行一个函数Anthropic 追加user消息 tool_result块Gemini 追加function消息 functionResponse部件OpenAI 发送tool消息 tool_call_id且 OpenAI 的arguments是 JSON 字符串、Gemini 的文本结果必须走response字段而非parts——任何一处写错都会导致多轮对话或工具循环失效流式协议按家适配Anthropic 是多事件类型协议、Gemini 走streamGenerateContent、OpenAI 是单 delta 类型 sse:[DONE]终止统一解析层需要分别实现 parser如 anthropic.parser.ts、gemini.parser.ts、openai.parser.ts并通过 stream.demuxers.ts 解复用不同流格式对比数据是时间快照本表数据截止 2024-07-09而 big-AGI 的 wiretypes 持续在同步上游演进如 OpenAI 的max_completion_tokens、developer角色Anthropic 的并行工具调用、Structured Outputs、各类服务端工具等接入时务必以目标 API 当前文档与仓库中最新 wiretypes 为准。【免费下载链接】big-AGIAI suite powered by state-of-the-art models and providing advanced AI/AGI functions. Includes AI personas, AGI functions, world-class Beam multi-model chats, text-to-image, voice, response streaming, code highlighting and execution, PDF import, presets for developers, much more. Deploy on-prem or in the cloud.项目地址: https://gitcode.com/GitHub_Trending/bi/big-AGI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考