得物推荐系统诊断 Agent：从 “调接口” 到 “会思考”｜AICon 演讲整理

本文是得物技术专家在 AICon 上海演讲整理的技术实录。

「得物推荐 AI Harness 工程化实践系列」的中篇内容，本系列共三篇连载。本篇（中篇）进一步详解得物推荐复杂业务场景下，AI代码从生成、防护校验到安全上线的完整技术体系、自研AI Harness整体架构框架、全流程安全防护机制、混合智能体核心算法实现，以及工业级工程落地的实战细节。

一、前世今生：从 "人工排查" 到 "系统沉淀"

"消息提示音响起，一则异常推荐案例告警推送而来。屏幕里是一个异常的推荐 Case，屏幕背后，是研发面对海量 Trace 日志的棘手难题。召回、粗排、精排、策略过滤...... 在多层嵌套的逻辑迷宫里，每一个 filter_code 或异常分值，都像是一个待解的谜题。过去，我们高度依赖个人经验，甚至需要多方会诊，才能从密密麻麻的代码中揪出那个隐藏的 "地雷"。如果遇到逻辑耦合或实验冲突，排查过程无异于一场漫长的马拉松，不仅效率受限，更让团队陷入低效重复的体力消耗。在这种深度黑盒的运维压力下，开发者始终被动处理各类线上突发问题。

而现在，"推查查" 的出现，正在终结这种盲目排查的时代。它是推荐系统领域的 "自动驾驶诊断专家"，让复杂的算法逻辑变得透明、可追踪、可预测。从今天起，告别深夜焦虑，让推荐系统真正进入 "白盒时代"！推荐系统的排查焦虑，本质上是知识的不对称与信息的碎片化。

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

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

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

局限一：SOP 脚本化的 "线性僵化"。 这种方案试图将专家路径固化为固定脚本。虽能快速响应已知问题，但弊端明显：推荐策略与底层架构的快速迭代，使得脚本的更新速度永远滞后于业务变化。面对 "新题型"，这类缺乏灵活性的方案往往表现出极高的维护门槛和极弱的泛化能力。
局限二：纯 Agent 模式的 "效率鸿沟"。 直接利用大模型（LLM）进行端到端的自主排查，在现阶段仍面临严峻挑战。过高的推理成本（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 工具集（由于数据安全问题，没有上传到公司 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（社区常称 Graphify Viki）是 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 通道。

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

五、实战：商品重复推荐诊断

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

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

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

六、写在最后：当AI成为系统的"诊断专家"

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

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

往期回顾

2.得物 OceanBase 落地实践

3.AI UITester：AI Native 的 UI 自动化测试新范式｜得物技术

4.从表单到 Agent：得物社区活动搭建的 AI 实践之路

5.从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流

文 / 炎阳

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。