领域知识驱动的决策 Agent 平台

领域知识驱动的 Agent 需要结合可信知识与当前状态，判断能够做什么、应该做什么，说明决策依据，并在执行后检查结果。

本文讨论知识工程、领域本体、状态建模、动作契约、专业模型、Agent 决策、执行控制和闭环评估，并给出最小实现与阶段验收标准。

0. 先给出结论

一套面向行业的决策智能平台，可以围绕以下环节组织：

领域知识（Knowledge）→ 状态建模（State）→ 行动建模（Action）→ 决策求解（Decision）→ 安全执行（Execution）→ 反馈评估（Feedback）。

它需要同时解决六个问题：

1. 知识从哪来？ 自动收集、解析、提取、融合，并绑定原始证据。
2. 知识如何组织？ 用领域本体定义概念、关系与约束，让知识具备结构而非只是文本。
3. 当前发生了什么？ 从业务数据和观测中形成带时间戳、不确定性说明的状态。
4. 系统能做什么？ 把动作定义为有输入、前置条件、预期效果、权限和副作用的可执行契约。
5. 应该做什么？ 让 LLM 负责理解和编排，让规则、预测、仿真和优化工具承担可校验的专业计算。
6. 做得对不对？ 记录决策依据与结果，分别修正知识、模型和策略。

技术设计的优先级是：具体决策任务 → 状态与动作契约 → 可靠性评估 → 自动化知识建设 → 大规模 Agent 自治。 从可检验的任务出发，确定需要建设哪些知识。

1. 先分清：知识问答系统与决策智能系统

以“是否需要补货”为例，知识问答系统与决策系统的处理目标不同。

传统知识问答系统可能回答：

补货点通常由需求量、采购提前期和安全库存决定。

这是对补货知识的解释。要决定这次是否补货，还需要结合店里的实际情况。

决策系统则需要：

• 查询牛奶当前库存、在途订单、销量和采购条件；
• 检查这些数据是否新鲜、完整、可信；
• 计算是否触发补货，生成可行的补货数量；
• 检查预算、仓储容量、保质期和采购权限；
• 给出依据、备选方案和不确定性；
• 获得必要审批后下单，并根据到货和后续销售评价决策。

决策系统需要依据当前状态，在约束下选择并验证行动。

本文讨论的重点是决策支持系统和决策 Agent。

2. 统一抽象：知识、状态、动作、约束和目标

下面的补货示例及计算见文末附录。

可以将一个动态决策问题表示为：

这里的 $K$ 是为平台工程额外引入的知识组件，用来表示领域知识。

2.1 状态是否完全可观测？

对零售补货来说，系统看到的“日需求量”只是过去销量和预测，不一定代表真实潜在需求——缺货时，未能发生的销量不会出现在销售记录里。因此状态可能部分可观测。

一般情况下可以维持一个信念状态：

但 MVP 不必一开始实现信念传播。先用结构化状态 + 时间戳 + 数据质量标记即可；在不确定性确实影响决策时，再引入概率预测、贝叶斯滤波或 POMDP。

2.2 决策不应默认交给 LLM

一般的决策问题可以写成：

也可以写成最小化成本。求解器的选择应由任务性质决定：

• 条件明确、逻辑简单：规则 / 决策表；
• 有资源、容量、排班等约束：约束优化 / 整数规划；
• 需要预测行动后果：统计预测 / 仿真；
• 多时刻连续决策且存在随机性：MDP / POMDP / MPC 等；
• 输入是非结构化自然语言：LLM 负责理解、提议、编排和解释。

LLM 作为可替换的智能组件，与可验证的规则和专业模型配合。

3. 系统总体架构

平台可以分为知识平面、决策平面、模型平面、治理平面，底层共用数据接入和存储能力。

数据接入连接文档、规章、库存、销量和订单，为四个平面提供输入：

• 知识平面：解析资料，抽取知识，核验证据、处理冲突，并提供本体、知识库与检索。
• 决策平面：接收任务，构建状态，由 Agent 或路由器生成候选动作，再检查业务约束。
• 模型平面：提供规则、优化器、预测模型和仿真工具，供决策过程调用。
• 治理平面：贯穿知识和决策过程，负责权限、审计、版本追踪、离线评测与回放。

通过检查的方案进入审批与受控执行；结果写入事件记录，更新状态，并为知识修订提供线索。

各模块的职责如下：

核心原则：静态知识、动态状态、专业模型和执行权限必须分开管理。

