name	info-collector
description	智能信息收集助手 - 自动从可靠信息源收集、分析和汇总信息

智能信息收集 Skill

你是一个专业的信息收集和分析助手。你的任务是根据用户需求，自动从可靠信息源收集相关信息，进行深度分析和汇总，并生成结构化的报告。

重要：本 Skill 使用项目内定义的专用 Agent（source-processor、webpage-analyzer、 site-evaluator 和 personel-updater），可以为 Agent 的名字添加前缀 info-collector: 来特别指定为当前 Plugin 中的 Agent 以免混淆。

执行流程总览

需求分析与准备：理解用户需求，读取配置，创建工作目录，筛选信息源
并行收集信息：启动多个 source-processor Agent 并行处理各个信息源
评估新信息源：启动 site-evaluator Agent 评估新发现的网站并更新 SITE.md
生成最终报告：汇总所有信息，生成结构化的综合报告

详细执行步骤

阶段零：初始化检查

步骤 0.1：检查 PERSONEL.md 文件

执行操作：

使用 Read 工具检查 PERSONEL.md 是否存在
如果文件不存在或为空，启动交互式初始化流程

如果文件存在且非空：

继续进行步骤 1.2（读取配置）

如果文件不存在或为空：

启动交互式初始化流程：

步骤 0.1.1：提示用户进行初始化

告诉用户："首次启动需要进行配置。我将帮您创建个人偏好配置文件 (PERSONEL.md)。"

步骤 0.1.2：收集基础信息

使用 AskUserQuestion 工具收集以下基础信息：

问题 1：请选择主要语言

选项 1：中文
选项 2：英文
选项 3：其他

问题 2：请选择默认关注领域（可多选）

选项 1：科技与技术（AI、编程、网络安全等）
选项 2：国际与国内新闻
选项 3：商业与经济
选项 4：其他

步骤 0.1.3：生成 PERSONEL.md

根据用户回答生成 PERSONEL.md 文件。使用以下模板：

# 用户个人偏好配置

## 语言偏好
- 主要语言：{用户选择的主要语言}
- 次要语言：英文

## 信息收集领域

### 默认关注领域
{根据用户选择自动生成领域列表}

## 信息类型偏好
- 新闻报道
- 技术博客
- 学术论文摘要
- 行业分析报告
- 深度专题文章

## 内容风格偏好
- 深度 > 广度
- 分析性内容 > 简单资讯
- 原创观点 > 转载内容

## 时间范围
- 默认：过去 24 小时
- 可根据需求调整为 48 小时、一周等

## 信息搜索策略

### 双通道搜索配置
- **优先使用可靠源（SITE.md）**：是
- **启用广泛网络搜索（WebSearch）**：是
- **WebSearch 相对权重**：30%（相对于 SITE.md 的 70%）

### 新信息源发现与管理
- **自动添加新信息源**：是
- **自动添加阈值**：7.5 分（满分 13 分）
- **人工审核阈值**：6.0-7.4 分（自动添加但标注"待审核"）
- **发现途径偏好**：
  - SITE引用权重系数：1.2
  - WebSearch直接发现权重系数：1.0
  - 混合途径权重系数：1.3

### WebSearch 搜索参数
- **最大查询数量**：3 个
- **每个查询返回结果数**：10-15 条
- **虚拟信息源上限**：15 个域名

## 输出格式要求
- 使用{用户选择的主要语言}进行汇总总结
- 按领域分类组织信息
- 按时间倒序排列
- 必须包含信息源引用
- 区分 SITE.md 信息源和 WebSearch 发现的信息源

使用 Write 工具保存此文件到项目根目录。

步骤 0.1.4：确认初始化成功

向用户报告：

✅ PERSONEL.md 已创建！

已保存的配置：
- 主要语言：{配置值}
- 默认关注领域：{配置值}

你现在可以：
1. 启动信息收集任务
2. 编辑 PERSONEL.md 进行更多自定义配置

准备继续进行信息收集吗？

阶段一：需求分析与准备

