TikHub API Token 与 Helper 技能实测

搜「tikhub api helper」排在前面的那个 Claude Code 技能，不是 TikHub 出的，是一位个人开发者放在 GitHub 上的社区项目（下文叫社区仓库 A）。我们在 2026-11-06 凌晨把它逐文件核了一遍：它自带的接口快照有 1,120 个路径，其中 288 个（25.7%）已经不在 TikHub 当天的文档里，SKILL.md 里 4 个示例调用有 3 个参数名和今天的文档对不上，教人设的环境变量名（TIKHUB_TOKEN）和代码真正读的名字（TIKHUB_API_TOKEN）也不一样。更直接的问题是它的客户端用 Python 自带的 urllib 发请求，我们从新加坡在 00:20 和 00:25（新加坡时间）两轮测试里，这个默认请求头去访问 api.tikhub.io 和 api.tikhub.dev 全部被挡，返回 403 和「error code: 1010」，连不用 token 的健康检查都过不去。

价格上，同样 1,000 次 TikTok、抖音请求，按 TikHub 公开价是 $1.00，我们三次真调实测每次 $0.000556，即 $0.556，TikHub 是我们的 1.8 倍；它要在同一个接口上一天调到约 117,900 次，按日阶梯打折后才追平。

本篇只回答搜「tikhub api token」「tikhub api helper」「api tikhub io」的人真正要做的那件事：建好 token 之后，把它交给 AI 代理，让代理自己找接口、调接口、处理报错，这一路上 token 放哪、权限和过期怎么管、限流怎么算、社区 Helper 能不能直接用。TikHub 一侧我们只用公开材料：它的文档站、api.tikhub.io 上的 openapi.json、不带 token 就能读的价目接口、定价页和 MCP 页，以及 GitHub 上公开的仓库；我们没有注册 TikHub，没有用任何人的 token 调它的付费接口。EveryInfra 一侧全部是同一晚的真调，读取和调用时间都写在正文里。

tikhub api token 怎么建：权限、过期和停用写在哪

TikHub 的 token 在用户中心建。它文档站的 README - English 末尾「Get API Token」一节写了四步：注册登录、进用户中心点 API token 菜单创建、复制到请求头、只在请求头里用并保密；中文版自述文档写法相同。教程与常见问题页补了一句「每个用户最多可以建 100 把 API Key」，适合按项目分开。到这里为止，和站内《TikHub API Key、文档与 GitHub 上手实测》讲的一样。本篇要多问一层：token 建好之后，能不能限定它只调某些接口、能不能设过期、能不能临时停用？这三件事决定了你敢不敢把它交给一个会自己做决定的 AI 代理。

我们在 TikHub 今天的公开文档里没找到这三件事的操作说明。今天的 README 和 api.tikhub.io 上的 openapi.json（2026-11-06 00:16 读取）只在状态码说明里间接提到了它们：401 的六种原因里有「API token has expired」和「status is invalid or not activated」，403 的原因里有「API token lacks required permissions」。也就是说，过期、停用、权限不足这三种状态是存在的，但怎么设置没写。往回翻才找到原文：TikHub Python SDK 在 PyPI 上的 1.13.0 版说明（2024-12-05 发布）写着，生成 token 时「可以自定义 API Token 的权限（Scopes），也可以设置过期日期（Expire Date），还可以手动暂时关闭（Status）」，并且强烈建议每个项目用不同的 token、创建时勾选对应的 Scopes，否则请求时会权限不足。到了 2.2.0 版（2026-10-03），这一段已经删掉，换成了一句「从控制台复制你的 API key，设成环境变量 TIKHUB_API_KEY」。我们没有登录 TikHub 用户中心，没法确认今天的控制台是否还保留这三个开关，只能照实写：旧文档写了能设，今天的文档没写怎么设，状态码说明里仍然有这三种状态。

EveryInfra 这边，这三件事都写在 /docs 的账户一节里。每把 Key 可以在控制台「API Keys → 权限限制」里关掉某一类产品，被关掉的产品调用返回 403 capability_denied；停用一把 Key，调用返回 401；管理 Key、修改设置、开工单这三项写权限默认关闭，只能人登录控制台勾选。经 Key 新建的 Key 每天最多 20 把，查看或轮换完整 Key、改权限和 IP 白名单、重新启用、付款，永远只能在控制台做。我们这样设计，是因为 AI 代理拿到 Key 之后，最该防的不是它调错一个接口，而是它顺手改了账户或者花了不该花的钱。两边的差别整理在下表，左边的「没写」是指今天公开文档里查不到操作说明，不等于功能不存在。

这张表最要紧的是第二行。一个会自己挑接口的代理，迟早会挑到你没打算让它调的接口：比如你只想让它查 TikTok 主页，它却去调了每次 $0.02 的抖音星图接口。TikHub 如果今天还支持 Scopes，就该在建 token 时只勾你要的那几个平台；如果你的控制台里已经没有这个选项，那么能做的只剩每个代理一把 token、余额只充够用的金额。我们这边按产品关闭的粒度比按接口粗，好处是一个开关就能把验证码、代理这类和数据采集无关的产品整个关掉。

限流：TikHub 按接口每秒算，我们按账户每分钟算

把 token 交给代理之后，第二个常见的坑是限流。代理喜欢并行，一次发出十几个请求很常见。TikHub 的 openapi.json 开头写的是「QPS: 10/Second」，定价页的问答写得更细：限流按接口算，不按账户算，默认每秒 10 次是对每个 API 路径分别计的，所以不同接口可以并行调；要更高的每秒次数，可以在 RPS 面板单独购买，按月计费，和请求费分开。2024 年的旧文档写法稍有不同，是「按 token 主人的邮箱、每个接口独立计算，多数情况下每秒 5 次」。

