经营周报拿到了订单，退款服务却离线了。助手依然写出净收入增长的结论，因为传给模型的退款材料是一段空文本。对读者来说，报告没有留下任何缺口；对计算来说，“没查到”已经被偷换成“没有退款”。
固定 BI 报表应先用数据管道的完整性检查，缺关键分区就不发布。EasyNet 不需要接管这件事。它适合来源由不同团队维护、助手临时组合查询的情况，让每次取数有明确输入和可检查的结果，而不是靠一堆复制粘贴材料凑报告。
订单和退款可分别作为受限查询接入，接受同一约定时区、时间范围及项目范围。提供方返回业务数据、数据截至时间和口径版本；它仍负责访问原数据库。调用身份只能查询获准业务，不能让模型通过任意 SQL 扩大取数范围。
编排代码要先检查来源覆盖，再邀请模型写文字。空数组是有效业务结果；超时、权限拒绝和数据过旧各有不同处理。净收入依赖两类数据，就应该在缺退款时停止给数，或者明确交付只有订单部分的报告。
如果原数据较大，也不必把整张表交给助手。可以在提供方完成确定性聚合，返回必要统计及可核对的引用。报告注明未取得的来源；恢复后生成新的版本，说明哪些结论更新，而不是悄悄覆盖已经被转发的旧稿。
测试应让退款服务真的不可用，再用确实为零的退款样本对照，检查两份报告是否不同。调用终态只是输入证据，完整性规则和业务计算仍需团队实现。这条方案的意义，是让读者知道能相信哪部分，不是保证每次都产出一份看似完整的周报。
- 01
查询同一期间
订单与退款各自返回状态
- 02
检查必要来源
失败不是零退款
- 03
交付明确范围
缺数据不输出净收入
把零和未知分开
本地完整性检查；金额用整数分。此处模拟查询结果，不连接真实财务系统。
本地示例 · python
def net_revenue(orders, refunds):
if orders["status"] != "ok" or refunds["status"] != "ok":
return {"net_cents": None, "complete": False}
return {"net_cents": orders["cents"] - refunds["cents"],
"complete": True}
orders = {"status": "ok", "cents": 10000}
missing = net_revenue(orders, {"status": "timeout"})
zero = net_revenue(orders, {"status": "ok", "cents": 0})
assert missing["net_cents"] is None
assert zero["net_cents"] == 10000
print(missing)
print(zero)预期结果：超时得到 None/False；真实零退款得到 10000/True，不能混成同一份报告。
接入时的检查项
- 断开退款来源后是否停止给出完整净收入。
- 合法零退款与查询失败是否显示为不同状态。
- 报告能否说明数据截至时间及覆盖范围。