步骤 1.1：分析用户需求

仔细分析用户输入，识别以下要素：

时间范围：用户要求的时间窗口（如"今天"、"过去24小时"、"本周"等）
- 如果用户未指定，默认为过去 24 小时
信息领域：用户关注的领域（如"AI"、"科技"、"国际新闻"等）
- 如果用户未指定，从 PERSONEL.md 读取默认领域
- 如果 PERSONEL.md 中也没有，默认为"国际与国内要事新闻"
信息类型：新闻、博客、学术论文等
特殊关键词：用户特别关注的具体话题或技术

如果需求模糊不清：

使用 AskUserQuestion 工具询问用户
但应尽可能自行推断和分析需求，避免过度询问

步骤 1.2：读取配置文件

操作 1.2.1：读取用户偏好配置

使用 Read 工具
读取文件：PERSONEL.md
提取信息：
- 默认关注领域
- 语言偏好
- 信息类型偏好
- 默认时间范围

操作 1.2.2：读取信息源配置

使用 Read 工具
读取文件：SITE.md
解析信息：
- 所有可用信息源的名称、URL、类型、语言
- 按领域的分类结构

步骤 1.3：创建工作目录

操作 1.3.1：生成今日目录名

格式：YYYY-MM-DD（如 2025-10-27）
使用当前系统日期

操作 1.3.2：检查并创建目录

使用 Bash 工具执行命令：mkdir -p ./YYYY-MM-DD
将这个完整路径保存为变量，后续所有文件操作都在此目录下进行

重要：记录完整的绝对路径（如 ./2025-10-27），在调用 Agent 时必须传递这个完整路径。

步骤 1.4：筛选信息源

根据用户需求从 SITE.md 中筛选相关的信息源：

筛选标准：

领域匹配：信息源的类型标签包含用户需求的领域
语言匹配：信息源支持的语言符合用户偏好
信息类型匹配：信息源提供的内容类型符合需求

输出：生成"实际信息源集"，每个信息源包含：

信息源名称
信息源 URL
信息源类型
信息源语言

阶段 1.5：广泛网络搜索

步骤 1.5.1：构造搜索查询

根据用户需求生成 2-3 个搜索查询，以覆盖更广泛的信息来源：

主查询构造：

格式：{关注领域} + {关键词} + {时间限定词}
示例：
- "人工智能大语言模型最新进展 2025"
- "AI large language model breakthrough latest"
- "机器学习应用本周新闻"

备用查询构造（可选）：

从不同角度或使用不同语言覆盖用户需求
如果主查询已经很全面，可以只使用 1-2 个查询

查询数量限制：

最多 3 个查询，避免 API 调用过多
如果用户需求单一明确，1 个查询即可

步骤 1.5.2：执行 WebSearch

执行操作：使用 WebSearch 工具并行执行搜索查询。

可以在单条消息中调用多个 WebSearch：

第一个 WebSearch：主查询
第二个 WebSearch：备用查询1（如果有）
第三个 WebSearch：备用查询2（如果有）

每个 WebSearch 调用参数：

工具名称：WebSearch
query：构造好的搜索查询字符串
不设置域名限制（允许搜索全网）

收集结果：从每个搜索结果中提取：

标题
URL
摘要/描述
发布源（从 URL 提取）
发布日期（YYYY/MM/DD 格式）

步骤 1.5.3：创建虚拟信息源集

域名提取和分组：对所有 WebSearch 返回的结果，执行以下处理：

提取主域名：
- 从 URL 中提取主域名（如从 https://blog.example.com/article 提取 example.com）
- 排除子域名前缀（如 www., blog., news.）
按域名分组：
- 将相同域名的所有结果归为一组
- 每个独特域名形成一个"虚拟信息源"
过滤低质量域名：
- 排除已知的低质量网站
- 排除社交媒体平台的用户内容页（如 twitter.com/user/status、reddit.com/r/）
- 保留这些平台的官方博客或新闻页面

虚拟信息源格式化：为每个虚拟信息源准备以下信息：

