工作流采纳 90%，多 Agent 只有 70%–80%：京东商责研判

工作流采纳 90%，多 Agent 只有 70%–80%：京东商责研判

京东云开发者社区在 2026 年 9 月 10 日记录了零售风控「智能商责研判 Agent」的三次演进。页面作者是社区账号 jd_75b13faa18e21，不是具名团队。截至 2026 年 8 月 1 日的线上数字和离线回放规则写在同一篇里，分母并不一样。

商责研判是平台根据规则和案件事实，判断商家是否要对某次交易、商品或服务问题担责。范围不只有「是不是全新」，还包括宣传和实物是否一致、延迟发货报备是否不当、食品是否满足安全要求。人工要在主站、订单、售后、举证图片和商家资质之间来回切，疑难案件平均要 5–10 分钟。

它不是对话 Agent

这篇要做的是端到端案件研判：在时效和资源预算内自己取材料、核验事实、汇总证据、交付结果。证据够，就给出能进后续流程的结论；证据不足、系统异常或风险高，就标明原因转人工，不用猜测代替结论。

对照写了三类 Agent。对话型靠用户追问纠偏。数据分析型靠分析人员改口径、重查。案件研判型必须自己处理不确定性。

系统约束也写了四条，都是设计要求，不是实测分数：

• 日常案件量写成十万级。不能靠无限轮推理或无节制工具调用。原文没有给出实际 QPS、单案耗时或 token 上限。
• 文本、图片、视频、PDF、订单和聊天的证明力不同。认出异常线索，不等于已经满足关联性和充分性。
• 外部知识可以用，宽泛规则必须落到证据来源、上下文和例外。
• 交付不能只是「是/否」。还要有结论、关键事实与证据、判定依据，以及异常或转人工状态。

演进顺序是：Prompt 编排，再到场景化工作流和多 Agent 协同，再到案件反馈驱动的自进化。

1.0 只证明 AI 能参与

1.0 用 Prompt 注入任务、规则和输出格式。前后处理代码做清洗、串联调用、解析和回填。以「是否夸大宣传」为例：先把商品信息和投诉整理成输入，再把规则写进 Prompt，模型给出结构化结果，系统补业务字段回传。不同场景沉淀了任务模板、过滤条件和终止节点，用来减少不必要的模型调用。

这一阶段没有准确率、采纳率或样本量。原文只说它验证了 AI 可以参与复杂商责的证据研判，部分场景能接重复工作。问题是 Prompt、规则和业务代码缠在一起，改一个场景可能碰到多个步骤；出错时往往只看见「结果不对」，看不出是哪一步。服务调用失败、证据不足和非商责如果没有边界，会混在同一个结果里。

2.0 先把经验写成能执行的 SOP

规则、证据口径和例外来自平台实践，不是通用模型自带的。新增场景如果每次都口头解释，覆盖扩不大。

做法不是从自然语言直接写 Prompt。先让业务把研判画成流程图：节点是待核验的事实，分支是判断、后续动作或结束条件。「出售非全新商品」会写清先看哪些材料，标题披露、商家回应和用户举证各自说明什么，运输痕迹、出厂检测这类解释要满足什么条件。

流程图还不能跑。什么叫对「非全新」的有效披露，「退款」「换货」算不算商家承认，划痕、灰尘、包装破损何时算有效证据，都要再澄清。系统根据流程图找出判定节点、分支和所需输入，用 AI 生成待确认问题清单，业务逐项确认，沉淀成场景研判 SOP：判断条件、证据要求、例外、异常边界、输入输出约束。原文写明 AI 不替业务发明规则。

路径稳定、证据空间不开放的，用场景化 Agent 工作流。证据组合开放的，用多 Agent 协同。图 6 画的是这两条的组织边界，没有配流量占比。

工作流：顺序事先写死

「出售非全新」的顺序是固定的：先看标题有没有有效披露「非全新」；没有，再看商家是否承认展示机、翻新机或已使用；还不能收敛，才核验用户举证是否规范，以及图片、视频能否证明非全新。

实现落在 LangGraph 上。标题、聊天、图片等 Agent 节点核验事实；图运行时决定顺序、能否提前收敛，以及异常后继续、终止还是转人工。和 1.0 的差别是：调用顺序、终止条件和异常分支从散落的 Prompt 和代码，收成节点和条件边，过程可以回放。

多 Agent：运行时才决定派谁

「商品信息与实物不符」往往只有一句「和页面不一样」。颜色、款式要对比宣传图和举证图；材质要核页面承诺、实物标签和举证；少发充电器要核配置、订单和聊天。商家已经在聊天里承认漏发并要补发时，可以直接收敛，不必再比图。

