网站 URL 用户归属查询

解决的实际问题

在 kutesmart 海外运营平台的日常运营中，运营、客服和审核人员经常需要根据网站 URL 快速定位该网站所属的用户 ID。无论是处理用户申诉、核实站点归属，还是对网站进行分类管理、排查异常站点，第一步都依赖同一个问题：给定一个 URL，它对应的用户是谁？

过去这类查询往往需要人工在多个后台页面之间切换、复制粘贴、反复核对，流程长、易出错，而且很难直接嵌入自动化流程。当上层 agent 需要批量处理站点清单时，逐条手动查询几乎不可行。

技能如何工作

该技能是一个最小颗粒度的原子技能，只负责一个接口动作：get_user_id_by_url。它把「URL → 用户 ID」的查询封装成一次标准化调用：

• 固定入口：正式环境调用地址写在 frontmatter 的 base_url 中，固定为 GET https://www.kutetailor.com/api/fabric/website-info/getUserIdByUrl，执行时不接受用户输入覆盖。
• 统一参数结构：所有调用参数封装在嵌套的 params 对象中，最外层只放 params，不使用 params.xxx 这类点号顶层 key。
• 鉴权方式：登录态接口使用 params.accessToken 生成 Authorization: Bearer 请求头；若传入值已包含 Bearer 前缀，不重复拼接。
• 参数分类存放：Path 参数写入 params.path，Query 参数写入 params.query，JSON Body 写入 params.body，额外请求头写入 params.headers。
• 请求方法：该接口为 GET，查询参数 url 放在 URL query 中传递。

调用完成后，技能将接口返回结果原样交给上层 agent，由后者决定是否继续调用其他原子技能。

适用边界与注意点

• 只做一步：本技能只完成 get_user_id_by_url 这一个接口调用。如果业务流程需要多个步骤，应由上层 agent 按聚合 skill 或计划文档编排多个原子技能，而不是在本技能内部扩展。
• 结果以接口为准：返回结果必须以接口响应为事实来源，不要根据上下文推测或补造用户 ID、站点信息等数据。
• 错误原样透传：若接口返回认证失败、权限不足、参数错误或业务错误，应将原始错误码和错误信息完整传给上层 agent，不要自行吞掉或改写。
• 仍需登录态：这是查询类接口，但仍受当前登录态、租户隔离和用户权限约束，调用前需确保 token 有效且具备相应权限。