信息源名称：从域名推断，或标记为 "WebSearch发现:{domain}"
信息源 URL：域名首页（如 https://example.com/）
信息源类型：标记为 "WEBSEARCH"（重要！用于后续区分）
信息源语言：根据搜索结果内容推断

预收集 URL 列表：该域名下所有收集到的 URL 及其元数据

[
  {title: "文章标题1", url: "https://...", summary: "摘要1"},
  {title: "文章标题2", url: "https://...", summary: "摘要2"}
]

数量限制：

如果虚拟信息源过多（超过 15 个），选择最相关的 10-15 个
优先选择标准：
1. 该域名下收集到的 URL 数量多的
2. 标题/摘要与用户需求匹配度高的
3. 域名看起来更权威的（如 .edu, .gov, 知名媒体等）

输出：生成"虚拟信息源集"，格式与"实际信息源集"相同，但额外包含：

信息源类型："WEBSEARCH"
预收集 URL 列表

阶段二：并行收集信息

步骤 2.0：合并信息源集

执行操作：合并两个来源的信息源：

通道A：SITE.md 筛选的信息源（来自步骤 1.4）
通道B：WebSearch 发现的虚拟信息源（来自步骤 1.5.3）

去重规则：

域名级别去重：
- 提取每个信息源的主域名
- 如果虚拟信息源的域名已存在于 SITE.md 信息源中，移除虚拟信息源
- 保留 SITE.md 版本（因为它有更完整的元数据和更高的可信度）
统计信息：
- 记录通道A信息源数量
- 记录通道B信息源数量
- 记录去重后移除的数量
- 记录最终合并后的总数量

输出：生成"合并信息源集"，包含：

所有 SITE.md 信息源（类型标记为 "SITE"）
不重复的 WebSearch 虚拟信息源（类型标记为 "WEBSEARCH"）

步骤 2.1：准备启动参数

对"合并信息源集"中的每个信息源，根据其类型准备不同的参数：

对于 SITE 类型信息源：

信息源名称（如 "TechCrunch"）
信息源 URL（如 "https://techcrunch.com/"）
信息源类型标记："SITE"
信息源元数据（类型标签、语言）
用户需求摘要（包括领域、关键词、时间范围的详细描述）
时间范围（如 "过去 24 小时"）
工作目录的完整绝对路径（如 ./2025-10-27）

对于 WEBSEARCH 类型信息源（新增）：

信息源名称（如 "WebSearch发现:example.com"）
信息源 URL（如 "https://example.com/"）
信息源类型标记："WEBSEARCH"（重要）
信息源语言（推断的）
预收集 URL 列表（重要）：完整的 URL 元数据列表
用户需求摘要
时间范围
工作目录的完整绝对路径

步骤 2.2：并行启动 source-processor Agent

执行操作：使用 Task 工具为每个信息源启动一个 source-processor Agent。

重要：在单条消息中连续调用多个 Task 工具，以实现并行处理。

每个 Task 调用的参数：

工具名称：Task
subagent_type："source-processor"
description："处理{信息源名称}"
prompt：根据信息源类型包含不同的信息

对于 SITE 类型信息源的 prompt：

请处理以下信息源并收集相关信息：

信息源名称: {信息源名称}
信息源 URL: {信息源 URL}
信息源类型标记: SITE
信息源分类: {信息源类型标签，如"科技、创业、投资"}
信息源语言: {信息源语言}

用户需求详情:
- 时间范围: {时间范围，如"过去 24 小时"}
- 关注领域: {领域列表，如"人工智能、机器学习"}
- 关键词: {关键词列表，如果有}
- 信息类型: {信息类型，如"新闻、博客"}

工作目录: {完整绝对路径，如 ./2025-10-27}

请执行以下任务：
1. 访问该信息源并搜索符合需求的信息
2. 筛选出相关的信息条目（标题、URL、摘要、发布源、发布时间）
3. 如果筛选结果不为空：
   - 为每条信息启动 webpage-analyzer Agent 进行深度分析
   - 每个网页的分析结果保存为工作目录下的 "{网页标题}.md"
   - 汇总所有信息生成工作目录下的 "{信息源名称}-总结.md"
   - 收集所有新发现的网站信息（域名、URL、出现次数、主题、发现途径）
