技能详情（站内镜像，无评论）
作者：ClawKK @ codekungfu
许可证：MIT-0
MIT-0 ·免费使用、修改和重新分发。无需归因。
版本：v1.0.0
统计：⭐ 0 · 4 · 0当前安装次数· 0历史安装次数
⭐ 0
安装量（当前） 0
🛡 VirusTotal ：良性 · OpenClaw ：良性
Package：codekungfu/rate-limiting
安全扫描（ClawHub）
- VirusTotal ：良性
- OpenClaw ：良性
OpenClaw 评估
这是一个仅供说明的设计/工作流程指南，用于速率限制；其要求和说明与其既定目的一致，不会请求凭据、安装软件或执行I/O。
目的
名称和描述与SKILL.md内容相匹配：多阶段速率限制设计工作流程。技能不要求二进制文件、环境变量或配置路径，这适用于仅指导技能。
说明范围
运行时说明纯粹是建议性的（六阶段工作流程、检查清单、提示）。它们不会指示代理读取文件、访问机密、联系外部端点或执行命令--保持在规定的目的范围内。
安装机制
不存在安装规范和代码文件（仅限指令）。这可以最大限度地减少磁盘写入和执行风险，适合文档风格的技能。
证书
技能没有请求环境变量、凭据或配置路径。提及的技术（ Redis、CDN、标头）仅与上下文相关，并不意味着可以访问这些系统。
持久
始终为FALSE ，并且技能不会请求提升或持久的权限。平台默认允许自主模型调用，但此技能的纯指令性质限制了它的功能。
综合结论
此技能是限速的低风险、仅指导性设计指南。它不会安装软件或要求提供凭据。您应该： （ 1 ）在应用更改之前，确认内容与您组织的政策和技术堆栈保持一致； （ 2 ）在暂存环境中测试任何推荐的算法/配置； （ 3 ）如果您需要合规性来源或内部策略，请考虑作者/源代码的可信度（未提供主页） ……
安装（复制给龙虾 AI）
将下方整段复制到龙虾中文库对话中，由龙虾按 SKILL.md 完成安装。
请把本段交给龙虾中文库（龙虾 AI）执行：为本机安装 OpenClaw 技能「速率控制步驟」。简介：深度速率限制工作流程-识别参与者和资源，选择算法，分布式与本地限制，客户端用户体验（标头，重试）和滥用检测...。
请 fetch 以下地址读取 SKILL.md 并按文档完成安装：https://raw.githubusercontent.com/openclaw/skills/refs/heads/main/skills/codekungfu/rate-limiting/SKILL.md
（来源：yingzhi8.cn 技能库）SKILL.md
---
name: rate-limiting
description: Deep rate limiting workflow—identifying actors and resources, choosing algorithms, distributed vs local limits, client UX (headers, retries), and abuse detection. Use when protecting APIs, gateways, or multi-tenant SaaS workloads.
---
# Rate Limiting (Deep Workflow)
Rate limits balance **fairness**, **availability**, and **abuse prevention**. Design explicitly: **who** is throttled, **what** resource is limited, and how clients should **back off**.
## When to Offer This Workflow
**Trigger conditions:**
- Protecting public APIs, auth endpoints, or expensive operations
- Multi-tenant “noisy neighbor” isolation
- Retry storms after incidents causing cascading 429/502
**Initial offer:**
Use **six stages**: (1) threat & fairness model, (2) dimensions & keys, (3) algorithms & config, (4) distributed enforcement, (5) client protocol & UX, (6) observability & tuning). Confirm enforcement layer (API gateway vs app middleware vs edge).
---
## Stage 1: Threat & Fairness Model
**Goal:** Distinguish legitimate bursts (batch jobs, mobile retries) from abuse; align limits with product tiers and SLAs.
**Exit condition:** Written policy: free vs paid limits, partner caps, burst allowances.
---
## Stage 2: Dimensions & Keys
**Goal:** Choose stable limit keys: authenticated user id > API key > IP (with shared-NAT caveats).
### Practices
- Per-tenant and global limits; separate expensive routes (exports, search)
---
## Stage 3: Algorithms & Config
**Goal:** Token bucket / leaky bucket for smooth bursts; sliding window for strict per-minute caps; consider **concurrency** limits separately from request rate.
---
## Stage 4: Distributed Enforcement
**Goal:** Central store (Redis, etc.) with atomic increments; handle multi-region (sticky routing vs shared counters); mind clock skew.
---
## Stage 5: Client Protocol & UX
**Goal:** Consistent **429** responses with **`Retry-After`**; document exponential backoff + jitter; optional `X-RateLimit-*` headers for transparency.
---
## Stage 6: Observability & Tuning
**Goal:** Metrics on throttles by route and actor class; alerts on abnormal deny spikes (attack vs misconfigured client).
---
## Final Review Checklist
- [ ] Policy matches tiers and fairness goals
- [ ] Limit keys stable and hard to spoof
- [ ] Algorithm matches burst vs sustained semantics
- [ ] Distributed correctness considered
- [ ] Client-facing 429 behavior documented
- [ ] Metrics and tuning loop defined
## Tips for Effective Guidance
- Coordinate with authentication—anonymous IP limits are coarse.
- Don’t throttle health checks in ways that break monitors.
- GraphQL: consider query **cost** / depth limits, not only HTTP count.
- WebSockets: separate connection caps from message rate limits.
## Handling Deviations
- **Edge/CDN:** limits may differ from origin—document both layers.