用 Opsx + AI 治理网站恶意爬虫：7 月拦截近 4 TB 无效 CDN 流量

生成式 AI 普及以后，技术用户获取答案的方式正在发生变化。一部分原本需要访问社区、搜索历史问答或发布新问题的需求，被 AI 对话直接承接。对技术社区而言，真实用户访问和 UGC 活跃度承受压力并不意外。Stack Overflow 也曾在官方流量分析中披露，GPT-4 发布后的 2023 年 4 月出现过约 14% 的超常流量下降。

墨天轮的数据一度呈现出相反现象：在行业真实流量承压的背景下，网站访问指标没有下降，反而增长了数倍。按照过去以日活、月活为核心的运营口径，这原本应该是一个非常好的结果；但同期 UGC 产出，以及用户登录、签到等能够确认的互动数据并没有同步增长，部分指标反而在下降。

继续核对 CDN、NGINX 和应用日志后，指标之间的矛盾才得到解释。传统搜索引擎蜘蛛的流量变化很小，对这轮指标增长的影响可以忽略；真正抬高访问量的是大量伪装成普通浏览器的程序化抓取请求。它们的目的无法从访问日志直接证明：可能是搬运网站内容，可能是构建本地知识库，也可能用于大模型训练。能够确认的是，这些请求没有带来相应的登录、签到或内容互动，却被计入了原有的流量、日活和月活指标。

第一阶段，我先用 User-Agent 黑名单处理能够明确识别的低价值抓取请求。当前实际规则如下，Googlebot 和 Bingbot 没有进入名单，因此不会在这一层被拦截。下面为了阅读做了换行，CDN 中保存的实际配置仍是一条连续规则：

*YisouSpider*|*Baiduspider*|*python-requests*|*Go-http-client*|*okhttp*|*Apache-HttpClient*|*Sogou*|*Firefox/3.0*|*Windows NT 5.1*|*360Spider*|*AhrefsBot*|*Windows NT 6.1*|pc|axios/1.7.7|*Bytespider*

这份名单不只包含一搜、百度、搜狗、360、Ahrefs 和 Bytespider 等已知蜘蛛，也覆盖 python-requests、Go-http-client、okhttp、Apache-HttpClient、axios 等常见程序化客户端，以及根据当前业务访问特征确认不再需要的旧客户端标识。规则生效后，CDN 侧流量下降约 30%，说明这一层简单、确定且几乎没有运行成本的过滤已经处理了相当比例的非用户请求。

但这一步很快遇到边界。剩余 Bot 不再使用固定的爬虫 User-Agent，而是伪装成 Chrome 等普通浏览器；有些还使用 IP 池轮换来源，把请求分散到同一网段的多个地址。单看某一个 IP，请求量可能并不突出；聚合到 /24 网段后，持续抓取的特征才会显现。只依赖 User-Agent 或单 IP 黑名单，已经无法继续识别这部分流量。

问题因此不再只是“访问量太大”。爬虫流量一方面污染运营指标，使表面增长与登录、签到、UGC 等互动指标发生背离；另一方面持续消耗 CDN、源站服务器和 OSS 资源。对于以原创技术内容为核心的网站，它还带来内容被批量获取的风险：

• CDN、源站服务器和 OSS 都在为它们消耗流量、连接和计算资源；
• 原创内容被外部平台批量抓取和搬运，墨天轮承担内容生产与分发成本，内容价值却被外部平台直接复用。

云 WAF 和 Cloudflare 都是可以考虑的方案，但并不适合直接套用到当前场景。WAF 的 Bot 识别与定制能力难以完整覆盖内容型网站的业务规则，整体费用也比较高；Cloudflare 在中国大陆的接入还有额外条件，其官方 China Network 文档要求先使用 Enterprise Plan，再单独订阅中国网络，并由合作方审核域名。