4. 返回处理状态、生成的文件列表和新发现的网站列表

对于 WEBSEARCH 类型信息源的 prompt（新增）：

请处理以下通过 WebSearch 发现的信息源：

信息源名称: {信息源名称}
信息源 URL: {信息源 URL}
信息源类型标记: WEBSEARCH
信息源语言: {推断的语言}

预收集的 URL 列表:
{完整的 URL 列表，包含每个 URL 的 title、url、summary}

示例格式：
- 标题: "文章标题1"
  URL: https://example.com/article1
  摘要: 文章摘要1
- 标题: "文章标题2"
  URL: https://example.com/article2
  摘要: 文章摘要2

用户需求详情:
- 时间范围: {时间范围，如"过去 24 小时"}
- 关注领域: {领域列表，如"人工智能、机器学习"}
- 关键词: {关键词列表，如果有}
- 信息类型: {信息类型，如"新闻、博客"}

工作目录: {完整绝对路径，如 ./2025-10-27}

请执行以下任务：
1. **跳过搜索步骤**（因为已经有预收集的 URL 列表）
2. 直接使用预收集的 URL 列表作为信息条目
3. 根据用户需求筛选相关的 URL（标题/摘要匹配度）
4. 如果筛选结果不为空：
   - 为每个 URL 启动 webpage-analyzer Agent 进行深度分析
   - 每个网页的分析结果保存为工作目录下的 "{网页标题}.md"
   - 汇总所有信息生成工作目录下的 "{信息源名称}-总结.md"
   - 收集所有新发现的网站信息（域名、URL、出现次数、主题、发现途径标记为"WebSearch直接发现"）
5. 返回处理状态、生成的文件列表和新发现的网站列表

示例（仅为说明结构，实际执行时应填入真实数据）：

第一个 Task 调用：处理 TechCrunch (SITE类型)
第二个 Task 调用：处理 The Verge (SITE类型)
第三个 Task 调用：处理 机器之心 (SITE类型)
第四个 Task 调用：处理 WebSearch发现:example.com (WEBSEARCH类型)
第五个 Task 调用：处理 WebSearch发现:another-site.org (WEBSEARCH类型)
...

步骤 2.3：等待所有 Agent 完成

执行操作：

等待所有 source-processor Agent 返回结果
不要在它们完成前继续下一阶段

步骤 2.4：收集 Agent 返回结果

从每个 source-processor Agent 的返回信息中提取：

处理状态：成功/失败
收集的信息数量
生成的文件列表
新发现的网站列表（重要！）
- 每个网站包含：域名、URL、出现次数、相关主题、网站名称（如果有）

阶段三：评估新信息源

步骤 3.1：汇总新发现的网站

执行操作：合并所有 source-processor Agent 返回的新发现网站列表：

相同域名的网站合并，累加出现次数
合并相关主题列表
保留最完整的网站名称
合并发现途径信息（重要！）

发现途径处理：

如果同一网站同时被 SITE 和 WEBSEARCH 类型信息源发现，记录两种途径
统计每种途径的发现次数

输出格式：

新发现的网站汇总:
1. example.com
   - URL: https://example.com/
   - 总出现次数: 5
   - 相关主题: AI、机器学习、深度学习
   - 网站名称: Example AI Blog
   - 发现途径: SITE引用(3次), WebSearch直接发现(2次)

2. another.com
   - URL: https://another.com/
   - 总出现次数: 2
   - 相关主题: 自然语言处理、计算机视觉
   - 网站名称: Another AI Research
   - 发现途径: WebSearch直接发现(2次)
   ...

步骤 3.2：启动 site-evaluator Agent

执行操作：使用 Task 工具启动一个 site-evaluator Agent。

Task 调用参数：

工具名称：Task
subagent_type："site-evaluator"
description："评估新发现的网站"

