企业级资产搜索技能（稳健版）

此技能将多跳资产检索 + 结构化实体提取任务委派给轻量级子代理，确保主代理的上下文保持精简。

适用于工作区中包含大量相互关联的资产（文档、聊天记录、会议纪要、PR、URL）以及参考元数据（员工/客户目录）的数据集。

本版本新增两项关键改进：

1) 产品定位与抗干扰过滤（防止在询问 CoachForce 时混入 CoFoAIX 等其他产品信息）。

2) 关键评审人提取规则（避免将“会议参与者 = 评审人”的错误认知；优先选择明确标注的评审人，其次为有证据支持的贡献者）。

何时调用此技能

当以下任一条件成立时，请调用：

1. 问题需要多跳证据收集（资产 → 参考信息 → 其他资产）。
2. 答案必须从资产中检索得出（如 ID/名称/日期/角色），而非推断。
3. 证据分散在多种资产类型中（文档 + Slack + 会议 + PR + URL）。
4. 需要提供精确指针（doc_id/message_id/meeting_id/pr_id）以支撑输出。
5. 必须保持上下文精简，避免将大文件加载进上下文。

为何使用此技能？

未使用该技能时： 你需手动在多个文件中搜索，容易遗漏跨链接，常因第一个“看起来正确”的报告而误判（常见失败：选错产品）。

使用该技能后： 子代理将：

• 快速定位候选资产
• 跨渠道/会议/文档/PR 跟踪引用关系
• 提取结构化实体（员工 ID、文档 ID）
• 验证产品范围，排除干扰项
• 返回紧凑的证据地图，附带资产指针

典型上下文节省率：70–95%。

调用方式

请使用以下格式：

Task(subagent_type="enterprise-artifact-search", prompt="""
Dataset root: /root/DATA
Question: <粘贴问题原文>

Output requirements:
- 返回可直接用于 JSON 的提取实体（员工 ID、文档 ID 等）。
- 提供证据指针：artifact_id(s) + 简短支持片段。

Constraints:
- 避免使用 oracle/标签字段（ground_truth, gold answers）。
- 优先选择主资产（文档/聊天/会议/PR/URL），而非仅含元数据的快捷路径。
- 必须强制执行产品定位：仅接受能证明属于目标产品的资产。
""")

核心流程（必须遵循）

步骤 0 — 解析意图 + 目标产品

• 提取：

- 目标产品名称（例如：“CoachForce”）

- 所需实体类型（例如：作者员工 ID、关键评审人员工 ID）

- 可能相关的资产类型（“市场调研报告”、文档、评审线程）

若问题中未提及产品名称，仅在附近上下文有明确资产支持的情况下谨慎推断；否则标记为 AMBIGUOUS。

步骤 1 — 构建候选集（广覆盖召回，再过滤）

按以下顺序搜索：

1) 产品资产文件：/root/DATA/products/<Product>.json（若存在）。

2) 全局扫描（如需）：提及目标产品名称的其他产品文件及文档。

3) 在已发现的频道/会议中：追踪文档链接（如 /archives/docs/<doc_id>）、引用的会议聊天、PR 中的提及。

收集所有满足以下任一条件的候选项：

• 类型/文档类型/标题包含 “Market Research Report”（不区分大小写）
• 或文档链接/Slack 文本包含 “Market Research Report”
• 或会议纪要中标记 document_type 为 “Market Research Report”

步骤 2 — 强制产品定位（抗干扰关卡）

只有通过至少两个独立定位信号的候选报告才被视为 VALID。

定位信号（任选其二及以上）：

A) 位于正确的產品资产容器内（例如，位于 products/CoachForce.json 内部，并与该产品的规划频道/会议相关联）。

B) 文档内容或标题中明确提及目标产品名称（“CoachForce”）或从资产中推导出的官方别名列表。

C) 分享于名称明显属于目标产品的频道（如 planning-CoachForce、#coachforce-*）或产品专属会议系列（如 CoachForce_planning_*）。

D) 文档 ID/链接路径中包含与目标产品一致的产品特定标识符（非其他产品）。

E) 会议纪要中讨论该报告的内容包含目标产品上下文（如会议标题/系列/频道引用）。

拒绝规则（非常重要）：

• 若报告内容反复提及另一产品（如“CoFoAIX”）且缺乏 CoachForce 定位证据 → 标记为 DISTRACTOR 并丢弃，即使其出现在同一文件或语义相近。

原因： 基准测试中故意在不同产品间设置相同文档类型；“首次命中即胜”是常见错误。

步骤 3 — 选择正确的报告版本

若存在多个 VALID 报告，按以下优先级选择“最终/最新”版本：

