apify-brand-reputation-monitoring – 品牌声誉监控 Skill

3周前更新 9 0 0 0

Apify 品牌声誉监控 Skill 用于帮助 AI Agent 采集并分析各平台上与品牌相关的评论、提及和舆情数据,适合需要跟踪品牌口碑、发现负面反馈或监测声誉动态的营销与运营场景。

Skill 安装

多 Agent 安装
npx skills add https://github.com/apify/awesome-skills --skill apify-brand-reputation-monitoring

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

Skill 调研报告

Skill 详细介绍

apify/awesome-skills#apify-brand-reputation-monitoring 是 Apify 官方 “awesome-skills” 仓库中的一个 Skill,从名称和所属组织可以判断,它的核心用途是品牌声誉监控——也就是通过 Apify 平台上的采集能力,持续追踪某个品牌、公司或关键词在公开网络上的提及、评价和舆情动向。

它本身不是一个独立运行的软件,也不是一个搜索引擎或舆情数据库。更准确地说,它是一个面向 AI Agent 的“技能包”:安装之后,Agent 就获得了围绕“品牌声誉监控”这类任务去组织工作流、调用 Apify 相关采集能力的能力。真正执行抓取和数据获取的是 Apify 平台上的 Actor 与 API,Skill 负责的是把这类任务的方法、步骤和调用方式交给 Agent。

核心能力方向

– 围绕品牌、公司名、产品名或关键词,在公开网络来源中搜集提及与讨论
– 对多个来源(如搜索结果、社交媒体、评论、新闻等,具体取决于所调用的 Apify Actor)进行采集
– 把分散的提及整理成可阅读、可分析的监控结果
– 支持周期性或批量监控类任务,便于持续跟踪声誉变化

它解决的问题

品牌声誉相关的信息通常散落在搜索引擎、社交平台、评论区、新闻报道等多个位置,人工逐一看成本高、容易遗漏。这个 Skill 的价值在于:把“如何系统地找到并整理这些提及”这件事,交给 Agent 按固定流程去做。

和 Agent 自身能力的区别

普通 Agent 可以在你给出链接或文本时帮你分析舆情,但它本身不负责去外部平台大规模采集。这个 Skill 补上的正是“采集 + 组织监控流程”这一段,而采集能力来自 Apify 平台。

适合谁

– 做品牌、公关、市场监测的人
– 需要跟踪自家或竞品公开口碑的团队
– 想用 Agent 自动跑周期性声誉检查的用户

不适合什么

– 不适合需要权威、付费、受版权保护的数据源(如专业舆情厂商的私有库)的场景
– 不适合期望完全不依赖第三方平台、纯本地运行的需求
– 不适合需要法律意义上精确判定“是否侵权、是否违法”的场景,那需要人工和专业工具

需要说明的是,该 Skill 的具体抓取来源、支持的平台范围、依赖的 Apify Actor 清单,以 Apify 官方仓库中的当前说明为准。如果官方资料没有明确列出某个平台,就不要默认它一定支持。

Skill 安全评估

总体判断:来自 Apify 官方组织仓库,来源可信度较高;由于它涉及调用第三方平台(Apify)并可能消耗额度、访问外部网络,安全性主要取决于你如何配置凭证和权限,而不是 Skill 本身“危险”。

一、来源可信度

它属于 Apify 官方维护的 awesome-skills 仓库。选择官方来源而不是第三方 fork、镜像或同名转载版本,是降低风险的第一步。请确认安装的是 apify/awesome-skills 下的这个 Skill,而不是名字相似的第三方项目。

二、第三方平台依赖

这个 Skill 的工作依赖 Apify 平台。这意味着:

– 需要网络访问 Apify 服务
– 很可能需要 Apify 账号和 API Token(具体以官方说明为准)
– 采集任务会消耗你 Apify 账号的额度 / 计费

API Token 是敏感凭证。泄露可能导致他人用你的账号跑任务、消耗你的额度。建议:不要把 Token 写进公开代码或提交到仓库,使用环境变量或 Agent 的密钥管理方式来存放,并定期在 Apify 后台轮换。

三、网络访问

作为采集类 Skill,它需要联网访问外部站点和目标数据源。联网本身不是问题,但你要清楚:Agent 可能会在无人监督的情况下发出请求。对访问量较大、频率较高的任务,注意目标站点的使用条款和访问频率限制。

四、Shell 与文件权限

如果 Agent 在执行过程中需要运行命令、读写本地文件,取决于你所在 Agent 的默认权限设置。如果只是想让它帮你规划监控任务或整理已有数据,可以关闭 Agent 的自动执行 Shell 权限,由你手动执行相关操作。

五、数据合规

品牌声誉监控涉及抓取公开网络内容。请自行确认你的采集行为符合目标站点的服务条款、 robots 规则以及适用的数据保护法规。Skill 不替你做合规判断。

降低风险的建议

1. 只从 Apify 官方 awesome-skills 仓库安装,避免第三方同名版本
2. 用专用、可撤销的 Apify Token,并控制其权限与额度
3. 不要把 Token 硬编码到会被分享的文件里
4. 监控任务从小规模、低频率开始,确认行为符合预期再扩大
5. 涉及个人数据或敏感内容时,先确认合规再执行

不要把这个 Skill 理解成“100% 安全”或“已通过全面安全审计”。它的风险点主要来自第三方平台调用和凭证管理,需要你自己把关。

Skill 使用要求

一、Agent / 客户端

该 Skill 以 Agent Skill 的形式存在,主要在支持 Skills / 自定义技能加载机制的 AI Agent 中使用。官方没有公布完整的第三方 Agent 兼容列表。

