从 Prompt 编排、到场景化 Agent 工作流与多Agent协同、再到案件反馈驱动的持续校准

智能商责研判Agent

一、背景：平台为什么需要商责研判

假设你在网上购买了一台标注“全新”的手机。收货后，你发现机身有划痕，系统里还留着疑似他人使用过的内容。商家解释说，这些痕迹来自运输或出厂检测，商品标题里也标明了“拆封检查”等相关描述。此时，平台该如何评判？

是商家应当为“出售非全新商品”承担责任，还是商品信息已经充分披露、现有痕迹也有合理解释？这个判断会影响消费者权益保障、商家后续处置和平台治理的公平性。它不是简单地识别一张商品图片，更不是让模型在“是”或“否”之间选一个答案。

这类判断在平台治理中通常被称为商责研判：平台依据业务规则和案件事实，判断商家是否应当对某次交易、商品或服务问题承担相应责任，覆盖的研判范围不只是“商品是不是全新”，还包括商品宣传与实物是否一致、商家是否存在不当延迟发货报备、食品是否满足安全要求等众多平台合规场景。

过去，商责研判的过程往往需要在多个系统间切换，疑难案件的平均耗时达 5–10 分钟。以消费者投诉“收到的商品与网页商品描述不符”为例，研判人员需要打开京东主站查看商品标题和商品详情页、登录到订单系统查看交易订单快照、在售后系统查看用户与商家的聊天记录、翻看用户上传的举证图片，甚至还要检查商家入驻提交的资质或其他业务材料。确认商责后，研判人员还需要补录处置单信息，完成面向商家的后续处置。

图 1：人工商责研判流程涉及多系统交互与证据补录

   商责研判的困难不只来自操作步骤多，更来自事实研判本身的复杂性：

• 研判信息是分散的。商品、订单、聊天、图片、资质、物流信息等信息分布在不同位置，不同信息之间存在互补依赖情况，任何单一信息都难以支撑完整判断。
• 结论需要完整有效的证据链支撑。一张图片中的标签，可能是原厂标签，也可能是他人留下的痕迹。识别到异常线索，不等于可以用于判责，需要把图文内容、商品类型、对话上下文和业务规则结合起来理解，确认关键事实之间能够相互印证，只有同时满足业务规则对证据来源、关联性、充分性和有效性的要求，才能形成可用于处置的商责结论。
• 规则与风险并存。不同品类、不同场景对应不同判断标准，而且规则会随着商品形态、业务模式和治理要求持续细化。误判可能让消费者得不到应有保障，也可能让商家承受不必要的处置。

因为每一笔案件都需要在效率、证据充分性与判定审慎性之间取得平衡，人力投入显然难以随案件量同步增长，AI 赋能商责研判的需求随之凸显。但 AI 的价值不只是“替人看材料”，更在于将分散的证据和经验转化为标准化、可解释的判断：系统从多源信息中提取关键事实，辅助给出更清楚的违规原因与整改依据；人工则可以将精力聚焦在高风险、疑难和需要最终裁决的案件上。

我们做的是什么 Agent？——面向真实案件的端到端研判 Agent

我们要构建的，并不是一个等待用户不断追问和引导的对话 Agent，也不只是一个根据数据生成报表与洞察的数据分析 Agent，而是一种面向真实业务案件的端到端研判 Agent。

一笔案件进入系统后，Agent 需要在既定的时效与资源预算内，围绕案件自主完成材料获取、事实核验、证据汇总和结果交付：证据充分时形成可进入后续流程的研判结论；证据不足、系统异常或风险较高时，则明确标记原因并转交人工，而不是以猜测替代结论。

图 2：智能商责研判 Agent：面向真实业务案件的端到端执行系统

   这种“全托管”的端到端执行方式，使案件研判 Agent 面临几类不同于普通 Agent 的系统约束：

