78%自动解决／拦截率 · 原有基线
88%自动解决／拦截率 · 上线首日
95%自动解决／拦截率 · 半年后稳定
重新审视“解决率”
开发者进线询问模型选型、计费规则或 API 报错时，需要的是准确且能直接跑通的方案。如果只盯着“减少转人工”，系统很容易用模棱两可的套话把用户挡在门外。因此，我们将“自动解决／拦截率”与“用户满意度”绑定观察，并抽样分析了 5,000 多条真实历史工单，按实际问题分布搭建了首轮评测基线。
导航式检索，而非碎片拼接
为什么常规 RAG 在技术文档上表现不佳？因为切片破坏了前提条件与层级关系。在架构设计上，我选择让 Agent 先逐级探索文档目录树，保留完整的来源与层级路径，锁定章节后再读取全文。当评测发现“平台促销活动”类问题频繁答错时，我顺着执行轨迹定位到根本原因——原文档目录命名过于晦涩，导致寻址迷失。对此，我们没有靠堆砌 Prompt 补丁硬凑，而是直接推动文档侧增设独立的“热门活动”目录入口，从信息源头解开了死结。
收益与方法边界
上线首日，自动解决／拦截率即从 78% 跃升至 88%；经团队半年的持续运营迭代，最终稳定在 95%，且用户满意度保持在 4.0/5.0 以上。
适用边界：这种“目录导航式检索”高度依赖结构清晰、维护良好的权威知识库；面对散乱的内部群聊记录、实时变动的状态数据或非结构化长文，仍需结合传统向量检索与专用查询工具（Tools）协同处理。