1) 显式“最新”标记（ID/标题/链接包含 latest，或最近的日期字段）

2) 显式“最终”标记

3) 否则，按 date 字段选择最晚时间

4) 若无日期，选择在后续讨论中被引用频率最高的（Slack 回复/会议聊天）

保留选定报告的 doc_id 和链接作为锚点。

步骤 4 — 提取作者

按以下优先级提取作者：

1) 文档字段：author, authors, created_by, owner

2) 若报告通过 PR 引入：PR 字段中的 author, created_by

3) Slack：发布“这是报告…”消息的用户（仅当消息明确链接到报告 doc_id 且具备产品定位证据时）

统一归一化为 员工 ID：

• 若已是 eid_*，直接保留。
• 若仅有姓名，需通过员工目录元数据进行映射（姓名 → employee_id），但仅在已有产品定位证据后方可执行。

步骤 5 — 提取关键评审人（不得将“参与者”等同于评审人）

关键评审人必须是基于证据的贡献者，而非仅出席会议的人员。

请按以下优先级执行：

一级（最优）：明确的评审人字段

• 文档字段：reviewers、key_reviewers、approvers、requested_reviewers
• PR 字段：reviewers、approvers、requested_reviewers

二级：明确的反馈提供者

• 文档中带有具体人员/ID 的 feedback 段落
• 会议记录中可归属到具体人员的发言，且该人员提出了具体的建议或修改意见

三级：对报告分享消息的 Slack 线程回复

• 仅包含提出实质性反馈、建议或问题的用户
• 排除：

- 作者（除非问题明确要求其作为评审人之一）

- 仅表示认可的内容（如“看起来不错”、“谢谢”），除非没有其他评审人存在

关键规则：

• 仅凭会议 participants 列表不足以判定。

- 只有当会议记录显示某人提供了反馈，或其出现在明确的评审人字段中时，才可计入关键评审人。

• 若基准要求“关键评审人”为“在评审会议中参与审查的人”，则必须引用记录中包含其建议的具体语句。

步骤 6 — 验证 ID 并去重

• 所有输出必须为有效的员工 ID（格式为 eid_...），且若提供员工目录，则需存在于其中。
• 去重时保留原有顺序：

1) 作者优先

2) 关键评审人其次

输出格式（严格，JSON 兼容）

返回：

1）最终答案对象

{
  "target_product": "<ProductName>",
  "report_doc_id": "<doc_id>",
  "author_employee_ids": ["eid_..."],
  "key_reviewer_employee_ids": ["eid_..."],
  "all_employee_ids_union": ["eid_..."]
}

2）证据映射（指针 + 最小片段）

每个提取出的 ID 需包含：

• 资产类型 + 资产 ID（doc_id / meeting_id / slack_message_id / pr_id）
• 直接支持该映射的简短片段

示例证据条目：

{
  "employee_id": "eid_xxx",
  "role": "key_reviewer",
  "evidence": [
    {
      "artifact_type": "meeting_transcript",
      "artifact_id": "CoachForce_planning_2",
      "snippet": "…Alex: 我们应该增加一个对比 CoachForce 与竞争对手 X 的章节…"
    }
  ]
}

推荐类型

返回以下之一：

• USE_EVIDENCE — 证据充分且与产品相关
• NEED_MORE_SEARCH — 缺少评审信号；需扩大搜索范围（如 PR、Slack 回复、其他会议）
• AMBIGUOUS — 产品信号冲突，或存在多个同等合理的报告

常见失败模式（本技能可避免）

1) 跨产品误用

因“市场调研报告”出现在其他产品（如 CoFoAIX）中而错误选择。

→ 通过步骤 2（双信号产品定位）解决。

2) 评审人过度泛化

将所有会议参与者视为评审人。

→ 通过步骤 5（基于证据的评审人定义）解决。

3) 版本错误

选择了草稿而非最终版/最新版。

→ 通过步骤 3 解决。

4) 结构不匹配

返回扁平列表，但评估者期望拆分字段。

→ 通过输出格式解决。

小型示例（你的场景）

问题：

“找出 CoachForce 产品市场调研报告的作者和关键评审人的员工 ID？”

正确行为：

• 拒绝任何内容或链接明显属于 CoFoAIX 的报告，除非其同时满足 2 个以上 CoachForce 的定位信号。
• 选择 CoachForce 的最终版/最新版报告。
• 作者来自文档字段 author。
• 关键评审人来自显式的 reviewers/key_reviewers 字段（若存在）；否则来自会议记录中的发言或 Slack 回复中体现具体反馈的内容。

不应调用的情况

• 答案位于单一小型已知文件中且无交叉引用。
• 任务为简单的单跳查找，且产品范围明确无歧义。