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

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

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

---

一、Agent 要解决的核心问题

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

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

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

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

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

1. 1. 低风险操作自动执行：库存低于安全线自动生成补货单、非核心商品 ±5% 内自动调价
2. 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 层：

• • 权限校验
• • 阈值校验（不超过 ±5%、毛利率不低于 25%）
• • 风险评级 → 低/中/高

低风险自动执行，中风险推批，高风险跳过并告警。

Step 5 — 执行 + 记录

执行完成后，把本次决策的完整记录（触发条件、知识检索结果、LLM 推理过程、最终动作、执行结果）写入向量知识库，作为下一次决策的历史案例。

这就是 Agent 能够自我进化的机制——每次决策都在丰富知识库。

---

四、关键架构决策

为什么不用纯规则引擎？

你可能想问：库存预警、调价建议这些，写规则不是更简单吗？

是的。纯规则能覆盖 80% 的常规场景。但剩下 20% 的模糊场景——“A 商品销量下滑是竞品降价还是季节性因素？”“这个异常是孤例还是系统性问题？”——规则很难写周全。

我们的做法是规则 + 知识 + LLM 三层叠加：

• • 规则引擎处理常规触发（快、稳、便宜）
• • 知识库提供业务上下文（让 LLM 不盲目推理）
• • LLM 处理模糊判断和综合分析（灵活、智能）

向量库 vs 结构化查询，怎么选？

一个容易犯的错误：所有知识都想塞进向量库。

但我们偏向把知识分成两类：

• • 事实型知识（价格、库存、类目）→ 结构化存储，SQL 查询
• • 经验型知识（历史案例、业务判断、市场分析）→ 向量库，语义检索

原则是：能确定回答的就不用语义检索。 语义检索只在需要"模糊匹配"和"综合判断"时启用。这既降低了延迟，也减少了检索噪音。

审批超时怎么处理？

推给人审批的流程有一个容易忽略的问题：人没看到怎么办？

设计原则：默认驳回比默认执行更安全。

• • 24 小时内无人审批 → 自动驳回
• • Agent 生成执行失败记录，下次决策时会作为参考
• • 连续驳回 3 次以上的建议类型 → Agent 主动降低该类型建议的频率

---

五、MVP 落地路径

如果从零开始，不建议一上来就搭完整系统。三步走：

Phase 1 — 数据基建 + 规则告警

先把数据通路建好，跑固定的 SQL 查询生成销量日报和库存预警表。配置关键阈值规则。这一步能让运营团队"不打开后台也能知道发生了什么"。

Phase 2 — 知识库建设

收集历史运营决策记录、SOP 文档、定价规则，构建结构化知识库和向量知识库。这个阶段 Agent 还不介入，知识库先让人用——运营人员可以通过搜索历史案例来做决策。

Phase 3 — Agent 接入

在前面两步的基础上加入 Agent 循环。先用只建议不执行的模式（纯分析型），团队信任建立后再放开自动执行。

每一步都有独立价值，不需要等到全部做完才能上线。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】