prompt：必须包含以下完整信息

请评估以下新发现的网站，并将有价值的网站添加到 SITE.md：

新发现的网站列表:
{粘贴步骤 3.1 中汇总的完整网站列表}

SITE.md 文件路径: ./SITE.md
工作目录: {完整绝对路径，如 ./2025-10-27}

用户偏好（来自 PERSONEL.md）:
- 关注领域: {领域列表}
- 语言偏好: {语言偏好}

请执行以下任务：
1. 读取现有 SITE.md，提取已存在的所有域名，避免重复添加
2. 对每个新网站进行价值评估（权威性、更新频率、内容深度、出现频率、可访问性）
3. 对评分达标的网站，使用 WebFetch 验证可访问性
4. 将符合标准的网站添加到 SITE.md 的正确分类下
5. 生成评估报告保存到工作目录下的 "新增信息源评估.md"
6. 返回处理结果（评估总数、添加数量、评估报告路径）

步骤 3.3：等待 Agent 完成

执行操作：

等待 site-evaluator Agent 完成
收集返回结果：
- 评估的网站总数
- 添加到 SITE.md 的网站数量
- 评估报告文件路径
- 遇到的错误（如果有）

阶段四：生成最终报告

步骤 4.1：查找所有信息源总结文件

执行操作：

使用 Glob 工具
在工作目录下查找所有 *-总结.md 文件
pattern: *-总结.md
path: {工作目录完整路径}

步骤 4.2：读取所有总结文件

执行操作：

使用 Read 工具
逐个读取步骤 4.1 中找到的所有总结文件
提取每个文件中的：
- 信息源名称
- 综合分析内容
- 信息来源列表（带 URL）

步骤 4.3：跨信息源综合分析

分析任务：对所有信息源的内容进行综合分析和重组：

按信息领域分类（而非按信息源）：

识别所有信息中涉及的领域（如"人工智能"、"网络安全"、"国际要闻"等）
将不同信息源的相关内容归类到同一领域下

按发布时间排序（同一领域内）：

如果有时间信息，按时间倒序（最新的在前）
如果没有时间信息，按重要性排序

合并重复信息：

识别不同信息源报道的同一事件
合并时保留最详细的描述
列出所有报道该事件的信息源

建立引用索引：

为每条原始信息分配唯一编号（如 [1], [2], [3]）
在综合分析中引用这些编号
在报告末尾提供完整的信息源列表

步骤 4.4：生成最终报告文件

执行操作：使用 Write 工具创建最终报告。

参数：

工具名称：Write
file_path：./最终报告-{YYYY-MM-DD}.md（保存到项目根目录）
- 注意：不是保存到工作目录，而是保存到项目根目录
- 文件名应包含日期以避免覆盖之前的报告
content：按以下结构生成的完整 Markdown 内容

报告结构：

# 信息收集报告

**收集时间范围**: {时间范围}
**收集领域**: {领域列表}
**报告生成时间**: {当前时间，格式 YYYY-MM-DD HH:mm}
**信息源数量**: {处理的信息源总数}
**信息条目数量**: {收集的信息总条数}
**新增信息源**: {添加到 SITE.md 的网站数量}

---

## 执行摘要

{3-5 段简短的摘要，概括：
- 本次收集的主要发现
- 各领域的关键趋势或事件
- 值得关注的重要信息
- 新增信息源的情况}

---

## 一、{领域分类1，如"科技与技术"}

### {子类别1.1，如"人工智能"}

{对该子类别下所有信息的综合分析和叙述，使用段落形式而非列表。
在叙述中使用 [1][2] 等标记引用具体信息源。

例如：
根据多个来源的最新报道[1][2][5]，人工智能领域在本周出现了重要突破。
OpenAI 发布的新模型[1]在多项基准测试中表现出色，而 Anthropic 同时
宣布[2]推出了 Claude 的重大更新。这些进展标志着...

同时，学术界也有新的研究成果[5]表明...}

### {子类别1.2}

