KuteSmart海外运营款式成品库存查询

要解决的问题

在服装定制和外贸运营场景里，款式（style）和成品库存（finished stock）往往分属不同系统：款式目录维护 SKU 档案，仓库系统维护可售数量。当运营人员或上层 Agent 需要在对话、工单或批量任务里回答“这款现在有多少成品可发”时，常规做法是让后端再写一个胶水接口，或让 Agent 自行拼接多个查询。前者重复造轮子，后者容易在鉴权、租户隔离和错误传递上踩坑。

这个 skill 只解决其中一步：给定 styleId，调用海外运营平台的固定接口拿到成品库存，并把原始响应或错误原样交给上层。

它如何工作

核心能力是一条 GET 请求，action 为 style_finish_stock，路由 /style-info/getStyleFinishStock，查询参数为 styleId。

关键执行步骤：

• 使用 frontmatter 中写死的正式环境 base_url，不从用户输入里覆盖地址；
• tool arguments 统一放在嵌套的 params 对象里，最外层只有 params 一个 key，不使用 params.xxx 这种点号顶层字段；
• params.query 传 styleId，params.accessToken 用于生成 Authorization: Bearer，若上游传入的值已包含 Bearer 前缀则不再重复拼接；
• 需要额外请求头时写入 params.headers；
• 返回结果以接口响应为事实来源，不补造库存数量、价格、订单号、优惠金额或物流状态。

适用边界

它是最小颗粒度的原子 skill，不包含业务流程编排。如果用户需求是“查询库存并生成补货建议”“批量导出多个款式库存”或“结合订单锁定库存”，需要由上层 Agent 把本 skill 与其他原子 skill 组合成聚合链路。

还要注意两点：一，它仍受当前登录态、租户和用户权限约束，越权访问会被接口拒绝；二，当接口返回认证、权限、参数或业务错误时，skill 会把原始错误码和错误信息透传给上层，由上层决定如何展示或重试，而不是自行猜测一个库存数值填进去。