apify-market-research

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 的子任务返回一个带 dataset id 的 Run 对象，读取该数据集会得到 [] 而非错误 —— 在一个 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 的标题数字将 "items carrying fields" 列引用为 "classified refusals"。根据本技能自己的表格，classified 计数从 0 -> 2，而 3 -> 6 是 items carrying fields。 - `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" 的故障开放默认值 - 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 是按搜索词计的；成本公式 = terms × maxPostsCount × (1 + maxCommentsPerPost)， 附来自实时运行的示例计算 - "last month" → postedAfter（强制 sort=new），并明确说明与 searchTime 的权衡 - 运行前显示可见的运行部分（terms、estimate）；运行后检查 estimate ≥ settled - dataType user → user_profile；帖子上的 searchTerm 为 null，评论上缺少 postTitle； removed_by 为 snake_case - 错误行与实时 README 一致（错误日期 = 故障开放，无目标 = 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 任务能够证明完整流程。

合并拉取请求 #124，来自 apify/codex/use-github-token-catalog-regen 使用 GITHUB_TOKEN 修复目录重新生成

fix：使用 GitHub token 重新生成目录

为 apify-plan-travel 重新生成目录

合并拉取请求 #123，来自 apify/codex/consolidate-apify-travel-skills 添加整合后的 Apify 旅行规划技能

添加整合后的 Apify 旅行规划技能

合并拉取请求 #69，来自 johnisanerd/add-apify-yandex-search-api 添加 apify-yandex-search-api 技能

将 Yandex Images 合并到 main 后重新生成目录

合并拉取请求 #70，来自 johnisanerd/add-apify-yandex-image-search-api 添加 apify-yandex-image-search-api 技能

合并 main 并应用经审查的 Yandex 图像技能修正

合并 main 并应用经审查的 Yandex 网页技能修正

合并拉取请求 #106，来自 johnisanerd/add-apify-company-data-api 添加 apify-company-data-api 技能

合并拉取请求 #107，来自 johnisanerd/add-apify-marketing-agency-database 添加 apify-marketing-agency-database 技能

应用经审查的 Clutch 技能修正并重新生成目录（#106）

应用经审查的 Clutch 技能修正并重新生成目录（#107）

合并拉取请求 #93，来自 luispintoapify/add-apify-product-data-setup 添加 apify-product-data-setup 技能