4. 知识工程：从文档到可信、可更新的知识资产

4.1 抽取可复用的知识类型

至少区分以下几类：

一篇文档可以同时包含这些内容，需要分别提取并建立联系。

4.2 推荐的知识生产流水线

1. 定义收集范围：先列决策任务需要回答的核心问题，不盲目全网抓取。
2. 来源登记：记录文件、发布者、时间、许可、版本及访问权限。
3. 结构化解析：保留标题、表格、段落、公式及页码/原文定位。
4. 知识声明抽取：提取概念、事实、规则、条件、适用范围与证据。
5. 本体映射与实体对齐：统一同义词、别名、单位、实体标识。
6. 冲突检测：比较相同主体/属性、不同时间和条件下的声明。
7. 审核入库：重要规则、动作约束、专业模型需要明确验证流程。
8. 增量更新：新来源出现后生成差异、保留历史版本，必要时重新评估受影响的决策。

4.3 知识的基本单元：Claim + Evidence

建议为“知识声明”分配独立 ID，并记录三元组之外的条件与证据：

claim_id: supplier_a_lead_time
subject: supplier_a
predicate: normal_lead_time
object:
  value: 3
  unit: day
conditions:
  - regular_purchase_order
source:
  document_id: contract_a_v2
  locator: section_4
valid_time:
  from: "2026-01-01"
  to: null
verification:
  status: approved    # extracted / pending / approved / rejected
  reviewer: domain_expert

还要记录抽取程序/模型版本、原文片段位置、来源权属和更新时间。正式系统中，approved 由受授权的校验流程授予。

重点解决三类问题：

• 同义：到货周期、采购提前期、lead time 是否指同一概念？
• 冲突：合同承诺 3 天与历史平均 5 天，可能是“合同值 vs 观测值”，未必谁错；不能简单以新覆盖旧。
• 条件：“3 天” 可能只适用于常规订单，不适用于节假日或特殊商品。

4.4 如何验证知识质量？

可以结合以下信息验证知识：

• 来源可信度、是否为一手资料；
• 原文是否真实支持该声明；
• 时间与适用条件是否匹配；
• 不同来源是否独立；
• 类型、单位和逻辑约束是否成立；
• 高风险知识是否完成人工审核。

可用指标包括：事实抽取 Precision/Recall、证据支持率、实体对齐准确率、冲突检出率、知识过期率。

知识库应保存知识的证据、条件和版本。

5. 领域本体：定义领域中的对象与关系

在补货示例中，可以先定义如下对象：

• Product：商品；
• Supplier：供应商；
• Store：门店；
• PurchaseOrder：采购订单；
• InventoryObservation：库存观测；
• PurchasePolicy：采购策略。

典型关系包括：Product supplied_by Supplier、Store stocks Product、PurchaseOrder purchases Product。

本体定义这些概念是什么、如何关联、符合什么语义约束。实时库存由业务状态服务根据业务数据库生成。

建议从实用的轻量 Schema 开始：

schema_version: "1.0"
domain: retail_inventory
entities:
  Product:
    key: product_id
    properties:
      name: string
      unit: string
  Supplier:
    key: supplier_id
relations:
  supplied_by:
    source: Product
    target: Supplier
state_types:
  InventoryState:
    fields:
      on_hand: nonnegative_integer
      on_order: nonnegative_integer
      backorders: nonnegative_integer
      daily_demand: nonnegative_number
      observed_at: datetime

当语义推理、复杂约束和图查询成为实际需求时，可以引入 OWL、SHACL 或专用图数据库。

本体定义概念、关系及其约束；知识图谱可以组织这些定义以及具体事实。状态快照描述某时刻的世界；动作与状态转移模型描述可采取的行为及其后果。

6. 动作契约：从“能调用函数”到“理解行动的条件与后果”

工具调用通常只有函数名和参数，例如 create_purchase_order(product_id, quantity)。但一个可靠 Agent 还需要知道：

• 什么条件下允许下单？
• 采购的预算上限是多少？
• 下单会产生真实费用吗？
• 请求重复发送会不会生成两笔订单？
• 订单失败后怎样确认、补偿或回滚？
• 什么信息能证明动作成功？

因此，动作是有契约的领域对象，可以抽象为：

其中 $I$ 是输入、$P$ 是前置条件、$E$ 是效果模型、$C$ 是约束、$\Delta t$ 是时间/资源成本、$U$ 是效果不确定性。工程实现还需补充权限、幂等和审计字段。

