企业官网建设流程全解析

先说个真实场景：上个月我帮朋友调一个知识库问答应用，他手里同时握着DeepSeek、智谱、讯飞星火的key，每个平台一份文档、一套鉴权方式、一个控制台，光是把三个模型的temperature参数对齐就花了一下午。后来换了聚合API，一个key、一个base_url、一套OpenAI格式的请求体，所有模型随便切，那种"终于不用在各家文档里反复横跳"的感觉，用过的人应该都懂。这篇就围绕FreeLLMAPI这种免费LLM聚合API展开，聊清楚它聚合了什么、怎么接入、报错怎么排查、在dify和codex这些工具里怎么用，以及免费服务背后有哪些坑。适合手里攒了一堆模型key的开发者、在折腾LLM工具的玩家，以及想快速对比多家模型效果但不想挨个充值的朋友。

市面上的聚合API不少，"免费"两个字是很多人入坑的第一动力，但免费背后藏着的限流、模型版本滞后、随时停服这些事，恰恰是文档里不会写清楚的。我在实际项目中踩过不少雷，这篇尽量一次性讲透。

1. 模型碎片化时代的聚合需求：为什么我最终转向了聚合API

1.1 各家模型各立山头的现状

这两年大模型厂商多到什么程度？DeepSeek、智谱、百度千帆、讯飞星火、Kimi、MiniMax，海外还有OpenAI、Anthropic、Google的Gemini系列。每个厂商都想让你用它的官方SDK、官方控制台、官方文档。对个人开发者和中小团队来说，这带来一个很现实的问题：每接入一个模型，就要重新注册账号、实名认证、申请key、充值、研究它的请求格式，工作量大得离谱。

这些平台的鉴权方式还不统一。大部分走Bearer Token，但有的要走AK/SK签名，有的要先调用一个接口换临时token，有的把密钥放在自定义Header里而不是Authorization字段。请求参数更是各说各话：同样是控制随机性，有的叫temperature，有的叫top_p，有的还冒出来一个thinking_budget这种专用参数。你写一套代码想同时兼容三家，简直是在给各家SDK做适配层。

还有一个隐性成本：每个平台的key都是单独计费的，月底一看账单，这个平台剩两百块，那个平台只剩三块钱，哪个都要记得去查，哪个都怕突然欠费导致线上服务中断。模型碎片化带来的心智负担，远大于模型本身的选择难度。

1.2 聚合API到底聚合了什么

聚合API做的事情用一个词概括就是"统一"。

第一是统一了接口地址和请求格式。几乎所有的LLM聚合平台都对外提供OpenAI兼容的/v1/chat/completions接口。这意味着你不需要为每个模型单独写一个调用函数，只要你熟悉OpenAI的请求体结构，就通吃了所有接进去的模型。

第二是统一了模型命名。你不需要记"这个模型在官方叫glm-4-plus，在那个平台上叫xxx-yyy"，聚合平台自己维护一套模型列表，它说这个叫deepseek-v4-pro，你就传deepseek-v4-pro，背后路由到哪家、走哪个版本，由平台处理。热词里那条 "the supported api model names are deepseek-v4-pro, deepseek-v4-flash" 就是典型的聚合平台提示，它用自己的一套命名空间来标识模型。

第三是统一了鉴权与计费。一个聚合平台的API key，可以调用它接入的所有模型。用量、余额、调用记录都在一个控制台里看，不用再开十个网页来回切换。

第四是统一了SDK接入方式。因为兼容OpenAI格式，你完全可以用OpenAI官方的Python或Node SDK，只改base_url和api_key，代码层面几乎不用动。

1.3 免费聚合API的商业模式与代价

很多人看到"免费"第一反应是：它靠什么活？我观察下来，免费聚合API的商业模式大概有这几类：

一部分平台走的是"低价转售+免费引流"路线，用一个甚至多个付费模型做低价促销，积攒用户后再引导升级付费套餐；一部分平台拿免费额度换取你的使用数据来优化自身路由；还有一部分是高校或开源社区的公益项目，靠捐赠和广告维持。

免费必然有代价，这个代价通常体现在三个地方：

一是限流。免费key的每分钟请求数、每日请求次数、单次最大token数通常被压得很低，适合测试和低频个人使用，扛不住生产级流量。

二是高峰期排队。免费额度在晚高峰时段经常出现响应变慢，甚至503。因为平台会优先保障付费用户的计算资源。