• 既要规模化响应，也要控制时延与成本。系统需要稳定响应日常十万级案件，不能依赖无限轮次的推理或无节制的工具调用，必须在效果、时延与资源预算之间取得平衡。
• 既要理解多模态材料，也要形成完整有效的证据链。文本、图片、视频、PDF、订单和聊天记录等材料的证明力不同；识别到一个异常线索，并不等于它已经满足判责所需的关联性和充分性要求。
• 既要使用外部知识，也要遵守研判规则边界。商品规格术语、行业标准或品牌标识特征，可能成为判断事实的一部分；而“出售非全新商品应承担责任”这类宽泛规则，又必须落到具体案件的证据来源、上下文和例外情形中。
• 交付结果必须可执行、可追溯。系统交付的不能只是一段“我是/否”的自然语言回答，还应包含结论、关键事实与证据、判定依据，以及异常或转人工状态，为后续处置、人工复核和问题回放提供依据。

也正因为案件研判同时受到规模、证据、规则和风险边界的约束，我们的演进重点并不只是让模型“回答得更像专家”，而是逐步建立一套能够组织决策过程、沉淀业务经验并持续校准的 Agent 系统：从 Prompt 编排，到场景化 Agent 工作流与多 Agent 协同，再到案件反馈驱动的自进化闭环。

图 3：智能商责研判 Agent的三次演进

二、智能商责研判 1.0：快速打通——Prompt 编排式研判

智能商责研判Agent的第一步，是让 AI 能够在具体场景中参与一笔案件的判断。

在初始阶段，我们更像 Prompt 的“水管工”，通过prompt注入向模型说明任务、研判规则和输出方式。我们把业务规则、上下游数据和模型能力一段段接起来，前后处理代码负责数据清洗、模型调用串联、结果解析与回填。例如，研判商品“是否存在夸大宣传”的场景，会先将商品信息、投诉内容等材料整理为模型能够理解的输入，再把对应规则写入 Prompt，让模型结合证据给出结构化结果；系统随后解析结果、补齐业务字段并回传给上游流程。围绕不同场景，我们逐步沉淀了任务模板、过滤条件和终止节点，以减少不必要的模型调用。

图 4：智能商责研判1.0 - Prompt编排式研判

这套模式的价值很直接：它验证了 AI 不只能处理简单文本分类，也可以参与复杂商责案件的证据研判；在部分场景中，AI 已经能够规模化地承担重复性工作，并初步形成“业务规则 + 案例经验 + 模型能力”协同的研判方式。

但随着场景增加，这种快速组合的方式也出现了新的挑战：Prompt、规则和业务代码逐渐交织；一个场景的改动可能影响多个处理步骤；出现偏差时，团队常常只能看到“结果不对”，却难以快速定位问题发生在哪一步。更重要的是，服务调用失败、证据不足和非商责等不同状态，若没有清晰边界，容易被混在同一个结果里。

智能商责1.0 解决的是“AI 能不能参与研判”；下一步要解决的，是“AI 的判断过程能不能被看见、被解释、被约束”。

三、智能商责研判 2.0：过程可控——场景化 Agent 工作流与多Agent协同

智能商责研判 2.0 的重点，从把能力“接起来”，转向把决策过程“组织起来”：让 Agent 负责理解和核验事实，让系统负责安排任务、约束边界、汇总证据并输出结论。

但是，商责研判中的规则、证据口径和例外处理，来自平台在消费者权益、商家经营与平台治理之间长期积累的实践，并不是通用大模型天然具备的知识。如果这些经验仍停留在口头沟通、零散文档或历史案例中，每新增一个场景，业务与技术团队就需要反复解释、确认和翻译，场景覆盖便难以规模化。所以要组织决策过程，首先要解决的基础问题是：业务人员长期积累的研判经验，如何被准确表达、充分澄清并快速复用到AI研判中？

2.1 从业务经验到可执行知识：让新场景覆盖可复制

我们不直接从一段自然语言规则开始编写 Prompt 或工作流代码，而是先引导业务人员将研判过程表达为流程图。每一个节点对应待核验的关键事实，每一条分支对应一种业务判断、后续动作或结束条件。