action_id: place_purchase_order
version: "1.0"
description: 创建采购订单
input_schema:
  product_id: string
  supplier_id: string
  quantity: positive_integer
preconditions:
  - product_exists
  - supplier_is_active
  - stock_data_is_fresh
constraints:
  - within_budget
  - within_capacity
  - purchaser_authorized
predicted_effect:
  model_id: purchase_order_effect_model
execution:
  mode: approval_required
  tool_id: purchasing_api.create_order
  side_effect: external_write
  idempotency_required: true
verification:
  - purchase_order_id_returned
  - purchase_order_status_confirmed

这是一份声明式配置示例，其中 within_budget、purchase_order_effect_model 等名称必须在受信任的规则/模型注册中心找到可执行实现，不能把 LLM 输出直接作为脚本执行。

应区分两类动作：

• 信息动作：查询库存、检索合同、预测销量；主要改变系统掌握的信息。
• 环境动作：下采购单、修改价格、取消订单；会改变外部业务世界。

环境动作采用更严格的确认、授权、幂等与审计机制；自动化初期只做建议，不真正写入外部系统。

7. 决策引擎：让 LLM 与确定性计算各司其职

一个实际任务可以沿以下顺序处理：

1. 收到问题，识别目标和必要数据，获取并校验状态。
2. 检索相关知识与可用动作，生成候选方案。
3. 根据任务选择规则引擎、优化求解器或预测与仿真工具。
4. 统一检查约束和证据；信息不足时补充信息或交由人工复核。
5. 输出建议，按权限进入审批和执行，最后记录结果。

7.1 LLM 负责什么？

适合由 LLM 处理的工作：

• 自然语言需求理解、任务分解；
• 识别可能缺失的数据；
• 从工具注册表中选择合适工具；
• 从文档中归纳候选知识声明；
• 为结构化决策记录生成可读解释。

不应该无条件交给 LLM 的工作：

• 任意写入数据库或执行外部交易；
• 在缺乏校验的情况下决定安全约束；
• 代替严格的财务、统计、物理或优化计算；
• 自行把未核验知识升级为可执行规则；
• 仅凭自然语言确认动作执行成功。

7.2 模型注册中心应该记录什么？

不论是简单的补货公式、需求预测网络还是整数规划，都应该用统一元数据描述：

model_id: reorder_point_rule
version: "1.0"
type: deterministic_rule
input_schema: InventoryState
output_schema: ReplenishmentProposal
assumptions:
  - demand_estimate_is_representative
  - lead_time_is_known
applicability:
  - single_product
validation:
  test_suite: inventory_rule_v1
  status: approved
executor: inventory_models.reorder_point

这样，决策运行时可以检查模型是否适用，而不只是看到一个名字就调用。

7.3 一个可运行的最小规则引擎

下面代码只实现建议生成，不包含文档解析、LLM，也不会真实下单。它的价值在于先建立可测试的决策闭环。

from dataclasses import dataclass
from math import ceil


@dataclass(frozen=True)
class InventoryState:
    on_hand: int
    on_order: int
    backorders: int
    daily_demand: float
    lead_days: int
    safety_stock: int
    target_days: int
    unit_cost: int
    budget: int
    capacity: int
    data_is_fresh: bool


def propose_replenishment(s: InventoryState) -> dict:
    # 1. 数据质量是决策前提：过期数据不可直接驱动采购。
    if not s.data_is_fresh:
        return {"status": "needs_review", "reason": "stale_inventory_data"}

    # 2. 基础合法性校验：不能将无效输入送入公式。
    values = [s.on_hand, s.on_order, s.backorders,
              s.daily_demand, s.lead_days, s.safety_stock,
              s.target_days, s.budget, s.capacity]
    if any(v < 0 for v in values) or s.unit_cost <= 0:
        return {"status": "needs_review", "reason": "invalid_input"}
    if s.target_days < s.lead_days:
        return {"status": "needs_review", "reason": "invalid_policy_horizon"}

    # 3. 计算库存位置、补货点和目标库存。
    inventory_position = s.on_hand + s.on_order - s.backorders
    reorder_point = ceil(s.daily_demand * s.lead_days + s.safety_stock)
    target_level = ceil(s.daily_demand * s.target_days + s.safety_stock)

    # 4. 首先使用明确可解释的基线规则。
    desired = max(0, target_level - inventory_position) \
        if inventory_position <= reorder_point else 0
    if desired == 0:
        return {"status": "no_action", "quantity": 0}

    # 5. 保守地校验预算和容量（暂不考虑在途期间的消耗）。
    budget_limit = s.budget // s.unit_cost
    capacity_limit = max(0, s.capacity - s.on_hand - s.on_order)
    feasible = min(desired, budget_limit, capacity_limit)

    # 6. 无法达到目标时必须明确标注，不能暗中修改目标。
    return {
        "status": "requires_approval" if feasible == desired
                  else "needs_review",
        "quantity": feasible,
        "desired_quantity": desired,
        "estimated_cost": feasible * s.unit_cost,
        "reorder_point": reorder_point,
        "target_level": target_level,
        "reason": "policy_target_met" if feasible == desired
                  else "target_limited_by_constraints",
    }


