金融信贷这个行当表面看是拼资金成本、拼渠道实际上真正拉开差距的是风控和审批效率。一笔信贷业务从进件到放款中间要过反欺诈、征信解析、额度测算、合规审查好几道关传统做法靠人工一条条核对一个客户经理一天能处理的单子就那么几十笔遇到资料不全或者流水复杂的光来回沟通就得耗掉大半天。华为云智果 AgentArts 这套东西就是冲着这个痛点来的——它把大模型能力、工作流编排和金融领域的知识库捏在一起让 AI 智能体去承担那些重复度高、规则明确但又需要一定理解能力的环节。我最近花了两周时间基于 AgentArts 搭了一套信贷审批辅助智能体从进件预审到风险提示再到合规话术生成跑通了一条完整的链路。这篇文章就把整个搭建过程、踩过的坑、以及一些参数调优的经验摊开来讲适合正在看金融 AI 智能体落地方向的同行也适合刚接触 AgentArts 想找个真实场景练手的开发者。1. 为什么金融信贷场景适合用 AI 智能体来改造1.1 信贷业务流程里的“三高”难题做信贷的人都知道这个行业有三个绕不开的高成本环节。第一是高重复客户提交的身份证、银行流水、收入证明、征信报告每一份都要人工录入和比对一个熟练的信贷员处理一套完整资料平均要 25 到 40 分钟其中 70% 的时间花在信息提取和交叉验证上。第二是高规则密度不同产品对应不同的准入规则比如公积金贷要求连续缴存 12 个月以上经营贷要求营业执照满两年且近半年流水覆盖月供两倍这些规则散落在各种制度文件里新人上手慢老人也容易记混。第三是高合规要求监管对信贷业务的留痕、话术、信息披露有明确规定一旦某个环节表述不当后续检查就是麻烦。这三个“高”叠加在一起导致信贷业务的人力成本居高不下而且服务质量严重依赖个人经验。AI 智能体的价值就在于它可以把规则理解、信息抽取、话术生成这些能力封装成可复用的模块让机器去干那些“需要动脑但不需要创造”的活。1.2 AgentArts 在信贷场景里的能力边界AgentArts 是华为云智果下面的一套智能体开发平台核心能力包括工作流编排、知识库挂载、工具调用和对话管理。放到信贷场景里它能做的事情其实很明确理解客户提交的非结构化材料、按照预设规则做初步判断、生成标准化的沟通话术、把结果结构化输出给下游系统。但它不能做的事情也要心里有数——最终审批决策、大额授信、异常案件的定性这些必须留给人。我个人的经验是把智能体定位成“信贷员的副驾驶”而不是“自动驾驶”落地阻力会小很多。副驾驶的意思是它帮你把仪表盘读好、把航线标出来、把异常提示出来但方向盘还在人手里。这个定位决定了你在设计工作流的时候哪些节点设成自动通过哪些节点必须设人工复核。1.3 选型对比为什么不用纯 Prompt 方案一开始我也试过直接用大模型的对话接口加一段长 Prompt 来处理信贷资料但很快就发现三个问题。第一是上下文长度不够稳定一份征信报告动辄几十页纯 Prompt 方案要么截断要么丢失关键信息。第二是规则更新麻烦每次产品政策调整都要改 Prompt改完还得重新测试版本管理一塌糊涂。第三是无法保证输出格式大模型有时候给你一段散文式的分析下游系统根本没法解析。AgentArts 的工作流模式正好解决这三个问题。工作流把任务拆成多个节点每个节点只负责一件事比如“提取征信报告中的逾期记录”就是一个独立节点它的输入输出格式是固定的。规则更新只需要改对应节点的配置不影响其他环节。而且工作流天然支持条件分支可以针对不同产品走不同的审批路径。2. 搭建信贷审批智能体的整体设计思路2.1 从进件到审批的链路拆解我把整个信贷审批辅助流程拆成了五个阶段每个阶段对应智能体里的一个或多个节点。第一阶段是进件预审客户提交基础资料后智能体先做完整性检查缺什么材料直接生成补件通知。第二阶段是信息抽取从身份证、流水、征信报告中提取关键字段比如月均收入、现有负债、逾期次数。第三阶段是规则匹配根据提取出来的字段去匹配产品准入规则输出“通过/拒绝/需人工”三种结果。第四阶段是风险提示对通过初步规则的单子再跑一遍反欺诈和异常检测逻辑比如短期内多头借贷、流水突然大额进出。第五阶段是话术生成根据审批结果生成给客户的沟通话术包括通过通知、补件通知、拒绝原因说明。这五个阶段里第一、二、五阶段可以完全自动化第三阶段建议自动出结果但保留人工复核入口第四阶段必须人工确认。这个分工是我试了好几版之后定下来的核心原则是涉及资金安全和合规定性的环节智能体只做提示不做决策。2.2 工作流节点的编排逻辑AgentArts 的工作流编排界面是拖拽式的但背后的逻辑要自己想清楚。我的做法是先把每个节点的输入输出定义好再连线。比如“信息抽取”节点的输入是原始文件路径输出是一个 JSON 对象包含monthly_income、existing_debt、overdue_count这些字段。这个 JSON 会作为下一个节点的输入。节点之间的连线有两种一种是顺序连线前一个节点完成自动触发下一个另一种是条件连线根据前一个节点的输出决定走哪条分支。信贷场景里条件连线用得很多比如规则匹配节点输出“拒绝”时直接跳到话术生成节点输出“需人工”时跳到人工复核队列节点。这里有个细节要注意条件连线的判断条件要尽量简单最好只判断一个字段的值。我见过有人在一个条件里写五六个 AND 条件结果调试的时候根本不知道是哪条没满足。我的做法是把复杂条件拆成多个节点每个节点只做一个判断这样出问题容易定位。2.3 知识库的挂载策略信贷业务的知识库分两类一类是制度规则库包括产品准入政策、监管要求、内部操作手册另一类是案例库包括历史审批案例、典型拒绝原因、常见问题解答。这两类知识库的挂载方式不一样。制度规则库适合用结构化切片的方式挂载把每一条规则切成独立的片段打上标签比如“公积金贷-准入-缴存月数”。这样智能体在检索的时候可以精确匹配到相关规则而不是把整本手册塞进上下文。案例库适合用语义检索的方式因为案例的描述方式千变万化靠关键词匹配效果不好用向量检索更合适。我在实际配置的时候发现知识库的切片粒度很关键。切得太细检索出来的片段缺乏上下文智能体理解不了切得太粗又会引入无关信息干扰判断。我的经验是每条规则切片控制在 200 到 400 字之间包含规则本身加上必要的解释和例外情况。这个粒度是我试了 150 字、300 字、500 字三个档位之后定下来的300 字左右的效果最稳。3. 核心节点的详细配置与实操要点3.1 信息抽取节点的字段定义与提示词设计信息抽取是整个链路的地基抽错了后面全错。我在这个节点上花了最多时间。首先是字段定义信贷场景需要抽取的字段大概有二十多个但我建议第一版只做核心字段比如月均收入、现有负债、逾期次数、工作年限、学历。字段太多会导致提示词过长模型注意力分散抽取准确率反而下降。提示词的设计有个技巧不要用“请提取以下信息”这种笼统的指令而是针对每个字段给出明确的定义和示例。比如“月均收入”这个字段我会写成“月均收入指客户近 6 个月银行流水中标注为‘工资’或‘代发’的入账金额的平均值不包括一次性奖金、报销款和转账收入。示例某客户近 6 个月工资入账分别为 12000、11800、12500、12000、12200、11900则月均收入为 12066 元。”这样模型就知道该怎么算不会把一次性收入也算进去。还有一个坑是日期格式。不同银行的流水日期格式不一样有的用“2024/01/15”有的用“2024-01-15”还有的用“15/01/2024”。我在提示词里明确要求模型统一输出为“YYYY-MM-DD”格式并且在抽取节点后面加了一个格式校验节点发现不符合格式的就打回重抽。这个校验节点看起来多余但实际上帮我省了很多下游解析的麻烦。3.2 规则匹配节点的条件配置与优先级规则匹配节点的核心是把抽取出来的字段和知识库里的规则做比对。AgentArts 支持两种匹配方式一种是精确匹配比如“逾期次数 3 则拒绝”另一种是语义匹配比如“客户所在行业属于限制类行业则需人工复核”。精确匹配用条件表达式配置语义匹配用知识库检索加模型判断。这里有个优先级的问题。一个客户可能同时触发多条规则比如既满足“逾期次数超标”又满足“收入不达标”这时候输出哪个拒绝原因我的做法是给每条规则设一个优先级合规类规则优先级最高其次是风险类规则最后是产品准入类规则。这样输出的拒绝原因永远是合规相关的避免给客户留下“你们就是嫌我收入低”的印象。条件表达式的写法也有讲究。AgentArts 用的是类 JSON 的表达式语法比如{field: overdue_count, operator: , value: 3}。我建议把常用的条件封装成规则模板比如“逾期次数超标”模板、“收入不达标”模板这样配置新规则的时候直接选模板改参数就行不用每次从头写。3.3 话术生成节点的语气控制与合规检查话术生成看起来简单实际上最容易出问题。信贷场景的话术有三个要求准确、合规、有温度。准确是指不能把拒绝原因说错合规是指不能承诺审批结果、不能泄露客户隐私有温度是指别让客户觉得你在冷冰冰地念条款。我在提示词里给模型设定了三个角色约束第一你是信贷机构的客服人员不是审批人员所以不能说“我批准了”或“我拒绝了”只能说“根据初步评估”或“需要进一步审核”。第二你不能透露具体的风控规则比如不能说“因为你逾期超过 3 次所以拒绝”只能说“根据综合评估目前暂不符合准入条件”。第三你要给客户明确的下一步指引比如“您可以补充近 3 个月的流水后重新提交”或“建议您联系客户经理了解详细原因”。话术生成之后我还加了一个合规检查节点用关键词过滤的方式扫一遍生成的话术如果出现“保证”“一定”“肯定”这类承诺性词汇或者出现客户身份证号、手机号等敏感信息就自动打回重生成。这个检查节点用简单的字符串匹配就能实现不需要模型参与速度快而且不会漏。4. 实操过程从零搭建一个可运行的信贷智能体4.1 环境准备与项目初始化在 AgentArts 上创建项目的第一步是选区域和规格。金融信贷场景对数据安全要求高我选的是国内区域并且开启了数据加密存储选项。规格方面如果只是做 POC 验证基础版就够了如果要跑真实业务量建议选专业版因为专业版支持更高的并发和更长的上下文窗口。项目初始化的时候要配置三个东西模型选择、知识库连接、工具权限。模型我选的是平台内置的金融行业微调模型它在信贷术语的理解上比通用模型准不少。知识库连接需要提前把制度文件和案例整理成平台支持的格式我一般用 Markdown 或者纯文本表格类的用 CSV。工具权限这块如果智能体需要调用外部系统查征信或者发短信要在这里配置 API 密钥和访问白名单。注意金融场景千万不要用默认的公开模型一定要选行业微调版本或者自己上传微调数据。通用模型在理解“连三累六”“多头借贷”这些行话的时候准确率会明显下降。4.2 工作流搭建的完整步骤工作流搭建我分成了六步走。第一步是创建空白工作流命名规则建议用“业务场景-版本号”比如“信贷审批辅助-v1.2”方便后续迭代管理。第二步是添加开始节点定义输入参数我定义了三个输入applicant_id申请人编号、document_paths资料文件路径列表、product_code产品代码。第三步是添加信息抽取节点把开始节点的document_paths作为输入输出结构化字段。这个节点要配置提示词和输出格式输出格式我定义了一个 JSON Schema包含所有需要抽取的字段和类型。第四步是添加规则匹配节点输入是信息抽取节点的输出输出是匹配结果和拒绝原因。这个节点要挂载制度规则知识库并且配置条件表达式。第五步是添加风险提示节点这个节点比较特殊它需要调用一个外部反欺诈 API所以要在工具权限里提前配好。第六步是添加话术生成节点和结束节点话术生成节点的输入是规则匹配结果和风险提示结果输出是最终话术结束节点把话术和结构化结果一起返回。整个工作流搭下来大概有八个节点连线逻辑是开始 → 信息抽取 → 规则匹配 →条件分支→ 风险提示 → 话术生成 → 结束。条件分支那里如果规则匹配结果是“拒绝”直接跳到话术生成如果是“通过”或“需人工”走风险提示节点。4.3 关键参数的计算与选择过程有几个参数是我反复调过的这里把计算过程写出来供参考。第一个是信息抽取的置信度阈值。AgentArts 的抽取节点会返回每个字段的置信度分数我一开始设的是 0.8结果发现很多正常单子因为某个字段置信度 0.75 就被打回了。后来我把阈值降到 0.65同时加了一个规则如果置信度在 0.65 到 0.8 之间标记为“需人工确认”而不是直接打回。这样既保证了准确率又减少了不必要的打回。第二个是知识库检索的 Top-K 值。这个值决定了每次检索返回多少个片段。设得太小可能漏掉关键规则设得太大会引入无关信息。我试了 3、5、8 三个值最后定在 5。因为信贷规则通常比较集中一个判断点相关的规则片段不会超过 5 个超过的基本都是噪音。第三个是话术生成的温度参数。温度越高生成的话术越多样但越不可控温度越低话术越稳定但越死板。信贷场景我建议设在 0.3 到 0.5 之间我最后用的是 0.4。这个温度下的话术既不会千篇一律也不会跑偏。参数名称初始值调整后值调整原因抽取置信度阈值0.80.65减少正常单子被打回知识库 Top-K35避免漏掉关键规则话术温度0.70.4保证话术稳定合规工作流超时时间30s60s征信报告解析耗时较长4.4 联调测试与效果验证联调阶段我准备了 50 条测试数据覆盖了通过、拒绝、需人工三种结果以及资料缺失、格式异常、多头借贷等边界情况。测试的时候发现两个问题。第一个是征信报告解析超时一份 40 页的征信报告解析要 45 秒左右超过了默认的 30 秒超时限制。解决办法是把工作流超时时间调到 60 秒同时把征信解析拆成两个节点先解析基本信息再解析信贷记录这样每个节点的耗时都控制在 30 秒以内。第二个问题是规则匹配的误判。有一条测试数据是客户有 2 次逾期但都是 3 年前的按照规则“近 2 年逾期次数 1 则拒绝”这条应该通过。但智能体把 3 年前的逾期也算进去了。排查发现是信息抽取节点没有正确提取逾期时间只提取了逾期次数。后来我在抽取字段里加了overdue_dates字段并且在规则匹配节点里加了时间范围过滤条件问题解决。最终 50 条测试数据里智能体判断结果和人工判断一致的有 46 条一致率 92%。不一致的 4 条都是“需人工”被智能体判成了“通过”或“拒绝”属于边界情况后续通过调整规则优先级和增加人工复核节点可以解决。5. 常见问题与排查技巧实录5.1 信息抽取不准的排查思路信息抽取不准是最常见的问题表现是字段值错误或者字段缺失。排查的时候按这个顺序来先看原始文件质量再看提示词最后看模型选择。原始文件质量包括扫描件是否清晰、PDF 是否加密、表格是否错位。我遇到过一份流水 PDF 是图片格式的OCR 识别出来全是乱码这种只能让客户重新提交。提示词的问题通常是描述不够具体。比如“提取收入信息”这种指令太模糊模型不知道你要的是税前还是税后、月均还是年均。改成“提取近 6 个月银行流水中标注为工资的入账金额计算月均值”就明确多了。模型选择的问题前面提过金融场景一定要用行业微调模型。实操心得在信息抽取节点后面加一个“字段完整性检查”节点检查所有必填字段是否都有值。如果有缺失不要直接打回而是生成一个补件通知告诉客户缺什么材料。这样用户体验比直接拒绝好很多。5.2 规则匹配冲突的处理方法规则冲突是指同一个客户同时满足多条规则但规则之间结论矛盾。比如一条规则说“收入 8000 则通过”另一条说“负债率 50% 则拒绝”客户收入 9000 但负债率 55%两条规则都满足。这时候怎么办我的处理方法是设优先级 设互斥标记。优先级前面说过了合规类 风险类 准入类。互斥标记是指给每条规则打一个标签比如“收入类”“负债类”“合规类”当同一类规则出现冲突时取最严格的那条。比如收入类规则有两条一条通过一条拒绝那就取拒绝。这个逻辑可以在规则匹配节点后面加一个“冲突消解”节点来实现用简单的条件判断就行。5.3 话术生成不合规的修正技巧话术不合规的表现有三种承诺审批结果、泄露风控规则、语气不当。承诺审批结果的话术比如“您这笔贷款肯定能批下来”泄露风控规则的比如“因为您逾期 3 次所以拒绝”语气不当的比如“您这条件太差了”。这三种问题都可以通过提示词约束来解决但提示词不是万能的还需要加一个合规检查节点做兜底。合规检查节点的实现方式我用了两种关键词黑名单和正则表达式。关键词黑名单包括“保证”“一定”“肯定”“绝对”“没问题”这些承诺性词汇以及“逾期”“负债”“征信”这些可能泄露风控规则的词汇。正则表达式用来匹配身份证号、手机号、银行卡号等敏感信息。检查到违规就自动打回重生成重生成两次还不合规就转人工处理。问题类型表现解决方法承诺审批结果“肯定能批”提示词约束 关键词黑名单泄露风控规则“因为逾期 3 次”提示词约束 关键词黑名单语气不当“条件太差”提示词约束 人工抽检敏感信息泄露出现身份证号正则表达式过滤5.4 性能优化的几个实用技巧智能体跑起来之后性能是绕不开的问题。我总结了几个优化技巧。第一是并行化信息抽取节点里如果有多个文件要处理比如身份证、流水、征信报告可以并行抽取不用串行。AgentArts 支持节点内的并行执行配置一下就行。第二是缓存同一个客户的资料如果多次查询可以把抽取结果缓存起来避免重复计算。第三是异步处理对于耗时长的节点比如征信解析可以设成异步先返回一个任务 ID处理完了再回调。第四是精简知识库知识库越大检索越慢我定期清理过期的规则和案例把不再使用的产品规则归档。第五是控制上下文长度每个节点的输入不要塞太多无关信息只传必要的字段。我见过有人把整个客户资料包传给每个节点结果上下文爆了工作流直接卡死。6. 智能体上线后的运营与迭代6.1 效果监控指标的设定智能体上线不是终点而是起点。我设了四个监控指标抽取准确率、规则匹配一致率、话术合规率、人工复核率。抽取准确率每周抽检 100 条人工核对字段值低于 90% 就要排查。规则匹配一致率是智能体判断结果和人工判断结果的一致比例低于 85% 就要检查规则配置。话术合规率是合规检查节点打回的比例高于 10% 说明提示词需要优化。人工复核率是转到人工处理的单子占比这个指标反映智能体的自动化程度我的目标是控制在 20% 以内。6.2 规则库的持续更新机制信贷产品的规则变化很频繁今天这个产品降息了明天那个产品提高准入门槛了。如果每次规则变化都要改工作流那运维成本太高。我的做法是把规则配置外置化规则不写在节点里而是放在一个独立的规则表里节点运行时去规则表读取。规则表用 CSV 或者数据库都行我用的是一张简单的 CSV 表包含规则 ID、规则描述、条件表达式、优先级、生效日期。每次规则变化只需要更新 CSV不用动工作流。这个外置化设计还有一个好处是可以回滚。如果新规则上线后发现有问题把 CSV 恢复到上一个版本就行不用重新部署工作流。6.3 从辅助审批到智能协作的演进方向目前这套智能体做的是辅助审批就是帮信贷员做初步筛选和资料整理。下一步我想往智能协作方向走让智能体不只是被动响应而是主动提示。比如客户提交资料后智能体不仅做预审还能根据客户画像推荐合适的产品或者提示信贷员“这个客户最近有多头借贷迹象建议重点关注”。再远一点可以做成多智能体协作的模式。一个智能体负责资料审核一个负责风险评估一个负责话术沟通它们之间通过消息传递来协作。这个模式在技术上已经可行AgentArts 支持多智能体编排但业务上还需要验证因为多智能体协作的调试复杂度比单智能体高不少。我在实际使用中发现智能体在信贷场景的落地技术只占三成七成是业务理解和流程梳理。你得先想清楚哪些环节可以交给机器哪些必须留给人然后再去搭工作流。如果一上来就想着全自动化大概率会踩坑。另外知识库的质量直接决定智能体的上限垃圾进垃圾出这句话在智能体时代依然成立。最后分享一个小技巧每次调整工作流之后一定要用同一批测试数据跑一遍回归测试确保改动没有引入新的问题。我吃过这个亏改了一个节点的提示词结果另一个节点的输出格式变了下游解析全挂。
