用途
迭代检索模式用于解决多智能体工作流中的“上下文问题”：子智能体在被派发时上下文有限，无法预知哪些文件包含相关代码、代码库中存在哪些模式、项目使用什么术语。标准做法往往失败——发送全部内容会超出上下文限制，什么都不发则缺少关键信息，凭猜测又常常出错。该模式通过渐进式精炼上下文来应对这一问题。
何时启用
- 派发需要代码库上下文、但无法预先预测所需内容的子智能体时
- 构建上下文逐步精炼的多智能体工作流时
- 在智能体任务中遇到“上下文过大”或“缺少上下文”失败时
- 为代码探索设计类 RAG 的检索管线时
- 优化智能体编排中的 token 使用量时
主要能力：四阶段循环
该模式是一个四阶段循环，最多执行 3 个周期后继续推进。
阶段 1：DISPATCH（派发） 以初始的宽泛查询收集候选文件。从高层意图出发，定义模式（patterns）、关键词（keywords）与排除项（excludes），然后派发给检索智能体获取候选文件。
阶段 2：EVALUATE（评估） 评估检索内容与任务的相关性，为每个文件给出相关性评分、理由与缺失上下文。评分标准：高（0.8–1.0）直接实现目标功能；中（0.5–0.7）包含相关模式或类型；低（0.2–0.4）仅间接相关；无（0–0.2）不相关，予以排除。
阶段 3：REFINE（精炼） 根据评估结果更新检索条件：加入在高相关文件中发现的新模式，加入在代码库中发现的术语，排除已确认无关的路径，并针对具体缺口设定聚焦区域。
阶段 4：LOOP（循环） 使用精炼后的条件重复执行（最多 3 个周期）。当高相关文件数量足够且不存在关键缺口时返回结果；否则继续精炼并合并上下文。
使用方式
在智能体提示词中可按如下步骤使用：
- 从宽泛的关键词搜索开始
- 评估每个文件的相关性（0–1 分）
- 识别仍然缺失的上下文
- 精炼检索条件并重复（最多 3 个周期）
- 返回相关性 >= 0.7 的文件
适用场景示例
示例 1：缺陷修复上下文 任务：“修复认证令牌过期缺陷”。周期 1 搜索 token、auth、expiry，评估得到 auth.ts（0.9）、tokens.ts（0.8）、user.ts（0.3），精炼时加入 refresh、jwt 关键词并排除 user.ts；周期 2 找到 session-manager.ts（0.95）、jwt-utils.ts（0.85），上下文已足够。结果为 auth.ts、tokens.ts、session-manager.ts、jwt-utils.ts。
示例 2：功能实现 任务：“为 API 端点添加速率限制”。周期 1 搜索 rate、limit、api 无匹配，发现代码库使用 throttle 术语，精炼加入 throttle、middleware；周期 2 找到 throttle.ts（0.9）、middleware/index.ts（0.7），仍需路由模式；周期 3 搜索 router、express 模式，找到 router-setup.ts（0.8），上下文足够。结果为 throttle.ts、middleware/index.ts、router-setup.ts。
最佳实践
- 先宽后窄，逐步收窄——不要过度限定初始查询
- 学习代码库术语——第一个周期常能揭示命名约定
- 追踪缺失内容——显式的缺口识别驱动精炼
- 在“足够好”时停止——3 个高相关文件胜过 10 个平庸文件
- 果断排除——低相关文件不会变得相关
限制
资料未提供该模式的具体性能指标、支持的平台或工具依赖、安装与配置细节，以及收费或价格信息。相关内容包括《The Longform Guide》的子智能体编排章节、continuous-learning 技能，以及随 ECC 打包的智能体定义（手动安装路径：agents/）。