从每天数百客诉到分钟级自动分析，从数天风险定位到 T+1 主动发现，从天级策略制定到分钟级策略生成——用多 Agent 架构改造风控流程的完整复盘。

注：

①风控从业者和做过 Agent 落地的读者，如果发现某些环节被简化或跳过，是正常的。半年项目的体量，一篇 1.6w 字文章只能装下冰山一角。例如我们有二十多个环节调用 AI，每一个 prompt 可能都五六千字，每一个 prompt 都要改十几版，评估了上百次……

②本文借助 AI 写作——原始复盘文档有六七万字，AI 辅助将其整合为这篇可直接阅读的版本。

③需要结合项目时间来看这篇文章，2025 年下半年，所以这个系统不涉及 Claude Code、skills、龙虾等概念。

虽然全文很长，还是推荐花半天时间详细阅读，可以一边和 AI 讨论，一边阅读。如果你时间有限，看六、七、十一、十三、十四这几章就够了。

一、一个链接，背后是数百个受害者

去年年初，有一类案件开始频繁出现。

用户在一个微信群、钉钉工作群里看到”国家补贴”或者”投票助力”的链接，点进去，页面要求输入手机号、验证码、支付密码。看起来很正常，很多人没多想就输入了。

几个小时后，他们的银行卡被一笔笔刷走。有人被盗刷了数千甚至上万元。

这不是偶然事件。国补只是众多诈骗类型中的一种——助力投票、虚假红包、冒充客服……各种钓鱼诈骗常年存在，而国补恰好在那段时间集中爆发。抖音、小红书上开始出现投诉帖，舆情开始发酵。每天有数百个受害者的客诉涌到客服中心，然后升级到风控分析师手里。

每一个客诉背后，都是一个真实用户的损失。而风控分析师团队面临的现状是：一个 case 排查下来 2-3 个小时，每天 40% 的时间花在从各个系统拉数据、对信息上，真正用来思考”怎么防”的时间少得可怜。

从这个现象切入，我开始思考一个问题：在这个场景里，AI 到底能帮上什么忙？

二、风控分析师的日常：在数据海洋里捞针

2.1 一个 case 的完整排查流程

要理解为什么效率低，得先看分析师是怎么工作的。

一个典型的 case 排查链路是这样的：

收到客诉 → 拿到用户的 uid、订单号、时间等信息 → 登录风控系统查风控日志 → 打开订单系统看最近几十天的订单情况 → 去鉴权系统查核验记录 → 去登录系统看异地/异常登录 → 关联用户画像信息 → 再回到风控策略系统看有没有命中规则 → 推理作案路径 → 定位策略漏洞

注：以上已经是简化流程了，实际操作会复杂很多。

每一步都要切系统、输参数、等查询、看结果、记笔记。跨 7-8 个平台是常态，单次排查轻松 2-3 小时。

2.2 时间都花在哪了

分析师每天的工作里，大约 40% 的时间花在”查数”而不是”思考”上。不是不知道怎么看，是数据散落在各个系统里，需要大量机械操作去捞取和关联。

剩下的时间还要处理监控预警、舆情、业务反馈。每天几百个客诉，不可能全部精细分析。新发案件往往被积压，等到发现时，黑产已经捞了一波。

2.3 新手为什么更难

还有一层困难：团队总有新人。新人要在数万条策略中快速定位相似策略，需要对业务场景、历史案件、字段含义有很深的理解。这不是看文档能解决的，纯靠经验和时间积累。

新人上手慢，老人时间不够。这是团队常态。

2.4 这不是人不够努力

做这半年 AI Agent 落地，我最大的感受是：很多场景的效率瓶颈不是人不够努力，是这个工作模式的天花板到了。

风控分析是一个典型的知识密集型工作——依赖专家的判断力、经验和直觉。这些东西难以规模化复制。而 AI Agent 正好擅长做这件事：把专家的隐性知识显性化、流程化、自动化。

但怎么落地，才是真正的难题。

三、黑产的进化：为什么传统防线在失效

3.1 手法在加速进化

如果仅仅是工作量大，那增加人手、优化工具或许能解决。但风控面临一个更根本的问题：对手也在进化。

从早期的撞库、薅羊毛，到后来的社会工程学钓鱼，再到现在 AI 辅助的精准诈骗——黑产手法的复杂度在指数级上升。

过去薅羊毛靠脚本批量操作，特征明显（高频、同 IP、同设备），策略容易命中。现在黑产走”精细化路线”——真人账号、正常操作频率、分散设备，很难在单一维度上发现异常。

3.2 时间差就是资损

风控领域有一个残酷的现实：从新手法出现到被识别、到制定策略、到上线生效，这个时间差直接决定了资损规模。

按照传统流程，一个新案件出现后：

1）用户投诉到客服（延迟 1-2 天）

2）客服转给分析师（延迟半天）

3）分析师排查（几小时到几天）

4）定位问题、制定策略（几小时）

5）策略部署上线（几小时到几天）

整个周期下来，3-7 天，甚至更长都是常态。足够黑产洗劫大量账户。

3.3 孤立案件很难关联

还有一个更难的问题。在一个案件大规模爆发之前，往往是零星的几个孤立案件。单个看，特征不明显——可能只是一个用户换设备登录、一笔稍大的订单。但把它们关联起来，才能发现”这是一伙人在操作”。

人工做这个关联非常困难。分析师每天面对几百个客诉，没精力对每一个做横向对比。而黑产恰恰利用了这个盲区——在”不够明显”的阶段疯狂作案。

