从零设计一个智能商品管理 Agent：架构、知识库与决策流

关注

原创最新推荐文章于 2026-08-11 14:50:35 发布 249 阅读 AI 写同款· GEO 优化 ›

基于Dify Agent构建智能客服：攻克知识库查询、多轮对话、安全鉴权与人机协同基于Dify Agent构建智能客服，并将知识库等核心能力工具化，再通过Chatflow进行流程编排，是一种强大且灵活的策略。它不仅解决了当前AI客服面临的诸多核心挑战，也为未来的功能扩展和智能化升级打下了坚实的基础。希望本文能为您在构建高效、智能的AI客服系统之路上提供有益的参考！dify实验室基于LLMOps平台-Dify的一站式学习平台。包含不限于：Dify工作流案例、DSL文件分享、模型接入、Dify交流讨论等各类资源分享。关注我，获取Dify相关资源（DSL、token、交流群等）。阅读详情

最近在做智能商品管理 Agent——帮电商运营团队做销量预测、库存预警、定价优化，低风险操作自动执行，高风险推给人确认。目标是 7×24 小时的 AI 运营助理。

但这篇文章不打算只讲架构。我想重点聊一个在设计过程中最关键也最容易低估的问题：知识库。

因为在实际做的时候你会发现，Agent 能不能做出靠谱的决策，90% 不取决于模型多强，而取决于它有没有足够好、足够结构化的知识可以查。

一、Agent 要解决的核心问题

在动任何架构之前，先把问题定义清楚。

电商运营每天要处理的信息非常多：哪些 SKU 快断货了？哪些商品需要调价？下周销量趋势怎么样？

这些问题不是"有没有数据"——数据都在，但需要人去翻、去算、去判断。几千个 SKU 靠人肉一个个看根本不现实。

所以 Agent 的定位很明确：自动完成"看数据 → 查知识 → 做分析 → 出建议 → 执行动作"这个闭环。

但不是所有动作都应该让 Agent 自己执行。两条基本原则：

1. 低风险操作自动执行：库存低于安全线自动生成补货单、非核心商品 ±5% 内自动调价
2. 高风险操作推给人确认：大促商品调价、批量下架、供应商切换

二、知识库：Agent 决策的底层支撑

这是很多 AI Agent 设计里最容易被忽略的部分。

很多人把 Agent 想象成"LLM + 工具调用"就够了——模型够强，什么都能推理出来。但在电商运营这个场景里，你想让 Agent 做出合理的定价决策，它需要知道：

这款商品是引流款还是利润款？（商品分层知识）
去年的这个时候做过什么促销？效果如何？（历史决策知识）
这个品类的毛利率底线是多少？（业务规则知识）
这批货是临期清仓还是正常周转？（商品状态知识）

这些知识 LLM 的预训练数据里没有。你必须在推理时通过知识库喂给它。

2.1 三种知识形态

我们在系统中设计了三种互补的知识库，覆盖不同的查询场景。

① 结构化知识库（关系型数据库）

商品的主数据——SKU、类目、供应商、规格参数、进价、售价、库存——这些天然是结构化数据，用传统关系型数据库存储最合适。

Agent 通过 SQL 查询获取精确信息：“查询 A 类商品中库存低于安全水位的前 20 个 SKU”。

适用场景：精确查询、聚合统计、批量筛选。这部分权重约占知识查询的 60%。

② 向量知识库（Embedding + 语义检索）

非结构化的业务知识和历史经验——运营 SOP、历史决策记录、促销复盘报告、商品描述——用 Embedding 存入向量库，Agent 在做分析时通过语义相似度检索。

举个例子，当 Agent 要判断"某款羽绒服是否应该降价"，它会去向量库里检索：

检索条件：“冬季商品降价决策历史案例”
返回结果：去年 12 月同品类商品的调价记录、当时的决策逻辑、最终效果

这比让 LLM 凭空推理要靠谱得多。

适用场景：语义搜索、案例匹配、经验查询。约占知识查询的 30%。

③ 规则知识库（可执行的业务规则）

运营团队积累的业务规则——定价规则、促销规则、上下架规则、合规规则。这部分最特殊：它既是知识，也是约束。

在我们的设计里，规则知识库有两种存在形式：

LLM 可读的规则文档：Agent 在推理时参考。比如"核心商品调价超过 3% 需要运营总监审批"。
Guardrail 层可执行的规则代码：Agent 执行前，Guardrail 层用硬规则做二次校验。同一个规则，Agent 用来"参考"，Guardrail 用来"强制执行"。

