将嘈杂的调查委托给一个或多个子代理，使编排器的上下文保持干净，然后基于提炼后的答案进行工作。当回答一个问题需要读取大量文件、长日志、大型差异或广泛的代码库调查时——即产生答案的过程比答案本身产生更多噪音时——使用此技能。适用于“X如何工作”、“Y在哪里使用”、“Z的根本原因是什么”、“总结这个PR/日志”这类问题，在直接内联读取一堆文件之前，请放心使用。
研究
使用此技能来回答问题，将寻找答案的工作委托给子代理，这样工作的副产品——文件内容、日志噪音、死胡同的读取——永远不会进入你自己的上下文。你得到的是提炼后的答案以及支持它的证据，并且你保持敏锐以处理实际任务。
为什么这很重要
你的上下文窗口是你最宝贵且有限的资源。读取二十个文件后发现其中三个是相关的，这永久性地用十七个文件的噪音污染了你的上下文，降低了你后续每个决策的质量。子代理为你吸收这些噪音，只把信号交给你。可以把它想象成请同事翻阅档案并汇报，而不是把整个档案堆在你的桌子上。
何时使用
当产生答案的成本远大于答案本身时，请考虑使用研究委托。强烈信号：
- 你需要读取许多文件才能找到少数相关的文件。
- 你需要费力阅读冗长的测试输出、CI日志或堆栈跟踪来提取失败信息。
- 你需要调查某个模式、API或符号在整个仓库中的使用情况。
- 你需要阅读并总结一个大型差异或PR。
- 问题有多个独立的子部分，可以分别调查。
示例——适合的情况：
- “这个失败测试的根本原因是什么？”（子代理读取日志并追踪代码；你得到原因）
- “
SessionManager在整个代码库中如何使用？”（子代理进行grep并读取；你得到带有调用点的摘要） - “总结这个4000行PR更改了什么以及为什么。”（子代理读取差异；你得到其概况）
示例——不要委托：
- 读取你已经知道需要的2-3个文件。直接读取它们；委托会增加延迟而没有上下文节省。
- 单个
grep或单行查找。自己完成。 - 任何你需要原始材料进行下一步操作的情况。 如果你即将编辑你要读取的文件，委托是适得其反的——你之后还得自己重新读取这些文件来进行更改。研究委托在输出是结论时才有回报，而不是当它是你将直接处理的材料时。
子代理的成本是真实的（延迟和令牌），所以测试标准始终是：我避免的噪音是否超过了这个成本？
如何操作
单个与并行
默认使用单个子代理。仅当问题确实可以分解为独立的子部分，且这些部分不需要共享中间发现时，才并行生成多个子代理——例如，“认证如何工作”和“计费如何工作”和“速率限制器如何工作”是三个独立的调查，可以同时进行。当各部分真正独立时，并行性是一项值得使用的能力，因为不同的子代理可以同时调查；但不要将单个连贯的问题强行分割成人为的碎片。
给子代理提供良好的简报
子代理不共享你的意图，所以要明确说明。一个好的研究简报包括：
- 要回答的确切问题。
- 查找位置（仓库路径、分支、怀疑的文件/符号，如果你知道的话）。
- 它是只读的——它应该调查并报告，而不是修改文件，除非任务明确要求更改。
- 你希望返回的输出（见下文）。
要求信号，而不是记录
告诉子代理返回提炼后的答案及其支持证据，而不是原始转储。具体来说：
- 问题的直接答案。
- 关键证据：确切的文件路径和符号（例如
src/session.rs:142、fn reconnect），这样你可以直接跳转到重要的内容。 - 任何令人惊讶的事情或它遇到的任何注意事项/未知项。
关键在于噪音留在子代理那里。如果报告返回时过于臃肿，向同一个子代理发送一个集中的后续请求，要求它精简答案——它保留其上下文，可以低成本地优化。
得到答案后
基于提炼的结果进行工作。如果后来发现需要底层文件来进行编辑，那时直接读取它们——现在你确切知道哪些文件重要，所以你读取三个文件而不是二十个。
