这两年做信贷风控系统的自动化迭代，坦白说对“智能风控”这四个字已经有了一些免疫力。真正让我改变想法的，是AI Agent以“编排者”身份切入后，把以前只能靠人肉完成的材料解读、多源信息串联、风险叙事生成这些环节，第一次变成了机器可执行的流水线。AI Agent在智能金融风险评估中的应用，核心不是再训练一个更大的预测模型，而是把“人看材料、查数据、下结论”的过程拆解成可编排、可留痕、可审计的智能工作流。
这篇博文不聊概念，只聊我在实际项目里验证过的东西：为什么传统评分卡做不到、Agent架构怎么搭、提示词怎么设计、工具调用怎么并行化、以及上线后最容易翻车的几个坑。适合正在做风控系统升级、或准备把大模型能力引入金融决策链条的工程师和决策者参考。
1. 传统智能风控的瓶颈：为什么偏偏是Agent
1.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_required=true，把问题留给人工。这在初期非常重要，能大幅降低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 灰度期评估指标设计
灰度期我们使用了下面这套指标，覆盖效果、质量、稳定性三个维度：
| 评估维度 | 指标名称 | 目标值 |
|---|---|---|
| 效果 | 人机结论一致性（Cohen's Kappa） | ≥ 0.70 |
| 效果 | 高风险客户召回率 | ≥ 0.85 |
| 质量 | 建议拒绝但人工通过的比例 | ≤ 5% |
| 质量 | 生成理由忠实度（抽样复核） | ≥ 90% |
| 稳定 | 端到端延迟P95 | ≤ 8秒 |
| 稳定 | 大模型服务可用性 | ≥ 99% |
这里特别提一下“生成理由忠实度”这个指标。我们会随机抽10%的Agent报告，让业务专家逐条对照工具返回字段，检查生成理由里的每个断言是否有证据支撑。这套主观指标虽然采集成本高，却是发现幻觉问题最有效的手段。
写在最后：给想在金融场景落地Agent的同行几句实话
项目做下来，我最大的感受是：Agent在金融风险评估里的价值，不在于跑得比人快，而在于让每一次风险判断都有据可查、有迹可循。它把分析员的经验沉淀成了可复用的工作流，而不是让模型直接替代人拍板。
如果正在读这篇文章的你也准备动手，我的建议是先砍掉一半野心，从一个具体场景切入，把数据解析、工具调用、人审反馈这四个环节的日志留全。后面再谈扩展。
我自己尝试跑通这套架构后，已经把方向放到了贷后预警：把贷后财务数据变化、行业舆情、实控人风险事件串成一个连续监控的Agent工作流。那又是一个新的故事了。