3.4 策略布控的两难

风控策略本身就是一个权衡问题。严了误伤正常用户——用户投诉、业务抱怨。松了拦不住风险——资损扩大、舆情爆发。

人工通过特征构建策略，很难快速找到最优布控方案。需要反复调参、验证、观察效果，一个”差不多”的策略上线后，可能还需要几轮迭代才能稳定。

3.5 本质矛盾

风险变化的速度，超过了人工响应的速度。

这不只是风控的问题。所有需要”人工分析-响应”的领域——安全运营、合规审查、客户服务、医疗诊断——都面临这个困境。信息在爆炸，但人的分析能力没有爆炸。

所以问题就变成了：当人的速度跟不上时，能不能用 AI 来补这个 GAP？

四、我们想做一个”数字分析师”

4.1 一句话说清楚

这个项目的目标很简单：基于客诉、舆情、监控预警等多源信息，用大模型 Agent 完成从风险感知、分析、报告生成、策略推荐到效果验证的全链路闭环。

或者更直接地说：建一个”数字分析师”——它能 7×24 小时在线，自动排查 case，生成分析报告，自动推荐防护策略。

4.2 不是做个更聪明的系统

很多做 AI 的人容易陷入一个误区：觉得 AI 比人聪明，所以应该让 AI 全面接管。

我的想法是：把分析师的思维方式做成可复制的 Agent。

分析师的核心能力是判断力——她知道哪些信号重要、哪些是噪声、什么情况下可以放心、什么情况下需要警惕。这个判断力来自多年的经验积累，不可能被一个 AI 瞬间替代。

但分析师的大量时间浪费在机械操作上——查数、对信息、翻日志、做分析。这些是可以被自动化的。

所以这个项目的定位很清楚：帮分析师把时间花在刀刃上。

4.3 闭环链路

整体流程是：感知风险 → 智能分析 → 报告生成 → 策略推荐 → 线上验证 → 效果反馈。

用大白话说：

1）感知：自动从客诉、舆情、监控预警中发现异常

2）分析：关联多源数据，还原作案链路，提炼风险特征

3）报告：根据分析结果，生成可视化报告，在前端页面展示

4）推荐：对比现有策略库，推荐需要调整的策略

5）验证：新策略进入旁路引擎跑，验证效果

6）反馈：效果回流，持续优化

注：

1）这个闭环中每一个环节都可以人工介入，以及很多小环节需要人工 double check，才能到下一步，否则会一步错步步错

2）旁路引擎，简单说就是不串在主链路上、只 “旁听” 流量的检测 / 分析引擎；主流量照样走，它只拿镜像或分光副本做分析、告警，不阻断、不影响业务。

4.4 一句话介绍这个系统

基于客诉等信息，关联十几张数据表（用户信息、订单信息、鉴权信息、登录信息、风控日志、策略信息等），通过业务逻辑和大模型，在订单维度、账号维度、事件维度打标签、做多轮推理分析，最终输出风险报告、推荐相似策略、自动生成策略。

五、系统架构：7 个 Agent 如何协同破案

5.1 两条可编排的流水线

系统设计了两条核心流水线：

特征流程：Prompt 解析 → 数据拼接 API → 特征 Agent → 生成结构化要素。这条线负责把原始数据变成可分析的结构化信息。

策略流程：向量检索 + 策略特征 + 历史请求数据 → 未命中根因分析 → 推荐策略/案件报告。这条线负责分析为什么没拦住、以及该怎么办。

两条流水线可以独立运行，也可以串联编排，灵活度比较高。

5.2 7 个子 Agent 详解

这个项目本质上是一个由多个子 Agent 构成的多 Agent 架构。每个 Agent 只做一件事，各司其职：

5.3 为什么要拆模块

这套系统架构有几个明确的设计原则：

• 单一职责。每个 Agent 只做一件事。
• 好处是可独立评估——哪个 Agent 不准就调哪个，不影响全局。
• 可回归——改了一个模块不会影响其他模块。
• 可复用——UID 分析、模式推断这些能力在其他场景也能用。

并行与串行的合理搭配。UID 分析独立于其他模块，可以并行跑。但模式推断和链路推演依赖事件结构的输出，必须串行。这种设计最大化了效率。

证据层与结论层分离。事件结构/UID 画像是”证据模块”，只输出事实（”这个账号近 7 天换过 3 台设备”）。链路/模式/信号/动作是”结论模块”，在证据基础上做推理（”频繁换设备 + 夜间集中支付 = 疑似账号被接管”）。

这个分离非常重要——它降低了多步推理的误差累积（后面会专门讲这个）。

5.4 数据流：从碎片到结构化

数据的旅程是这样的：客诉/支付宽表/登录/鉴权/UID 画像 → 聚合/关联 → 聚合成事件数据包 → 各 Agent 分析 → 生成报告 → 策略匹配 → 阈值调优 → 策略生成。

每个环节的产出都是结构化 JSON，而不是一段文本。这件事我们踩过坑，后面会展开说。

5.5 前端展示

分析师的界面上，信息以卡片形式呈现：摘要卡片、Top3 作案模式、Top5 异常信号、动作建议表格、可折叠的详细数据区。信息层级清晰，分析师可以快速判断”这个事件值不值得管”。

因为每个环节都是 json 输出，然后存储到数据库，所以前端就能非常清晰后的展示具体每一个字段了，如下图

六、基建：70% 的时间在搭地基

