1. 金融信贷场景下智能体方案的整体设计思路1.1 为什么金融信贷是智能体落地的天然试验场金融信贷业务有一个非常鲜明的特征流程长、节点多、规则密集、合规要求高同时每一个环节都涉及大量的信息判断和决策。从贷前获客、身份核验、反欺诈筛查到贷中额度评估、利率定价、合同签署再到贷后监控、逾期提醒、催收策略整条链路上有大量重复性高但又需要一定判断力的工作。传统做法要么靠人工逐单审核效率低、成本高要么靠固定规则引擎遇到复杂情况就失灵。智能体的价值恰好卡在这个缝隙里。它不像传统规则引擎那样只能做“如果A则B”的硬判断也不像纯大模型那样只会聊天、无法对接业务系统。智能体可以理解自然语言、调用外部工具、按预设流程执行多步操作还能在关键节点引入人工确认。说白了它像一个不知疲倦的初级信贷助理能处理80%的标准化工作把剩下20%的疑难杂症交给人类专家。华为云AgentArts这个平台本质上就是给开发者提供了一套搭建这类智能体的工具箱。它把大模型能力、工作流编排、工具调用、知识库检索、权限管控这些模块打包在一起让开发者不用从零造轮子而是把精力放在业务逻辑上。金融信贷场景下这套东西能做的事情包括但不限于自动解析客户提交的申请材料、交叉比对多方数据源、生成风险评估摘要、触发人工复核工单、自动生成合规话术等。1.2 方案选型的核心考量为什么是AgentArts而不是其他市面上做智能体的平台不少有偏C端对话的有偏RPA流程自动化的也有偏纯模型微调的。金融信贷场景对平台的要求比较特殊我总结下来主要是四条第一数据不能出域。信贷数据涉及大量个人敏感信息监管对数据存储和传输有明确要求。AgentArts支持私有化部署和VPC内网隔离模型调用和知识库检索都在企业自己的网络环境里完成这一点是硬门槛。第二流程必须可审计。信贷业务每一步操作都要留痕出了问题要能回溯。AgentArts的工作流编排支持节点级别的日志记录每个工具调用的入参、出参、耗时、状态都能查到满足审计要求。第三工具调用要灵活。信贷系统里有很多存量接口比如征信查询、黑名单校验、额度计算引擎这些不可能推倒重来。AgentArts支持通过API插件的方式接入外部服务把存量能力包装成智能体可调用的工具改造成本低。第四人工兜底要顺畅。智能体再聪明也不能完全替代人做信贷决策尤其是大额授信。AgentArts支持在流程中插入人工审核节点智能体处理完前置步骤后自动生成待办任务人工在后台确认后流程继续往下走。基于这四点我最终选择了AgentArts作为搭建平台。不是说其他平台不能用而是在金融信贷这个特定场景下AgentArts在数据安全、流程审计、工具集成、人机协同这四个维度的匹配度最高。1.3 整体架构分层与数据流向整个智能体方案我把它拆成四层从下往上分别是基础设施层华为云ECS承载AgentArts运行时RDS存业务数据OBS存非结构化文件比如客户上传的身份证照片、收入证明扫描件Redis做会话缓存。所有资源都在同一个VPC内安全组只开放必要的内网端口。能力层AgentArts平台本身包含大模型推理服务、工作流引擎、知识库、插件管理、权限中心。大模型我选的是华为云盘古系列主要考虑是中文理解能力强而且和AgentArts原生集成调用延迟低。业务逻辑层这是开发者主要写代码的地方。我把信贷流程拆成若干个子智能体比如“材料解析智能体”负责提取申请材料关键字段“反欺诈智能体”负责多头借贷和黑名单筛查“额度试算智能体”负责调用内部定价引擎“合规审查智能体”负责检查话术和流程是否符合监管要求。每个子智能体独立编排通过主控智能体串联。交互层面向客户的是移动端H5和小程序面向信贷经理的是PC端工作台面向风控人员的是审核后台。不同角色看到的界面不同但底层调用的都是同一套智能体服务。数据流向是这样的客户在移动端提交申请→文件上传到OBS→主控智能体触发材料解析→解析结果写入RDS→反欺诈智能体读取RDS数据并调用外部征信接口→结果回写→额度试算智能体调用定价引擎→生成预授信结果→合规审查智能体做最后检查→如果需要人工复核则生成工单→信贷经理在工作台处理→最终结果推送给客户。整个链路里智能体负责的是信息流转和初步判断人类负责的是最终决策和异常处理。这个分工模式在实际跑下来之后效率提升非常明显。2. 核心细节解析与实操要点2.1 材料解析智能体的字段提取与校验逻辑材料解析是整个流程的第一步也是最容易出问题的一步。客户上传的材料五花八门有拍照的、有扫描的、有PDF的、有Word的清晰度和格式都不统一。如果第一步提取错了后面全错。我的做法是分三步走第一步文件预处理。所有上传的文件先统一转成PDF格式图片类的做一次锐化和去噪处理。这一步用Python的Pillow和pdf2image库就能搞定代码不复杂但效果很明显。实测下来预处理之后OCR的识别准确率能提升15%左右。第二步OCR识别与字段定位。调用华为云OCR服务做文字识别然后根据材料类型身份证、收入证明、银行流水、征信报告用不同的规则做字段定位。这里有个技巧不要指望OCR一次就能把所有字段都识别对而是要把识别结果和置信度一起返回。置信度低于阈值的字段标记为“待人工确认”不要强行往下走。第三步交叉校验。比如身份证上的姓名和收入证明上的姓名要一致银行流水里的月均收入和收入证明上的数字要能对上。交叉校验不通过的直接触发人工复核工单不要试图让智能体去“猜”。这里踩过一个坑最开始我让智能体自动修正OCR的识别错误比如把“0”和“O”混淆的自动替换。结果发现有些客户的姓名里确实有“O”这个字母自动替换反而改错了。后来改成只标记不修改把判断权交给人工准确率反而上去了。2.2 反欺诈智能体的规则引擎与模型打分融合反欺诈是信贷风控的核心环节也是最需要“智能”的地方。纯规则引擎容易被绕过纯模型打分又缺乏可解释性。我的方案是规则和模型各跑各的最后做融合决策。规则部分我配置了大概三十条硬规则比如申请人年龄不在22到60岁之间直接拒绝手机号实名认证时间少于6个月直接拒绝近3个月贷款审批查询次数超过8次进入人工复核当前有逾期未结清的贷款进入人工复核。这些规则在AgentArts里用条件分支节点实现每条规则独立配置方便后续调整。模型部分我调用的是内部训练好的XGBoost反欺诈模型输入特征包括申请人的基本信息、征信特征、行为特征等。模型输出一个0到1之间的欺诈概率分数。这个分数不直接做拒绝决策而是作为一个权重因子参与最终判断。融合逻辑是这样的如果硬规则命中拒绝项直接拒绝不看模型分数如果硬规则命中复核项模型分数低于0.3则自动通过高于0.7则自动拒绝中间区间转人工如果硬规则全部通过模型分数高于0.8则转人工复核否则自动通过。这套逻辑跑下来自动审批率大概在65%左右剩下的35%转人工。人工复核的准确率比之前纯人工审批时高了因为智能体已经把明显有问题的单子过滤掉了人工只需要处理边界案例。2.3 额度试算智能体的参数传递与异常处理额度试算需要调用内部的定价引擎这个引擎是一个老系统接口是SOAP协议的返回的是XML格式。AgentArts的插件默认支持RESTful API对接SOAP需要做一层转换。我的做法是写一个适配器服务部署在ECS上对外暴露RESTful接口内部把请求转成SOAP调用定价引擎再把XML响应解析成JSON返回给智能体。适配器用Python的zeep库实现大概两百行代码。参数传递方面有几个关键点客户基本信息年龄、职业、收入从材料解析结果里取取不到的时候要有默认值兜底不能让流程卡住。征信特征负债率、查询次数、逾期记录从反欺诈智能体的输出里取这些字段的命名要和定价引擎的入参严格对应不能有歧义。产品参数贷款期限、还款方式、利率浮动范围从产品配置表里读不同产品走不同的定价逻辑。异常处理是重点。定价引擎有时候会超时有时候会返回业务错误码。我的策略是超时重试两次两次都失败则降级到备用定价规则用简单的利率表查表同时记录告警日志。业务错误码则根据错误类型分别处理比如“客户年龄不符合产品要求”就直接返回拒绝“收入证明不足”则转人工补充材料。2.4 合规审查智能体的话术检查与流程校验合规审查这一环在金融信贷里绝对不能省。监管对信贷业务的营销话术、合同条款、催收行为都有明确规定一旦违规处罚很重。智能体在这里的作用是做一个自动化的“合规检查员”。话术检查方面我建了一个违规词库包含监管明令禁止的表述比如“保证放款”“无视征信”“百分百通过”等。智能体在生成给客户的回复之前先过一遍违规词库命中则拦截并替换成合规话术。同时用大模型做语义层面的检查防止有些违规表述换了个说法但意思没变。流程校验方面我配置了一套检查清单比如是否在放款前完成了所有必要的授权书签署是否向客户明确展示了年化利率是否给了客户足够的冷静期。智能体在每个流程节点完成后自动检查对应项未完成的则阻断流程并提示。这里有个经验合规规则不是一成不变的监管政策调整时规则也要跟着改。所以我把合规规则做成了可配置的存在数据库里运营人员可以在后台修改不需要改代码重新部署。这个设计后来被证明非常实用半年内改了三次规则每次都是运营自己搞定的。3. 实操过程与核心环节实现3.1 环境准备与AgentArts基础配置开始搭建之前先把基础环境准备好。我列一下具体的步骤和配置华为云资源开通在华为云控制台开通ECS规格选4核8G操作系统用Ubuntu 22.04、RDS for MySQL主备版8核16G、OBS标准存储开启服务端加密、Redis主从版4G内存。所有资源放在同一个VPC下子网划分成应用子网和数据子网安全组只允许应用子网访问数据子网的特定端口。AgentArts工作空间创建登录AgentArts控制台创建一个新的工作空间命名为“金融信贷智能体”。在工作空间里创建三个环境开发环境、测试环境、生产环境。开发环境用于日常调试测试环境用于UAT验证生产环境对外提供服务。三个环境的配置完全隔离避免开发时的改动影响线上。大模型服务接入在AgentArts的模型管理里添加盘古大模型配置API Key和Endpoint。我选的是盘古NLP大模型参数规模选的是中等规模因为信贷场景对响应延迟比较敏感太大的模型推理慢太小的模型理解能力不够。实测下来中等规模在准确率和延迟之间平衡得最好。知识库初始化把信贷产品的说明书、费率表、常见问题、监管文件等文档上传到知识库。AgentArts支持PDF、Word、TXT等格式上传后自动做向量化处理。这里有个细节文档要提前做好分段每段不要太长否则检索出来的结果不够精准。我的经验是每段控制在300到500字之间按语义自然分段。3.2 工作流编排从申请提交到预授信生成工作流是整个智能体的骨架我用AgentArts的可视化编排器来搭建。整个流程大概有二十多个节点我挑几个关键节点说明。入口节点接收客户提交的申请数据包括基本信息表单和上传的文件。入口节点做一次基础校验比如必填项是否为空、文件格式是否支持、文件大小是否超限。校验不通过直接返回错误提示不进入后续流程。并行分支节点材料解析和反欺诈筛查可以并行执行因为两者之间没有数据依赖。并行执行能节省大概40%的总耗时。AgentArts支持并行分支配置的时候注意设置超时时间避免某个分支卡住导致整个流程挂起。条件判断节点根据反欺诈结果决定走哪条路。如果命中硬规则拒绝直接跳到拒绝节点如果命中复核规则跳到人工复核节点如果全部通过继续往下走额度试算。人工审核节点这个节点会生成一个待办任务推送到信贷经理的工作台。任务里包含智能体整理好的客户信息摘要、风险提示、建议额度。信贷经理可以选择通过、拒绝或退回补充材料。人工处理完成后流程继续往下走。结果输出节点把最终结果组装成标准格式推送给客户和内部系统。结果里包含授信额度、利率、期限、还款方式、下一步操作指引。整个工作流编排完之后一定要在测试环境跑一遍全流程用真实的测试数据验证每个节点的输入输出是否符合预期。我遇到过因为字段命名不一致导致数据传递失败的情况在测试环境跑的时候才发现如果直接上生产就出事故了。3.3 插件开发对接征信查询与定价引擎AgentArts的插件机制是它比较灵活的地方。插件本质上就是一个API封装把外部服务的调用细节隐藏起来暴露给智能体的是一个简单的函数签名。征信查询插件征信查询接口是HTTP的返回JSON。插件配置里定义好请求方法、URL、请求头、请求体模板。请求体里的参数用占位符表示智能体调用的时候传入实际值。响应结果里我提取了十几个关键字段比如查询次数、逾期记录、负债总额、担保信息等映射成智能体可读的变量。定价引擎插件前面说过定价引擎是SOAP的我写了一个适配器做转换。适配器部署在ECS上用Nginx做反向代理配置了限流和熔断。插件里配置的是适配器的RESTful地址智能体不需要知道底层是SOAP。插件调试技巧AgentArts提供了插件调试功能可以模拟调用并查看请求和响应的完整内容。我建议每个插件上线前都要在调试工具里跑通至少十条测试用例覆盖正常情况、边界情况和异常情况。特别是异常情况比如接口超时、返回空数据、返回错误码这些在生产环境一定会遇到提前处理好过事后救火。3.4 提示词工程让大模型输出稳定可靠的信贷判断提示词写得好不好直接决定智能体的输出质量。信贷场景对输出的稳定性和准确性要求极高不能今天一个说法明天一个说法。我的提示词结构是这样的角色定义明确告诉模型它是一个金融信贷助理职责是协助信贷经理处理贷款申请所有输出必须基于事实和数据不能编造。任务描述具体说明当前要完成什么任务比如“根据以下客户信息和征信数据生成一份风险评估摘要”。输入数据把结构化的数据以JSON格式传给模型字段名用英文值用中文。这样模型理解起来更准确。输出格式严格定义输出的JSON结构包括哪些字段、每个字段的类型和取值范围。比如风险等级只能是“低”“中”“高”三个值之一。约束条件列出模型不能做的事情比如不能给出具体的授信额度建议那是定价引擎的事不能使用绝对化表述不能泄露其他客户的信息。示例给一两个输入输出的示例让模型照着格式来。示例不用多一两个就够多了反而占token。这套提示词模板我迭代了大概十几版每版都在测试集上跑一遍看输出的准确率和一致性。最终定下来的版本在五百条测试样本上的字段提取准确率是96.7%风险等级判断准确率是91.2%。这个水平已经可以支撑自动审批了剩下的误差由人工复核兜底。4. 常见问题与排查技巧实录4.1 智能体响应超时与性能优化智能体上线初期遇到最多的问题就是响应超时。客户在移动端点了提交等了十几秒还没反应体验很差。排查下来主要有几个原因大模型推理慢盘古大模型在默认配置下单次推理大概需要2到3秒。如果工作流里有多个节点都调用大模型累加起来就超时了。优化方法是把能合并的模型调用合并比如材料解析和风险评估可以用一次模型调用完成不要拆成两次。另外可以调整模型的max_tokens参数输出越短推理越快。外部接口慢征信查询接口在高峰期响应时间会从200毫秒涨到2秒以上。优化方法是加缓存同一个客户短时间内重复查询直接读缓存。缓存有效期设的是24小时因为征信数据一天内变化不大。工作流节点过多最开始我把所有逻辑都放在一个工作流里三十多个节点串行执行总耗时自然长。后来拆成主工作流和子工作流子工作流可以并行执行总耗时降到了原来的三分之一。优化之后端到端的平均响应时间从12秒降到了4秒左右P99从25秒降到了8秒。这个水平客户基本感知不到等待。4.2 数据不一致与字段映射错误排查数据不一致是另一个高频问题。表现是智能体输出的结果和预期不符比如明明客户收入填的是月入两万风险评估里却显示月入五千。排查这类问题我的方法是沿着数据流向往回查。先看智能体的输出确认是哪个字段错了然后看这个字段是从哪个节点传过来的再看那个节点的输入是什么一直追溯到数据源头。AgentArts的日志功能可以查到每个节点的输入输出排查起来比较方便。常见的字段映射错误有几种一是字段名拼写错误比如“monthly_income”写成了“month_income”二是数据类型不匹配比如把字符串“20000”当数字用计算结果就错了三是单位不统一有的地方用元有的地方用万元。这些低级错误听起来可笑但在实际开发中非常常见尤其是多人协作的时候。我的预防措施是建一个字段字典所有字段的名称、类型、单位、取值范围都在字典里定义好开发的时候统一从字典里引用不要手写。这个习惯养成之后字段映射错误减少了90%以上。4.3 人工复核工单流转异常处理人工复核节点涉及智能体和人工的交互出问题的概率比纯自动流程高。我遇到过几种典型情况工单生成失败智能体判断需要人工复核但工单没有推送到工作台。排查发现是工单服务的接口超时了智能体没有做重试。后来在插件里加了重试逻辑超时后重试三次仍然失败则记录到死信队列由定时任务补偿。工单状态不同步信贷经理在工作台处理了工单但智能体这边没收到通知流程一直挂着。原因是工单服务的回调地址配置错了回调打到了测试环境。修正之后正常了。这个问题的教训是环境切换的时候一定要检查所有回调地址和接口地址。重复工单同一个申请生成了多个工单信贷经理处理了其中一个另外几个还挂着。原因是智能体在判断是否需要人工复核时条件写得不严谨在某些边界情况下会重复触发。后来把条件改成幂等判断同一个申请ID在工单未关闭前不再生成新工单。4.4 常见问题速查表问题现象可能原因排查方法解决方案智能体响应超时模型推理慢/接口慢/节点过多查看各节点耗时日志合并模型调用、加缓存、拆分子工作流输出字段值错误字段映射错误/类型不匹配沿数据流向往回追溯建立字段字典、统一引用工单未生成接口超时/回调地址错误检查工单服务日志和回调配置加重试逻辑、修正回调地址重复工单条件判断不严谨检查触发条件逻辑改为幂等判断OCR识别率低图片质量差/预处理不足查看原始图片和预处理结果加强预处理、设置置信度阈值模型输出不稳定提示词不够明确对比多次输出的差异优化提示词、增加输出格式约束知识库检索不准文档分段不合理查看检索结果和原文对比调整分段策略、优化向量化模型4.5 几个踩坑之后才明白的经验第一个经验不要追求全自动。最开始我想让智能体把所有环节都自动化结果发现有些边界情况处理不了反而增加了风险。后来在关键节点都保留了人工兜底智能体做初步筛选和整理人做最终决策。这个模式跑下来效率提升明显风险也可控。第二个经验日志要打全。智能体的每个决策、每次工具调用、每个字段的取值都要记日志。出问题的时候日志是唯一的排查依据。我见过有的团队日志打得太少出了问题只能靠猜排查效率极低。第三个经验测试数据要真实。用假数据测试和用真实数据测试结果可能完全不同。真实数据里有各种脏数据、边界值、异常格式这些在假数据里是模拟不出来的。我建议在测试环境用脱敏后的真实数据做验证上线前的最后一轮测试尤其要这样。第四个经验版本管理要严格。智能体的提示词、工作流配置、插件参数每次改动都要记录版本并且要能回滚。我遇到过改了一版提示词之后效果变差想回滚却发现没存旧版本只能凭记忆重写。后来用了Git管理所有配置文件每次改动都提交问题就解决了。第五个经验和业务方保持同步。智能体的规则和话术最终是业务方在用他们的反馈最重要。我每周会和信贷团队开一次短会收集使用中的问题和建议然后排优先级迭代。这个习惯让智能体的实用性和业务贴合度一直保持得不错。5. 效果评估与后续扩展方向5.1 上线后的关键指标变化智能体上线运行三个月后我拉了一组对比数据。自动审批率从0提升到了65%意味着三分之二的申请不需要人工介入就能完成初步审批。单笔申请的平均处理时间从原来的45分钟纯人工降到了8分钟智能体处理加人工复核。人力成本方面原来需要8个信贷经理处理的单量现在3个人就能搞定而且处理质量更稳定因为智能体不会因为疲劳或情绪影响判断。风险指标方面反欺诈的拦截率比纯人工时期提升了12个百分点主要原因是智能体可以7×24小时不间断地交叉比对多个数据源而人工在高峰期容易漏掉一些细节。合规检查的违规率降到了接近零因为智能体的违规词库和流程校验是硬性的不会因为疏忽而跳过。客户体验方面申请提交后的等待时间从平均2小时缩短到了15分钟以内客户满意度评分提升了18%。这个提升主要来自响应速度的改善客户不需要再等半天才知道初审结果。5.2 从单场景到多场景的复制思路金融信贷智能体跑通之后这套模式可以复制到其他场景。我的思路是抽象出通用的能力模块然后针对不同场景做适配。通用的能力模块包括材料解析、规则引擎、模型打分、人工复核、合规检查、结果输出。这些模块在信贷场景里验证过逻辑是通用的。适配新场景的时候主要改的是规则配置、模型选择、话术模板和输出格式。比如消费金融场景和信贷场景高度相似只需要调整额度范围和期限选项规则引擎里的参数改一下就能用。供应链金融场景稍微复杂一些需要增加对贸易背景真实性的核查但核心的材料解析和反欺诈模块可以直接复用。保险理赔场景也有类似之处材料解析和合规检查的模块可以复用但风险评估的逻辑需要重新设计。我的建议是不要一开始就想着做大而全的平台而是先把一个场景做深做透把通用能力沉淀下来然后再往其他场景扩展。这样每一步都有实际业务验证风险可控。5.3 模型迭代与规则优化的持续运营智能体不是上线就完事了后续的持续运营才是关键。我建立了一套迭代机制数据回流智能体每次处理的申请包括输入数据、中间结果、最终决策、人工复核意见都回流到数据仓库。这些数据是优化模型和规则的原材料。效果监控每天自动跑一次效果报表看自动审批率、人工复核率、拒绝率、通过率这些指标有没有异常波动。如果某个指标突然变化超过阈值触发告警人工介入排查。规则调优每两周review一次规则命中情况看哪些规则从来没命中过可能是冗余的哪些规则命中率过高可能是阈值设得太松哪些规则被人工频繁推翻可能是规则本身有问题。根据review结果调整规则参数。模型重训每季度用回流数据重新训练一次反欺诈模型保持模型对最新欺诈手法的识别能力。重训之前会做A/B测试新模型在测试集上的表现超过旧模型才会上线。话术更新每月更新一次话术模板和违规词库跟进监管政策的变化和客户反馈。这个工作由运营团队负责不需要开发介入。这套机制跑下来智能体的效果不是一成不变的而是持续在优化。我个人的体会是智能体项目的成败三分靠搭建七分靠运营。搭建的时候把基础打好运营的时候持续打磨才能让智能体真正产生业务价值。最后分享一个小心得智能体的提示词里一定要加一句“如果信息不足请明确说明需要补充什么信息不要猜测”。这句话看起来简单但能避免很多模型“一本正经胡说八道”的情况。在信贷场景里宁可让智能体说“我不确定”也不能让它编一个看起来合理但实际错误的结果。这个原则贯穿了我整个项目的设计和运营。