海外运营平台面料附件查询

这个技能解决什么问题

在面料后台的维护流程里，附件不是独立存在的对象，它总是和商品资料、订单记录或审核单绑定在一起。运营人员在排查问题、核对资料时，经常需要根据附件 ID 拿到对应的文件信息——比如确认某份面料样卡是否已经上传、查看附件元数据是否完整。但这个动作本身很轻：一次 GET 请求、一个 id 参数、返回一份附件记录。如果为此维护一个完整的功能模块，代码量和认知负担都会不成比例地放大。

platform-fabric-admin-attachment-by-id 就是为这个单一动作而生的最小颗粒度技能。

技能如何工作

这个技能只封装一个接口动作：attachment_by_id。

调用方式很直接——GET /attachment/getAttachById，Query 参数传入附件 id。认证方面，执行器从 params.accessToken 读取令牌并生成 Authorization: Bearer 头；如果传入值已经包含 Bearer 前缀，则不会重复拼接。

几个关键约束值得注意：

• 正式环境的 base_url 固定写在 frontmatter 中，执行时不接受用户输入覆盖。
• 参数统一放在嵌套的 params 对象里，不使用 params.xxx 这类点号顶层 key。
• 返回结果以接口响应为唯一事实来源，不补造库存、价格、订单号、优惠金额或物流状态。

适用边界与注意点

这个技能的设计哲学是"只做一件事，做好一件事"。它不负责附件列表的分页查询，不处理上传流程，也不管理附件与业务单据的关联关系。如果上层业务需要完成"先查商品、再取附件、最后核对版本"这样的完整链路，需要由聚合 skill 或计划文档编排多个原子技能，本技能在其中只承担"按 ID 取附件"这一环。

另一个容易踩的坑是权限模型。虽然是查询类接口，它仍然受当前登录态、租户隔离和用户权限的约束。如果传入的 id 属于其他租户或当前用户无权访问，接口会返回认证或权限错误——执行器不会尝试绕过或伪造，而是把原始错误码和错误信息原样交给上层 agent 处理。