INSIGHT对社区搜索中的复杂意图，可以把查询理解、召回、事实核验等能力封装成可检索的 Agent profile，而不是让一个大模型每次从零规划。工程上应维护 profile 的版本、适用域和工具契约，并用小模型负责路由与蒸馏，大模型只覆盖低频、高不确定性的搜索任务。

INSIGHT这对 Agentic RAG 的多轮搜索预算很关键：离线挑出高收益轨迹不能证明线上模型能识别高价值查询。应同时做随机对照、噪声 placebo 和 per-instance policy 评估，再决定哪些 query 值得继续检索；否则系统可能只是把排序噪声误判为可学习的调用信号。

INSIGHT社区帖子、评论和图文混排内容不应默认全部塞入上下文。可以先做低成本粗读，再按实体、表格或证据密度触发局部精读，并把缩放动作纳入 Agent 轨迹；8B 模型和公开代码降低了试点门槛，但仍需用 nDCG、证据命中率、P99 延迟和图片 OCR 错误率共同验收。

INSIGHT社区 UGC 搜索也存在“文档找到了但关系没恢复”的问题，例如作者—话题、事件—地点或评论—帖子之间的隐含连接。评测应把单跳召回、跨文档组合、潜在关系推理拆开，并记录证据链和可验证答案；否则一个看似更高的最终准确率无法说明 Agent 究竟改进了检索还是只改进了生成。

INSIGHT对社区搜索 Agent，最危险的不是不会生成答案，而是在第一次命中后过早停止验证。应把“继续检索”作为显式动作，给 query、证据、来源和用户偏好建立可追踪状态；评测除最终答案外，还要统计定位错误、误用证据、工具调用深度和跨来源整合成功率。

INSIGHT社区平台的搜索需求也会随热点、作者状态和内容生命周期变化，不能把一次回答的准确率当作 Agent 能力终点。可借鉴其时间线与后端状态评测，把新帖发现、过期内容回避、用户偏好更新和主动澄清纳入长期 replay，并为“不该行动”设置明确的负奖励。

INSIGHTAgentic 搜索的交互质量不应只看 nDCG 或答案正确率，澄清次数、用户信息量和信任也会改变后续 query。社区产品可以按探索、比较、核验场景动态选择对话策略，同时保留简洁基线；不要把更长回复或更主动追问直接当成更好的用户体验。

INSIGHT这为搜索 Agent 的工程评测提供了可迁移范式：把工具编排、操作系统落地、中间结果反馈和最终业务正确性放进同一任务，而不是只测单轮 QA。社区搜索可构造带索引更新、召回失败重试、结果过滤和排序回写的长链路任务，用确定性检查器区分模型推理错与工具执行错。