tune(anti-risk): 加固防风控策略(间隔2s+抖动2.5s+上限300+退避5-120s×6次)

Co-Authored-By: Claude <noreply@anthropic.com>

yunke-server/app/config.py

@@ -35,25 +35,35 @@ class Settings(BaseSettings):
     api_token: str = ""
 
     # --- Anti-risk-control / stealth tuning ---------------------------------
-    # These are the knobs that pace automated scraping so it resembles the
+    # Tuned 2026-08-11 after triggering 风控 during a heavy session (~500+
-    # normal web app. Defaults are deliberately CONSERVATIVE (slow + jittered):
+    # consecutive requests across groups/WA/voice-clips/SMS in ~1 hour).
-    # roughly one request every ~1.0..1.8s. Loosen these only once we have
+    # The previous defaults (1.0s + 0.8s jitter = ~1.0..1.8s cadence) were
-    # evidence the CRM tolerates a faster pace. See app.session.yunke_client.
+    # fast enough to trigger 云客's volume-based risk control when many
+    # entities are synced back-to-back. New strategy: slower base cadence +
+    # larger jitter (human-like irregularity) + hard per-run cap + longer
+    # backoff with more retries (patience over aggression).
+    # See app.session.yunke_client for the implementation.
+
     # Lower bound on seconds between successive upstream requests.
-    request_min_interval: float = 1.0
+    # 2.0s base — roughly mimics a human clicking through pages (not a bot
-    # Random extra 0..jitter seconds added on top of ``request_min_interval``
+    # hammering at 1 req/s). Combined with jitter this gives ~2.0..4.5s cadence.
-    # per request, so the cadence is not a perfectly periodic signature.
+    request_min_interval: float = 2.0
-    request_jitter: float = 0.8
+    # Random extra 0..jitter seconds. Large jitter (2.5s) ensures the cadence
-    # Hard cap on the number of upstream requests a single client may send in
+    # is highly irregular — no periodic signature for 云客 to fingerprint.
-    # one run. 0 = unlimited; >0 = enforce, then raise RequestCapReached.
+    request_jitter: float = 2.5
-    max_requests_per_run: int = 0
+    # Hard cap: 300 requests per run (~10 minutes at 2s avg). Prevents a
-    # Exponential backoff parameters applied when the CRM signals risk control
+    # runaway sync from hammering 云客 for hours. 0 = unlimited (only for
-    # (HTTP 429 or a 200 body carrying a 风控/限流 marker). Delay for retry N
+    # manual debugging). A daily `sync --entity all` will likely need multiple
-    # (0-indexed) is ``risk_backoff_base * 2**N`` clamped to ``risk_backoff_max``.
+    # runs (or increase this cap) — by design, to stay under 风控 radar.
-    risk_backoff_base: float = 2.0
+    max_requests_per_run: int = 300
-    risk_backoff_max: float = 60.0
+    # Exponential backoff: start at 5s, double each retry, cap at 120s.
-    # Number of retries attempted after the initial request before giving up.
+    # More patient than the old 2s/60s/4 — gives 云客 time to cool down.
-    risk_backoff_attempts: int = 4
+    risk_backoff_base: float = 5.0
+    risk_backoff_max: float = 120.0
+    # 6 retries (was 4) — more chances to recover before giving up.
+    # Total worst-case backoff: 5+10+20+40+80+120 = 275s (~4.6 min) before
+    # the final attempt; generous recovery window.
+    risk_backoff_attempts: int = 6
 
 
 @lru_cache