Agentic 洪水：当 AI Agent 把你的请求量放大 5 倍，如何既扛住洪峰又不误伤真人

AI 让填表、写申诉、提交投诉变得前所未有的容易，于是公共服务正在被「洪水」冲击。研究者 Chris Schmitz 给这种现象起了个名字：agentic flooding（Agent 洪水）。数字很有说服力：英国住房申诉专员的投诉量自 ChatGPT 出现以来翻了一倍多（从 2022 年 2600 件升至去年 7000 多件），美国 CFPB 的投诉量同期增长约 5 倍，巴西司法请愿与德国议会请愿也有类似跃升。但真正关键、也最容易被误解的一点是：这些新增申请里，绝大多数来自享有正当权利的真实个人，而不是恶意水军。

1. 什么叫 agentic flooding

Schmitz 正在追踪这股上升趋势，他称之为 agentic flooding。一篇将于下月在 AI Ethics and Society 会议上发表的论文研究了 11 个司法辖区内的 84 个潜在「洪水」案例，发现广泛证据表明 AI 工具正在改变人们与公共服务交互的方式。方法论上，论文谨慎地没有直接断言「AI 造成了申请量激增」，但大多数案例都呈现同一弧线：2022 年前提交量大致平稳，随后随着 AI 技术扩散而加速上升；更关键的是，大多数案例的增长尚未放缓，意味着未来数年可能持续攀升。

# Per-identity token bucket: smooth bursts without banning real people.
import time

class TokenBucket:
    def __init__(self, rate, capacity):
        self.rate, self.capacity = rate, capacity
        self.tokens, self.updated = capacity, time.time()

    def allow(self, n=1):
        now = time.time()
        self.tokens = min(self.capacity, self.tokens + (now - self.updated) * self.rate)
        self.updated = now
        if self.tokens >= n:
            self.tokens -= n
            return True
        return False

b = TokenBucket(rate=0.5, capacity=5)   # 30/min burst 5
print(b.allow(), b.allow())

2. 洪水从哪来：行政负担被 AI 抬走了

为什么 AI 会推动激增？Schmitz 的解释很朴素：人们发现「原来这事可以这么干」，而且做起来越来越容易。过去可能需要费力地拼凑上下文、精确地提示 ChatGPT 3.5；现在可能只需要把一封信拍照传进 Claude 应用，一次性就能得到一个相当不错的回复。在政策领域，这被称为「行政负担（administrative burden）」——如果这些人以前没去申领福利，很可能是因为申请流程本身太劝退。AI 把这道门槛抬走之后，被压抑的合法需求就释放了出来。这一点决定了应对策略的方向：不能简单地把增量都当成垃圾。

# Distinguish bulk-agent traffic from a genuine claimant.
def triage(features):
    score = 0
    score += 3 if features["same_template_as_50_others"] else 0
    score += 2 if features["no_human_dwell_time"] else 0
    score += 2 if features["submits_24_7"] else 0
    score -= 3 if features["verified_identity"] else 0
    score -= 2 if features["attachment_is_real_document"] else 0
    return "human_review" if score >= 4 else ("fast_path" if score <= 0 else "queue")

print(triage({"same_template_as_50_others": True, "no_human_dwell_time": True,
              "submits_24_7": True, "verified_identity": False,
              "attachment_is_real_document": False}))

3. 「洪水」不等于「垃圾」：与漏洞赏金的关键差别

这种量级跃升让人想起去年许多漏洞赏金项目经历的情况：企业发现收件箱被 LLM 生成的低质量报告淹没，这些报告几乎不包含真实安全问题，企业却仍必须逐一甄别，造成巨大资源消耗。公共服务很容易面临类似困境——预算不变，却要处理 5 倍申请。但关键在于：漏洞赏金里被灌进来的多是「无价值提交」，而 Schmitz 说，公共服务的新增申请大多来自真实的人。他告诉 TechCrunch：「我们发现的绝大多数案例，都是有权申领某项东西的人，在申领那项东西。」因此，把「防刷」当作唯一目标，会同时伤到最需要服务的人群。

# Collapse near-duplicate submissions without dropping distinct claims.
import hashlib, re