三是模型版本滞后。聚合平台接上游模型要重新适配和测试，所以新版本模型正式发布后，聚合平台往往要晚几天甚至几周才同步。

所以我一直的观点是：免费聚合API适合学习、测试、模型效果对比和个人知识库这类场景，不适合直接扛线上生产。生产环境至少需要付费档位，或者再叠加一层多平台failover。

2. FreeLLMAPI的核心机制拆解：统一网关背后做了什么

2.1 从客户端到上游模型的请求流转

当你向聚合API发一个请求，中间至少经过三层：你的应用、聚合网关、上游模型厂商。

聚合网关做的事情，比你想的要多。它先做协议转换，你发的是OpenAI格式的JSON，它要转换成上游厂商实际需要的格式。然后是参数映射，你传的temperature、max_tokens这些通用参数，要被翻译成各家模型能识别的字段，比如有的模型要求用max_completion_tokens，有的要求用thinking_budget，网关要在中间做一层适配。再是鉴权校验，它要验证你的key有没有权限、额度够不够、超过没超过限流阈值。最后是错误码翻译，上游返回的错误信息往往很"原教旨"，比如一些奇怪的HTTP状态码，网关要把它转成客户端最好理解的形式。

这个过程听起来简单，实际坑很多。参数映射这块尤其容易出问题，我后面排查章节会专门讲。这里先记住一个核心结论：你面对的不是某个模型厂商的原始API，而是聚合平台自己封装过的一道门，它既是便利，也是潜在的错误来源。

2.2 模型路由与负载均衡

一个聚合平台背后通常不只有一个上游渠道。同一个模型名，可能同时接了A厂商的官方API、B云平台的转售渠道、C合作方的资源池。网关选哪个渠道，有一套路由策略，常见的有三种：

按价格优先，走最便宜的那个渠道，哪怕它时延稍高；按时延优先，走响应最快的渠道，哪怕价格贵一点；按可用性优先，某个渠道连续报错就自动摘除，把流量切到健康的渠道上。

这套机制对用户最直观的影响是：同一个模型名，不同时间段的响应质量和速度会波动。有时候早上用时延20毫秒，晚上延迟2秒，不一定是网络问题，很可能只是网关把你的请求路由到了一个繁忙的上游渠道。理解这一点，排查超时问题时会少走很多弯路。

2.3 密钥管理与额度分配的实操要点

聚合平台通常会提供主key和子key机制。主key拥有全部权限，可以创建子key、查看用量、充值。子key可以限制额度上限、限制可用模型、设置有效期，适合分发给不同项目或团队成员。

实际使用中我强烈建议：线上项目和测试项目用不同的子key，不要共用主key。一旦某个子key泄露，你可以在控制台单独吊销它，不影响其他项目。而主key泄露等于给了对方你的整个账户。

密钥的轮换周期也要有。我的习惯是每三个月轮换一次核心key，如果发现异常调用记录，立即吊销重发。另外千万注意别把key硬编码到前端代码或提交到公开仓库，热词里那些"login failed. check api token"的报错，八成都是key填错，而key填错的深层原因往往是复制错了、过期了、或者权限不对，很少是真的API挂了。

免费额度的配额规则要仔细读。有的平台按分钟限流，有的按天限流，有的同时限制并发数。不要等到429才去看文档，接入前先确认清楚：免费档的RPM（每分钟请求数）是多少？TPM（每分钟token数）是多少？单次请求最大上下文是多少？这些参数直接决定你的调用策略。

3. 从零接入：一套兼容层通吃所有SDK

3.1 环境准备与base_url替换

接入聚合API最爽的一点，就是不需要额外安装任何SDK。你手头如果有OpenAI的Python库，直接就能用。

Python环境装好后的最小示例是这样：