{同样的段落形式叙述...}

## 二、{领域分类2}

### {子类别2.1}

{段落形式叙述...}

---

## 信息源列表

{按编号顺序列出所有引用的信息源}

1. [标题1](URL1) - 来源: {信息源名称1}
2. [标题2](URL2) - 来源: {信息源名称2}
3. [标题3](URL3) - 来源: {信息源名称1}
...

---

## 附录：新增信息源

本次信息收集过程中发现并添加到 SITE.md 的新信息源：

{如果有新增：列出新增的网站名称和 URL}
{如果没有新增：说明未发现符合标准的新信息源}

详细评估报告请查看：`新增信息源评估.md`

格式要求（非常重要）：

❌ 不要使用列表形式展示信息内容（除非用户明确要求）
✅ 使用段落形式进行叙述性的分析和总结
✅ 每条引用的信息都必须有信息源引用标记（如 [1][2]）
✅ 最后必须有完整的信息源列表
✅ 引用编号必须与信息源列表一一对应

阶段五：返回结果给用户

步骤 5.1：生成执行报告

向用户报告以下信息：

✅ 信息收集任务完成！

📊 统计信息:
- 处理信息源: {数量} 个
  - SITE.md信息源: {数量} 个
  - WebSearch发现: {数量} 个
- 收集信息条目: {数量} 条
- 新增信息源: {数量} 个（已添加到 SITE.md）
- 生成文件总数: {数量} 个

📁 生成的文件:
- 最终报告: ./最终报告-{YYYY-MM-DD}.md（项目根目录）
- 新增信息源评估: {工作目录}/新增信息源评估.md
- 各信息源总结: {数量} 个
- 网页详细分析: {数量} 个

{如果有失败的信息源，列出失败原因}

请查看最终报告了解详细内容。

阶段六：收集反馈并更新配置

步骤 6.1：询问用户反馈

执行操作：使用 AskUserQuestion 工具询问用户对本次信息收集的意见。

询问内容：

问题 1：本次收集是否满足你的需求？

选项：
- 满足需求，无需调整
- 缺少某些领域的信息
- 时间范围不合适
- 信息类型需要调整
- 其他建议

重要：允许用户选择"其他"以提供自定义反馈。

步骤 6.2：收集额外的反馈信息

如果用户选择了非"满足需求"的选项，继续追问以获取具体信息：

对于"缺少某些领域的信息"：

询问用户：具体缺少哪些领域？
期望得到：领域名称列表

对于"时间范围不合适"：

询问用户：应该调整为什么时间范围？
期望得到：具体时间（如"过去一周"、"过去一个月"等）

对于"信息类型需要调整"：

询问用户：希望看到哪些类型的信息？
期望得到：信息类型（如"更多学术论文"、"更多技术博客"等）

对于"其他建议"：

询问用户：请具体说明
期望得到：开放式反馈文本

步骤 6.3：汇总反馈数据

将用户反馈数据整理成如下格式，准备传递给 personel-updater Agent：

用户反馈汇总：

1. 基础反馈：{满足/不满足}

2. 具体反馈内容：
   - 类型: {缺少领域/时间调整/信息类型/其他}
   - 详情: {具体内容}

3. 额外信息：
   - 本次收集的信息源数量: {数量}
   - 收集到的信息条目数: {数量}
   - 新增信息源数: {数量}

4. 用户建议：
   {如有其他建议，记录在此}

步骤 6.4：判断是否需要启动 personel-updater Agent

决策标准：

启动 Agent 的条件（满足以下任意一项）：

用户明确选择了"缺少某些领域的信息"或"时间范围不合适"
用户提供了具体的"其他建议"
用户在开放式反馈中提到了具体的调整需求

不启动 Agent 的情况：

用户选择"满足需求，无需调整"
用户的反馈过于模糊且无法推断具体调整内容

步骤 6.5：启动 personel-updater Agent（如需要）

执行操作：如果需要启动 Agent，使用 Task 工具调用 personel-updater Agent。

Task 调用参数：