更关键的是，Google、Bing、正常用户和高成本爬虫之间没有一条可以直接套用的通用边界。什么样的抓取频率可以接受，何时应该封单个 IP、何时才可以按网段处理，都取决于网站自身的内容和访问模式。

事实上，这并不是 Opsx 完成以后才找来验证平台的案例。恶意爬虫带来的流量成本、内容风险和跨系统治理难题，本身就是我设计 Opsx 的首要动机，也是平台最先要实现的生产运维需求。

这个需求从一开始就要求 Opsx 不能只是一个连接 LLM 的聊天界面：它必须基于真实 Asset 连接 CDN、双节点 NGINX、访问日志、OSS 和已有知识，让 AI 处理仍在变化、需要综合判断的爬虫模式，再把经过验证的判断固化为不依赖 LLM 的 Shell Schedule。分析、执行、反馈和规则演进需要留在同一个运维控制面中，而不是继续分散在云控制台、服务器终端和个人经验里。

这次实践的目标并不是清除所有爬虫，而是在降低无效流量、校正运营指标和控制内容搬运风险的同时，尽可能保留搜索引擎与正常用户访问，并为误封提供可验证的恢复路径。机制运行后，全站 CDN 流量较治理前下降约 50%，登录、签到和 UGC 等互动指标并未出现同等幅度的下降，也没有为此购买高价 WAF。

图 1：2026 年 6 月 17 日至 7 月 14 日的全站 CDN 流量趋势。规则逐步生效后，整体流量较治理前下降约 50%。这里展示的是网站整体流量变化，不是“只封住了全部爬虫中的一半”。

图 2：2026 年 8 月 23 日的 CDN 状态码分布。23:45 时，因命中黑名单而返回 403 的请求占比达到 78.45%，全天大部分时间也维持在接近 80% 的高位。这说明封禁以后，程序化抓取并没有停止尝试，而是被持续挡在 CDN 边缘。

这 80% 以请求数为统计口径，并不等同于 80% 的响应流量或费用。但如果没有边缘黑名单，这些请求首先会继续产生 CDN 请求次数、下行流量和带宽费用；其中缓存 MISS 和动态页面请求还会进一步穿透到 NGINX、应用与数据库，带来连接、计算和查询压力。现在大部分请求在 CDN 返回 403，成本和压力被截断在了链路最前端。

后文提到的 NGINX 日志中 18.7% 的 403 是另一个层级、另一个采样窗口：已经在 CDN 被拦截的请求不会再进入 NGINX，因此两个比例不能直接比较，也并不矛盾。

从人工事后处置，变成分钟级持续治理

在 Opsx 之前，这项工作只能在人发现流量异常或账单上涨以后开始：登录 CDN 控制台，手工查询访问日志，把数据导出后分析来源，再回到域名配置页面逐条增加 IP 黑名单。它天然是后置的；只要人没有及时发现，程序化抓取就会继续消耗资源。面对不断轮换的 IP 池，同一批地址查完、封完，下一批可能已经出现。

Opsx 改变的不只是黑名单由谁填写，而是整个治理时序：

当前 NGINX Schedule 每 10 分钟分析一次增量日志，CDN Tier1 每 15 分钟分析最近一小时的请求。它不是毫秒级防火墙，但已经把过去以小时甚至天计算的人工响应压缩到分钟级：新出现的高频 IP 或地址池达到条件后，无需等待人打开控制台，就能自动进入候选、完成边缘封禁并返回验证结果。

这套方案在技术思路上参考了 Cloudflare 的分层 Bot 治理：把 Google、Bing 等已验证爬虫与未知自动化请求分开；不只依赖可伪造的 User-Agent，而是根据多种信号形成评分；使用 IP 与 CIDR 列表表达处置范围，并尽可能在边缘终止请求。Cloudflare 的官方文档也将 Bot Score、Verified Bot 作为规则字段，并支持在规则中引用 IP、CIDR 和 ASN 列表。