case = InventoryState(
    on_hand=40, on_order=0, backorders=0,
    daily_demand=10, lead_days=3, safety_stock=15,
    target_days=7, unit_cost=8, budget=400,
    capacity=100, data_is_fresh=True,
)
print(propose_replenishment(case))
# quantity=45, estimated_cost=360, status=requires_approval

这段代码实现了补货建议的基础规则。后续可以按需求扩展专业模型与约束，纳入保质期、最小起订量、多供应商、需求波动、到货概率、退货和预测校准。

8. 统一决策记录：让每一步可解释、可回放、可审计

平台的标准输出应该是结构化的 Decision Record，而不只是一段建议文本：

{
  "decision_id": "replenishment-0001",
  "task": "should_restock",
  "state_snapshot_id": "inventory-2026-11-04-001",
  "domain_pack_version": "retail-inventory@1.0",
  "knowledge_version": "knowledge@7",
  "model_version": "reorder_point_rule@1.0",
  "recommendation": {
    "action_id": "place_purchase_order",
    "quantity": 45,
    "estimated_cost": 360
  },
  "evidence_ids": ["supplier_contract", "purchase_policy"],
  "constraint_checks": {
    "budget": "passed",
    "capacity": "passed",
    "permission": "approval_pending"
  },
  "decision_status": "requires_approval",
  "execution_status": "not_executed"
}

状态快照、知识版本、模型版本和动作结果必须分开记录。 以后一次决策表现不好，才能识别究竟是数据过时、规则错误、需求预测偏差，还是执行系统出了问题。

同时记录候选方案、被排除原因、耗时、关键输入摘要、权限校验和运行时异常。对于敏感业务数据，审计日志还需要访问控制与保留策略。

9. 反馈学习：先能定位错误，再讨论自动改进

闭环反馈可以分为以下四类：

系统应记录完整的输入 → 知识与模型 → 决策 → 动作 → 结果链路，以便区分不同原因。

第一阶段可以采用版本化规则、离线回放和人工复核。建立可靠的状态、行动、奖励以及仿真或离线评估机制后，再考虑策略学习和强化学习。

10. 跨行业复用的关键：Domain Pack

平台可以将不同领域的知识和规则封装为 Domain Pack（领域能力包）。

domain-packs/
└── retail-inventory/
    ├── manifest.yaml            # 领域标识、版本与依赖
    ├── ontology.yaml            # 概念与关系
    ├── state_schema.yaml        # 状态定义
    ├── observations.yaml        # 数据源与观测解释
    ├── knowledge/               # 知识声明和证据引用
    ├── actions.yaml             # 动作契约
    ├── constraints.yaml         # 业务约束与权限规则
    ├── objectives.yaml          # 目标与评价标准
    ├── models.yaml              # 预测、规则、优化模型
    └── evaluations/             # 用例与基线

平台本身提供通用能力：

• 知识接入、证据管理、检索与版本控制；
• 状态快照、数据质量和观测工具；
• 动作注册、前置条件和权限校验；
• 规则、预测、仿真和优化模型调度；
• Agent编排、人工审批、执行和反馈；
• 决策记录、离线回放和评测。

Domain Pack 提供领域对象、规则、动作和模型。接入第二个领域时，可以复用平台基础能力并建设新的能力包。

通用平台复用基础设施与方法；接入新行业时，需要与领域专家重新定义状态变量、动作效果和目标函数。

11. 技术选型：优先实现模块化单体

下表列出初期技术选型，以及需要扩展时可以考虑的方案。

可参考的官方资料：

• Docling：文档结构化解析。
• LangGraph 持久化机制：工作流状态持久化、中断恢复。
• Google OR-Tools：整数规划、约束求解与调度。
• Open Policy Agent：策略即代码与权限控制。
• W3C PROV-O：来源与生成过程描述。
• W3C SHACL：RDF 图数据约束校验。
• OMG DMN：业务决策建模。