def normalize(text):
    t = re.sub(r"s+", " ", text.lower()).strip()
    return t

def simhash(text, bits=64):
    v = [0] * bits
    for tok in normalize(text).split():
        h = int(hashlib.md5(tok.encode()).hexdigest(), 16)
        for i in range(bits):
            v[i] += 1 if (h >> i) & 1 else -1
    out = 0
    for i in range(bits):
        if v[i] > 0:
            out |= (1 << i)
    return out

def hamming(a, b):
    return bin(a ^ b).count("1")

a = simhash("I was overcharged for my utility bill in March")
b = simhash("I was overcharged for my utility bill in March!")
print(hamming(a, b) <= 3)

4. 工程应对之一：限流、背压与排队

无论增量多么合法，系统的并发与吞吐是有限的，工程上第一步是限流与背压。对公共服务这类接口，建议用「按身份令牌桶」而非简单封禁：允许短时突发（例如 30 次/分钟、突发 5 次），平滑流量而不是直接拉黑。当队列超过阈值时，不要粗暴丢请求，而是返回 429 并附带 retry_after，或返回 202 加预计完成时间——对 Agent 客户端而言，明确的退避信号比错误更友好。同时用容量模型把「5 倍量」翻译成「需要多少人力工时」，在承诺 SLA 之前先算清利用率，避免用同样的预算硬扛 5 倍洪峰。

5. 工程应对之二：近似重复检测，而非一刀切封杀

洪水中确实混有高度模板化的批量提交，但「相似」不等于「无价值」。可行的做法是近似重复检测（如 simhash + 汉明距离）与分诊评分：把「与 50 份模板相同」「没有人类停留时间」「24 小时不间断提交」作为可疑信号，把「身份已验证」「附件是真实文档」作为减分项，得分超过阈值才转人工复核，低分走快速通道。这样既能压缩重复提交的处理成本，又不会把格式相似但内容真实的合法申请误杀。这里的分诊要可解释、可审计，因为公共服务的决策关系到真实权益。

# Backpressure: queue instead of rejecting, and tell clients when to retry.
import time

def admit(queue_len, drain_rate_per_s, incoming, max_queue=10000):
    if queue_len + incoming > max_queue:
        wait = (queue_len + incoming - max_queue) / drain_rate_per_s
        return {"status": 429, "retry_after": round(wait, 1)}
    return {"status": 202, "eta_s": round((queue_len + incoming) / drain_rate_per_s, 1)}

print(admit(9900, 50, 300))   # 429 with a retry_after
print(admit(100, 50, 10))     # 202 with an ETA

6. 从「防洪水」到「为 AI 时代重塑服务」

Schmitz 把这场洪水看成一个罕见的机遇，而不只是威胁：「让 AI 走好的一个重要部分，是能够把『好的版本』描绘清楚。任何用 ChatGPT 报过税的人都知道，这里面存在一个好版本——你被帮助了。」他说的可能是重塑几乎整个流程的时刻。落到工程上，这意味着把公共服务设计成「Agent 友好」的：提供结构化提交接口与幂等键以避免重复申报，提供清晰的字段校验与错误信息，提供稳定的限流与退避契约。实现这些时，用 JSON 格式化工具校验入站载荷，用 UUID 生成器签发幂等键，用 Cron 表达式生成器安排批量分诊任务，并用 API 测试工具验证接口在各种负载下的响应。真正的目标不是把 AI 挡在门外，而是让洪水变得可被治理。

# Make the intake agent-friendly: idempotency keys stop double-filing.
import hashlib

def submission_id(claimant, period, form_type):
    raw = f"{claimant}|{period}|{form_type}".encode()
    return hashlib.sha256(raw).hexdigest()[:32]

seen = set()
def submit(payload):
    sid = submission_id(payload["claimant"], payload["period"], payload["form"])
    if sid in seen:
        return {"status": "duplicate", "id": sid}
    seen.add(sid)
    return {"status": "created", "id": sid}

p = {"claimant": "u-123", "period": "2026-Q3", "form": "housing-complaint"}
print(submit(p), submit(p))