Structured Entity Enumeration

目标 解决针对知名人物或组织的枚举查询问题（如"某导演的所有电影"、"某设计师的所有游戏"），跨时间段的列表查询问题（如"历年富豪榜前十"），以及跨越多个子类别的宏观枚举问题（如"某机构多个项目的所有任务"）。此类任务通常要求提取结构化数据（标题、年份、排名等）并按时间排序。本技能旨在纠正因逐条搜索、跨时间维度搜索不当或跨类别搜索过于宽泛导致的预算耗尽和死循环，通过定位权威汇总页或实施维度分片策略实现高效批量提取。

适用场景

• 查询类型: "列出..."、"所有..."、"枚举..."等需要返回完整列表的问题。
• 实体类型: 知名人物作品集、组织成员列表、事件时间线等。
• 时间序列数据: 需要跨多个年份或时间段的排名列表、统计数据（如"2019-2024年福布斯富豪榜"）。
• 多类别枚举: 需要跨越多个独立项目、系列或类别的列表查询（如"NASA水星、双子星、阿波罗计划的所有任务"），且单一汇总页难以覆盖所有细节或不同类别具有不同的数据结构。
• 输出要求: 需要特定列（如年份、角色、排名）且要求去重和排序。
• 示例: "找出小岛秀夫担任设计师、导演或制作人的所有电子游戏"、"列出诺兰导演的电影作品及票房"、"列出2019至2024年每年福布斯富豪榜的前十名"、"列出NASA水星、双子星和阿波罗计划的所有载人任务细节"、"列出2019至2023年每年诺贝尔物理学奖得主、所属机构及获奖原因"。

核心原则

• 源头优先: 严禁针对单个作品进行碎片化搜索。必须首先寻找包含完整信息的"母页面"（如Wikipedia作品列表页、IMDB主页、专业数据库）。
• 维度分片: 针对具有时间维度或类别维度的列表任务，严禁使用宽泛的范围进行单一搜索。应将任务拆解为独立的时间点（如按年）或独立的类别（如按项目计划），针对每个分片独立执行"定位-提取"流程。
• 并行分发: 对于拆解后的独立分片（如不同的年份或类别），应优先采用并行分发机制（如 dispatch_agents）同时处理，而非串行迭代，以最大化效率并减少上下文拖尾风险。
• 即时分发原则: 针对明确的年份区间查询（如"2019-2023年"），应直接执行并行分发策略，跳过尝试搜索"全区间汇总页"的步骤。证据表明，直接针对单一时间点并行搜索能有效规避初始阶段的搜索停滞（NO_PROGRESS）和预算浪费。
• 结构预判: 在执行提取前，必须校验目标表格的列头是否满足任务所需的字段颗粒度。若汇总表缺失关键细节字段（如"备份机组"、"发射台"），需立即调整策略，避免无效提取。
• 批量提取: 发现数据表格后，采用批量行提取策略，避免逐条处理导致的效率低下。
• 反循环机制: 遇到连续搜索无进展（NO_PROGRESS）时，立即停止SEARCH，强制转向OPEN已获取的高权重页面。

执行流程

1. 维度拆解: 分析任务是否包含多重维度。
   • 时间维度: 若任务涉及时间范围（如2019-2024），将任务拆解为针对单一时间点（如"2019年"）的子任务。
   • 类别维度: 若任务涉及多个独立子项目或类别（如Mercury, Gemini, Apollo），将任务拆解为针对单一类别（如"Project Mercury missions"）的子任务。
   • 并行策略: 针对拆解后的独立分片，应利用 dispatch_agents 机制为每个分片实例化独立的搜索代理，并行执行后续步骤。对于明确的跨年查询，直接分发，避免尝试寻找不存在的"总表"。
2. 定位汇总页: 构造包含"list"、"filmography"、"discography"、"wiki"、具体年份或具体类别关键词的搜索查询，快速定位权威汇总页。
   • Query示例: search "Forbes billionaires list 2019"
   • Query示例: search "Hideo Kojima video games list wiki"
   • Query示例: search "Project Mercury missions list wiki"
   • Query示例: search "Nobel Physics Prize winners 2019"
3. 打开与验证: 打开最相关的页面，快速扫描是否存在结构化表格或列表。
4. 建立与校验Schema: 根据任务要求明确需提取的字段（如：Title, Year, Role, Platform）。关键步骤：比对页面表格列头与需求字段。若页面为简略汇总表（缺失"Backup Crew"等细节字段），切勿强行提取。应转而寻找更详细的子页面，或先提取索引字段（如任务名），再视预算决定是否深入详情页补充数据。
5. 批量抽取: 定位数据区域后，让抽取链路一次性扫整页——open() 一个汇总页就够，抽取中间件会自动从页面里把所有匹配 schema 的行抓出来。若候选汇总页有多个值得读的，逐个 open() 即可，全文会自动进入抽取队列。若Schema校验不通过但必须提取，应仅提取现有列，其余列标记为缺失。
6. 排序与补充: 对提取数据进行时间排序；若汇总页不全，再针对性补充缺失项。

常见误区

• 场景: 尝试逐个搜索目标实体（如逐个搜游戏名）。
  • ❌ 踩坑: 连续执行 search "Game A", search "Game B"。导致 SEARCH_LOOP、budget_exhausted 且覆盖率为0。
  • ✅ 应改用: 搜索 "Hideo Kojima games list"，打开汇总页，一次性提取表格数据。
• 场景: 查询跨越多个时间段的列表（如历年榜单）。
  • ❌ 踩坑: 尝试一次性搜索整个时间跨度（如 search "Forbes billionaires list 2019-2024" 或 search "Nobel Physics Prize winners 2019-2023"），期望存在单一汇总页。结果往往找不到对应页面，导致连续搜索无进展（NO_PROGRESS）并耗尽预算。
  • ✅ 应改用: 实施"并行时间分片"策略。将时间范围拆解为独立的年份，利用并行分发机制（如 dispatch_agents）为每个年份实例化独立的搜索单元（如 dispatch_agent task="Find 2019 list..."），同步执行定位与提取，避免低效的串行等待。证据示例：查询"2019-2023年诺贝尔物理学奖"时，直接分发5个代理分别查询各年份信息，可迅速达成100%覆盖率，而尝试搜索全区间汇总页则会导致0%覆盖率。
• 场景: 查询跨越多个独立项目或类别的列表（如不同NASA计划的任务）。
  • ❌ 踩坑: 尝试一次性搜索所有类别（如 search "NASA Mercury Gemini Apollo missions list"），期望单一页面包含所有计划的详尽数据。结果因信息过载或缺乏统一汇总页导致覆盖率为0，陷入搜索循环。
  • ✅ 应改用: 实施"类别分片"策略。将任务拆解为针对具体类别的子任务（如分别搜索 "Project Mercury missions list", "Project Gemini missions list"），分别定位并提取数据。
• 场景: 搜索结果不理想，持续更换关键词泛泛搜索。
  • ❌ 踩坑: 触发 bare_search_without_progress 警告，