海外运营撤单工坊订单查询

这个技能解决什么问题

海外运营平台的撤单并不是一次干净的删除。订单可能已经关联了工坊（GF）订单，甚至已经下发到履约侧。如果直接撤单或盲目重试，要么漏掉已存在的工坊订单造成账实不符，要么把已经进入生产环节的订单当成空单处理，事后只能人工翻表对账。

check_exist_gf_order 就是撤单动作之前的那道闸门，它只回答一个问题：这个物流单下面到底有没有工坊订单。它不删除数据、不改状态、不重算金额，只做一次只读判断。

它如何工作

技能只封装一个原子动作，正式环境地址固定写在 frontmatter 的 base_url 中，调用时不接受用户输入覆盖。

• 请求方式：GET，路径 /order/orden/checkExistGFOrden
• 入参：Query 参数 shippingCode，即待校验的物流单号
• 参数传递：统一使用嵌套的 params 对象，最外层只放 params，不要写成 params.xxx 这类点号顶层 key
• 鉴权：登录态从 params.accessToken 读取，执行器拼接 Authorization: Bearer；若传入值已包含 Bearer，不要重复拼接
• 其余部分：Path 走 params.path，Query 走 params.query，Body 走 params.body，额外 Header 走 params.headers

返回的 RS 结构由上层 agent 解析，判断结果作为是否继续撤单的依据。

适用边界与注意点

• 这是查询/计算类接口，不会修改任何数据；接口返回后也不要自行补造订单号、金额、库存或物流状态
• 结果以接口响应为准。遇到认证失败、权限不足、参数错误或业务错误时，把原始错误码和错误信息原样传给上层，不要吞掉
• 调用仍然受当前登录态、租户和用户权限约束
• 单次调用只覆盖一个物流单。批量校验需要在上层编排循环，或由聚合 skill platform-order-cancel-confirm 统一调度
• 如果业务链路还需要多个接口步骤，本 skill 只负责这一步，其余由上层 agent 按计划文档串联