gate-exchange-affiliate

解析 gate-cli（二进制文件路径）

按以下顺序解析 gate-cli：（1） command -v gate-cli 和 gate-cli --version 均成功；（2） 如果 ${HOME}/.local/bin/gate-cli 可执行，则使用该路径；（3） 如果 ${HOME}/.openclaw/skills/bin/gate-cli 可执行，则使用该路径。规范规则：exchange-runtime-rules.md §4（或 gate-runtime-rules.md §4）。

Gate Exchange Affiliate Program Assistant

查询和管理 Gate Exchange 联盟/合作伙伴计划数据，包括佣金追踪、团队绩效分析和申请指南。

通用规则

⚠️ 停止——继续操作前，必须阅读并严格遵守共享运行时规则。 在阅读完所有规则之前，不要选择或调用任何工具。这些规则具有最高优先级。 → 阅读 ./references/gate-runtime-rules.md

• 仅使用此技能中明确列出的 gate-cli 命令。 对于这些工作流，不得运行此处未记录的命令，即使其他接口提供了这些命令也不例外。

技能依赖项

使用的 gate-cli 命令

查询操作（只读）

• gate-cli cex rebate partner application
• gate-cli cex rebate partner eligibility
• gate-cli cex rebate partner commissions
• gate-cli cex rebate partner sub-list
• gate-cli cex rebate partner transactions

身份验证

• 交互式文件配置：如果主机上没有同时设置 GATE_API_KEY 和 GATE_API_SECRET，则运行 gate-cli config init，通过向导配置 API 密钥、密钥、配置文件和默认值（参见 gate-cli）。
• 环境变量/标志：如果已提供凭据，则无需运行 gate-cli config init——例如，在主机上同时设置 GATE_API_KEY 和 GATE_API_SECRET，或在支持的情况下使用 --api-key / --api-secret——绝不要要求用户在聊天中粘贴密钥。
• 必需的 API Key：是
• 权限： Rebate:Read
• **门户：**在聊天之外创建或轮换密钥：https://www.gate.com/myaccount/profile/api-key/manage

安装检查

• 必需：gate-cli（如果缺失，请在此技能目录中运行 sh ./setup.sh；可选设置 GATE_CLI_SETUP_MODE=release）。
• 如果要按名称调用 gate-cli，请将 $HOME/.openclaw/skills/bin 加入 PATH（或加入 setup.sh 的安装目录）。
• 凭据：当主机同时设置了非空的 GATE_API_KEY 和 GATE_API_SECRET 时，不要要求运行 gate-cli config init——这对 gate-cli 而言属于等效的有效配置。当两者都未设置或为空时，提醒操作人员运行 gate-cli config init，或在技能库中对应的技能里配置 GATE_API_KEY / GATE_API_SECRET（绝不要要求用户在聊天中粘贴密钥）。
• **基本检查：**在进行经过身份验证的调用前，不要继续操作，直到 CLI 行为符合预期（例如，运行 gate-cli --version 或此技能中的只读 gate-cli cex ... 命令）；确认凭据已正确解析后，才能执行变更操作。

执行模式

阅读并严格遵守 references/gate-cli.md，然后执行此技能的联盟工作流。

• SKILL.md 负责路由和报告策略。
• references/gate-cli.md 是资格审查/申请/佣金查询流程及降级处理的权威 gate-cli 执行规范。

重要说明

• 角色：此技能仅使用合作伙伴 API。用户查询中的“affiliate”指的是合作伙伴角色。
• 时间限制：API 每次请求最多支持 30 天。对于超过 30 天（最多 180 天）的查询，Agent 必须将时间范围拆分为多个 30 天的区段。
• 身份验证：合作伙伴 API 仍通过本地 Gate MCP 会话运行。任何必需的合作伙伴请求头（包括 X-Gate-User-Id）均由该会话提供，无需用户粘贴。
• 重要 - user_id 参数：在 commission_history 和 transaction_history API 中，user_id 参数筛选的是“交易者/交易用户”，而不是“佣金接收者”。仅在明确查询特定交易者的贡献时使用此参数。一般佣金查询中，请勿使用 user_id 参数。
• 数据汇总：根据业务规则，使用自定义汇总逻辑计算 API 响应列表中的总额。请勿直接对所有值求和，否则可能因数据结构和业务逻辑方面的考虑而导致结果不正确。

查询时间与时区（UTC+8）

