客服想让 AI 回答“我的订单什么时候到”。为了接入后台，开发时用了一个现成管理员账号，它既能查进度，也能改价和退款。提示词里虽然写着“只查询”，但助手一旦调错操作，底层并没有另一道限制。
最直接的办法，是先看原系统有没有只读角色或更细的接口权限。如果已有，就应该用它们。安全不来自把一个工具起名叫“查询”，也不来自相信模型会一直听话，而来自这条接入路径实际上做不了额外的事情。
当原后台只能提供过宽的接口时，可以在它前面接出一个更具体的操作：查某个订单的配送进度。EasyRemote 能把这样的函数提供给不同助手使用，EasyNet 负责相应的调用入口；订单属于谁、哪些字段能返回，则需要由这个业务函数及原系统共同检查。
这个函数不应该接收“你想执行什么后台方法”，再替助手原样转发。它只接受查进度需要的条件，并依据已经确认的调用身份确定可见订单。支付信息、内部备注和退款操作不在这个工作范围内，就不应顺便出现在结果或接口中。
底层凭证也要尽可能收窄。如果原系统支持只读账号，提供方就使用只读账号；如果只能拿到宽权限凭证，需要明确它仍然是风险点，不能因为外面包了一层函数就宣称问题完全消失。凭证留在提供方，调用者不需要为了问一次进度而拿到它。
验收时除了正常查询，还应主动尝试改订单号、增加退款参数、要求返回更多字段。检查这些请求是在执行端被拒绝，还是仅仅没有出现在界面上。尤其要用不同身份测试：自己订单能查，不代表改成别人的订单也应该返回。
这样交给助手的是一项能完成客服工作的操作，而不是后台账号的所有权。公开的函数示例可以帮助理解这种接法，真正用于订单系统仍要完成适配和测试。最后的判断很简单：它能回答需要的问题，同时即使请求越界，也不能替客户改掉不该改的东西。
- 01
客服询问进度
输入订单号，不输入后台方法名。
- 02
核对身份与归属
执行端确认订单属于获准范围。
- 03
只返回配送信息
不附送付款、内部备注或退款入口。
只投影客服需要的字段
此本地投影只展示输出收窄；认证、订单归属和只读凭证仍需实现。
def delivery_fields(order):
return {key: order[key] for key in ('id', 'delivery_status')}
print(delivery_fields({
'id': 'demo-8', 'delivery_status': 'out_for_delivery',
'internal_note': 'private', 'payment_token': 'not-returned'
}))预期结果：结果仅含id和delivery_status，没有内部备注与支付字段。
接入时的检查项
- 允许查询能返回必要进度信息。
- 调用者不能用参数切换到修改类操作。
- 其他客户订单及禁止字段不被返回。