INSIGHTUGC 搜索 Agent 的失败不一定来自召回器，可能是计划漂移、记忆丢失或工具执行未完成。落地时应把一次回答拆成可观测的 query 分解、检索、证据校验和生成节点，分别记录 nDCG、证据覆盖、工具成功率与最终 CTR，避免用单一答案分数掩盖长链路瓶颈。

INSIGHT搜索 Agent 读取帖子、长文或附件时，不应默认每一步都调用强模型。可先用轻量特征估计 query 与文档复杂度，只有在预测到召回歧义、表格结构或跨文档证据缺口时升级模型；上线前必须验证‘便宜模型确实会失败’和‘失败可被特征预测’两个前提。

INSIGHT对社区搜索的长期 Agent 记忆，可把用户偏好、会话目标和当前 query 分开存储，只允许对应层局部更新，避免一次新对话覆盖长期兴趣。上线评测应加入跨会话状态一致性与局部更新回归，而不只测单轮答案相关性。

INSIGHT搜索 Agent 的难例构造可以从固定模板转为能力边界校准：让强弱检索器或不同 Agent 配置竞争同一 query，生成只被其中一个配置解决的难例。这样能持续发现 query 分解、工具调用和证据核验的边界，补足随机抽样无法覆盖的长尾 UGC 查询。

INSIGHT搜索 Agent 的用户画像也可能在连续交互中被错误地‘人格化’或过度收敛。可借鉴 BFI-Adapt 的对照思想，为用户长期兴趣建模加入无事件重测、改写 query 稳定性和跨会话持久性检查，区分真实偏好变化与上下文噪声。

INSIGHT对社区搜索，真正需要优化的不是某个孤立 reranker，而是 query 规划、检索器切换、证据读取、工具权限和终止条件的组合。建议建立 harness 级 trace，至少统计每次搜索的子 query 数、重复调用率、证据覆盖率、耗时和最终点击反馈。

INSIGHT搜索 Agent 需要读取表格、卡片和附件时，工具模型的增量训练不能只看新任务分数。更稳妥的做法是混合保留原能力的回放数据，再用任务级奖励优化结构化输出，并用奖励方差过滤低价值 prompt，避免文档解析升级反过来损伤通用问答。

INSIGHTUGC 搜索 Agent 可能把危险操作、隐私泄露或越权建议包装成正常答案，因此安全评估应放进检索—工具—生成链路的每一步。可采用‘逻辑连贯 + 情境安全’双奖励，并保留高风险 query 的轨迹级审计，而不是只对最终文本做关键词过滤。

INSIGHT迁移到 UGC 搜索时，重点不是照搬财务场景，而是保留‘检索证据—中间分析—可编辑交付—过程可追溯’的链路。对搜索 Agent，应让每个工具调用留下证据与版本信息，使线上点击下降时能定位到 query 改写、召回、重排还是生成环节。