技能介绍

解决的具体问题

在多步骤的业务编排中，Agent 经常需要根据用户提供的特定线索（如客户昵称）去查询对应的客户实体信息。然而，直接让大模型去猜测或生成一个外部 CRM 系统的 API 调用往往不够稳定，且容易忽略认证、租户隔离以及接口契约等细节。当上层 Agent 正在执行一个复杂的“客户画像补全”或“订单关联”计划时，它需要一个高度可靠、只负责单一动作的原子接口封装，来确保获取到的上下文是准确且符合系统权限的。

技能如何工作

本技能将“按昵称查询客户”这一动作封装为最小颗粒度的原子技能，核心逻辑严格遵循平台接口契约。

固定调用地址：执行器会直接读取 frontmatter 中配置的正式环境地址（https://www.kutetailor.com/api/customer/customer/getCustByNickName），并强制使用 GET 方法，拒绝任何来自用户输入的 base_url 覆盖，从而防止请求被路由到非预期的测试环境或恶意地址。
参数与请求构造：所有请求参数必须统一封装在 params 对象中。具体的查询条件（如 nickname）会作为 Query 参数附加到 URL 上。如果接口需要认证，执行器会从 params.accessToken 提取 Token，并自动拼接成 Authorization: Bearer 格式的请求头；若 Token 已包含前缀，则避免重复拼接。
响应透传：接口返回后，本技能只负责将原始响应结构（RS）原封不动地交给上层 Agent，不进行任何业务层面的二次加工、补全或假设。

适用边界与注意点

作为原子技能，它的设计初衷是被组合而非独立作战。

不做多步聚合：本技能只完成 customer_by_nickname 这一个动作。如果用户需要“查客户 -> 查订单 -> 算总金额”，上层 Agent 需要自行通过计划文档编排多个不同的原子技能。
状态与权限约束：虽然这是一个查询接口，但调用必须严格遵守当前的登录态、租户上下文和用户数据权限。如果传入的 accessToken 权限不足，接口返回的认证或权限错误会被原样透传，不会自动降级处理。
数据真实性：返回结果必须以接口响应为唯一事实来源，严禁在返回结果中编造库存、价格、订单号或物流状态等未在本次响应中出现的字段。