很多人在把 AI Agent 从“玩具”往“生产力工具”推的时候都会卡在同一个地方模型会聊天了但工具集空空荡荡。我的经验是Agent 真正跑起来靠的不是大模型的魔法而是它背后能调用的那批 API。这篇文章我整理了平时自己搭建 Agent 时反复在用的 10 个免费 API尤其把 GitHub / Gitee / GitLab 三个平台的下载加速单独挑出来讲因为这块最容易踩坑也是很多自动化流程的刚需。这批 API 对三类人最有用一是做个人知识库或自动化脚本的开发者二是正在给公司搭内部 Agent 工具的工程师三是刚接触 LLM 应用、想低成本把链路跑通的新手。后面我不仅会把每个 API 的免费额度、调用姿势写清楚还会把 5GB/月这种额度到底能下多少东西、超额了怎么救、并发打满了怎么办一次性讲透。全程偏实操你花半小时看完基本能少踩掉我过去两三年踩过的大半坑。1. 项目分析与整体思路拆解1.1 为什么我给 Agent 准备的是 10 个 API而不是一个“万能钥匙”很多人的第一反应是找一个大而全的 API 聚合平台一个 KEY 全搞定。但我实测下来这个思路在 Agent 场景里并不成立。原因很简单Agent 的任务类型跨度太大从拿仓库元数据、下载 release 二进制到文档解析、翻译、模型推理每一类任务对 API 的 QoS 要求完全不一样。一个免费聚合服务往往是样样通、样样松尤其在高并发或大文件流转时非常容易拖后腿。所以我更倾向于按“任务类型”去选 API读 GitHub 数据就走 GitHub 官方 API静态文件分发就走 jsDelivr大文件 release 下载再单独接一个带免费额度的镜像加速服务推理和翻译又各自独立。这种方式看着麻烦实际维护起来反而简单因为每个环节只依赖一个稳定的服务源一个挂掉了不会牵连整条链路。还有一个被很多人忽略的理由免费 API 的稳定性受政策、流量、域名续费影响很大单一依赖等于把命运交给别人。拆成 10 个互相备份的免费 API哪个挂了就切哪个这才是把“免费”用出“商业级”效果的正确姿势。1.2 “5GB/月免费”到底能干什么这个 5GB/月不是模型 API 的 token 额度而是下载类加速服务里最常见的免费流量包。我按照实际 Agent 的工作负载帮你算一笔账素材类型常见体积5GB 能拉多少个配置文件 / JSON / 小脚本 1MB5000开源二进制安装包20-100MB50-250大模型文件 / 权重包500MB 以上10 个以内容器镜像 / 数据集300MB-1GB5-17我自己的用法是把 5GB/月当成“大文件专用池”只对那些超过 20MB 的 release 资产走加速通道。小 JSON、小代码文件直接走 GitHub 官方地址或 jsDelivr这样既不会浪费珍贵流量也能给大文件预留足够空间。如果你每天固定要下两个 100MB 左右的安装包一个月大约 6GB这个量级微超但只要搭配缓存策略和断点续传实际 spend 是可以控制在 5GB 以内的。1.3 我筛免费 API 只看三个标准第一必须支持鉴权。哪怕免费也要有 KEY 或 Token否则无法统计调用方平台不敢放开额度你也不敢在 Agent 里长期依赖它。第二必须写明 Rate Limit。没有限流说明的 API我默认它随时会挂不敢进核心链路。第三必须考虑跨域和头信息。Agent 不一定都跑在后端有些调试页面直接走浏览器CORS 支持不好就会白白烧掉半天时间。这三条筛完真正能长期进我工具箱的免费 API 并不多。下面这 10 个是我跑了一年多 Agent 之后留下来的主力清单。2. 十个免费 API 逐个点评与实操要点2.1 GitHub REST API——所有 Agent 的第一个数据源GitHub API 是 Agent 获取仓库信息、release 版本、issue 列表最直接的路。未认证的匿名请求只有 60 次/小时认证之后是 5000 次/小时这个差距是数量级的所以哪怕只是自己用我也建议老老实实申请一个 fine-grained personal access token。我高频用到的接口就几个GET /repos/{owner}/{repo}/releases/latest拿最新版本GET /repos/{owner}/{repo}/releases/tags/{tag}拿指定版本还有GET /repos/{owner}/{repo}/contents/{path}读仓库文件。基础用法一句话curl -s \ -H Authorization: Bearer ${GITHUB_TOKEN} \ -H Accept: application/vnd.githubjson \ https://api.github.com/repos/ggerganov/llama.cpp/releases/latest响应里那个browser_download_url数组就是下载资产的直链。注意直链域名在objects.githubusercontent.com上这个地址如果你直接用脚本去拉吞吐量通常不稳定这就是后面第二部分要做下载加速的原因。2.2 jsDelivr——给 GitHub 静态文件找一个全球 CDNjsDelivr 是个很多人低估了的免费资源。它能把 GitHub 仓库里的静态文件映射到 CDN 上你根本不需要买服务器也不需要配证书URL 拼对就能用。原本那种动不动几秒的连接延迟经过 CDN 分发后能压缩到毫秒级。对于 Agent 场景最典型的是读项目里的 JSON 配置、文档、工具函数。格式就一行https://cdn.jsdelivr.net/gh/{用户名}/{仓库名}{版本}/{文件路径}例如拉取某个仓库的config.json最新版不需要/blob/main/那种人类阅读地址文件路径直接用就好。但 jsDelivr 不是万能的它更适合小文件和静态资源遇到几十 MB 的 release 二进制包就不该走这里了。2.3 Gitee Open API v5——中文文档最顺手的仓库接口Gitee 的 Open API v5 在国内开发者的工具链里很常见尤其适合做仓库管理和内网同步。它的认证方式是在请求参数里带access_token也可以用 OAuth 流程换取。相比 GitHub它对中文场景的响应速度和错误信息都要友好一些。常用场景包括自动创建仓库、读取 release 列表、获取仓库 commits、触发 Webhook。比如拉取最新 release 的简洁写法curl -s https://gitee.com/api/v5/repos/{owner}/{repo}/releases/latest?access_token${GITEE_TOKEN}我在实际项目里更多把它当“二级缓存”用把 GitHub 的体积较大、下载频繁的资产同步到 Gitee再从 Gitee 拉取。原因很实际同一份 500MB 的模型文件从 Gitee 拉通常更稳至少不会因为跨地域传输断在半路。2.4 GitLab API v4——私有化仓库的老朋友GitLab 的 API 风格和 GitHub 类似但认证头用的是PRIVATE-TOKEN。做 Agent 的时候它最常用的场景是拿私有项目的 pipeline 状态、触发 CI 任务、读取 release 资产。curl -s \ --header PRIVATE-TOKEN: ${GITLAB_TOKEN} \ https://gitlab.com/api/v4/projects/{project_id}/releases有几个新手坑值得说第一project_id不是仓库名是数字 ID可以在项目主页拿到也可以用 URL-encoded 路径代替第二GitLab 13 之前的私有令牌机制和现在差别很大idea login failed. gitlab versions older than 14.0 are not supported这类报错我见过太多次市面上新工具基本都要求 14.0 以上老实例请先升级第三API 的 Rate Limit 是按 IP 维度算的公司内部共用出口 IP 时特别容易集体超限。2.5 GitHub/Gitee/GitLab 统一下载加速镜像 API——5GB/月的核心来源这是标题里“5GB/月免费”的主角。简单说这类加速服务提供了一个可以在线拼接的 URL 前缀你把 GitHub 或 GitLab 的原始下载地址直接接在后面它会在服务端做多节点分发和断点续传让你的 Agent 拉大文件时又快又稳。以 GitHub release 为例原始地址长这样https://github.com/ggerganov/llama.cpp/releases/download/b3435/llama-b3435-bin-ubuntu-x64.zip加速后的地址就是https://加速域名/https://github.com/ggerganov/llama.cpp/releases/download/b3435/llama-b3435-bin-ubuntu-x64.zip没错就是把两个地址拼在一起。为什么这个格式能成立因为这类镜像服务本质上是一个转发层它拿到完整 URL 后会先从自身节点或就近节点尝试命中缓存没有缓存再回源站拉取。对于脚本场景它最核心的价值有两个一是多节点容错一个节点慢会自动换二是支持断点续传网络中断后不用从头再拉。我过去常用的几个加速前缀有 ghproxy.net、ghfast.top、gh-proxy.com 这类还有不少自建镜像。要特别提醒这类公益域名迭代很快可能隔半年就换一批。所以千万别把某个镜像域名写死我这边的做法是维护一个健康检查脚本定时探测可用性把不可用的自动从列表里摘掉。这类服务大都免费给你 5GB/月的流量注册后按账号统计大文件下载特别适合走这里。不足的是它免费档可以同时下载的并发连接数通常有限所以不适合做大规模分发只适合个人 Agent 或小团队内部使用。2.6 MinerU API——让 Agent 读懂 PDF/图片里的文字Agent 要处理真实世界的资料第一步往往不是大模型而是把 PDF、扫描件、图片里的内容结构化提取出来。MinerU 在这方面做得比较省心它能直接把文档解析成 Markdown、JSON 这类干净格式而不是给你一堆 OCR 乱码。我习惯把它放在 Agent 的“预处理层”用户丢一篇论文进来Agent 先调用 MinerU 把 PDF 转成 Markdown再交给大模型做总结和问答。这一步能不能做好直接决定了后续 RAG 的质量。MinerU 的免费额度是按积分或每日次数给的个人日常研究完全够用。需要注意它的请求处理时间跟 PDF 页数强相关几十页的文档可能要等一小会儿所以要在 Agent 里设置合理的超时不要用默认 10 秒去等一份长文档。2.7 Groq 免费推理 API——Agent 的“思考”不用花钱Groq 是目前开源模型高速推理的热门选择它提供了 OpenAI 兼容的 API 格式这意味着你现有代码不需要大改只要把base_url和 model 名称换一下就能接入。免费档通常包含常见的开源模型速度非常快做 Agent 的中间推理层很合适。from openai import OpenAI client OpenAI( base_urlhttps://api.groq.com/openai/v1, api_keyos.getenv(GROQ_API_KEY), ) resp client.chat.completions.create( modelllama-3.3-70b-versatile, messages[{role: user, content: 总结这段日志}], )免费档的 Rate Limit 一般不高适合个人和原型验证。但也因为免费平台策略调整频繁我在生产环境里不会把它当唯一推理通道而是作为备用或者低优级任务的处理器。2.8 LibreTranslate——多语言 Agent 的免费翻译管线做跨语言的 Agent 时翻译 API 的预算很容易失控。LibreTranslate 是开源翻译服务有公共在线实例也可以自己部署。它走的是 HTTP APIPOST JSON 过去就能拿译文集成成本很低。我的用法是把它放在语言前置层Agent 收到非中文内容先统一翻译成中文再丢给大模型。这样既省 token又能让模型稳定输出中文结果。公共实例一般有限流并且免费字符数按天计算如果你每天翻译量比较大我更建议租一台小机器私有部署或者用 Hugging Face 免费空间跑一个实例作为长期方案更可靠。2.9 Cloudflare Workers——自己动手封装一个聚合 APICloudflare Workers 免费版每天有 10 万次请求额度这个量级对个人 Agent 绰绰有余。它的价值在于你可以把前面那堆 API 聚合到自己手写的接口后面统一做鉴权、缓存、限流。举个例子我常在里面写一个聚合下载接口Agent 传一个url参数Worker 先去 KV 或 Cache 里查缓存命中直接返回没命中再回源抓取抓完顺手写进缓存。这样既能省下游 API 的调用次数也能避免把免费的 5GB 流量浪费在重复下载上。export default { async fetch(request, env) { const url new URL(request.url); const target url.searchParams.get(url); if (!target) return new Response(missing url, { status: 400 }); const cache caches.default; const cached await cache.match(target); if (cached) return cached; const resp await fetch(target); const headers new Headers(resp.headers); headers.set(Cache-Control, public, max-age3600); const newResp new Response(resp.body, { status: resp.status, headers }); await cache.put(target, newResp.clone()); return newResp; } };这段代码不复杂但它给整个 Agent 加了一道很稳定的“缓存闸门”。原始 API 挂了还有缓存顶着重复请求也不会白白消耗免费额度属于投入小收益大的操作。2.10 免费 Mock 与数据类 API——联调测试的高性价比选择最后补两个不入流但很实用的 APIJSONPlaceholder 提供一套假的 REST 接口专供 Agent 联调时生成假数据OpenWeatherMap 有免费层可以拿天气数据RestCountries 可以快速查国家基础信息。这些东西看起来“没有技术含量”但在测试工具链时非常省事。比如 Agent 要对接一个订单系统但真实系统还没就绪你可以先用 JSONPlaceholder 的/posts、/users接口模拟数据结构。再比如做跨境电商类 AgentRestCountries 的免费接口能帮你验证国家名称和区号映射不用自己维护一份容易过期的静态表。这些 API 的免费额度通常对个人极其宽裕唯一的风险是“太稳定了容易忽略”记得在正式业务里还是切到正式数据源。3. 实操过程让 Agent 从“会读 Release”到“能下载大文件”3.1 抓下最新 Release 版本号第一步Agent 要知道目标项目最新版本号。通过 GitHub API 拿到 JSON 后不需要人肉看直接管道到 Python 提取curl -s \ -H Authorization: Bearer ${GITHUB_TOKEN} \ -H Accept: application/vnd.githubjson \ https://api.github.com/repos/ggerganov/llama.cpp/releases/latest | \ python3 -c import sys, json data json.load(sys.stdin) print(data[tag_name]) 这一步虽然简单但是很多后续自动化判断都依赖它。Agent 可以先比对本地缓存版本号和新版本号相同就直接跳过下载完全避免消耗镜像加速的 5GB 流量。3.2 拼接下载加速 URL 并做断点续传拿到版本号后第二步就是把 release 的browser_download_url拼上加速前缀。我用 Shell 做快速验证时是这样写的RAW_URLhttps://github.com/ggerganov/llama.cpp/releases/download/b3435/llama-b3435-bin-ubuntu-x64.zip MIRROR_BASEhttps://ghproxy.net ACCEL_URL${MIRROR_BASE}/${RAW_URL} curl -L -C - -o llama.zip ${ACCEL_URL}-C -是断点续传的关键参数。它会让 curl 检查本地已下载的文件大小从断点继续而不是从头再来。这一条对下载大文件极其重要没有它一个 500MB 模型文件在弱网环境下基本不可能完整下完。另外-L必须保留因为加速服务通常会先返回 302 跳转让客户端去真正的文件节点。3.3 用 Python 封装一个 Agent 可调用的下载工具如果你想把下载能力做成 Agent 的 function calling 工具一行 curl 就不够看了。我这里给一个稍微完整版的封装import os import requests MIRROR_BASE https://ghproxy.net def fetch_release_asset(owner: str, repo: str, tag: str, filename: str, use_mirror: bool True): api_url fhttps://api.github.com/repos/{owner}/{repo}/releases/tags/{tag} headers {Accept: application/vnd.githubjson} token os.getenv(GITHUB_TOKEN) if token: headers[Authorization] fBearer {token} resp requests.get(api_url, headersheaders, timeout15) resp.raise_for_status() assets resp.json().get(assets, []) target next((a for a in assets if a[name] filename), None) if not target: raise FileNotFoundError(f{filename} not found in release {tag}) raw_url target[browser_download_url] final_url f{MIRROR_BASE}/{raw_url} if use_mirror else raw_url local_file f/tmp/{filename} with requests.get(final_url, streamTrue, timeout60) as r: r.raise_for_status() with open(local_file, wb) as f: for chunk in r.iter_content(chunk_size512 * 1024): f.write(chunk) return local_file这段代码把“查 API”“拼镜像”“流式下载”串在一起Agent 只需要拿到owner、repo、tag和文件名就能把目标文件落到本地。timeout参数记得要调大大文件下载不是 10 秒能搞定的事我通常给 60 秒以上否则 Agent 会误判为超时失败。3.4 给 5GB 流量加一道“预算闸门”免费流量最怕的不是不够用是不知不觉用光。我建议在下载工具里加一个简单的计数文件import time, os QUOTA_FILE /tmp/quota_counter.json MONTHLY_LIMIT 5 * 1024 * 1024 * 1024 def consume_quota(size: int): now time.time() month_key time.strftime(%Y-%m) data {} if os.path.exists(QUOTA_FILE): with open(QUOTA_FILE) as f: data.update(json.load(f)) if data.get(month) ! month_key: data {month: month_key, used: 0} data[used] size if data[used] MONTHLY_LIMIT: raise RuntimeError(5GB monthly quota exceeded) with open(QUOTA_FILE, w) as f: json.dump(data, f)虽然写文件计数看起来很低端但在个人 Agent 里它足够可靠而且改造成 Redis 或 SQLite 都很容易。加了这层闸门之后至少不会在月底才发现流量被某次失控循环打光了。4. 常见问题与排查技巧实录4.1 镜像地址报 404、403、超时的排查法这几个状态码我全都踩过每次踩完都后悔没早点总结。直接看这张速查表现象大概率原因处理办法404URL 拼接时少了一个斜杠或版本号不存在打印最终请求 URL和原始 URL 逐字符比对403免费额度归零或服务端限制了当前 IP检查响应头换另一个镜像域名超时回源节点拥堵或文件体量太大加--retry 3换低峰时段启用断点续传下载中断网络抖动文件超过单次连接限制用curl -C -续传或改用 Python 流式下载尤其注意 403 不一定是你被平台拉黑也可能只是当日的共享节点过载。免费 API 的 403 有时还会带一段 JSON 提示先把 body 打印出来再判断不要凭感觉。4.2 如何避免 5GB 流量被“场景循环”烧光一个典型场景Agent 每轮对话都去检查同一个大文件是否下载。这本身就是个 bug——检查版本应该用 GitHub API下载文件只需要一次。我的建议是把“查版本”和“下文件”拆成两个独立工具并且为每个文件维护一个本地缓存记录命中缓存就直接跳过下载。如果 Agent 确实需要反复拉同一个远程大文件最好在中间加一层本地或 Cloudflare Workers 缓存。Worker 的 Cache API 可以帮你在边缘节点保存一份副本后续请求直接命中缓存根本不消耗你的 5GB 月度流量。4.3 Agent 并发上来之后怎么不让免费 API 直接雪崩有人问“AI Agent 怎么扛并发”其实 Agent 本身的并发并不难难的是下游免费 API 的并发限制。免费 API 通常会给单账号或单 IP 一个小窗口比如每分钟 60 次。我在 Agent 里用了信号量来控制并发数量很简单的办法import asyncio semaphore asyncio.Semaphore(5) async def safe_request(func, *args, **kwargs): async with semaphore: return await func(*args, **kwargs)把并发压到 5 以下大多数免费 API 都能扛住。再加一个指数退避重试基本不会触发限流。不要把并发调到 20、30 去测试免费 API 的底线亲测的结果通常是快速 429然后被限流十几分钟。4.4 密钥泄露与最小权限控制这是最容易忽略也最致命的一条。很多 Agent 框架会把人设 prompt、工具参数全部拼进上下文一旦你的 Token 出现在 prompt 里它就可能被大模型无意间带进日志甚至返回给用户。我踩过一次坑之后现在强制所有 Token 只存在于服务端环境变量或密钥管理服务里Agent 工具只接收“用密钥的权限”而不是“密钥本身”。Gitee 和 GitLab 的 Token 创建时都有权限范围选项一定按最小权限勾选。只读数据就只给 read 权限需要上传 release 再临时开 write 权限用完就删。免费 API 的 Key 也一样不要放在前端页面或公开仓库里。5. 扩展把这些 API 串成一个高可用下载链路5.1 多镜像自动切换免费镜像域名的时效性是不可控的所以我写了一个简单的健康检查循环每 5 分钟探测一次各镜像域名对某个小资源文件的响应状态。探测结果写入一个 JSON 文件Agent 每次拼 URL 前先读取可用列表。这样某个镜像域名突然挂了Agent 自动换下一个不会因为域名失效导致整条任务失败。这个思路也适用于 GitHub/Gitee/GitLab 三平台间的互备。5.2 Gitee 做二级备份GitHub release 的下载地址可能会变而 Gitee 的仓库在国内访问通常更稳。我在流程里加了一步当某个大文件是高频复用的就通过 Gitee 的仓库管理能力把它备份到自己的 Gitee 项目下后续 Agent 统一从 Gitee 拉取。这样既绕开了 GitHub 下载的不稳定期也把宝贵的多平台免费额度都利用了起来。5.3 最后再分享一个小技巧整套 API 串联起来之后我建议你给 Agent 加一条系统提示能用缓存就用缓存能走小文件通道就不走大文件通道。大模型的工具调用往往倾向于“最简单直接”的路径不会主动替你节省免费流量。你得通过工具设计和提示词把成本意识注入到 Agent 的每次决策里。我个人实践下来的体会是免费 API 不是玄学它就像信用卡的免息期用得好的人靠规则和缓存过日子用不好的人总在月底为超额账单后悔。把这 10 个 API 当积木搭好你就能用 0 成本撑起一条还挺能打的生产链路。