一则异常推荐案例告警推送而来，屏幕上呈现的是个看起来不太对劲的推荐结果。屏幕背后，是研发同学面对海量Trace日志时的典型困境——召回、粗排、精排、策略过滤，多层嵌套的逻辑迷宫，每个filter_code或异常分值都像待解的谜题。过去，这高度依赖个人经验，甚至需要多方会诊，才能从密密麻麻的代码中揪出那个隐藏的“地雷”。遇上逻辑耦合或实验冲突，排查过程无异于一场马拉松，效率受限不说，团队还陷在低效重复的体力消耗中。这种深度黑盒的运维压力，让开发者始终被动应对各种线上突发问题。

现在，“推查查”的出现正在终结这种盲目排查的时代。它是推荐系统领域的“自动驾驶诊断专家”，让复杂的算法逻辑变得透明、可追踪、可预测。推荐系统的排查焦虑，本质上是知识的不对称与信息的碎片化。

• 1.0 经验驱动时代（早期）：这个阶段高度依赖静态文档和核心成员的个人经验。异常发生时，团队往往通过多方汇总、手动检索日志、抓取关键词来拼凑上下文。这种“地毯式”检索效率极低，排查过程如同盲目博弈。
• 2.0 平台工具时代（中期）：接入截图识别、日志查询和画像看板等API后，排查流程实现了数字化。虽然解决了“看得到”的问题，但本质上仍是“由人驱动机器”。海量的诊断经验无法沉淀，排查链路依然重度依赖专家判别，难以形成标准化闭环。

突破天花板：传统推荐诊断方案的“三大认知困境”

在自动化排查的探索中，我们落地过多种技术方案，也从中总结出传统架构普遍存在的三类典型局限：

• 局限一：SOP 脚本化的“线性僵化”。这种方案试图将专家路径固化为固定脚本。虽然能快速响应已知问题，但弊端明显：推荐策略与底层架构的快速迭代，使得脚本的更新速度永远滞后于业务变化。面对“新题型”，这类方案往往表现出极高的维护门槛和极弱的泛化能力。
• 局限二：纯 Agent 模式的“效率鸿沟”。直接利用大模型进行端到端的自主排查，现阶段仍面临严峻挑战。高推理成本（Token消耗）与较长的响应延迟（分钟级等待），使其难以满足生产环境严苛的SLA要求。模型本身可能存在的逻辑偏离（幻觉），也增加了二次验证的时间成本。
• 局限三：经验孤岛化的“知识流失”。由于缺乏有效的沉淀机制，核心诊断逻辑往往存在于个人经验中。人员更迭时，就会出现严重的“知识断层”。现有工具大多只能停留在“展示现象”（输出状态码）的层面，而缺乏“辅助决策”（输出行动路径）的能力。诊断与行动的脱节，导致平均故障修复时间（MTTR）始终处于高位。

二

解决方案：“推查查” 登场

在“推查查”建设初期，我们深度权衡过：是基于通用开源框架进行定制，还是采用更具工程确定性的OpenClaw？最终选择了后者，目标就是打通智能诊断“生产环境落地”的最后一公里：

• 从“过程耦合”到“原子化插件”：传统的链式调用在处理推荐系统复杂的逻辑嵌套时，容易陷入难以维护的耦合。OpenClaw的插件化规范（Plugin/Skill）让我们能将各平台的API封装为标准化的Skill。这种原子化的解耦能力，完美契合了推荐系统多策略、高频迭代的业务底色。
• 企业级的“确定性”治理：灵活性是Agent的利刃，但在生产环境下，确定性才是基石。OpenClaw框架对ReAct逻辑流提供了更严谨的控制机制（如最大迭代熔断、工具调用白名单等），有效规避了Agent陷入逻辑死循环或产生非受控幻觉的风险。
• 生态兼容与能力复用：OpenClaw对演进标准的适配性，确保了我们沉淀的Skill资产不仅能服务于“推查查”，更能在未来低成本地辐射至企业内部其他智能场景，实现“一套核心能力，全域多处调用”。

三

Highway 与 ATV，诊断界的“快”“全”双模式

系统设计中，开发者往往面临一个抉择：是追求极致响应的线性逻辑，还是追求深度推理的自主智能？我们的答案是：拒绝取舍，兼容并蓄。基于此，"推查查"构建了独特的"Highway & ATV" 混合智能体架构。它不是两种模式的简单堆砌，而是效率与智能的深度融合。

