INSIGHT多轮检索最关键的不是“再搜一次”，而是把“还缺什么”和“何时停止”变成可审计的结构化状态。对社区复杂 query，可将帖子级证据压缩为句子级记忆，并把缺口直接映射成下一轮召回条件；这一轻量控制器无需更换搜索引擎或重训生成器，适合先在现有 RAG 链路旁路试验。

INSIGHTAgentic Retrieval 的工程价值来自成本感知的逐级升级，而不是默认让 Agent 无限搜索。社区搜索可把 BM25/向量召回、重排、全文读取和子 Agent 总结设计为分层动作，并以证据覆盖、剩余预算和边际增益决定升级；这能避免长上下文“稀释”关键信息，同时保留可追溯证据链。

INSIGHT端到端补丁成功率会掩盖检索失败，Agent 评测应单独记录首次命中步骤、文件级召回、上下文预算与无答案校准。对搜索 Agent 同理：除了最终回答，还应测证据首次出现轮次、每轮新增有效证据和错误库/错误域拒答；“更大的 embedding”也无法统一赢下所有任务，路由策略必须按任务类型选择。

INSIGHTDeep Research 的质量门控应沿证据图逐层验收，不能只用一个 LLM Judge 打最终报告分。社区搜索可把每条结论绑定到帖子、评论或外链证据，并分别测召回、跨源关联、主张成立和引用正确；渐进式 gate 能定位故障发生在“没找到、没连上、推错了”中的哪一层，便于针对性修复。

INSIGHT把更多思考文本塞进 prompt 可能让 Agent 更忙，却不一定让检索更准；轨迹状态必须进入经过校准的动作策略，而非无条件上下文。线上应监控重复 query、零结果、无效邻域扩展和单位预算的排名增益，并让策略学习何时宽搜、局部扩展、回退或停止；单纯收紧轮数只降成本，不能修复错误动作选择。

INSIGHTGraphRAG 的优势高度依赖语料规模和实体索引质量，不能把小候选池收益直接外推到生产开放库。对 UGC 社区，图检索更适合补充跨帖实体关系和可解释路径，而 BM25 仍应保留为强基线；上线前必须在真实全量索引上比较召回、首位精度与成本，并验证融合增益是否统计显著。

INSIGHT当 UGC 搜索包含截图、长图或多页附件时，纯 OCR 会丢失布局与图表语义，页面级视觉索引和结构化文本索引应并行保留。实践上可先用混合召回取候选页，再让验证 Agent 检查缺失证据和引用；需要注意该方法牺牲部分 Precision@K 换取更高证据覆盖，必须结合生成阶段的上下文预算评估。

INSIGHTAgent 评测需要同时覆盖状态、工具执行和隐性高风险场景，静态问答无法暴露“说已完成但工具未执行”这类故障。搜索产品可借鉴动态场景生成与可复用 rubric：用合成用户画像和长尾意图驱动多轮检索，并把检索正确、动作落地、风险升级和对话体验分开评分；安全维度宜采用偏保守的自动判定并抽样人工复核。

INSIGHT工业落地的瓶颈正在从“能否生成实现”转向“如何定义验收标准并长期维护”。搜索/推荐团队使用 Agent 改造召回、特征或评测代码时，应先建立结果等价、统计行为和回归测试等外部 oracle，把大任务拆成可测迭代，并明确代码所有者；否则低成本生成会制造更多分叉实现和维护债务。