6.1 数据层的复杂程度远超预期

想象一个场景：你要分析一个客诉，判断这个用户是不是被骗了。

你需要看哪些数据？用户的个人信息、这笔订单的详情、下单时的登录记录、支付时的鉴权记录、设备信息、历史行为、命中的风控策略……这些数据来自不同的系统、不同的团队、不同的表结构。

有的按天分区，有的实时写入；有的在宽表里，有的在 JSON 串里；有的字段名一看就懂，有的需要找原始业务方确认。

所以，做这个项目，第一件事是打通数据。

6.2 建大宽表的实战

我们花了很多时间在数据基建上——比预想的多得多。

四百多个字段，关联十几张表。具体做了这些事：

从 JSON 串中提取字段到根目录。很多核心数据埋在大 JSON 串里，查询起来很慢，需要一张张表把需要的字段”拆”出来。

复杂的过滤逻辑。金额小于特定值的剔除、支付不成功的剔除、订单号重复的去重。每条过滤背后都有业务依据。

字段为空的补数方案。数据缺失是常态。同一个字段可能有多个来源路径，需要按优先级依次尝试。写了好几版逻辑才稳定下来。

…………

最终建成了 4 张大宽表：请求维度表、账号维度表、鉴权维度表、登录维度表。它们的字段存在率从 0% 到 100% 不等——这也是一个要面对的现实，不是每个 case 都有完整的数据。

6.3 字段理解的深坑

数据层的难度不只在”拿得到”，更在”看得懂”。

字段名、枚举值、枚举含义——这些信息往往连业务方自己也说不清楚。举个例子：”核验方式”字段里，”短信”和”人脸”在风控中的含义完全不同——人脸可以视为本人操作，短信不能。如果你不了解这个背景，直接用原始数据，模型会得出错误结论。

另一个例子：很多字段的取值是编码（比如 56-65 位表示某个含义），需要对照文档来解析。而这些文档往往分散在不同团队、不同系统里，甚至有些已经过时。

最难的还不是技术问题，而是组织问题。要从其他团队获取字段含义和口径，需要沟通协调，而对对方来说没有直接收益，他们不一定有人来支持你。很多时候只能靠自己一点一点”考古”。

6.4 基建的隐性价值

这些工作在产品推出前不直接产生”价值”——搭建知识库、做名词定义、建表、数据清洗。没人看得到你在建什么，但这些是 Agent 能运转的前提。

当然后来证明：打地基的时间没有白花。 没有这些，大模型只能对着碎片化数据”瞎猜”，输出质量会很差。

这是在建一整套基础设施。

七、最难的事：把分析师的脑子拆成 SOP

7.1 分析师自己也不知道自己怎么想的

这是整个项目里最难的部分，没有之一。

你找一位资深分析师坐下来，问她：”你是怎么做分析的？你的判断依据是什么？”

她看着你，想了半天，说：”……因为 xxx，所以有风险。”

但这个“xxx”可能只是他们判断逻辑的 1%，另外的 99%判断逻辑怎么办？能梳理出来吗？梳理不出来，只能说看到后知道该怎么判断，没看到之前写不出判断逻辑。

这不是她不配合，是真的说不出来。她有能力分析出结果，但无法结构化描述自己的思考过程。这是典型的隐性知识（Tacit Knowledge）问题。

很多领域专家都这样。他们能做事，但说不清”怎么做的”。因为他们的判断力来自多年的经验积累，内化成了直觉，而不是一系列可陈述的规则。

7.2 解法：不给她填空题，给选择题

刚开始我犯了一个错误：让她填空。”你能把分析步骤写下来吗？”——写不出来。

后来换了思路：用 GPT 梳理出分析框架，让她做选择题。

我先把一次分析过程拆成几个维度（下单信息、收货信息、实名信息、鉴权信息、登录信息），每个维度列出几种可能的风险模式，让她选”哪个更符合你的判断”。

根据她的选择，调整框架。再让她选。多轮下来，框架越来越清晰。

最终拆出来的，大概是她经验的 60-70%。还有大量隐性经验无法结构化——这些就保留给人来做。

这件事给我一个重要认知：AI Agent 不是万能替代，是做分析师能做的 60-70%，剩下交给人工。 承认这个边界，系统设计才能变得务实。

7.3 管理预期：分析师也有不靠谱的需求

还有一个问题：分析师对大模型的期望往往不合理。

典型对话是这样的：

“我把所有信息都提供给 AI 了，它怎么还不能分析？”

“……哪些信息？”

“客诉原文和订单号啊。”

他们过度神话了大模型的能力，以为给了原始数据就能自动推理出完美结论。这是外行对 AI 的普遍误解。

我需要不断科普 LLM 的能力边界：

– 注意力机制决定了，到了 Token 上限的 20% 左右，中间部分的效果就开始变差

– 原始数据和结构化信息是两回事——LLM 需要清晰的结构化输入，而不是一坨 raw data

– 输入不是越多越好，存在”舒适区间”——这个后面会专门讲

核心就一句话：要把”能做什么”和”不能做什么”定义清楚，做一个靠谱的产品，而不是一个万能的产品。

7.4 协作模式总结

我知道 AI 一定是不靠谱的，也知道它哪里不靠谱。所以通过机制设计让它变得可控。

而团队里其他人还在纠结”AI 到底靠不靠谱”——这个认知差距，决定了项目的走向。

八、风险报告：分析师的决策起点

