01｜规则写到400 条时，我开始怀疑这条路本身

我是上海富友支付服务股份有限公司的技术负责人。富友是一家科技驱动型的支付公司，先后获得由中国人民银行颁发的多项支付业务资质，也是上海市高新技术企业、上海市重点软件企业、上海市 100 强软件企业。我们以富掌柜数字化收银、多用途预付卡、金融科技解决方案、跨境收付款、基金支付、信用卡还款等为核心业务矩阵，团队每天处理千万级交易流水，服务的活跃商户超过十万家，餐饮、零售、跨境电商什么都有。

风控组一直是公司的"压舱石"。我们有六个资深风控专家，维护着四百多条规则，从金额阈值到时间分布到支付方式组合，能想到的维度基本都写进去了。

但去年下半年开始，我越来越明显地感觉到一件事：规则写得越多，系统越脆弱。

新的套现手法三五天一变，我们的分析-验证-上线周期要两三周。风控组的同事每天早上第一件事就是看昨天有没有漏网之鱼，大部分时间花在了"人肉巡检"上。更让我焦虑的是，真正能写出高质量规则的就那两三个老人。新人上手慢，老人一旦离职，规则背后的经验就断了。

这不是"加人"能解决的问题。

02｜我为什么没有自建，而是选择了阿里云 Data Agent

其实我一开始考虑的方案是自建：找个算法团队，搭一套特征工程流程，跑模型出评分。支付行业里做这件事的公司不少。

但我很快否掉了这个路线，原因有三：

第一，我没有专职算法团队。支付公司核心是交易系统和合规，养一个 3-5 人的算法组成本高、且很难持续迭代。

第二，特征工程是最大的坑。跟几个做过风控模型的朋友聊完，我发现真正耗时的不是跑模型，而是从业务数据里"翻出来"哪些特征有用、怎么组合。这个过程极度依赖领域经验和反复试验，一轮做下来两三个月是正常的。

第三，我需要的不是一个模型，而是一套可以跟着业务变化持续演进的分析能力。 风险类型在变，商户结构在变，今天好使的特征三个月后可能就失效了。

这时候，一直跟我们保持合作的阿里云 TAM团队例行来问询业务进展，聊到我们在风控这块的拉扯，他说阿里云AI原生数据库服务的Data Agent，跟我们的场景挺契合的，建议我们先看一眼再决定要不要自建。我说那行，约个时间一起聊聊。

第一次沟通，TAM 拉着瑶池的产品和解决方案同学一起到我们公司，现场拿一份脱敏样例数据跑了个 demo：上传数据，Data Agent 自己跑商户画像、特征分析、建模、出策略报告，整个链路十几分钟跑完。

我当时的第一反应是"这不就是我想要的东西吗？"，但也没急着拍板。

后续 TAM 团队又帮我们组织了两轮深入对齐：第一轮聊我们的风控方法论能不能"翻译"成 Data Agent 的任务编排，第二轮直接拿我们脱敏后的真实数据跑了一次 PoC。PoC 跑完，团队里之前最保守的算法同学跟我说："这套东西如果我们自己搭，至少要半年。"

那次之后我才下定决心：不自建，上阿里云AI原生数据库服务的Data Agent。

03｜我们实际怎么用的：三层架构，Data Agent 打头阵

方向定下来之后，我们就带着团队基于Data Agent开始重构整套风控体系。从首轮 PoC 到核心策略全面切换，最终沉淀出一套三层架构，也是今天还在线上跑着的版本。

第一层：Data Agent 做数据洞察—"看清楚"

这是最核心的一层，也是我觉得 Data Agent 和传统工具差异最大的地方。

以前，风控特征从哪来？是业务专家拍脑袋总结经验，然后让算法同事翻译成代码，周期长、遗漏多。

现在，Data Agent 按照我们预设的分析框架，自动执行五个阶段：

1、商户画像：拿原始交易数据建立"正常商户长什么样 vs 风险商户长什么样"的行为基线。

2、特征分析：找出风险聚集最明显的区间，定位高风险阈值。

3、ML 特征挖掘：跑 XGBoost/LightGBM 学多维特征的组合关系——比如"交易规模偏低 + 活跃天数少 + 非 POS 比例高 + 失败交易多"这种人很难穷举的组合。