from openai import OpenAI client = OpenAI( api_key="sk-你的聚合平台key", base_url="https://api.freellmapi.example/v1" # 换成聚合平台的base_url ) resp = client.chat.completions.create( model="deepseek-v4-flash", messages=[{"role": "user", "content": "你好，用一句话介绍你自己"}] ) print(resp.choices[0].message.content)

核心就三个改动点：api_key换成聚合平台的、base_url换成聚合平台的、model换成聚合平台文档里的模型名。除此之外，messages的格式、temperature的用法、流式输出的处理方式，都跟你用OpenAI官方API时一模一样。

Node.js那边也是同理，用openai npm包，构造OpenAI实例时传入baseURL和apiKey即可。前端项目里如果用了Vercel AI SDK这类框架，同样支持自定义base_url，在provider配置里指过去就行。

3.2 用curl先绕过SDK验证连通性

我排查API问题时有个习惯：先不用SDK，用curl直接打一发请求。这样做的好处是把问题分层——SDK报错的原因很多，可能是网络代理、证书、SDK版本问题，也可能确实是服务端的问题。curl一发下去，如果通了，问题就在SDK或代码层；如果不通，问题就在网络、key或服务端。

一个标准的curl测通命令：

curl https://api.freellmapi.example/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-你的聚合平台key" \ -d '{ "model": "deepseek-v4-flash", "messages": [{"role": "user", "content": "ping"}], "max_tokens": 20 }'

返回200并带出content字段，说明链路是通的。这时候再去查SDK哪里配错了。如果返回401，多半是key的问题；返回404，多半是base_url拼错了；返回400，看具体错误信息，大概率是请求体参数有误或上下文超长。

这个"先curl再SDK"的排查顺序，看着简单，实际能省掉至少一半的折腾时间。

3.3 流式输出与错误处理的Python示例

真实业务里大家几乎都要用流式输出，体验好太多。流式调用的代码也不复杂：

from openai import OpenAI client = OpenAI( api_key="sk-你的聚合平台key", base_url="https://api.freellmapi.example/v1" ) stream = client.chat.completions.create( model="deepseek-v4-flash", messages=[{"role": "user", "content": "写一段300字的短文，讲春天"}], stream=True ) for chunk in stream: delta = chunk.choices[0].delta if delta and delta.content: print(delta.content, end="", flush=True)

错误处理方面，OpenAI SDK自带了一套异常体系，常用的有这几类：

import openai try: resp = client.chat.completions.create(...) except openai.RateLimitError as e: # 429限流，做退避重试 print("限流了：", e) except openai.APIConnectionError as e: # 网络层问题，检查域名可达性 print("连接失败：", e) except openai.BadRequestError as e: # 400，请求体问题，仔细看e.body里的错误信息 print("请求错误：", e) except openai.APIStatusError as e: # 5xx服务端错误，可以稍后重试 print("服务端异常：", e)

这里有个细节：某些聚合平台返回的400错误信息非常详细，甚至会把不合法的字段名直接点出来。看到这种错误别急着改代码，先读完整的错误body，答案往往就在里面。

4. 高频报错排查：400、503、timeout的完整定位链路

热词里挂着一堆报错信息，我挑几个出现频率最高的，按"错误长什么样、为什么发生、怎么定位、怎么解决"的顺序展开。

4.1 400 context length超限：不是你写错了，是上下文爆了

热词里有这么一条：

api error: 400 this model's maximum context length is 1048576 tokens. howeve...

这个错误我第一次看到时愣了一下，1048576 tokens就是1M上下文，已经是非常大的窗口了，怎么还能爆？后来排查发现，问题出在调用方：写了一个循环，每次循环都把完整对话历史拼接进去，跑了几十轮之后，上下文直接冲破了1M上限。

这类400的定位链路其实很清晰：

第一步，确认是上下文超长还是参数错误。错误信息里同时报maximum context length和however后面跟的内容，仔细读，一般会告诉你当前请求有多少tokens、超了多少。第二步，数一下实际请求体的token量。最简单的方法是把messages数组序列化后，用tiktoken或者直接按字符估算，看是不是真的超了。第三步，检查调用代码里是不是无意中把历史消息无限追加了，特别是循环和递归场景。

解决方案我按优先级排序：

• 滑动窗口裁剪：只保留最近N轮对话，早期消息直接丢弃。
• 摘要压缩：超过窗口后，把早期对话先用一个便宜模型总结成摘要，再塞进上下文。
• 拆分子任务：把长文档分段处理，而不是一次性全塞进去。
• 调低max_tokens：如果你设置了很大的max_tokens，加上输入的messages tokens，总和可能超过模型上限，这时调低max_tokens也能救回来。

这个错误的本质不是"模型不行"，而是"调用方没做上下文管理"。养成好习惯：每次请求之前先在代码里计算当前上下文的token总量，接近阈值就做压缩。

4.2 503 overloaded与timeout：聚合方的资源调度问题

热词里这两条很典型：

api error: 503 server overloaded. this is a server-side issue, usually tempora... llm request timed out. | the model did not produce a response before the mod...

503的定义很明确：服务端过载，通常是暂时性的。它不是你的代码问题，也不是你的key有问题，而是模型供应商或聚合网关那边的资源暂时被占满了。

timeout则有两种情况：网络连接超时和模型响应超时。前者是连不上，后者是连上了但模型推理太久没返回。

定位链路我建议这样走：

第一步，用curl同一模型同一参数连发三次，看是否每次都503。如果只有一次503，那就是偶发过载，重试就能过；如果三次全挂，大概率是模型供应商确实在故障，或者免费档被限流了。

第二步，换一个模型名再试。比如deepseek-v4-pro挂了，换成deepseek-v4-flash，如果flash正常，说明只有pro这个模型的渠道有问题，可以考虑临时降级。

第三步，ping一下聚合API域名，看网络延迟。延迟高+TLS握手慢，往往是网络链路问题，跟模型f服务端无关。

解决策略上，重试一定要带退避。我常用的策略是指数退避加抖动：第一次失败等1秒重试，第二次等2秒，第三次等4秒，最多重试5次，每次加一个随机0到500毫秒的偏移量，避免所有请求同时重试造成雪崩。更稳的做法是降级：主模型超时后自动切换到备用模型。

在dify这类工具里，超时时间是可以配置的。我把首次响应超时设置成60秒，流式空闲超时设置成120秒，能有效减少"明明模型还在生成，SDK就报timeout"的假性失败。

4.3 模型名不识别与参数拒绝：聚合API的命名空间差异

聚合平台最大的隐藏坑，就是它的模型命名空间和参数支持范围和原厂不一样。

热词里那条：

the supported api model names are deepseek-v4-pro, deepseek-v4-flash, and de...

就是聚合平台在告诉你：这个平台里模型只叫这两个名字，你传别的（比如原厂的deepseek-chat）它不认。这是很多人的第一反应："我明明用的是原厂模型名，怎么报错？"因为聚合平台有自己的模型映射表，它不一定把上游每个模型名都原样暴露给你。接入之前，一定要先查它文档里的模型列表，或者调GET /v1/models接口看一下实际支持的模型名。

另外一个高频参数错误是：

api error: 400 the thinking_budget parameter must be a positive integer and...

thinking_budget是某些模型支持思考预算的控制参数，但聚合网关的参数校验比原厂严格。要么它不支持这个参数，要么它要求必须是正整数，你传了个0或字符串就报错。这类问题的排查逻辑是：先删掉报错指向的参数试试，通了就说明这个参数是多余或有问题的；如果必须用思考预算功能，那就换一个官方渠道，或者选聚合平台专门标注支持该参数的模型。

还有一类错误：

error: llm request failed: provider rejected the request schema or tool paylo...

这是tool calling（函数调用）格式被拒绝了。聚合平台在转发tool调用时，可能对tools数组里的schema做了严格校验，某些原厂能接受的宽松格式它不接受。遇到这种，我一般先简化tools定义，去掉不必要的description或去掉多余字段，再看看是不是required字段缺失。如果还不行，查一下当前模型在聚合平台上是否支持function calling，很多便宜模型或旧模型其实不支持工具调用，这个能力在模型层面就砍掉了。

4.4 410 gone与密钥类报错：服务和账号层面的失效

热词里有一条：

unexpected status 410 gone: walkai.top api access has been retired. use walk...

410和404不一样，它意味着这个资源曾经存在，现在有意的被移除了。对API服务来说，通常就是："这个接口退休了，请迁移到新的接口或新版本。"

聚合平台因为商业模式问题，接口变动比官方API频繁。上个月还能用的免费端点，这个月可能就收到了410。遇到410，不要再反复重试了，赶紧去查两件事：一是平台公告有没有新的base_url或API版本，二是自己本地有没有缓存旧的接口地址。另一个很常见的key类报错：

login failed. check api token or gitlab version...

乍看是LLM相关，其实是代码托管平台（GitLab）的报错，在多模型工具同时配置了GitLab和LLM服务时容易混在一起。报错信息里同时出现"check api token"和"gitlab version"，说明是代码仓库的token失效或SSL版本不匹配，跟LLM API没关系。这种就属于工具集成过程中的干扰项，定位思路是：一个组件一个组件排查，先禁用GitLab相关配置，再测LLM。

5. 把聚合API接入主流工具：dify、codex与obsidian实战

5.1 dify接入：自定义模型供应商的完整配置

dify是目前很火的LLM应用开发平台，它内置了不少模型厂商，但聚合API不在内置列表里，需要通过OpenAI API兼容格式手动配置。

在dify的设置页面找到模型供应商，选择"OpenAI-API-compatible"（不同版本可能叫"OpenAI API Compatible"或"自定义OpenAI"），然后填三个关键字段：API的Base URL填聚合平台的地址，形式是https://api.freellmapi.example/v1；API Key填聚合平台生成的key；模型名称填聚合平台文档里的模型ID，比如deepseek-v4-flash。

填完之后有个细节：dify会要求填模型类型。对话类模型选"LLM"，如果聚合平台也提供了embedding能力，那另建一个embedding供应商配置。很多人卡在这一步是因为只配了LLM，没配embedding，导致知识库上传文档时报错。注意，知识库的embedding接口和对话接口常常是同一个base_url下的不同路径，但模型名不同，要分别确认。

配置完成后，在dify里新建应用时就能选到这个自定义模型了。热词里有一条"dify llm怎么让模型不输出思考过程"，这个问题也比较典型：如果你选的模型是thinking类模型（比如带思考预算的推理模型），dify界面上可能有一个"思考模式"开关，关掉它；如果模型不支持关闭思考，那就换一个非推理模型。我个人建议在dify里给知识库问答场景用非推理模型，响应速度快，输出也更干净。

5.2 codex cli接入第三方LLM

codex是OpenAI出的一个终端编程助手，很多人在折腾它接入第三方API。它的命名里虽然带着OpenAI，但配置层面其实留了很大的自由度。

codex cli读取配置的方式有两种：环境变量和config.toml。环境变量是最快的方式：

export OPENAI_BASE_URL="https://api.freellmapi.example/v1" export OPENAI_API_KEY="sk-你的聚合平台key" export OPENAI_MODEL="deepseek-v4-flash"

如果codex版本支持config.toml，可以在配置文件的model_providers区域加一个自定义provider：

[model_providers.freellmapi] name = "FreeLLMAPI" base_url = "https://api.freellmapi.example/v1" api_key_env_var = "FREELMAPI_API_KEY"

然后通过--provider参数或环境变量指定使用这个provider。

这里有个重要提醒：codex这类编程Agent工具对模型能力要求很高，它依赖工具调用、结构化输出和长上下文的综合能力，不是随便一个聚合模型都能跑好。我实测下来，普通聊天模型在codex里经常出现"rejected the request schema or tool payload"这类问题。选模型时尽量选带tool call支持且上下文窗口大的型号，否则你花半天调通的接入，最后可能因为模型能力不足而没法实际使用。

5.3 obsidian llm wiki配置与embedding的注意事项

obsidian里的LLM wiki插件是很多知识库玩家的心头好，它支持自定义OpenAI兼容API。配置入口在插件设置里，找到API配置，填base_url、api_key和model。

热词里有"llm wiki obsidian使用教程"和"anything llm 知识库"，说明不少人把obsidian知识库和大模型API绑在一起用。我实际用下来发现几个坑：

第一，obsidian里的md文件内容往往很长，超出模型上下文时容易触发前面说的400 context length错误。LLM wiki插件不一定有自动裁剪功能，需要你在笔记里手动控制单次处理的内容量。

第二，markdown格式的接收能力。LLM wiki插件会把笔记内容以markdown原文发给模型，有些聚合模型在快速问答场景下没问题，但做长文档总结时格式会乱。建议选对markdown理解力强的模型，遇到格式混乱时换一个模型试。热词里"markdown格式 llm 接收"应该就是这个痛点。

第三，embedding的独立配置。观察知识库问答和文档向量化是两条线，LLM API负责对话，embedding API负责向量化。聚合平台如果同时提供两种能力，你要分别确认模型名和接口；如果聚合平台不提供embedding，那就需要配合本地embedding模型（比如Ollama跑的bge-m3），把两者分开配置。

6. 免费聚合API的隐藏风险与避坑经验

6.1 免费额度的隐形天花板

免费额度最迷惑人的一点是：它不像付费套餐那样明码标价写清楚所有限制，而是藏在某个"服务条款"或"fair use policy"里。等你用着用着，突然发现请求被拒或响应奇慢，才意识到有隐形天花板。

常见的免费额度限制包括：每分钟请求次数，通常是个位数到几十；每日请求总次数，可能在几百到几千；单次请求的最大token数，可能被压到8K或16K；并发数限制，只允许1到2个并发请求。

应对策略其实就一个：做配额自检。在接入代码里，每次请求前从聚合平台拉一次当前用量，或者自己本地维护一个计数。我自用的做法是封了一个简单的类，每次调用前查本地redis计数器，达到阈值的90%就切换备用平台。这个脚本写起来不复杂，但能避免很多"用着用着莫名其妙挂了"的情况。

免费档还有一个隐性限制是时段性。高峰期免费配额排队时间变长，503概率上升，早上六七点用反而很流畅。如果你对响应时间有要求，尽量把批量任务安排在凌晨或上午执行。

6.2 数据隐私与合规的底线

免费的代价里最值得警惕的是数据隐私。你的prompt和上下文内容，会经过聚合平台的服务器转发，再由它转发给上游模型厂商。也就是说，你的数据至少经过了两道中间环节。聚合平台是否有日志审计、是否会记录和保存你的请求内容、是否会拿你的数据做模型优化，这些问题在免费服务的条款里通常写得含糊。

我的建议很明确：涉及公司内部代码、客户数据、未公开产品信息的内容，一律不要通过免费聚合API传输。测试和体验可以用，生产环境的关键业务数据，要么走官方API，要么在私有化部署的模型上跑。

另外，即使是测试，也要尽量对数据做脱敏处理。把真实的用户名、邮箱、手机号替换成假的占位符，既不影响功能验证，又能降低泄露风险。

6.3 停服与版本退役的应对方案

前面提到的410 gone就是一个停服的真实信号。"api access has been retired"翻译过来就是"这个接口已经退休了"。免费聚合API的生命周期天然不稳定：运营者可能没有持续投入的意愿，上游模型厂商改版可能导致它要重新适配，甚至运营者某天直接关停服务。

应对策略的关键是：永远不要把某个聚合API当成基础设施，它只是你整个架构里的一个可替换组件。

我在代码里统一封装了一层llm Provider接口，所有业务逻辑只依赖这个接口，不直接依赖任何平台的SDK。切换平台时，只需要写一个新的Provider实现类，改一行配置，业务代码完全不用动。这套抽象花不了多少时间，但能在平台突然关停的时候把你从灾难中救回来。

其次，至少准备两个聚合平台或一个聚合加一个官方渠道的key。平时以一家为主，另一家作为冷备。我用一个简单的健康检查脚本定期探测备用key的通畅性，确保真到用的时候它还能用。

6.4 多模型对比的低成本选型思路

免费聚合API还有一个很妙的用法：模型效果对比。官方API通常要充钱才能测，聚合API免费额度足够你在同一个请求体格式下，把不同模型的输出摆在一起对比。

我个人的工作流是：新项目立项时，先写好一批评测prompt（覆盖问答、代码生成、长文总结、工具调用这几个场景），然后用聚合API把所有候选模型各跑一遍，记录质量、时延、输出稳定性三个维度。跑完心里就有数了，再决定正式用哪个模型，并通过官方渠道充值。算下来，评测阶段花的是聚合API的免费额度，正式生产用的是官方API的稳定保障，两边的好处都占了。

这个思路同样适用于选embedding模型。知识库的召回效果如果不理想，先用聚合API切不同的embedding模型对比召回率，找到最优解再固定下来。

另外补充一个轻松一点的技巧：思考预算参数。热词里那个"the thinking_budget parameter must be a positive integer"，其实是说有些推理模型支持设置思考预算。在聚合API上做效果对比时，如果你发现某个模型输出质量忽高忽低，可以看看是不是思考预算没设置好——有时候模型不是"不会答"，而是"还没来得及思考就被强制输出了"。给足思考预算，效果往往能上一个台阶。

最后说一点个人体会。免费聚合API这个东西，我用它最舒服的场景不是"省钱"，而是"试错"。不知道用哪个模型合适的时候，用它快速跑一遍；不确定某个功能（比如tool call或长上下文）能不能实现的时候，用它快速验证。当你把它定位成"低成本实验台"而不是"生产底座"，它给你带来的价值会远大于那点免费token。如果哪天这个项目停服了，我也不会慌——多层备用key、Provider抽象、以及那个健康检查脚本，已经帮我扛过不止一次类似的突发情况了。