7 个 Agent 跑完分析，产出的不是一篇”文章”，而是一份结构化的风险报告。这个报告怎么设计，直接决定了分析师能不能快速做判断。

8.1 报告要回答四个问题

在设计报告结构之前，我先想清楚了一件事：报告本质是帮分析师提供决策依据

分析师拿到一份报告，想知道的其实是四件事：

1）发生了什么事？范围多大？ — 事实与规模

2）为什么值得管？风险在哪？ — 风险评估与证据

3）我下一步该做什么？ — 策略建议与优先级

4）已经做了什么？效果怎样？ — 处置与复盘

每一条都对应报告里的一个模块。

8.2 报告模块设计

最终确定的报告结构是这样的：

• 事件元信息：事件 ID、风险等级（P0/P1…）、首次爆发时间、最近更新时间、触发场景（支付/营销/登录）、当前状态（待决策/观察中/已建策略/已关闭）、责任人
• 事件概况：大模型生成的一段总结——这个事件是什么类型、涉及多少用户和订单、核心风险特征是什么。
• 作案模式推断：还原黑产的作案链路，可以有多条。比如”A 组 10 个 UID 是通过钓鱼链接被骗的，B 组 5 个 UID 是设备被远程控制的”。每条链路都要写清楚涉及哪些具体的 UID，方便分析师核实。
• 关键异常信号 Top N：系统在所有异常信号中，挑出最有价值的几条。比如”设备更换频率异常””深夜集中支付””收货地址与常用地址跨省”。分析师看一眼就知道该从哪个方向入手。
• UID 维度风险画像：从用户账号维度展示风险特征——这个账号是新注册还是老号、是否有过异常记录、设备是否可信、实名信息是否一致。
• 矛盾点与缺证：用户反馈的内容和实际交易数据之间如果存在不一致，系统会列出来。比如”用户反馈未进行人脸识别，但鉴权记录显示人脸已通过”。这些矛盾点由分析师做最终判断。
• 建议动作与优先级：根据风险等级和证据强度，给出建议处置方式——拦截、加验、观察、或不做处理。每条建议附带置信度说明。

8.3 从一段话到结构化输出

这个报告的形态经历了三次迭代。

最初版本：让大模型直接输出一段分析报告，一气呵成。看起来好像还行，但分析师拿到后不知道怎么用——信息全都混在一起，找不到重点。

第一次迭代：按模块分段输出 JSON。每个模块独立生成、独立评估。前端页面用卡片化方式展示：摘要卡片、Top3 作案模式、Top5 异常信号、动作建议表格。信息层级清晰了很多。

第二次迭代：区分”证据模块”和”结论模块”。中间结论（比如 UID 维度画像、事件结构分析）是为下一步推理服务的，不是给人看的。不需要写成可读的文章，给结构化的 JSON 信号就行。最终呈现给分析师的，是结论层的摘要。

8.4 信息不足的处理

风控分析里有一个常见情况：信息不足以得出任何结论。

如果你给分析师的是一份”看起来分析很深入但实际上关键信息全缺”的报告，他反而要花更多时间去验证。所以我们定了一条铁律：信息不足时，直接输出空数组，不编造、不猜测、不补全。

这在 prompt 层面对大模型做了强制约束。模型天然倾向于”说点什么”而不是”什么都不说”，需要用规则把它压住。

8.5 报告与策略的衔接

报告的最后一个模块（建议动作）直接对接策略推荐系统。分析师看完报告后，系统已经基于风险特征预计算了推荐策略——这是一个从”你发生了什么”到”你应该怎么办”的无缝衔接。

这也解释了为什么我们要把报告做成结构化 JSON：策略推荐模块需要读取报告中的结构化字段来做匹配，而不是从一段文字里重新提取信息。

九、三种策略推荐：从暴力匹配到因果理解

9.1 策略推荐的业务逻辑

做风险分析只是第一步。最终目的是出策略——用什么规则、什么阈值、什么处置方式来拦截风险。

分析师在制定策略时有一个经典思路：”强证据配小范围，弱证据配速率。”

什么意思？如果证据很充分（比如设备黑名单），可以直接拦截，范围可以收窄。如果证据比较弱（比如高频访问），需要配合速率限制来使用，范围可以放宽。

所以策略推荐不能只推荐最相似的一条，而应该按策略组来推荐——一组互补的规则，覆盖不同场景。

基于这个思路，我们设计了三种策略推荐方式。

9.2 方式一：基于相似脚本推荐

逻辑：事件下命中了哪些风控脚本 → 做数据清洗 → 筛出核心脚本 → 搜索最匹配的已有策略来推荐。

实现步骤：

1）把当前场景的所有策略单独落表，T+1 更新

2）取出事件下近 30 天命中的所有脚本 id，做聚合

3）排除无关脚本（和本场景无关的、和风险无关的）

4）大模型通过 RAG 召回和本次风险相关的脚本（从约 100 条筛到约 20 条）

5）通过剩余脚本调用相似策略接口，推荐并计算相似度

优点：逻辑清晰，实现成本低，ROI 高。

缺点：局部最优解——推荐的可能是不相关的策略，只是”看起来像”。

9.3 方式二：基于脚本描述推荐

逻辑：大模型理解风险特征 → 理解策略下脚本的描述 → 做卡槽匹配。

这里有一个关键创新：把脚本描述解析为结构化的策略描述，涵盖 10 个维度：

布尔逻辑：条件之间的逻辑关系

