这几年做 AI Agent问得最多的一句话是你这些能力用的什么 API尤其是一个 Agent 要同时管对话、搜索、文件下载、文档解析时API 清单一下子能拉得很长。我给自己的工具箱整理过一批免费可用的 API覆盖模型推理、信息检索、文档处理和仓库下载加速其中 GitHub/Gitee/GitLab 下载加速这个接口每月有 5GB 免费流量特别适合做自动化采集和更新推送的工具型 Agent。今天把这 10 个接口连同接入方式一起放出来新手可以直接抄作业老手可以对照着查漏补缺。先说明一点我这里说的“免费”不全是永久免费还包括注册赠送、有免费额度和官方免费模型三类。每条我都标清楚口径免得你兴冲冲接完第二天收到扣费短信才反应过来。1. AI Agent 的 API 需求拆解模型只是第一步很多刚入门的朋友以为 Agent 就是“调一个大模型然后让它自己玩”。实际跑起来你才会发现模型 API 只是地基真正让 Agent 有“手脚”的是外围那些工具型 API。1.1 模型类 API 是底座但别把所有预算都砸在它上面对话类模型承担了 ReAct 循环中的推理部分读任务、决定调用哪个工具、把工具结果总结成回答。模型 API 的质量直接决定 Agent 的“智商”但它也最容易超预算尤其是一次任务里有多个工具调用时一轮对话可能要消耗几千甚至上万 token。所以我的习惯是能用免费模型兜底的场景就用免费模型比如智谱的 GLM-4-Flash、通义的 qwen-turbo 免费额度、讯飞星火 Lite都是比较靠谱的免费档稍微重要一点的推理任务再切到 DeepSeek、通义千问 MAX 这类更强模型。把“免费轻量模型”和“付费强模型”做分层而不是只盯着一家 API 的单价。1.2 工具型 API 才决定 Agent 能不能“干活”Agent 和普通 ChatBot 最大的区别就是它要调用外部工具。常见的工具型 API 有搜索类 API让 Agent 能查实时信息文档解析类 API把 PDF、图片、表格变成模型容易理解的文本下载类 API拉取模型权重、开源仓库的 Release 文件、数据集推送类 API把结果发到钉钉、飞书、邮件、Telegram。搜索和解析大家容易想到下载类 API 却经常被忽略。但你在做“定时监控某个 GitHub 仓库更新”“自动拉取某个模型新版本并跑评测”“批量下载开源数据集”这类任务时下载环节的稳定性比模型调用还重要。去年我做仓库监控类 Agent 时遇到的最大瓶颈不是模型不会总结而是下载 release 文件时频繁超时卡住后面一整串任务。后来把下载环节切到加速接口整个流程才顺起来。1.3 免费 API 的三个隐性成本你得先看明白免费 API 到底免了什么我踩过坑之后总结成三条免费期限有些是注册送 2000 万 token三个月内有效有些是某个特定模型永久免费。从文档里看“免费额度”三个字一定要点进去看细则。速率限制模型免费档通常限制并发和每分钟请求数RPM比如每分钟 60 次工具型 API 则限制每月调用次数或流量。计量口径模型按 token搜索按次数下载按流量。口径不同优化思路也不同。这三条决定了一个 API 能不能跑生产。免费但每分钟只能调 5 次的模型做个人工具没问题做客服系统就是灾难。所以在选 API 的时候我第一步不是看价格而是看限流和计量排在价格前面。2. 10 个免费 API 清单速览从对话模型到下载加速下面这张表是我目前整理出来的 10 个适合 AI Agent 的免费 API接入难度按我个人经验标注★越多越费劲。注意免费政策经常变动手前先去官网确认一眼。API免费口径适合用途接入难度DeepSeek 开放平台注册赠送 token之后按量付费复杂推理、代码生成、Tool Call★智谱 GLM-4-Flash模型本身免费日常对话、轻量 Agent 推理、文本摘要★通义千问 DashScope新用户免费额度中文理解、长文本、Function Calling★讯飞星火 Lite免费档长期可用中文场景、语音相关 Agent★★百度千帆 ERNIE Speed免费调用额度百度生态、中文任务★★硅基流动 SiliconFlow注册送资源部分开源模型免费开源模型统一接入多模型对比★OpenRouter注册送 credit还有 :free 免费模型聚合多种模型随时切换 fallback★★GitHub/Gitee/GitLab 下载加速 API5GB/月免费流量Release 下载、仓库导出、模型权重拉取★★MinerU API免费调试额度PDF/图片转 Markdown、版面解析★★★Tavily Search API每月 1000 次免费搜索Agent 实时搜索返回结构化摘要★★2.1 对话模型这组怎么选如果你只接一个我首推智谱 GLM-4-Flash 或者硅基流动上的免费开源模型。前者胜在稳定、有官方免费模型后者胜在兼容 OpenAI 接口格式你在本地写好的代码几乎不用改。DeepSeek 我是放在第二梯队的它能力确实强价格在付费模型里也算便宜但免费部分只是注册赠送不是长期免费适合拿来跑“高难度任务”不适合当默认依赖。OpenRouter 则是保险丝角色它聚合了各家模型一旦某个 Provider 抽风你可以快速把请求切到 :free 模型至少不中断。这里补充一个经验模型 API 不要只留一家。你永远不知道哪家服务商哪天改策略同一套 Agent 架构最好在配置层把 Provider 抽象出来换来换去只改一个变量。OpenRouter 和硅基流动的接入方式都是 OpenAI 兼容格式改 base_url 和 key 就能切换这点在排障时能省很多时间。2.2 搜索和解析是 Agent 的“外接感官”Tavily 是我在 Agent 项目里用得比较多的搜索 API。它和普通搜索 API 不一样返回结果直接整理成摘要和结构化字段方便直接塞给 LLM不用自己做一堆网页清洗。免费档每月 1000 次个人监控场景基本够用。具体接法也很简单一个 POST 请求传 query 和 max_results返回里带着 title、url、content 和 score基本就是给 LLM 定制的格式。MinerU 适合处理 PDF 和扫描件。以前我用纯文本抽取公式和表格基本没法看喂给模型就成了乱码。换成 MinerU 这类版面解析工具之后PDF 能转成规整的 Markdown再丢给 LLM 总结效果好很多。它的免费档通常用于调试如果要做大批量解析建议本地部署开源版本别拿公开 API 去跑几万页文档既慢也容易超量。2.3 下载加速 API 为什么值得单独占一个名额下载加速这个 API 单看很不起眼但对自动化的 Agent 来说价值不小。Agent 要主动获取外部资源最常见的就是从 GitHub 拉 Release 包、从 Gitee 拉代码仓库、从 GitLab 拉构建产物。这些文件如果在某些网络环境下直连很慢就会把整个 Agent 任务的耗时拖到十几分钟甚至直接超时。这类加速 API 的出现就是让你把下载动作的耗时降下来。一个月 5GB 免费流量听起来不多但如果只是拉源码包、发布包、文档完全够用了。我后面专门用一章讲它因为这里牵扯的计量口径和路径规则比模型 API 复杂一些。3. 重点解析GitHub/Gitee/GitLab 下载加速 API5GB/月这章专门聊聊下载加速因为我发现很多人要么不知道有这么个东西要么把它当普通 CDN 乱用结果流量一下就没了。3.1 它到底解决什么问题想象一个场景Agent 每天早上要去 GitHub 拉取某个项目的 Release zip然后解压、分析变更、生成日报。如果直连下载网络一波动就得等半天如果下载任务放在定时脚本里超时重试还会把 Agent 的执行队列堵死。下载加速 API 本质上是一个“回源转发接口”你请求加速服务提供的地址服务端替你去真正的下载地址取文件再把文件流回给你。因为服务端到 GitHub 的链路通常比你的客户端到 GitHub 的链路快很多所以下载速度会明显提升。对客户端来说你不需要装任何特殊软件也不需要改下载工具只需要改一下 URL 前缀普通 HTTP 请求就能下载。很多人会问这和直接用 curl 下载有什么区别区别在于curl 直连是“你的机器到 GitHub”要经过一条长链路中间任何一个节点抖动都会拖慢速度。加速服务是“你的机器到加速服务加速服务再到 GitHub”通常两个方向都有优化实际体验会稳定不少。换个角度来看它也像是给 Agent 加了一个“代取快递”的环节你只需要等着收件。3.2 免费 5GB/月的计量方式和边界这个免费额度是按“成功下载的流量”计算的通常是出站流量。我的理解是请求失败、404、响应内容长度很小比如错误页不会计入。具体使用边界我在实际测试中总结了几点单文件大小限制公共实例一般限制单文件不能超过 2GB有些更严格建议下载大文件前先看 Response Header 里的 Content-Length路径限制多数支持/releases/download/、/raw/、/archive/路径不一定支持git clone协议仓库和git-lfs大文件私有仓库不支持需要鉴权的仓库免费档不会传你的 Token直接下载会失败流量月度清零5GB 是自然月额度不结转。所以它的定位是“个人开发者和中小 Agent 的下载加速”不是“企业级大文件分发通道”。我自己的用法是每天下载几百个 Release 文件每个几百 KB 到几 MB一个月下来也到不了 1GB。真正吃流量的是模型权重、数据集这类几百 MB 到几 GB 的文件下几次就接近配额了需要省着用。3.3 Python 接入示例最基础的一种假设你要下载的原始地址是https://github.com/user/repo/releases/download/v1.0/app.zip加速地址就是在前面拼一个服务域名https://加速域名/https://github.com/user/repo/releases/download/v1.0/app.zip用 requests 的 stream 模式写一个通用下载函数import requests def accelerated_download(url, save_path, timeout60): # url 已经是拼好的加速地址 headers {User-Agent: agent-toolbox/1.0} with requests.get(url, headersheaders, streamTrue, timeouttimeout) as resp: resp.raise_for_status() total 0 with open(save_path, wb) as f: for chunk in resp.iter_content(chunk_size1024 * 1024): f.write(chunk) total len(chunk) return total如果你想并发下多个文件换成 httpx 的 AsyncClient 更合适import asyncio import httpx async def download_one(client, url, save_path): async with client.stream(GET, url, timeout60) as resp: resp.raise_for_status() with open(save_path, wb) as f: async for chunk in resp.aiter_bytes(): f.write(chunk) async def download_many(tasks): limits httpx.Limits(max_connections10, max_keepalive_connections5) async with httpx.AsyncClient(limitslimits) as client: await asyncio.gather(*[ download_one(client, url, path) for url, path in tasks ])这段代码里有个小细节下载超大响应时一定要用stream模式不能直接resp.content一次性读进内存否则 Agent 的内存会被大文件打爆。我之前就是图省事用resp.content下载一个 1.6GB 的模型文件结果 Python 进程直接内存暴涨后来改成流式才解决。3.4 Gitee 和 GitLab 怎么用加速思路如果是 Gitee 上的仓库访问速度本来就快一般不需要加速 API。真正有用的是“把 GitHub 仓库导入 Gitee再从 Gitee 下载”那种下载体验会很稳定。GitLab 分两种情况如果你用的是 GitLab.comRelease 文件一样可以走加速服务如果你用的是自建 GitLab、企业内部 GitLab那本身就是内网直连不需要任何加速。自建 GitLab 的 CI/CD 里用 GitLab API 下载 artifacts 反而更合适它有独立的配额和 Token 机制。我踩过的坑是用加速 API 去处理一个需要登录才能下载的私有 Gitee 仓库结果一直返回 404查了半天才反应过来转发服务不会带我的登录态。私有文件还是要用官方 API 加 Token 拉取加速服务只适合公开仓库和公开 Release。3.5 避坑别拿下载加速 API 当无限 CDN加速 API 的公共实例是共享资源不适合高并发、大并发地刷。我曾经写过一个监控脚本每小时去拉 50 个仓库的 Release tar 包跑了一周后收到限流提示原因就是单个 IP 并发太高。后来改成串行下载、加哈希缓存流量骤降也再没有触发限流。另外建议在 Agent 里对下载过的文件做本地缓存。先记录文件的 ETag 或 SHA256下次要下载前先对比没变化就跳过。这样省的不只是下载流量还有解压和解析的时间。做信息监控类 Agent缓存几乎是必备设计不然每天重复下载相同文件白白浪费 5GB 额度。4. 实测经验把 10 个 API 装进一个 Agent 工具箱单纯列 API 没有意义关键是接进你自己的 Agent 架构。这一章我分享几个实测后沉淀下来的工程习惯。4.1 Key 集中管理别写死在代码里我见过太多项目把 API Key 直接写在config.py里或者写死在 prompt 里让模型调用这非常危险。正确做法是放到环境变量或.env文件用 pydantic-settings 或 python-dotenv 读取。命名上我用统一的PROVIDER_API_KEY前缀比如DEEPSEEK_API_KEY、ZHIPU_API_KEY、TAVILY_API_KEY方便排查问题。如果是 Spring AI 项目配置项同样是走application.yml的密钥管理别把 Key 放进代码仓库。扣子这类低代码平台则要注意工具插件里的密钥要使用平台提供的 Secret 存储不要用普通变量。这里还要提醒一句切勿把 Key 打进日志。很多 HTTP 客户端在 debug 模式下会把请求头打印出来如果 Authorization 字段没脱敏一旦日志外发等于白送。我通常在日志配置里加一个过滤器把authorization、api-key、token这几个字段全部替换成***。4.2 统一请求封装超时、重试、指数退避免费 API 最常返回的状态码是 429限流和 5xx服务端抖动。我的统一 HttpClient 会做三件事设置分层超时连接超时 10 秒读取超时 60 秒对 429 和 5xx 重试最多 3 次每次等待时间按 1s、2s、4s 指数递增对所有异常打结构化日志方便事后复盘。import asyncio import httpx async def request_with_retry(client, method, url, **kwargs): max_attempts 3 for attempt in range(max_attempts): resp await client.request(method, url, **kwargs) if resp.status_code not in (429, 500, 502, 503, 504): return resp sleep_time 2 ** attempt await asyncio.sleep(sleep_time) resp.raise_for_status()Rust 生态写 Agent 时reqwest的中断重试也可以用tower或手动循环核心逻辑一样。很多坑不是 API 文档写的而是重试策略不对比如对 4xx 也重试白白挨限流或者对 429 不加等待越重试越被封。把“什么错误值得重试”单独拎出来列一张表比事后猜靠谱得多。4.3 并发控制Agent 扛并发先学会“让路”“AI Agent 怎么扛并发”是最近被问烂的问题。我的答案是Agent 的并发瓶颈通常不在框架而在外部 API 的限流。一次 Agent 任务可能同时触发模型调用、搜索、下载如果每个请求都全速打出去免费额度几分钟就没了还容易触发封禁。落地做法是给每个 API 配置独立的 Semaphore把并发数限制在官方限制的 70% 左右任务层面再用队列削峰。比如同时监控 100 个仓库模型调用一次只并发 5 个下载一次只并发 3 个实测下来稳定性明显好于反复超时重试。import asyncio sem_model asyncio.Semaphore(5) sem_download asyncio.Semaphore(3) async def run_with_limit(sem, func, *args): async with sem: return await func(*args)更进阶的做法是给每个 API 做一个令牌桶。模型 API 每分钟 60 次你就每秒放行 1 个请求下载 API 按流量限你就按已下载字节数计费超过配额自动切到备用源。这样免费额度不仅不会被突发流量打爆还能让 Agent 在并发场景下平稳运行。4.4 常见报错和多 Provider 降级最近朋友圈里高频出现两个报错一个是api error: 400 this models maximum context length is 1048576 tokens另一个是no api key for provider route deepseek-official。第一个是上下文超长处理思路是把喂给模型的文本按章节切块先做一轮摘要再拼接如果必须全量处理就要用支持超长上下文的模型而不是硬塞。第二个是 Key 没配上。这个报错常见于 OpenRouter 这类多 Provider 路由平台指定了 provider 但没填对应 Key。修复方式很简单在配置里把 provider 指向你真正填过 Key 的那个路由。但更推荐的做法是多 Provider 降级主 Provider 挂了自动切到备用比如 DeepSeek 不可用时切到智谱或 OpenRouter 的 :free 模型保证 Agent 任务不断。我在工具箱里把降级写成装饰器主调用抛异常后自动走备用整个过程对上层任务透明。5. 组合实战做一个“开源项目更新情报员”Agent理论说了不少我们来拼一个实际能跑的最小 Agent。场景是每天定时检查一批关注的 GitHub / Gitee / GitLab 仓库把最新 Release 的变更说明拉下来让大模型总结成简报。5.1 工作流设计用 GitHub API 拉某个仓库的最新 Release拿到 Release 正文或 changelog 文件地址用加速下载 API 把 changelog 下载到本地把文本截断后交给 GLM-4-Flash 总结把结果追加到本地 Markdown 日报。无需复杂 Agent 框架一个简单的调度循环就够了。如果硬要套 ReAct也可以但“固定流程模型总结”模式在这个场景下更省 token也更可控。Agent 不是越复杂越好能用一个定时任务解决的问题没必要硬上编排框架。5.2 关键代码片段import os import httpx GITHUB_TOKEN os.environ.get(GITHUB_TOKEN, ) # 公开仓库可为空 ACCEL_DOMAIN os.environ.get(ACCEL_DOMAIN, ) # 下载加速服务域名 async def get_latest_release(repo): url fhttps://api.github.com/repos/{repo}/releases/latest headers {Accept: application/vnd.githubjson} if GITHUB_TOKEN: headers[Authorization] fBearer {GITHUB_TOKEN} async with httpx.AsyncClient() as client: resp await client.get(url, headersheaders) resp.raise_for_status() return resp.json() async def fetch_asset_text(asset_url): # asset_url 是 release 里某个文件的浏览器下载地址 accel_url f{ACCEL_DOMAIN}/{asset_url} async with httpx.AsyncClient() as client: resp await client.get(accel_url, timeout60) resp.raise_for_status() return resp.text这里有个小注意点GitHub API 未认证时是每小时 60 次监控 60 个仓库刚好压线加上 Token 后有 5000 次配额几乎不用担心。所以我建议即使是读公开仓库也挂一个只读 Token成本为零但能避开大部分限流问题。5.3 免费额度消耗估算假设你监控 100 个活跃仓库每个 Release 正文按 2KB 算100 个仓库的 changelog 总量也就几百 KB一个月下来不到 20MB5GB 下载加速流量几乎用不掉。真正消耗流量的是你想下载完整 Release 包比如模型权重或安装包那种几百 MB 的文件下几个就会吃掉配额。模型额度也一样。用 GLM-4-Flash 总结 100 条 release 信息每条几百 token一个月消耗也就几百万 token免费档完全能扛住。所以这类信息监控 Agent 用免费 API 跑完全可行。我实际跑下来一个 30 仓库的监控任务每天耗时不超过 3 分钟月流量不到 50MB模型调用基本都在免费额度内。如果自己写代码手动做这些光下载重试就可能耗掉几小时。这也是为什么我一直强调给 Agent 选 API不能只看模型能力要把下载、解析这些“辅助环节”也纳入成本核算。5.4 扩展思路加 Gitee 仓库用 Gitee API 的 Releases 列表改改 URL 就能接入加 GitLab用/projects/:id/releases接口注意它是先拿 Project ID 再查 Releases加推送把日报用 Webhook 发到钉钉或飞书换语言Rust 用 reqwest tokio逻辑照着上面的异步代码平移上框架如果你已经在用 Spring AI把下载任务做成 Tool配合 Scheduled 定时触发。这些扩展都不难核心还是把“下载、解析、总结、推送”这条链路跑通。链路稳定了后面加数据源只是改配置的事。6. 选型建议与个人经验最后聊几句我这段时间用免费 API 做 Agent 的体会。6.1 免费 API 的“水桶效应”不稳定环节要有兜底10 个 API 里哪怕有 9 个稳定只要下载加速那个偶尔抽风你的 Agent 依然会“看起来不好用”。因为用户感知到的是整条链路的最终结果而不是你调了哪家 API。所以我给每个关键 API 都准备了一个备用方案。下载加速不可用了就切 Gitee 中转模型 A 限流了就切模型 BTavily 配额用完了就用 免费搜索或直接调搜索引擎的网页接口。免费 API 本身就是试用装稳定性预期不能和付费 SLA 比兜底是必须的。6.2 我推荐的起步组合和升级路径如果你现在从零开始做一个工具型 Agent我的建议是先用最小组合跑通GLM-4-Flash 做推理 Tavily 做搜索 下载加速 API 拉文件 MinerU 解析 PDF。这套组合几乎零成本能覆盖大部分“查资料、下文件、写总结”的场景。跑通之后再根据瓶颈升级如果模型总结质量不够把核心任务切到 DeepSeek 或更强模型如果下载量很大考虑自建加速服务或换带宽更足的方案如果 Agent 响应太慢再去做并发和缓存优化。别在第一步就追求完美架构先跑起来再迭代。6.3 用不了的免费 API可以换成自建有几类 API 其实可以自建替代。比如文档解析MinerU 本身就是开源项目服务器够的话直接本地部署随便跑不心疼比如搜索如果只是针对特定站点可以自己写爬虫做索引甚至下载加速你也可以用一台带宽较好的服务器搭简化版转发服务只给自己用。但自建也是有成本的服务器费用、运维时间、稳定性维护。我个人的判断标准是如果某个 API 每天调用量超过免费额度的 80%或者已经影响主线任务才值得考虑自建替代。否则为了省几块钱搭一堆服务反而得不偿失。如果你问我最推荐哪个我会说没有银弹。但如果你想在 30 分钟内跑通一个能“监控仓库更新并自动总结”的 Agent用 GLM-4-Flash Tavily 下载加速 API MinerU 这组组合应该是最省事也最省钱的路径。