文档里说「默认 10 次」，实际每个接口的数在价目接口里逐个写着，这个接口不带 token 也能读。我们在 00:18:13（新加坡时间）读到 1,471 个有价接口，按 rate_limit 字段一数：1,397 个是每秒 10 次，47 个每秒 5 次，14 个每秒 3 次，10 个每秒 1 次，另有每秒 20、4、2 次的各 1 个。也就是说有 74 个接口不是默认值。对一个按文档默认值并发的代理来说，碰到每秒 1 次的接口就会连续收到 429。

EveryInfra 的限流按账户算，不按接口算：定价页写明默认每分钟 60 次，名下所有 Key 合计，多开 Key 不叠加；要更快可以按 30 天买提速包（每分钟 180 次 $10、600 次 $30），或累计充值到档自动获得。超了返回 429 rate_limited，带 Retry-After，告诉你等几秒。HTTP 429 和 Retry-After 的用法来自 RFC 6585 第 4 节，两家都用这个状态码。两种做法各有利弊：TikHub 按接口算，同时调很多不同接口时总吞吐可以很高，每秒 10 次也比我们默认的每分钟 60 次快得多；我们按账户算，代理不用记 1,471 个接口各自的上限，只要看一个数。

这里要提醒一个社区 Helper 的细节：它的 SKILL.md 写着「QPS 每接口每秒 10 次、超时 30 到 60 秒、错误最多重试 3 次」，这三句是从 TikHub openapi.json 开头抄的，但 Helper 的客户端代码里没有任何重试，超时写死 30 秒，碰到 429 只是把「HTTP 429」原样交回给模型。模型读了 SKILL.md，会以为客户端会替它重试。

tikhub api helper 是谁做的，装上之后有什么

搜「tikhub api helper」，排在前面的是 GitHub 上一个名叫 tikhub_api_skill 的仓库（社区仓库 A），和它被各家技能目录收录的页面，例如 LobeHub 技能市场和 Shyft。仓库所有者是一个个人账号，不在 TikHub 的 GitHub 组织名下；仓库描述写的是「TikHub API 助手是一个 Codex/Claude Code Agent Skill」，没有说自己是官方出品。我们 00:14 用 GitHub 接口读到：129 星，页面显示 17 个 fork，2026-01-08 建库，最后一次推送 2026-07-08，没有声明开源许可。所以准确的说法是：这是一个社区项目，TikHub 没有出过名叫「API Helper」的技能。TikHub 自己出的是 tikhub-plugin，一个 Claude Code 插件，最后一次发布是 2026-06-15 的 v1.1.0，里面有 18 个技能和 7 个平台的 MCP 配置。

Helper 的目录结构很简单：.claude/skills/tikhub-api-helper/ 下面四个文件，SKILL.md 5,850 字节，告诉模型先搜接口、再看参数、再调用；api_searcher.py 在本地 openapi.json 里按关键词找接口；api_client.py 负责发请求；openapi.json 是一份 2,997,476 字节的接口快照。这个思路本身是对的：TikHub 的接口文件约 84 万 token，不可能整份塞给模型，先在本地搜、只把命中的几条交给模型，是省上下文的好办法。Claude Code 的技能文档也说，技能正文只在用到时才加载，大段参考材料平时几乎不占上下文。问题出在细节上，后面几节逐个讲。

社区里不止这一个。TypingMind 技能目录还收录了另一个社区技能 tikhub-skill（社区仓库 B），它是开源项目 OpenCompany 的一部分，做法不同：不带接口快照，而是把 TikHub 官方 Python SDK 的方法摊平成一个工具。三种做法放在一起看：

TikHub 官方插件，站内上手实测那篇已经核过，本篇重点放在社区 Helper，因为它是这个搜索词下最常被点开的结果，而且它会被原样复制：后面讲 token 时会看到，一份有问题的代码一旦被 fork，修好原仓库也收不回来。

接口快照过期：1,120 个路径里 288 个已经找不到

Helper 的 openapi.json 是作者 2026 年 1 月从 TikHub 下载的一份副本，之后只在 5 月动过一次。我们把它和 TikHub 2026-11-06 00:16:44（新加坡时间）的 openapi.json 逐条比对路径。两份文件的 info.version 都写着 V5.3.2，单看版本号会以为没变；实际快照里 1,120 个路径，只有 832 个还在今天的文档里，288 个（25.7%）已经消失；反过来，今天的 1,058 个路径里有 226 个（21.4%）是快照里没有的，代理用 Helper 永远搜不到它们。两边都有的接口里，还有 59 个的查询参数变了，比如快手的用户搜索去掉了 page、加了 pcursor 和三个筛选项。

消失的 288 个集中在几组：领英两组 77 个、TikTok 广告 23 个、抖音网页版 20 个、小红书网页版 V2 18 个、TikTok App V3 17 个、Sora2 17 个，小红书网页版第一代 15 个全部没了。新增的 226 个里，B 站花火 45 个、抖音星图 V2 29 个、小红书蒲公英 20 个、抖音 DOU+ 17 个，这些恰好是做达人营销、投放分析的人最想用的接口。另一方面，288 个消失的路径里有 201 个仍然出现在价目接口里、照样标着价格。站内上手实测那篇当时也发现价目接口里有 433 个路径在文档里查不到，这说明 TikHub 下线一个接口时先从文档里拿掉，价目里还留着；对代理来说，「价目里有」不能当成「还能调」的证据。

SKILL.md 自己的平台表也能看出时间差。它写小红书网页版有 26 个接口，快照里实际是 15 个，今天的文档里是 0 个；YouTube 网页版写 16 个，今天是 8 个；TikTok App 写 76 个，今天是 58 个。表里写的数，既不等于它打包的快照，也不等于今天。一个照着这张表规划的代理，会以为小红书网页版接口还很多，去搜之后却只能拿到已经下线的路径。

按 SKILL.md 的写法去搜：多词查询为什么常常 0 条

