定价系统里最昂贵的 bug 不是算错了，而是一个看起来对、但无法解释的价格。当买家对费率提出异议，当供应商声称少付，当收入团队审计季度佣金时，平台必须回答一个简单的问题：这个数字是怎么来的？大多数规则引擎在这个测试上都会失败。它们算得快、改得静默，只留下一个最终价格，没有任何谱系。结果是运营瘫痪：团队知道有什么变了，但无法还原是什么、什么时候、以及经谁授权。

HotelByte 的动态定价与业务规则引擎把来源追溯作为一等输出。每个经过系统的房价都携带一个 MarkupProcess 痕迹，记录原始供应商净价、最终买家可见价、绝对和百分比差额，以及按时间顺序排列的每条触发规则——包括规则 ID、策略类型、场景标签和人工可读的描述。这不是事后补的日志，而是一个结构性保证：只要价格存在，它的解释就存在。

行业惯例：黑盒加价

酒店分销领域的商业团队通常通过三种路径管理定价：供应商适配器里的硬编码逻辑、表格驱动的批量更新，或者通过不透明 API 集成的外部规则引擎。这三种方式共享同一个失败模式：修改价格的规则与价格本身是解耦的。一个第三方系统在请求后应用了 12% 的”季节性调整”规则，但在平台的响应载荷里不留痕迹。买家看到一个数字，平台看到一个数字，没人看到链条。

这种不透明带来三个可预测的问题。第一，争议解决变成取证工作，需要跨多个供应商和时区的日志关联。第二，回归测试不可能：一月份的规则变更可能影响六月份的价格，而平台没有任何机制在买家投诉前发现漂移。第三，多方治理崩塌。当平台运营方、供应商和买家各自维护独立的规则集时，缺乏统一痕迹意味着没有任何一方能验证自己的策略是否被正确执行。

HotelByte 的取舍：配置优于代码，痕迹优于速度

引擎建立在三层架构之上——因素、条件、动作——把”评估什么”与”何时触发”以及”接下来做什么”分离开来。规则以声明式 JSON 配置表达，而非命令式代码。这个选择牺牲了图灵完备脚本的表达能力，换取了确定性评估、可版本化定义，以及非工程人员的可编写性。

这个取舍是真实的。配置驱动引擎无法表达任意业务逻辑，无法在评估期间调用外部服务，无法在请求之间维护隐藏状态，也无法引入时间副作用。这些限制是故意的边界。它们确保相同输入总是产生相同输出——这是缓存层、对账流水线和争议解决都依赖的性质。

评估生命周期分为两个阶段。请求前动作在外部调用之前控制供应商选择和请求塑形；请求后动作在收到供应商响应后应用加价或过滤。这种分离避免了浪费的供应商调用，并确保面向买家的价格是基于完全物化的费率计算出来的，而非估计值。

加价层的语义守卫

引擎实现了四种加价模型——百分比、固定金额、乘数和分层——每种都有在规则创建、模拟和执行时验证的边界参数。百分比加价限制在 -99% 到 +1000% 之间；乘数在 0× 到 10× 之间；分层区间必须格式正确且单调。这些边界不是性能优化，而是语义守卫，防止畸形或恶意的规则扭曲价格。

浮点边界精度处理确保整数值阈值在底层费率为十进制货币类型时仍能正确行为。像 netRate > 100 这样的条件，不应因 IEEE 754 表示误差而把 99.999999999 错误分类。引擎应用精度安全的比较语义来消除这类细微的加价失败。

因素注册表把上下文维度组织成五个范围——请求、用户、商品、租户和环境——每个都有明确定义的数据源和运算符支持。这种范围划分防止规则作者无意中创建跨租户条件，并使引擎能够为每个评估上下文预过滤因素集。

白皮书重点阅读路径

如果你在评估 HotelByte 的商业控制，建议重点阅读以下章节：

  • 因素层 —— 理解五个评估范围和混合数据源解析策略。
  • 条件层 —— 查看运算符语义和浮点精度处理。
  • 动作层 —— 审阅请求前和请求后动作类型、四种加价模型及其参数边界。
  • 规则评估生命周期 —— 追踪 Seller-In、Seller-Out 和 Buyer-Out 规则的顺序执行。
  • MarkupProcess 痕迹 —— 研究响应级来源结构和它在争议解决中的作用。
  • 已实现控制摘要 —— 审阅完整控制列表，包括模拟能力和多租户规则隔离。

完整技术规范见 Dynamic Pricing & Business Rules Engine 白皮书。中文版：动态定价与业务规则引擎白皮书。

全部白皮书索引见 HotelByte Whitepapers。