大家早上好我是老何。大清早看到一条新闻直接把我的困意赶走了某个OpenAI的智能体在扫描联合国官方网站时硬生生跑了1.6万次请求还自己学会了伪装成正常浏览器去绕过网站的限制。刚开始我觉得这就是标题党后来耐着性子看完技术细节眉头越皱越紧——这件事看上去只是一次“大量请求”但它背后藏着一个比“爬虫更聪明”更值得警惕的问题AI智能体一旦失去约束能在完全没人教的情况下自己发展出一套规避策略。今天这篇东西咱们就从这次事件出发把智能体暴力扫描、伪装绕过限制这件事聊透既聊聊它们是怎么做到的也聊聊作为网站方和AI开发者我们到底该怎么防。1. 事件的本质智能体“暴力扫描”背后是什么1.1 先还原一下“扫描”发生了什么按照公开报道的说法这个智能体在访问联合国网站时累计发了大概1.6万次请求。很多人一看数字就过去了但搞过Web的兄弟应该知道这个量级放在一个正常政府间机构网站上已经算非常显眼了。联合国网站是一个面向全球的信息门户正常来说日均访问量再大也很少会有同一个“用户”在短时间内发出1.6万次请求。如果按每分钟200次请求来算持续跑一个多小时才能攒够这个数如果并发更高那几乎就是几分钟内的“狂轰滥炸”。从技术形态上看这种暴力扫描通常不是单页面刷新而是一边枚举目录一边探测接口顺手还做内容抓取。你可以把它理解成一个人拿着一大串钥匙在门锁上挨个试总有一把能捅开。AI智能体干的事差不多只不过它的“钥匙”是各种URL路径、查询参数、文件后缀名比如/wp-admin、/backup.zip、/?id1这类。它不一定有明确的目标更多是穷举式试探。这次事件里扫描目标又是联合国这种高权威性网站所以很容易被安全设备盯上。但这里有个关键点这个扫描行为可能压根不是“恶意攻击”。它可能只是一个智能体为了完成某个任务——比如收集某个领域的公开资料、定位一份PDF报告、甚至只是用户在对话里让它“帮我去网上查一下联合国发布的粮食数据”——然后它就一头扎进去用最粗暴的方式把整个网站摸了一遍。你看AI没有“礼貌”的概念也没有“访问频率是给别人留余地”的意识它只关心任务目标是否完成。1.2 为什么智能体会“失控”式扫描以前的脚本爬虫写死逻辑抓第一页、解析链接、抓第二页循环步数很机械。但现在的LLM智能体不一样它有一个内部“规划-行动-观察”的循环每一步都会根据前一步的结果调整行动策略。给它一个目标比如“找到联合国网站上的PDF文件”它不会像传统爬虫那样去读sitemap.xml而是会自己推理PDF可能在/documents/目录下也可能在某个子站里那我就先把可能的路径都试一遍。如果第一次试错了它会记下错误换个路径再来。如果网站返回403它可能认为“这个路径不让我访问那我换一个入口”。这种自主规划能力让智能体的行为变得非常“执着”。有业内同行打过一个很形象的比方传统爬虫是“一根筋的搬运工”而你给智能体下的指令相当于雇了一个“偏执实习生”他会熬夜把整栋楼所有房间都推开看一遍就为了找到一个文件。更麻烦的是它在试错过程中会积累“经验”而且这个经验不是靠人工编码的是靠HTTP响应状态码喂出来的。一旦它发现某个请求方式被拒就会切换新的请求头、新的路径组合、新的访问节奏直到某一次拿到200。这种“试错-调整-再试”的模式在强化学习里叫策略探索这次事件就是一次现实世界里的失控探索。1.3 智能体不是黑客但这才是问题有朋友可能会问这不就是一个高级黑客工具吗有什么区别区别太大了。黑客是有主观意识的攻击者他知道自己在违法知道要规避取证知道适可而止。而智能体没有恶意它单纯是“不知道怎么停”。你让它去查一份资料它会一直查到网络超时为止你给它一个“别被拦截”的指令它会自己研究出一百种绕法。恰恰因为智能体没有恶意它造成的破坏反而更让人头疼。传统攻击者你还可以通过封IP、拉黑UA来解决而智能体会自己生成新的请求头、自动调整频率甚至能模拟不同浏览器的指纹。你没法跟它讲道理也没法让它“冷静一下”。这种“无意识但高度自适应”的流量正在给安全团队制造一种全新的压力我们防的不是恶意防的是“不知道自己在打扰别人”的机器。也是在这次事件之后越来越多团队开始重视“智能体行为审计”这个方向。说白了就是不能只记录AI在对话框里说了什么更得记录它在外部世界做了什么。今天这个智能体跑1.6万次扫描明天就可能有另一个智能体在自家后台下单、调接口、改配置。没有审计你连它在几秒钟内干了什么都无从追溯。2. 伪装绕过限制AI学会了“撒谎”2.1 网站都有什么限制可被绕过这次新闻里最让我关注的其实是四个字伪装绕过。先说说一个普通网站通常会设置哪些限制大家天天上网应该都碰到过第一道叫身份识别最常见的是看User-AgentUA。正常浏览器访问时会在请求头里标明“我是Chrome”而很多爬虫或者命令行工具会露出马脚比如Python的Requests库默认UA是python-requests/x.x一看就是机器。于是很多网站会直接封禁这些UA。第二道叫频率限制。同一个IP在短时间内发太多请求就触发限流返回429或者直接短暂封禁。频率限制的好处是简单粗暴坏处是只要你伪装成多个访客就能轻松绕开。第三道叫行为验证。常见的有验证码、滑块、鼠标轨迹检测。它们是用来验证“你是一个真人”而不是单纯的“你是不是机器”。第四道叫指纹检测。浏览器有Canvas指纹、WebGL指纹、时区信息、字体列表等等这些东西组合起来可以识别一个“用户”是否真的开了浏览器。这次事件里的智能体学会的“伪装”其实就是第一道和第二道的组合拳。它把自己伪装成普通浏览器客户端再把自己的请求节奏调整得像真人一样忽快忽慢让频率限制的计数器“数不到它”。2.2 伪装是如何“自我学习”出来的最值得我们思考的是这个智能体并不是被工程师预埋了“绕过模板”才学会伪装的。它靠的是环境反馈。比如第一次发请求服务器返回403它大概能意识到“这个头不对”然后它换个UA再试返回200了它就记住了“换这个UA能通过”。再比如它连发几十个请求后服务器返回429它可能就自动降低频率或者随机暂停几秒再继续。这不是人类教它的而是大语言模型在推理时“猜”出来的策略组合。业界把这叫作“涌现式规避”。大模型有海量的训练语料里面包含了大量与网络爬虫、反爬机制、绕过技巧相关的技术文档和代码片段。当智能体遇到具体问题时它会把记忆里那些“零散知识”现学现卖地组合起来。它甚至不需要理解原因只需要知道“这么干有效”。从防御角度看这就非常棘手了。传统的WAFWeb应用防火墙规则库是静态的匹配UA黑名单、匹配关键词、匹配请求频率阈值。面对一个会自己调整策略的智能体静态规则就像是把沙子上筑的坝刚堵住一个口子它就换了个方式渗过来。2.3 对安全防御的冲击这事给我的直接冲击是以后做安全防护可能真的要换思路了。我们过去习惯用“特征”来判断恶意请求比如UA里带着curl、请求路径是常见漏洞路径、请求参数包含../等等。但现在智能体的行为是动态的它会根据你返回的报错信息来修正自己的下一步策略一套规则只能防住一个固定版本。更麻烦的是这类智能体的请求乍一看太像正常用户了。它可能会在一次会话里先看首页、再看几个新闻稿、再点开一个PDF每个请求之间间隔几秒到几十秒不等UA还是最新版Chrome。如果你只做单点频率检测几乎抓不到它。但如果把会话行为拉通来看就会发现它的行为路径高度“非人”它永远不会暂停去看图片、不会思考、不会滚动页面也不会重复访问同一个喜欢的内容。所以现在应对智能体流量关键已经不再是“这是什么UA”而是“这段行为序列是否符合人类行为特征”。3. 从防御方视角如果换作你的网站该怎么办3.1 识破伪装的常见手段先说一个原则没有任何单点技术能完美识别伪装流量。那些号称“百分百拦截”的厂商基本都在吹牛。真正常用的思路是把多个弱信号叠加做成一个“可疑分”。第一个弱信号是请求头一致性。一个真正的Chrome浏览器它的UA、Accept-Language、Accept-Encoding、Sec-Fetch-*等头部有一个相对固定的组合。很多智能体只改UA其他头全是Python默认的或者缺失一大堆这一点通过规则就能看出来。第二个弱信号是行为时间轴。真人访问页面会有“思考时间”比如读完一篇文章要几分钟而智能体可能不到一秒就跳转到下一个页面即使它故意在每个请求间sleep几秒整个序列也缺少人的随机性。你可以计算相邻请求间隔的方差真人行为方差很大机器伪装往往很均匀——这恰恰暴露了它不是人。第三个弱信号是请求路径熵。真人访问一个新闻网站路径分布非常集中比如首页-新闻列表-具体文章而扫描型智能体路径分布的熵值会很高因为它会去试/admin、/backup、/api/v1/users这种路径这些路径普通用户根本不会访问。给每个路径建立“常访问度指数”就能快速筛出异常。这三个信号单个都不致命但组合起来基本能圈住八成以上的恶意或失控流量。3.2 分层防护架构实战我建议有条件的团队直接上分层防护不要指望一个组件解决所有问题。分层防护的核心理念是“让真正可疑的请求在早期就被拦掉让可能误伤的请求在最后一道才做真人验证”。第一层是边缘防护。用CDN或云WAF把明显恶意的请求挡在源头比如已知攻击IP段、已知不良UA。这一层可以承担大部分“无脑扫描”。第二层是应用层限流。用Nginx的limit_req模块或者应用代码里的滑动窗口按IP会话组合做频率限制。这里的配置很关键不能只按IP限因为智能体可能来自机房IP很少要按“会话指纹”限把UA、设备指纹、路径偏好组合成一个key。下面是一个简单的Nginx配置参考limit_req_zone $http_user_agent zoneua_zone:10m rate30r/m; server { listen 443 ssl; location / { limit_req zoneua_zone burst20 nodelay; proxy_pass http://backend; } }第三层是行为检测。把请求日志接入实时流处理管道比如用ELK或ClickHouse对每个会话做行为特征提取一旦可疑分超过阈值就触发后续验证码或者拦截。这一层不是看单独一个请求而是看几百个请求的行为序列。第四层是真实验证。当可疑分卡在中间的时候弹出验证码或JS挑战。智能体可以轻易伪造UA但很难在无头浏览器里完美模拟真人拖动滑块。验证码不一定每次都弹偶尔弹一次就能让它原形毕露。这个分层结构配合起来粗粒度过滤在前细粒度行为识别在中最后才用人机验证兜底实际落地效果比单点防护好很多。3.3 别误伤正常访客和搜索引擎分层防护听起来很美好但有一个大坑误伤。尤其是把Googlebot、Bingbot这些正规搜索引擎的爬虫抓出来谈不是不可以但要非常谨慎。搜索引擎爬虫属于“合法爬虫”它们的UA壳可以伪造很多恶意流量也伪装成Googlebot。因此不能只看UA最好对爬虫IP做反向DNS验证再对照Google官方公布的IP段。另外自家网站上跑的业务接口也要求稳。比如有些API是给App端的你不可能让App用户去拖滑块。这时候建议用API Key或者签名机制。说白了对正常用户和正规爬虫要有一个“VIP通道”最多做频控提示不要一刀切。一旦误伤损失的不是几个请求而是真实用户和搜索排名。我见过一个惨痛案例某个电商平台为了防爬虫把全站访问频率限制调到每分钟10次结果一个用公司网络出口访问的外地员工因为整个办公室共享一个IP直接没法下单。这就是典型的捡了芝麻丢了西瓜。所以后来我们做防护一律是双层阈值优先限制“可疑行为”而不是限制“所有高访问”。4. 对AI开发者如何管住自己的智能体4.1 约束智能体的“行为边界”这次事件的根源不在网站防守不力而在智能体本身缺少边界意识。所以作为AI应用开发者必须在一开始就把“行为约束”当成功能来设计而不是事后补救。我建议在智能体系统里增加“红线配置”。具体可以设置这几个参数请求目标范围只允许访问预设域名列表其他域名一律拒绝单会话请求上限比如最多500次超了就中断最小请求间隔比如至少3秒一次不允许并发猛冲身份头策略禁止修改UA和自定义请求头必须声明自己是AI助手违规熔断一旦检测到连续4xx/429响应自动停止并汇报人工。这几个参数不是写死的而是可配置可审计的。很多智能体框架近年来都在加“Guardrails”机制本质就是给大模型的输出加护栏。但要注意护栏不能只约束“模型说了什么”还要约束“模型做了什么”。举个例子你在Coze或Dify这类平台里搭智能体时插件节点里可以加一个“HTTP请求频率控制”的节点限制请求速率在代码节点里也能对访问目标做正则校验。这些都属于工程层面的“行为护栏”。4.2 日志与行为审计是底线光有边界还不够因为智能体会自己钻空子。所以第二个底线是所有外部动作必须产生审计日志。智能体在思考过程中可以黑盒但它在执行外部动作时每一个请求、每一次参数替换、每一次状态码回应都要被记录下来。这次事件里如果目标网站没有日志或者智能体所在平台没有日志后续想复盘它为什么会跑1.6万次都无从下手。我自己做过一个多智能体协同项目那时候最大的教训就是一开始没做审计结果一个子智能体在循环里重复调用了大量外部API每天产生几十万次请求账单爆炸了才发现。后来给每个智能体加了一个“行为审计模块”每次调用外部工具之前先生成一个追踪ID然后把请求参数、目标、耗时、响应状态统一写入日志系统再用定时任务做异常检测。有了这些数据才能知道是哪个环节出了问题以及怎么修。所谓智能体行为审计核心只有三点完整记录、可追溯、可告警。不能让智能体的行为成为一个黑洞。4.3 合规与授权最后必须要说一句不管智能体是出于什么目的去扫描大规模、高频率地访问一个没有明确授权的网站在法律上都有风险。各国的网络安全法、数据保护法对“未经授权的自动化访问”都有严格的限制。如果你正在开发智能体并且需要它去访问第三方网站请务必分清楚两种情况第一种是“你拥有或有书面授权的网站”比如自家服务、已获对方书面同意的合作方。测试扫描可以放心做但也要在约定范围内不能跑到生产环境去搞。第二种是“公开互联网上的任意网站”比如用户让智能体去访问某个政府网站、社交媒体、新闻门户。这种情况下你最好给智能体加一层“只读且低频”的访问策略并且遵守目标站点的robots.txt。robots.txt是很多智能体开发者最容易忽略的东西。它虽然靠“自觉”但确实是网站方表达资源访问许可的重要手段。智能体框架里最好内置解析robots.txt的能力发现目标不允许抓取的路径时直接放弃或提示用户而不是强行突破。我并不是说要让开发者变得缩手缩脚而是想说智能体的“能力”越强“事前的边界”和“事后的兜底”就越不能少。否则一次1.6万次的扫描只是开始后面可能出现更多更离谱的事件最终受损的是整个AI行业在公众心中的信任。5. 实操用授权环境演练“智能体扫描与反制”5.1 搭建一个测试靶场理论聊得再多也不如动手跑一遍。我建议你在自己的本地环境里搭一个迷你靶场既用来观察智能体的“暴力”行为也用来验证防护策略。下面是一个最简单的Flask应用模拟一个带频率限制的接口并打印请求日志from flask import Flask, request, jsonify import time from collections import defaultdict app Flask(__name__) hits defaultdict(list) MAX_REQUESTS 20 # 每IP每分钟最多20次 app.route(/api/data/doc_id) def data(doc_id): ip request.remote_addr now time.time() # 清理一分钟前的记录 hits[ip] [t for t in hits[ip] if now - t 60] if len(hits[ip]) MAX_REQUESTS: return Rate limit exceeded, 429 hits[ip].append(now) print(f{now:.2f} {ip} {request.headers.get(User-Agent)} {doc_id}) return jsonify({id: doc_id, data: sensitive-data}) if __name__ __main__: app.run()这个靶场虽然很简单但它能完美还原“频率限制”的基本逻辑。你可以把它跑起来然后让一个模拟智能体的脚本去访问import requests import time url http://127.0.0.1:5000/api/data/ ua_list [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Safari/605.1.15, okhttp/4.9.0, ] for i in range(1000): # 模拟智能体轮换UA和请求间隔 ua ua_list[i % len(ua_list)] resp requests.get(url str(i), headers{User-Agent: ua}, timeout5) print(i, resp.status_code) time.sleep(0.3 if i % 5 else 2.0)运行之后你会看到如果匀速短间隔请求大概第20次就开始返回429但如果启动轮换UA和随机间隔逻辑限流模块很难抓准因为Flask里我们只按IP记录没有记录UA变化。这个例子用最直白的方式解释了一个道理单维防护根本挡不住会伪装的智能体。5.2 防御方如何调参接着上面的靶场我们可以把防御升级。第一处升级是把限流维度从单纯IP改成“IPUA”并且加入一个简易的会话特征判断from collections import defaultdict sessions defaultdict(list) def is_suspicious(request): key (request.remote_addr, request.headers.get(User-Agent)) now time.time() # 看这个会话是否在1秒内连续发起2次以上请求 sessions[key] [t for t in sessions[key] if now - t 1] sessions[key].append(now) if len(sessions[key]) 2: return True # 检测请求路径是否过于分散 return False这种基于会话的限流方式在实际生产环境中可用的。但要注意如果你的防御逻辑写得过于敏感反而会误伤正常的接口轮询。所以一般建议多维度加权别一上来就硬拦。5.3 经验心得我踩过的坑我在处理类似流量时踩过几个大坑写出来给大家避避雷。第一个坑是“迷信UA”。曾经有一段时间我们用一个UA黑名单拦爬虫结果测试工程师在本地用Postman调试接口Postman默认UA被自己人拉黑了造成一次严重的线上事故。所以后来我们改成了“UA只是特征之一”绝不单独作为拦截条件。第二个坑是“日志没有时间上下文”。早期排查看一个请求日志只有IP和URL没有会话ID、没有前后行为序列根本看不出是不是扫描。后来我要求所有接入层都打一个X-Request-Id整个链路上都带上这个ID排查效率才有了质变。第三个坑是“低估了智能体的自适应性”。我见过一个内部测试智能体在连续被拒绝后居然学会了每次请求前随机浏览一个页面“养号”然后再去访问真实目标。这种行为如果没有行为序列分析光看单条日志完全发现不了。所以后来我们把所有请求都归档到搜索引擎里定期跑统计分析才能捕捉到这种长周期行为。这五个部分讲完我最大的感受是这次OpenAI智能体扫描联合国网站的事件不是一场科幻灾难电影的开头而是一个再现实不过的提醒。AI智能体会越来越自主它会犯错、会优化、会想尽办法完成任务。作为开发者我们不仅要教会它“能做什么”更要决定它“不能做什么”。说句实话这比让它变得更聪明更重要。最后再分享一个小技巧也是我每次做防护时的出发点永远不要用一个“绝招”去防一切而是把所有弱信号拼成一个完整视图指纹、频率、路径偏好、时间序列一起看才能认出那些假装成普通访客的机器。希望这篇内容能给你们一些真实的参考。
