★ FEATURED ARTICLE 这两年做信贷风控系统的自动化迭代坦白说对“智能风控”这四个字已经有了一些免疫力。真正让我改变想法的是AI Agent以“编排者”身份切入后把以前只能靠人肉完成的材料解读、多源信息串联、风险叙事生成这些环节第一次变成了机器可执行的流水线。AI Agent在智能金融风险评估中的应用核心不是再训练一个更大的预测模型而是把“人看材料、查数据、下结论”的过程拆解成可编排、可留痕、可审计的智能工作流。这篇博文不聊概念只聊我在实际项目里验证过的东西为什么传统评分卡做不到、Agent架构怎么搭、提示词怎么设计、工具调用怎么并行化、以及上线后最容易翻车的几个坑。适合正在做风控系统升级、或准备把大模型能力引入金融决策链条的工程师和决策者参考。1. 传统智能风控的瓶颈为什么偏偏是Agent1.1 传统模型没有拆任务的能力传统风控模型无论是逻辑回归、XGBoost还是深度学习评分卡本质都是“输入固定特征、输出一个值”。这个流程在特征工程完备、数据标准化程度高的场景里很稳定但它有两个先天短板。第一个短板是非结构化信息吃不下。客户上传的财务报表、客户经理写的现场尽调纪要、企业舆情摘要这些文本里往往藏着关键风险信号比如“实控人近期频繁变更”“上下游账期明显拉长”“厂房抵押给民间资金方”。但传统模型只能通过人工把这些信息变成标签或特征耗时不说还容易遗漏。第二个短板是任务无法动态拆解。一个客群的申请材料可能需要查司法涉诉另一个客群可能只需要查多头借贷传统规则引擎面对这种分支逻辑只能硬编码。我见过某平台的风控规则库里躺着几百条if-else每次业务调整都要开发排期改一次上线一周等上线了风险形态又变了。这两个短板叠加导致风控策略迭代始终追不上业务变化速度。这也是Agent能切入的根本原因Agent天然具备“拆解目标—规划步骤—调用工具—汇总结果”的能力恰好补上传统模型没有的流程智能化环节。1.2 风控规则和模型之间缺一个“串联叙事”的层传统风控系统里规则引擎负责命中风险项评分模型负责输出违约概率但两者之间是割裂的。业务人员看到的是“规则命中3条”“评分582分”但这些信号之间是什么关系、哪个风险是主因、哪些信息还需要补查系统给不出来。打个比方一套传统系统像一摞检查表黑名单查了、涉诉查了、工商异常查了每个结果单独打钩。但把这些钩连成一段逻辑清晰的风险描述需要的是一个能理解上下文的分析员。Agent就是来做这个串联的。它可以先调用黑名单接口发现实控人关联企业有一条被执行记录再调用司法涉诉接口确认执行标的金额然后结合评分卡输出“该客户还款意愿存疑建议人工介入核实资金来源”。这个过程里Agent不只是简单地罗列接口结果而是把多个信号组织成有因果关系的风险叙事。1.3 Agent不是替代模型而是模型之上的编排者很多人一听到Agent引入风控第一反应是“把审批决策交给大模型”这个理解很危险也是我一开始最担心的事。实际落地时我的原则非常明确预测能力仍然由传统判别模型负责大模型Agent只负责“阅读理解、工具调度、信息整合、报告生成”不直接输出分数更不直接做最终决策。这样分工的原因很简单大模型在定量计算上不可靠但在语义理解和多步推理上有优势评分卡、GBDT这类模型在定量预测上稳定可复现但理解不了文本。二者结合错位竞争才能既保住风控口径的一致性又补上非结构化信息的处理能力。我常说Agent在风控里的定位像一个“分析员实习生”它不签字但负责把材料读透、把数据查全、把疑点标出来让有审批权的老人只做最后的判断。2. 智能风险评估Agent的系统架构与关键模块2.1 五层架构与各层职责整个系统的架构我按职责拆成了五个层次这样既方便团队分工也方便后续单独替换某个环节。层级核心职责关键技术点数据接入层对接申请资料、内部征信、外部数据源统一字段格式、脱敏、鉴权模型推理层输出评分、标签、特征评分卡、GBDT、风险规则引擎Agent编排层任务拆解、工具调用、多步推理状态机、提示词控制、工具注册生成表达层生成风险报告、解释理由大模型文本生成、结构化JSON约束人工复核层人审工作台、留痕、反馈回写建议展示、一键通过/拒绝、反馈采集其中Agent编排层是整个系统的大脑其余四层都是它的“手和眼”。实际开发中我建议把Agent编排层拆成独立的服务不要和业务主流程耦合太深。否则后续迭代一次提示词整个风控系统都要跟着发版风险很大。2.2 底座模型与判别模型的配合方式先说说底座的选择。金融场景对数据安全要求高我们用的是私有化部署的开源基座模型再基于脱敏后的历史审批记录做了指令微调。模型参数量级在70B左右单次推理耗时可以接受。这里有个很关键的细节不要让大模型直接读原始申请材料的全部内容而是先由解析服务把PDF、图片、扫描件转成结构化的字段比如“营业收入”“负债总额”“实控人变更记录”再把这些结构化字段喂给Agent。这样做有三个好处一是减少大模型幻觉空间二是降低Token成本三是解析环节可以复用已有的OCR和文档解析能力不用重复造轮子。判别模型这边我们保留了原有的评分卡把它的输出score、规则命中列表、特征重要度一并传给Agent层。Agent的提示词里会明确说明“客户评分为XXX分命中规则列表为[...]这些数据以字段为准不得自行修改。”2.3 Agent工作流状态机设计Agent在风控场景里不能是自由对话式的内容生成器而应该是一个受控的状态机。我们设计的核心流程分六个状态材料解析、风险信号抽取、工具调用、推理研判、报告生成、复核输出。用一个简化的JSON描述状态流转{ states: [ material_parsing, signal_extraction, tool_calling, judgement, report_generation, review_output ], transitions: { material_parsing: [signal_extraction], signal_extraction: [tool_calling], tool_calling: [judgement, report_generation], judgement: [tool_calling, report_generation], report_generation: [review_output] } }每个状态都对应一个独立的处理函数状态之间传递的数据是严格的Schema不允许传递自由文本。这样做的最大好处是可控如果工具调用失败了状态机可以直接进入“信息缺失”分支强迫Agent在报告里标注unknown而不是硬编一个答案。2.4 工具注册与数据源接入Agent的“手”体现在工具调用上。我们把常用的数据查询封装成一个个函数Agent根据任务自主决定调用哪些工具。工具清单大致如下工具名称输入参数关键输出字段主要风险信号查询司法涉诉公司名称、实控人姓名被执行次数、案件类型、执行标的总金额涉诉频繁、被执行金额大查询企业工商信息公司名称注册资本、成立年限、股权变更次数频繁变更股东、成立时间过短查询多头借贷实控人身份证号Hash近3个月申请次数、放款机构数多头申请、以贷养贷迹象查询舆情摘要公司名称负面事件标签、热度指数经营异常、负面舆情爆发查询内部历史借贷统一社会信用代码历史逾期次数、循环授信使用率历史逾期、授信使用率过高工具返回的字段必须经过一层“字段白名单”过滤Agent只能看到白名单内的字段杜绝模型接触无关敏感信息。比如诉讼文书里面可能有大量与风险无关的细节直接暴露给模型既增加幻觉概率也带来合规压力。3. 从零到一完整落地实操记录3.1 场景选择与目标定义Agent适合切入的场景需要同时满足三个条件信息源多但分散、决策依赖人工阅读、单笔决策有足够时间。我们最终选定的是小微企业贷前风险初筛原因是小微企业的申请材料往往最杂既有结构化数据又有财务报表、流水截图、访谈记录非常考验分析员的综合判断能力。目标定得非常具体将人工初审的平均时长从12分钟压缩到5分钟以内。在不扩大客群风险敞口的前提下将建议拒绝的准确率提升5个百分点。保证所有Agent生成的初筛报告100%留痕可供审计追溯。指标不贪多三个够了。贪多就会分散精力而且灰度期采集有效样本需要时间指标设太多周期会拉得很长。3.2 数据准备与知识库构建很多人以为Agent落地最大的成本是模型训练实际上数据准备工作量更大。我们做了三块数据建设。第一块是历史申请材料的脱敏解析。把过去两年的历史审批记录翻出来对PDF和扫描件做OCR再按统一Schema抽取关键字段。这一块纯粹是体力活但必须做扎实因为Agent能理解什么取决于上游解析给到它什么。第二块是专家审核结论的结构化。历史审批意见书里审批员会写“同意理由经营流水稳定负债率适中但需关注近期股权变更”这类文本。我们用正则加小模型辅助的方式把这些文本拆成“结论、理由、关注点”三个维度形成标准化样本。第三块是知识库样本的选择。不需要几十万条全量入库质量比数量重要。我们从不同行业、不同风险等级中各选200条左右覆盖典型场景人工审核后作为提示词的few-shot示例。实际经验是知识库样本控制在300条以内时效果最可控太多反而干扰模型判断。3.3 Agent提示词与输出约束设计提示词是整个系统里迭代最快的地方。我们的系统提示词简版如下你是某金融机构的小微企业贷前风险分析助理。 收到申请材料解析结果后按以下步骤处理 1. 根据材料解析结果列出关键风险信号优先关注司法涉诉、多头借贷、经营异常。 2. 对有疑问的信号调用对应工具获取最新数据。 3. 基于工具返回字段给出risk_level低/中/高和具体理由。 约束 - 所有数值、金额、日期必须来自工具返回字段禁止自行推算。 - 某一项信息无法获取时对应字段输出unknown禁止猜测。 - 输出必须为JSON格式包含risk_level、key_risks、 supporting_evidence、manual_review_required、suggested_actions。这个提示词有几个关键设计。第一禁止自行推算。大模型算数能力堪忧让它自己算负债率、收入环比几乎必错。我们实测让模型计算“负债总额/资产总额”看似简单但样本里超过三成结果有偏差。所以所有财务比率都由上游特征工程统一计算Agent只做“取数”和“引用”。第二强制JSON输出。这样做是为了方便下游人审工作台直接解析字段也减少了自由文本带来的歧义。第三给Agent一条“求助路径”。当它发现某个关键信息缺失时可以输出manual_review_requiredtrue把问题留给人工。这在初期非常重要能大幅降低Agent硬着头皮下结论的概率。3.4 工具调用并行化与延迟优化刚上线时系统跑得很慢单个请求端到端延迟在15秒左右这个速度没法让审批员舒服地用。分析发现延迟大头在工具调用环节司法涉诉、工商、多头、舆情四个外部接口是串行执行的平均每个1.2秒加起来近5秒再加上前序LLM解析和后续报告生成各占1到2秒总延迟自然居高不下。优化方案有三个。第一工具调用并行化。Agent先做一次信号预判确定需要调用哪几个工具然后并发发起请求等所有结果返回后再进入研判状态。改动后工具调用环节从4.8秒降到1.9秒。第二加缓存层。对高频查询的企业工商信息、舆情摘要设置五分钟到一小时的本地缓存重复申请同一企业时命中缓存直接返回。第三控制LLM调用次数。方案里原本设计了两轮LLM调用——先解析、后生成实际上我们把第一轮解析改为规则小模型处理只有信号抽取后需要判研时才调用大模型。整体端到端延迟中位数最终稳定在6秒以内。3.5 人工复核工作台与灰度策略Agent系统上线不是一键切换而是灰度渗透。我们的策略是分三批放量第一批选取10%的低风险客群Agent只生成初筛报告不直接给出审批结论人工复核员需要在工作台里看到Agent建议并对比自己的判断全部结论仍由人工点击确认。此阶段核心是收集人机结论一致性数据。第二批扩大到30%的客群Agent可以直接对“低风险”客群给出“建议通过”但高风险结论必须人工复核。这里注意Agent的建议永远标注为“AI建议”不允许直接作为最终审批结果展示给客户。第三批全流量接入但保留人工抽审机制。每周按一定比例对Agent建议通过的订单进行人工复盘。工作台设计上核心是“一眼看全”。左侧展示Agent生成的JSON结论和风险等级中间是工具返回的关键字段证据右侧是人工操作按钮。页面必须突出证据链接点击某条风险描述能直接跳转到对应工具的原始返回记录。没有证据链支撑的结论在人工眼里就是不可信。4. 实战避坑手册问题、诊断与解决方案4.1 幻觉问题数字不一致比结论错误更致命金融场景最不能忍的不是Agent判断错了而是它编造了一个看似合理但实际不存在的数字。我们在灰度期就撞上过一次Agent在报告里写“该企业近6个月纳税额环比下降42%”但工具返回的历史数据里根本没有纳税字段。溯源后发现模型把“利润总额”和“纳税额”两个概念搞混了在上下文里自己脑补了这个数字。从这之后我们立了两条规矩所有关键数字字段在提示词里用“只读标记”强调并在解析阶段做规则校验如果生成文本里出现不在工具结果集合里的数字型字段直接拦截并重写。禁止Agent在理由中引入未调用过的数据源。比如它没调用过舆情工具就不能在报告里说“舆情监测显示负面新闻”。4.2 工具调用失败与降级策略外部数据源不可能永远稳定。我们遇到最多的是司法涉诉接口超时和舆情接口限流。最初的实现里Agent遇到工具报错就直接把这个信号丢掉了结果风险报告漏掉了关键信息。后来调整为显式的降级逻辑工具调用失败时状态机强制向报告写入“该数据源本次查询失败”并把对应风险项标记为“待人工核实”。同时Agent会被要求重新审视其他已有信号如果其他信号已经指向高风险即使缺失一项数据也可以建议人工介入如果其他信号都正常则不要因为缺失数据而直接通过而是标记为“信息不完整建议补充材料”。4.3 可解释性不一致生成理由和模型结论打架有段时间我们发现Agent输出的risk_level是“低风险”但理由里却列了三条高风险信号。排查发现原因是Agent在研判阶段过于依赖那一次“综合判断”的语义生成而忽略了工具结果的权重。解决思路是引入“结论一致性校验”。我们用规则引擎先把工具返回字段映射成一个“规则投票”比如司法涉诉有执行标的超过100万就投一张高风险票。再让Agent输出结论最后系统自动比对如果Agent结论与规则投票偏差超过一个等级就强制触发复核流程。这个机制上线后人机结论一致性从0.71提升到了0.83。4.4 服务稳定性与流量控制Agent系统引入大模型服务后最头疼的是稳定性。高峰时段并发一上来大模型推理服务响应时间会从2秒飙到10秒以上。我们的应对方案比较务实大模型服务单独部署与业务接口之间加一层队列超时请求直接降级为“规则引擎人工处理”不让Agent成为单点故障。设置熔断开关一旦大模型服务错误率超过5%自动把流量切回传统人工流程等恢复后再切回。每个Agent任务都设总超时上限超过25秒直接终止并转人工。这些机制不复杂但上线前后必须反复压测。金融场景稳定大于一切哪怕是“AI辅助”也不能因为技术故障影响正常审批链路。4.5 灰度期评估指标设计灰度期我们使用了下面这套指标覆盖效果、质量、稳定性三个维度评估维度指标名称目标值效果人机结论一致性Cohens Kappa≥ 0.70效果高风险客户召回率≥ 0.85质量建议拒绝但人工通过的比例≤ 5%质量生成理由忠实度抽样复核≥ 90%稳定端到端延迟P95≤ 8秒稳定大模型服务可用性≥ 99%这里特别提一下“生成理由忠实度”这个指标。我们会随机抽10%的Agent报告让业务专家逐条对照工具返回字段检查生成理由里的每个断言是否有证据支撑。这套主观指标虽然采集成本高却是发现幻觉问题最有效的手段。写在最后给想在金融场景落地Agent的同行几句实话项目做下来我最大的感受是Agent在金融风险评估里的价值不在于跑得比人快而在于让每一次风险判断都有据可查、有迹可循。它把分析员的经验沉淀成了可复用的工作流而不是让模型直接替代人拍板。如果正在读这篇文章的你也准备动手我的建议是先砍掉一半野心从一个具体场景切入把数据解析、工具调用、人审反馈这四个环节的日志留全。后面再谈扩展。我自己尝试跑通这套架构后已经把方向放到了贷后预警把贷后财务数据变化、行业舆情、实控人风险事件串成一个连续监控的Agent工作流。那又是一个新的故事了。
阅读完成 · 觉得有帮助？