Helper 的工作流是先搜、再查详情、再调用。我们 00:19（新加坡时间）在本机离线运行它的 api_searcher.py，用 SKILL.md 里原样出现的查询各搜一次，再补了 4 个中文和多词查询。结果见下图：SKILL.md 示例工作流第一步用的「tiktok user profile」只搜到 1 条，而且是不能带参数的演示接口；「常见用法」一节用的「fetch user profile tiktok」是 0 条；「douyin video comments」和「小红书 笔记」也是 0 条。

原因在搜索脚本本身。它把整个查询当成一个子串，去拼接后的「路径 + 摘要 + 描述 + operationId」里找，找到 20 条就停。多个词只有恰好按这个顺序连在一起出现时才能命中，而 TikHub 的摘要是「获取用户的个人信息/Get user profile」这种写法，「tiktok user profile」三个词从来不连着出现。脚本里其实写了一个按关键词映射的 suggest_api 函数，可以把「user profile」扩成 fetch_user_profile，但命令行入口没有调用它。单个词能搜到东西，可是一搜就满 20 条，而且按文件顺序截断：「笔记」的 20 条里有 8 条已经下线，排在前面的不一定是你要的平台。

第三步「查详情」也有坑。SKILL.md 示例写的是 detail:tiktok_web_fetch_user_profile_get，我们照抄运行，返回「No API found」。快照里这个接口真正的 operationId 是 fetch_user_profile_api_v1_tiktok_web_fetch_user_profile_get，换成它才拿到 1,970 字节的参数说明。最后一步「调用」，SKILL.md 给了 4 个不同的示例调用，我们逐个和今天文档里的参数比对：

一个照示例学的代理，第一次调主页接口时会带上一个服务器不认识的 sec_user_id。TikHub 的接口用的是 FastAPI，今天的 openapi.json 里有 973 个接口声明了 422 校验错误，返回体是标准的 loc、msg、type 三个字段，能告诉你缺了哪个必填参数，但不会告诉你「你写的 post_id 其实应该是 itemId」。主页接口两个参数都是可选的，带一个不认识的参数会不会被静默忽略、会不会扣费，我们没有账户，没有测，只能写成未知。我们这边写错时的返回见后文「写错了会怎样」一节。

token 放在哪：三个环境变量名和一段写死的 token

先看最容易踩的一个：环境变量名。SKILL.md 的 Authentication 一节让用户「设置 TIKHUB_TOKEN 环境变量」，可 api_client.py 读的是 TIKHUB_API_TOKEN；TikHub 官方 Python SDK 和官方插件用的又是 TIKHUB_API_KEY，官方插件的配置文件里这个名字出现了 83 次。我们在本机只设 TIKHUB_TOKEN、不设另外两个，然后实例化 Helper 的客户端：它拿到的 token 长度是 0，请求头变成鉴权方案名后面跟一个空格、什么都没有。也就是说，严格照 SKILL.md 做的人，发出去的每个请求都不带 token，只会收到 401。

截图里第一个青绿框那句「请求会用一个默认 token」，是这个 Helper 早期版本留下的说法：早期版本曾把一段 token 直接写进代码，后来有贡献者提交修复，改成只从环境变量读，并合并进了主分支。修复本身做得对，可它漏改了 SKILL.md，所以今天的 SKILL.md 仍然告诉模型「请求会用默认 token」，而代码里已经没有这个默认值。模型读到这句，会以为不设环境变量也能调通，结果只拿到 401。

更麻烦的是 fork。我们用 GitHub 接口逐个读了这个仓库的 fork，只比对字符串的哈希，不复制、不试用那个值。结论只有一句：部分 fork 里仍带着早期写死的 token，建议作者轮换。这段 token 现在还能不能用，我们没有试，也不该试；拿别人泄露的 token 调接口，扣的是别人的钱。对用这个 Helper 的人来说，要记住的是另一面：你从 fork 或复制仓库装来的版本，未必是原仓库修好之后的版本。

GitHub 的文档对这种情况写得很直白：如果泄露的是密码、token 这类凭据，第一步是作废或轮换它，作废之后它就不能再用；只改写历史再强推，带凭据的提交仍然可以从任何克隆和 fork 里拿到，fork 里的那份要找 fork 的主人自己删。换句话说，原仓库的修复只修了以后，修不了已经散出去的副本，真正有效的一步是作废那把 token。

把这几件事合起来，给用 TikHub token 的人三条做法。第一，环境变量名以你实际运行的代码为准：用官方 SDK 或官方插件就设 TIKHUB_API_KEY，用社区 Helper 就设 TIKHUB_API_TOKEN，最稳妥的是把两个都设成同一把 token，别信 SKILL.md 里的 TIKHUB_TOKEN。第二，如果你是从 fork 或复制仓库装的 Helper，先在本地副本里搜一遍有没有写死的长字符串，有就删掉、改成从环境变量读，并且永远不要用别人留下的 token。第三，每个代理一把单独的 token，余额只放够用的钱，出事只作废那一把。我们这边推荐的写法是只在 MCP 配置里引用 ${EVERYINFRA_API_KEY}，Claude Code 的 MCP 文档说明 .mcp.json 支持这种环境变量展开，团队可以共享配置文件而不共享 Key。

api tikhub io 和 api.tikhub.dev：Python 自带的 urllib 为什么连不上

搜「api tikhub io」的人，多半是在代码或报错里看到了这个域名。api.tikhub.io 是 TikHub 的主域名，打开根路径是 Swagger 页面，可以填 token 在网页上试调；还有一个 api.tikhub.dev，Helper 把它叫「中国域名，绕过网络限制」，可 TikHub 的 README 在「域名与连接说明」里写的是请统一用 api.tikhub.io，尽量别用 api.tikhub.dev，后者可能更慢；如果请求超过 30 秒，请自己配代理。