以“出售非全新商品”为例，业务人员会先将原本依赖经验完成的判断过程梳理出来：哪些材料应当优先查看，标题披露、商家回应和用户举证分别能够说明什么，面对运输痕迹、出厂检测等解释时又需要满足哪些条件。这样，原本隐含在日常研判中的判断顺序、证据优先级和例外处理，便能够被显式表达为一张可讨论的流程图。

但流程图还不能直接运行。它能够说明“需要判断什么”，却未必天然回答“应当如何判断”。例如，什么表述才算对“非全新”的有效披露？“退款”“换货”等处置性表达能否视为商家承认？划痕、灰尘或包装破损在什么条件下能够成为有效证据？这些判断口径仍需要进一步澄清。

为此，我们基于流程图识别其中的判定节点、分支条件和所需输入，借助 AI 生成待确认的问题清单，再由业务人员逐项确认。确认后的结果会沉淀为场景研判SOP，其中明确判断条件、证据要求、例外处理、异常边界和输入输出约束，并为后续技术实现提供统一依据。AI 在这里并不替业务凭空创造规则，而是帮助将业务经验结构化、将隐含分歧显式化，并将确认后的口径整理为可执行规范。

图 5：从业务经验到可执行知识

这样，新增场景的覆盖便从“反复解释规则、定制开发代码”，逐步转变为“梳理流程、澄清口径、生成并验证实现”的标准化协作过程。当场景研判SOP、证据口径和例外处理被结构化后，技术实现便不再需要从零开始编排。我们会根据案件的判断路径是否稳定、证据空间是否开放，选择两种相互补充的实现方式：

• 1、场景化 Agent 工作流：适用于判断路径相对清晰的案件，将稳定经验沉淀为可执行、可回放的流程；
• 2、多 Agent 协同研判：适用于证据组合更开放的案件，由主 Agent 根据当前证据缺口动态派生任务，补足关键事实。

图 6：工作流与多 Agent 协同的组织边界

2.2 场景化工作流：把稳定经验固化为可执行的研判路径

对于研判SOP 中核验顺序、提前收敛条件和异常边界都能够在设计阶段明确的部分，我们采用场景化 Agent 工作流，将稳定经验转化为可执行、可回放的研判路径。

以“出售非全新商品”为例，场景 SOP 已经明确了核心判断顺序：先核验标题是否有效披露“非全新”信息；未有效披露时，再判断商家是否明确承认商品为展示机、翻新机或已被使用；只有在无法直接收敛的情况下，才继续核验用户举证是否规范，以及图片、视频等材料能否证明商品确实存在非全新问题。对这类案件而言，事实核验项虽然不止一个，但其先后关系和业务分支相对清晰。

我们在LangGraph 基础上，将场景 SOP 中的案件状态、事实核验节点、路由规则、异常处理和结果契约落实为一张可运行的图：标题、聊天、图片等 Agent 节点分别负责核验具体事实；Langraph图运行时则负责决定节点的执行顺序、何时可以提前收敛，以及出现异常后应继续、终止还是转交人工。

与 1.0 阶段将调用顺序、终止条件和异常分支分散在 Prompt 与业务代码中的方式相比，场景化工作流将这些决策逻辑显式表达为图中的节点与条件边。这样，稳定经验不再依赖隐式代码串联，而成为路径清晰、状态明确、可回放检查的运行过程。

图 7：“出售非全新商品”场景中的Agent工作流

2.3 多 Agent 协同：面对开放证据空间，按需补足关键事实

但场景 SOP 被结构化，并不意味着所有案件都应被写成一条固定流程。

以“商品信息与实物不符”场景为例，消费者可能只留下一句“收到的商品和页面不一样”。这句话背后的事实缺口却可能完全不同：投诉颜色、款式或花纹不一致时，需要比对商品宣传图与消费者举证图；投诉材质不符时，需要核验页面承诺、实物标签和相关举证；投诉少发充电器、配件时，则需要核对商品配置说明、订单信息及商家沟通记录。还有些案件中，商家已经在聊天中明确承认漏发并表示补发，案件可以直接收敛，无须继续进行图片比对。

