技能介绍

问题背景

海外运营平台做邮件营销时，运营和数据分析角色经常要回答“这波活动邮件到底发出去多少、展示情况如何”。如果由每个调用方各自拼 HTTP 请求，很容易出现 base_url 漂移、鉴权头拼接不一致、Query 结构与接口契约对不上等问题。这个技能把 send_history 这个动作固定成一个最小颗粒度接口 skill，让上层 agent 只关心业务编排，而不必重复处理传输层细节。

技能如何工作

这个 skill 只负责一次平台接口调用：通过 GET /campaign-send-history/campaignShow 获取邮件发送展示数据。调用时遵循一套统一约定：

正式环境地址写在 frontmatter 的 base_url，执行器固定使用该地址，不接受用户输入覆盖。
tool arguments 统一使用嵌套 params 对象；最外层只放 params，不使用 params.xxx 这类点号顶层 key。
登录态通过 params.accessToken 生成 Authorization: Bearer；如果传入值已经包含 Bearer，不再重复拼接。
params.path 放路径变量，params.query 放查询参数，params.body 放 JSON Body，params.headers 放额外请求头。
按接口表选择 HTTP method 和 URL；GET/DELETE 的查询参数放在 URL query，POST/PUT 默认发送 JSON body，若上层网关另有约定则以网关契约为准。
返回结果以接口响应为事实来源，不补造库存、价格、订单号、优惠金额或物流状态。

适用边界与注意点

这个技能是原子接口 skill，不是完整业务链路。当用户需要多个步骤时，它只完成本接口调用，并把关键返回字段交给后续 skill；完整流程由上层 agent 按聚合 skill 或计划文档编排。

调用前需要确认当前登录态、租户和用户权限是否覆盖目标活动。如果接口返回认证失败、权限不足、参数错误或业务错误，应原样透传错误码和错误信息，不要吞掉异常或自行改写结论。若要复用这套约定扩展新的查询或计算类接口，也要保证 base_url 不可被覆盖、参数按 params 嵌套传递、响应字段不额外推断。