正式宣布：流量安全分析 Agent 1.0 已上岗，一个 7*24 的实习生

最近团队收到的各种bot处置需求出现的爆炸性增长，属实有点超负荷。

比如有人在爬支付业务的敏感信息，有人用脚本批量发视频，有的在爬地图数据……各种业务线的风险 case 像潮水一样涌过来，同时还得盯着已有策略的异常波动告警。响应率、完成率这些指标压在头上，坦诚地讲，人手就这么多，真的顾不过来。

更让我头疼的是，这些 case 的分析过程其实 80% 都是相似的——查 TLS 指纹、查设备标签、查 IP 类型、验证特征聚集性、评估误杀……骨架大同小异，但每次都得根据具体 case 重新拼 SQL、重新等结果、重新想下一步。经验活在人脑子里，散落在临时写的 SQL 片段里，换个人接手质量就波动。

我当时就在想，有没有可能搞一个 Agent，把这些基础的排查分析先跑完？ 就好比业务方提安全需求的时候，不只是说"这个接口有问题"，而是连基础的风险情况也一并排查好了——TLS 分布什么样、有没有可疑的设备特征、攻击流量大概什么规模——我拿到手就能直接进入判断环节，而不是从零开始写 SQL。

想明白这事儿之后，我就开始搭了。今天不讲虚的，分享一下从 0 到 1 撸这个流量分析 Agent 的踩坑日记。

动手之前：别上来就调 API

很多人做 Agent 的第一反应就是去调教大模型——换 GPT-4、试 Claude、搞 fine-tune……折腾一圈发现效果还是拉胯。

我也走过这条弯路。后来想明白了，模型本身没那么重要，重要的是你想清楚一个 Agent 到底由什么组成。

在我眼里，一个能干活的安全 Agent 就像个实习生，你得给他配齐装备：

有一说一，LLM 本身是不带安全领域知识的，更没权限进你的数据库。你要是直接问它"这波流量正常吗"，它大概率会给你编一段看起来很专业的废话。

这里我想泼一盆冷水：你在网上看到的那些 Agent Demo，基本上都是在没有真实攻击流量的环境下跑的。到了生产环境，Agent 犯的错比新人还离谱。80% 的工作量不在模型选择上，在 SOP 设计上。

第一版：从信心满满到想删 Prompt

最开始，我给 Agent 写了一份简单的步骤清单：

1. 查 TLS 指纹分布
2. 查IP用户聚集特征
3. 查设备风险标签
4. 给出拦截建议

清单写完的那一刻，我甚至觉得这事儿已经成了大半。

然后 Agent 跑完，给我的建议是：建议封禁具体 IP 地址和用户 ID。

我当时的反应是……盯着屏幕愣了三秒。在流量安全领域，封 IP 跟打地鼠没区别——攻击者换个代理成本几乎为零。这是我们团队新人第一天就会被教的常识。但 Agent 不知道啊，它觉得这逻辑没毛病。

更让我头疼的是，每次输出格式都不一样，结论长短不一，根本没法沉淀对比。跑了五个 case，五种输出格式。

我当时真想把这份 Prompt 删了重来。

冷静下来之后总结了一下——

步骤列表只告诉它做什么（What），没告诉它为什么（Why）。没有 Why，遇到边界情况它就只能靠表面逻辑填空。

说白了，我给它的是一份执行脚本，不是一套思维框架。

重构：从步骤列表到四阶段框架

我意识到，老司机的直觉其实不是直觉，是一套沉淀了十几年的分析框架。只是这个框架一直活在脑子里，从来没被写出来过。

这次我逼自己把它掏出来，重构成了四个阶段：

• Phase A — 理解攻击。 先搞清楚攻击者是谁、在做什么、动机是什么。强制执行，不允许跳过。这一步最容易被急性子跳过——直觉告诉你赶紧查特征、上策略，但如果你连攻击者画像都没搞清楚，后面查什么特征？
• Phase B — 验证特征。 每个候选特征必须用数据证明聚集性。直觉不算数，查询结果算数。关键是要回答两个问题：这个特征在异常流量里占比多少？在正常流量里又占比多少？
• Phase C — 评估误杀。 拦截这个维度会波及多少正常用户。C 没过，B 的结论不能进入最终建议。这条规则是硬门槛，不是"尽量做"，是"不做就不能往下走"。
• Phase D — 输出结论。 格式固定，每条建议附查询数据。不允许自由发挥。固定格式的好处是可以跨 case 横向对比，也方便其他人 review。

步骤清单和分析框架是两回事。 步骤清单告诉你"下一步做什么"，框架告诉你"我现在处于哪个阶段，这个阶段的目标是什么"。遇到没见过的攻击模式，步骤清单会卡住——因为它没预设这一步。框架不会，因为它的逻辑是阶段性的：不管什么攻击，你都需要先理解它，再验证特征，再评估误杀，最后输出结论。