真正挡住 Helper 的不是域名，是请求头。Helper 的 api_client.py 用 Python 标准库 urllib.request 发请求，没有设置 User-Agent，所以用的是 Python 文档里写的默认值「Python-urllib/版本号」。我们在 00:20:21 用 Helper 原样调健康检查接口 /api/v1/health/check（这个接口不需要 token），返回「HTTP 403: Forbidden」；接着带不同请求头直接请求同一个地址，结果如下图：Python-urllib 在 api.tikhub.io 和 api.tikhub.dev 上各试 2 次，全部 403，返回体只有一行「error code: 1010」，响应头 server: cloudflare；python-requests、python-httpx、curl 和浏览器请求头都是 200 {"status":"ok"}。

1010 是 Cloudflare 的错误码。Cloudflare 的说明页写的是「网站主人根据你的浏览器特征拒绝了访问」，常见原因里直接点名了「Python urllib 的默认 User-Agent」；它的浏览器完整性检查默认开启，会拦没有 User-Agent 或 User-Agent 不标准的请求。给出的解决办法是让客户端发一个能说明自己是谁的 User-Agent，比如「my-app/1.0」，不必伪装成浏览器。这个结果有边界：我们只从新加坡一个网络、在两个时刻测过，Cloudflare 的规则由 TikHub 自己配置，换地区、换时间可能不同；但两轮测试、两个域名的结果完全一致。

对 AI 代理来说，这个 403 比 401 更难处理。Helper 收到 403 时，因为返回体不是 JSON，只交回一行 {"error": "HTTP 403: Forbidden", "status_code": 403}，没有「1010」这个关键线索；它的 SKILL.md 错误表里只写了 401、429、连接错误和缺参数四种，没有 403；而 TikHub README 里 403 的四种原因是「没有这个路由的权限、账户被停用、邮箱没验证、token 缺少权限」。一个认真读文档的模型，几乎一定会把这个 403 当成 token 权限问题，让你去检查邮箱验证或者重建 token，而真正要改的只是一行请求头。修法也简单，在 _build_headers 里加一行 User-Agent：

# api_client.py 的 _build_headers：只加 User-Agent 这一行，其他不变
def _build_headers(self, content_type: str = "application/json"):
    return {
        "Authorization": f"Bearer {self.api_token}",
        "Content-Type": content_type,
        "User-Agent": "my-tikhub-agent/1.0",  # 不加这行，urllib 默认请求头会被 Cloudflare 以 1010 挡下
    }

我们也用同样的 Python-urllib 请求头测了 EveryInfra：00:26:04 读 TikTok 能力目录、00:26:05 请求 MCP 的工具列表，都是 200。同一段最朴素的 Python 代码，在一边能跑，在另一边会被挡；代理生成的脚本很多正是这种不加依赖的写法。

调一次要几步：Helper、官方 MCP 和 EveryInfra 远程 MCP

把前面几节串起来，看「让代理拿到一个 TikTok 账号的主页数据」这一件事，三种接法各要几步。Helper 一侧按修好环境变量、修好请求头之后的理想情况算；TikHub 官方 MCP 按它 MCP 页面给的配置算；EveryInfra 按我们今晚的真调算。

TikHub 官方 MCP 按平台拆成多个服务，平台列表不带 token 就能读：TikTok 163 个工具、抖音 319 个、Instagram 93 个、小红书 45 个。每个接口直接是一个工具，模型挑起来很直接，代价是连上抖音服务就要读 319 份工具说明。它的配置示例用 npx mcp-remote 把远程 HTTP 转成本地进程，鉴权写在 --header 参数里；官方插件的配置文件用 ${TIKHUB_API_KEY} 引用环境变量。下面是 TikHub 页面给的写法（Key 换成环境变量引用）和我们的写法，放在一起对照；客户端字段以你用的工具文档为准：

{
  "mcpServers": {
    "tikhub-tiktok": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.tikhub.io/tiktok/mcp",
               "--header", "Authorization: Bearer ${TIKHUB_API_KEY}"]
    },
    "everyinfra": {
      "type": "http",
      "url": "https://api.everyinfra.com/mcp",
      "headers": { "Authorization": "Bearer ${EVERYINFRA_API_KEY}" }
    }
  }
}

我们只有一个地址 https://api.everyinfra.com/mcp。00:21:08 不带 Key 请求它的工具列表，返回 12 个工具、16,247 字节；另有 12 个账户管理工具（用量、账单、Key 等）放在完整入口 /mcp/all，两边合计 24 个工具，见 /mcp-server。数据能力不按接口拆工具，而是统一走 everyinfra_call_api，用 platform 和 action 两个参数指定，例如 tiktok/profile。这样做的好处是工具列表小、新能力上线不用改配置；坏处是模型第一次要先查目录才知道有哪些 action。目录本身不要 Key：GET /api/v1/social/catalog?platform=tiktok&compact=1 只回 TikTok 一个平台，00:18:12 读到 6,835 字节，里面是 TikTok 全部能力的参数、单价和返回字段名。MCP 规范本身对这两种拆法都允许；2026-07-28 版规范的鉴权一节写明鉴权是可选的，两家都没有走 OAuth，都是请求头带 Key，这和 RFC 6750 推荐的 Bearer 头写法一致。

写错了会怎样：400、422 和 did_you_mean 实测

代理最常犯的错是用别家的命名习惯来调。我们故意模仿一个刚用过 TikHub 的代理：00:21:08（新加坡时间）发一个 action 写成 TikHub 风格 fetch_user_profile、参数写成 uniqueId 的请求，再发一个能力名对了、参数却用 Helper 示例里的 sec_user_id 的请求。前一个返回 400 unknown_capability，did_you_mean 是 profile，allowed 列出 TikTok 的全部 24 项数据能力（和上面 MCP 的 24 个工具是两回事），next_steps 写「用 profile 重发，没有扣费」；后一个返回 422 missing_param，next_steps 写「补上必填的 username（sec_user_id 在这里不是参数）」，并附一个能直接跑的 example。两次都没有扣费。