– 如果你的工作流围绕 Claude Code,可以优先在 Claude Code 中尝试,这类Agent Skill 与 Claude Code 的加载方式通常衔接较自然。
– Codex、Cursor、Trae、OpenClaw、WorkBuddy 等:如果它们支持 Skills、自定义 Skill 或类似的指令加载机制,通常也可以尝试使用。不同 Agent 的加载方式和兼容程度可能不同,具体以对应 Agent 当前版本为准。

需要区分:这是“通常可以尝试”,不等于官方明确支持上述每一个 Agent。

二、运行环境 / 依赖

| 项目 | 要求 |
|—|—|
| Agent | 支持 Skills / 自定义技能的 Agent |
| 网络 | 需要,用于访问 Apify 及目标数据源 |
| Apify 账号 | 大概率需要,用于调用采集能力与计费(以官方说明为准) |
| Node.js / Python | 官方未明确必需;是否需要取决于 Skill 的调用方式 |

官方没有明确说明 Node.js、Python 的具体版本要求,因此这里不给出具体版本号。以该 Skill 当前官方说明为准。

三、权限

– 网络访问:必需(采集与调用 Apify)
– Apify 凭证(API Token):大概率必需(以官方说明为准)
– 文件读写 / Shell 执行:不是该 Skill 功能的必然要求,取决于你的 Agent 权限设置,可按需关闭

四、账号 / API Key

要区分两层:

– Skill 本身:其功能依赖 Apify 平台,因此大概率需要 Apify 账号与 API Token
– 你用 Skill 去监控的目标:通常不需要额外账号,公开内容一般可直接采集

具体需要哪种凭证、如何配置,以 Apify 官方说明为准。

最小使用条件

1. 一个支持 Skills 的 Agent 环境
2. 可用的网络连接
3. 一个可用的 Apify 账号与 API Token(以官方说明为准)

Skill 安装、使用与卸载教程

一、安装

本页面已经单独提供该 Skill 的安装指令,直接复制并粘贴到对应 Agent 或终端执行即可。

如果你不确定自己的 Agent 该怎么安装,可以直接问当前 Agent:

如何安装 apify/awesome-skills#apify-brand-reputation-monitoring?

如何在 Claude Code 中安装 apify/awesome-skills#apify-brand-reputation-monitoring?

如何在 Cursor 中安装 apify/awesome-skills#apify-brand-reputation-monitoring?

让 Agent 根据自己的 Skill 加载 / 管理机制给出安装步骤。如果该 Skill 有特殊官方要求(例如必须配置 Apify Token),按官方说明补充即可。

二、安装后如何使用

安装完成后,用自然语言把任务交给 Agent 即可,不需要记忆特定命令。适合交给它的任务类型包括:追踪某品牌的公开提及、整理某关键词的舆情、周期性检查口碑变化。

自然语言使用示例:

使用 apify-brand-reputation-monitoring,帮我监控“某某品牌”最近一周在公开网络上的提及和评价。

使用 apify-brand-reputation-monitoring,整理一下这个品牌当前的主要负面讨论点。

使用 apify-brand-reputation-monitoring,帮我对比我们和竞品近期的公开口碑。

向 Agent 描述需求时,尽量说清楚:监控对象、时间范围、关注的来源类型和输出形式,结果会更贴合预期。

三、卸载

保持简单即可:

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

如何卸载 apify/awesome-skills#apify-brand-reputation-monitoring?

不同 Agent 的 Skill 安装位置和管理方式可能不同。如果没有统一的卸载命令,直接问当前 Agent 如何移除通常更稳妥。

常见问题

1. 这个 Skill 会把我的 Apify Token 上传到别处吗?

Skill 调用 Apify 服务需要凭证。Token 主要用于你与 Apify 之间的认证。稳妥做法是把 Token 放在环境变量或 Agent 的密钥管理里,不要写进会公开分享的文件,并定期轮换。

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

该 Skill 需要访问 Apify 平台,可能还涉及目标数据源。Apify 属于境外服务,中国大陆网络环境下访问境外服务可能需要自行确认连通性。这一点以你的实际网络环境为准。

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

先确认安装确实成功、路径正确,再确认当前 Agent 版本支持 Skills / 自定义技能加载。不同 Agent 的识别方式不同,可以直接问当前 Agent“为什么没有加载到这个 Skill”,让它根据自身机制排查。

4. 是否可以同时安装到多个 Agent?

一般可以,只要各个 Agent 各自支持 Skill 安装。但要注意凭证配置和额度消耗是按 Apify 账号计量的,多个 Agent 同时跑任务会更耗额度。

5. 这个 Skill 会修改我本地的项目文件吗?

它的核心功能是采集与整理公开网络信息,不以修改本地项目为目的。但如果你的 Agent 被授予了文件写入权限,理论上仍可写文件。想避免的话,可以关闭 Agent 的自动写入权限。

6. 适合在生产环境长期跑品牌监控吗?

取决于你的需求和对第三方平台依赖的接受度。它适合做周期性的公开口碑检查。若要用于正式的公关或合规决策,建议把结果作为参考之一,关键结论仍需人工复核。

7. 更新后需要重新安装吗?

视你的 Agent 和 Skill 管理方式而定。有些环境会自动同步更新,有些需要手动重新安装。不确定时,直接问当前 Agent 如何处理该 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 的子任务返回一个带有 dataset id 的 Run 对象,读取该 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 的标题数字将 "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, 带有 $0.002/app 的 ratingHistogram、按模式成本模型和跨商店标识符速查表 - 来自 #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 返回总和等于 userRatingCount 的 ratingsHistogram;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 一致(错误日期 = 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
暂无评论...