• Highway（高速路）：这是我们的标准化诊断流水线，专门负责处理80%的常见问题。当用户问题命中知识库中的标准Story（比如“根据截图评测商品”、“某用户推荐不准”、“某个商品被过滤”），系统就会自动进入Highway模式。它像工厂流水线一样，按照预设的标准剧本（Story）一步步执行。
• ATV（全地形越野车）：则是我们的王牌侦察兵，专啃20%的长尾、复杂硬骨头。当遇到从未见过的异常，比如“特征服务网络抖动引发精排分数集体漂移”这种诡异场景，Highway的固定剧本就失效了。这时，系统会自动无缝降级到ATV模式。它基于ReAct框架，像真正的专家一样自主规划：先看日志，发现网络错误；然后调用工具检查网络拓扑；再关联分析同时段失败的其他请求……一步步推理，直到找到根因。它不依赖固定脚本，灵活且强大。

关键在于中间的智能调度器（判定引擎）。用户问题一来，它先去知识库快速匹配，命中标准Story就走Highway；匹配不上或Highway执行中卡住了，立刻切换到ATV模式。双轨互补，智能切换，确保任何问题都有路可走，有法可用。

“推查查” Highway & ATV 双轨架构示意图

左侧高速路处理常见问题，右侧越野车攻克复杂异常，中间智能调度实现无缝切换。

四

核心技术解剖：从原理到实现的硬核拆解

前面说了那么多“AI诊断专家”的故事，是时候掀开引擎盖，看看这辆“诊断跑车”到底是怎么跑起来的了。

Story 基座：原子化 Skill

基于内部API，我们沉淀了一套遵循MCP标准的Skill工具集。这套工具库如同为推荐能力装上了“通用接口”，不仅支撑了当前Agent的精准调度，更形成了一套可复用的技能基座。通过简单的场域适配，这套能力可迅速辐射至社区、广告等场景，成为各场域快速拉起自身Agent能力的“助推器”。几个核心Skill介绍如下：

这些Skill就像乐高积木，Highway的剧本可以按顺序拼，ATV的推理引擎可以按需调用。新增排查能力？再封装一个Skill加入即可，热插拔，不用停机。

Highway Story 编排：剧本驱动的确定性执行

Highway模式的核心是Story 机制——把专家的排查路径固化成可复用的标准剧本。每个Story本质上是一个有序的Skill 编排模板，定义了标准的执行路径。

Story 结构示例：

Story: 商品推荐异常-标准诊断
├── Step 1: screenshot-trace-query# 截图识别，自动匹配Trace
├── Step 2: user-profile-query# 查用户购买/点击历史
├── Step 3: layer-items-query # 看商品在各层曝光情况
├── Step 4: strategy-logs-query# 核对策略干预（去重/过滤）
├── Step 5: commodity-forward-query# 查商品正排信息
└── Step 6: output_diagnosis # 输出诊断结论

Story 的核心特性：

• 确定性执行：每个Step严格按照编排顺序执行，不存在“AI自主决策”。
• 条件分支：支持if/else条件判断，如“若召回结果为空 → 进入召回专项排查分支”。
• 热插拔：Story可独立版本控制，业务迭代时只需更新Story配置，无需改动代码。
• 降级兜底：当某个Step执行失败或置信度低于阈值，自动触发ATV降级。

Story 的诞生方式：

• 手工沉淀：专家（即我们的研发同学）手动编排核心排查路径。
• 自动进化：ATV成功解决长尾问题后，通过反思框架自动蒸馏生成新Story。

这才是“Highway”的精髓——把专家脑海里的“经验”变成可执行、可复用、可进化的标准化剧本。

story - skill 工具库

ATV 的 ReAct 循环：让 AI “有章可循”

ATV模式采用OpenClaw框架，实现经典的ReAct循环：

Question→ Thought → Action(Skill) → Observation → Final Answer

但“放飞自我”的AI容易陷入死循环，就像走迷宫时沉迷探索每条岔路，却忘了找到出口。我们给它装上了三道约束。

• Max Iterations = 6：最多思考6步，再强的专家也必须停下来，防止“过度推理”。
• Tool 白名单：只给它能用的小工具，不让它乱调用（比如不让它访问无关数据）。
• 置信度阈值：每步推理都要自问“这个结论靠谱吗”，不靠谱就换思路，拒绝盲目自信。这套机制让ATV既能自主探索，又不会脱缰狂奔。毕竟我们要的是“越野车”，不是“脱缰野马”。

辅助诊断：知识库的向量检索

