迭代检索模式
解决多智能体工作流中的“上下文问题”,即子智能体在开始工作前不知道需要哪些上下文。
何时激活
- 当需要生成需要代码库上下文但无法预先预测的子代理时
- 构建需要逐步完善上下文的多代理工作流时
- 在代理任务中遇到"上下文过大"或"缺少上下文"的失败时
- 为代码探索设计类似 RAG 的检索管道时
- 在代理编排中优化令牌使用时
问题
子智能体被生成时上下文有限。它们不知道:
- 哪些文件包含相关代码
- 代码库中存在哪些模式
- 项目使用什么术语
标准方法会失败:
- 发送所有内容:超出上下文限制
- 不发送任何内容:智能体缺乏关键信息
- 猜测所需内容:经常出错
解决方案:迭代检索
一个逐步优化上下文的 4 阶段循环:
阶段 1:调度
初始的广泛查询以收集候选文件:
阶段 2:评估
评估检索到的内容的相关性:
评分标准:
- 高 (0.8-1.0):直接实现目标功能
- 中 (0.5-0.7):包含相关模式或类型
- 低 (0.2-0.4):略微相关
- 无 (0-0.2):不相关,排除
阶段 3:优化
根据评估结果更新搜索条件:
阶段 4:循环
使用优化后的条件重复(最多 3 个周期):
实际示例
示例 1:错误修复上下文
示例 2:功能实现
与智能体集成
在智能体提示中使用:
最佳实践
- 先宽泛,后逐步细化 - 不要过度指定初始查询
- 学习代码库术语 - 第一轮循环通常能揭示命名约定
- 跟踪缺失内容 - 明确识别差距以驱动优化
- 在“足够好”时停止 - 3 个高相关性文件胜过 10 个中等相关性文件
- 自信地排除 - 低相关性文件不会变得相关
相关
- 长篇指南 - 子代理编排章节
continuous-learning技能 - 适用于随时间改进的模式- 与 ECC 捆绑的代理定义(手动安装路径:
agents/)