时间维度：近 7 天 / 24 小时内 / 夜间 0-6 点 / 大促期间

对象维度：用户 / UID / 设备 / 手机号 / IP / 商户

渠道维度：线上 PC/H5/小程序/APP、线下门店

支付工具：银行卡、微信、支付宝……

品类维度：虚拟、高危虚拟、易变现、E 卡、黄金……

设备维度：非常用设备、模拟器、云控、root……

登录维度：异地登录、登录方式异常、撞库……

地理位置：IP 省与门店地址是否一致

阈值维度：日累计金额、单笔金额、请求次数……

每个维度都有结构化的正则规则和枚举值，形成一个可计算的匹配框架。

优点：简单，容易落地。

缺点：强依赖脚本描述是否准确。如果命名不规范，效果等于人工关键词搜索。

9.4 方式三：基于对抗方案推荐

逻辑：大模型理解风险 + 大模型理解策略 → 在”成因”层面做映射匹配。

这是最复杂的方式，也是最有潜力的。

同一风险下，大模型会生成 3-5 条互补规则，分别覆盖”强证据小范围”和”弱证据配速率”两种场景。

输入：

– 风险侧：核心风险特征、维度化字段、附加特征（金额/频次/时间窗）

– 策略侧：策略描述、策略特征、策略逻辑

输出：一组推荐策略，每条都有解释——”这条策略针对什么特征、为什么能拦截这个风险”。

优点：成因和处置一一对应，推荐结果可解释。

缺点：实现成本高，策略理解难，可能漏召。

9.5 三种方式的演进逻辑

这三种方式实际上代表了大模型介入深度的递增：

方式一：找相似的（传统机器学习思维）

方式二：理解后再匹配（用大模型做语义理解）

方式三：理解成因后再生成（大模型真正参与策略设计）

实际落地中，三个模块同时在系统里，各自推荐一批策略。分析师综合参考，再根据自己的判断做最终决策。

十、prompt 设计经验

做这个项目过程中，我积累了一套 Prompt 规则体系，核心思路是把 Prompt 从”写给 AI 看的话术”升级为”可回归的约束系统”。

这些规则涵盖：业务边界信息的强制约束、输出格式的严格定义、信息不足时的空输出策略、评估体系的设计等。篇幅原因不在此展开，已单独整理为一篇文章，可以对照参考。

十一、踩坑实录：价值百万的教训

11.1 组织架构的坑

问题：大量基建工作（搭建知识库、建表、关联表、数据清洗、打标签）在产品推出前不直接产生可展示的价值。你花了三周建宽表，但对外说就是”在搞数据”。团队看不到进展，上面的人会质疑。

资源有限，很多事推进起来阻力很大。这个阶段最难的不是技术，是扛住压力。

启示：做 AI 项目一定要管理好组织预期。基建期的不确定性需要上面有人扛。如果没有，就需要快速出 MVP 来”止血”。

11.2 策略生成定位之争

这是项目过程中最关键的争论，也是两条完全不同的技术路线。

两种思路的差异：

我组长的选择是：AI 直接生成可上线部署的策略。这意味着系统要对策略的准确性负全责——容错率非常低。一条误拦策略可能导致大范围客诉和舆情。为了支撑这条路线，他拉了很大的团队，甚至涉及模型训练。经过几个月的折腾，验证了他这条路基本跑不通，在复杂风控系统里，追求一步到位的策略生成不现实。

我的选择是：AI 生成 80% 完成度的策略草案，分析师做 double check 后上线。这意味着系统承担的是”提效”角色而非”决策”角色——容错率高，可以在复杂系统里快速跑起来。关键不是让 AI 做对每一件事，而是让 AI 做完 80% 的机械工作，人来做最后 20% 的判断。

这个定位差异决定了所有设计决策。AI Agent 的定位选择不是技术问题，是产品和战略问题。在复杂系统里，容错率比能力强、自动化更重要。

11.3 输出格式的坑

第一个坑：报告不要输出整段文本。

最初我们让大模型直接输出分析报告，一段话从头到尾。看起来还行，但分析师用起来很痛苦——信息混杂在一起，找不到重点。

后来改成按 JSON 分段输出，前端页面用卡片化展示。信息层级清晰了很多。

第二个坑：报告不要一并输出。

一开始所有模块的分析结果一起生成。但如果有一个模块不准，影响整个报告的可信度。

后来改成每个模块独立生成、独立评估。好就好，不好就单独修，不影响其他模块。

第三个坑：要区分内容的用途。

有些中间结论是为下一步推理做准备的——比如”这个用户的设备是模拟器”这个判断，不是为了给人看，是给下一个 Agent 用的。所以不需要写成一篇文章，给个结构化的信号就行。

上面这些问题都是在踩坑过程中才理解的，没实践过，都不说是否能避开这些坑了，他甚至都无法 get 到这些坑是啥意思。

11.4 处置建议过度

大模型有一个倾向：给强动作。

证据很弱的时候，它也会建议”P0 阻断””紧急拦截”。这是模型自身的偏好——它倾向于”宁错杀不放过”。但在风控场景里，误拦截一个正常用户可能带来更大的问题（客诉、舆情、业务流失）。

后来加了一层规则映射：结论置信度 → 动作优先级。置信度 80% 以上才能建议拦截，60-80% 建议加验，60% 以下只能建议观察。把选择权交给分析师。

11.5 客诉信息量低 + 用户描述不可靠

这是一个非常反直觉的发现：用户说的很多是错的。

