探索了 120 个文件，只用了 12% 上下文

在主会话中读文件会累积上下文。读 45 个文件消耗 75% 的上下文窗口。读 30+ 个日志文件导致分析降级——早期发现被压缩或丢失，agent 重复浅层结论，条目之间的关联被遗漏。

Explore 子代理在隔离的上下文中运行。它按需读取大量文件做发现，然后只返回结构化摘要到主会话。主会话的上下文保持干净，留给实现。

数字

子代理探索了 2.7 倍文件，多发现了 37% 的依赖，留下了 3.5 倍的上下文给实现阶段。在大规模探索上它严格更优。

上下文耗尽怎么表现

当 CI agent 在主会话中直接读 30+ 个日志文件时，质量在调查中途就降级了：

• 分析变得浅层和重复
• 早期发现被忽略或矛盾
• 条目之间的关联被遗漏
• Agent 重复结论而不是在之前分析上深入

这不是能力限制。是上下文窗口耗尽。随着文件累积，早期对话内容——包括关键分析——被压缩或截断。Agent 确实失去了对自己之前工作的访问。

修复不是更短的 Read 范围（仍然会累积）、不是 /clear（毁掉已完成的工作）、也不是 Plan 模式（不压缩上下文）。修复是 Explore 子代理把冗长的阅读保持在隔离上下文中。

混合策略

对一个需要架构理解和具体实现细节的 2,000 文件代码库：

1. Explore 子代理 — 广泛的架构发现。遍历代码库，映射模块边界，识别关键依赖。返回结构化摘要。
2. 读具体关键文件 — 在主会话中，只读子代理识别为实现关键的文件。定向读取，不是批量探索。

子代理处理广度（2,000 文件的架构）。主会话处理深度（关键文件的详细实现模式）。上下文预算支持两者。

会话中途救援

如果探索已经消耗了 40% 的主上下文还有 8 个服务要追踪：

• 不要继续在主会话中读——剩余探索会把上下文推过 80%。
• 不要 /clear——这毁掉了已收集的 40% 发现。
• 要把剩余探索委派给 Explore 子代理。子代理在隔离中追踪剩余 8 个服务并返回摘要。主会话保留了早期发现和新摘要。

不存在的东西

• Plan 模式自动压缩 — Plan 模式是只读探索模式。它不压缩文件内容、不释放上下文空间、不管理容量。Plan 模式中读取的所有内容仍然消耗上下文窗口。
• Read 的批处理丢弃 — Claude 不会在处理后自动丢弃文件内容。每个文件读取都累积在上下文中。
• 按需上下文压缩 — Claude 不能通过用户指令的摘要命令压缩自己的上下文。上下文压缩在接近限制时在系统层面自动发生。
• 无限 fork 上下文 — 带 context: fork 的 skills 有和主会话相同的上下文窗口限制。Fork 提供隔离，不是扩展容量。
• Temperature 漂移 — Temperature 在会话期间不变。保持恒定。

什么时候不用 Explore 子代理

对于小规模探索（几个文件、已知位置），Explore 子代理增加不必要的间接层。如果你知道要读哪 3 个文件，直接在主会话中读它们更快且提供实现需要的完整细节。

子代理是给会消耗大量上下文的探索——通常 30+ 文件跨多个模块。对已知文件的定向读取，直接 Read 更高效。

一句话总结： Explore 子代理在隔离上下文中读几百个文件并只返回摘要——为真正需要上下文的工作保留 88% 的主会话。