对比 TikHub：不带 token 时它先查鉴权，00:20:40 我们带着错参数 post_id 请求作品详情接口，返回 401，返回体回显了路由和参数，但不会先指出参数错了；带 token 时，按它的 openapi.json，缺必填参数会得到 FastAPI 的 422，告诉你缺的是哪个字段，不会给候选名。我们这边的顺序是先鉴权，再校验参数：没带 Key 返回 401，不让未鉴权的请求探出接口结构；带了 Key 以后，未知参数和非法取值返回 422，带支持的参数、允许的取值和 did_you_mean。这条规则的目的就是让调用方的 AI 能自己改对，而不是写错一次就扣一次钱。

三次真调：MCP 一次，curl 两次

最后是实际调用。我们挑了三项都是 $0.000556 一次的能力，覆盖两个平台、两种接法，每次记下新加坡时间、条数和 charged_usd。

三次合计扣 $0.001668。耗时要照实说：三次分别用了 30、38、19 秒，这是同步等结果的时间，适合代理在后台跑，不适合让人盯着页面等；TikHub 一侧我们没有账户，测不了它的耗时，它的 README 写的是超时设 30 到 60 秒。返回字段以目录里的 response_fields 为准，主页一项返回 16 个字段（follower_count、video_count 等），作品一项 30 多个字段，评论一项包括 like_count、reply_count、ip_location 和翻页用的 next_page_token。下面是第二次调用的 curl 写法，Key 只从环境变量取：

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"tiktok","action":"user_videos","params":{"username":"tiktok"}}'
# 返回 count: 10，billing.charged_usd: 0.000556

价格：同样 1,000 次 TikTok、抖音请求

比价只算一小笔，详细的价目拆解在 TikHub pricing 详解。TikHub 一侧用 00:18:13 读到的价目接口和 00:16 读到的定价页：本文对应的接口，TikTok 主页 fetch_user_profile、TikTok 作品列表 fetch_user_post、抖音评论 fetch_video_comments 都是每次 $0.001；TikTok 和抖音一共 658 个有价接口，其中 529 个是 $0.001。EveryInfra 一侧用上面三次真调的 charged_usd，都是 $0.000556。

按条算要加两点说明。TikHub 作品列表的 count 参数可以调大，每页条数多了，按条算就更便宜，调到多大我们没法测；我们的 tiktok/user_videos 每次 10 条，所以按条算差距缩小到 1.2 倍。TikHub 还有按日阶梯价：同一接口一天里第 1,000 次以后单价逐级降到 $0.0009、$0.0008，三万次以后是 $0.0005。我们把阶梯价换算成「一天调 N 次的平均每千次价」，一天 1 万次时是 $0.86，5 万次时是 $0.632，要到约 117,900 次才降到和我们一样的 $0.556，再往上 TikHub 更便宜。阶梯价只对允许打折的接口有效，TikTok 和抖音那 529 个 $0.001 的接口里允许打折的占 52.0%，抖音单条作品 fetch_one_video 就不打折。

所以结论要带条件：一个代理每天在同一个接口上调几千、几万次，用 EveryInfra 便宜；每天在同一个允许打折的接口上调到十几万次，TikHub 的阶梯价更低。我们的价格也有按月充值的折扣档，具体见定价页。另外 TikHub 定价页写明，通过 MCP 和浏览器扩展调用和直接调接口按同样的价扣费；我们这边也一样，MCP、SDK 和 curl 扣的是同一份 charged_usd，失败和空结果不扣。

把 token 交给 AI 代理之前：六项检查

前面几节分开讲了 token、限流、Helper 和报错，这里把它们收成一张交接前的检查表。不管你最后用 TikHub 还是 EveryInfra，这六件事都值得在代理第一次真调之前做完，每一项后面写了怎么验证。

第一，一个代理一把 token。TikHub 每人最多 100 把，我们这边经 Key 新建的 Key 每天最多 20 把，在控制台里建不受这个限制。分开之后，哪个代理花了多少钱、哪个代理被限流，在用量记录里一眼能分出来；某个代理的配置文件不小心进了公开仓库，只停用那一把，其他代理照常跑。验证方法：确认每把 token 只写在一个项目的环境变量里，不在两个项目之间共用。

第二，token 只放环境变量，不写进技能文件，也不明文写进配置文件。TikHub 官方插件和我们的插件都在配置里用 ${...} 引用变量，这是对的做法。社区 Helper 的历史说明了反面：早期写进代码的那段 token，原仓库后来删掉了，可部分 fork 里仍带着它。验证方法：在项目目录里搜「Bearer」和你 token 的前几位，结果里应该只剩变量名。

第三，变量名按实际运行的代码设。这一条听起来多余，但 Helper 的三处写法互相不一致：SKILL.md 写 TIKHUB_TOKEN，代码读 TIKHUB_API_TOKEN，官方 SDK 和官方插件用 TIKHUB_API_KEY。只设了 SKILL.md 里的那个名字，请求会带着一个空的 Bearer 头出去，TikHub 回 401，模型多半会以为 token 填错了，让你去重新生成一把。验证方法：调用前让代码打印 token 的长度，不打印值，长度为 0 就是变量名不对。

第四，先跑一次不花钱的请求。TikHub 的健康检查和价目接口不带 token 也能读，EveryInfra 的目录和 MCP 工具列表也不要 Key。用代理实际要用的那个 HTTP 客户端去请求一次，能把三类问题分开：请求头被挡（1010）、鉴权失败（401）、参数不对（422）。我们这次就是靠这一步，发现 urllib 默认请求头在 TikHub 两个域名上都过不去，而换成 curl 或 requests 都正常。

