夜雨聆风
AI Agent 如何把日志、SQL 和图谱串成一条风控证据链
最近我在做 RiskPilot，一个 AI 风控巡检 Agent。
它做的事情很简单：接上你的日志或者数据库，让 AI 像风控分析师一样，自己看数据、自己提假设、自己写 SQL、自己追关系图谱，最后交回一份可以复核的巡检报告。
这不是“AI 帮你写一段总结”。
真正有价值的是，它把一次风控巡检里最繁琐的几件事串起来了：看日志、查 SQL、拼图谱、写报告。
风控最累的，不是写 SQL
很多公司不是没有风控数据。
恰恰相反，是数据太多了。
注册日志、登录日志、设备指纹、IP 情报、支付流水、退款记录、礼物流水、提现记录、AI token 消耗、用户行为事件，全都躺在不同的表里。
问题是，没人每天有时间把它们全部串起来看。
一个风控同学真正辛苦的地方，不是写一条 SQL。
真正辛苦的是，他要先知道该怀疑什么。
最近注册量上来了，到底是增长变好了，还是某个渠道在注水？
提现变多了，到底是大 R 活跃，还是有人在用礼物链洗钱？
AI token 成本突然升高，到底是产品起量，还是免费额度被脚本批量薅走？
这些问题都不是单表能回答的。
你得先看全局，再猜一个方向，然后写 SQL 去验证。查完以后发现不对，还得换个角度继续查。最后查到一批可疑账号，又要确认有没有误伤正常用户。
这就是风控巡检最费人的地方：它不是一次查询，而是一串假设和验证。
RiskPilot 想做的，就是把这串动作交给 Agent 跑完。
第一步：先看懂这家公司长什么样
一次巡检开始时，Agent 不会直接自由发挥。
它会先拿到一份数据简报。
这份简报会告诉它：这批数据有多少用户、多少事件、时间跨度多长、事件类型怎么分布、哪些设备被多人共用、哪些 IP 段特别集中、哪些用户的行为序列特别相似、哪些资金链路存在多跳流转。
这一步很像一个老风控刚接手新业务时会做的事。
他不会一上来就拍脑袋说“这里有洗钱”。他会先翻一遍盘子，看这家公司正常用户长什么样，异常点可能藏在哪里。
Agent 也是一样。
没有数据简报，AI 很容易在细节里乱转。先有简报，它才知道这份业务数据的地形。
第二步：先提假设，不急着下结论
看完数据简报后，Agent 会开始列调查方向。
注意，是假设，不是结论。
它可能会说：“这里好像有一批账号共享设备注册，需要检查是不是批量注册。”
也可能会说：“这里有几个账号收礼后又快速转出，需要检查是不是资金中转。”
还可能会说：“AI 调用日志里有一批用户每天把免费额度用到 95% 左右就停手，需要检查是不是算力薅羊毛。”
这些话现在都不能算结论。
它们只是调查方向。
好的人类风控分析师也是这样工作的：先起疑心，再找证据。区别在于，人一天能起几个疑心、查几个方向，时间非常有限。
Agent 可以在一次巡检里同时跑很多个方向，而且不会因为查起来麻烦就跳过。
第三步：把怀疑落到 SQL 里
这一步是整个系统最不像“聊天机器人”的地方。
它不是坐在那里写一段看起来很聪明的总结，而是真的去数据库里取数。
比如它怀疑有批量注册，就会按设备聚合：
SELECT device_id,COUNT(DISTINCT user_id) AS user_count,MIN(timestamp) AS first_seen,MAX(timestamp) AS last_seenFROM risk_eventsWHERE event_type ='register'GROUPBY device_idHAVINGCOUNT(DISTINCT user_id) >=5;这条 SQL 不是为了“命中规则”，而是为了回答一个问题：有没有设备在短时间内挂了太多账号？
查完设备，它还会继续查 IP。
同一批账号是不是来自相同网段？是不是数据中心 IP？是不是住宅代理？是不是总在固定时间窗口出现？
然后查行为。
这些账号注册后有没有正常浏览、关注、聊天、消费？还是只做了注册、登录、转账、提现这些工具化动作？
如果涉及资金，它还会继续查资金流。
谁给谁转了钱，谁收了礼物又转给下游，谁是中转节点，谁是最终收割人。
第四步：把 SQL 结果拼成图谱
图谱这件事，人工查起来尤其痛苦。
单看一笔流水，你只能看到 A 给了 B。
但黑产不会只走一跳。它会拆成 A 给 B，B 给 C，C 再给 D。每一跳单独看都像正常行为，连起来才像一条链。
如果把一次巡检里 Agent 拼出来的关系画成图，大概是这样：
真正有价值的是重合。
同一批账号在设备图里聚在一起，在 IP 图里也聚在一起，到了资金图里还都流向同一个中转账号。三张图叠到一起，风险形状就出来了。
这也是为什么风控里不能只看单点信号。
同设备多账号，可能是家庭共享。
同 IP 多账号，可能是公司 WiFi。
新账号快速消费，可能是真用户刚好上头。
但如果是“新账号 + 共享设备 + 同网段 IP + 行为序列雷同 + 资金都流向同一个人”，这就不是一个普通异常了，这是证据链。
第五步：报告不是总结，而是证据链
最后，Agent 会把假设变成报告。
报告不是简单写一句“发现高风险用户 100 个”。
真正有用的报告，至少要讲清楚四件事。
第一，这批人是谁。
涉及哪些 user_id、device_id、IP 段、收款账号、下游账号。
第二，为什么可疑。
不是给一个黑盒分数，而是把关键证据列出来：设备怎么聚集、行为怎么相似、资金怎么流转、和正常用户相比差在哪里。
第三，Agent 排除了什么。
一个只会报风险的系统并不稀缺。真正有用的是，它能告诉你“我查过这个方向，但证据不足，所以没有报”。
比如它发现一批用户用了 VPN，但行为正常、支付正常、没有共享设备，也没有异常资金流。那就不能因为 VPN 一个信号就把人打成黑产。
第四，建议怎么处理。
不同 finding 的处置动作不一样。
有些适合直接封禁，比如明确的模拟器群控注册池。
有些适合冻结提现，比如资金链路里的收割账号。
有些适合进入观察名单，比如还没有造成损失，但和已知坏人行为高度相似的账号。
还有些适合变成新规则，进入规则引擎继续跑。
规则引擎守门，Agent 巡逻
这也是 RiskPilot 里很关键的一点：Agent 不是替代规则引擎。
规则引擎适合做确定性的、实时的、低延迟的拦截。Agent 适合做更复杂的、需要跨表分析的、需要解释的巡检。
它们的关系更像是：
规则引擎守门，Agent 巡逻。
门口已经知道的坏人，用规则拦。
不知道藏在哪里的新模式，让 Agent 去翻。
比如一家 AI 陪聊产品最近 token 成本上涨了 30%。
人工排查通常会先看成本 Top 用户，再看调用次数，再看设备，再看注册时间，再看这些账号是不是来自同一批 IP。每一步都要写 SQL，每一步都可能卡住。
Agent 的巡检会把这条线自动串起来。
它先看 token 消耗分布，发现一批免费账号每天都消耗到 90%-97% 就停止。
然后查这些账号的注册时间，发现它们集中在几天内注册。
再查设备，发现 30 个账号背后只有 5 台设备。
再查 IP，发现它们来自同一个代理网段。
最后查行为，发现它们几乎没有正常聊天留存，只是在稳定消耗额度。
单看“用满免费额度”，不一定是坏人。
但“免费额度精准消耗 + 批量注册 + 共享设备 + 代理网段 + 行为极窄”，这就是一条完整证据链。
最后报告里不会只写“疑似薅羊毛”。
它会写清楚：涉及多少账号、多少设备、估算消耗了多少 token、每天造成多少成本、建议按设备集群限额还是按账号冻结。
还有一种价值：读懂客户自己的字段
现实里的数据不会长得很标准。
有的公司叫 device_id，有的叫 fp_id，有的把 WiFi、传感器、电量、渠道、风控标签全塞进 JSON 里。
人工接入一个新客户，最痛苦的事情之一就是理解这些字段到底是什么意思。
Agent 可以先读 schema，再看字段分布，再把异常字段拉进调查。
比如一个字段叫 wifi_ssid_hash，看起来不起眼。
但如果 20 个行为正常、设备风险也正常的账号，都聚在 3 个 WiFi 哈希下面，同时电量长期 100%、传感器数量很低，这可能就是一个真机设备农场。
传统规则如果没提前写这个字段，根本不会看它。
Agent 的优势是，它可以在巡检时发现这个字段有用，然后把它纳入证据链。
最后说清楚边界
RiskPilot 做的不是“AI 帮你写报告”。
写报告只是最后一步。
真正有价值的是前面那一串动作：
先看日志，知道业务长什么样。
再提假设，决定今天要查哪些方向。
再写 SQL，把假设落到数据里。
再追图谱，把账号、设备、IP、资金关系连起来。
再做回测，确认这条规则会不会误伤一大片正常用户。
最后才生成报告，把证据、结论和处置建议交给人。
当然，它也不是万能的。
如果数据里没有设备、没有 IP、没有交易、没有行为细节，只剩一个 user_id 和一堆结果标签，那 Agent 能做的事情会很有限。
如果日志质量很差，时间戳不准，用户 ID 混乱，关键事件没有上报，巡检也会受影响。
所以早期 POC 最适合的方式不是一上来大集成。
最简单的是拿最近 7-30 天的脱敏日志，先跑一轮。
最小数据只需要 user_id、timestamp、event_type。
如果还有设备、IP、支付、退款、提现、礼物、AI token 消耗这些字段，Agent 就能做更深的交叉验证。
不需要聊天内容，不需要明文手机号，不需要明文邮箱，也不需要真实姓名。
对于风控团队来说，这件事的价值不是“多一个系统”。
而是你可以问一个很直接的问题：
我的日志里，有没有一些我还没来得及查、规则还没覆盖、人工也很难及时发现的问题？
给 Agent 一份数据，让它跑一轮。
如果它能交出一份有证据、有 SQL、有图谱、有处置建议的报告，那这件事就值得继续往下做。