这些案件并非没有规则。相反，沉淀的场景研判 SOP 仍然规定了不同问题需要核验哪些事实、哪些证据可被采信、什么情况下可以形成结论。不同之处在于：案件进入系统前，很难预先知道它究竟缺少哪一项关键事实，也不适合将所有可能的核验动作都写进每一笔案件的固定路径。如果预先穷举所有分支，一条工作流会不断叠加“如果……则……”的判断：每笔案件可能经历大量无关核验，带来无效调用；随着投诉类型、证据来源和例外情况增加，流程也会越来越长、越来越难维护。

因此，对于证据组合更开放、研判路径难以经济地预定义的场景，我们采用多 Agent 协同研判。它与工作流的差别不在于是否使用了多个 Agent，而在于任务编排发生的时间：场景化工作流在设计时预先写明路径；多 Agent 协同则在运行时，根据当前案件已经确认的事实和仍待补足的证据，决定下一步需要派发哪些任务。

我们基于 Claude Agent SDK，并围绕商责案件构建了专属的 Agent Harness。Claude Agent SDK 提供持续会话、任务派发、专业 Agent 定义、工具与 MCP 接入、执行事件回传等基础能力；Harness 则进一步补齐了面向案件研判的角色职责、上下文组织、工具权限、任务状态、结构化结果和执行留痕等约束。

案件进入系统后，主 Agent 不会按固定顺序调用所有角色，而是持续判断：哪些事实已经确认，哪些关键证据仍然缺失，哪些任务可以并发，哪些任务必须等待前序结论。随后，它按需派发相应的专业 Agent；子 Agent 返回新的事实后，主 Agent 再结合场景 SOP 决定继续补证、发起新的核验，还是收敛为最终结论。

例如，聊天记录已经显示商家明确承认漏发配件时，主 Agent 可以直接收敛，无须再派发图文比对任务；而当聊天内容仅表明消费者反馈“货不对版”、但尚未说明具体差异时，主 Agent 则可能先派发聊天核验任务，再根据返回结果决定需要核对材质、配件，还是商品宣传图与实物图的差异。

图 8：“商品信息与实物不符”场景中的多Agent协同研判

多 Agent 协同并不意味着让一个通用 Agent 无边界地自由规划。场景研判SOP 仍然定义了判断依据和业务边界，专业角色仍然具有明确职责，工具调用仍然受到权限约束，最终结果也必须以统一的结构化接口交付。证据不足、任务异常或风险较高时，系统应明确输出异常或转人工状态，而不能以猜测替代结论。同时，任务派发、工具调用、子 Agent 返回和异常状态都会被记录下来。这些执行轨迹既支持日常问题排查，也为后续的案件回放、BadCase 归因和系统持续校准提供了基础。

通过这两种互补的执行方式，我们能够让稳定经验以工作流的形式高效运行，也能让开放场景在规则边界内按需调度专业能力：前者追求路径确定下的稳定与效率，后者解决证据组合变化下的灵活取证与事实补全。

四、智能商责研判 3.0：持续校准——案件反馈驱动的受控自进化Agent系统

场景化工作流和多 Agent 协同，让系统能够以更清晰、更可控的方式完成一次案件研判；但“能够稳定执行”并不意味着系统从此不需要变化。

随着业务发展，商品形态和违规手法会持续变化，平台规则也会不断细化，人工复核中还会出现新的边界案例。即使工作流本身没有问题，规则边界、模型理解、输入质量或外部服务异常，仍可能导致研判偏差。如果每次改进都依赖人工逐条翻查案例、凭经验调整 Prompt 或流程，系统在规模化场景下就难以持续提升。

因此，我们进一步探索让系统具备持续校准能力：定位问题出现在哪个环节，生成候选改进方案，并在历史数据中验证其效果，再由人决定是否用于真实业务。

本文所说的“自进化”，并不是让 Agent 自动修改线上规则或自行发布生产变更，而是让系统自动完成问题发现、归因分析和候选验证；生产规则、工作流策略和高风险裁决的最终决定权，始终保留在人手中。

图 9：智能商责研判3.0 - 案件反馈驱动的受控自进化闭环

第一步：案件留痕——留下可复盘的执行轨迹