第五，把限流写进给代理的说明里。TikHub 的上限按接口算，74 个接口不是默认的每秒 10 次，最低每秒 1 次；我们的上限按账户算，默认每分钟 60 次。代理默认会尽量并行，要明确告诉它碰到 429 先等：我们的返回带 Retry-After，按给的秒数等就行；TikHub 的 429 说明只写了「Request too fast」，公开文档里没写要等多久，建议从 1 秒起逐次加倍等待。

第六，给余额设上限，并先算一遍最贵的调用。TikHub 1,471 个有价接口里，大多数每次 $0.001，但名字里带 xingtu 的 78 个抖音星图接口里，有 19 个每次 $0.02，抖音综合搜索 v2 每次 $0.01，同一把 token 下价差到 20 倍。我们这边每个能力的单价写在目录里，代理调用前可以先读。验证方法：让代理在调用前把要调的接口和单价列出来，你看一眼再放行；余额只充够这一轮用的金额。

这六项里，第三、四项在 EveryInfra 这边由服务端兜住一部分：变量名只有 EVERYINFRA_API_KEY 一个，插件、命令行工具和文档写法一致；写错能力名或参数时，返回里直接给出可用的名字和一份能照抄的示例，不用代理自己去翻文档。第一、二、五、六项两边都要你自己做，平台换了也一样，值得写进团队给代理用的固定说明里，每次新接一个代理都照着过一遍。

免费下载的数据分析 Skill 和 Helper 不是一回事

搜「tikhub api helper」的人，常常想要的是「装一个技能，让 AI 自己去拿数据、再分析」。这里要分清两类技能。Helper 这类是「调接口的说明书」，它告诉模型去哪找接口、怎么拼请求，本身不分析数据。EveryInfra 另外有一套数据分析 Skill，免费下载，用你自己的 AI 工具和模型，2026-10-15 发布的 v0.4.1 里有四个：电商商品分析、社媒内容表现、内容分类打标、评论洞察。它们本身不采集数据，数据要用 EveryInfra 的接口另外采，采集按次计费；用法和站内一份 SKILL.md 通用四个 AI 工具那篇里写的一样。调接口这一半，我们放在插件仓库里，2026-10-21 发了 v0.4.0，配置文件里引用的就是 ${EVERYINFRA_API_KEY}；2026-11-01 还在 PyPI 发了 everyinfra 0.3.0，带命令行和估价。

把采集和分析分开，对 token 管理也有好处：分析技能根本不需要 Key，只有调接口的那一步需要；你可以让分析在本地跑，让采集只用一把权限收紧的 Key。Helper 把「找接口」「拿 token」「发请求」「讲结果」写在同一个技能里，任何一步出错，模型都会在同一段上下文里来回试，最容易出现前面说的那种把 1010 当成 token 权限问题的误判。

还有一个容易忽略的差别是更新方式。Helper 的接口快照停在它最后一次推送（2026-07-08）时的样子，和 TikHub 今天的文档相比，多了 226 个它搜不到的接口，少了 288 个它还在推荐的接口；这些变化不会自动进入你本地装的那份技能，除非重新克隆，模型每次读到的都是旧清单。官方插件同样是本地文件，2026-06-15 发了 v1.1.0。我们把能力清单放在服务端：目录和 MCP 工具说明在调用时现读，加了平台或改了参数，代理下一次调用就能看到，本地不用升级。分析 Skill 那一半虽然是本地文件，但它只写怎么分析，不写接口名和参数，不会因为接口变化而过期。

什么时候 TikHub 更合适

照实写 TikHub 比我们强的地方。第一是接口覆盖：它今天的文档有 1,058 个路径，抖音星图、DOU+、小红书蒲公英、B 站花火这类达人营销和投放后台的数据，接口又多又细，这类达人营销后台接口它比我们多。第二是量大时的价格：同一个允许打折的接口每天调到十几万次以上，它的阶梯价低于我们。第三是起步门槛：最低充值 $5，比我们的 $10 档低；送的 $0.05 不限时。第四是原始字段：它返回平台原样的数据结构，比如站内上手实测那篇里，TikTok 粉丝数它给到个位，我们给的是取整后的数。第五是 Key 的数量：每人 100 把，按项目分账很方便；官方 Python SDK 2.2.0 的说明写着覆盖 1,048 个接口，有异步客户端。

第一点可以说得更具体。拿 Helper 快照和 TikHub 今天的文档对比，新增的 226 个接口里，B 站花火 45 个、抖音星图 V2 29 个、小红书蒲公英 20 个、DOU+ 17 个，几乎都是达人营销和投放后台方向；同一时间段里不见了的，主要是 LinkedIn（两组合计 77 个）、TikTok 广告 23 个，以及老版本的抖音和小红书网页接口。它的接口正在往营销后台扩，如果你的工作是给品牌找达人、看报价和投放数据，这一块它比我们深得多，价格也要按这些接口的单价单独看，不能套用每次 $0.001。

如果你已经在用 TikHub，不想换，本文能帮上的是三件事：用官方插件或官方 SDK，不用过期的社区 Helper；环境变量名按你实际运行的代码设；自己写的 Python 脚本记得设 User-Agent。如果你是第一次给 AI 代理接社媒数据，看重的是写错能自己改、失败不扣钱、一个地址接所有平台、每天几千到几万次的成本，那么 EveryInfra 更省事。

站内另外几篇和本篇分工不同：TikHub API Key、文档与 GitHub 上手实测讲 Key 在哪拿、文档多大、官方 SDK 还剩多少能用；TikHub pricing 详解拆了它一千多行价目；TikHub 替代方案和 /alternatives/tikhub 是整体对比。

行业动向