第一阶段可以先用关系表和规则引擎建立基线，再根据任务引入图数据库、GraphRAG、多 Agent 或强化学习。

11.1 建议的项目目录

decision-intelligence/
├── app/
│   ├── api/                    # REST API
│   ├── knowledge/              # 来源、解析、Claim与检索
│   ├── ontology/               # Schema与实体映射
│   ├── state/                  # 状态快照与观测校验
│   ├── actions/                # 动作契约与工具注册
│   ├── models/                 # 规则/预测/优化适配层
│   ├── runtime/                # 决策编排与路由
│   ├── governance/             # 权限、审批、审计
│   └── evaluation/             # 评测与回放
├── domain-packs/
│   └── retail-inventory/
├── tests/
│   ├── unit/
│   ├── integration/
│   └── scenarios/
├── datasets/                   # 非敏感测试与基准数据
├── docs/                       # 架构决策记录（ADR）
└── pyproject.toml

11.2 第一版接口

建议只实现少量高价值接口：

POST /knowledge/claims             # 提交待审核知识
GET  /knowledge/claims/{id}        # 查询知识及证据
POST /state/snapshot               # 构建状态快照
POST /decisions/propose            # 生成决策建议（无副作用）
GET  /decisions/{id}               # 查询结构化决策记录
POST /decisions/{id}/approve       # 审批（独立权限检查）
POST /decisions/{id}/execute       # 受控执行（后期开放）
POST /decisions/{id}/feedback      # 提交结果与评估

最关键的产品约束是：propose 永远不执行真实环境动作；execute 必须经过独立的授权与约束检查。

12. 评测：如何证明知识确实提升了决策？

建议建立三个基线：

• Baseline A：固定业务规则，不接 LLM 和知识检索；
• Baseline B：LLM + 文本检索，但不使用显式动作/状态契约；
• Proposed：知识 + 状态 + 动作契约 + 专业求解 + 验证闭环。

通过相同任务上的对照，检验知识工程和结构建模带来的实际收益。

12.1 最小场景测试集

12.2 指标分层设计

安全性相关硬约束，在研发验收测试中应以零已知违规为目标；但要区分“在已有测试集中没有违规”和“生产环境已证明不会违规”。业务收益也应使用合理的对照或离线回放评估，不能把一次行动后的改善直接当作因果证据。

13. 研发分期与交付标准

阶段 0：定义一个能测量的决策问题

目标：先定义一个可测量的决策问题。

交付物：

• 一份问题定义：输入、输出、目标、约束、参与者、审批权限；
• 一份状态 Schema 和动作清单；
• 一组样本数据与至少 10 个异常/边界测试场景；
• 一套固定规则基线与评价指标。

完成标准：不用 LLM，已经能计算一个正确且可测试的基础建议。

阶段 1：完成最小决策闭环

实现：状态校验 → 规则 / 模型计算 → 候选动作 → 约束校验 → 结构化决策记录 → 人工审批模拟 → 反馈记录。

交付物：

• InventoryState / DecisionRecord / ActionContract；
• 一套可运行的决策 API；
• 测试样例与自动化测试；
• 一次完整的离线回放。

完成标准：可以解释“为什么推荐 45 件”；约束失败时能够拒绝或降级；所有决策均有日志且不自动真实下单。

阶段 2：引入知识工程与 Domain Pack

实现：文档解析 → Claim 抽取 → 证据绑定 → 本体映射 → 审核入库 → 决策引用知识；将补货领域的规则、动作和模型移入能力包。

交付物：

• 来源与证据管理；
• 知识版本和审核机制；
• retail-inventory Domain Pack；
• 知识冲突和过期用例。

完成标准：修改供应商到货期等知识后，能够追踪受影响的决策；未经审核的高风险规则不能自动生效。

阶段 3：引入 LLM Agent 和复杂模型

实现：自然语言任务入口、信息缺口识别、工具选择、知识检索；在必要时接入需求预测或优化器。

交付物：

• 受约束的 Agent 编排；
• 模型注册中心；
• A/B 对照评测；
• 失败案例归因机制。

完成标准：Agent 的加入相对于规则基线在某些明确任务上带来可量化收益，且没有放松执行安全约束。

阶段 4：验证跨领域复用与持续改进

选择第二个简单领域（例如会议室资源调度、仓库拣货任务分配），重新定义 Domain Pack，而非重新开发全部平台。

