研究协调器Skill：用「双代理」把零散调研变成可复用的结构化知识资产
核心结论速览
- 双代理架构：研究协调器Skill（英文名 research，技能ID 12609）把一次深度研究拆成「规划代理」和「执行代理」两个独立角色，用干净上下文分别完成"想清楚"和"写出来"。
- 先审后执行：规划代理先产出一份可编辑的研究计划文件，用户在确认前可以修改目标和策略，避免 AI 朝着错误方向跑完全程。
- 产出即资产：执行阶段自动生成主研究笔记、原子概念笔记、示例文件，复杂主题还会生成可视化概念地图，并归档进固定的笔记目录体系。
- 触发极简：核心入口就是
/research <主题>一句话指令，无需自己拆解任务、逐轮追问。 - 省上下文也省重复：规划阶段会先检索已有笔记，避免重复造轮子；执行阶段在全新上下文中进行，显著降低令牌消耗。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 研究协调器Skill |
| 技能英文名 | research |
| 技能ID | 12609 |
| 定位 | 面向技术、概念或复杂主题的深度研究工作流 |
| 触发方式 | /research 指令（配合主题参数使用） |
它解决什么问题
大多数人做技术调研的流程是：打开对话窗口 → 问一句 → 拿到一段回答 → 复制到笔记里 → 三天后完全找不到。问题集中在三处：一是没有规划，问得太散，回答也跟着散；二是上下文污染，一边规划一边写作，前面的对话越来越长，后面的产出质量越来越低；三是不可复用，调研结果无法沉淀成可检索、可链接的知识。
研究协调器Skill 正是针对这三点设计的：它把"研究"这件事工程化——先规划、再执行、最后归档，每一步都有明确产物。
一键安装的思路与步骤
需要说明的是，该技能本身是一个工作流技能，它依赖宿主环境（详情中称为 OrbitOS）以及以下能力前提，具体安装命令与入口请以官方说明为准：
- 确认环境支持子代理（Subagent）：该技能的核心是调度
general-purpose类型的子代理，因此宿主需要支持技能加载与子代理调度能力。 - 确认具备联网检索工具：执行代理在研究环节会调用 WebSearch 与 WebFetch，若环境未开启联网能力，研究成果会退化为模型已有知识。
- 准备目录骨架：该技能假定了一套固定的笔记目录结构，包括
10_日记/、20_项目/、30_研究/、40_知识库/、90_计划/、99_系统/（含提示词与模板）。首次使用前建议先建好这些目录，否则计划文件与笔记无处落地。 - 加载技能：在技能市场/技能管理入口中搜索技能名「研究」或技能ID 12609 完成添加（具体入口与命令以官方说明为准）。
- 验证是否生效：新建一次会话，输入
/research 一致性哈希，观察两点——是否自动生成形如90_计划/Plan_YYYY-MM-DD_Research_<主题>.md的计划文件；是否返回"我已在 [计划文件路径] 创建了研究计划，请查看并按需修改，确认后继续执行"这类提示。两者都出现，说明技能链路正常。
该技能的主要功能和特点
- 规划与执行分离的双代理机制：规划代理只负责识别上下文、制定策略、写计划文件；执行代理只拿着计划文件路径开始研究。两者互不继承对话历史，各自保持"新鲜上下文"。
- 上下文感知的规划：规划代理会检查主题是否与
20_项目/中的活动项目相关，判断所属领域（如软件工程、金融、健康等），并主动搜索30_研究/与40_知识库/以避免重复笔记。 - 角色化专业知识匹配：规划时会扫描
99_系统/提示词/，挑选最贴合该主题的专业知识角色，让后续研究更"懂行"。 - 可编辑的研究计划模板：计划文件统一包含研究目标、发现的上下文、研究策略清单、输出结构、澄清问题五个部分。澄清问题覆盖"你的知识水平（初级/中级/高级）"“这是针对特定项目还是一般学习”“更喜欢理论优先还是示例驱动”，留空则按标准假设继续。
- 结构化研究产出：主研究笔记固定包含概述、核心概念（带原子笔记维基链接）、工作原理、示例、最佳实践、常见陷阱、相关阅读、参考资源八个板块。
- 原子化知识库沉淀：每个可复用概念单独成篇（1–3 段），存入
40_知识库/<分类>/，并附"相关概念"链接，方便后续被反复引用。 - 可视化概念地图：主题复杂时额外生成
<主题>_Map.canvas，用图形方式呈现概念之间的关系。 - 实践示例落地：动手类主题自动创建
examples/目录并放入可运行的代码示例。 - 自动归档与日志追踪：完成后把计划移入
90_计划/归档/，并在当天日记10_日记/YYYY-MM-DD.md中登记；若与项目相关，还会在项目进度中补充链接。 - Obsidian 格式规范内建：严格执行 YAML Frontmatter 规则（
---起始于第 1 行、标签用数组语法、禁止重复键），相关链接一律放在正文底部的「相关阅读」区而非 frontmatter，避免属性污染。 - 友好的边缘处理：主题过宽泛时自动拆子主题；主题已存在时只做更新不新建重复笔记；修改请求直接改现有笔记而非另起一份。
和普通"丢给大模型问一句"的做法相比，它强在流程可控、产物可查、知识可累积——你得到的不是一段聊天记录，而是一套能被自己未来的自己读懂的笔记。
如何使用该技能？
步骤 1：发起研究
在对话框中输入 /research 加主题，可以附带具体问题或项目背景。示例输入：
/research React Server Components
带上下文的示例：
/research OAuth2 授权码流程，重点搞清楚 PKCE 为什么必需，会用在我们的开放平台项目上
步骤 2：等待规划代理产出计划
技能会立即生成规划代理，代理完成上下文识别、领域判定、重复检查、角色挑选后，在 90_计划/ 下写入计划文件。随后你会收到类似提示：
我已在
90_计划/Plan_2025-01-15_Research_OAuth2.md创建了研究计划。请查看并按需修改，确认后继续执行。
步骤 3：审阅并（可选）填写澄清问题
打开计划文件，重点看三处：研究目标是你要的吗；研究策略清单是否需要增删；澄清问题是留空还是要答。例如填成：
**问:** 你目前的知识水平是什么？（初级/中级/高级）
**答:** 中级
**问:** 这是针对特定项目还是一般学习？
**答:** 特定项目——开放平台项目
**问:** 你更喜欢理论优先还是示例驱动的方法？
**答:** 示例驱动
步骤 4：确认执行
回复确认后，协调器会以干净上下文生成执行代理，并把计划文件路径作为唯一输入传入。执行代理会读取计划（含你的修改与答案），调用 WebSearch 抓最新信息、WebFetch 读官方文档、收集实际示例、抽取原子概念，然后落盘。
步骤 5：查看产出
执行完成后会返回一份研究总结，格式大致如下：
## 研究总结: OAuth2 授权码流程
**已创建:**
- 主笔记: [[OAuth2 授权码流程]] 位于 30_研究/SoftwareEngineering/
- 知识库概念: [[PKCE]], [[授权码]], [[重定向URI]]
- 示例: 3 个文件位于 examples/
**核心要点:**
1. ……
2. ……
3. ……
**下一步:**
- [ ] 通过实践练习巩固
- [ ] 应用到[[开放平台项目]]
- [ ] 一周后复习加深记忆
此时你可以直接跳到主笔记阅读，或顺着维基链接进入原子概念笔记做深挖。
步骤 6：按需迭代
如果对结果不满意，直接提出修改要求即可。技能的后继协议是：读取现有研究笔记 → 就地修改 → 必要时补充新原子概念 → 若研究不完整则更新状态。不会再新建一份重复笔记。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 研究协调器Skill（research） | 结构化深度研究工作流 | 双代理规划+执行、计划可审、笔记/知识库/示例/地图多产物、自动归档 | 需支持子代理与联网工具的宿主环境，需预置目录骨架，以官方说明为准 | 技术选型、概念深挖、项目前期调研、长期知识库建设 | 优势：流程可控、产出可复用、省令牌、避免重复笔记；不足：依赖固定目录体系，首次配置有学习成本 |
| 通用大模型对话（直接提问） | 即时问答 | 对话式解释、追问、生成代码片段 | 几乎为零，打开即用 | 快速确认某个名词、临时查漏补缺 | 优势：门槛最低、响应最快；不足：无规划、易发散、上下文越长质量越低、结果难以沉淀 |
| 搜索引擎 + 手工整理笔记 | 传统人工调研 | 检索、阅读原文、手动摘录归档 | 零成本上手，但耗时最长 | 需要一手权威信息、合规要求高的场景 | 优势：信息源最可靠、完全自主可控；不足：效率极低、依赖个人归纳能力、容易半途而废 |
| 笔记软件内置 AI 插件 | 笔记内的写作与问答助手 | 摘要、续写、基于笔记库问答 | 需安装插件并配置模型，以官方说明为准 | 已有笔记的二次加工、局部润色 | 优势：与既有笔记贴合紧密；不足：多偏"改写/摘要"，缺少完整的调研流程与代理分工 |
选型建议：如果你只是想知道"某个词是什么意思"，通用对话就够；如果你需要一份能被三周后的自己直接复用的研究成果，并且已经在用 Obsidian 式的本地知识库，研究协调器Skill 的流程化优势才会真正体现出来。
该技能的典型应用场景与实际体验情况
场景一：后端工程师啃下一个陌生技术栈
角色：需要评估"是否引入 React Server Components"的前端/全栈工程师。痛点：官方文档、社区文章、博客观点互相矛盾，看完仍不知道边界在哪。
使用方式：/research React Server Components，在澄清问题里填"中级 + 特定项目 + 示例驱动"。规划代理会先检查 30_研究/ 是否已有相关笔记，再生成策略；执行代理产出主笔记（含工作原理与示例代码）、examples/ 下的可运行片段，以及"常见陷阱"章节。
实际体验：上手几乎无门槛，一句指令即可。效果上，最大的收益不是"答案"，而是结构——主笔记的"核心概念"区直接链到原子笔记，可以按需深挖，而不是被一篇长文淹没。注意事项：如果宿主未开启联网，执行代理只能依赖模型已有知识，时效性会打折扣。
场景二：项目启动前的技术选型调研
角色：技术负责人。痛点：选型结论散落在群聊、会议记录和若干浏览器标签页里，两周后无人能复盘。
使用方式：把主题写成"OAuth2 与 SAML 在开放平台场景下的对比"，并在计划文件的研究策略中手动加一条"对比两者在移动端与第三方集成的差异"。因为计划是 Markdown 文件，你可以像改需求文档一样改它。
实际体验："先审后执行"这个设计非常实用。AI 跑完整个研究通常要花不少时间，能在几分钟的规划阶段就把方向纠偏，比事后返工划算得多。注意事项：主题过宽时（如只写"安全"），规划代理会尝试拆子主题，但仍建议自己先收窄到一个可回答的范围。
场景三：把一个模糊概念沉淀成团队知识库
角色：团队内的"知识管理员"。痛点：每个人都在学，但没人沉淀，同一个概念被反复讲三遍。
使用方式：针对"一致性哈希"这类基础概念发起研究，重点利用原子笔记机制——每个可复用概念单独成篇并可互链。完成后计划文件自动归档，当天日记留有记录，便于回溯"我是什么时候学的这个"。
实际体验：原子笔记控制在 1–3 段，短小但互相链接，长期积累后知识库的网状结构会自然浮现。注意事项：一定要遵守 frontmatter 规范（相关链接放正文底部而非 frontmatter），否则 Obsidian 的属性面板会变得很乱——技能本身已内建这条规则，用户手动编辑时不要破坏它。
场景四：动手型主题的实操准备
角色：准备上手某个新框架的开发者。痛点：概念看懂了，一动手就卡在环境配置。
使用方式：发起 /research <框架名>，执行代理会为动手型主题专门创建 examples/ 文件夹并放入可工作的代码。
实际体验：这类主题的产出价值最高，因为示例是"能跑"的而不只是"能读"的。注意事项：示例代码仍需自行核对版本与依赖，技能文档中并未承诺示例一定适配你的本地环境。
该技能能为用户带来的价值
1. 把隐性的调研流程显性化
过去"研究一个主题"全靠个人经验驱动，质量波动极大。现在流程被固定成"识别上下文 → 制定策略 → 用户确认 → 执行 → 归档"五步，任何人按同一路径走，产出的下限被显著抬高。
2. 上下文隔离带来的质量与成本双收益
规划与执行分成两个代理，各自拥有干净上下文。好处是双向的：一方面执行代理只专注研究与写作，不被冗长的前期对话干扰，输出更聚焦；另一方面，技能文档明确指出这种方式减少令牌使用——长对话反复携带历史是成本黑洞，拆开之后每一段都更轻。
3. 从"一次性回答"到"可复用资产"
一次研究可能产出 1 篇主笔记 + N 篇原子概念笔记 + 若干示例文件 + 1 张概念地图。这些产物带维基链接、带 frontmatter 元数据、带分类路径，可以在未来被搜索、被引用、被更新。边际价值随时间上升，而不是像聊天记录一样随时间沉底。
4. 重复劳动的自动规避
规划阶段会主动搜索 30_研究/ 与 40_知识库/，发现已有笔记就转向"更新"而非"新建"。对知识库长期维护者来说，这一条能省下大量去重与合并的力气。
5. 降低"深度研究"的心理门槛
不需要会写提示词、不需要懂任务拆解、不需要知道该问哪几个问题——把主题丢进去，剩下的交给规划代理。澄清问题留空也能跑，按标准假设继续。对初级工程师和跨界学习者尤其友好。
常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？
A：它属于技能市场中的一项技能，通过技能管理入口搜索技能名「研究」或技能ID 12609 添加即可，具体命令与入口以官方说明为准。使用前需要确认宿主环境支持子代理调度与联网检索，并按技能约定准备好 10_日记/、20_项目/、30_研究/、40_知识库/、90_计划/、99_系统/ 等目录。是否收费取决于所在平台与所用模型，本技能详情中未包含价格信息，请以官方说明为准。
Q2：不填那些"澄清问题"能正常用吗？
A：可以。计划文件里的三个澄清问题（知识水平、是否针对特定项目、理论优先还是示例驱动）标注为可选，留空时执行代理会按标准假设继续。但如果你对深度和风格有明确偏好，填上会明显提升产出贴合度——尤其是"示例驱动"这一项，会直接影响是否创建 examples/ 目录。
Q3：它和直接问大模型有什么区别？我为什么需要多一步确认？
A：直接提问是"一问一答"，没有规划、没有沉淀、上下文越长质量越差。研究协调器Skill 多出的那一步确认，恰恰是它最有价值的设计之一：深度研究往往耗时较长，在几分钟的规划阶段就能审阅目标与策略、修改研究清单，比等执行完再返工划算得多。这一步同时也是"用户控制"的体现。
Q4：如果我要研究的主题之前已经研究过了，会不会生成两份重复笔记？
A：不会。规划代理会搜索 30_研究/ 与 40_知识库/ 做重复检查；若发现已有内容，会注明情况，执行代理则转为更新现有笔记。后续如果你提出修改要求，技能的后继协议也是"读取现有笔记 → 直接修改 → 不创建重复"，必要时才补充新的原子概念。
Q5：它适合谁用？什么情况下不适合？
A：最适合三类人——需要持续沉淀知识库的工程师与研究者、要做技术选型或方案对比的技术负责人、以及正在系统学习某个领域的学习者。不太适合的情况是：只想快速确认一个名词释义（用通用对话更快）、对信息源有严格合规要求必须人工核验一手资料的场景（AI 检索结果仍需人工把关）、以及尚未搭建笔记目录体系且不打算搭建的用户——这套技能的价值很大程度上来自"产物有地方安放"。