得物推荐系统诊断 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 存储检索实现大段技术内容的有效利用。极致省 TokenGraphify 精简图谱 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 时代自治运维的可行路径。下一步我们可以期待它从 “诊断” 走向 “预防”在问题发生前就发出预警。技术发展的本质不就是为了让人从枯燥的重复劳动中解脱出来去从事更有创造性的工作吗“推查查” 让我们离这个目标又近了一小步。往期回顾1.从狂野代码到按目标生产得物推荐 AI Harness 的工程化实践AICon 演讲整理2.得物 OceanBase 落地实践3.AI UITesterAI Native 的 UI 自动化测试新范式得物技术4.从表单到 Agent得物社区活动搭建的 AI 实践之路5.从埋点需求到规则资产Hermes Agent 重构得物数仓工作流文 / 炎阳关注得物技术每周更新技术干货要是觉得文章对你有帮助的话欢迎评论转发点赞未经得物技术许可严禁转载否则依法追究法律责任。