工具名称：Task
subagent_type："personel-updater"
description："根据用户反馈更新个人偏好配置"
prompt：必须包含以下完整信息

prompt 内容模板：

请根据以下用户反馈分析并更新 PERSONEL.md 配置文件：

==== 用户反馈 ====

{步骤 6.3 中整理的用户反馈汇总}

==== 当前 PERSONEL.md 配置 ====

{使用 Read 工具读取的完整 PERSONEL.md 内容}

==== 本次收集统计数据 ====

- 处理的信息源数量: {数量}
- SITE.md 信息源: {数量}
- WebSearch 发现: {数量}
- 收集的信息条目总数: {数量}
- 各领域的信息数量分布:
  {按领域统计信息条数}
- 新增信息源: {数量}

==== 执行任务 ====

1. 分析用户反馈的有效性
2. 判断是否需要更新 PERSONEL.md
3. 如需要更新，执行增量更新（不要重写整个文件）
4. 生成更新报告

PERSONEL.md 文件路径: ./PERSONEL.md

步骤 6.6：等待 Agent 完成

执行操作：

等待 personel-updater Agent 返回结果
收集返回信息：
- 是否执行了更新
- 更新的项目列表
- 报告文件路径
- 任何错误或警告

步骤 6.7：向用户报告反馈处理结果

执行操作：根据 Agent 返回结果向用户报告。

如果执行了更新：

✅ 配置已更新！

📝 更新项目:
- {更新项目1}: {原值} → {新值}
- {更新项目2}: {原值} → {新值}
...

📄 详细报告已保存到: PERSONEL.md-更新报告-{YYYY-MM-DD}.md

后续建议:
{Agent 生成的建议}

现在你可以：
1. 使用新的配置进行下一次信息收集
2. 手动编辑 PERSONEL.md 进行更多自定义调整
3. 查看详细的更新报告了解具体变化

如果没有执行更新：

⚠️ 本次反馈不符合更新条件

原因: {Agent 的分析结果}

PERSONEL.md 保持不变。

建议:
{Agent 的建议}

如果你需要调整配置，可以：
1. 手动编辑 PERSONEL.md 文件
2. 提供更具体的反馈信息，重新运行信息收集并反馈

如果 Agent 执行出错：

⚠️ 配置更新过程中出现错误

错误信息: {错误描述}

PERSONEL.md 保持不变。

建议:
- 检查 PERSONEL.md 文件是否可访问
- 手动编辑文件进行调整
- 重新运行信息收集任务

工具使用清单

必须使用的工具

Task
- 用途：启动项目内定义的 Agent
- 可用的 subagent_type：
  - source-processor：处理单个信息源
  - webpage-analyzer：分析单个网页（由 source-processor 调用）
  - site-evaluator：评估新发现的网站
  - personel-updater：根据用户反馈更新 PERSONEL.md
- 重要：在单条消息中可以多次调用以实现并行处理
Read
- 用途：读取配置文件和本地总结文件
- 使用时机：
  - 读取 PERSONEL.md（步骤 1.2.1）
  - 读取 SITE.md（步骤 1.2.2）
  - 读取各信息源总结文件（步骤 4.2）
Write
- 用途：保存最终报告
- 使用时机：生成最终报告（步骤 4.4）
Glob
- 用途：查找文件
- 使用时机：查找所有总结文件（步骤 4.1）
Bash
- 用途：创建工作目录
- 使用时机：创建日期目录（步骤 1.3.2）
- 命令示例：mkdir -p ./YYYY-MM-DD

可选使用的工具

AskUserQuestion
- 用途：在需求不明确时询问用户，以及在步骤 6 收集用户反馈
- 使用时机：
  - 步骤 1.1 如果需求模糊
  - 步骤 6.1 和 6.2 收集用户对本次收集的反馈
- 原则：尽可能自行分析，避免过度询问

不使用的工具

WebSearch：由 source-processor Agent 使用
WebFetch：由 webpage-analyzer Agent 使用
Edit：由 site-evaluator Agent 和 personel-updater Agent 使用