规则仍然在 SOP 里。差别是进系统之前不知道缺哪一项事实。把所有分支预先写进每条案件，会产生大量无关核验，流程也会越来越难维护。

所以这条路径用 Claude Agent SDK，外面再包一层商责 Harness。SDK 提供会话、派发、专业 Agent、工具与 MCP、执行事件。Harness 补角色职责、上下文、工具权限、任务状态、结构化结果和留痕。

主 Agent 不按固定顺序叫所有角色。它看哪些事实已确认、哪些证据还缺、哪些任务能并发、哪些必须等前序结论，再派专业 Agent。子 Agent 返回后，主 Agent 按 SOP 决定继续补证、新开核验，还是收敛。

边界写得很硬：SOP 仍定义依据，角色有职责，工具有权限，结果走统一结构化接口。证据不足、任务异常或高风险必须输出异常或转人工。任务派发、工具调用、子 Agent 返回和异常都记下来，给排查、回放和后面的 BadCase 归因用。

3.0 把改线上和出候选拆开

工作流和多 Agent 只保证一次研判可控。商品形态、违规手法和规则还会变，人工复核会出现新边界。规则边界、模型理解、输入质量或外部服务异常都可能让结论偏。人工逐条翻案例再改 Prompt，规模上跟不上。

这里的「自进化」不是自动改线上规则，也不是自己发生产变更。系统自动做问题发现、归因和候选验证。生产规则、工作流策略和高风险裁决仍由人决定。

第一步是留痕。每次执行记脱敏后的输入摘要、节点路径、Agent 派生、Agent 输出、耗时、异常和最终结果，叫做 Trace。只留复盘需要的字段。人工复核和系统结论不一致时，要能看出差异在证据读取、事实核验，还是流程路由。

第二步是 BadCase。系统结论和人工标注或复核不一致，才算 BadCase。归因 Agent 不重新裁决对错，只根据真实轨迹看偏差来自：规则边界不清、缺新规则、输入或证据质量、节点调用异常，还是路由、规划和依赖。归因只能引用这起案件实际走过的节点、对应规则和 Prompt。再按节点、规则和问题类型聚合，形成候选优化方向和最小修复指引，交给业务、运营和产研评审。

第三步是离线验证。拟改的 Prompt、规则或节点策略，用历史轨迹回放：在相同或可比的历史输入上跑候选版本，对比新旧输出，看哪些从错变对、哪些可能从对变错，并生成差异报告。新旧工作流迁移可以做影子比对，不影响正式结论，有差异的样本优先给业务复核。

图 11 的图注写的是「进化前后的差异报告」。原文没有写出从错变对、从对变错的件数，也没有写回放样本量和通过线。只有经过历史回放、差异审查和人工准入的方案才能进灰度或上线，其余留在离线迭代。

线上数字停在 2026 年 8 月 1 日

图 12 的图注又写成「进化前后的差异报告」，和上文图 11 重了。下面这段才是规模数字，统计截止日是 2026 年 8 月 1 日，比文章发布日 9 月 10 日早：

• 覆盖 15 个风控合规二级场景、30 个三级场景。
• 场景化工作流的 AI 结论采纳率 90%。
• 多 Agent 协同研判的结论采纳率 70%–80%。
• 商品信息与实物不符：周均研判单量从 2,000 到 6,000，提效 3 倍。
• 品质缺陷里的非全新：周均从 1,000 到 1.5 万，提效 15 倍。
• 不当延迟发货报备：全流程无人化研判和处置，周均自动研判 1,000 单、自动处置 300 单。
• 本地生活食品安全：周均自动研判 21 万单、自动处置 5.6 万单。

90% 和 70%–80% 不是同一条路径的分数，不能合成一个总准确率。原文没有写采纳率的分母、抽样窗口、人工复核比例，也没有写「提效」是相对纯人工还是相对 1.0。2,000 到 6,000 是研判单量，不是准确率。自动处置 300 和 5.6 万是处置量，不是判对的数量。

能直接拿去用的是顺序，不是那个 90%：先把经验收成 SOP，路径稳定的用可回放工作流，证据组合开放的用受约束的多 Agent，线上改动必须先有 Trace、BadCase 归因和历史回放，人点头之后才进生产。

京东云开发者社区，jd_75b13faa18e21，从真实业务落地到持续“自进化”：揭秘零售风控智能商责研判Agent的三次演进，2026-09-10，https://developer.jdcloud.com/article/4586