Opsx 并不具备 Cloudflare 的全球流量样本、托管信誉库和机器学习规模，它的优势是更贴近自己的业务与资产：第一次出现的新模式由人和 AI 结合真实日志判断；经过验证的 UA、IP 池、/24、同 /16 聚集度和复发记录进入评分模型；误封和解封又会补充 allowlist、Knowledge 与规则。识别逻辑因此不是上线后固定不变，而是在每一次真实处置中持续进化，成熟规则再下沉为不依赖 LLM 的 Shell Schedule。

这不是一个 NGINX 脚本能独立解决的问题

Bot 请求从互联网进入网站，可能先经过 CDN，再到 NGINX 和应用；静态内容还可能来自 OSS。每一层看到的证据都不一样：

Bot / AI 爬虫
  │
  ├── CDN：带宽、请求量、来源分布、边缘黑名单
  │
  ├── NGINX：真实 URL、状态码、User-Agent、访问频率
  │     ├── 应用节点 A / NGINX 副本 A
  │     └── 应用节点 B / NGINX 副本 B
  │
  ├── 应用：接口、业务身份、异常日志
  │
  └── OSS：对象流量和源站成本

如果只在 CDN 控制台看流量，很难知道某个高流量来源到底在抓什么内容；如果只登录一台 NGINX 看日志，又可能漏掉另一个副本，也无法直接修改 CDN 边缘策略。云资源、主机、容器、日志和历史处置脚本被不同平台分开以后，人需要不断切换窗口、补齐上下文并等待结果。

普通聊天式 AI 同样解决不了这个问题。它只能分析我粘贴进去的几行日志，不知道准确的生产资产、两台 NGINX 的关系、阿里云 CLI 在哪个环境、黑名单脚本怎么同步，也无法确认操作以后两个副本是否真正生效。

Opsx 补上的正是这一层。它把 cdn-js-modb-cc 和 svc-emcs-nginx 作为明确的生产 Asset，保存身份、元数据、关系、运行拓扑和 Runtime 路由：

• CDN 云资源由具备阿里云 CLI 能力的 Runtime 操作；
• NGINX 服务关联两个实际运行节点，日志需要分别采集；
• Issue 保存告警、分析、授权、执行和验证；
• Asset Memory 和 Knowledge 提供日志格式、历史流量特征、管理脚本和过去误判；
• Claude Code 负责第一次面对复杂流量时收集证据、分析和调整方案；
• Shell 负责把验证后的判断稳定地执行下去。

如果只在某台主机安装 Agent，执行能力仍然受单机环境限制，跨云资源和双节点操作还需要人工切换。Opsx 作为控制面，负责解析目标 Asset、选择可用 Runtime，并让不同执行端返回的证据进入同一个 Issue。

先用 Aliyun CLI 和 SLS 把流量还原成证据

要把事后人工处置变成持续运行的 Schedule，首先要同时接通两个能力：一边是能够快速查询和聚合 CDN 日志的数据面，另一边是能够安全修改域名黑名单的控制面。若直接调用云 API，还要为签名、参数和错误处理维护一套专用代码；Aliyun CLI 则把这两类能力统一成了可编排的命令接口。

Aliyun CLI 在这次治理中不是可有可无的工具。Opsx 根据 cdn-js-modb-cc Asset 找到已经配置好正确 CLI 版本和访问身份的 Runtime，Claude Code、Issue 和后续 Shell Schedule 都通过同一条受控路径访问阿里云。凭据保留在 Runtime 的 CLI Profile 中，不进入 Prompt，也不写进 Schedule。

第一步不是立即封 IP，而是通过 CLI 直接查询 CDN 的 SLS 日志。下面是从实际 Schedule 中抽出的脱敏查询结构：

ALIYUN=/path/to/aliyun
FROM=<窗口开始的 Unix 时间戳>
TO=<窗口结束的 Unix 时间戳>