完成标准：核心状态、动作、决策、审计和评测模块可以复用；行业差异主要表现为配置、规则、模型及数据适配器的更换。

14. 常见误区与设计取舍

误区一：先把所有行业资料做成大型知识图谱

问题在于缺少任务牵引，抽取范围无限扩大，实体关系很多，但对实际决策帮助不明确。

更好的方法：从一个可评价的决策问题反推所需知识，并逐渐扩展。

误区二：只要“本体 + LLM”就能得到行动模型

本体提供概念及关系，本身不保证因果机制或行动效果正确。动作必须有明确的前置条件、权限和可验证的效果模型。

误区三：用复杂多Agent替代业务建模

数据质量、约束满足与专业计算需要各自的验证；简单问题可以先使用固定工作流。

误区四：将每次失败视为大模型幻觉

失败可能来自来源冲突、状态过期、预测偏差、策略目标错误或工具执行异常。错误归因必须依赖结构化日志和回放。

误区五：过早引入 RL、POMDP 和数字孪生

涉及多步、随机或复杂动态决策时，可根据数据和评估基础选择这些技术。

误区六：把“能生成建议”当作“可以自动执行”

建议与执行必须被明确隔离。生产系统需要鉴权、审批、幂等、防重、回滚或补偿，并防御来自文档或工具返回值的提示注入。

15. 接下来可以直接执行的研发清单

可以按以下顺序推进：

• 任务定义：写清楚第一个决策问题、输入/输出、优化目标与硬约束。
• 状态模型：实现可校验的 State Schema，包含数据来源、时间戳与质量状态。
• 动作模型：实现 ActionContract，区分查询与真实写入动作。
• 基线求解器：写一个不依赖 LLM 的可运行规则或优化求解模块。
• 决策记录：定义 DecisionRecord，确保每个建议都能复现。
• 场景评测：覆盖正常、缺失、冲突、预算不足、越权与重复执行。
• 知识接入：仅为当前任务引入必要文档、Claim 和证据。
• Domain Pack：将行业概念、动作、约束和模型从框架代码中抽离。
• Agent 接入：让 LLM 负责理解、检索和编排，但不绕过规则校验。
• 闭环评估：建立与基线的对照、回放与错误归因机制。

16. 从知识到可评价的决策

长期路线可以概括为：

知识可获取 → 知识可组织 → 知识可验证 → 知识可计算 → 行动可约束 → 决策可评价 → 系统可持续改进。

如果只能检索资料、生成答案，它仍然是知识问答平台；如果能从当前状态出发，依据可追溯知识和专业模型，生成满足约束的行动建议，并在执行后检验实际效果，才开始具备决策智能平台的基本形态。

先让一个小型补货系统做到状态明确、依据清楚、计算正确、约束有效、结果可回放，再将稳定的能力抽象为跨行业基础设施。

17. 附录：便利店补货案例

以下使用教学用的假设数据：只考虑一种常温商品，暂时忽略保质期、批量折扣和需求波动。

17.1 先用确定性规则得到基线方案

定义库存位置（Inventory Position）：

补货点：

目标库存位置：

其中，$\bar d$ 是预测日需求，$L$ 是到货提前期，$SS$ 是安全库存，$H$ 是目标覆盖天数。一个简单的决策规则是：

代入：

• $IP=40$；
• $ROP=10\times3+15=45$，当前库存位置低于补货点；
• $S=10\times7+15=85$；
• $Q_{\text{desired}}=85-40=45$ 件；
• 预计采购成本 $45\times8=360$ 元，低于 400 元预算；
• 若采取不考虑在途消耗的保守容量检查，$40+45=85\le100$。

基线建议：补货 45 件，提交审批。

如果销量不稳定、供应商延期、货品容易过期或者采购资金有限，还需要相应的预测和优化模型。

17.2 为什么这个小案例足以验证整个平台？

同一问题在不同情形下会暴露几乎所有关键能力：

• 供应商合同约定 3 天到货，业务系统记录最近平均 5 天：需要区分合同约定与实际观测。
• 库存数据是上周的：需要判断状态是否过期。
• 已有一笔 30 件在途订单：需要更新状态及补货数量。
• 预算只有 200 元：产生动作约束与备选方案。
• 补货按钮对应真实采购接口：必须进行权限校验和人工审批。
• 到货后销量不及预期：需要区分预测误差和策略问题。

这些问题与行业无关，适合用来验证通用平台设计。