有用户投诉说”我已经下单了”，但实际查看交易记录，订单根本没成功。

有用户说”我没经过人脸验证”，但鉴权记录显示人脸已通过。

这不是用户故意撒谎——他们可能记错了、混淆了、或者根本没注意到自己做了什么。

启示：不能盲目相信输入数据，系统要有”质疑”能力。

我们的做法是：关联大量数据做交叉验证，把矛盾点列出来，由分析师做最终判断。系统不做”信任或不信任”的决策，只做”事实核查”。

11.6 多步错误复合效应

系统有 5-6 个处理环节。假设每个环节的准确率是 90%（已经不错了），最终准确率是多少？

90% × 90% × 90% × 90% × 90% = 约 59%。

这就是多步推理的残酷现实。误差会沿着链路逐级放大。

解法有三个：

第一，缩短链路。不是把所有环节串起来，而是把中间结论也暴露出来。就算最终报告不准，中间的分析结果也可能有价值。

第二，用硬逻辑代替大模型。能通过规则打标签的，绝不调用大模型。比如”命中某脚本则属于某类”这种判断，一条规则就能搞定。

第三，系统兼容这种不准确。让系统做辅助而非决策。80% 完成度的策略 + 人工 double check，比追求 100% 准确率更务实。

11.7 数据存不下、查不出

我们要分析一个账号的风险，想把账号最近一段时间的风控数据丢给 AI 基于 timeline 分析。

首先，每一条日志量级可能就占十几万 Token，最近一段时间可能有上千条日志。

当然，这个都可以通过数据清洗，筛选出重要数据来解决。

但会进入到一个更底层的问题，日志存不下来，每天几十亿条数据，每天几百 T 的数据量，每条数据十几万 Token，部门自己会存一份，集团也会存一份。

部门自己存的，因为量级太大，可能一两天就会自动失效。

集团存的，虽然理论上半年前的都能查，但是他们的数据量太大了，从来都查不出数据，查一条数据，等 5 小时，然后告诉你 timeout。

如果要推集团去优化，那就不是我们三两个部门推得动得了。

启示：在大公司做 AI 项目，数据可达性比数据量更重要。你有多少数据不重要，你能稳定、快速地拿到多少才重要。如果集团数据查不到、部门数据只保留两三天，就要在设计系统时把这些约束考虑进去——比如缩小分析窗口、优先用本地可缓存的数据、或者把数据采集前置到业务层来做。

十二、效果验证

⚠️ 以下所有数据经过脱敏处理，展示相对值和趋势方向，不涉及具体金额和内部数据。

12.1 核心量化成果

风险发现时效大幅提前。过去需要数天的风险定位周期，通过系统自动化的数据关联和推理分析，缩短到小时级。这个差距决定了资损规模——早一天发现，黑产就少一天作案时间。

欺诈资损显著下降。欺诈资损率（欺诈资损金额占成功交易总金额的比例）在系统上线的评估周期内，环比出现了明显下降。主要原因是新发风险高峰期被大幅压缩，风险暴露窗口收窄。

客诉量有效压降。随着新风险被快速发现并拦截，受害用户减少，客诉量也随之下降。日均客诉量在评估期内呈现出明显的下降趋势。

12.3 这些效果怎么实现的

几个关键机制在起作用：

T+1 发现替代被动等待。过去一个新手法出现后，要等到客诉积累到一定量级才被发现。现在系统每天自动扫描线索，T+1 就能识别出聚集性风险。

策略组推荐替代单点修补。以前发现一个风险漏洞，针对性地修一条策略。现在系统会推荐一组互补策略——强证据的直接拦截，弱证据的配速率限制——形成完整的防御面，不给黑产留缝隙。

精细化策略替代粗犷拦截。过去一条策略往往覆盖多个风险场景，为了防住某些风险而牺牲了精度。现在一条策略只针对一个风险场景，通过”多而精”代替”少而全”，在保证召回率的同时把误伤降到最低。

12.4 定性成果

从被动响应到主动发现。过去分析师等客诉来了才知道有新风险，现在系统主动扫描异常趋势。这种转变不只是效率提升，而是风控模式的变化。

分析师效率提升。分析师从大量的机械查数工作中解放出来，更多时间花在判断和决策上。策略制定从小时缩到分钟级。

策略精细化运营。原来一条策略覆盖多个风险，现在根据风险特征精准配置拦截策略。分析师的策略库从”少量大规则”变成了”大量小规则”，每一层的精准度都提升了。

十三、真正想明白的事：从做项目到形成方法论

13.1 问题不在于 AI 是否可靠，而在于不可靠性是否可控

做这个项目的过程中，我反复在思考一个问题：AI 到底能不能被信任？

我的结论是：基于 Transformer 架构的大模型，本质就是不可控的。这是概率预测器的本质特征。我们不可能训练出一个”永不犯错”的模型，就像不可能造出一个永不漏水的杯子。

所以问题变成了”怎么在 AI 不可靠的情况下，系统依然可以可靠地运转”。

这个认知转变很关键。它决定了你设计的不是一个”AI 系统”，而是一个”人机协同系统”——AI 负责它擅长的部分（信息提取、模式识别、文本生成），人负责它擅长的部分（判断、决策、容错），通过机制设计让双方互补。

系统设计能力 vs 模型调优能力，前者才是真正的工程壁垒。

13.2 有效信息长度曲线

这个项目让我对”给 AI 多少信息合适”有了深刻的理解。