QUERY="* | select
  ip_prefix(remote_ip, 24) as ipp,
  count(*) as req,
  count(distinct remote_ip) as ips,
  count(distinct user_agent) as uas,
  sum(response_size) as bytes,
  sum(case when hit_info='MISS' then 1 else 0 end) as miss
where return_code < 400
group by ipp
order by req desc
limit 2000"

"$ALIYUN" sls get-logs-v2 \
  --profile "$PROFILE" \
  --project "$PROJECT" \
  --logstore "$LOGSTORE" \
  --from "$FROM" --to "$TO" \
  --query "$QUERY"

这不是把整份日志下载回来再慢慢处理，而是在日志服务端用类 SQL 直接完成时间窗过滤和 /24 聚合。返回结果同时包含请求总量、独立 IP 数、UA 数量、响应字节和缓存 MISS，可以继续回答几个关键问题：流量集中在哪些网段，是单 IP 高频还是 IP 池分散，同一批地址是否只使用少量 UA，以及成本主要来自 CDN 带宽还是回源。

kw_159 沉淀的一次流量归因很有代表性：在一个 9 小时窗口内，经过反向 DNS 复核的真实 Googlebot 只占约 0.05%；两个伪装成普通浏览器的爬虫 UA 却贡献了约 88% 的增量流量，其中一个 UA 分散在 5 万多个 IP 上。与此同时，缓存 MISS 低于 0.02%，说明这批请求主要消耗 CDN 下行带宽，并没有明显增加回源压力。没有这组证据，很容易把“总访问量增长”误判成正常用户增长，也可能把成本归因到错误的层级。

这里还有一个重要教训：Chrome/某版本 不能单独作为恶意证据，UA 本身可以伪造，也可能受浏览器 UA 简化策略影响。Opsx 最终采用的是行为组合：时间窗口、请求量、响应字节、IP 分布、UA 集中度、URL 特征、状态码、缓存命中和历史处置记录共同参与判断。

一条 /24 告警，最终为什么只封一个 IP

2026 年 8 月 4 日，一条 NGINX 告警显示：最近一小时，某个 /24 网段产生了 10,659 次访问，需要尽快封禁。

如果机械执行告警，最简单的动作就是把整个 /24 写入黑名单。但 Claude Code 通过 Opsx 同时读取两个 NGINX 副本的日志后发现：

• 这 10,659 次访问实际都来自同一个 IP；
• 对方使用伪装成普通 Chrome 的 User-Agent；
• 请求集中扫描 /db/<ID> 一类内容页面；
• 主要返回 200/302，并不是已经被拦截的 403 噪声。

根据这些证据，封禁对象从整个 /24 收缩为一个精确 IP，避免把同网段的其他地址一并纳入影响范围。

在规则尚未成熟的阶段，Claude Code 负责跨节点聚合日志、识别请求模式和排除错误方向；生产操作则始终锚定在 svc-emcs-nginx Asset 上，通过明确的 Runtime 和受控脚本执行。分析能力可以来自 LLM，但目标、权限和执行范围不能由模型临场猜测。

封禁后，Opsx 又从两个运行中的 NGINX 配置确认 deny 规则已经加载。这里的完成标准不是命令返回成功，而是流量真正经过的两个副本都处于预期状态。

这个案例说明，告警按网段聚合，并不意味着应该直接封整个网段；但后续调查也证明，不能永远只封精确 IP。对于真正使用 IP 池的 Bot，单个地址会不断变化，必须比较同一 /24 内的请求总量、不同 IP 数量、UA 集中度和历史命中次数，才能识别持续产生高频抓取的网段。

Aliyun CLI 如何把分析结果变成 CDN 策略

单次分析只能处理当前来源。Bot 可以继续更换 IP、降低单次频率或切换访问入口，因此还需要把已经验证的判断转成持续运行的机制。Aliyun CLI 在这里完成了另一半工作：同一个执行环境既能查询 SLS，也能读取和修改 CDN 域名的 IP 黑名单。

