web-research（网络研究技能）Skill 是什么？如何下载安装使用？

网络研究技能（web-research）：把复杂网络调研拆成可委派、可复用的结构化流程

核心结论速览

它是什么：网络研究技能（web-research）是一套「先规划、再并行委派子代理、最后系统化合成」的调研方法论，配套 task、write_file、read_file、list_files、fetch_url 等工具完成全流程。
解决什么问题：面对需要多来源交叉验证的复杂主题，避免「东查一点西查一点、结论零散、来源丢失」的常见困境，让调研过程有文件留存、有引用、可追溯。
怎么用：第一步建研究文件夹并写 research_plan.md；第二步用 task 工具生成研究子代理并行采集；第三步读取 findings_*.md 归纳成有据可查的结论与报告。
关键约束：每个子代理最多 3-5 次网络搜索、并行最多 3 个子代理、只对本地文件用 read_file（网页一律用 fetch_url），避免过度研究与工具误用。
适合谁：需要做竞品调研、行业扫描、多主题比较分析的研究者、产品经理、内容与运营同学，以及把调研流程固化为工作流的开发者。

1. 该技能叫什么？如何下载安装 AI 技能提升开发效率？

基本信息

项目	内容
中文名	网络研究技能
英文名	web-research
技能 ID	13841
技能定位	以结构化方法完成全面网络研究的技能，强调规划、高效委派与系统化合成

它解决什么问题

普通的「直接问一句、让模型上网搜一下」有三类典型缺陷：

范围失控：复杂主题一次性搜索，容易浅尝辄止，覆盖不到关键子问题；
结论无据：答案里缺少可核验的来源链接，或者来源与结论对不上；
过程不可复用：调研过程散落在对话里，无法沉淀为文件、无法交给别人复核或迭代。

网络研究技能把这套流程标准化：先用 write_file 写下研究计划，再用 task 工具派发研究子代理并行工作，子代理把发现写成文件，最后由主流程汇总成带引用的结论或报告。

安装思路与步骤（一键安装 AI 技能提升效率）

该技能的详情内容属于技能说明文档，未提供具体的安装命令、下载地址或价格信息，因此以下为通用思路，具体命令、入口与授权方式请以官方说明为准：

确认前提：你所使用的 AI 编程/Agent 环境需要支持技能（Skill）加载机制，并且具备 task、web_search、write_file、read_file、list_files、fetch_url 这些工具能力；其中子代理依赖 web_search（详情中提到使用 Tavily 搜索网络）。
获取并放置技能：通过官方技能市场、技能仓库或团队内部技能目录获取 web-research 技能文件，按官方文档说明放入对应的技能目录（通常为技能文件夹 + 技能说明文件的结构），以官方说明为准。
启用技能：在会话或项目中启用该技能，使其说明文档被加载进上下文。
验证是否生效：发起一个明确的调研类请求（例如「请用结构化方法调研某某主题并给出带来源的结论」），观察是否出现「创建研究文件夹 → 编写 research_plan.md → 派发子代理 → 生成 findings 文件 → 合成结论」的动作链。若技能未被加载或工具缺失，通常会表现为无法创建文件或无法派发子代理。
注意权限：由于会写本地文件与访问网页，请确认工作目录可写、网络访问可用。

2. 该技能的主要功能和特点

