apify-content-analytics – 内容表现数据分析 Skill

3周前更新 8 0 0 0

apify-content-analytics 是用于从 Apify 平台抓取和分析内容数据的 Skill,可帮助 AI Agent 获取网页内容、社交平台帖子等数据并进行统计与洞察,适合内容监控、竞品分析和数据采集场景。

Skill 安装

多 Agent 安装
npx skills add https://github.com/apify/awesome-skills --skill apify-content-analytics

使用 npx skills 快速安装,支持将 Skill 添加到多个兼容的 AI Agent。

Skill 调研报告

Skill 详细介绍

apify/awesome-skills#apify-content-analytics 是 Apify 官方维护的 awesome-skills 仓库中的一个 Skill,属于 Apify 平台生态下的技能集合。从名称和所属组织来看,它的目标场景与内容分析、内容数据采集或内容表现评估相关,可能借助 Apify 的爬虫与数据采集能力,对网页或平台上的内容进行结构化整理和分析。

它是什么

– 一个由 Apify 官方组织维护的 Skill,属于 awesome-skills 技能集合的组成部分。
– 定位偏向内容分析相关工作:对内容数据(如文章、页面、社媒帖子等)进行采集后的整理、统计或洞察。
– 依赖 Apify 平台能力(Actor、API、数据集等)的可能性较高,具体以该 Skill 官方说明为准。

它不是什么

– 不是独立的桌面软件或独立运行的服务,通常需要依托 AI Agent 加载使用。
– 不是通用爬虫框架的替代品,其核心目标更聚焦在内容分析任务上。
– 不能脱离 Skill 宿主环境单独使用。

核心用途

– 帮助 Agent 在处理内容类数据时,具备更贴近“内容分析”这一任务的结构化能力。
– 通常在需要把采集到的内容数据转化为可读结论、报表或摘要时使用。

适合的用户

– 需要做内容运营、内容表现分析、内容数据整理的用户。
– 已经在使用 Apify 平台,希望借助 AI Agent 提升内容分析效率的用户。
– 需要把内容数据转成结构化结果再交给下游处理的研究或增长团队。

不适合的需求

– 只需要通用网页抓取的用户,直接用抓取类 Skill 更合适。
– 完全不需要 Apify 生态、也不想接触 Apify 平台的任务。

由于当前没有获取到该 Skill 的 SKILL.md 原文,具体支持的分析维度、输入输出格式以及是否必须调用 Apify Actor,均以该 Skill 当前官方说明为准。

Skill 安全评估

总体判断:来自 Apify 官方组织仓库的 Skill,来源可信度较高,但仍需根据它实际调用的外部能力和权限做评估。

来源可信度

– 该 Skill 归属 Apify 官方 awesome-skills 仓库,属于官方组织维护的内容。
– 相比个人 fork、第三方转载或来源不明的 Skill,供应链风险相对较低。

需要重点关注的方面

– 网络访问:内容分析类 Skill 往往需要访问外部数据源,网络权限通常属于其正常用途,不必直接视为危险。
– 第三方 API / Token:如果 Skill 需要 Apify API Token 或类似凭证,注意不要硬编码到提示词、代码仓库或聊天记录中,建议通过环境变量或官方推荐的安全方式管理。
– Prompt Injection 风险:当 Skill 处理来自网页或第三方平台的原始内容时,原始内容可能包含引导性指令,需要在使用时保持警惕。
– 数据外发:如果 Skill 会把抓取到的内容发送到 Apify 或其他第三方服务,需要注意是否涉及敏感数据。

可降低风险的做法

– 如果只希望 Skill 帮助生成分析思路,可以关闭 Agent 自动执行网络请求的权限,由用户手动执行。
– 不要把 Apify Token、Cookie、账号密码等凭证以明文写进提示词。
– 在正式投入生产前,先用非敏感数据做一次试运行。

该 Skill 是否涉及 Shell、文件写入、Docker 等高权限操作,以其官方说明为准;在缺少可靠依据时不作断言。

