research

研究

使用此技能，通过委派子 Agent 来完成查找答案的工作，从而避免文件内容、日志噪声和无关阅读等副产品进入你的上下文。你会收到经过提炼的答案及其依据，从而能专注于真正的任务。

为什么这很重要

你的上下文窗口是最宝贵、也最有限的资源。阅读 20 个文件，最后发现只有 3 个有用，这会让另外 17 个文件的噪声永久占据上下文，影响你之后的每个决策。子 Agent 会替你吸收这些噪声，只把有用信息交给你。你可以把这想成请同事翻阅档案并汇报，而不是把整份档案堆在你的桌上。

何时使用

当产出答案的成本远高于答案本身时，可以考虑委派研究。明显的信号包括：

• 你需要阅读许多文件，才能找出少数相关内容。
• 你需要在冗长的测试输出、CI 日志或堆栈跟踪中梳理并提取故障信息。
• 你需要调查某种模式、API 或符号在整个代码库中的用法。
• 你需要阅读并总结大型差异或 PR。
• 问题包含多个可独立调查的子部分。

适合委派的示例：

• “这个测试失败的根本原因是什么？”（子 Agent 阅读日志并追踪代码；你获得原因）
• “SessionManager 在整个代码库中如何使用？”（子 Agent 搜索并阅读；你获得摘要和调用位置）
• “总结这个 4,000 行 PR 改了什么，以及为什么要改。”（子 Agent 阅读差异；你了解整体情况）

不适合委派的示例：

• 阅读你已经知道要看的 2–3 个文件。直接阅读即可；委派只会增加延迟，不会节省上下文。
• 单次 grep 或一行查询。自己完成即可。
• 任何需要原始材料来开展下一步工作的情况。 如果你准备编辑自己要读取的文件，委派会适得其反——你之后还得亲自重读这些文件才能修改。研究委派适用于输出是结论的情况，而不是你要直接处理的材料。

使用子 Agent 确实有成本（延迟和 Token），所以判断标准始终是：避免的噪声是否值得付出这项成本？

如何使用

在本地启动搜索模型

研究子 Agent 必须始终作为本地 Agent 启动，不能使用远程 Agent——即使父级是工厂 Agent 或云端 Agent，也不例外。

根据搜索任务选择模型，而不是使用你自己的模型。研究子 Agent 应负责搜索和提炼，而不是分析：简单搜索使用 gpt-6-luna-medium，更复杂的请求（例如追踪多个调用位置之间的数据流）使用 gpt-6-luna-xhigh。

单个还是并行

默认启动一个子 Agent。只有当问题确实可以拆分为彼此独立、且无需共享中间发现的子部分时，才并行启动多个子 Agent——例如“认证如何运作、计费如何运作，以及速率限制器如何运作”就是三个可以同时调查的独立问题。问题各部分真正独立时，并行处理很有价值；但不要为了并行而人为拆分一个连贯的问题。

清楚地说明任务

子 Agent 不会了解你的意图，因此要明确说明。完善的研究任务说明应包含：

• 需要回答的确切问题。
• 要查看的位置（仓库路径、分支，以及已知的可疑文件或符号）。
• 明确说明任务是只读的——子 Agent 应调查并汇报；除非任务明确要求，否则不要修改文件。
• 希望它返回的内容（见下文）。

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

告诉子 Agent 返回提炼后的答案及其支持证据，而不是原始信息倾倒。具体来说：

1. 问题的直接答案。
2. 关键证据：准确的文件路径和符号（例如 src/session.rs:142、fn reconnect），这样你就能直接找到重点。
3. 遇到的任何意外情况、注意事项或未知之处。

这样做的全部意义，就是让子 Agent 处理噪声。如果返回的报告过于冗长，就向同一个子 Agent 发送有针对性的追问，请它精简答案——它会保留上下文，因此能以较低成本进一步完善答案。

获取答案后

根据提炼后的结果继续工作。如果之后发现需要底层文件才能进行编辑，就在那时直接读取它们——现在你已经清楚哪些文件重要，只需读取三个文件，而不是二十个。