Kutesmart 工艺 ID 查询

海外运营平台涉及大量跨系统的工艺数据查询。开发者在对接 Kutesmart 工艺目录时，常被分散的接口地址、认证头拼接和参数格式规则拖累。同一个“根据工艺 ID 查询详情”的动作，往往要在多个业务链路中重复实现，容易产生配置不一致、参数位置错误等问题。

技能如何工作

这个技能把 craft_by_id 这个接口动作收敛为最小颗粒度调用，核心流程固定且明确。

• 固定调用地址：正式环境使用 GET https://www.kutetailor.com/api/craft/craft/craft/getCraftById/{id}，地址写在 frontmatter 的 base_url 中，执行器不会从用户输入覆盖。
• 嵌套参数结构：tool arguments 统一使用嵌套的 params 对象，避免出现 params.xxx 这类点号顶层 key。
• 参数归位规则：Path 参数写入 params.path，Query 参数写入 params.query，JSON Body 写入 params.body，额外 Header 写入 params.headers。
• 认证处理：登录态接口使用 params.accessToken 生成 Authorization: Bearer；如果传入值已含 Bearer，不会重复拼接。
• 请求约定：POST/PUT 默认发送 JSON body；如果上层网关另有契约，以网关契约为准。
• 事实来源：返回结果完全基于接口响应，不会补造库存、价格、订单号、优惠金额或物流状态。

适用边界与注意点

这个技能只负责“根据工艺 ID 查询”这一个原子动作。如果业务流程需要多个接口步骤，应由上层 agent 通过聚合 skill 或计划文档编排多个原子技能，而不是在这个技能内部实现完整链路。

它属于查询或计算类接口，执行时仍需遵守当前登录态、租户和用户权限。若接口返回认证失败、权限不足、参数错误或业务错误，技能会把原始错误码和错误信息原样传给上层 agent，不吞掉、不改写错误上下文。

对于需要组合查询、跨接口数据关联的场景，直接依赖这个原子技能并不合适。它适合作为更大业务编排中的一个可靠环节，由上层负责后续的数据整合与决策。