• 2026-10-22，Anthropic 把 Agent Skills 标准捐给 Agentic AI Foundation，Linux 基金会同日公告：已有 70 多个代理平台支持，发布了 100 万个技能、安装近 2.8 亿次。对读者意味着：同一份 SKILL.md 会被越来越多的工具读到，它里面写错的变量名和接口名，也会跟着 fork 和复制传得更远，就像本文的社区 Helper。
• 2026-10-24，Cloudflare 更新了 1010 错误说明，直接点名 Python urllib 默认请求头。对读者意味着：代理生成的不加依赖的脚本，先设 User-Agent 再上线。
• 2026-10-27，Google Cloud 发布 IAM Helper，用 Agent Skills 加 MCP 工具让代理自己排查 403、申请一小时的临时权限，改权限前要人确认。对读者意味着：代理碰到 403 会越来越倾向于「去要权限」；如果这个 403 其实是 1010 这种请求头问题，要权限是白忙，先看返回体分清 403 从哪来。
• 2026-10-28，GitHub 把 AI 识别的密钥接进推送拦截，公开预览、默认关闭。对读者意味着：能拦住以后写死 token 的推送，拦不住已经在 fork 里的。

常见问题

tikhub api token 在哪里创建？

（出处：Google 搜索联想词「tikhub api token」，2026-11-06 读取。）登录 TikHub 用户中心，点 API token 菜单创建，复制后放进 Authorization: Bearer 请求头，文档站 README 末尾「Get API Token」一节有原文，每人最多 100 把。旧版文档写过可以设权限范围、过期日期和手动停用，今天的公开文档没写怎么设，只在 401、403 的原因里出现这些状态。给 AI 代理用时，建议每个代理单独一把。

tikhub api helper 是 TikHub 官方的吗？

（出处：Google 搜索联想词「tikhub api helper」，2026-11-06 读取。）不是。排在前面的 tikhub_api_skill 属于一个个人账号，仓库描述里也没说自己是官方。TikHub 官方出的是 GitHub 组织 TikHub 下的 tikhub-plugin（v1.1.0，18 个技能）和官方 Python SDK。社区 Helper 的接口快照有 25.7% 已下线，客户端用 urllib 默认请求头会被挡，建议改用官方插件，或者照本文的两处修改再用。

api tikhub io 打不开或者返回 403 怎么办？

（出处：Google 搜索联想词「api tikhub io」「https api tikhub io」，2026-11-06 读取。）先看返回体：如果是「error code: 1010」，是 Cloudflare 按请求头拦的，给客户端设一个 User-Agent 就行，和 token 无关；如果是 JSON 里写着 token 缺权限、邮箱未验证，才是账户问题。TikHub 建议统一用 api.tikhub.io，请求超过 30 秒时自己配代理；api.tikhub.dev 可能更慢。

tikhub api key 和 token 是一回事吗？

（出处：Google 搜索联想词「tikhub api key」「tikhub api token」，2026-11-06 读取。）是同一个东西，TikHub 文档在不同地方叫法不同：文档站写「API Token」，教程页和新版 Python SDK 写「API key」，环境变量叫 TIKHUB_API_KEY。容易混的是变量名：社区 Helper 代码读 TIKHUB_API_TOKEN，它的 SKILL.md 却写 TIKHUB_TOKEN。另外 TikHub 的 AI 代理服务另有一套 Key，和数据接口的不通用。

tikhub github 上的技能能直接装吗？

（出处：Google 搜索联想词「tikhub github」，2026-11-06 读取。）官方的 tikhub-plugin 可以按 Claude Code 插件装，配置里用 ${TIKHUB_API_KEY}。社区 Helper 能装，但要先做三件事：设对环境变量名，在 api_client.py 加 User-Agent，再在本地副本里搜一遍有没有写死的 token；如果你装的是 fork 或复制来的副本，里面可能还留着早期写死的 token，不要用它。

tikhub ai api 是什么，能用同一把 Key 吗？

（出处：Google 搜索联想词「tikhub ai api」，2026-11-06 读取。）TikHub 另有一个测试中的 AI 代理服务，按 TikHub 自己的文档（站内上手实测那篇引用过），要在单独的站点注册、拿单独的 Key，和社交数据接口的 Key 不通用。本文讲的 token 只指数据接口的那一把。EveryInfra 的一把 Key 可以同时调数据、搜索和验证码，按产品在控制台单独关闭。

上手步骤

1. 打开 /docs，注册后在控制台建一把 Key，设成环境变量 EVERYINFRA_API_KEY；不想先充值，可以按 /pricing 的说明在 GitHub 点星领 $1 试用额度。
2. 不用 Key 先读目录：GET https://api.everyinfra.com/api/v1/social/catalog?platform=tiktok&compact=1，看 TikTok 和 抖音 各有哪些能力、单价多少。
3. 在你的 AI 工具里加 MCP：地址 https://api.everyinfra.com/mcp，鉴权头引用环境变量，配置见 /mcp-server。
4. 让代理先调 everyinfra_list_capabilities，再用 everyinfra_call_api 调 tiktok/profile 这类能力；写错时按返回的 did_you_mean 和 example 改，不扣费。

参考资料