AI 输出质量和输入有效信息量之间是一条有最值的类二次函数曲线：

• 上升期（左侧）：有效信息很少时，AI 基本在”猜”，输出非常随机，和预期可能相差甚远。
• 平稳期（中间）：有效信息足够详细时，AI 输出达到峰值。稳定可靠，速度快。这是”舒适区间”或”可靠工作区间”。
• 衰退期（右侧）：信息过载时，输出质量开始下降。关键信息被噪声淹没，幻觉开始出现，AI 频繁遗忘需求。效率也显著下降。

几乎所有 AI Agent 的优化策略，都围绕这条曲线展开：

– 简单任务：舒适区左移且变宽，因为需要的信息少

– 复杂任务：舒适区右移且变窄，因为需要更多有效信息才能描述清楚

所以做复杂任务时，核心策略就是分层分步——把一个大任务拆成若干个小任务，每个子任务都落在自己的舒适区里。

13.3 Agent 的减法比加法重要

我犯过一个错误：一开始总想往系统里加东西——再加一个 Agent、再多一个分析维度、再优化一下 prompt。

后来发现，减法比加法重要。

三个原则：

1）能用硬逻辑的不用大模型。规则打标签优先——命中某脚本直接标记类型。又快又准，还不用花钱调模型。

2）推理时把前面信息也丢进去。多步推理时，每一步只做”增量推理”，同时保留上下文的全貌。这样即使某一步出现偏差，后续也不至于完全偏离方向。

3）前面不做结论，仅给出供后续推理的信息。证据层输出”事实是什么”，结论层才输出”这意味着什么”。两者分离，即使结论层错了，证据层还可以复用。

13.4 反向梳理方法论

这个项目做到后面，我总结了一套方法论。听起来很简单，但实操时很容易跳过：

– 先确认需要哪些标签

– 标签需要哪些数据

– 数据需要哪些表

– 表之间如何关联，数据如何流转

– 分析师需要的大宽表还需要哪些字段

– 搞清楚每张表是哪个团队的，什么加工逻辑

很多 AI 项目失败，不是因为模型不行，而是因为数据和需求之间断了链。第 1 步没想清楚，后面全是白费。

这套方法论不只能用在风控上。

13.5 Copilot 定位的终极思考

最后，我想清楚了一件事：不是帮分析师做决策，而是帮他提供决策依据。不是干掉他，而是让他从他做不好的事情上解放。

系统设计了一个”80% 完成度”的策略 + 人工 double check 的模式。这个 80% 不是妥协，是刻意设计的——承认 AI 的局限，系统才会变得可靠。

核心是 AI 的不可靠性是否可控。

如果不可控，那就在人的监督下运行。如果可控，就可以设计机制来自动检测和处理问题，最终实现”把它交给它”。

当下的 LLM，答案显然是前者。但这不妨碍我们用它来构建一个在 AI 不可靠时依然可靠的系统。

13.6 关于大模型应用的一条总结

最后：借助大模型做风控分析，不要走”全靠大模型”的路，而应分层拆解任务、组合多种模型与规则。

大模型最适合放在归因、解释、标注辅助等环节。而最终决策，仍建议保留规则与轻量模型的组合机制。

十四、这套能力不止能用在风控上

做这个项目最大的收获，不只是一套风控系统，而是一套可迁移的方法论。

回头来看，这个项目实际上产出的是几层可复用的能力。

14.1 第一层：复杂业务流程的 Agent 化拆解

我们验证了一件事：一个复杂的、多步骤的、需要多人协作的业务流程，可以被拆解为多个 Agent 的协同工作流。

关键在于三条原则：

– 单一职责：每个 Agent 只做一件事，可独立评估、可回归、可复用

– 并行与串行结合：独立模块并行跑，依赖模块串行跑，最大化效率

– 证据层与结论层分离：中间不做过早的推断，每层只做自己该做的事

这套拆解方法论不依赖任何风控领域的知识。只要你有一个”人工分析 → 判断 → 决策”的业务流程，都可以用这个框架来设计。

14.2 第二层：从业务数据到结构化分析的工程方法论

这个项目最重的投入不在模型，在数据。我们花了大把时间在：打通数据、建宽表、理解字段含义、做数据加工、设计补数方案。

这个过程沉淀了一套”数据就绪”的方法论：

– 怎么从多源异构数据中提取关键字段

– 怎么处理数据缺失（不是每个 case 都有完整数据）

– 怎么理解字段的业务含义（连业务方自己都不清楚的时候怎么办）

– 怎么做数据质量校验（过滤无效数据、去重、异常值处理）

这套方法论在任何一个需要”用 AI 分析业务数据”的场景里都会遇到。风控如此，零售分析、运营分析、供应链分析也一样。

14.3 第三层：AI 输出的可控性工程

我们花了大量时间不是让 AI “更聪明”，而是让 AI “不犯错”。29 条 prompt 规则、四维评估体系、测试集设计——这些做法本质上是在解决一个通用问题：怎么让概率预测器的输出变得可预期、可回归。

不管你的业务场景是什么，只要你的系统依赖 LLM 输出来做决策，你都会遇到：

– 模型脑补（信息不足时编造）

– 输出格式不稳定

– 无法评估”好不好”

– 改了 prompt 之后效果不可预期

我们在这方面的实践——把 prompt 当接口文档写、铁律约束、空输出机制、评估体系——可以直接复用到任何 LLM 应用场景。

14.4 第四层：隐性知识的显性化方法论

