研究

它的作用¶

research 通过阅读拥有答案的来源来回答问题，然后在仓库中留下一个带引用的 Markdown 文件。它只基于一手来源工作：官方文档、源代码、规范、第一方 API。它会沿着每个说法追溯到拥有该说法的来源，因此当 API 自身文档可访问时，它不会重复博客文章对该 API 的描述。

它不会在对话中回答你。输出是一个文件，写入仓库中已经存放此类笔记的位置，并且每个说法都带有链接。你会得到一份可以回应、交给另一个智能体或丢弃的文档，而不是一个在会话结束时就会消失的答案。

何时使用¶

输入 /research，或者当任务变成阅读跑腿工作时，智能体 会自动使用它。

当下一步是从工作目录之外查明某件事（第三方 API 如何表现、规范说了什么、某个版本说法是否成立），而你不想让自己的线程停下来做阅读时，就使用它。你需要什么决定了使用哪个技能：

research 与 grill-with-docs 之间的界限是返回内容的保质期。研究产生短命的事实，例如截至本周这个库的认证机制做了什么。ADR 记录一个你保留的决策。如果你产出的是一个决策而不是事实，你是在 grilling，而不是在做研究。

委托的跑腿工作¶

阅读作为后台智能体运行。当它沿着每个说法追溯到其一手来源、写入一个 Markdown 文件并回报时，你继续工作。研究是你委托的跑腿工作，而不是你外包的思考。你会得到一份文档，用于拷问、规划或作为设计依据，而你仍然做出决策。

没有什么能阻止后台智能体生成另一个它自己的后台智能体。这是该技能文档记录最充分的问题。

文件放在哪里由仓库决定，而不是由技能决定。它遵循笔记中已经存在的任何约定。如果没有，它会选择一个合理的位置并告诉你在哪里。每次运行写入一个文件。

常见问题¶

它派生了第二个研究智能体。这是有意为之吗？

不。这是一个未关闭的 bug，issue #530。该技能告诉其调用者启动一个后台智能体，但没有限制智能体类型。因此调用者会生成一个 general-purpose 智能体，它拥有 Agent 工具和相同的指令，并再次遵循这些指令。一位报告者测量到，单个研究任务在三次重叠运行中花费了大约 450k tokens，而重复项在半小时后完成，用户看不到它。它也会发生在 Claude Code 之外。用户确认在 Codex 中使用 GPT-5.6-sol 时存在相同的嵌套。没有已发布的修复。用户已经通过添加一行说明来修补自己安装的副本，告诉一个已经是子智能体的智能体自己完成工作。这有帮助，但它只是一条指令，而不是结构性修复。调用技能后，监视你的后台任务列表并停止重复项。

相反的故障也会发生。如果你自己的全局指令禁止智能体再次委托工作，后台智能体会拒绝任务，而技能不会告诉你就什么都不做。

文件应该放在哪里，我应该提交它吗？

该技能把文件放在仓库已经存放笔记的位置，并且没有其他意见。社区观点基本已经确定：保留 ADR，而不是研究文件。关于这个问题的一个 Discord 帖子说得最清楚：“ADR 要保留。其他一切在完成后归档或删除。否则它会变成工作残渣，如果你已经偏离了规范/研究，还会污染未来对仓库的阅读。”研究文件记录的是它被写下那天为真的内容，因此过时的文件比没有更糟。总体而言，这些文件不属于 git，也没有标准存放位置。人们改用 Obsidian、单独的知识仓库或问题跟踪器。

什么算作“高信任”一手来源，由谁决定？

模型 决定。该技能列出了符合条件的来源类型（官方文档、源代码、规范、第一方 API），但没有允许列表、没有域名门控，也没有验证环节。当该技能最初被提出时，这是最强烈的反对意见，而且没有人公开回答过：“五个指向垃圾的研究子智能体只会更快地给你五个自信的错误答案。你如何把关什么算作高信任来源？”你唯一的保护是每个说法上的引用。跟踪其中两三个。如果它们落到该事物的摘要而不是事物本身，这次运行就失败了。

后续会话会重用早期运行发现的内容吗？

不会。没有任何东西会自动加载过去的研究文件。文件会留在仓库中，直到人类或某个技能指向它。这是早期对该设计最强烈的质疑：“价值在于 Markdown 成为智能体稍后重读的背景，而不是获取本身。一个只写一次的死文件只是一个花哨的搜索。”已发布的技能没有解决这个问题。在实践中，只有当你自己把它输入下一步时，文件才有用：把它附加到规范中、引用到 grilling 会话中、让一个工单指向它。

为什么不直接让代理去读文档？

你可以这样做，而一个恰好说明这一点的双行 prompt 正是这个技能所取代的做法。这个技能提供了 prompt 不具备的两点。它在后台运行，因此你会话的 上下文 保持干净。并且一手来源约束和引用文件输出每次都相同，而不是取决于你如何措辞 prompt。与 harness 自身的 deep-research 模式相比，区别在于文件和一手来源规则，而不是搜索。如果对于一个小问题，一个双行 prompt 就能得到你需要的东西，就用双行 prompt。

它什么时候停止阅读？

这个技能没有停止标准。这表现为两种看似相反但原因相同的抱怨：代理钻得过于深入，以及代理广泛覆盖某个主题却漏掉了那个关键的细节。一位实践者这样描述：“deep-research 技能有时有点太深入。而让代理去研究通常会导致遗漏关键细节。”你必须设定范围。一个狭窄且可回答的问题（一个 API、一个行为、一个版本声明）返回的结果远好于“研究 X”。

/wayfinder 创建了研究工单。我需要自己解决它们吗？

不，现在它会替你触发它们。在 v1.1 之后未发布的更改中，一个绘图会话会为每个研究工单生成一个 /research 子代理，并并行运行它们。每个子代理都会将其发现记录在一个一次性 research/<name> 分支上，并带有来自工单的 上下文指针。研究工单是 wayfinder 每会话一个工单规则的唯一例外，因为它们是 AFK：没有任何事情在等你。一个已知问题：之后删除该分支会破坏工单中的上下文指针。

如果它正在工作¶

• 你自己的会话继续运行。如果你坐在那里看着它阅读，说明委托没有发生。
• 恰好出现一个新后台任务。第二个名称几乎相同的任务就是嵌套 bug。
• 出现一个新的 Markdown 文件，位于仓库已经用于笔记的文件夹中，并且代理会告诉你路径。
• 其中每个论断都带有链接，随机点开两个会带你到官方文档、规范或源文件本身，而不是某人的转述。
• 你仅凭该文件就能做出你之前卡住的那个决定，而无需自己回到来源。

它在哪里适用¶

research 是一个随时可用的独立技能。它服务于思考类技能，并不是构建链中的一个步骤。你把它生成的文件带入流程。grilling 和 grill-with-docs 在已经掌握事实时会提出更尖锐的问题，to-spec 可以基于它进行综合。wayfinder 是唯一直接调用它的技能。它使用 /research 子代理在其地图上解决每个研究工单。要查看完整地图，请参阅 ask-matt。