随着推查查深入业务，技术文档、代码架构、业务记忆的积累成为瓶颈。比如，召回渠道TIDE，它并不知道是首页瀑布流的潮汐召回，只会根据字面意思理解为基于全站热度/趋势做的非个性化召回；同时传统的RAG方案在代码理解、跨场景关联上存在明显短板。我们探索了一套「上下文引擎 + 知识图谱」的混合架构。

核心组件

OpenViking并非传统意义上的RAG工具，而是以“上下文驱动”为核心，整合记忆存储、文档索引、语义检索、多Agent隔离与共享的本地上下文引擎，主要服务于需要长期记忆、大规模文档检索、多Agent协同的AI应用场景，尤其适配OpenClaw插件生态，解决原生记忆检索弱、多Agent数据隔离难等问题。

Graphify是2026年爆火的开源工具，核心定位是将本地文件夹（代码、文档、图片等）转化为“实体+关系”的知识图谱，主打极致省Token、代码工程理解与多模态适配，恰好弥补OpenViking在技术文档深度解析上的短板。

我们利用OpenViking + Graphify的组合，重构了本地知识库的构建逻辑——OpenViking负责“管记忆、管协同、管检索”，Graphify负责“做结构化、做解析、做精简”，两者协同实现：

• 解决技术文档“提取记忆失败”的痛点：Graphify结构化拆解，OpenViking存储检索，实现大段技术内容的有效利用。
• 极致省Token：Graphify精简图谱 + OpenViking三级分层，大幅降低LLM上下文消耗，提升响应速度。
• 多Agent高效协同：OpenViking实现数据隔离与共享，Graphify提供统一的结构化知识底座，适配复杂业务场景。

整个知识库内容按详细程度分为三层，按需加载，避免上下文膨胀。

过去排查故障分为两步：人工定位问题、自主查阅方案；现在AI一站式完成根因识别与修复指导，同步给出异常位置与配套执行方案。比如：它不会只冷冰冰地告诉你：“结论：被去重策略拦截。” 它会结合公司的业务Wiki和SOP手册，附上一句：“行动建议：请去商品管理平台确认，检查商品ID是否被误加入‘商品搜推黑名单’。” 从诊断到修复的最后一公里，它也帮你铺好了路。这下，很多简单问题，产品、运营同学自己就能查明白。

后续优化点：我们现在使用知识库的方式是语义触发，向推查查提问时，只要问题涉及记忆检索或背景知识查询，OpenViking会自动触发。这种方式有个触发策略问题，推查查“不知道什么时候该查文档”或“该查时不查、不该查时乱查”；现在有几个思路，待后续进行尝试探索看看效果：

• 引入“确认式检索”

“在回答技术问题前，你必须先评估：‘我是否拥有该问题的最新配置参数/文档？’ 如果答案是NO，必须调用知识检索Skill，禁止凭记忆盲目回答。”核心逻辑：利用Agent的思考链（CoT），在查文档前加一个“自问自答”的环节；标准指令：在System Prompt中加入固定约束；效果：强制Agent意识到自己的“知识盲区”，变被动检索为主动索取。

• 意图分类触发

不要让Agent对每一句话都去扫描向量数据库，而是先过一层轻量级的意图判断；显式触发：训练一个微型分类器（或通过System Prompt约束），识别带有“查询”、“确认”、“对比”、“背景”等特征的指令；关键词密度：如果用户输入中包含特定领域的专有名词或长尾词（高IDF词），则强制触发检索；缺点：无法处理隐含的背景需求。

进化层：从“排查记录”到“通用方法论”的进化全流程

进化层的核心是“反思 - 抽象 - 验证”三阶段闭环，参考Hermes的自我进化机制，让系统从“排查记录”中学会“通用方法论”：

第一步：轨迹剪枝与效能提纯

核心任务：将冗长的Agent思考过程压缩为“黄金路径”。

• 动作：进化引擎回溯Agent在原始排查中的所有排查历史、满意度反馈、每日记忆。
• 逻辑：识别并剔除试错路径（如：查询了无关的商品信息），仅保留对最终根因定位起决定性作用的工具调用链。
• 效果：将原本需要10步的繁琐过程压缩为3-4步的高效诊断链，实现“排查路径的最优化”。

第二步：特征升维与逻辑泛化

核心任务：脱离单次Case的偶然性，提取具有通用性的业务逻辑。

• 动作：利用LLM的业务感知能力，将具体的“硬编码数据”（如具体的UID、特定的RequestID、某一个商品ID）自动映射为高维业务变量。
• 意义：解决逻辑的“空间迁移性”，确保该排查经验能自动适配不同用户、不同时间段的同类故障。