4、关联规则挖掘：用 Apriori 算法找出特征间的共现模式。

5、策略报告：自动输出哪些规则的召回率高、哪些误杀率可控，附带不同激进程度的策略对比。

关键点是：Data Agent 不是在"自由探索"。 我们把传统风控中验证过的分析方法（分箱统计、决策路径提取、关联规则挖掘）结构化地"教"给它，它在框架内执行。这就避免了 AI 天马行空出一堆不可落地的结论。

第二层：机器学习底座—"算准确"

Data Agent 发现的特征，喂给机器学习层做统一的风险评分。这里有个实践中踩出来的坑：不能一个模型打天下。

大商超和小微线上商户的"异常"定义完全不同。所以我们先用 KMeans 把商户按行为模式分成几簇，每簇单独训练 XGBoost 模型。另外对新入驻商户（数据不够）和外卡商户（高危场景）单独建模覆盖盲区。最终多模型融合出统一风险分。

第三层：大模型推理—"说明白"

风险分出来了，但业务同事看到的不能只是一个分数。LLM 层的作用是把"为什么这个商户分高"翻译成人话：哪些特征贡献了风险分，属于什么风险类型，建议怎么处置。

有个定位我觉得想得很清楚：大模型是"解释层"不是"决策层"。 核心判断靠前两层的数据和模型，大模型负责让人看懂和信任。这样既有 AI 的推理能力，又不会出现"黑盒给了个结论但谁也不敢信"的尴尬。

04｜实际跑出来的效果

实际执行下来，几个数字让我确认这件事走对了：

• 分析效率：从 2周缩短到1天

过去一轮完整的特征分析和规则构建，从商户画像到策略验证，团队怎么也要两周。现在 Data Agent 一轮五阶段分析1天内跑完，第二天就能进入策略评审。

• 覆盖率：提升到90%

不再是"风控组每天看几十家"的人力模式，而是对全量商户系统性评分和排序。高风险商户直接进入处置流程，中风险的自动监控。

• 知识沉淀：方法论固化在系统里，不怕人走

以前最怕的是老专家离职带走经验。现在分析方法论固化在 Data Agent 的流程编排里，新人上手成本大幅降低。

05｜几个踩坑经验，给同行参考

别让 AI 自由发挥。

最开始我也试过让 Data Agent 不加约束地"自由分析"，出来的东西统计结论一大堆但跟业务落地隔了十万八千里。后来把传统风控方法论拆成任务编排，效果好了一个量级。

分簇是必须的。

一个模型试图同时区分大商超和小微商户的风险，黑白样本始终收敛不了。加了 KMeans 分簇之后，每个簇内模型的 AUC 都明显提升。这个坑我们踩了两三轮才想明白。

LLM 不能做最终判定。

我见过有团队试图让大模型直接判断"这个商户有没有风险"，在生产环境里出过事。我们的定位很明确：量化判断靠数据和模型，LLM 只做解释和辅助。

06｜最后

回过头来看，当传统规则引擎走到极限，AI “不是替代了人”，而是改变了风控的生产方式。而阿里云AI原生数据库服务的 Data Agent，是把这件事跑通的最优解。

以前是"人看数据→人总结经验→人写规则"，现在是"Data Agent 看数据→机器发现规律→机器给出评分→人做终审"。人的角色从"劳动者"变成了"审核者"和"方法论设计者"。这个角色更有价值，也更可持续。

如果你也在做金融风控，遇到规则写到头了、老专家快退了、覆盖率上不去这类问题，可以看看阿里云AIDBS 的 Data Agent 能不能帮到你。

不一定要像我们一样一步到位做三层架构，从"让 Data Agent 先跑一轮特征分析"开始，你就能感受到区别。

07｜想亲手试试 Data Agent 的数据洞察能力？

阿里云AI原生数据库服务的 Data Agent 现已开放免费体验，每天 30 分钟，上传你的业务数据即可一键启动智能分析洞察——无需部署、无需写代码、开箱即用。

了解产品详情：Data Agent for Analytics-数据管理 DMS-阿里云帮助中心

点击下方链接，立即开始你的第一轮数据洞察吧：数据管理 DMS 控制台