research 精读：12 行定住一个后台代理，产物是一个带引用的 Markdown 文件

（本文读的是 mattpocock/skills 快照 5beb35b，2026-10-19。引用原文都能按文中路径回仓库核对。这是「逐个技能精读」系列的第十八篇，聚焦 research 一个技能。）

它怎么工作：三句话，派一个后台代理

skills/engineering/research/SKILL.md 是这一路读下来最短的技能文件——12 行，一句话加三条编号职责：

Spin up a background agent to do the research, so you keep working while it reads.

Investigate the question against primary sources (official docs, source code, specs, first-party APIs), not a secondary write-up of them. Follow every claim back to the source that owns it.

Write the findings to a single Markdown file, citing each claim’s source.

Save it where the repo already keeps such notes; match the existing convention, and if there is none, put it somewhere sensible and say where.

触发方式：敲 /research，或者任务本身变成「阅读体力活」时自动上场。产品形态很关键——它不在对话里回答你。产物是一个文件：每条断言带来源链接，位置由仓库已有的笔记惯例决定，一次只写一个。

三条职责各自对应一个真实的失败：

「后台」对应别占住你的线程。文档的判据很形象：Your own session keeps going. If you are sitting watching it read, the delegation didn't happen.
「一手来源」对应别复述别人的复述。品类是开放的（官方文档、源码、规范、第一方 API），判断权在模型手里，技能只点名「哪类算」。
「落一个带引用的文件」对应可审计。文档给的最短验收法：随手点开两三条引用，如果落在一篇「关于它的介绍」而不是它本身，这次运行就是失败的。

还有近邻之间的分界，判据是保质期：research 产出短命事实（这个库这周的鉴权机制是什么样的），grill-with-docs 产出你打算长期保留的决定（写进 GLOSSARY.md 和 ADR）。如果产出的是决定而不是事实，那你是在被追问，不是在研究。

它和「一般技能」的差别：把位置和格式都交出去

一般的「深度研究」技能会规定路径、规定模板、规定章节结构，因为它想保证产物长成自己期望的样子。research 反过来：只承诺三件事（后台、一手来源、带引用的单文件），把「文件放哪、叫什么、长什么格式」全部交给宿主仓库的既有惯例。这是一次很彻底的依赖倒置——技能不定义产物，仓库定义产物；仓库没有惯例时，它挑一个合理的地方并明确告诉你路径。

第二个差别是它把自己做成了「原语调用」而不是流程：没有检索策略、没有来源打分、没有交叉验证、没有 stopping criterion。它假定调用方（你，或 wayfinder）已经握着一句可回答的问题。文档把这个空缺说得很直接：The skill has no stopping criterion. 并且指出两种看起来相反的抱怨——「钻得太深」和「铺得太广却漏掉关键细节」——其实同一个原因，解药是由你来缩小范围：一个 API、一个行为、一条版本断言，远好于「研究一下 X」。

第三个差别是它默认你会亲手把文件带进下一步。没有任何东西会自动重读过去的 research 文件，值不值钱取决于你有没有把它塞进一份 spec、引到一次追问里、或者挂到一张工单上。文档里对这个设计最重的一句质疑也在这一层：the value's the markdown becoming context the agent re-reads later, not the fetch itself. A write-once dead file is just a fancy search.——而它至今没有解决。

它有意识摒弃了什么

一、摒弃了「在会话里回答」。 回答会随会话蒸发；文件可以被反驳、转交、丢弃。它取代的其实是那个朴素做法——一条两行的 prompt（「去读一下文档」）。技能相对那条 prompt 只多两件东西：后台运行不脏上下文，以及每次都一样的「一手来源 + 引用」约束。文档甚至直说：如果两行 prompt 就够用，那就用两行 prompt。

二、摒弃了写死路径与格式。 目录规范是宿主的事，技能越俎代庖只会造出没人读的孤岛。

三、摒弃了对「文件该不该进 git」的意见。 社区共识大致是这类文件不该留在 git 里（它记录的是写下那天为真的东西，过期比没有更糟）——但这属于使用者的判断，技能不做规定。

四、摒弃了来源白名单。 技能只点名来源的种类，没有域白名单、没有网关、没有验证环节。文档承认这是它被提过最响的反对意见：「五个研究子代理指向垃圾，只是更快地给你五个自信的错答案」——至今没人正面回答，唯一的保护就是每条断言上的引用。

五、摒弃了「保证」这个词。 文档把两个已知问题摊开：后台代理可能再派一个后台代理（issue #530，有人量到一次研究烧掉约 450k token、三个重叠的运行，第三个还在你看不见的地方又跑了半小时）；反过来，如果你的全局指令禁止再委派，后台代理会拒绝任务，技能什么都不做也不告诉你。

原文证据

最短的正文里最能说明设计意图的，是第一条和第三条的措辞：

Investigate the question against primary sources … not a secondary write-up of them. Follow every claim back to the source that owns it.

Save it where the repo already keeps such notes; match the existing convention, and if there is none, put it somewhere sensible and say where.

「能落成一条断言、并且你能顺着它走回源头」才是产物的价值所在，这也是文档为什么把它叫 legwork you delegate, not thinking you outsource：你交出去的是阅读，不是决定。而「说 where」这四个词是整篇最便宜的一条设计——它把一次静默的落盘变成一次可交接的动作。

可迁移结论

短技能的前提是复用现成原语。 12 行之所以够，是因为它站在三样已经存在的东西上：后台代理、一手来源这个既有约束、仓库自己的笔记惯例。原语越硬，技能越能薄。
把产物位置交给宿主惯例，别写死。 需要时要求它把路径告诉你——这一条比任何目录规范都实用。
给产物定一条可审计的验收法。 「随手点开两三条引用，看落在哪」——一句可执行的检查，胜过一堆质量形容词。
把「技能不解决什么」写进文档。 没有停止条件、不会自动复用、不评审来源，全部摆出来。承认空缺比假装覆盖更能让使用者做对判断。
用「保质期」给相邻技能划界。 事实 vs 决定，比「压力测试 / 不做决定」这类描述更容易在当场分清该用哪个技能。

research 和 tdd 恰好是这套技能的两个极端：一个把标准写得很厚却只讲规则，一个只有 12 行却要动一个后台代理。它们能站住的原因一样——每一条都只承诺一件可验证的事。research 的承诺是：读到的每句话，你都能顺着一条引用走回说出它的那个源头。