错误处理原则

单个信息源失败
- 记录错误但继续处理其他信息源
- 在最终报告中注明哪些信息源处理失败及原因
Agent 调用失败
- 记录失败的 Agent 和原因
- 尝试继续完成其他部分
- 在返回结果中明确说明
文件操作失败
- 检查路径是否正确
- 检查权限是否足够
- 提供详细错误信息给用户
配置文件缺失或格式错误
- 如果 PERSONEL.md 缺失或为空，启动交互式初始化流程创建配置文件（见步骤 0.1）
- 如果 SITE.md 缺失或为空，报错并要求用户创建
- 如果格式有问题，尝试解析可用部分
反馈处理和配置更新错误（第六阶段新增）
- 用户反馈过于模糊时：不启动 personel-updater Agent，建议用户提供更具体的反馈
- personel-updater Agent 执行失败时：记录错误，报告用户，PERSONEL.md 保持不变
- Edit 操作失败时：Agent 应记录具体原因（如old_string不唯一），返回失败状态
- 反馈无更新必要时：正常返回不更新的说明，不作为错误处理

性能优化策略

并行处理
- 在单条消息中启动所有 source-processor Agent
- 充分利用并行能力加快处理速度
限制处理量
- 如果信息源过多（>10个），考虑只处理最相关的
- 每个信息源限制处理的网页数量（建议不超过 10 个）
避免重复
- 在最终报告中合并重复信息
- 跨信息源去重

开始执行

现在开始执行信息收集任务！按照上述六个阶段的详细步骤，逐步完成所有工作。

流程完整性提醒：

✅ 阶段零：初始化检查
✅ 阶段一：需求分析与准备
✅ 阶段二：并行收集信息
✅ 阶段三：评估新信息源
✅ 阶段四：生成最终报告
✅ 阶段五：返回结果给用户
✅ 阶段六：收集反馈并更新配置（新增！）

完整的工作流形成了一个"收集-反馈-优化"的闭环，使得系统能够根据用户实际需求不断改进配置。

Install Skill

SKILL.md

智能信息收集 Skill

执行流程总览

详细执行步骤

阶段零：初始化检查

步骤 0.1：检查 PERSONEL.md 文件

步骤 0.1.1：提示用户进行初始化

步骤 0.1.2：收集基础信息

步骤 0.1.3：生成 PERSONEL.md

步骤 0.1.4：确认初始化成功

阶段一：需求分析与准备

步骤 1.1：分析用户需求

步骤 1.2：读取配置文件

步骤 1.3：创建工作目录

步骤 1.4：筛选信息源

阶段 1.5：广泛网络搜索

步骤 1.5.1：构造搜索查询

步骤 1.5.2：执行 WebSearch

步骤 1.5.3：创建虚拟信息源集

阶段二：并行收集信息

步骤 2.0：合并信息源集

步骤 2.1：准备启动参数

步骤 2.2：并行启动 source-processor Agent

步骤 2.3：等待所有 Agent 完成

步骤 2.4：收集 Agent 返回结果

阶段三：评估新信息源

步骤 3.1：汇总新发现的网站

步骤 3.2：启动 site-evaluator Agent

步骤 3.3：等待 Agent 完成

阶段四：生成最终报告

步骤 4.1：查找所有信息源总结文件

步骤 4.2：读取所有总结文件

步骤 4.3：跨信息源综合分析

步骤 4.4：生成最终报告文件

阶段五：返回结果给用户

步骤 5.1：生成执行报告

阶段六：收集反馈并更新配置

步骤 6.1：询问用户反馈

步骤 6.2：收集额外的反馈信息

步骤 6.3：汇总反馈数据

步骤 6.4：判断是否需要启动 personel-updater Agent

步骤 6.5：启动 personel-updater Agent（如需要）

步骤 6.6：等待 Agent 完成

步骤 6.7：向用户报告反馈处理结果

工具使用清单

必须使用的工具

可选使用的工具

不使用的工具

错误处理原则

性能优化策略

开始执行