所有查询时间范围均使用用户在 UTC+8 时区的当前日历日期。对于相对时间表达（“最近 7 天”“最近 30 天”“本周”“上个月”）：从今天起减去相应时长，分别将开始和结束时间转换为 UTC+8 的 00:00:00 和 23:59:59，然后转换为 Unix 时间戳。绝不要使用未来时间戳作为查询边界。to 参数必须始终 ≤ 当前 Unix 时间。如果用户指定未来日期，请拒绝查询并说明只能查询历史数据。

可用 API（仅限合作伙伴）

API 端点	描述	时间限制
GET /rebate/partner/transaction_history	获取被推荐用户的交易记录	每次请求 ≤30 天
GET /rebate/partner/commission_history	获取被推荐用户的佣金记录	每次请求 ≤30 天
GET /rebate/partner/sub_list	获取下级列表（用于统计客户数）	无时间参数
GET /rebate/partner/eligibility	检查用户是否符合申请合作伙伴的条件	无时间参数
GET /rebate/partner/applications/recent	获取用户最近的合作伙伴申请记录（最近 30 天）	无时间参数

注意：代理 API（/rebate/agency/*）已弃用，此技能中不使用。

⚠️ 重要 API 使用警告

user_id 参数说明

• 一般佣金查询中绝不要使用 user_id 参数
• commission_history 和 transaction_history API 中的 user_id 参数筛选的是交易者/交易用户，而不是佣金接收者
• 仅在明确查询特定交易者的贡献时使用 user_id（例如，“UID 123456 的交易量”）
• 对于“我的佣金”“我的收入”“我的返佣”等查询，请勿使用 user_id 参数

数据汇总规则

• 请勿直接对 API 响应列表中的所有值求和
• 使用考虑以下因素的自定义汇总逻辑：
• 业务规则和数据关系
• 资产类型分组
• 正确筛选和去重
• 时间范围边界
• 由于数据结构复杂，直接求和可能导致结果不正确

安全规则

• 查询时间（UTC+8）：对于相对时间范围、日期边界和 Unix 时间转换，请遵循 重要通知 → 查询时间和时区（UTC+8）。切勿使用未来时间戳；to 必须 ≤ 当前 Unix 时间；拒绝用户指定的未来日期。
• user_id 的使用：仅当用户明确询问特定交易者的贡献时，才使用 user_id 参数（例如“UID 123456 的交易量”）。不要在询问“我的佣金”或“我的收益”时使用 user_id——这些是合作伙伴所有被推荐用户的总额。
• 数据范围：仅查询已认证合作伙伴的数据。不得尝试访问其他合作伙伴的数据，也不得推断 API 响应之外的数据。
• 聚合：不要盲目汇总列表字段。请遵循文档中的聚合规则，并注意资产类型、去重和周期边界，以避免总额错误。
• 子账户：如果 API 表明该账户是子账户，或返回 sub_account 资格信息块，请引导用户使用主账户查询合作伙伴数据或提交申请。

核心指标

1. 佣金金额：commission_history 中的返佣收益总额
2. 交易量：transaction_history 中的交易总额
3. 净手续费：transaction_history 中收取的手续费总额
4. 客户数：sub_list 中的下级总数
5. 交易用户数：transaction_history 中的唯一用户数

领域知识

• 合作伙伴（推广者）：在此技能中，“推广者”和“合作伙伴”指的是同一角色：在 Gate Exchange 推荐他人进行交易，并从被推荐用户的交易活动中赚取返佣（佣金）的用户。仅使用 Partner API；Agency API 已弃用。
• 佣金（返佣）：佣金是根据被推荐用户产生的交易手续费支付给合作伙伴的返佣。佣金按交易或周期通过佣金历史记录报告。金额可能使用不同资产（例如 USDT）；聚合必须遵循业务规则并妥善处理资产。
• 交易量和净手续费：这些数据来自被推荐用户的交易活动（现货、期货等）。交易历史记录会返回逐笔交易记录；必须采用恰当逻辑聚合交易量和手续费，不要简单地累加列表字段。
• 下级：由合作伙伴推荐的用户。下级列表会按类型返回用户：次级代理（1）、间接客户（2）、直接客户（3）。客户数是下级总数；交易用户数是指定周期内有交易活动的唯一用户数。
• 资格：当前用户是否可以申请合作伙伴计划。通过资格 API 检查；响应包含 eligible，若不符合资格，还会包含 block_reasons 和 block_reason_codes（例如 sub_account、already_agent、kyc_incomplete）。
• 申请状态：用户最近 30 天内的合作伙伴申请（如有），包括审核状态（pending / approved / rejected），由 applications/recent API 返回。

工作流

第 1 步：解析用户查询

识别查询类型并提取参数。

需要提取的关键数据：

• query_type：overview | time_specific | metric_specific | user_specific | team_report | application | application_eligibility | application_status
• time_range：默认为 7 天，或采用用户指定的周期
• metric：commission | volume | fees | customers | trading_users（若查询特定指标）
• user_id：特定用户 ID（若查询特定用户）

第 2 步：验证时间范围

检查请求的时间范围是否有效，并确定是否需要拆分。

需要提取的关键数据：

• needs_splitting：布尔值（超过 30 天时为 true）
• segments：需要拆分时的时间段数组
• error：时间范围超过 180 天时的错误字符串

第 3 步：调用合作伙伴 API

根据查询类型，调用相应的合作伙伴 API。

如果 MCP 已配置 Gate 返佣工具，请按名称调用相应的 MCP 工具（例如，调用 gate-cli cex rebate partner transactions、调用 gate-cli cex rebate partner commissions、调用 gate-cli cex rebate partner sub-list、调用 gate-cli cex rebate partner eligibility、调用 gate-cli cex rebate partner application），并使用 API 参数参考中说明的参数。如果无法使用 MCP，请使用下方的 API 路径。

重要提醒：

• 除非明确要查询特定交易员的贡献，否则不要使用 user_id 参数
• API 响应中的 user_id 代表交易员，而非佣金接收方
• 查询“我的佣金”时，完全省略 user_id 参数

对于概览或特定时间的查询：

• 调用 /rebate/partner/transaction_history 并传入时间参数（不传 user_id）
• 调用 /rebate/partner/commission_history 并传入时间参数（不传 user_id）
• 调用 /rebate/partner/sub_list 查询客户数量

对于特定指标的查询：

• 根据指标仅调用所需的 API（除非另有说明，否则不传 user_id）

对于特定用户的查询：

• 调用 API 时传入 user_id 参数（这会显示该特定交易员的贡献）

对于申请相关查询：

• “我可以申请吗？”/“我符合资格吗？” → 调用 GET /rebate/partner/eligibility（返回 eligible、block_reasons、block_reason_codes）
• “我的申请状态”/“最近的申请”/“申请结果” → 调用 GET /rebate/partner/applications/recent（返回最近 30 天的申请记录，包括 audit_status、apply_msg 等）
• 泛指“如何申请” → 可先调用资格查询，然后提供申请步骤和门户链接

需要提取的关键数据：

• transactions：交易记录数组
• commissions：佣金记录数组
• subordinates：团队成员数组
• total_count：用于分页的记录总数
• eligibility：{ eligible, block_reasons, block_reason_codes }（用于 application_eligibility）
• application_recent：申请记录或空值（用于 application_status）

第 4 步：处理分页

如果 total > limit，请进行分页以获取所有数据。

需要提取的关键数据：

• all_data：分页后的完整数据集
• pages_fetched：发起的 API 调用次数

第 5 步：汇总数据

根据原始 API 响应计算所需指标。

重要：根据业务规则使用自定义汇总逻辑。不要简单地将所有数值相加。

• 考虑数据关系和业务逻辑
• 妥善处理不同资产类型
• 应用适当的分组和筛选规则

需要提取的关键数据：

• commission_amount：按适当业务逻辑汇总的佣金金额
• trading_volume：经过适当计算后汇总的交易金额
• net_fees：按适当规则汇总的费用
• customer_count：来自 sub_list 的总数
• trading_users：唯一 user_ids 的数量

第 6 步：整理响应

使用模板，根据查询类型生成相应的响应。

判断逻辑概要

条件	状态	操作
查询类型 = overview	✅	使用默认的 7 天，调用全部 3 个 API
查询类型 = time_specific	✅	解析时间范围，检查是否需要拆分
查询类型 = metric_specific	✅	仅调用该指标所需的 API
查询类型 = user_specific	✅	在 API 调用中添加 user_id 筛选条件（注意：user_id 指交易者，而非接收者）
查询类型 = team_report	✅	调用全部 API，生成综合报告
查询类型 = application	✅	返回申请指南；当用户询问“我可以申请吗？”或“我的申请状态如何？”时，可选择调用 eligibility 或 applications/recent
查询类型 = application_eligibility	✅	调用 GET /rebate/partner/eligibility，返回符合资格的状态和 block_reasons
查询类型 = application_status	✅	调用 GET /rebate/partner/applications/recent，返回最近的申请记录和 audit_status
时间范围 ≤30 天	✅	每个端点调用一次 API
时间范围 >30 天且 ≤180 天	✅	拆分为多个 30 天的区间
时间范围 >180 天	❌	返回错误“仅支持查询最近 180 天内的数据”
相对时间描述（例如“最近 7 天”）	✅	根据当前 UTC+8 日期计算，转换为 UTC+8 的 00:00:00-23:59:59，再转换为 Unix 时间戳
用户指定未来日期	❌	拒绝查询——仅提供历史数据
to 参数 > 当前时间戳	❌	拒绝查询——将时间调整为当前时间或更早
API 返回 403	❌	返回“没有联盟推广权限”错误
API 返回空数据	⚠️	将指标显示为 0，而不是报错
响应中的总数 > limit	✅	实现分页
User_id 不在 sub_list 中	❌	返回“用户不在推荐网络中”
UID 格式无效	❌	返回格式错误消息
用户询问“我的佣金”	✅	不要使用 user_id 参数——查询所有佣金
用户指定交易者 UID	✅	使用 user_id 参数筛选该交易者

报告模板

# Affiliate Data Report

**Query Type**: {query_type}
**Time Range**: {from_date} to {to_date}
**Generated**: {timestamp}

## Metrics Summary

| Metric | Value |
|--------|-------|
| Commission Amount | {commission_amount} USDT |
| Trading Volume | {trading_volume} USDT |
| Net Fees | {net_fees} USDT |
| Customer Count | {customer_count} |
| Trading Users | {trading_users} |

## Details

{Additional details based on query type:
- For user-specific: User type, join date
- For team report: Top contributors, composition breakdown
- For comparison: Period-over-period changes}

## Notes

{Any relevant notes:
- Data retrieved in X segments (if split)
- Pagination: X pages fetched
- Warnings or limitations}

---
*For more details, visit the affiliate dashboard: https://www.gate.com/referral/affiliate*

使用场景

案例 1：概览查询（未指定时间）

触发语句：“我的联盟数据”、“显示我的合作伙伴统计数据”、“联盟推广仪表板”

默认值：最近 7 天

输出模板：

Your affiliate data overview (last 7 days):
- Commission Amount: XXX USDT
- Trading Volume: XXX USDT
- Net Fees: XXX USDT
- Customer Count: XXX
- Trading Users: XXX

For detailed data, visit the affiliate dashboard: {dashboard_url}

案例 2：指定时间的查询

触发语句：“本周的佣金”、“上个月的返佣”、“3 月的收入”

时间处理：

• 所有时间均根据用户系统当前日期，以 UTC+8 时区计算
• 将日期范围转换为 UTC+8 的 00:00:00（开始）和 23:59:59（结束），然后转换为 Unix 时间戳
• 若 ≤30 天：调用一次 API
• 若 >30 天且 ≤180 天：拆分为多个 30 天的区间
• 若 >180 天：返回错误“仅支持查询最近 180 天内的数据”

Agent 拆分逻辑（适用于 >30 天）：

Example: User requests 60 days (2026-01-01 to 2026-03-01 in UTC+8)
Convert to UTC+8 00:00:00 and 23:59:59, then to Unix timestamps:
1. 2026-01-01 00:00:00 UTC+8 to 2026-01-31 23:59:59 UTC+8 (31 days -> adjust to 30)
2. 2026-01-31 00:00:00 UTC+8 to 2026-03-01 23:59:59 UTC+8 (29 days)
Call each segment separately with converted timestamps, then merge results.

输出模板：

Your affiliate data for {time_range}:
- Commission Amount: XXX USDT
- Trading Volume: XXX USDT
- Net Fees: XXX USDT
- Customer Count: XXX
- Trading Users: XXX

案例 3：指定指标的查询

触发语句：

• 佣金：“我的返佣收入”、“佣金收入”、“佣金有多少”
• 交易量：“团队交易量”、“总交易量”
• 手续费：“收取的净手续费”、“手续费贡献”
• 客户：“客户数量”、“团队规模”、“有多少推荐用户”
• 交易用户：“活跃交易者”、“有多少用户在交易”

输出模板：

Your {metric_name} for the last 7 days: XXX {unit}

For detailed data, visit the affiliate dashboard: {dashboard_url}

案例 4：特定用户的贡献

触发语句：“UID 123456 的贡献”、“用户 123456 的交易量”、“来自 123456 的佣金有多少”

重要：user_id 参数按“交易者”筛选，而非“佣金接收者”。这会显示该特定交易者进行的交易活动及其产生的佣金，而非其收到的佣金。

参数：

• 必需：user_id（你想查询其贡献的交易者 UID）
• 可选：时间范围（默认为最近 7 天）

输出模板：

UID {user_id} contribution (last 7 days):
- Commission Amount: XXX USDT (commission generated from this trader's activity)
- Trading Volume: XXX USDT (this trader's trading volume)
- Fees: XXX USDT (fees from this trader's trades)

案例 5：团队业绩报告

触发词：“团队业绩”“联盟报告”“合作伙伴分析”

流程：

1. 调用 sub_list 获取团队成员
2. 调用 transaction_history 获取交易数据
3. 调用 commission_history 获取佣金数据
4. 汇总并分析

输出模板：

=== Team Performance Report ({time_range}) ===

📊 Team Overview
- Total Members: XXX (Sub-agents: X, Direct: X, Indirect: X)
- Active Users: XXX (XX.X%)
- New Members: XXX

💰 Trading Data
- Total Volume: XXX,XXX.XX USDT
- Total Fees: X,XXX.XX USDT
- Average Volume per User: XX,XXX.XX USDT

🏆 Commission Data
- Total Commission: XXX.XX USDT
- Spot Commission: XXX.XX USDT (XX%)
- Futures Commission: XXX.XX USDT (XX%)

👑 Top 5 Contributors
1. UID XXXXX - Volume XXX,XXX USDT / Commission XX.X USDT
2....

案例 6：联盟申请指导

触发词：“申请联盟”“成为合作伙伴”“加入联盟计划”“我可以申请吗？”“我符合资格吗？”“我的申请状态”“最近的申请”“申请结果”

何时调用 API：

• 用户询问“我可以申请吗？”或“我符合资格吗？”→ 调用 GET /rebate/partner/eligibility。如果符合资格，则返回申请步骤；如果不符合，则返回 block_reasons 和指导。
• 用户询问“我的申请状态”或“最近的申请”→ 调用 GET /rebate/partner/applications/recent。返回 audit_status（0=待处理，1=已批准，2=已拒绝）、apply_msg 和 jump_url。
• 用户只询问“如何申请”→ 可先调用 eligibility，然后返回步骤和入口。

资格响应模板（调用 eligibility API 后）：

Eligibility check: {eligible ? "You are eligible to apply." : "You are not eligible at this time."}
{If not eligible:}
Block reasons: {block_reasons}
Please address the above before applying.

Application Portal: https://www.gate.com/referral/affiliate

申请状态模板（调用 applications/recent API 后）：

Your recent partner application (last 30 days):
Status: {audit_status: 0=Pending, 1=Approved, 2=Rejected}
{apply_msg}
{jump_url if provided}

通用指导（未调用 API 或 API 响应后）：

You can apply to become a Gate Exchange affiliate and earn commission from referred users' trading.

Application Process:
1. Open the affiliate application page
2. Fill in application information
3. Submit application
4. Wait for platform review

Application Portal: https://www.gate.com/referral/affiliate

Benefits:
- Earn commission from referred users
- Access to marketing materials
- Dedicated support team
- Performance analytics dashboard

错误处理

非联盟成员

Your account does not have affiliate privileges. 
To become an affiliate, please apply at: https://www.gate.com/referral/affiliate

时间范围超过 180 天

Query supports maximum 180 days of historical data.
Please adjust your time range.

无可用数据

No data found for the specified time range.
Please check if you have referred users with trading activity during this period.

未找到 UID

UID {user_id} not found in your referral network.
Please verify the user ID.

UID 不是下级成员

UID {user_id} is not part of your referral network.
You can only query data for users you've referred.

子账户限制

Sub-accounts cannot query affiliate data.
Please use your main account.

API 参数参考

transaction_history

Parameters:
- currency_pair: string (optional) - e.g., "BTC_USDT"
- user_id: integer (optional) - IMPORTANT: This is the TRADER's ID, not commission receiver
- from: integer (required) - start timestamp (unix seconds)
- to: integer (required) - end timestamp (unix seconds)
- limit: integer (default 100) - max records per page
- offset: integer (default 0) - pagination offset

Response: {
 total: number,
 list: [{
 transaction_time, user_id (trader), group_name, 
 fee, fee_asset, currency_pair, 
 amount, amount_asset, source
 }]
}

commission_history

Parameters:
- currency: string (optional) - e.g., "USDT"
- user_id: integer (optional) - IMPORTANT: This is the TRADER's ID who generated the commission
- from: integer (required) - start timestamp
- to: integer (required) - end timestamp
- limit: integer (default 100)
- offset: integer (default 0)

Response: {
 total: number,
 list: [{
 commission_time, user_id (trader), group_name,
 commission_amount, commission_asset, source
 }]
}

sub_list

Parameters:
- user_id: integer (optional) - filter by user ID
- limit: integer (default 100)
- offset: integer (default 0)

Response: {
 total: number,
 list: [{
 user_id, user_join_time, type
 }]
}
Type: 1=Sub-agent, 2=Indirect customer, 3=Direct customer

eligibility

GET /rebate/partner/eligibility
Parameters: none (uses authenticated user)

Response: {
 data: {
 eligible: boolean,
 block_reasons: string[],
 block_reason_codes: string[]
 }
}
block_reason_codes may include: user_not_exist, user_blacked, sub_account, already_agent, kyc_incomplete, in_agent_tree, ch_code_conflict

applications/recent

GET /rebate/partner/applications/recent
Parameters: none (returns current user's recent application in last 30 days)

Response: {
 data: {
 id, uid, audit_status, apply_msg, create_timest, update_timest,
 proof_url, jump_url, proof_images_url_list,...
 } or empty
}
audit_status: 0=Pending, 1=Approved, 2=Rejected

分页策略

当总数超过 limit 时，完整获取数据：

offset = 0
all_data = []
while True:
 result = call_api(limit=100, offset=offset)
 all_data.extend(result['list'])
 if len(result['list']) < 100 or offset + 100 >= result['total']:
 break
 offset += 100

# IMPORTANT: Apply custom aggregation logic after collecting all data
# DO NOT simply sum values - consider business rules and data relationships

时间处理

• API 接受以秒为单位的 Unix 时间戳（不是毫秒）
• ⚠️ 关键时间计算规则：
• 所有查询时间均基于用户系统当前日期计算（UTC+8 时区）
• 对于任何相对时间描述（“过去 7 天”“过去 30 天”“本周”“上个月”等）：

1. 获取 UTC+8 时区的系统当前日期
2. 从当前日期中减去指定天数，计算开始日期
3. 将两个日期分别转换为 UTC+8 时区的 00:00:00（当天开始）和 23:59:59（当天结束）
4. 将这些 UTC+8 时间转换为 Unix 时间戳
5. 使用这些时间戳调用 API

• 绝不要将未来时间戳用作查询条件

• to 参数必须始终 ≤ 当前 Unix 时间戳

• 如果用户指定未来日期，请拒绝查询并说明仅提供历史数据

• 时间转换示例（假设 UTC+8 时区的当前日期为 2026-03-13）：

• “过去 7 天”查询：

• 开始日期：2026-03-07（7 天前）

• from：2026-03-07 00:00:00 UTC+8 → Unix 时间戳

• to：2026-03-13 23:59:59 UTC+8 → Unix 时间戳

• “过去 30 天”查询：

• 开始日期：2026-02-12（30 天前）

• from：2026-02-12 00:00:00 UTC+8 → Unix 时间戳

• to：2026-03-13 23:59:59 UTC+8 → Unix 时间戳

• “本周”查询（假设一周从星期一开始）：

• 开始日期：2026-03-09（本周星期一）

• from：2026-03-09 00:00:00 UTC+8 → Unix 时间戳

• to：2026-03-13 23:59:59 UTC+8 → Unix 时间戳

• 每次 API 请求最多 30 天，必要时拆分请求

金额格式化

• 将字符串金额转换为数字进行计算
• 根据币种采用适当的精度显示（USDT：2 位小数，BTC：8 位小数）
• 大数字添加千位分隔符

验证示例

黄金查询（测试用例）

1. 基本概览

• 查询："显示我的联盟数据"
• 预期：显示过去 7 天的指标

2. 时间范围

• 查询："过去 60 天的佣金"
• 预期：拆分为 2 次 30 天的请求，并汇总结果

3. 特定指标

• 查询："我有多少客户？"
• 预期：调用 sub_list，返回总数

4. 用户贡献

• 查询："UID 12345 本月的交易量"
• 预期：调用 transaction_history，并使用 user_id 筛选

5. 错误情况

• 查询："过去 200 天的数据"
• 预期：提示 180 天的限制

6. 申请

• 查询："如何成为联盟成员？"
• 预期：提供申请指导，不调用 API