迭代检索模式 是做什么的？
解决多代理工作流中的“上下文问题”——子代理需要先工作才知道需要什么上下文。
何时激活
- 分发子代理时，子代理需要无法预知的代码库上下文
- 构建需要逐步精炼上下文的多代理工作流
- 遇到代理任务中的“上下文过大”或“缺失上下文”错误
- 为代码探索设计类似 RAG 的检索管道
- 优化代理编排中的 Token 使用
问题
子代理被分发时只有有限的上下文。它们不知道：
- 哪些文件包含相关代码
- 代码库中存在哪些模式
- 项目使用了什么术语
标准方法均会失败：
- 发送所有内容：超出上下文限制
- 不发送任何内容：代理缺少关键信息
- 猜测所需内容：通常错误
解法：迭代检索
一个四阶段循环，逐步精炼上下文：
┌─────────────────────────────────────────────┐
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 分发 │─────│ 评估 │ │
│ └──────────┘ └──────────┘ │
│ ▲ │ │
│ │ ▼ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 循环 │─────│ 精炼 │ │
│ └──────────┘ └──────────┘ │
│ │
│ 最多 3 个周期，然后继续 │
└─────────────────────────────────────────────┘
阶段 1：分发
初始的广泛查询，收集候选文件：
// 从高层意图开始
const initialQuery = {
patterns: ['src/**/*.ts', 'lib/**/*.ts'],
keywords: ['authentication', 'user', 'session'],
excludes: ['*.test.ts', '*.spec.ts']
};
// 分发到检索代理
const candidates = await retrieveFiles(initialQuery);
阶段 2：评估
评估检索到的内容的相关性：
function evaluateRelevance(files, task) {
return files.map(file => ({
path: file.path,
relevance: scoreRelevance(file.content, task),
reason: explainRelevance(file.content, task),
missingContext: identifyGaps(file.content, task)
}));
}
评分标准：
- 高 (0.8-1.0)：直接实现目标功能
- 中 (0.5-0.7)：包含相关模式或类型
- 低 (0.2-0.4)：间接相关
- 无 (0-0.2)：不相关，排除
阶段 3：精炼
基于评估更新搜索标准：
function refineQuery(evaluation, previousQuery) {
return {
// 添加在高相关性文件中发现的新模式
patterns: [...previousQuery.patterns, ...extractPatterns(evaluation)],
// 添加在代码库中找到的术语
keywords: [...previousQuery.keywords, ...extractKeywords(evaluation)],
// 排除已确认不相关的路径
excludes: [...previousQuery.excludes, ...evaluation
.filter(e => e.relevance < 0.2)
.map(e => e.path)
],
// 聚焦特定缺失内容
focusAreas: evaluation
.flatMap(e => e.missingContext)
.filter(unique)
};
}
阶段 4：循环
使用精炼后的标准重复（最多 3 个周期）：
async function iterativeRetrieve(task, maxCycles = 3) {
let query = createInitialQuery(task);
let bestContext = [];
for (let cycle = 0; cycle < maxCycles; cycle++) {
const candidates = await retrieveFiles(query);
const evaluation = evaluateRelevance(candidates, task);
// 检查是否已有足够的上下文
const highRelevance = evaluation.filter(e => e.relevance >= 0.7);
if (highRelevance.length >= 3 && !hasCriticalGaps(evaluation)) {
return highRelevance;
}
// 精炼并继续
query = refineQuery(evaluation, query);
bestContext = mergeContext(bestContext, highRelevance);
}
return bestContext;
}
实际示例
示例 1：故障修复上下文
任务：“修复认证令牌过期错误”
周期 1：
分发：在 src/** 中搜索 "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)
精炼：上下文足够（2 个高相关性文件）
结果：auth.ts, tokens.ts, session-manager.ts, jwt-utils.ts
示例 2：功能实现
任务：“为 API 端点添加速率限制”
周期 1：
分发：在 routes/** 中搜索 "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
与代理集成
在代理提示中使用：
当为此任务检索上下文时：
1. 从广泛的关键词搜索开始
2. 评估每个文件的相关性（0-1 分）
3. 识别仍缺失哪些上下文
4. 精炼搜索标准并重复（最多 3 个周期）
5. 返回相关性 >= 0.7 的文件
最佳实践
- 先广泛，逐步缩小 — 不要过度指定初始查询
- 学习代码库术语 — 第一个周期常常揭示命名约定
- 追踪缺失内容 — 明确的差距识别驱动精炼
- 在“足够好”时停止 — 3 个高相关性文件胜过 10 个普通文件
- 自信地排除 — 低相关性文件不会变得相关
相关
- 长篇指南 — 子代理编排部分
continuous-learning技能 — 用于随时间改进的模式- 与 ECC 一起提供的代理定义（手动安装路径：
agents/）