夜雨聆风
章节关键词：Subagent、只读探索、代码库理解、Session 隔离、Task Tool
章节字数：8,000+
阅读时间：约 25 分钟
///
PART 01
开篇：你有没有被一个陌生项目「劝退」过？
周一早上，你被分配去优化一个没人维护的老项目。
你打开代码库——
500 个文件夹，2000 个文件，10 万行代码。没有文档，没有注释，上一个人已经离职两年。
你从头开始读文件。一个小时过去了，你只读完了 10 个文件，脑子里一团浆糊。
你开始怀疑人生：*这代码是谁写的？为什么要这样设计？这个文件是干什么用的？*
你花了整整两天，才勉强搞懂了这个项目 20% 的代码。
两天。20%。
如果是新项目呢？如果是遗留代码呢？如果没有文档呢？
这种情况，几乎每个工程师都遇到过。
而今天我要告诉你的是：有了 Explore Agent，你只需要 5 分钟，就能搞清楚一个 10 万行代码库的核心结构。
///
PART 02
6.1 什么是 Explore Agent？
6.1.1 第三个内置 Agent
在第 5 章中，我们介绍了 Plan Agent 和 Build Agent——它们是 OpenCode 的两个核心 Primary Agent，分别负责规划和执行。
但还有第三个内置 Agent，它专门解决一个你每天都会遇到的问题：
这就是 Explore Agent。
[Tab] Plan │ Build │ Explore
↑
第三个模式
6.1.2 Explore Agent 的定位
Explore Agent 是一个只读的代码探索工具。
当你切换到 Explore 模式时，AI 的能力被限制为：
✅ 读取所有文件
✅ 分析代码结构
✅ 生成探索报告
✅ 绘制架构图和依赖关系
❌ 不能修改任何代码
❌ 不能执行任何命令
这看起来和 Plan Agent 很像，但它们的目标不同：
| Agent | 目标 | 输出 |
|---|---|---|
| Plan Agent | 制定行动计划 | 任务清单、实现步骤、时间表 |
| Explore Agent | 理解代码结构 | 架构图、依赖关系、关键发现 |
Plan Agent 回答：「我们要做什么？」
Explore Agent 回答：「这个代码是怎么组织的？」
6.1.3 Tab 键切换到 Explore
[Tab] Plan │ Build │ Explore
↑
按 Tab 键切换
当你需要理解一个陌生项目时：
> [按 Tab 键，切换到 Explore 模式]
[Explore Agent 模式]
我已进入 Explore 模式。
这是一个只读探索模式，专门帮你理解陌生的代码库。
请告诉我你想探索什么？
///
PART 03
6.2 为什么「你自己读 20 个文件不如让 Explore Agent 读 1 次」？
6.2.1 人类的「阅读瓶颈」
当你手动阅读一个陌生代码库时，你会发现：
问题一：没有重点
你不知道该从哪个文件开始。所有的文件看起来都一样重要，或者一样不重要。你随机挑选文件开始读，结果读了半天发现读的是边缘模块。
问题二：记不住
你读了文件 A，记住了它依赖文件 B。读了文件 B，发现它又依赖文件 C 和 D。等你读完 C 和 D回来，文件 A 的细节已经忘了。
问题三：缺乏上下文
你读单个文件的代码，但没有整体架构的概念。你不知道这个文件在整个系统中处于什么位置，为什么存在，和谁交互。
问题四：效率低下
手动阅读速度：
- 快速浏览一个中等文件：5-10 分钟
- 深度理解一个复杂文件：30-60 分钟
- 理解一个完整模块（10个文件）：半天到一天
Explore Agent 阅读速度：
- 深度分析 100 个文件：5-10 分钟
- 生成完整架构报告：10-15 分钟
6.2.2 Explore Agent 的「并行阅读」能力
人类阅读是串行的，一次只能读一个文件。
但 Explore Agent 可以并行阅读整个代码库——它可以同时读取几十个甚至上百个文件，然后在几秒钟内综合出整体架构。
人类阅读：
文件1 → 文件2 → 文件3 → 文件4 → ... → 汇总（在脑子里）
↑
串行，还容易忘
Explore Agent 阅读：
[文件1] ─┐
[文件2] ─┤
[文件3] ─┼──→ 并行分析 → 架构报告
[文件4] ─┤
[...] ─┘
↑
同时进行，综合理解
6.2.3 一个真实的对比
我曾经需要理解一个 React Native 移动应用的核心架构。这个项目：
- 50+ 个页面组件
- 20+ 个核心服务
- 复杂的导航系统
- 状态管理库混用了 Redux 和 MobX
手动阅读：
- 我花了 6 个小时
- 读了大约 80 个文件
- 最后对整体架构只有模糊的认知
- 很多细节还是不理解
用 Explore Agent：
- 我花了 8 分钟
- 分析了 120+ 个文件
- 获得了一份完整的架构报告
- 包括依赖关系图、模块说明、数据流图
结论：
- 手动阅读：6 小时，获得模糊理解
- Explore Agent：8 分钟，获得清晰的全景图
///
PART 04
6.3 Subagent：让主 Agent 保持清醒的「外包大脑」
6.3.1 什么是 Subagent？
在理解 Explore Agent 之前，我们需要先理解一个核心概念：Subagent（子代理）。
Subagent 是 OpenCode 中的一种机制——它允许你在主会话中创建一个独立的 AI 工作进程，专门处理某个特定任务。
主会话
┌─────────────────────────┐
│ 主 Agent │
│ （规划、协调、汇总） │
│ ↓ 委托任务 │
│ ┌───────────────────┐ │
│ │ Subagent A │ │
│ │ （专门处理任务 A） │ │
│ └───────────────────┘ │
│ ↓ 返回结果 │
│ 主 Agent 汇总 │
└─────────────────────────┘
6.3.2 Subagent 的核心特性
特性一：Session 隔离
每个 Subagent 都在自己独立的 Session 中运行。
这意味着一件事：它不记得之前的任何对话。
这听起来像缺点，但实际上是巨大的优点——因为它不会被之前的对话污染，上下文始终干净。
主 Agent Session：
- 保留完整历史
- 知道所有上下文
- 负责规划和协调
Subagent Session：
- 无历史记忆
- 每次都是新开始
- 专注执行单一任务
特性二：有限上下文
Subagent 的上下文窗口比主 Agent 小得多。但这正是设计意图——
如果你的任务需要 50 次对话才能完成，那就不应该用 Subagent，而应该用主 Agent。
特性三：并行执行
你可以同时启动多个 Subagent，让它们并行工作。
想象一下你需要同时理解三个不同的模块：
串行方式（主 Agent）：
模块 A（5分钟）→ 模块 B（5分钟）→ 模块 C（5分钟）= 15分钟
并行方式（Subagent）：
模块 A（Subagent 1）──┐
模块 B（Subagent 2）──┼──→ 汇总 = 5分钟
模块 C（Subagent 3）──┘
6.3.3 Task Tool：创建 Subagent 的方式
在 OpenCode 中，创建 Subagent 的核心工具是 Task Tool。
Task Tool 的本质：
把一个任务描述交给 Subagent，让它在独立 Session 中执行
Task Tool 的限制：
- 每个主会话最多创建 50 个 Subagent
- 每个 Subagent 有独立的上下文限制
- Subagent 之间不能直接通信
6.3.4 为什么用 Subagent 做探索？
这是一个关键的认知转变：
❌ 传统方式（主 Agent 自己读文件）：
主 Agent 读 20 个文件
→ 这 20 个文件的内容进入主上下文
→ 上下文窗口被污染
→ 剩下的空间变少
→ AI 开始「失忆」
✅ 正确方式（Task Tool 外包探索）：
Task Tool 创建 Subagent
→ Subagent 读 20 个文件
→ Subagent 返回摘要（而不是原始内容）
→ 主上下文保持干净
→ 只保留了「结论」而不是「过程」
关键洞察：
如果你用主 Agent 读 20 个文件，你的上下文窗口会被这些文件的内容填满。但如果你用 Subagent 读 20 个文件，主上下文只收到 Subagent 返回的一页纸摘要。
///
PART 05
6.4 Explore Agent 实战：5分钟搞懂一个陌生项目
6.4.1 场景设定
你是新入职的工程师，被分配去维护一个「订单履约系统」。
这个系统：
- 3 年历史，2 万行代码
- 没有文档
- 核心开发者已离职
- 订单模块、库存模块、物流模块、支付模块交织在一起
你需要快速理解它的整体架构，然后才能开始工作。
6.4.2 第一步：进入 Explore 模式
> [按 Tab 键，切换到 Explore]
[Explore Agent 模式]
欢迎使用 Explore Agent！
这是一个只读探索模式，专门帮你理解陌生的代码库。
我无法修改任何代码，只会分析和报告。
请告诉我你想探索什么？
6.4.3 第二步：描述你的探索目标
> 帮我分析这个订单履约系统的整体架构。
我需要了解：
1. 系统的整体结构（有哪些核心模块）
2. 模块之间的依赖关系
3. 订单流程的数据流
4. 关键的业务逻辑在哪里
请把分析结果保存到 `.opencode/explore/order-fulfillment-report.md`
6.4.4 第三步：Explore Agent 开始分析
[Explore Agent 开始分析订单履约系统...]
第一步：扫描项目结构
✅ 发现核心目录：
- src/modules/order/ （订单模块）
- src/modules/inventory/ （库存模块）
- src/modules/logistics/ （物流模块）
- src/modules/payment/ （支付模块）
- src/services/ （公共服务）
- src/models/ （数据模型）
第二步：分析核心文件
✅ 分析了 45 个核心文件
- order.service.ts (820 行)
- inventory.service.ts (560 行)
- logistics.service.ts (490 行)
- payment.service.ts (380 行)
第三步：识别模块依赖
✅ 依赖关系图：
payment ──→ order
inventory ──→ order
logistics ──→ order
order ──→ models
第四步：追踪订单流程
✅ 订单流程数据流：
创建订单 → 库存预占 → 支付确认 → 物流分配 → 履约完成
↓ ↓ ↓ ↓
order inventory payment logistics
第五步：生成分析报告
✅ 报告已保存到 .opencode/explore/order-fulfillment-report.md
6.4.5 第四步：查看分析报告
# 订单履约系统架构分析报告
## 1. 系统概览
### 1.1 整体架构
┌─────────────────────────────────────────────┐
│ 订单履约系统 │
├─────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Payment │ │Inventory│ │Logistics│ │
│ │ 支付模块│ │ 库存模块 │ │ 物流模块 │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │
│ └────────────┼────────────┘ │
│ ↓ │
│ ┌───────────┐ │
│ │ Order │ │
│ │ 订单核心 │ │
│ └─────┬─────┘ │
│ ↓ │
│ ┌───────────┐ │
│ │ Models │ │
│ │ 数据模型层 │ │
│ └───────────┘ │
│ │
└─────────────────────────────────────────────┘
### 1.2 模块统计
| 模块 | 文件数 | 代码行数 | 复杂度 |
|------|--------|----------|--------|
| Order | 12 | 2,400 | 高 |
| Inventory | 8 | 1,800 | 中 |
| Logistics | 10 | 1,600 | 中 |
| Payment | 6 | 1,200 | 低 |
| Models | 15 | 900 | 低 |
## 2. 核心流程
### 2.1 订单履约流程（数据流）
用户下单
↓
[Order Service] 创建订单记录
↓
[Inventory Service] 预占库存（如果库存不足 → 拒绝）
↓
[Payment Service] 确认支付（如果支付失败 → 取消订单）
↓
[Logistics Service] 分配物流（生成运单）
↓
[Order Service] 更新订单状态为「已履约」
↓
通知用户（邮件/短信）
### 2.2 关键业务规则
**规则 1：库存预占机制**
- 下单时立即预占库存
- 支付超时 30 分钟后释放预占
- 退款时立即归还库存
**规则 2：支付超时处理**
- 订单创建后 15 分钟内必须完成支付
- 超时后订单自动取消
- 取消后预占库存立即释放
**规则 3：物流分配策略**
- 优先分配距离用户最近的仓库
- 如果仓库库存不足，触发跨仓调拨
- 调拨失败则订单降级处理
## 3. 模块依赖关系
### 3.1 依赖图
Order Service
├── 依赖 Inventory Service（检查/预占库存）
├── 依赖 Payment Service（确认支付状态）
├── 依赖 Logistics Service（分配物流）
└── 依赖 Models（数据模型）
Inventory Service
├── 依赖 Models
└── 依赖外部库存 API
Payment Service
├── 依赖第三方支付网关
└── 依赖 Models
Logistics Service
├── 依赖第三方物流 API
└── 依赖 Models
### 3.2 循环依赖检查
✅ 无循环依赖
## 4. 关键发现
### 4.1 架构优点
- 模块化清晰，职责划分明确
- 服务间通过接口通信，耦合度低
- 有完整的错误处理机制
### 4.2 潜在风险
⚠️ **高风险**：Inventory Service 和 Logistics Service 调用外部 API 无熔断机制
⚠️ **中风险**：订单状态机缺少「部分履约」状态
⚠️ **低风险**：缺少请求重试机制
### 4.3 优化建议
1. 添加 Resilience4j 熔断器
2. 扩展订单状态机
3. 实现重试机制（建议使用 Polly）
## 5. 快速上手指南
### 5.1 阅读顺序建议
1. 先读 `src/models/` 了解数据模型
2. 再读 `src/modules/order/` 理解核心逻辑
3. 最后读其他模块了解协作关系
### 5.2 关键文件清单
| 文件 | 说明 | 阅读优先级 |
|------|------|----------|
| `order.service.ts` | 订单核心逻辑 | ⭐⭐⭐ |
| `order.state-machine.ts` | 订单状态机 | ⭐⭐⭐ |
| `inventory.service.ts` | 库存服务 | ⭐⭐ |
| `logistics.service.ts` | 物流服务 | ⭐⭐ |
| `payment.service.ts` | 支付服务 | ⭐⭐ |
## 6. 后续探索建议
- [ ] 深入分析订单状态机（12 个状态，转换规则复杂）
- [ ] 分析外部 API 调用链路（库存/物流/支付）
- [ ] 审查错误处理和重试机制
- [ ] 补充单元测试覆盖
6.4.6 成果
你花了 8 分钟，获得了一份：
- 📊 系统架构图
- 🔄 核心数据流
- 📁 模块依赖关系
- ⚠️ 潜在风险清单
- 📋 快速上手指南
- ✅ 可执行的探索任务
这就是 Explore Agent 的价值——把「理解一个陌生项目」的时间从几天压缩到几分钟。
///
PART 06
6.5 Subagent 的 Session 隔离：无记忆的优势
6.5.1 什么是 Session 隔离？
每个 Subagent 运行在一个完全独立的 Session 中。
这意味着：
主 Agent Session：
第 1 天：「你好，我知道我们之前讨论过...」
第 2 天：「根据我们昨天的讨论...」
第 3 天：「记得你说要优化订单模块...」
Subagent Session：
第 1 天：「你好。」
第 2 天：「你好。」（完全不记得第 1 天）
第 3 天：「你好。」（完全不记得第 1、2 天）
6.5.2 为什么这反而是优势？
你可能会想：「完全不记得？那不是很糟糕吗？」
不，这恰恰是 Subagent 的设计优势。
优势一：不会被污染
主 Agent 的历史越长，越容易被之前的对话「污染」：
- 之前的错误假设
- 过时的上下文
- 不相关的讨论
Subagent 没有历史，所以不会有这些问题。
优势二：每次都是「最佳状态」
Subagent 每次启动都是从零开始，状态最干净。
优势三：可预测性
主 Agent 的行为可能受到历史影响，但 Subagent 的行为完全可预测——给定同样的输入，总是有同样的输出。
6.5.3 Subagent 的三大限制
限制一：无历史记忆
Subagent 不记得之前的对话，所以：
- 不能承接复杂的、多步骤的任务
- 不能理解「上下文」
- 每次都需要完整的信息输入
❌ 错误用法：
Subagent：「帮我继续上次没完成的工作」
（Subagent 不记得上次是什么）
✅ 正确用法：
Subagent：「帮我分析这个模块，输出架构报告到指定路径」
（任务明确，不需要历史）
限制二：有限上下文
Subagent 的上下文窗口比主 Agent 小，所以：
- 不能处理需要大量信息的任务
- 不能同时处理太多文件
- 任务必须足够小、足够明确
限制三：不能并行通信
Subagent 之间不能直接通信，必须通过主 Agent 中转。
Subagent A ← ✗ → Subagent B（不能直接通信）
↓
主 Agent（协调中转）
↓
Subagent C ← ✗ → Subagent D（不能直接通信）
///
PART 07
6.6 Task Tool：创建 Subagent 的核心机制
6.6.1 Task Tool 的本质
Task Tool 是 OpenCode 中用于创建 Subagent 的核心工具。
它的本质是：
Task Tool 工作流程：
1. 主 Agent 定义任务
「帮我分析这个模块的结构」
2. Task Tool 创建 Subagent
分配独立 Session，启动 AI
3. Subagent 执行任务
读取文件，分析代码
4. Subagent 返回结果
输出摘要或报告
5. 主 Agent 接收结果
继续处理或汇总
6.6.2 Task Tool 的使用模式
模式一：串行执行
一个接一个地执行任务：
Task 1（Subagent）→ 结果1
↓
Task 2（Subagent）→ 结果2
↓
Task 3（Subagent）→ 结果3
↓
主 Agent 汇总所有结果
适用场景：
- 任务之间有依赖关系
- 需要按顺序处理
- 结果需要汇总
模式二：并行执行
多个任务同时执行：
Task 1（Subagent A）──┐
Task 2（Subagent B）──┼──→ 主 Agent 汇总
Task 3（Subagent C）──┘
适用场景：
- 任务之间相互独立
- 可以同时处理
- 节省总时间
6.6.3 50 次调用限制的理解
每个主 Session 最多创建 50 个 Subagent。
这个限制的意义是：
❌ 错误用法：
for 100 times:
create Subagent「分析这一个文件」
（创建 100 个 Subagent → 超过限制）
✅ 正确用法：
create Subagent「分析这 100 个文件」
（创建 1 个 Subagent → 正常工作）
6.6.4 什么时候用 Subagent？
根据技术底稿的推荐：
任务类型 → 推荐处理方式
─────────────────────────────────────────
探索/搜索代码库 → Subagent（Haiku 模型）
简单单文件编辑 → Subagent（Haiku 模型）
多文件复杂实现 → 主 Agent（Sonnet 模型）
复杂架构设计 → 主 Agent（Opus 模型）
Bug 调试 → 主 Agent（Opus 模型）
PR 审查 → 主 Agent（Sonnet 模型）
安全分析 → 主 Agent（Opus 模型）
核心原则：
- 探索用 Subagent：把「读文件」的工作外包，结果以摘要形式返回
- 实现用主 Agent：「写代码」需要完整上下文，必须用主 Agent
///
PART 08
6.7 Explore vs General：什么时候用哪个？
6.7.1 两种模式的区别
OpenCode 有两种主要的探索模式：
| 维度 | Explore Agent | General Agent |
|---|---|---|
| 定位 | 专门用于代码探索 | 通用任务执行 |
| 能力 | 只读分析 | 可读可写 |
| 输出 | 架构报告、依赖图 | 任意任务结果 |
| 上下文 | 专注探索 | 任意上下文 |
| 风险 | 无破坏风险 | 有误改风险 |
6.7.2 选择流程图
任务开始
↓
是代码探索任务吗？
↓ 否
General Agent（通用执行）
↓
是
需要生成架构报告吗？
↓ 否
Subagent + Task Tool（直接探索）
↓ 是
Explore Agent（专门探索模式）
6.7.3 实际场景选择
场景 1：接手新项目，需要快速了解架构
选择：Explore Agent
原因：
- 需要生成完整的架构报告
- 需要依赖关系图
- Explore Agent 专门优化了这个场景
场景 2：需要修改某个模块，但不确定在哪里
选择：Subagent + Task Tool
原因：
- 不需要完整报告，只需要定位文件
- Subagent 更轻量
- 可以并行快速搜索
场景 3：需要边探索边修改
选择：General Agent
原因：
- 探索和修改交替进行
- 需要保持上下文连续性
- Subagent 不适合这种模式
场景 4：需要审查代码质量
选择：General Agent + code-reviewer Skill
原因：
- 需要深入分析代码质量
- 需要提出改进建议
- 可能需要修改示例代码
///
PART 09
6.8 实际演示：用 Explore Agent 分析 10 万行代码库
6.8.1 项目背景
假设你接手了一个大型电商后端系统，有以下特点：
- 50+ 个微服务
- 10 万行代码
- 分布在 200+ 个文件中
- 使用微服务架构
6.8.2 第一次探索：了解整体架构
> 帮我分析这个电商后端系统的整体架构。
请输出：
1. 系统由哪些服务组成
2. 服务之间的依赖关系
3. 核心的数据模型
4. API 网关的位置
输出到：.opencode/explore/ecommerce-architecture.md
结果：
# 电商后端系统架构分析
## 1. 系统组成
### 1.1 核心服务（8个）
| 服务 | 功能 | 代码行数 |
|------|------|----------|
| api-gateway | API 网关 | 1,200 |
| user-service | 用户服务 | 3,400 |
| product-service | 商品服务 | 4,100 |
| order-service | 订单服务 | 5,200 |
| payment-service | 支付服务 | 2,800 |
| inventory-service | 库存服务 | 3,600 |
| logistics-service | 物流服务 | 2,900 |
| notification-service | 通知服务 | 1,800 |
### 1.2 架构图
[详细架构图...]
6.8.3 第二次探索：深入订单模块
> 帮我深入分析订单模块（order-service）。
我需要了解：
1. 订单的状态机设计
2. 订单创建的完整流程
3. 与其他服务的交互方式
4. 关键的业务逻辑
输出到：.opencode/explore/order-service-deep-dive.md
6.8.4 第三次探索：性能优化分析
> 帮我分析这个系统的潜在性能瓶颈。
重点关注：
1. 数据库查询（是否有 N+1 问题）
2. 缓存使用情况
3. 同步/异步处理
4. 连接池配置
输出到：.opencode/explore/performance-analysis.md
6.8.5 最终成果
经过 3 次探索（共计约 25 分钟），你获得了：
- 📊 完整的系统架构图
- 🔄 核心模块的数据流
- 📁 10 万行代码的目录结构
- ⚠️ 10+ 个潜在风险点
- 💡 20+ 个优化建议
- 📋 详细的快速上手指南
如果手动完成这些工作，你可能需要 1-2 周。
///
PART 10
6.9 常见问题与解决方案
Q1：Explore Agent 的分析结果不够深入怎么办？
A：分多次探索，先整体后局部。
第一次：探索整体架构
> 帮我分析这个系统的整体架构
第二次：深入特定模块
> 基于刚才的分析，深入分析订单模块的细节
第三次：追踪特定流程
> 帮我追踪一个订单从创建到完成的完整数据流
Q2：Subagent 返回的结果太简略怎么办？
A：在任务描述中明确要求详细的输出格式。
❌ 模糊任务：
> 帮我分析这个模块
✅ 明确任务：
> 帮我分析这个模块，输出包含：
> 1. 模块结构（列出所有文件）
> 2. 每个文件的用途说明
> 3. 关键函数列表（名称、参数、返回值）
> 4. 依赖关系图
> 5. 建议的阅读顺序
Q3：应该先用 Explore Agent 还是直接问主 Agent？
A：根据任务大小决定。
小任务（5分钟内能解决）：
→ 直接问主 Agent
大任务（需要理解多个模块）：
→ 先用 Explore Agent
→ 再用主 Agent 执行
Q4：Explore Agent 会改变我的代码吗？
A：不会。Explore Agent 是只读模式，不能执行任何写操作。
Explore Agent 的能力边界：
✅ 读取文件
✅ 分析代码
✅ 生成报告
❌ 修改文件
❌ 执行命令
❌ 创建文件
///
PART 11
6.10 本章小结
核心知识点
| 知识点 | 关键内容 |
|---|---|
| Explore Agent | 第三个内置 Agent，专门用于代码探索 |
| Subagent | 独立 Session 的 AI 进程，无历史记忆 |
| Session 隔离 | Subagent 的核心特性，保证上下文干净 |
| Task Tool | 创建 Subagent 的核心机制 |
| 并行探索 | 用多个 Subagent 同时分析不同模块 |
关键术语
| 术语 | 定义 |
|---|---|
| Explore Agent | OpenCode 第三个内置 Agent，只读探索模式 |
| Subagent | 主 Agent 派生的独立执行进程，有限上下文 |
| Session 隔离 | Subagent 无历史记忆，每次都是新开始 |
| Task Tool | 创建 Subagent 的核心工具 |
| 并行探索 | 用多个 Subagent 同时工作以节省时间 |
Explore vs 其他模式
| 场景 | 推荐模式 |
|---|---|
| 快速理解陌生项目 | Explore Agent |
| 定位某个文件/函数 | Subagent + Task Tool |
| 边探索边修改 | General Agent |
| 代码审查 | General Agent + Skill |
行动建议
- 立即行动（5 分钟）：体验一次 Explore Agent：
- 打开一个陌生的代码库
- 用 Explore Agent 生成架构报告
- 下一步（10 分钟）：体验 Subagent 并行探索：
- 同时启动 3 个 Subagent
- 分别探索 3 个不同的模块
- 汇总结果
- 持续优化：为你的团队创建「探索模板」
- 标准化的探索报告格式
- 关键文件清单模板
- 快速上手指南模板
///
PART 12
下章预告
*第 7 章：Subagent 军团——一人公司的「AI 雇佣兵团队」*
///
*本章完。
THANKS FOR READING
🦐 龙虾 · OpenClaw 技术分享
