C 站用户 ID 查询

解决什么问题

在 kutesmart 海外运营平台的 C 站场景中，业务系统常常持有一个站点 URL，却需要据此定位到对应的用户身份。C 站的上下文信息（例如访问来源、落地页）与平台内部的用户 ID 之间并不是静态映射，它会受到登录态、租户隔离、站点归属等因素的影响。如果由上层 Agent 自行拼接规则或维护缓存，很容易在租户切换、权限变更后拿到过期或错误的用户标识。

get_user_id 技能把这个问题收敛为一次明确的接口调用：给定一个 URL，返回它当前的用户 ID。上层 Agent 无需理解 C 站上下文的生成逻辑，只需要按约定传入 url，即可拿到稳定的 Integer 类型结果。

技能如何工作

该技能对应一个 GET 接口，正式环境地址固定为 https://www.kutetailor.com/api/fabric/website-info/getUserId。调用时需在 params.query 中传入 url 参数，接口返回一个整数类型的用户 ID。

参数传递遵循统一的嵌套 params 对象约定：

• 认证头由 params.accessToken 生成 Authorization: Bearer，如果传入值本身已包含 Bearer 前缀，执行器不会重复拼接。
• base_url 锁定在 frontmatter 中，执行过程中不接受用户输入覆盖，避免被构造请求指向其他环境。
• 其他位置参数（path、body、headers）在当前接口中未使用，但保留结构以匹配平台通用契约。

执行器读取 SKILL.md 中声明的接口表，确定 HTTP 方法、路径和查询参数，发起请求后以原始响应体作为结果返回给上层 Agent。

适用边界与注意点

这是一个最小颗粒度的原子技能，只完成「URL → 用户 ID」这一查询动作。如果业务流程需要多个步骤（例如先解析站点、再查询用户、最后拉取权限），应由上层 Agent 自行编排，而不是在本技能中扩展。

接口返回结果必须以响应体为事实来源，执行器不会补造库存、价格、订单号或物流状态等任何接口未提供的字段。如果接口返回认证失败、权限不足或业务错误，原始错误码和错误信息会原样透传给上层 Agent，由后者决定重试或降级策略。

此外，该查询虽为只读操作，但仍受当前登录态、租户和用户权限约束。调用方需要确保传入的 accessToken 在目标租户下有效，否则可能收到权限类错误。