这种双重机制的好处是：Agent 的决策有业务上下文，同时又有不可绕过的安全底线。

2.2 RAG Pipeline：Agent 怎么做知识检索

有了知识库之后，关键问题是：Agent 在什么时候、用什么策略去查知识？

我们设计了三级检索策略，按需触发：

Level 1 — 精确查询（每次必走）
  查结构化数据：当前库存、销量、价格
  耗时：毫秒级

Level 2 — 规则匹配（场景触发）
  根据场景查规则库
  比如触发调价决策时 → 查调价规则
  耗时：毫秒级

Level 3 — 语义检索（复杂决策时触发）
  需要综合判断时查向量库
  比如异常归因、趋势分析、综合决策
  耗时：百毫秒级

关键设计原则：能不查向量库就不查，先走精确查询和规则匹配。

原因是：向量检索有召回率问题，可能查到不相关的内容，反而污染 LLM 的推理上下文。结构化查询和规则匹配是确定性的，查到就是对的，这能让大多数常规决策不需要依赖"模糊的知识"。

2.3 知识库的维护与更新

知识库最怕的不是没有，而是过时。

我们设计了自动更新机制：

结构化数据：实时同步（CDC），订单/库存变更后秒级更新
向量知识库：增量更新。新产生的高质量决策记录 → 自动 Embedding → 写入向量库
规则知识库：半自动更新。Agent 发现规则冲突或缺失时，生成修订建议，人确认后生效

其中第二条最有意思。Agent 每一次做的决策，只要最终被人确认或修改了，就是一次高质量的训练样本。自动回流到向量库，下一次遇到类似的场景，Agent 就有了参考案例。Agent 越用越聪明。

三、整体架构：三层一库

有了知识库的支撑，完整的架构就清晰了。

┌─────────────────────────────────────────────────┐
│                  触达层                            │
│  Dashboard + 企微/钉钉/飞书机器人                  │
└──────────────────────┬──────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────┐
│              Agent 核心循环                       │
│                                                  │
│  感知 ──→ 查知识 ──→ 推理 ──→ Guardrail ──→ 执行 │
│  (数据)   (三级检索)  (LLM)   (规则校验)   (动作)  │
│                    │              │               │
│                    ▼              ▼               │
│              知识库层        Guardrail 规则库       │
└──────────────────────┬──────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────┐
│                  知识库层                         │
│  ┌──────────┐ ┌──────────┐ ┌───────────────┐    │
│  │ 结构化库  │ │ 向量知识库│ │ 规则知识库    │    │
│  │ (MySQL/  │ │ (Milvus/ │ │ (规则引擎 +   │    │
│  │  ClickH.)│ │  PG Vec) │ │  规则文档)    │    │
│  └──────────┘ └──────────┘ └───────────────┘    │
│                   │                              │
│              ┌────▼────┐                        │
│              │ 预测模型  │                       │
│              │ (销量/    │                       │
│              │  需求)    │                       │
│              └─────────┘                        │
└──────────────────────────────────────────────────┘

核心循环比之前多了一个环节：查知识。这是 Agent 每次做决策的必经步骤。

核心循环详解

Step 1 — 感知

定时（每小时轮询）或事件驱动（库存低于阈值、订单量突增），拉取当前需要关注的上下文。

不是所有数据都拉。分级处理——A 类商品（高价值 TOP 20%）逐个分析，B/C 类商品聚合处理。

Step 2 — 查知识

根据触发场景，执行三级检索策略：

必查：结构化数据（当前库存、销量）
场景触发：相关业务规则
复杂决策：向量库语义检索历史案例

Step 3 — 推理

将感知数据 + 检索到的知识 + 系统指令一起拼成 Prompt，交给 LLM。

Prompt 结构示例：

你是一个电商运营助手。
当前任务：判断 A 类商品 SKU-10086 是否需要调价。

【实时数据】
  7日销量：1200 件，环比下降 15%
  当前库存：850 件
  当前售价：¥89.9
  进货成本：¥52.3

【业务规则】
  核心商品调价 ±3% 内自动执行
  超过 ±3% 需运营经理审批
  毛利率不得低于 25%

【历史案例】
  去年 6 月同品类商品 SKU-2034 降价 5%
  效果：销量提升 22%，但毛利率下降 3%
  归因：季节性需求波动，非竞争因素

【指令】
  请分析是否需要调价。
  如果需要，给出建议价格、调价幅度、理由和风险评级。

Step 4 — Guardrail

LLM 输出决策动作后，进入 Guardrail 层：