抖抖村流量突然翻倍的那几天，我其实是开心的。服务器告警弹出来的时候，脑子里第一反应是"业务要起飞了"。但打开后台一看，新注册用户数纹丝不动，在线时长中位数掉到了不到二十秒，连平时最活跃的几个老用户，行为轨迹都变得陌生起来。再翻会话记录，一批又一批"用户"从同一个IP段涌进来，访问路径整齐得像阅兵方阵。那一刻我突然意识到一件事：我的用户，可能根本不是人。
这篇文章不聊哲学，聊的是实实在在的工程问题。过去半年我一直在和"非人类用户"打交道——从最早靠肉眼识别，到后来搭了一套自动化检测系统，中间踩了不少坑，也总结了一些可复用的方法。无论你是独立开发者、数据分析师，还是在大厂做风控或增长，这篇内容应该都能给你一些参考。我会讲清楚机器流量到底长什么样、藏在哪些数据特征里、为什么要分级拦截而不是一刀切，以及当AI Agent成为新一批"用户"之后，产品设计该怎么调整。
1. 一场诡异的流量"繁荣"：并发翻倍，收入纹丝不动
先说我是怎么发现问题的。我有个SaaS工具，日常并发在几百左右，某天凌晨两点开始，并发一路飙到两千多，持续了将近三个小时。正常情况下这个时间点应该是低谷，凌晨的流量曲线通常比白天矮一大截。直觉告诉我这不正常，但打开实时监控，看到的却是四平八稳的指标——页面加载正常，接口响应正常，没有报错，也没有明显的高负载拖垮服务。
诡异的地方在于，服务的"访问量"上去了，但业务指标完全没动。注册量没涨，付费转化没涨，连老用户的活跃度都没涨。PV涨了，UV涨了，唯独"人"没涨。我把那段时间的访问日志导出来，筛出凌晨两点的会话记录，翻了大概二十分钟，后背开始发凉：几乎所有的会话都是同一个固定的路径——首页、登录页、某一个接口，然后就没了，停留时间集中在1.2秒到1.8秒之间，标准差小得不像真人会有的行为。
1.1 为什么"流量高但转化差"是第一个警报
"流量高但转化差"这个信号，我能想到的最贴切类比是：一家餐厅门口排了很长的队，但进店的人没有一个坐下来点菜。这时候你要担心的不是厨师出餐慢，而是排队的人是不是真的想吃饭。
流量数据如果只有PV、UV这两个层面，很容易被表面的繁荣骗过去。必须叠加转化漏斗看，才能暴露问题。我自己惯用的做法是拉一条五层漏斗：访问次数→登录行为→核心功能触发→留存行为→付费行为。如果前两层涨了、后三层没动，那前两层的"用户"里大概率混进了非人类访客。反过来，如果全链路一起涨，才更像是真实用户增长带来的结果。
另一个我后来养成的习惯是看时段分布。真人用户的活跃时间服从日出日落规律，工作时段集中，深夜低谷明显。机器人不一样，它不受生物钟约束，可以凌晨三点精准地以每秒几十个请求的节奏扫你的接口。所以当我看到凌晨时段的流量曲线出现"平顶"甚至"尖峰"而不是"深谷"时，直接就会提高警惕。
1.2 从"人肉排查"到"不得不自动化"的转变
发现问题最初的三天，我还在用笨办法排查——手动翻日志，把可疑的IP摘出来，再用IP反查工具验证归属地。这个办法对付几十个可疑会话还行，但等到每秒几百个请求涌进来，你根本翻不过来。人肉筛查效率太低，而且容易被机器人刻意模仿真人行为骗过去。
真正推动我下定决心做自动化的，是一次典型的"打地鼠"经历：晚上封了一批IP，第二天早上发现它们换了一拨IP继续扫，手法一模一样。你封，它就换；你加规则，它就改UA。它们的技术门槛不高，但胜在量大、速度快、不知疲倦，光靠人工根本不在同一个数量级。
于是我决定把思路改掉，不追IP（追不完，而且代理出口IP多的是），转而去识别行为和指纹。机器人的IP可以随便换，但它的行为节奏、浏览器指纹、请求特征这些东西，换起来要困难得多，也更容易露出马脚。这套思路后来演变成为我整个检测体系的地基。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 机器在数据里留下的指纹：从UA到行为节奏
识别"非人用户"，本质上是在回答一个问题：这台设备后面坐的到底是一个人，还是一段脚本。没有哪个单一信号能百分之百下结论，但多个信号叠加在一起，置信度就非常可观了。我把这些信号分成四类，每一类都有自己的代表特征和检测逻辑。
2.1 HTTP头与UA：最容易被伪造、也最值得看的起点
很多人觉得User-Agent字段没什么用，因为随便哪个脚本都能伪造。这话对一半。UA确实最容易被伪造，但大量低质量机器人根本不伪造，它们直接用默认的UA字符串。你的"用户"里如果频繁出现 python-requests、Go-http-client、okhttp 这类特征，几乎可以断定有脚本在访问。
深层来看，真正值得关注的不是UA本身，而是UA与真实浏览器行为之间的"不匹配"。比如UA声明自己是Chrome 120，但HTTP头里没有 sec-ch-ua 平台信息，或者声明是Windows系统，但字体列表里没有中文字体——这些细节对于普通浏览器用户几乎不可能出现，组合起来就是非常强的非人类信号。
我自己写过一个很基础的黑名单正则，把常见编程语言HTTP库和知名爬虫框架的UA特征捞出来，命中之后直接打上"疑似机器人"标签：
python复制import re
BOT_UA_PATTERNS = [
r"python-requests", r"Go-http-client", r"okhttp",
r"Scrapy", r"curl/", r"wget", r"HeadlessChrome",
r"selenium", r"Playwright", r"Puppeteer"
]
def classify_ua(user_agent: str) -> str:
for pattern in BOT_UA_PATTERNS:
if re.search(pattern, user_agent, re.IGNORECASE):
return "bot"
return "human_or_unknown"
这只是第一道筛子，不能只依赖它。因为稍微用心一点的机器人，会把UA改成和真实浏览器一模一样的东西。所以UA只能做初筛，真正靠谱的还得往下看。
2.2 行为节奏：真人会犹豫，机器"零延迟"
我观察过大量真实用户的行为轨迹，一个很重要的发现是：真人使用产品的过程充满了"低效"。滑过去又滑回来，看了一半停了十几秒，鼠标在按钮附近晃两下再点击，这些无意义的微小动作构成了人类行为的独特噪声。
机器完全不同。脚本执行的是一串确定指令，每一步之间几乎不存在随机延迟。就算开发者给脚本加了随机sleep，这个"随机"的分布通常也过于均匀——真人的思考停顿呈长尾分布，偶尔会有10秒以上的超长停顿，而脚本的等待时间几乎总是集中在几百毫秒到几秒之间，很少出现极端值。
我常用的一个统计指标是"页面停留时间变异系数"。真人会话里，不同页面的停留时长差异极大，变异系数通常在0.8以上；而机器人的停留时长如果做过均值处理，变异系数往往低于0.3。另外，"鼠标移动轨迹"和"滚动行为"也是很强的区分信号。真人移动鼠标时走过的是弧线，有加速、有减速，还会过度偏移；脚本模拟鼠标则通常是直线，速度恒定。通过浏览器端JS采集mousemove事件，把这些轨迹存下来做一次简单分析，识别精度会提升一大截。
2.3 浏览器指纹：Canvas、WebGL与硬件并发
浏览器指纹的基本思路，是让前端脚本读取当前设备的各种渲染与硬件信息，拼成一个几乎唯一的标识符。同一个浏览器在不同设备上渲染出来的Canvas图片会有细微差异，WebGL的渲染器名称、GPU型号、支持的扩展列表也不尽相同，再加上屏幕分辨率、语言列表、时区、字体、CPU核数、内存大小等，组合出来的指纹在真人群体里区分度是很高的。
对于检测机器人来说，指纹的意义刚好反过来。无头浏览器（headless browser）和完整浏览器在指纹上差异明显。最典型的就是 navigator.webdriver 属性，无头模式自动浏览器下它会是 true，普通浏览器根本不会出现这个属性。另外，Canvas指纹如果每次刷新都完全一样，也可能有问题——同一个人同一台设备指纹稳定是正常的，但如果一个会话里短时间内出现几十个各不相同但又高度相似的指纹，那大概率是脚本批量生成的环境。
我在项目里集成过一个轻量指纹库，采集了约二十项信息，生成一个hash值。单看某个hash意义不大，真实用户里重复率本来就低，但把指纹和会话数结合：如果同一个指纹出现在大量会话里，判定为机器人；如果一个IP下出了几十个不同的"新指纹"，同样怀疑是脚本在批量开session。
2.4 IP与网络特征的组合判断
IP特征算是老生常谈，但还是值得提两个有效维度。第一是IP的ASN归属：如果大量访问来自某个云厂商的数据中心网段，而你的目标用户是普通C端人群，那这批流量就很可疑，因为普通家庭宽带用户不会从数据中心出口访问你的产品。第二是IP的变化频率和地域一致性：真人坐地铁会切换基站，IP会变，但通常在地理上是连续变化的；机器人代理池里的IP则可能上一秒在北京、下一秒在法兰克福，而且切换频率极高。
还有一个进阶指标叫TLS指纹（JA3/JA4），通过TLS握手包的特征识别客户端类型。这个指标对脚本库特别敏感，因为Python的requests库和Chrome浏览器的TLS栈在ClientHello上存在明显差异。不过这需要流量层面的采集能力，通常要借助网关或边缘节点来做，对于普通SaaS项目来说门槛略高，放在这里供有条件的朋友参考。
3. 三种"不是人"的用户：识别特征与真实动机
把识别指标说清楚之后，我想再展开讲讲"非人类用户"的构成。它们并非铁板一块，不同种类的机器人，行为特征和运营动机完全不同，应对方式也自然不同。
3.1 爬虫型访客：来去匆匆，从不真正交互
搜索引擎蜘蛛是唯一一类你不用拦的爬虫，Googlebot、Bingbot这些，UA特征稳定、robots遵守度高，识别出来之后放行就好。真正需要警惕的是两类：一类是竞争对手的采集爬虫，专门把你的产品页面、价格信息、内容库大批量拉走；另一类是AI公司的数据采集器，它们的UA通常直接写明是某个大模型的采集爬虫，但也有相当一部分会伪装成普通浏览器，偷偷摸摸地爬。
爬虫型访客的典型行为特征是：覆盖率高但深度浅，短时间内访问大量页面，但从不点击、不登录、不触发核心交互。它们的请求速率很高，平均到每个页面的停留时间极短，在日志里表现为"刷屏式的GET请求瀑布"。识别这种类型，最有效的指标是"点击到达率"——一个会话内，看到页面之后真正产生交互动作的比例。真人即便只是随便逛逛，也免不了滚动页面或移动鼠标，但这部分行为在爬虫会话里几乎为零。
3.2 脚本型机器人：注册机、点击农场与薅羊毛
脚本型机器人比爬虫更"高级"一点，因为它会模拟交互流程。注册机批量创建账号，点击农场刷广告和点赞，薅羊毛党在促销活动里疯狂抢优惠券——这些场景里，脚本会完整走完注册、登录、点击等步骤，行为模式看起来很接近真人。
但脚本毕竟不是人，细节上总会露馅。我观察过一批被薅羊毛的账号：它们输入表单的速度快得像粘贴，填表时间几乎为零；验证码通过率高得离谱；所有账号的昵称生成规则相同，密码强度相似甚至相同。更明显的是，这批账号在注册后极短时间内就完成了大量操作，真人从注册到熟悉产品至少需要几分钟，而脚本可以在0.5秒内完成"注册→登录→领券→退出"的全流程。
识别这类脚本时，除了行为节奏，建议把"账号维度特征"也加进去：同一设备指纹关联了多少账号、同一IP关联了多少账号、大批账号是否在同一时间段集中注册。这类模式一旦出现，几乎可以实锤是脚本批量操作。
3.3 AI Agent：正在快速增加的新型访客
前两类"非人用户"是过去十年的老对手，而最近一年我明显感觉到第三类在快速冒出来，就是AI Agent。大模型应用在调用你的API的时候，它会以程序的身份出现，行为逻辑却接近真人——它会有"上下文"、有"多轮对话"、还会根据你的返回结果调整下一步动作。更常见的情况，是AI摘要助手、RSS阅读器、翻译插件这类工具在后台替你访问网页，它们带着"半真人半机器"的属性，很多还主动在UA里标注了 gptbot、Google-Extended、ClaudeBot 之类。
这类访客带来一个新的问题：你很难简单把它定义为"坏流量"。AI Agent读你的内容、调用你的接口，可能给你带来真实的用户（比如用户通过ChatGPT触达你的产品），也可能直接拿走你的内容而不产生任何直接回馈。对待它们，策略上不能一棍子打死，更多时候要做分级限制而不是一刀切封锁。
4. 分级拦截体系：从被动观察到主动过滤
识别做到位之后，接下来的问题就是——怎么处理。我强烈建议不要搞"发现即封杀"的一刀切策略，误伤真人的代价往往比漏过几个机器人更大。我最终落地的方案是四级处理流程，每一级都有不同的强度和代价。
4.1 第一层：基础过滤，挡掉最明显的噪音
第一层完全是规则过滤，零误伤风险。包括拉黑已知恶意IP网段、拦截数据中心IP段（通过ASN库匹配）、丢弃满足黑名单UA正则的请求、对单个IP的请求频率做硬性限制（比如每秒超过20次直接返回429）。这一层过滤掉的流量占全部机器流量的60%左右，且完全不需要机器学习，部署成本极低。
注意：这一层过滤和封禁的建议是基于工程实践中的通用保守策略。任何过滤规则都必须配合监控告警，防止规则误伤真实用户而没人发现。
另外建议在robots.txt里处理好爬虫规则。虽然恶意爬虫根本不看robots.txt，但规范的大模型采集器和搜索引擎蜘蛛基本都会遵守，这能帮你减少一大类"无需对抗"的流量。
4.2 第二层：行为评分，给每个会话打一个"人类分数"
第二层是行为评分模型，也是整个体系的核心。我把前面讲到的所有行为信号转换成分值，然后加权汇总，给每个会话打一个0到100的"人类分数"。权重设计大致如下：
| 信号维度 | 具体指标 | 评分示意 |
|---|---|---|
| 请求节奏 | 页面间等待时间的变异系数，低则扣分 | 变异系数<0.3扣20分 |
| 交互深度 | 是否有滚动、点击、鼠标移动等真实交互 | 无任何交互扣25分 |
| 浏览器指纹 | 是否缺少Canvas指纹或出现异常属性 | 异常扣20分 |
| 网络行为 | 单IP请求频率、ASN归属是否数据中心 | 高频或数据中心扣20分 |
| 输入行为 | 表单填写速度、输入间隔的随机性 | 速度过快或过于规律扣15分 |
最终分值低于40的，进入观察名单；低于20的，直接触发验证码挑战。这个评分体系部署起来不算复杂，前端采集行为事件，后端聚合打分，中间用消息队列缓冲流量压力。初期规则可以定得保守一些，后续通过人工复核持续调整权重。
4.3 第三层：蜜罐与陷阱，让机器人自己暴露
蜜罐是个挺老的技巧，但在实战里依然管用。具体做法是在页面上藏几个真实用户完全看不到的元素——通过CSS把链接移出视口、设置 display: none、或者把一个输入框用代码隐藏起来。真人浏览页面时不会触发这些元素，但机器人爬虫会直接抓取页面里的所有链接和表单字段，一旦触达蜜罐，基本可以确定是脚本。
我在一些敏感接口里也放了陷阱：在注册表单中加了一个完全隐藏的字段，填写该字段的请求一律判定机器人。效果非常好，薅羊毛脚本的市场化工具大多会抓取所有input字段自动填充，根本不会管它是否可见。
蜜罐的价值不在于拦截量，而在于极高的置信度。它给了你一个"零误伤"的判定信号——任何触发蜜罐的会话都可以放心封禁，不需要担心把真人推到了验证码面前。
4.4 第四层：挑战升级，验证码、JS挑战与指纹库
前三层都没拦截住的，第四层做最后兜底。核心手段是验证码。但我强烈建议不要一上来就甩给用户一个滑块或图片识别验证码，那是在消耗真人的耐心。更好的做法是"隐形验证"：通过JS challenge方式，让浏览器完成一个默认不会自动执行的计算任务，正常浏览器几百毫秒就能完成，而无头浏览器会因为缺少完整渲染环境而失败或超时。
指纹库在这里也起到关键作用。当某一个指纹已经在此前被判为机器人，那么之后任何携带同指纹的访问请求，都可以直接跳转到验证码页面；反之，如果指纹是"优良记录"，则可以享受免验证直接通过。这就等于把"信用体系"引入了访问控制，灵活度和体验都比固定规则好太多。
整个过程我画过无数遍流程图，但实际落地时比图更复杂——真正的难度不在于每个环节的算法，而在于环节之间的阈值如何联动。我建议一步步调，先跑通第一层和第二层，稳定运行一两周，再逐步加入蜜罐和挑战，降低误伤风险。
5. Agent即用户：产品设计必须面对的新现实
现在回到标题。识别和管理好"非人用户"，是防守侧的工作。但过去半年我越来越强烈地感觉到，进攻侧的问题更值得思考，不是如何防止AI访问，而是如何为AI设计产品。
5.1 真正的变化：AI开始像用户一样"用"你的产品
如果只是把AI Agent当作需要拦截的坏流量，会错过一个更大的趋势。现在已经有相当数量的大模型应用通过API和MCP协议与外部工具交互，它们会主动读取你的文档、查询你的数据、调用你的接口，甚至模拟用户操作你的网页。翻译插件、AI摘要工具、语音助手，这些都在以"用户"的身份消费你的产品。
你可以观察自己产品的访问日志，留意那些UA里带有 GPTBot、ClaudeBot、Google-Extended、PerplexityBot 等特征的流量。它们的访问深度往往不低，访问内容集中在核心功能页面、定价页、API文档，行为和搜索引擎爬虫类似，但更智能——它们会记住上次访问的状态，会根据页面的结构提取有效信息。
5.2 数据污染：指标系统面临的新威胁
对做数据和增长的人来说，AI Agent带来的不是"流量污染"这么简单，而是整个决策依据被污染。如果你的周报里写着"活跃用户上升20%"，但这里面有15%是Agent在访问你的文档页面，那你对这个产品健康状况的判断就是错的。
我现在的做法是把流量分成三个泳道打标签：真人、爬虫型机器人、AI Agent。真人流量继续作为核心用户指标；爬虫型机器人进黑名单重点防控；AI Agent单独统计，作为"品牌可见度"和"AI生态触达率"参考，但绝不混入产品核心转化指标。报表分层在数据治理上真的很关键，能做到的话，很多判断失误都能避免。
5.3 产品的两种选择：友好对待还是设置边界
面对AI Agent，我不觉得"彻底开放"或"彻底封锁"是对的。更现实的策略是按内容价值分级。公开的营销页、产品文档、技术博客，可以放心向所有Agent开放，这是免费的传播渠道；需要登录才能访问的数据、成本较高的API接口，则通过API密钥、配额管理和服务条款来明确边界。
我在自己的服务条款里明确写明了自动化访问规则，包括允许的爬虫类型、请求频率上限、和哪些行为会被视为滥用。有规则的好处是，当你需要和某家AI公司沟通采集边界时，可以拿条款说话。另外，如果你的网站具备"语义化结构"——清晰的标题层级、规范的JSON-LD结构化数据、良好的meta描述——对Agent抓取内容也是一种正向引导，它会抓到更准确的信息，减少无效的反复抓取。
5.4 从"防范AI"到"服务AI"：一个新机会
最后想讲一个可能听起来有点超前、但已经在发生的方向：把AI Agent当作正式用户来服务。很多智能助手现在需要实时获取外部信息来完成用户请求，如果我的产品提供结构化的、更新及时的、允许程序访问的数据，就更容易被AI推荐给它的用户。
这有点像过去十年的SEO，只不过现在的"搜索引擎"变成了AI助手。你在自己的站点里给Agent提供一份友好的入口（比如一份专门给机器读取的产品说明书、一份清晰的sitemap、开放一部分公开API），就是在为未来的"AI推荐流量"打基础。等Agent真正开始替用户做决策的时候，你的产品在不在它考虑的范围里，很多时候就取决于它能否理解你的网站和接口。这波趋势里，我选择站在拥抱这一侧，至少保持一个开放和容错的姿态。
在这套识别与应对体系上线之后，我的后台又恢复了"低并发、高转化"的正常状态，报表里那些涨了但不赚钱的流量，也终于找到了它的来处和去处。回头再看那次凌晨两点的流量突增，反而要感谢它——没有那一次意外，我不会意识到自己一直在和一个"看不见的用户群体"打交道。
如果你手上也有一款正在运营的产品，我的建议是，花一个下午去看看最近的访问日志，别再只盯着PV和UV了。拉开会话粒度，看看停留时间、交互深度、行为节奏，那些藏在数据缝隙里的规律会让你重新认识自己的"用户画像"。而且，这个动作做一次是不够的——AI Agent的占比还在涨，今天不需要处理，不等于下个月也不需要。