一次 CDN 自动治理的完整链路如下：

Schedule 触发
  → Opsx 根据 Asset 选择 Runtime 与 CLI Profile
  → Aliyun CLI 查询指定时间窗的 SLS 日志
  → 按 /24 聚合 req / ips / uas / bytes / return_code
  → 结合历史 ledger 计算候选和评分
  → 读取 CDN 当前 ip_black_list_set
  → 保存完整快照，计算 existing ∪ candidate
  → Aliyun CLI 下发整表
  → 再次读取 CDN 配置，验证条数与目标网段
  → 写入 ledger，并把结果返回 Issue / Execution

其中最容易被忽略的是 CDN 接口的写入语义。BatchSetCdnDomainConfig 对 ip_black_list_set 的更新不是“追加一个 IP”，而是用新的 ip_list 整体替换当前列表。如果只把本次候选传进去，已有黑名单会被全部覆盖。因此 Schedule 必须先通过 DescribeCdnDomainConfigs 读出完整列表，做去重并集，保存旧值快照以后才能下发：

# 1. 读取当前完整黑名单
"$ALIYUN" cdn DescribeCdnDomainConfigs \
  --DomainName "$DOMAIN" \
  --FunctionNames ip_black_list_set

# 2. 程序根据读取结果计算：merged = existing ∪ candidate
#    FUNCTIONS 由 merged 生成完整 ip_list，而不是只包含本次新增项

# 3. 整表下发
"$ALIYUN" cdn BatchSetCdnDomainConfig \
  --DomainNames "$DOMAIN" \
  --Functions "$FUNCTIONS"

# 4. 再次 Describe，确认新增项存在且条数符合预期

过去这四步要么在网页上手工完成，要么为阿里云 API 单独编写调用代码；现在 CLI 把云产品操作变成了可以由 Agent 调试、由 Shell 确定执行、由 Opsx 统一审计的标准动作。同一套域名配置读写方式也能承载黑名单、白名单等策略，但本案例在线自动化使用的是 ip_black_list_set；正常来源的例外规则由独立 allowlist 管理，避免黑、白名单互相掩盖真实判断。kw_73 已经把正确 Runtime、CLI 能力、查询字段、评分逻辑、整表写入方式、快照和回滚方法保存成 Runbook，后续不再依赖某个人记得这些细节。

候选也不是“请求多就封”。当前 CDN 引擎至少同时考虑四类信号：

• /24 在时间窗内的请求量很高，但 UA 数量很少；
• 同一 /24 出现较多独立 IP，符合地址池轮换特征；
• 同一 /16 下已有多个网段反复命中；
• ledger 中出现过的网段再次复发，需要提高处置优先级。

相反，独立 IP 很少但 UA 很丰富的共享出口更接近 NAT 场景，会被排除。只有评分达到阈值并命中至少一个硬信号，候选才会进入待下发集合。SLS 或黑名单读取任一步失败，Schedule 都直接结束而不修改线上；不设置 APPLY=1 时只做 dry-run；正式执行还受单次最大新增数量限制。

从一次处置到 CDN + NGINX 三层持续治理

链路验证成功后，Opsx 将它拆成三个资产绑定的 Shell Schedule：

两级 CDN Schedule 通过阿里云 CLI 查询真实云资源并更新边缘黑名单；NGINX Schedule 在两个应用 Runtime 上分别读取新增日志，只允许选出的主节点下发正式变更，再由管理脚本同步另一节点并 reload 两个副本。

NGINX 的候选对象分为两类：单个 IP 超过高频阈值时封精确地址；同一 /24 内出现多个来源，并同时满足请求总量、IP 数量、UA 特征和评分要求时，才进入网段候选。封禁 ledger 还会保存历史记录，对反复出现的网段增加权重，从而找出持续高频命中的抓取网段，而不是每次都把它当成一批全新的 IP。