Skill 使用要求

一、Agent / 客户端

官方没有公开完整的第三方 Agent 兼容列表。从 Agent Skill 的工作方式来看,支持 Skills 或类似指令加载机制的环境通常可以尝试使用,包括 Claude Code、Codex、Cursor、Trae、OpenClaw、WorkBuddy 等。不同 Agent 的加载方式和兼容程度不同,以对应 Agent 当前版本为准。

二、运行环境 / 依赖

| 项目 | 要求 |
|—|—|
| Agent | 支持 Skills 的 AI Agent |
| 网络 | 内容分析任务通常需要联网(以官方说明为准) |
| Apify 账号 | 如果 Skill 依赖 Apify 平台,可能需要 |

官方未明确列出的依赖项不作推测。Node.js、Python、Docker 等是否为硬性依赖,以该 Skill 当前官方说明为准。

三、权限

– 网络访问:内容分析任务通常为必需,具体以官方说明为准。
– 文件读取 / 写入:以官方说明为准。
– Shell:以官方说明为准。
– 浏览器 / Docker:以官方说明为准。

四、账号 / API Key

– Skill 本身是否需要 Apify 账号或 API Token,以官方说明为准。
– 如果 Skill 后续生成或操作的项目依赖 Apify 平台,则可能需要 Apify API Token,注意凭证安全。

最小使用条件

1. 一个支持 Skills 的 AI Agent。
2. 可用的网络环境。
3. 如依赖 Apify,需要有效 Apify 账号与 Token。

Skill 安装、使用与卸载教程

一、安装

可以直接复制本页面提供的 Skill 安装指令,粘贴到对应的 Agent 或终端执行。

如果不清楚自己的 Agent 如何安装,可以直接问当前 Agent:

如何安装 apify/awesome-skills#apify-content-analytics?

也可以按你的 Agent 环境询问:

如何在 Claude Code 中安装 apify/awesome-skills#apify-content-analytics?

如何在 Cursor 中安装 apify/awesome-skills#apify-content-analytics?

由 Agent 根据自身的 Skill 加载与管理机制给出安装步骤。如果该 Skill 存在特殊安装要求,以其官方说明为准。

二、安装后如何使用

安装后,在需要进行内容分析类任务时,用自然语言把这个 Skill 指出来即可。例如:

使用 apify-content-analytics,把这份内容数据的表现指标整理成一份可读的分析摘要。

使用 apify-content-analytics,分析这批网页内容,找出主题分布和高频关键词。

使用 apify-content-analytics,帮我设计一个针对内容表现的内容分析流程。

如果 Agent 没有正确加载该 Skill,可以显式说出 Skill 名称,或让 Agent 先确认该 Skill 是否已安装。

三、卸载

不同 Agent 的 Skill 安装位置和管理方式不同,通常没有统一的卸载命令。可以直接:

– 使用对应 Agent 或 Skill 管理器提供的删除方式,删除对应 Skill。
– 或者直接问当前 Agent:

如何卸载 apify/awesome-skills#apify-content-analytics?

常见问题

1. 安装后 Agent 没有识别这个 Skill,怎么办?

先确认 Agent 是否支持 Skills,并确认安装指令是否执行成功。可以显式说出 Skill 名称让 Agent 加载,或直接问 Agent 是否已经检测到 apify/awesome-skills#apify-content-analytics。

2. 可以同时安装到多个 Agent 吗?

多数情况下可以,只要各个 Agent 支持独立的 Skill 安装机制。不同 Agent 之间互不影响,以各自管理方式为准。

3. 使用这个 Skill 需要 Apify 账号吗?

如果该 Skill 依赖 Apify 平台的能力,通常需要 Apify 账号及 Token。具体以该 Skill 当前官方说明为准。

4. 中国大陆使用是否有网络要求?

如果 Skill 依赖 Apify 或境外数据源,中国大陆网络环境可能需要可访问对应服务的网络条件。具体以实际使用环境为准。

5. Skill 更新后需要重新安装吗?

