research

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Research

研究

Use this skill to answer a question by delegating the work of finding the answer to a subagent, so that the byproducts of that work — file contents, log noise, dead-end reads — never enter your own context. You get back a distilled answer plus the evidence that supports it, and you stay sharp for the actual task.

使用此技能时，可将“寻找答案的工作”委托给subagent，从而让该工作产生的副产品——文件内容、日志噪音、无意义的读取记录——永远不会进入你自己的上下文。你会收到一份提炼后的答案及支撑证据，同时能专注于实际任务。

Why this matters

为什么这很重要

Your context window is your most valuable and limited resource. Reading twenty files to discover that three of them mattered permanently pollutes your context with seventeen files of noise, degrading every subsequent decision you make. A subagent absorbs that noise on your behalf and hands you only the signal. Think of it as asking a colleague to dig through the archives and report back, rather than dumping the whole archive on your desk.

你的上下文窗口是最宝贵且有限的资源。为了找到3个相关文件而读取20个文件，会让你的上下文被17个无关文件的噪音永久污染，进而影响后续所有决策。subagent会替你吸收这些噪音，只传递关键信息。这就好比让同事帮忙查阅档案并汇报结果，而非把整份档案直接堆在你桌上。

When to use it

使用场景

Reach for research delegation when the cost of producing the answer is far greater than the answer itself. Strong signals:

You'd need to read many files to find the few that are relevant.
You'd need to wade through long test output, CI logs, or stack traces to extract a failure.
You'd need to survey how a pattern, API, or symbol is used across the whole repo.
You'd need to read and summarize a large diff or PR.
The question has several independent sub-parts that could be investigated separately.

Examples — good fits:

"What's the root cause of this failing test?" (the subagent reads the logs and traces the code; you get the cause)
"How is
```
SessionManager
```
used across the codebase?" (the subagent greps and reads; you get a summary with call sites)
"Summarize what this 4,000-line PR changes and why." (the subagent reads the diff; you get the shape of it)

Examples — do NOT delegate:

Reading 2–3 files you already know you need. Just read them directly; delegation adds latency for no context savings.
A single
```
grep
```
or one-line lookup. Do it yourself.
Anything where you need the raw material for your next step. If you're about to edit the files you'd be reading, delegating is counterproductive — you'd just have to re-read them yourself to make the change. Research delegation pays off when the output is a conclusion, not when it's material you'll work on directly.

The cost of a subagent is real (latency and tokens), so the test is always: does the noise I'd avoid outweigh that cost?

当生成答案的成本远高于答案本身时，请选择委托研究工作。典型信号包括：

需要读取大量文件才能找到少数相关文件。
需要在冗长的测试输出、CI logs或stack traces中筛选故障信息。
需要调研某个模式、API或符号在整个repo中的使用情况。
需要读取并总结大型diff或PR。
问题包含多个可独立调查的子部分。

适用示例：

“这个测试失败的根本原因是什么？”（subagent读取日志并追踪代码，你得到故障原因）
```
SessionManager
```
在代码库中的使用方式是怎样的？”（subagent执行grep并读取相关内容，你得到包含调用位置的总结）
“总结这个4000行的PR做了哪些改动及原因。”（subagent读取diff，你得到改动概况）

不适用示例：

读取2-3个你已知需要的文件。直接读取即可；委托只会增加延迟，无法节省上下文空间。
单次
```
grep
```
或单行查询。自行操作即可。
任何需要将原始材料用于下一步工作的场景。如果你接下来要编辑即将读取的文件，委托反而适得其反——你最终还是得自己重新读取这些文件来修改。只有当输出是“结论”而非“你将直接处理的材料”时，委托研究工作才会带来价值。

启动subagent确实存在成本（延迟和token消耗），因此判断标准始终是：避免的噪音是否超过这些成本？

How to do it

操作方法

Single vs. parallel

单代理 vs 并行代理

Default to a single subagent. Spawn multiple subagents in parallel only when the question genuinely decomposes into independent sub-parts that don't need to share intermediate findings — for example, "how does auth work AND how does billing work AND how does the rate limiter work" are three independent investigations that can run at once. Parallelism is a capability worth using when the parts are truly independent, since separate subagents can investigate simultaneously; but don't force a single coherent question into artificial fragments.

默认使用单个subagent。仅当问题能真正分解为无需共享中间结果的独立子部分时，才并行启动多个subagent——例如，“认证机制如何工作、计费系统如何工作、速率限制器如何工作”这三个独立调查可同时进行。当各部分确实独立时，并行能力值得利用，因为不同的subagent可同时开展调查；但不要将一个连贯的问题强行拆分为人工片段。

Brief the subagent well

清晰告知subagent任务

The subagent does not share your intent, so spell it out. A good research brief includes:

The exact question to answer.
Where to look (repo path, branch, suspected files/symbols if you know them).
That it is read-only — it should investigate and report, not modify files, unless the task explicitly calls for changes.
The output you want back (see below).

subagent无法感知你的意图，因此需要明确说明。一份优质的研究任务说明应包含：

需回答的具体问题。
调查范围（repo路径、分支、已知的疑似文件/符号）。
明确只读操作——除非任务明确要求修改，否则subagent仅需调查并汇报，不得修改文件。
期望的输出形式（见下文）。

Ask for signal, not transcript

要求关键信息，而非原始记录

Tell the subagent to return a distilled answer plus its supporting evidence, not a raw dump. Specifically:

The direct answer to the question.
The key evidence: exact file paths and symbols (e.g.
```
src/session.rs:142
```
,
```
fn reconnect
```
), so you can jump straight to what matters.
Anything surprising or any caveats/unknowns it hit.

The whole point is that the noise stays with the subagent. If a report comes back bloated, send a focused follow-up to the same subagent asking it to tighten the answer — it retains its context and can refine cheaply.

告知subagent返回提炼后的答案及支撑证据，而非原始内容的堆砌。具体应包含：

问题的直接答案。
关键证据：精确的文件路径和符号（例如
```
src/session.rs:142
```
、
```
fn reconnect
```
），以便你直接跳转至关键内容。
任何意外发现或遇到的警告/未知情况。

核心目标是让噪音留在subagent端。如果返回的报告过于冗长，可向同一个subagent发送针对性的跟进请求，要求其精简答案——它会保留上下文，能低成本地优化结果。

After you get the answer

获取答案后

Work from the distilled result. If you later find you need the underlying files to make edits, read them directly at that point — now you know exactly which ones matter, so you read three files instead of twenty.

基于提炼后的结果开展工作。如果后续发现需要读取原始文件进行编辑，此时再直接读取即可——你已明确知道哪些文件是关键，因此只需读取3个而非20个文件。