这些高频任务没有继续交给 LLM。日志增量、阈值和排除规则已经可以由 Shell 确定表达，相同输入按相同规则执行，不需要等待模型，也不持续消耗 Token。LLM 被保留给新流量模式和证据冲突，而不是承担每 10 分钟一次的重复统计。

# 当前 NGINX Schedule 中决定影响范围的核心参数
SOLO_REQ=1200       # 单 IP 的 10 分钟阈值
NET_REQ=600         # /24 的 10 分钟总请求阈值
POOL_MIN=4          # 至少出现多少个不同 IP
POOL_MIN_REQ=300    # 地址池必须达到的最低请求量
UAS_MAX=2           # UA 过于集中才增加攻击嫌疑
MIN_SCORE=40
MAX_BAN=30          # 控制单次最大变更范围

Shell 保存上次读取位置，只分析增量日志；日志轮转时重置 marker；首次运行只建立基线，不拿历史日志直接封禁。CDN 和 NGINX 在变更前保存快照，执行后记录 ledger，为后续审计和回退留下依据。

Opsx 的 Schedule 也不只是一条放在服务器 crontab 里的命令。它绑定 Workspace 和目标 Asset，每次运行都有独立记录，执行路由、上下文、结果和后续 Issue 都留在平台。换掉 Agent 或 LLM，不会丢掉这套已经运行的治理状态。

自动封禁必须先控制误伤边界

Bot 的访问特征越来越接近正常用户请求。对这类程序化抓取而言，扩大封禁范围并不困难，困难的是将影响限制在有充分证据的对象上。

第一版 NGINX 规则上线后就出现了真实教训：它把“同一 /24 出现多个 IP、UA 比较集中”视为较强攻击信号，却没有要求这个地址池本身产生足够流量。结果 12 个低频网段被误封，其中包含 Apple、Meta 等正常爬虫来源。

这次误封直接推动了第二版规则的调整：

• 增加 POOL_MIN_REQ，地址多但请求量很低时不封整个网段；
• 搜索引擎蜘蛛只保留 Googlebot 和 Bingbot；Apple、Meta 等链接预览流量通过独立白名单处理；
• 过滤 403，避免已经被封的请求反复抬高统计；
• 优先封精确 IP，证据足够时才扩大到 /24；
• 保存请求量、IP 数、Top UA 和评分，方便人复核；
• 限制一次新增黑名单的数量，控制错误影响面。

kw_150 保存了这次规则演进所依赖的一项现场数据：在 20 万行 NGINX 日志样本里，403 占 18.7%。如果不排除这些请求，自动化会把自己的封禁结果再次当成攻击信号。

人的专业判断仍然重要。我需要告诉 Opsx 哪些爬虫对业务有价值、哪些内容允许搜索引擎发现、什么程度的流量可以接受，以及封禁网段是否需要审批。AI 不是天然知道这些业务边界；但一旦判断经过现场验证，就可以进入 Knowledge 和 Schedule，下一次不必再从头解释。

自动封禁之外，Opsx 也能快速解封

自动封禁要进入生产，必须同时具备快速恢复能力。发现正常来源受到影响时，只需在 Opsx 中创建解封 Issue，指定 IP 或 CIDR 并完成授权，平台就能根据关联的 Asset、Runtime 和已有 Knowledge 选择正确的恢复路径。

NGINX 解封由主节点上的受控脚本执行，随后自动同步另一个节点并 reload 两个副本。Opsx 最后分别读取两个运行中容器的 NGINX 配置，确认对应的 deny 规则已经消失：

解封 Issue
  → 定位 svc-emcs-nginx Asset 与主 Runtime
  → 执行 unban
  → 同步双节点并 reload
  → 检查两个运行配置，确认访问规则已恢复

CDN 解封则通过 Aliyun CLI 完成。Opsx 先读取当前完整黑名单并保存快照，再删除目标 IP；如果目标 IP 被某条 CIDR 覆盖，则同时处理对应网段，最后整表写回并再次读取 CDN 配置确认已经生效：

