在金融信贷场景里折腾过AI落地的人应该都有同感模型训练已经不是最大的卡点真正让人头疼的是怎么把“能回答问题的模型”变成“按业务流程办事的智能体”。我最早做信贷初审助手的时候先是接大模型API结果发现它只管生成文本客户想查个征信得分、调个黑名单记录还得靠人工复制粘贴去各个系统里捞数据。后来接触了华为云智果 AgentArts才算把“对话能力”和“业务执行能力”真正捏到了一起。这篇实战记录就是基于我用 AgentArts 搭建金融信贷 AI 智能体的全过程适合正在做智能体开发、或者想给信贷业务引入AI能力的同学参考。开头先把结论放这儿AgentArts 这类平台的价值不在于“又给了一个写提示词的地方”而在于它把模型、工具、知识库、流程编排、权限管控这些事情统一收敛到了一个可运维的工程体系里。信贷业务对准确性、可追溯性、合规性的要求远高于一般客服场景这决定了智能体不能只是“聊天机器人套壳”它必须是一个可以审计、可以回滚、可以灰度发布的完整技术产品。下面我会从业务拆解、架构设计、实操搭建、踩坑实录四个方面展开尽量把每一步背后的为什么也说清楚。1. 动手之前先把信贷场景的痛点拆明白很多团队做金融AI失败不是技术不行是压根没把业务场景拆到位。所以我先不急着讲平台操作而是把信贷流程里那些“适合智能体干”和“暂时不适合智能体干”的活分开看。1.1 传统信贷流程的三大堵点信贷业务从进件到放款的链路大致是客户申请、资料收集、反欺诈校验、征信评估、额度测算、人工审批、签约放款、贷后监控。流程看起来清晰但实际操作中至少有三个地方让效率上不去第一是信息割裂。客户经理要在反欺诈系统查黑名单在征信平台拉报告在税务系统验发票在银行流水里看交易每个系统都得单独登录、单独复制结果再做人工汇总。这种“人在中间搬数据”的模式既慢又容易出错。第二是规范执行不统一。同样一份征信报告不同审核员关注的指标权重不一样有的看重逾期次数有的看重负债率结果就是审批标准飘忽不定。制度文档写得再细执行层面还是会打折扣。第三是重复劳动占比过高。我见过一个消费金融团队初审岗每天处理几百个进件其中大量工作是对着固定字段做比对、找异常值、填审核表真正需要经验判断的占比其实不到三成。这就很浪费。1.2 AgentArts 到底解决了什么问题AgentArts 给我的直观感觉是它把“智能”和“连接”整合成了一个工程化的东西。你可以在一个平台里搭出这样一条链路——用户提交进件资料之后智能体自动调用反欺诈插件查黑名单调用征信解析工具读取征信报告关键字段再把这些结果连同知识库里调出来的制度规则一起交给大模型生成初审意见最后把审核结论推送到人工复核队列。整个过程中模型负责理解和推理插件负责执行动作知识库负责提供依据流程编排负责控制走向。这套东西组合起来的意义在于它把原来靠人搬数据的环节自动化了而且每一步都有日志、可追溯。这对信贷业务太重要了——不是简单“让AI干活”而是“让AI干完活之后能解释自己为什么这么干”。2. 信贷智能体的整体架构四个模块一个都不能少如果你只把 AgentArts 当做一个“对话框里加工具”的开发平台那格局就小了。以我搭信贷初审智能体的经验来看一个能稳定上线的智能体至少要拆成四个层次入口与意图识别、流程编排、工具调用、知识与管理。缺任何一个后面都会出幺蛾子。2.1 一个可落地的智能体长什么样讲一个具体例子。我设计的第一版“贷前初审助手”入口在客户经理工作台里客户经理把进件信息一笔一笔录入或上传。智能体先做意图识别判断这条进件属于“个人消费贷”还是“小微企业贷”因为这两个品类的审查重点差异很大——个人主要看征信和负债小微企业还要额外看工商信息、税务数据、对公流水。意图识别完之后进入编排流程。AgentArts 支持把流程画成有向图节点之间可以放“条件判断”“平行调用”“人工确认”这些逻辑。我在初审流程里放了三个平行节点反欺诈查询、征信解析、流水特征提取三个节点全部返回之后再进入额度测算节点。这样设计的好处是耗时可控三个接口并行调用总共耗时取决于最慢的那个而不是串行累加。2.2 工具层、模型层、编排层怎么分分层这件事听起来是架构师的活但实际写智能体的人如果一开始不这么想后期改起来会痛不欲生。我的习惯是工具层只负责“稳定地拿到干净的原始数据”。比如征信解析插件入参是授权号出参是固定结构化的JSON字段不掺任何模型判断。这样做的好处是即使大模型换了一个工具层完全不用动。模型层只负责语言理解和生成。AgentArts 侧接了多个大模型我对比下来金融文书类任务对模型的指令遵循能力要求很高选型上宁可选一个“听话、输出格式稳定”的而不是“文采斐然但格式随意”的。编排层管流程、状态和异常。谁先谁后、失败重试几次、超时了怎么兜底都在这一层定。知识层放制度文档、产品手册、历史审批案例通过向量检索为大模型提供“业务上下文”。我在实际项目里还加了一层“人工兜底层”。所有智能体给出的审核建议都只是建议最终推到人工复核队列由审核员一键确认或修改。这个设计不是为了不信任AI而是信贷场景的容错空间太小保留人在回路是底线。提示千万不要为了追求“全自动”而取消人工复核节点。一旦某个环节出问题追责和整改的成本远高于你省下的那点人力。3. 实战从零搭一个贷前初审智能体理论说了再多不如上手实操一遍。这一节我按实际搭建顺序写步骤之间都有因果逻辑你跟着走基本不会卡壳。3.1 环境准备与平台接入在华为云侧先把 AgentArts 服务开通这个倒不复杂。创建工作空间的时候建议按“业务线环境”去建比如“credit_loan_prod”和“credit_loan_test”分清楚别把测试和生产混在一个空间里。我见过有人图省事全放一起结果调接口时把测试数据打到生产知识库出过事故。创建完工作空间接下来要把数据源接进来。信贷初审要用的数据主要走企业内部的接口网关AgentArts 支持标准 API 插件注册方式你把反欺诈查询接口、征信解析接口、流水特征接口按 OpenAPI 文档注册进去就行。注册时有个细节超时时间一定要按接口真实情况设置不要拿到文档就填个默认3秒。反欺诈系统常常要从多个数据源聚合结果真实响应可能是2到5秒如果你设了3秒超时会导致大量调用被误杀。3.2 设计意图识别与主流程意图识别我用的是“分类模型规则兜底”的组合方式。AgentArts 平台里可以直接配置用户输入的分类意图也可以把模型输出映射为结构化动作。我的落地做法是先用大模型判断进件类型和业务动作同时用规则引擎做一层校验。规则很简单——如果文本里包含“经营贷”“流水”等词就强制切到小微企业贷分支如果包含“车贷”“房贷”等词则切到对应的抵押类分支。双保险的好处是即使模型抽风规则还能把流程拉回正常轨道。主流程的节点顺序我整理成了下表你可以直接照搬改造节点动作输入输出start_node接收进件输入客户信息、申请信息标准化进件对象intent_classify判断业务品类标准化进件对象品类标签anti_fraud_check调用反欺诈接口身份证号、手机号黑名单命中结果credit_report_parse调用征信解析接口征信授权号征信结构化字段flow_analysis调用流水特征接口银行卡号、流水文件月均收入、异常交易标记rule_engine执行硬性规则校验上述所有输出硬性拒绝项llm_analysis生成初审意见上述所有输出知识库规则初审结论、风险点说明manual_review推送到人工复核初审结论人工确认结果3.3 调用信贷数据工具反欺诈、征信解析、流水特征工具调用是智能体能不能“办成事”的关键。我逐一说明这几个插件怎么配。反欺诈查询插件入参是身份证号和手机号出参是一个标志位加命中类型。这里有个坑有的反欺诈接口返回的是“命中次数”不是“是否命中”你直接拿给大模型去判断它可能会把“历史命中过”误读成“当前命中”。我的做法是在工具层就把结果归一化成risk_level: HIGH/MEDIUM/LOW和hit_type: MLM/COURT/OVERDUE这类枚举值让模型只做选择题不做阅读理解。征信解析插件本质上是一个OCR字段抽取的接口它把PDF版征信报告解析成结构化数据。如果你自己接这一类工具要特别注意对“未婚”“离婚”这类文本的识别——征信报告里常有手工批注OCR容易错。我处理的办法是让插件把原始文本和结构化字段都传回来模型在生成审核意见时引用的是结构化字段但人工复核时还能看到原始文本方便回溯。流水特征分析是这三类工具里最“重”的一个因为它涉及大量交易明细的处理。AgentArts 的编排节点支持调用长时间运行的异步任务我建议这种分析任务不要放在同步链路上而是先触发、后轮询结果避免整个智能体被一个慢任务卡死。流水特征主要关注月均收入稳定性、夜间交易占比、快进快出特征等输出为结构化指标。3.4 接入大模型做审核报告生成当反欺诈、征信、流水数据都齐了才轮到模型出场。这里我给模型设计了一个“只干一件事”的提示词策略输入所有结构化数据输出固定格式的 JSON 审核报告包含review_result通过/拒绝/补充材料、quota_suggestion建议额度、risk_points风险点列表、reasoning依据说明、confidence模型置信度。为什么不用对话式输出因为对话式文本没法直接对接下游审批系统。审核报告是要落库、要被人工复核岗逐条确认的固定格式 JSON 可以让后续消费者对结果做校验、排序、统计。模型层还要注意“数值计算”这个坑。大模型做加法乘法容易出错额度测算这种逻辑不要依赖模型算数而是把额度因子放进规则引擎里算。模型只负责解读比如规则引擎算出建议额度是 8.5 万模型负责写“根据月收入3.2万、负债率小于0.4、无逾期记录综合建议额度8.5万”这样的自然语言解释。4. 关键环节的细节打磨提示词、知识库、流控权限跑通流程只是第一步真正决定智能体能不能长久稳定运行的往往是那些看起来不起眼的细节。这里面水很深我挑三个印象最深的展开讲。4.1 提示词工程在信贷场景的特殊性在信贷场景里写提示词跟在通用场景完全不是一回事。通用场景讲究“多轮对话、灵活应变”信贷场景恰恰反过来——我追求的是“少废话、多守规矩”。这里有几个必须写死的口径第一是“禁止编造数据”。我要求模型在输出里区分哪些字段来自工具返回哪些字段来自知识库引用哪些字段来自模型推断。如果某个数据缺失模型必须如实标记字段缺失而不是顺着上下文猜一个数字填进去。第二是“禁止越权表达”。比如模型不能说“为您放款”只能说“您的申请已进入复核流程”。原因不难理解审批权限不能给一个模型任何涉及最终决策的表达都会带来合规风险。第三是“拒绝要讲原因”。人工复核岗每天看大量拒绝件如果模型只说“拒绝”不说依据复核的人还得自己翻一遍材料这智能体就白搭了。我让模型在输出风险点时必须带上数据依据例如“征信命中连续3期逾期属于产品设定的硬性拒绝项”这样人工复核几秒钟就能确认。提示写提示词的时候把“禁止做的事”和“必须做的事”分开写。混在一起模型容易顾此失彼尤其在长上下文中。4.2 知识库与RAG把制度文档变成智能体的判断依据信贷审核有一个显著特点规则太多。产品制度、风控政策、监管要求动辄几十份文档而且更新频繁。如果每次规则更新都要改提示词维护成本太高。我的做法是把这些文档统一投喂到知识库让 AgentArts 的 RAG 链路在模型生成前先检索相关内容把检索结果作为上下文片段传给模型。这里有两个参数值得讲。一个是检索的 TopK 值我把 TopK 设成6太少了可能漏掉关键条款太多了会让上下文膨胀、模型抓不住重点。另一个是引用溯源我强制要求模型在reasoning字段里标注“依据知识库文档《个人信贷审批管理办法2024版》第3.2节”这样人工复核时可以一键跳转查看原文。别小看这个设计它让智能体的结论从“看起来有道理”变成了“有据可查”。知识库还有一个容易踩的坑文档更新之后要记得重建索引。我一开始以为上传新文档覆盖旧文件就行结果模型还在引用旧版额度上限排查了半天最后发现是索引库里残留了旧分片。现在我把“每次更新文档后重建知识库索引”写进了发布检查清单。4.3 流控、权限与审计金融合规下的运行红线金融场景的智能体上线前最大的拦路虎往往不是模型效果而是合规和安全。AgentArts 本身提供了不少相关能力但怎么用好还是有一些门道。流控方面我给每个内部接口配置了独立的 QPS 上限防止智能体在进件高峰期把反欺诈系统打崩。具体数值不是拍脑袋定的——我拉了网关历史流量数据取峰值 QPS 再留30%的余量。另外在编排层设置了“全链路超时熔断”整个初审流程超过15秒就降级改为先记录进件、延迟处理避免在客户等待时无限重试。权限方面智能体的工具调用要分角色。客户经理能看到的工具和审核员能看到的不一样审核员能触发的操作又不等于管理员。AgentArts 支持按工作空间粒度做权限隔离我把“工具注册”“知识库更新”“流程发布”这三类敏感操作的权限单独收敛给管理员普通成员只保留运行和监控权限。审计方面我开启了对所有工具调用的全量日志。日志内容包括入参摘要、出参摘要、耗时、调用人、时间戳。敏感字段在日志里做脱敏处理只保留后四位比如手机号138****1234。这一条极其重要——我不是在吓你一旦出合规问题日志就是你的自保证据。5. 真实踩坑清单与排查实录这一段是压箱底的东西。以下问题都是我在实际开发和灰度过程中真实遇到的每一个都花了不少时间去定位和解决。我按“典型现象-根因分析-解决方案-预防措施”的结构写方便你直接对号入座。5.1 智能体“假死”接口慢导致整个流程卡住现象灰度测试时一部分进件突然在“反欺诈查询”节点卡住前台转圈几十秒最后超时失败。根因反欺诈系统在月底结算日业务量大真实响应从平时的1秒飙到8秒而我在插件注册时统一设了3秒超时和0次重试。超时之后编排节点直接抛异常但是我没配置异常兜底整个智能体就中断了。解决方案给“查询类”插件统一设置超时5秒重试2次重试间隔采用指数退避1秒、2秒。同时在编排层增加超时熔断单节点耗时超过阈值就直接把进件标记为“待人工处理”不让用户干等。预防措施上线前把所有依赖接口的P95、P99延迟都测一遍再按最坏情况设置超时和熔断参数。5.2 大模型“幻觉”把额度算错现象有一笔进件规则引擎给出的建议额度明明是 8.5 万但模型生成的审核报告里写了“建议额度12万”人工复核险些放错款。根因模型把额度测算的“因子解读”错当成了“额度计算”。它拿到了“月收入3.2万负债率0.35收入稳定”这几个因子自己心算推导出了一个额度区间而没有直接引用规则引擎的结果。解决方案第一把额度测算逻辑完全搬到规则引擎模型只负责解释规则引擎给结果。第二在提示词里写死“quota_suggestion字段必须等于rule_engine.quota字段的数值任何情况下不得自行计算”。第三加了一层后置校验——编排层在拿到模型输出后做一个代码校验如果quota_suggestion和规则引擎的结果不一致判定为“生成失败”触发重试。预防措施凡是涉及金额、日期、账号这类精确数值的字段一律从工具和规则引擎取模型只做文案生成不做数学运算。5.3 敏感字段在日志里出现现象安全扫描时发现模型调用的 debug 日志里打印了完整的身份证号和银行卡号。根因插件在调试模式下把输入输出原样打日志开发人员图方便开了 debug 级别结果敏感信息裸奔了。解决方案第一关闭生产环境的 debug 日志统一调整为 info 级别。第二在平台侧配置日志脱敏规则对身份证号、手机号、银行卡号等字段做正则匹配脱敏。第三给所有插件加一层“日志安全过滤器”凡是被识别为敏感字段的内容一律替换成掩码再写日志。预防措施把“日志脱敏检查”列入发布 Checklist每次发布前用测试样本跑一遍人工检查日志输出。5.4 版本演进灰度发布与快速回滚我最早是“改完直接发布会”结果有一次把意图识别的阈值调错了导致部分进件被切到错误的业务分支发现问题时已经跑了半小时。那半小时里所有进件的处理结果都是错的只能回滚重来。后来我老老实实用了 AgentArts 的版本管理能力改了三个习惯第一是流程版本化。每次改动都生成一个新版本发布时先发到测试环境用历史数据跑回归。第二是灰度发布。生产环境保留旧版本作为基线新版本先切5%流量跑几天观察人工复核的通过率、工具调用成功率、平均耗时这几个指标都稳定了再逐步加流量。第三是快速回滚预案。一旦新版本核心指标恶化一键切回旧版本。这个“一键”不是嘴上说的——我在发布前会先在预发环境演练一遍回滚操作确保流程本身就是顺畅的。提示智能体的版本回滚不只是“改个代码”它牵涉到模型版本、知识库版本、插件版本、提示词版本四个维度。发布前一定要把四者的版本号绑在一起记录否则回滚之后配置对不上哭都来不及。6. 运维、迭代与放大从一个智能体到一套智能体单个信贷初审智能体跑通之后接下来要考虑的是怎么把它放进更大的体系里让它可持续运转、可复制扩张。6.1 指标监控别只看“准确率”金融场景做智能体评估不能只盯着模型准确率。我用的核心指标是这几项工具调用成功率、节点超时率、人工复核确认率、平均处理时长、回退率。准确率固然重要但工具调用成功率才是“智能体有没有在办事”的硬指标——如果反欺诈插件十次里有三次调不通模型再准也没用。人工复核确认率尤其关键。它反映的是模型输出和审核员判断的一致性。如果确认率低说明智能体的初审意见参考价值有限问题大概率出在提示词、知识库覆盖度或者工具数据质量上需要针对性优化。6.2 迭代节奏小步快跑但不要天天改在稳定运行的前提下我建议保持相对克制的迭代节奏。信贷场景的每一次改动都有真实业务影响所以我这边是每周一次小迭代、每月一次大版本。小迭代主要修知识库、调提示词、补规则大版本才动流程结构、插件逻辑、模型选型。固定节奏的好处是改了什么、什么时候改的、谁改的都能对应上出问题容易追溯。6.3 横向复制信贷初审之外还能做点什么AgentArts 的编排能力一旦跑熟你会发现同一套组件可以复用到很多相邻场景。我在信贷初审之外又搭了“贷后预警助手”——核心链路是把贷后监控规则、还款行为数据、司法涉诉查询接到一起定期输出预警名单。“智能客服助手”也顺势接了进来它复用反欺诈插件和知识库只是改了意图识别和话术模板。与其每个场景从零开发不如把工具层沉淀成统一的“信贷数据插件市场”哪个智能体需要哪个插件直接挂载进来。成本低、好维护、权限还可控这是我做了一段时间之后最推荐的玩法。最后再分享一点个人经验我做过不少AI项目最大的体会是智能体能不能在信贷场景里真正跑起来拼的不是模型有多聪明而是工程化有多扎实。聪明模型遍地都是但能把工具调用、流程编排、知识管理、权限合规、灰度发布这些事一件件事无巨细地落实到位才决定你能不能上线、敢不敢上线。踩过几次坑之后我现在接手任何金融智能体项目都会先问三个问题数据从哪来、规则怎么落、出错了谁来兜底。这三个问题想清楚了剩下的只是时间和耐心的事。