1. README - English（API Token Introduction、HTTP Status Codes），TikHub 文档站，2026-11-06 读取，https://docs.tikhub.io/4592766m0
2. 自述文档 - 中文，TikHub 文档站，2026-11-06 读取，https://docs.tikhub.io/4579297m0
3. llms.txt（文档站目录），TikHub，2026-11-06 读取，https://docs.tikhub.io/llms.txt
4. TikHub API Swagger 页面，TikHub，2026-11-06 读取，https://api.tikhub.io/
5. openapi.json（V5.3.2，1,058 个路径），TikHub，2026-11-06 00:16 读取，https://api.tikhub.io/openapi.json
6. get_all_endpoints_info 价目接口（1,471 个有价接口、rate_limit 字段），TikHub，2026-11-06 00:18 读取，https://api.tikhub.io/api/v1/tikhub/user/get_all_endpoints_info
7. health/check 健康检查接口，TikHub，2026-11-06 00:20–00:26 请求，https://api.tikhub.io/api/v1/health/check
8. Pricing（阶梯价、RPS 计划、最低充值），TikHub，2026-11-06 读取，https://tikhub.io/pricing
9. Tutorials & FAQ（每人最多 100 把 Key、状态码），TikHub，2026-11-06 读取，https://tikhub.io/tutorials
10. Getting Started，TikHub，2026-11-06 读取，https://tikhub.io/getting-started
11. MCP Integration Guide，TikHub，2026-11-06 读取，https://tikhub.io/mcp
12. MCP platforms（各平台工具数），TikHub，2026-11-06 读取，https://mcp.tikhub.io/platforms
13. llms.txt（官网），TikHub，2026-11-06 读取，https://tikhub.io/llms.txt
14. tikhub 2.2.0，PyPI，2026-10-03 发布，https://pypi.org/project/tikhub/
15. tikhub 1.13.0（含 Scopes、Expire Date、Status 原文），PyPI，2024-12-05 发布，https://pypi.org/project/tikhub/1.13.0/
16. TikHub-API-Python-SDK，GitHub TikHub，2026-11-06 读取，https://github.com/TikHub/TikHub-API-Python-SDK
17. tikhub-plugin（v1.1.0），GitHub TikHub，2026-06-15 发布，https://github.com/TikHub/tikhub-plugin
18. tikhub-plugin 的 .mcp.json，GitHub TikHub，2026-11-06 读取，https://github.com/TikHub/tikhub-plugin/blob/main/.mcp.json
19. tikhub_api_skill 仓库，GitHub liangdabiao，2026-11-06 读取，https://github.com/liangdabiao/tikhub_api_skill
20. SKILL.md（95b2a10），GitHub liangdabiao，2026-07-08 版本，https://github.com/liangdabiao/tikhub_api_skill/blob/95b2a10199b77d461a2108785eb2c03569bc28c9/.claude/skills/tikhub-api-helper/SKILL.md
21. api_client.py（95b2a10），GitHub liangdabiao，2026-07-08 版本，https://github.com/liangdabiao/tikhub_api_skill/blob/95b2a10199b77d461a2108785eb2c03569bc28c9/.claude/skills/tikhub-api-helper/api_client.py
22. api_searcher.py（95b2a10），GitHub liangdabiao，2026-07-08 版本，https://github.com/liangdabiao/tikhub_api_skill/blob/95b2a10199b77d461a2108785eb2c03569bc28c9/.claude/skills/tikhub-api-helper/api_searcher.py
23. tikhub-api-helper，LobeHub Skills Marketplace，2026-11-06 读取，https://lobehub.com/skills/liangdabiao-tikhub_api_skill-tikhub-api-helper
24. TikHub API Skill，Shyft，2026-11-06 读取，https://shyft.ai/skills/tikhub-api-skill
25. Tikhub Skill by zeenie-ai，TypingMind，2026-11-06 读取，https://www.typingmind.com/skills/zeenie-ai-tikhub-skill
26. OpenCompany tikhub-skill 源码，GitHub zeenie-ai，2026-11-06 读取，https://github.com/zeenie-ai/OpenCompany/tree/main/server/skills/web_agent/tikhub-skill
27. Extend Claude with skills，Claude Code 文档，2026-11-06 读取，https://code.claude.com/docs/en/skills
28. Connect Claude Code to tools via MCP，Claude Code 文档，2026-11-06 读取，https://code.claude.com/docs/en/mcp
29. Donating Agent Skills to the Agentic AI Foundation，Anthropic，2026-10-22，https://www.anthropic.com/news/donating-agent-skills-to-the-agentic-ai-foundation
30. Agentic AI Foundation Announces Four New Projects，Linux Foundation，2026-10-22，https://www.linuxfoundation.org/press/agentic-ai-foundation-announces-four-new-projects-agent-skills-open-responses-openenv-and-opensandbox
31. Authorization（2026-07-28 版），Model Context Protocol 规范，2026-11-06 读取，https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
32. RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage，IETF，2012-10，https://datatracker.ietf.org/doc/html/rfc6750
33. RFC 6585 Additional HTTP Status Codes（429），IETF，2012-04，https://datatracker.ietf.org/doc/html/rfc6585
34. Error 1010，Cloudflare 文档，2026-10-24 更新，https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/error-1010/
35. Browser Integrity Check，Cloudflare 文档，2026-11-06 读取，https://developers.cloudflare.com/waf/tools/browser-integrity-check/
36. urllib.request，Python 文档，2026-11-06 读取，https://docs.python.org/3/library/urllib.request.html
37. Removing sensitive data from a repository，GitHub 文档，2026-11-06 读取，https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository
38. Push protection beyond predefined secret patterns，GitHub Changelog，2026-10-28，https://github.blog/changelog/2026-10-28-push-protection-beyond-predefined-secret-patterns/
39. Scale agents securely with IAM Helper Agent Skills and MCP Tools，Google Cloud，2026-10-27，https://cloud.google.com/blog/products/identity-security/scale-agents-securely-with-iam-helper-agent-skills-and-mcp-tools
40. EveryInfra 能力目录（TikTok，compact），EveryInfra，2026-11-06 00:18 读取，https://api.everyinfra.com/api/v1/social/catalog?platform=tiktok&compact=1
41. EveryInfra llms.txt，EveryInfra，2026-11-06 读取，https://api.everyinfra.com/llms.txt
42. everyinfra-agent-plugins（v0.4.0），GitHub everyinfra，2026-10-21 发布，https://github.com/everyinfra/everyinfra-agent-plugins
43. analysis-skills v0.4.1，GitHub everyinfra，2026-10-15 发布，https://github.com/everyinfra/analysis-skills/releases/tag/v0.4.1
44. everyinfra 0.3.0，PyPI，2026-11-01 发布，https://pypi.org/project/everyinfra/