助手返回了一份报价，格式完整，金额也像真的。销售准备发给客户之前，却不知道它调用了价格服务，还是依据旧对话猜出了一个数字。回答看起来完成，与业务计算真正发生过，是两回事。
如果报价系统已有正式报价编号，直接查询该编号就是最可靠的起点。接口日志也可辅助核对。需要助手参与时，应让它拿到真实计算结果，而不是要求它用更肯定的语气证明自己执行过。
把价格计算接成受限函数后，助手提交产品、数量和获准客户条件，提供方返回金额及规则版本。EasyNet 的调用记录用于关联这次执行；正式报价仍由报价系统创建，并返回自己的业务编号。
查询者只能核对自己有权查看的报价，价格凭证和完整客户资料留在提供方。展示上应区分准备请求、运行中、已返回和业务记录已确认，不能把收到请求或一条本地演示结果当成正式报价已经生成。
还要接好调用与报价编号的关联，并处理服务离线和回复丢失。没有拿到结果时应显示未确认，不能让模型用估算补上空白后继续标成完成；业务人员仍需要检查报价是否适合当前客户。
拿一组可以独立算出的价格条件进行核对，再断开提供方重试。正常请求应查得到对应计算和报价，断线请求应停在真实状态。销售最后确认的是可追查的报价，而不是助手对自己的评价。
- 01
提交报价条件
产品、数量、获准客户范围
- 02
价格服务返回
金额与实际规则版本
- 03
核对正式报价
查业务编号与同次结果
核对返回金额而不是相信完成标记
本地合成结果核对，不声称服务已运行。真实结果与报价编号需从获准业务系统取得。
本地示例 · python
quantity, unit_cents = 3, 1250
returned = {"quote_id": "demo-Q17", "amount_cents": 3750, "rule_version": "demo-v1"}
assert returned["amount_cents"] == quantity * unit_cents
print({"quote": returned["quote_id"], "amount_matches": True})预期结果：算术核对通过，但demo-Q17仍是合成编号，不能作为真实执行收据。
接入时的检查项
- 有效参数的返回结果与独立预期一致，可以关联到这一次调用。
- 提供方不可达时显示明确失败或未知，不出现伪造的成功结果。
- 运行结束与业务正确分别核验，历史展示不会被当作实时健康状态。