第三步：Story 和 Skill 生成

• 动作：将泛化后的逻辑链封装为符合标准协议Story和Skill。
• 逻辑：不再编写复杂的代码，而是生成一个包含“触发条件、执行逻辑、断言检查”的结构化skill.md。
• 产出：skill.md，可直接存入Agent技能仓库（Skill Store），供后续排查秒级调用。

第四步：沙箱 Dry Run 与准入校验

核心任务：建立知识的质量防线，防止不成熟的诊断逻辑污染系统。

• 动作：在新技能正式上线前，系统自动抓取过去7天内相关的排查Case。
• 回放（Replay）：强制系统利用新生成的Story或者Skill对历史Case进行自动化回放。
• 准入判定标准：自动化排查结论与专家人工结论的一致性是否 > 90%；决策：达标则合入Highway（高速诊断通道），不达标则打回进化层重新反思。

从此，系统每解决一个新难题，就自动学会一项新技能，自动优化原有技能。知识不再随着人员变动而流失，而是在系统中系统化沉淀。真正实现了“越用越聪明”，从“工具”进化成了有“诊断能力”的智能体。

每日进化

提案入库上线

为什么我们没有直接照搬 Hermes？

其实在Hermes出来之后我们已经有初步每日总结和反思机制，但是Hermes还是给了我们很大的启发，特别是它的“反思 - 蒸馏”机制。但在推荐系统的生产环境下，我们需要的是“确定性的进化”。

• Hermes 像是在“练内功”：让模型整体素质变强，但你不知道它下一次排查时会出什么招。
• OpenClaw 像是“打铁铺”：给了我们最好的工具模具。
• 推查查则是“编写拳谱”：我们利用OpenClaw提供的ReAct框架让ATV去“练实战”，再参考Hermes的思想，将实战中那些有效的招式（路径）剪枝、泛化，最后固化成一段段Highway的“拳谱”（Story）。

我们有自己的进化层的“推查查特点”：

• 脱离参数依赖：我们的进化结果是Skill和Story。这意味着即使我们明天更换了底层大模型，这些沉淀下来的“排查经验”依然可以直接无缝迁移。
• 回放准入制：不同于Hermes的全自动合入，我们增加了一个“Dry Run”校验环节。新进化的技能必须在过去真实Case回放中保持90%以上的一致性，才能正式进入Highway通道。

资深工程师笔记：“真正的进化不是盲目追求自动化，而是在保持系统确定性的前提下，实现知识的流水线化沉淀。”

五

实战：商品重复推荐诊断

这是一个来自内测群的真实案例：“为什么一直给我推送手机壳？”推查查自动执行诊断流程。

Story: 商品推荐异常-标准诊断
├── Step 1: screenshot-trace-query # 截图识别，自动匹配Trace
├── Step 2: user-profile-query# 查用户购买/点击历史
├── Step 3: layer-items-query # 看商品在各层曝光情况
├── Step 4: strategy-logs-query# 核对策略干预（去重/过滤）
├── Step 5: commodity-forward-query# 查商品正排信息
└── Step 6: output_diagnosis # 输出诊断结论

诊断结论（AI 自动生成）：

• 手机壳被TIDE渠道召回（TIDE = 潮汐召回，是二次加工后的召回渠道）；
• 原始召回来源储存在item.extMap.cns_v2字段里；
• 系统发现用户近期浏览过手机壳类商品（兴趣信号），持续召回了相似商品；
• 结论：不是Bug，是用户行为信号触发的正常召回，只是曝光频次过高影响用户体验。

六

写在最后：当AI成为系统的“诊断专家”

回看“推查查”的成长之路，它不仅仅是一套排查工具。它是一个有诊断能力、有学习能力、甚至有点“实战经验”的智能诊断系统。它把我们这些工程师从重复、低效、充满不确定性的“玄学debug”中解放出来，让我们能更专注于算法本身的迭代与创新。当然“推查查”也还在持续的成长和迭代中，偶尔还是会有一些意料之外的回答，它的意义在于，我们开始用AI去解决推荐系统自身最棘手的排查难题。这或许是一条通往AI for System，乃至未来AGI时代自治运维的可行路径。下一步，我们可以期待它从“诊断”走向“预防”，在问题发生前就发出预警。

技术发展的本质，不就是为了让人从枯燥的重复劳动中解脱出来，去从事更有创造性的工作吗？“推查查”让我们离这个目标，又近了一小步。