取决于 Agent 的 Skill 管理方式。有些环境支持自动更新,有些需要重新执行安装指令。以对应 Agent 的当前机制为准。

6. 可以关闭 Shell 权限使用吗?

如果该 Skill 的核心流程不需要执行 Shell 命令,通常可以关闭 Shell 自动执行,由用户手动处理需要终端操作的部分。是否可行以官方说明与实际任务为准。

7. 这个 Skill 适合生产环境吗?

上线前建议先用非敏感数据做一次完整试运行,确认依赖、权限和数据流向都符合预期,再决定是否用于正式场景。

Skill 更新日志

版本列表
无版本号
chore:重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-orchestrator-actor-development 技能 (#72) * 添加 apify-orchestrator-actor-development 技能 构建 TypeScript Apify 编排器 Actor —— 使用 apify-orchestrator 库协调一系列子 Actor(可选带一个 LLM 步骤)。交互式脚手架流程, 包含 Apify MCP schema 发现、通过 maxTotalChargeUsd 设置每步成本预算, 以及 OpenRouter LLM 步骤。 Co-Authored-By: Claude Opus 4.7 * fix(apify-orchestrator-actor-development):修正成本跟踪、子任务状态检查和 MCP 字段名 对照实时 Apify 平台和 Apify MCP 服务器进行测量;以下每项更改 都有一次运行或一次调用作为依据,而非仅凭审查。 成本跟踪(返回的 Run 报告 $0): - `run.usageTotalUsd` 在 `.call()` 返回的对象上为 0,而且它不会随后 完整到达 —— 按事件付费的子任务在达到 SUCCEEDED 后数秒内仍会按 计费事件收费。实测:一个两项子任务在约 3 秒时读取为 $0.0020, 最终结算为 $0.0040,而一个同类子任务在 8 秒时仍读取为 $0。采用 返回值会使整个工作流的 `spent` 保持为 0,因此累计总额从未变动。 - 将每个子 Run 记录在账本中,并等待其费用稳定下来,而不仅仅是 变为非零;在每次预算决策前和退出时重新读取已记录的 Run, 这样延迟的费用仍能计入总额。 - 修正“累计总额可防止失控支出”的说法。在均分且子任务遵守其上限的 情况下,该保护无法在最后一步之前触发;它只是针对无上限步骤的 兜底,且仅当超支已及时累积完成时才有效。实测:一个无上限步骤 在总额 $0.0030 的情况下收费 $0.0040,而下一步仍然启动了。 子任务状态(失败的步骤看起来像空步骤): - FAILED、ABORTED 或 TIMED-OUT 的子任务返回的 Run 对象带有 dataset id, 读取该 dataset 会得到 [] 而非错误 —— 在一个 TIMED-OUT 子任务上实测。 模板直接调用 listItems(),因此失败的步骤被当作空步骤处理,工作流 在无数据的情况下报告成功。已添加 requireSucceeded() 以及一条描述 该失败模式的注意事项。 Apify MCP 字段名(在 apify-mcp-server 0.16.0、7 个 Actor 上实测): - `fetch-actor-details` 的参数是 `actor`,不是 `actorId`;`actorId` 会失败, 报错 "must have required property 'actor'"。 - 定价位于 `actorInfo.pricing`,不是 `pricingInfo`。对于按事件付费的 Actor, 它会逐项列出费用,这正是设定上限所需的信息。 - 描述中没有 REQUIRED 前缀(7 个 Actor 中 0 个);必填字段通过标准的 `inputSchema.required` 数组传递。两条指示 agent 高亮 REQUIRED 前缀字段的 说明指向了空处。 - 枚举列表不会截断到 200 字符:google-search-scraper 返回了全部 240 个 countryCode 值(480 字符)。 - 所有 7 个 Actor 都缺少 `outputSchema`,包括本技能自己的示例。 同时添加必需的 `metadata` 块(keywords、category: actor-development); 没有它,scripts/generate_agents.py 会无法通过目录 lint。 Co-Authored-By: Claude Opus 5 * chore:从技能 PR 中移除生成的目录文件 marketplace.json、agents/AGENTS.md 和 README 技能表由 SKILL.md frontmatter 生成,并在合并后由 bot 重新生成;技能 PR 只能触及 skills/apify-/ (validate-pr 范围检查)。 Co-Authored-By: Claude Opus 5 --------- Co-authored-by: Claude Opus 4.7 Co-authored-by: pavel242242
无版本号
chore:重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-blocked-scrape-triage 技能 (#84) * 添加 apify-blocked-scrape-triage 技能 针对返回空结果的抓取进行分诊:在花费任何成本之前,区分硬封锁、 托管质询、失效路径和渲染问题,然后按成本顺序升级,浏览器放在最后。 * 纳入关于分诊技能的审查反馈 - 在使用其质询标记之前先确认 CDN 供应商,并让正文覆盖缺失的响应头 - 解释为什么解除盲化的修复是一个 hook:Actor 输入不包含任何 Crawlee 的 session-pool 选项,这是对照构建 schema 实测的 - 将住宅代理探测设为需先询问,并优先选择免费的第二个观测点而非付费运行 * 将目录元数据移入 SKILL.md frontmatter 目录现在由 frontmatter 生成,因此 keywords 和 category 位于 SKILL.md 中, 手写的 marketplace.json 条目已移除。 * fix(apify-blocked-scrape-triage):修正实测结论、保护 pageFunction、设置 category 于 2026-09-21 对照实时平台验证;详情如下。 代码修复: - 两个示例 pageFunction 都未加保护地调用了 context.$。在响应没有 HTML 正文时 —— 例如空正文的 403,或 text/plain,即本技能所诊断的正是这种情况 —— context.$ 不是函数,pageFunction 会抛出异常。该项随后带有 #error, 与没有该 hook 的运行无法区分,因此 hook 的效果在下一行就被抵消了。 实测:一次运行中 6 次失败。现已加保护;当没有 HTML 时,依赖 $ 的字段返回 null。 已针对 403(可读状态,无抛出)和 HTML 页面(title、scripts、mountPoints、 offHostLinks 不变)重新测量。 修正的结论: - 该 hook 的标题数字将“携带字段的项”列引用为“已分类的拒绝”。根据技能 自己的表格,已分类计数从 0 -> 2,而 3 -> 6 是携带字段的项。 - `gotOptions.throwHttpErrors = false` 表格行并未测量任何设置:gotOptions 不在该 Actor 的 30 个输入字段中,且该 Actor 接受包含它的输入而不报验证错误, 并静默丢弃它。该行已移除,发现已在原处说明。 - application/json 和 application/xml 属于 cheerio-scraper 的默认 MIME 类型, 因此 JSON 端点根本不需要 additionalMimeTypes。该 Actor 在跳过错误中列出了 自己允许的列表。(该 Actor 发布的 schema 描述在这一点上已过时。) - 完整账户审批并非仅限浏览器:cheerio-scraper 和 web-scraper 也需要它, 因此这不是偏好其中一个而非另一个的理由。已添加到 Prerequisites, 因为其失败模式在那里很重要:stdout 带退出码 0。 新增: - proxyConfiguration 通过 MCP 是必需的,但通过 CLI 不是。 - CLI 接受 additionalMimeTypes,而 MCP 在任何编码下都拒绝它。 元数据: - category: data-extraction -> actor-development Co-Authored-By: Claude Opus 5 --------- Co-authored-by: pavel242242 Co-authored-by: Claude Opus 5
无版本号
chore:重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-jobs-data 技能 (#40) 添加 apify-jobs-data 技能:通过 agentx/all-jobs-scraper 跨 20+ 个招聘板 提取职位发布,具备跨板去重、启发式幽灵职位和转载标记、规范化字段, 以及在其之上的分析 / 导出 / 简历匹配模式。 在维护者对贡献者分支进行一轮审查后合并:验证了实时 Actor schema 和定价, 按 Actor 修正了上限字段名,删除了 Google Jobs 承诺(不在聚合器枚举中), 在没有捏造证据的情况下重建了简历匹配示例,围绕抓取的职位描述添加了 提示注入边界,并解决了路由矛盾,使一个返回区域内无结果的具名招聘板 获得一次有上限的回退运行,而不是被直接放弃。 通过对照 Actor 自身文档的成对评估验证(9 月 16 日和 21 日): 0 个捏造值,每个统计量都可从记录重新计算,7 次 Actor 运行中无策略偏差。 Co-authored-by: oleg martinez Co-Authored-By: Claude Opus 5
无版本号
chore:重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-app-store-intelligence 技能 (#89) 两次提交:技能由 @donnywin85 提供,以及一次维护者提交,纳入了来自 #41 和 #54 的 Google Play 工作。 取代: - #41 由 @Freshactors 提供 —— freshactors/google-play-scraper mode=details,带 1–5★ ratingHistogram、按模式成本模型,以及跨商店标识符速查表 - #54 由 @0xsline 提供 —— neatrat recentDays 用于硬日期窗口,以及 sortBy "newest" / appVersion 作为真实输入字段
无版本号
feat(apify-app-store-intelligence):纳入 #41 和 #54,对照实时 API 修正路由事实 - 来自 #41 的 Google Play 模块(@Freshactors):freshactors/google-play-scraper mode=details, 带 ratingHistogram,$0.002/app,按模式成本模型和跨商店标识符速查表 - 来自 #54 的 Google Play 窗口事实(@0xsline):neatrat recentDays,以及 sortBy "newest" / appVersion 是真实输入字段,尽管该 Actor README 记录的是其他字段 - 路由表现在为每个被路由的 Actor 都带有上限和价格(价格读取自 2026-09-18 的实时 Actor 定价),包括此前留作 "see schema" 的 fail-open 默认值 - Apple 确实发布 1-5 星直方图:sourabhbgp/apple-app-store-scraper mode=app-details 返回 ratingsHistogram,其总和等于 userRatingCount;includeVersionHistory 不额外收费 (2026-09-19 实测:有无均为 $0.004) - changesOnly 按其实际行为记录:该模式下的首次运行会输出每个应用并作为基线, 快照在整个 Apify 账户间共享,评分以 5 位小数精度进行差异比较,且源被边缘缓存 约 24 小时,因此同日的版本更新可能被遗漏 - apify actors info 接受 --input 而不需要 --json(CLI 1.10.0 否则会隐藏 schema) - brilliant_gum 版本可以是字面量 "VARY";评论文本标记为不可信内容 - 目录产物(marketplace.json、README 表格、agents/AGENTS.md)已还原为 main; bot 会在合并后从 SKILL.md frontmatter 重新生成它们 Co-Authored-By: Claude Opus 5
无版本号
chore:为 apify-app-store-intelligence 重新生成目录 该技能在 d32f471 中添加时未重新生成生成的目录,因此 marketplace.json、 agents/AGENTS.md 和 README 技能表未列出它。PR 工作流会重新生成目录并 进行比较;fork PR 的 token 无法将结果推送回去,因此该作业会失败而非自愈。 由 scripts/generate_agents.py 生成,无手动编辑: 写入 14 个插件。纯新增 —— 26 处插入,0 处删除。 Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01MQCHGvdKdAa9fZroPjrXte
无版本号
fix(apify-osint-threat-intel):替换已弃用的租赁 Reddit Actor,强制时效性,设置新闻时间范围 (#125) * fix(apify-osint-threat-intel):将已弃用的 trudax/reddit-scraper 替换为 harshmaur/reddit-scraper trudax/reddit-scraper 在商店中已弃用(租赁,$45/月)。将三个 Reddit 步骤路由到 harshmaur/reddit-scraper,它已是此处的回退方案,也是 apify-easy-competitive-intelligence 中 main 上的回退方案,其输入已通过实时运行验证:withinCommunity 只接受一个 subreddit ("A OR B" 值会静默丢弃过滤器并搜索整个 Reddit),postedAfter 强制窗口 (searchTime 不会 —— 该 Actor 会用多年前的帖子填充上限),maxPostsCount 是按搜索词计的, 没有 proxy 字段。Troubleshooting 现在指向 RUN-SUMMARY(inputWarnings、emptyReason) 以及 fatihtahta/reddit-scraper-search-fast 作为按项付费的回退方案。 Co-Authored-By: Claude Opus 5 * fix(apify-osint-threat-intel):在 google-news-scraper-fast 示例中设置 timeframe 该 Actor 的 `timeframe` 默认为 `1h`,因此除非模型猜中该字段,"recent activity" (2c) 和 "landscape" (2d) 新闻调用几乎返回不了任何内容。为威胁行为者活动设置 `30d`, 为每周 landscape 设置 `7d`,与评估运行(E3、E4、E8、E9)不得不手动添加的内容一致。 Co-Authored-By: Claude Opus 5 --------- Co-authored-by: Claude Opus 5
无版本号
chore:重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-reddit-scraper 技能 (#114) * feat:添加 apify-reddit-scraper 技能 * fix(apify-reddit-scraper):按词成本公式、相对时间段的 postedAfter、实时 schema 事实 在作者设计之上的维护者文本修正(无结构性更改): - maxPostsCount 是按搜索词计的;成本公式 = 词数 × maxPostsCount × (1 + maxCommentsPerPost), 附来自实时运行的示例计算 - "last month" → postedAfter(强制 sort=new),并说明与 searchTime 的权衡 - 运行前显示可见的运行部分(词数、估算);运行后检查估算 ≥ 结算值 - dataType user → user_profile;帖子上的 searchTerm 为 null,评论上缺少 postTitle; removed_by 为 snake_case - 错误行与实时 README 一致(错误日期 = fail-open,无目标 = 0 项) - aiAnalysis 在 Free 上计费;UGC 防护语句;--user-agent 仅在可接受处使用 在三次隔离的评估运行中测量(R4/R4b/R4c,0 个捏造值)。 Co-Authored-By: Claude Opus 5 --------- Co-authored-by: Harsh Maur Co-authored-by: Pavel Chocholous Co-authored-by: Claude Opus 5
无版本号
chore:重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
还原手动目录重新生成 目录文件由合并后重新生成工作流负责。此操作还原 e1245ea,以便修复后的 GITHUB_TOKEN 作业能够证明完整流程。
无版本号
Merge pull request #124 from apify/codex/use-github-token-catalog-regen 使用 GITHUB_TOKEN 修复目录重新生成
无版本号
fix:使用 GitHub token 重新生成目录
无版本号
为 apify-plan-travel 重新生成目录
无版本号
Merge pull request #123 from apify/codex/consolidate-apify-travel-skills 添加整合后的 Apify 旅行规划技能
无版本号
添加整合后的 Apify 旅行规划技能
无版本号
Merge pull request #69 from johnisanerd/add-apify-yandex-search-api 添加 apify-yandex-search-api 技能
无版本号
将 Yandex Images 合并到 main 后重新生成目录
无版本号
Merge pull request #70 from johnisanerd/add-apify-yandex-image-search-api 添加 apify-yandex-image-search-api 技能
无版本号
合并 main 并应用已审查的 Yandex 图像技能修正
无版本号
合并 main 并应用已审查的 Yandex 网页技能修正
无版本号
Merge pull request #106 from johnisanerd/add-apify-company-data-api 添加 apify-company-data-api 技能
无版本号
Merge pull request #107 from johnisanerd/add-apify-marketing-agency-database 添加 apify-marketing-agency-database 技能
无版本号
应用已审查的 Clutch 技能修正并重新生成目录 (#106)
无版本号
应用已审查的 Clutch 技能修正并重新生成目录 (#107)
无版本号
Merge pull request #93 from luispintoapify/add-apify-product-data-setup 添加 apify-product-data-setup 技能

暂无评论

none
暂无评论...