系统为每一次执行记录了经过脱敏处理的输入摘要、节点路径、Agent派生、Agent 输出、耗时、异常和最终结果，形成执行轨迹（Trace）。记录遵循最小必要原则，只保留复盘需要的字段。

这样，一笔案件不再只有“商责”或“非商责”两个结果。运营、产研可以回看：系统经过了哪些步骤？哪一类证据触发了判断？为什么提前结束？是否出现了工具或 Agent 调用异常？当人工复核与系统结论不一致时，差异又出现在证据读取、事实核验，还是流程路由环节？

第二步：Badcase归因——从“结果错了”定位到“哪里需要改”

当系统结论与人工标注或复核结果不一致时，我们将这类案件视为 BadCase。BadCase 不只是一个错误案例列表，而是系统改进的起点。

归因 Agent 不重新裁决案件对错，而是基于真实的执行轨迹分析偏差来源：是既有规则边界不清，还是缺少覆盖某类新情况的规则；是输入或证据质量不足，还是节点调用异常；又或者是工作流路由、任务规划和依赖处理需要调整。

为了避免归因过程脱离真实业务，系统只允许归因结果引用案件实际执行过的节点、对应的规则和 Prompt。随后，系统会按节点、规则和问题类型聚合 BadCase，形成候选的优化方向与最小修复指引，供业务、运营和产研共同评审。

图 10：从案件差异到最小修复指引的 BadCase 归因过程

第三步：离线验证——让候选改进先经历历史中验证

候选建议并不等于生产变更。对于拟调整的 Prompt、规则或节点策略，系统会基于历史执行轨迹进行离线回放：在相同或可比的历史输入上运行候选版本，对比新旧输出和变化样本，观察哪些案件从错变对、哪些案件可能从对变错，并生成差异报告。新旧工作流迁移时，还可以在不影响正式结论的前提下进行影子比对，将发生差异的样本优先交给业务人员复核。

图 11：进化前后的差异报告

这一步的关键在于把“自进化并生成候选方案”与“批准生产变更”严格分开。前者追求问题发现和分析效率；后者必须服从业务规则、安全要求和人工责任边界。只有经过历史回放、差异审查和人工准入的方案，才有资格进入后续灰度或上线流程；不满足条件的方案则继续留在离线迭代中。

从这个意义上说，生产环境中可靠的自进化不是让系统在无人注视下改变自己，而是让每一次可能的改变都能够被发现、被解释、被验证，并由人决定它是否值得进入生产环境。

五、业务成效——从场景覆盖到规模化处置

图 12：进化前后的差异报告

截至 2026 年 8 月 01日，智能商责研判 Agent 已累计覆盖 15 个风控合规二级场景、30 个三级场景，场景化工作流AI 结论采纳率达90%， 多Agent协同研判的结论采纳率达70%-80%。其中：

• 商品信息违规—信息与实物不符场景：周均研判单量从 2,000 单提升至 6,000 单，提效 3 倍；
• 品质缺陷—非全新场景：周均研判单量从 1,000 单提升至 1.5 万单，提效 15 倍；
• 履约违规—不当延迟发货报备场景：全流程无人化研判-处置，周均自动研判 1,000 单、自动处置 300 单；
• 本地生活—食品安全场景：全流程无人化研判-处置，周均自动研判 21 万单、自动处置 5.6 万单。

这些数据验证的，不只是案件处理规模的提升，更是智能商责研判从单点试用走向系统化运行的能力：业务规则能够被沉淀，证据核验能够被组织，复杂案件能够按需调度，运行中的偏差也能够被持续发现、分析和校准。

商责研判的智能化，不是把规则交给模型后就结束了。从 Prompt 编排，到场景化 Agent 工作流与多 Agent 协同，再到案件反馈驱动的自进化闭环，演进的并不只是自动化程度，更是平台将规则、案例和人工经验逐步沉淀为可靠决策系统的能力。对于需要审慎对待的业务决策而言，可靠的自进化并不是让系统自行改变，而是让每一次改进都有迹可循、有据可验、有人准入。这也是智能商责研判能够从真实业务中持续生长的基础。