隐性知识不写出来，就不存在

前面说了，Agent 会推荐封 IP。我以为不封 IP 是常识——做流量安全的人都知道，封 IP 在对抗场景下没有意义，攻击者换代理的成本接近零。但在 AI 眼里，"发现异常 IP → 建议封禁"逻辑上完全说得通。

再比如"误杀评估必须在特征验证之后"。在我脑子里这是天经地义的顺序，但如果不写进 SOP，Agent 完全可能跳过直接给建议。

我后来加了一组 Hard Rules，把这些隐性知识显式地写进 SOP：

• 禁止推荐以具体 IP 或 UID 作为拦截维度
• 可用维度限定为：TLS JA3 指纹、设备风险标签组合、UA 特征、IP 类型（DCH）、地理位置异常
• Phase C 完成前，Phase B 的结论不能进入建议
• 每条建议必须附上查询数据作为依据

这些规则看起来很基础，但恰恰是最容易被忽略的。因为对领域专家来说它们太显而易见了，显而易见到不值得写下来。给 Agent 写 SOP 本质上是在做知识外化——把你脑子里那些"条件反射"级别的判断，翻译成明确的、可执行的规则。 你在这个领域待得越久，积累的隐性知识越多，这一步就越难，也越重要。

SOP 必须从真实 Case 里长出来

这个坑是最痛的一个。

有次视频发布接口告警了，凌晨流量异常飙高。我让 Agent 按 SOP 跑了一遍——TLS 指纹正常、签名校验正常、IP 类型正常。所有标准信号全没命中。Agent 结论：未发现明显异常特征。

但流量曲线明明不对劲。我不信这个结论，强制抽了 5 条原始请求日志逐字读——全露馅了。视频文件大小精确到字节完全一致，设备型号完全相同，每条视频挂 6 个不同店铺的商品，标题全是空字符串。技术特征模仿得像正常用户，但业务行为的模板化暴露了攻击者：设备农场批量预制视频，通过联盟营销刷量赚佣金。

问题出在哪？不是 Agent 笨，是 SOP 的 Phase A 里根本没有"读原始日志"这一步。Agent 只看了聚合后的统计指标，而攻击者恰恰是在单条请求的业务字段层面暴露马脚的。

这个 case 直接改了我的 SOP——"原始日志强制采样"被加入 Phase A 第一步。 采样 5-10 条，逐字读，重点看 request_body 的内容模式和字段固定性。

这就是我说的，SOP 不是你坐在办公室里拍脑袋写出来的，它必须被真实 case 反复喂养。框架是骨架，具体的检查项需要从实战中长出来。每跑完一个 case，回头问自己：这次有没有出现框架没覆盖到的情况？有就补进去。我现在的 SOP 已经被修改了十几个版本，每个版本背后都是一个真实的 case。

Agent 的边界在哪里

折腾了这么久，我发现 Agent 也有它的天花板。这里必须说清楚，别被 Demo 骗了。

上一轮打击视频 Bot 用的是设备风险标签（root / frida / adb 等），效果不错。然后黑产学聪明了——直接在 hook 关键函数之前，把请求里的风险标签字段删掉。结果就是标签采集失效，风险信号凭空消失，原来的策略全部失效。

Agent 跑完 SOP 给我的结论是：当前风险标签无法作为拦截维度。

结论对不对？对。但它不会追问一个关键问题：为什么标签突然没了？

是我发现的，不是 Agent。我注意到攻击行为模式没变化，但风险信号突然消失——这不对劲。推断出攻击者改了手法后，我去找新的检测维度：DFP header 异常缺失。

先拉正常用户基线：675,878 次请求，145,371 个用户，其中 DFP header 为空且 device_id 存在的——仅 13 次，3 个用户，占比 0.002%。

然后按版本拉分布：

关键判断：客户端在 34xxx 版本就已全面接入 DFP header，后续版本不存在"还没接入"的问题。任何版本出现 DFP 为空，都是主动删除，不是兼容性问题。

这整个发现过程，从"标签怎么没了"这个疑问到定位新特征，全靠人的直觉和追问。Agent 擅长在既定框架内高效执行，但不擅长质疑框架本身。发现新攻击模式、提出新假设——这些还是人的工作。

写在最后

几个我比较确定的判断：

1. 模型不是瓶颈，SOP 才是。 换模型解决不了 SOP 设计不好的问题。
2. 领域隐性知识必须显式写出来。 你觉得不需要说的，Agent 就是不知道的。
3. Agent 要持续喂养。 每隔一段时间要总结一下Agent分析结果，有没有新模式要补进去。
4. Agent 是运动员，人是教练和裁判员。 这个分工短期内不会变。

有一个检验标准我觉得挺实用：把你的 SOP 交给一个认真的新人，看他能不能独立完成一次合格的分析。 新人做不到，Agent 也做不到。新人能做到，Agent 大概率能做得更快更稳定。