Apify 网页抓取与自动化平台 Skill
Apify 是以 Actor（跑在云端的爬虫/自动化程序）为核心的市场，本 skill 只覆盖"不管跑哪个 Actor 都要用到"的平台机制，不收录具体 Actor 的输入字段。两个最容易踩的坑：status: SUCCEEDED 只代表进程正常退出，不代表真的抓到了数据；计费也不是"每次调用固定几个 credit"，而是 compute unit 叠加 Actor 自选的四选一定价模型，同一任务换个 Actor 花费可能差几十倍。
Authorization: Bearer <APIFY_API_TOKEN>，公开只读 GET 可以不带Agent 工具更新 2026-09-21安装
选你用的 Agent，复制命令。
npx -y skills add fxp/skillify --skill apify --agent claude-code --yes装到项目的 .claude/skills/；加 -g 装到全局。装完需要你手动执行 /reload-plugins，这一步 Agent 代劳不了。
npx -y skills add fxp/skillify --skill apify --agent codex --yes装到项目的 .agents/skills/；加 -g 装到全局。
npx -y skills add fxp/skillify --skill apify --agent cursor --yes装到项目的 .agents/skills/；加 -g 装到全局。
npx -y skills add fxp/skillify --skill apify --agent opencode --yes装到项目的 .agents/skills/；加 -g 装到全局。
npx -y skills add fxp/skillify --skill apify --agent gemini-cli --yes装到项目的 .agents/skills/；加 -g 装到全局。
npx -y skills add fxp/skillify --skill apify --agent github-copilot --yes装到项目的 .agents/skills/；加 -g 装到全局。
npx -y skills add fxp/skillify --skill apify --agent trae --yes装到项目的 .trae/skills/；加 -g 装到全局。
npx -y skills add fxp/skillify --skill apify --agent windsurf --yes装到项目的 .windsurf/skills/；加 -g 装到全局。
npx -y skills add fxp/skillify --skill apify --agent qwen-code --yes把 --agent 换成你用的 Agent 标识，可以一次写多个。skills CLI 1.5.25 共支持 79 个，例如 qwen-code、kimi-code-cli、trae-cn、qoder、lingma、cline、roo。
或者让 Agent 自己装
读 https://github.com/fxp/skillify/blob/main/skills/apify/prompt.md 并照它执行装对了的标志：references/ 下有 7 份文档。
装好后，可以这样问你的 Agent
这份 Skill 覆盖的典型任务。点一下复制。
7 类能力
每类能力对应一份 reference，Agent 按任务只打开需要的那份。
启动 Actor 与生命周期
同步/异步三种启动方式怎么选、run 状态机、status=SUCCEEDED 不等于抓到数据、用 Actor Task 保存输入配置复用
读取运行结果
Dataset 表格型结果 vs Key-value store 单值/文件型结果怎么选、分页参数、批量写入 schema 校验失败为何拒绝整批
从 Store 挑选 Actor
GET /v2/store 的搜索/筛选参数、responseFormat=agent 省 token 的精简字段、includeUnrunnableActors 默认过滤行为
Webhook 通知
持久生效的标准 webhook 和一次性 ad-hoc webhook 的区别、事件类型、重试策略与自定义 payload 模板
Request Queue
什么场景才需要直接操作队列、批量入队的去重规则、和 Dataset/KV store 不同的单消费者并发限制
定价与计费
compute unit 怎么算、四选一的 Actor 定价模型、用 maxTotalChargeUsd 封顶花费、查用量的 API
错误与限流
统一错误信封与它的例外端点、HTTP 状态码速查、三套并存的分页约定、限流阈值与官方退避策略
当前事实
整理自官方文档（抓取于 2026-09-21），还没有用真实凭证验证。
| 项 | 值 |
|---|---|
| Base URL | https://api.apify.com/v2；文档站在 docs.apify.com，别对着它发请求；旧前缀 /v2/acts/ 仍可用，新代码用 /v2/actors/ |
| 30 秒跑通 | POST /v2/actors/{actorId}/run-sync-get-dataset-items 直接返回条目数组，最长等 300 秒（MAX_ACTOR_JOB_SYNC_WAIT_SECS），超时只是这次请求失败，后台 run 仍在跑 |
| 两个包都叫 Apify SDK | 调平台 API 装 apify-client；自己写一个跑在平台上的 Actor 才装 apify（配合 crawlee）——两者输入输出、鉴权完全不同 |
| compute unit | 1 CU = 1GB 内存 × 1 小时，memory 参数必须是 2 的幂（最小 128MB），叠加代理/存储/传输才是总平台用量 |
| 分页两套不同约定 | Dataset items 用 offset/limit（limit 文档原文写"默认不限制条数"）；Key-value store 的 .../keys 用 exclusiveStartKey 游标，不能混用 |
照通用经验写容易错的 6 件事
来自官方文档，还没有用真实凭证验证。
status: SUCCEEDED不等于业务上抓到了有意义的数据。目标站点把请求全拦截、搜索词零匹配，Actor 依然能正常退出得到SUCCEEDED；要判断真的达成目的，还得看statusMessage/exitCode，以及实际检查 dataset 条目数或OUTPUT记录是不是空的。apify-client和apify是两个不同的包，都叫 "Apify SDK"。调用别人写好的 Actor 用apify-client；自己开发一个跑在平台上的 Actor 才用apify（配合crawlee）——装错包代码根本跑不起来。- 成本不能按"每次调用固定花费"估算。基本单位是 compute unit，叠加 Actor 开发者自选的四种定价模型之一（免费/纯平台用量/
PAY_PER_EVENT/包月租用，且包月模式 2026-10-01 起全面下线）；同一任务换个 Actor 花费可能差几十倍，开跑前先看该 Actor 的 Pricing 区块，预算敏感场景传maxTotalChargeUsd封顶。 - 三个端点的响应形状互不相同，混用解析代码会直接崩。异步
POST /v2/actors/{actorId}/runs包在{"data": {...}}里；run-sync-get-dataset-items直接返回条目数组；run-sync返回的是 KV storeOUTPUT记录的原始内容。 - 对一个已有 runId 做后续操作要切到新命名空间。
/v2/actors/{actorId}/runs/{runId}/...下的 get/abort/reboot 等操作已标为[DEPRECATED]，官方建议改用/v2/actor-runs/{runId}/...；但启动新 run 仍然用POST /v2/actors/{actorId}/runs，这个端点本身没有废弃。 - 写数据集时一条校验失败会拒绝整批。如果目标 dataset 定义了 schema 校验，
POST /v2/datasets/{datasetId}/items批量传入的条目里只要有一条不合规，整个请求 400，不是"跳过坏的写入好的"——错误响应里的error.data.invalidItems[].itemPosition能定位是第几条。