解封 Issue
  → 定位 CDN Asset 与 Aliyun CLI Runtime
  → Describe 当前 ip_list 并保存快照
  → 删除目标 IP 或覆盖它的 CIDR
  → BatchSet 下发完整列表
  → Describe 回读验证并记录解封结果

整个过程不需要重新登录服务器、切换 CDN 网页或手工查找域名配置。由 Issue 保存人的授权，由 Asset 确定操作对象，由 NGINX 管理脚本或 Aliyun CLI 执行恢复，再以真实运行配置作为完成证据。快速解封因此不是自动封禁的附属功能，而是这套机制能够安全进入生产的必要组成部分。

全站流量下降约一半之后，拦截仍在持续

治理效果分为两个阶段：传统蜘蛛的 User-Agent 黑名单先使 CDN 侧流量下降约 30%；随后增加伪装 Bot、IP 池和高频网段识别，治理前后的全站 CDN 流量最终下降约 50%。与此同时，2026 年 8 月 23 日命中 CDN 黑名单并返回 403 的请求占比仍接近 80%，说明这些来源并没有因为访问失败而立即停止，Schedule 仍在持续发挥作用。

这里的 50% 是治理前后全站 CDN 流量的对比，不是爬虫封禁完成度；接近 80% 则是 2026 年 8 月 23 日全部 CDN 请求中的 403 占比，也不是流量字节占比。结合登录、签到和 UGC 等互动指标没有出现同等幅度变化，可以判断减少的主要是已经识别并处置的程序化抓取，而不是正常用户活动。

这套规则也有明确边界。对于“同一个 UA 横跨数万 IP、每个 /24 请求量都很低”的分布式扇出爬虫，本地阈值很难在不扩大误伤的前提下完整识别，仍可能需要 JS Challenge、全网 IP 信誉或更专业的 Bot 管理能力。Opsx 当前优先持续清理证据充分的高频来源和成片地址池，而不是为了追求封禁数字无限降低阈值。

行业变化带来的用户活跃度和 UGC 压力仍然存在，但从治理前后的请求、登录和互动数据看，绝大部分正常访问以及保留的 Google、Bing 蜘蛛没有因封禁规则受到额外影响。与此同时，CDN、服务器与 OSS 的无效流量成本随之降低，也没有为此购买高价 WAF；原创内容被无节制批量抓取的情况得到明显遏制，遇到误封则有明确的解封和验证路径。

从执行结果看，这是一套反爬机制；从持续维护的角度看，真正发挥作用的并不是某一条正则或某一个模型，而是 Opsx 将过去分散的对象组织成了一套运维系统：

Asset
  确定 CDN、NGINX、主机、应用和云资源究竟是谁

Knowledge
  保存日志格式、正常爬虫、历史攻击、误封教训和操作边界

Runtime
  让 Shell 与 Agent 通过正确环境触达真实资产

Aliyun CLI
  把 SLS 查询和 CDN 配置读写变成可编排、可验证的云资产操作

Issue
  持有告警、判断、授权、执行、证据和结论

Agent + LLM
  分析新型流量、解释证据冲突并调整方案

Shell + Schedule
  让已经验证的规则稳定、快速、低成本地持续运行

这次实践也验证了 Opsx 的一个核心判断：AI 可以分析，Agent 可以执行，但生产治理还需要一个由资产和知识驱动的控制面。它让多个执行端共享上下文，让证据持续返回，让误判转化成新的知识和策略，并使这些状态不依赖某个 Agent 或某次对话而存在。

Bot 还会继续改变伪装方式。新的流量模式仍然需要 AI 和人一起判断，但已经解决过的问题会逐渐从 Agent 推理下沉为确定性 Shell；每次误判也会反过来修正 Knowledge 和策略。与单纯购买一个黑盒防护功能相比，我最终得到的是一套更贴近自己业务、能恢复、也会继续成长的流量治理能力。