# AI 求职代理如何选择：Chronometrica Google Jobs 与 Apify Google Search 当你的 AI 求职代理需要筛选数量有限的结构化职位记录时，选择 Chronometrica Google Jobs。其文档所述的输出将职位字段和申请选项放在同一条记录中，供代理使用。当下一步需要查找雇主招聘页面，或查找返回职位集合之外的其他来源页面时，选择 Apify Google Search。无论采用哪条路径，都必须单独核查来源的当前信息，才能将结果列为通过审核的候选职位。[Chronometrica Google Jobs](https://apify.com/chronometrica/google-jobs-scraper)、[Apify Google Search](https://apify.com/apify/google-search-scraper) 先根据下一项任务作出选择。需要比较职位名称、公司和地点的代理，需要的是职位记录。需要查找更多雇主的代理，需要的是可能提供信息的来源页面。这两项任务分别以职位记录和来源页面为处理单位。选对处理单位，下一步就会明确。 Chronometrica 是我们的工具。对于本文所述的结构化职位任务，我们推荐使用它。主要限制在于采集范围：它采集的是 Google Jobs 在所选搜索条件和条目上限下返回的内容。它不提供完整的雇主索引，也不提供经核实仍在招聘的职位。[Actor 文档](https://apify.com/chronometrica/google-jobs-scraper) ![职位要求与技能证据卡片、审核表格及一小组有序排列的条目相连。](/blog/jobs-fit-shortlist.png) ## 选择下一步所需的记录 Actor 是在 Apify 上托管运行的采集程序。在这项比较中，关键问题是：每条采集记录能让代理接下来做什么。 Chronometrica 的文档规定，每次运行内的 Google `jobId` 不重复。每条职位记录包含 `title`、`companyName`、`location`、`description`、`postedAtRaw`、`applyOptions`、来源 URL 和 `observedAt`。这些字段适合组成供代理筛选的职位表。[文档所述的输出](https://apify.com/chronometrica/google-jobs-scraper) Apify Google Search 的文档说明，其常规自然搜索路径提供搜索结果观测记录和页面链接。它还提供更丰富的搜索控制选项，以及可选的网站内容采集功能。因此，它适合用来查找招聘页面和其他潜在来源。[文档所述的搜索路径](https://apify.com/apify/google-search-scraper) | 决策要点 | Chronometrica Google Jobs | Apify Google Search | | --- | --- | --- | | 文档所述的起始单位 | 1 条结构化的 Google 职位记录 | 1 条带有页面链接的搜索结果观测记录 | | 在本文场景中最适合的用途 | 根据返回的职位字段进行筛选 | 查找可能提供信息的来源页面 | | 仍需补充的证据 | 核查来源的当前信息和应聘资格 | 获取页面、识别职位并核查应聘资格 | 表中的产品详情来自 [Chronometrica 文档](https://apify.com/chronometrica/google-jobs-scraper)和 [Apify 文档](https://apify.com/apify/google-search-scraper)。 在提出宽泛的采集请求之前，先明确这一区别。“查找 5 条职位记录以供审核”为代理指定了明确的输出。“查找 5 个招聘页面以供检查”指定的是另一种输出。“查找 5 个好机会”这样的请求，则没有说明采集单位和通过审核的规则。 切换条件很简单。需要数量有限的职位记录时，先用 Chronometrica。当需求超出返回的职位集合时，切换到来源页面发现。一个工作流程可以包含这 2 个阶段，但应将各阶段的记录分开保存。 ## 为什么更多搜索链接未必能解决求职任务 一篇关于求职代理的公开亲述报告，描述了先尝试从固定公司获取信息，再使用通用网页搜索的过程。作者仍然遇到无法处理的页面、信息时效不明，以及职位或地点不匹配的问题。这篇报告有助于理解工作流程中的问题，但它不是受控的产品对比。[公开报告](https://www.reddit.com/r/LocalLLM/comments/1ta92yp/i_burned_33_million_tokens_using_mcp_agents_to/) 实际可用的经验是：先明确搜索步骤必须交付什么。找到一个页面，并不能证明页面中有合适的职位。找到一条职位记录，也不能证明雇主仍在接受申请。 例如，代理可能找到一个列有多个部门的公司招聘页面。接下来，它必须识别具体职位。这个职位可能要求在另一座城市工作，或要求不同的经验水平。虽然该页面没有产生通过审核的候选职位，但它仍然是有效的页面发现结果。 这一区别有助于找出尚未完成的工作。如果代理缺少雇主信息来源，继续发现来源就有用。如果它已有足够的来源，却无法评估职位，增加链接可能只会增加审核工作，而无法解决决策问题。 该报告支持根据工作流程阶段作出选择。它不能证明任何一款 Actor 在成本、速度、覆盖范围或准确性方面具有优势。本文没有将报告中的支出和采集结果用作基准。 ## Chronometrica 适用于什么情况，其限制何时会影响选择 如果你当前需要的是一个设有明确条目上限的职位表，可以放心选择 Chronometrica。文档所述的职位字段，可让代理直接开始字段审核。输入包含 4 个字段：`market`、`queries`、1 个共用的 `location`，以及 `maxItems`。[输入和输出规范](https://apify.com/chronometrica/google-jobs-scraper) 当请求要求“所有结果”时，这一范围限制很重要。已核查的模式允许 `maxItems` 取值为 1 至 1000。如果你的原始需求是单次运行超过 1000 条，这款 Actor 无法满足该需求。把请求减少到 1000 条，是改变需求，并不是满足原始需求。即使在这个上限以内，返回的记录也不能证明覆盖完整。[已核查的输入限制](https://apify.com/chronometrica/google-jobs-scraper) 设置较小上限的运行仍然可以满足有用的需求。审核人员可能希望先检查 5 条记录，再决定是否采集更多记录。这是一项范围有限、停止条件明确的审核任务。它不需要声称覆盖市场上的每个职位。 本次比较所审阅的证据采集于 2026 年 10 月 20 日。Google Jobs 审核包含一次设有上限的采集所返回的 3 条有用记录。这只能支持对返回记录作出有限的观察结论。它不能证明存在完整的跨公司索引，不能证明职位已经核实且仍在招聘，也不能证明信息时效更好。本文没有进行新的运行，也没有在相同条件下测试竞品。 任何一款 Actor 都不能单独确定简历匹配度、雇主意向或申请是否成功。匹配和申请操作应通过单独核查的工作流程处理。采集结果必须先进入审核，才能作为这些决策的依据。 ## 从符合请求的小规模输入开始 Task 是 Apify 上保存的输入预设。公开的 [Google Jobs 技术招聘 Task](https://apify.com/chronometrica/google-jobs-scraper/examples/google-jobs-technology-hiring-dataset) 提供了一个起始预设。运行前，请检查实际保存的输入。公开的 Task 页面不能证明当前保存了哪些输入值。 对于一个虚构的请求，即获取多伦多最多 5 条数据分析师职位记录，可使用： ```json { "market": "CA-en", "queries": [ "data analyst" ], "location": "Toronto, Ontario, Canada", "maxItems": 5 } ``` 从符合请求的小规模输入开始 这份输入通过了基于缓存的公开 JSON Schema 的检查。JSON Schema 定义了允许使用的字段和值。本文没有实际运行这份输入。该检查确认的是输入结构，不能证明实时来源会返回 5 条记录。 已核查的模式允许 `market` 使用 `CA-en`，`queries` 包含 1 至 100 个条目，`location` 使用文本值，`maxItems` 使用 1 至 1000 的整数。所有查询共用同一个地点。[当前模式的证据](https://apify.com/chronometrica/google-jobs-scraper) 应将这些设置理解为采集指令。`market` 用于选择 Google 站点和语言。它不是严格的地点、国籍或工作资格筛选条件。地点设置也需要在后续根据职位本身进行核查。搜索词可以引导采集，但不能证明返回的每个职位都符合用户规则。 采集前，写明预期单位和上限：“最多 5 条职位观测记录，以供审核。”这样，即使结果较少，也能理解其含义。它还可以防止后续流程把请求上限当成必定提供 5 个合格职位线索的承诺。 ## 保留 3 张含义明确的表 分别使用独立的表保存来源页面观测记录、职位观测记录和通过审核的候选职位。观测记录说明流程在指定时间发现了什么。是否通过审核，则是随后根据用户规则作出的决定。 对于来源页面观测记录，保留搜索查询、结果排名和来源 URL。添加审核状态，让代理能够区分尚未阅读的页面和已经检查的页面。一个页面可能没有职位，也可能包含 1 个或多个职位。提取记录时，要明确保留这种对应关系。 对于职位观测记录，保留 `jobId`、职位字段、来源 URL 和 `applyOptions`。将 `observedAt` 与采集记录一同保存。这些字段可让后续检查指向同一条观测记录，而不必仅凭职位名称进行判断。文档所述的标识规则适用于单次运行内；它并不能建立不同运行之间的历史关联。[Chronometrica 记录规范](https://apify.com/chronometrica/google-jobs-scraper) 对于通过审核的候选职位，保存对应职位观测记录的引用，以及通过审核所依据的证据。同时记录审核时间和简短的决策理由。如果某项必需事实缺失，就将其保留为未知。不要把缺失值改成 0，也不要把尚未回答的应聘资格问题当成已经获准。 尚未解决的记录应有单独的状态。例如，无法读取的页面应标记为待解决，除非其他证据足以支持决策。这与明确不符合地点规则的职位不同。这一区别有助于下一位审核人员决定，是重试获取页面，还是停止处理该职位。 这种表设计也能确保计数准确。10 个来源页面、10 条职位观测记录和 10 个通过审核的候选职位，代表不同的结果。展示每个计数时，都要注明单位。 ## 进行简短的来源和应聘资格审核 生成所需的观测记录后，采集阶段即完成。每条观测记录都有证据支持的决定，或明确的待解决状态后，审核阶段才算完成。 1. 明确下一步。确定代理需要筛选职位字段，还是查找更多雇主信息来源。先选择记录类型，再选择 Actor。 2. 明确采集请求。对于职位记录，检查 Task 的查询、市场、共用地点和条目上限。对于页面发现，保存确切的通用搜索查询。 3. 保留来源引用。将职位标识和申请选项与职位记录一同保存。将查询、排名和来源 URL 与页面观测记录一同保存。 4. 检查来源的当前证据。打开评估具体职位所需的雇主页面或来源页面。记录支持审核结论的内容。 5. 应用用户规则。检查职位、资历级别、地点和应聘资格。保存通过、拒绝和待解决的决定，并附上观测时间和审核时间。 审核前先定义规则。“多伦多”可能指在多伦多办公室工作、明确说明的混合办公安排，或允许远程工作的地点。如果这一区别会影响是否通过审核，就向用户确认。资历级别和所需工作资格也应如此处理。明确的规则可以减少缺少依据的决定。 谨慎处理时间字段。`postedAtRaw` 是来源中描述职位已发布多久的文本。`observedAt` 是采集时间。这 2 个字段都不能确定准确的发布时间，也不能证明职位仍在招聘。应根据来源的当前证据作出判断。[字段文档](https://apify.com/chronometrica/google-jobs-scraper) 对于页面获取环节，可参考现有指南：[为网页搜索代理提供经过核查的页面证据](/zh-Hans/articles/%E5%BF%85%E5%BA%94-%E7%BD%91%E9%A1%B5%E6%90%9C%E7%B4%A2%E6%99%BA%E8%83%BD%E4%BD%93-%E5%B7%B2%E6%A0%B8%E5%AF%B9%E9%A1%B5%E9%9D%A2%E8%AF%81%E6%8D%AE/)。该指南介绍证据处理步骤。本文的比较则帮助你决定，应将采集到的哪类记录用于该证据审核步骤。 匹配、历史记录和申请操作，只应通过单独核查的工作流程加入。将最初这项决策的范围控制在便于核验的程度。 ## 一个核对了计数单位的虚构示例 以下示例为虚构内容。它不是 Actor 测试、实时数据集、买家引述或实测成本结果。 一个虚构的代理需要 5 条职位观测记录，供后续审核。用户已定义职位和地点规则。Google Jobs 路径返回了 5 条结构化观测记录。随后，单独进行的来源当前信息和应聘资格审核通过了 3 条，拒绝了 2 条。 结果为： 5 条职位观测记录 − 2 条被拒绝的观测记录 = 3 个通过审核的候选职位。 示例到此结束。它不能确定该 Actor 的实测审核通过率。其他查询、用户规则或采集时间，都可能产生不同的结果。 再考虑一条提供了 5 个候选招聘页面链接的发现路径。代理仍需获取这些页面并提取职位，才能将结果作为职位记录进行比较。一个页面可能包含多个相关职位，另一个页面则可能没有。因此，5 个链接并不等于 5 个职位。 无论哪条路径，返回 5 条记录都不等于获得了 5 个合格职位线索。审核才能确定哪些记录符合用户规则。因此，应先比较所需的输出单位，再评估由此得到的证据。 如果代理已有足够的职位观测记录可供下一次审核，就使用这些记录。如果它需要查找返回集合之外的雇主，就开始搜索相关来源页面。根据尚未完成的工作作出决定。 ## 将选择付诸行动 当代理需要数量有限的结构化职位记录时，使用 Chronometrica Google Jobs。打开[公开 Task](https://apify.com/chronometrica/google-jobs-scraper/examples/google-jobs-technology-hiring-dataset)，检查已保存的输入，并根据请求设置查询、市场、共用地点和条目上限。将来源审核和应聘资格审核列为必需的后续步骤。 如果需要返回的 Google Jobs 集合之外的来源页面，就选择发现路径。如果要求单次运行超过 1000 条，已核查的 Chronometrica 输入上限无法满足该需求。 对于本文所述的结构化职位任务，可从 [Chronometrica Google Jobs Scraper](https://apify.com/chronometrica/google-jobs-scraper) 开始。其文档所述的职位记录适合下一步筛选。保留每条记录的证据，审核来源的当前信息，并且只接受符合用户明确规则的候选职位。 ## 来源和延伸阅读 - [Chronometrica Google Jobs Scraper：公开产品文档和输入](https://apify.com/chronometrica/google-jobs-scraper) - [Apify Google Search Scraper：公开产品文档](https://apify.com/apify/google-search-scraper) - [Google Jobs 技术招聘 Task：公开的起始预设](https://apify.com/chronometrica/google-jobs-scraper/examples/google-jobs-technology-hiring-dataset) - [求职代理亲述报告：用于理解工作流程背景，不作为产品基准](https://www.reddit.com/r/LocalLLM/comments/1ta92yp/i_burned_33_million_tokens_using_mcp_agents_to/)