强制规划先行：要求先创建 research_[topic_name] 研究文件夹，并用 write_file 写出 research_plan.md，包含「主要研究问题 + 2-5 个不重叠子主题 + 每个子主题的预期信息 + 结果合成方式」。这一步把模糊的问题变成可执行的任务清单。
子代理并行研究：用 task 工具为每个子主题生成一个研究子代理，每个子代理拥有 web_search 与 write_file 两项能力，职责单一、范围明确。
基于文件的沟通：子代理不直接把结果回传给主流程，而是写入 research_[topic_name]/findings_[subtopic].md，天然形成可审计的中间产物。
搜索预算控制：每个子代理最多 3-5 次网络搜索，最多并行 3 个子代理，用「适可而止」原则避免无效堆量。
系统化合成：先用 list_files 看有哪些发现文件，再用 read_file 逐个读取，最终输出直接回答原始问题、整合各子主题见解、并用 URL 标注来源的结论；需要时还可生成 research_report.md。
工具分工明确：本地文件用 read_file，网页内容用 fetch_url（转为 markdown），从机制上降低「用错工具导致内容读不到」的风险。
规划强度可按复杂度调节：简单事实查找 1-2 个子主题；比较分析每个比较元素 1 个子主题（最多 3 个）；复杂调查 3-5 个子主题。

和普通「搜一下再说」的做法相比，它强在流程可控、产出可留档、结论可核验。

3. 如何使用该技能？

步骤 1：创建研究文件夹

在当前工作目录下建立专用文件夹，例如研究「AI 编程助手市场格局」：

mkdir research_ai_coding_assistants

步骤 2：分析问题并写出研究计划

把大问题拆成不重叠子主题，然后用 write_file 写入 research_ai_coding_assistants/research_plan.md。示例内容结构：

主要研究问题：当前主流 AI 编程助手的产品定位与差异是什么？
子主题 1：主流产品的核心功能与目标用户
子主题 2：定价模式与商业化路径
子主题 3：开发者社区的评价与常见抱怨
预期信息：每个子主题需给出关键事实、来源链接
合成方式：按「功能—定价—口碑」三段式对比，最后给出选型建议

步骤 3：派发研究子代理（最多并行 3 个）

对每个子主题调用 task 工具，指示模板可参考：

研究[主流 AI 编程助手的核心功能与目标用户]。使用 web_search 工具收集信息。
完成研究后，使用 write_file 将您的发现保存到 research_ai_coding_assistants/findings_features.md。
包括关键事实、相关引用和来源 URL。
最多使用 3-5 次网络搜索。

要点：问题描述要具体、不使用缩写；明确写出目标文件路径；明确搜索次数上限。

步骤 4：审查发现文件

先 list_files research_ai_coding_assistants 查看生成了哪些文件，再用 read_file 搭配文件路径读取（如 research_ai_coding_assistants/findings_features.md）。若需要补充某个网页的细节，使用 fetch_url 抓取该 URL 并转为 markdown，不要对网址使用 read_file。

步骤 5：合成结论与产出报告

输出一份直接回答原始问题的答复：整合所有子主题观点、为关键事实标注来源 URL、并坦率指出信息空白或局限。如果用户要求正式交付物，再用 write_file 生成 research_ai_coding_assistants/research_report.md。

输入输出示例

输入：「帮我调研三个主流 AI 编程助手的差异，要带来源。」
预期输出：一个研究文件夹（含计划文件 + 多个发现文件）、一段带来源链接的对比结论，以及可选的完整研究报告文件。

4. 同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
网络研究技能（web-research）	结构化多子代理网络调研流程	研究计划文件、子代理并行搜索、发现文件留存、带引用合成、可选报告输出	需支持技能加载与 `task`/文件/抓取类工具，按官方说明配置	复杂主题调研、跨主题比较、需引用与可复核的报告	优势：流程可控、过程留档、来源可追溯；不足：依赖工具环境，简单查事实略显重
直接对话式搜索（让 AI 随手搜一次）	轻量即时问答	单轮检索 + 概括	极低，开箱即用	单一事实确认、快速了解概念	优势：快；不足：覆盖浅、来源易缺失、难以复核
通用深度研究类产品	端到端自动调研报告	自动多轮检索、生成长报告	中等，通常需产品账号，以官方说明为准	行业研究、长文报告	优势：省心；不足：中间过程透明度与可控性通常弱于文件化流程
手工多标签页调研 + 自建笔记	人工主导的传统调研	人工搜索、人工摘录、人工汇总	低，但耗时高	高价值、需强判断的调研	优势：判断力强；不足：效率低、易漏项、难以并行