这个项目最难的部分既不是技术也不是数据，是”把分析师的脑子拆成 SOP”。

我们摸索出来的方法，给选择题，用 AI 梳理框架让她选，多轮迭代——本质上是把领域专家说不出来的隐性知识逼出来的方法。这个方法在风控里有用，在医疗诊断、金融审核、设备运维、客户服务，任何”专家比新人强但说不清怎么强”的领域，都有用。

14.5 第五层：容错优先的系统设计哲学

这是贯穿整个项目的核心认知：在复杂系统里，容错率比能力强更重要。

当一个系统有 5-6 个环节时，每个环节 90% 准确率，最终只有 60%。如果每个环节一味追求 95% 的准确率，成本会指数级上升，但系统整体效果提升有限。更务实的做法是：接受 80% 的准确率，用机制设计来兜底——中间结果暴露、人工介入、硬逻辑兜底。

这套设计哲学决定了：你的 Agent 应该是 Copilot 而不是 Autopilot；你的输出应该是”80% 完成度的草案”而不是”一步到位的成品”；你的系统应该承认 AI 的局限，不能假装它无所不能。

这套哲学也不止适用于风控。它适用于任何一个在真实环境里运行的 AI 系统。

十五、更多场景落地

15.1 场景一：线下连锁零售的商品分析与预警

你可能面临的问题：几十人的数据分析团队，人工分析周期要数周。女装流行变化快，等分析结果出来款早就过了。更致命的是不会预警——问题出现一周后才被发现，又一周才能出应对方案，两周就过去了。

我们的方法论怎么用：

– Agent 拆解：选品预测 Agent（分析销售趋势预测爆款）、动销分析 Agent（每个门店畅销/滞销品识别）、预警 Agent（滞销预警、断货预警）、用户画像 Agent（年龄段变化趋势）

– 数据就绪：打通 ERP 库存数据、POS 销售数据、会员数据、门店坪效数据，建商品维度和门店维度大宽表

– AI 可控性：预测报告按模板输出：畅销品 Top N、滞销品 Top N、趋势变化、置信度标注；信息不足时标记”数据不足以预测”而非瞎猜

– 隐性知识提取：把买手选品的经验拆成可执行的维度——品类趋势、季节性规律、历史爆款特征、区域差异

– 容错设计：80% 准确率的选品建议 + 人工复核，系统做预警而非做决策

结果：不用等到问题暴露再应对，系统 T+1 预警，分析周期从数周压到 1 天。

15.2 场景二：金融机构的合规审查与报告生成

你可能面临的问题：每天要处理大量交易合规审查，需要人工从多个系统拉数据、对比规则、写报告。合规人员加班是常态，但出错还是要被罚。新人培训半年才能独立出报告。

我们的方法论怎么用：

– Agent 拆解：交易筛选 Agent（从全量交易中筛出可疑交易）、规则匹配 Agent（逐条对比合规规则）、证据收集 Agent（关联交易背景信息）、报告生成 Agent（输出合规审查报告）、风险评级 Agent（对可疑交易做风险评级）

– 数据就绪：打通交易系统、客户信息、黑名单库、历史案例库。处理不同系统的数据格式差异，建立统一的审查宽表

– AI 可控性：审查报告按监管要求的模板输出，每条结论附引用来源。信息不足时标记”需要补充材料”，不脑补。四维评估体系确保输出质量可量化

– 隐性知识提取：资深合规官判断”这笔交易有问题”靠直觉，但直觉背后是多年的经验。用框架把它拆解——交易金额、频率、对手方、交易时间、历史行为五个维度的综合判断

– 容错设计：系统生成 80% 完成度的审查报告 + 合规官做 final check，系统风险评级作为参考而非决定

结果：审查周期从几天压缩到几小时，合规官从写报告变成审报告。

15.3 场景四：电商平台的客服工单智能处理

你可能面临的问题：每天几千个客服工单，从用户投诉到退款涉及客服、质检、财务多个部门，每个环节都要人工判断。客诉量一大就处理不过来，用户满意度下降，重复投诉增多。

我们的方法论怎么用：

– Agent 拆解：工单分类 Agent（投诉/退款/咨询类型自动分配）、问题提取 Agent（从对话中提取订单号、问题描述）、处理建议 Agent（匹配历史案例生成建议）、质检 Agent（检查处理方案是否符合规则）、流转 Agent（把需要升级的工单推到正确的人手里）

– 数据就绪：接入客服系统、订单系统、物流系统、售后系统。把不同来源的工单、对话记录、处理结果关联起来建宽表

– AI 可控性：建议方案标注置信度，低置信度直接转人工。矛盾信息（用户说没收到货但物流显示已签收）标记为待核实，不做判断

– 隐性知识提取：金牌客服知道什么情况该退、什么情况该补券、什么情况该升级，把这些决策经验拆成可执行的规则

– 容错设计：常见问题 AI 直接回复，复杂问题 AI 整理信息后转人工。80% 工单 AI 可以给出完整处理建议，人为最后做决定

结果：客服处理效率翻倍，重复投诉减少，人工只需要处理最复杂的 20% 工单。

这些场景看似行业差距很大，但底层的核心问题一模一样：大量数据需要人工分析、流程环节长、高度依赖经验判断、响应速度跟不上变化。

我们的方法论——Agent 拆解、数据就绪、AI 可控性、隐性知识提取、容错设计——每一层都可以独立迁移到这些场景中。不一定要做 AI 替代人，先从 AI 提效开始。