海外工艺目录批量查询

要解决的问题

在 Kutesmart 海外运营平台的工艺目录场景里，上层 Agent 或业务系统常常需要一次拿到多个工艺的详情。如果没有统一的调用封装，每个调用方都要自己拼 craftIds、处理认证头、拼接正式环境地址，还要面对「这批工艺里哪些查到了、哪些不存在」这类分散返回，最后很容易各写一套、口径不一致。

这个技能做了什么

platform-craft-catalog-craft-list 只负责一件事：调用 craft_list 这个 GET 接口。

• 固定入口：正式环境地址写死在 frontmatter 的 base_url 里，固定为 GET https://www.kutetailor.com/api/craft/craft/craft/getCraftList，不接受用户输入覆盖，避免误打到测试环境。
• 统一参数载体：所有 tool arguments 都放在嵌套的 params 对象里，不在最外层出现 params.xxx 这类点号 key。
• 登录态透传：通过 params.accessToken 生成 Authorization: Bearer；如果传入值本身已含 Bearer，不再重复拼接。
• 参数归位：路径参数进 params.path，查询参数进 params.query（craftIds 就放在这里），JSON 体进 params.body，额外请求头进 params.headers。
• 以接口返回为准：结果直接透出接口响应，不补造库存、价格、订单号、优惠金额或物流状态。

适用边界与注意点

• 这是最小颗粒度的原子技能，只完成本接口调用。需要组合完整业务链路时，要由上层 Agent 按聚合 skill 或计划文档编排多个原子技能。
• 虽然这是查询类接口，仍受当前登录态、租户和用户权限约束。
• 遇到认证、权限、参数或业务错误时，把原始错误码和错误信息原样传给上层 Agent，不要吞掉或改写。
• 后续字段如果还有加工需求，建议按步骤索要，而不是一次把链路做完。