KutSmart 海外运营平台查询地址信息

问题背景

在 KutSmart 海外运营平台的发货管理流程中，地址信息是最基础但最常被读取的数据。无论是创建发货单、校验收货信息，还是用户在后台修改地址后回读确认，上游模块都需要拿到一条完整的 AddressVO。实际开发中，这类需求很容易被写成“顺手加一个接口调用”，但由此引发的问题不少：

• 请求参数位置不统一：有的脚本把 Query 参数拼在 URL 上，有的塞进 Body，上层 Agent 组装请求时得为每个接口单独适配。
• 认证方式不一致：部分接口用 Query 传 token，部分用 Header，还有的在值里已经带了 Bearer 前缀导致重复拼接。
• 环境地址被覆盖：测试脚本里写死 base_url 是常见做法，但生产调用一旦允许用户输入覆盖，地址就可能被改到非预期的网关上。
• 错误被吞掉：接口返回 401 或业务错误码时，上层往往只拿到一句“调用失败”，原始错误码和 message 丢失，排查链路被截断。

这个技能只解决一件事：以固定契约调用 address_one 这个查询地址接口，把返回结果原样交给上层。

技能如何工作

这个技能是发货管理聚合技能 platform-shipping-manage 下的一个原子动作，对应接口文档中的 address_one。它只负责一次 GET 调用，不做任何业务编排。

调用步骤：

1. 从请求参数中读取地址 ID（id）。
2. 将 Query 参数写入 params.query，请求方法固定为 GET。
3. 从 params.accessToken 生成 Authorization: Bearer 请求头；如果传入值已包含 Bearer 前缀，直接使用，不重复拼接。
4. 正式环境地址固定为 https://www.kutetailor.com/api/shipping/address/selectOne，由 frontmatter 中的 base_url 提供，不接受用户输入覆盖。
5. 将接口返回的 AddressVO 原样回传，不做字段裁剪或二次计算。

参数传递约定：

• 最外层只放 params 对象，不使用 params.xxx 这类点号路径作为顶层 key。
• Path 参数写入 params.path，Query 参数写入 params.query，JSON Body 写入 params.body，额外请求头写入 params.headers。
• POST/PUT 默认发送 JSON body；若上层接口网关有其他约定，以网关契约为准。

适用边界与注意点

• 不构成完整业务链路：查询地址只是发货流程中的一个环节。如果上层需求涉及“先查地址、再校验库存、再创建订单”这类多步操作，本技能只完成其中 address_one 这一跳，其余步骤需要由上层 Agent 按聚合技能或计划文档编排其他原子技能。
• 不生成业务数据：返回结果以接口响应为唯一事实来源。技能不会补造库存数量、价格、订单号或物流状态——接口没返回的字段，技能也不会凭空填充。
• 错误原样上抛：当接口返回认证失败、权限不足、参数错误或业务异常时，技能会把原始错误码和错误信息原封不动传给上层 Agent，不做异常吞并或格式化掩盖。
• 权限与租户隔离：虽然是查询类接口，仍然受当前登录态、租户和用户权限约束。调用前需确保传入的 accessToken 具备对应地址的读取权限。
• 正式环境限制：base_url 已固定为正式环境地址，技能不支持切换到测试环境或其他网关地址。