5. 该技能的典型应用场景与实际体验情况

场景一：产品经理做竞品比较分析

痛点：多个竞品、多个维度（功能、定价、用户口碑），人工整理容易漏项。使用方式：把「每个比较元素一个子主题（最多 3 个）」写进 research_plan.md，派发 3 个子代理并行采集，最后按维度合成对比表。实际体验：结构清晰、并行效率高；注意子主题必须不重叠，否则会出现重复信息。

场景二：内容/运营做选题背景调研

痛点：需要可信数据与来源链接支撑观点。使用方式：子代理把关键事实与来源 URL 写入 findings_*.md，合成时逐条引用。实际体验：引用可核验是最大收益；注意每个子代理 3-5 次搜索的预算限制，主题过宽时要靠拆分而非加搜索次数解决。

场景三：开发者把调研流程固化为工作流

痛点：团队重复做同类调研，经验无法沉淀。使用方式：把研究计划的模板结构、子代理指示模板固定下来，产出目录结构统一为「计划 + 发现 + 报告」。实际体验：上手不难，但需要理解 read_file 只读本地文件、网页要用 fetch_url 这条规则，否则容易出现「读不到内容」的困惑。

场景四：复杂调查（3-5 个子主题）

痛点：问题跨度大，单线程调研容易半途丢失线索。使用方式：拆成 3-5 个子主题，分批并行（每次最多 3 个），最后统一读文件合成，并显式说明信息空白。实际体验：整体可控；注意事项是不要为了「更全面」无限加搜索，详情中明确建议 3-5 次搜索通常足够。

6. 该技能能为用户带来的价值

效率提升：并行子代理 + 明确分工，把串行的人工搜索变并行采集；搜索预算上限避免无效消耗。
门槛降低：不需要自己设计调研方法论，按「计划—委派—合成」三步走即可得到结构化结果。
质量可控：结论必须整合子主题见解并标注来源 URL，还会主动指出信息空白，减少「看似完整实则站不住」的答案。
过程资产化：研究文件夹、计划文件、发现文件、可选报告形成完整证据链，便于复核、交接与二次迭代。
长期价值：这套「先写计划、再委派、再合成」的模式可迁移到任何复杂信息任务，成为团队可复用的调研范式。

7. 常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？ A：安装方式取决于你所用的 AI 环境，通常是在技能市场或技能目录中获取 web-research 并按官方文档启用；费用与授权信息详情中未提供，请以官方说明为准。安装后建议用一个调研类请求验证「建文件夹→写计划→派子代理→出发现文件」的链路是否跑通。

Q2：它和直接让 AI 上网搜一下有什么区别？ A：直接搜索通常是单轮、浅层、无留档；本技能强制先写 research_plan.md，再按子主题并行委派子代理，发现写入 findings_*.md，最后系统化合成并标注来源。复杂主题差异明显，简单事实查找则用 1-2 个子主题即可，不必上重流程。

Q3：为什么子代理最多只能搜 3-5 次、最多并行 3 个？ A：这是技能内置的「适可而止」原则：通过拆分不重叠子主题来控制覆盖度，而不是靠无限增加搜索次数。主题太宽时应增加或细化子主题，而非突破预算。

Q4：读取内容时总读不到，是什么原因？ A：常见原因是工具用错：read_file 只用于本地文件；网页内容必须用 fetch_url（会转换为 markdown）。另外合成前建议先 list_files 确认生成了哪些发现文件，再用文件路径读取。

Q5：适合谁用？什么情况下不必用？ A：适合需要多来源交叉验证的研究者、产品与运营、需要可引用报告的场景。若只是查一个确定事实（如某产品发布时间），用轻量搜索更快；本技能的价值在复杂主题、比较分析与需要留档复核的调研任务。