1. 先聊清楚金融信贷场景为什么需要 AI 智能体1.1 传统信贷业务流程里的“自动化断层”做金融科技的同行应该都有同感信贷业务的前端咨询和材料审核长期以来是个“吃力不讨好”的环节。银行或助贷平台的客服要面对大量重复问题——利率多少、额度怎么算、需要准备什么材料、征信花了能不能贷风控初审人员又要一遍遍核对身份证、收入证明、流水截图、征信报告。这两类工作听起来简单实际却非常依赖上下文理解、材料识别、规则判断和多轮沟通能力。传统的规则引擎和 RPA 只能解决“条件完全匹配”的任务遇到用户一句“我这种情况还能申请吗”基本就卡住了。我这次拿华为云智果 AgentArts 做金融信贷智能体实战主要就是想把这个断层补上。AgentArts 是华为云上用来编排、运行和运维 AI 智能体的平台核心思路是把大模型的对话理解能力、任务规划能力和金融业务系统里的插件、规则、知识库串起来让机器不仅能“回答问题”还能“想清楚步骤、调系统、拿数据、再给结论”。1.2 AI 智能体到底和普通客服机器人差在哪很多人会把智能体和聊天机器人搞混。普通机器人是“检索式”或者“意图匹配式”的用户说“利率多少”机器人匹配到FAQ返回一段话术。它没有状态不会根据上下文做推理更不会自己去调用信贷系统的查询接口。智能体则更像一个熟悉业务流程的信贷经理助理你告诉它“我想贷20万装修但我公积金只交了半年”它知道你当前条件可能不符合某个产品接着会追问你是否有代发工资、是否本地有房然后决定下一步是引导你补充材料还是直接生成预审结论并转人工。这里面的关键在于“行动”。AgentArts 让智能体具备了调用工具和编排任务的能力。我这次搭建的信贷智能体能够在一个会话里完成身份核验 → 基础信息收集 → 调用反欺诈和征信查询接口 → 结合知识库判断 → 输出预审意见。整个过程用户感知上是一段连续对话而背后实际上跑了好几个系统调用和规则分支。1.3 为什么我选 AgentArts 而不是自己从零拼一套我做这个项目之前也犹豫要不要直接用 LangChain 或者自研框架自己接模型、自己做工具调用、自己管理知识库。后面对比下来放弃了。金融场景最麻烦的不是模型而是可用性、权限、审计、合规。自研一套智能体底座至少要搞定模型网关切换、会话记忆、插件协议、知识库切片、人工审核流程、操作日志留痕这些工作量非常大而且很难在短期内做到企业级稳定。AgentArts 提供的是一套完整的智能体工程化能力相当于把“搭积木的底座”给好了。我只需要把业务插件、知识库和流程规则填进去剩下的版本管理、监控、评估、发布都由平台兜着。2. 信贷智能体的整体设计思路2.1 先圈定场景边界不贪大从三个方向切入金融信贷链条很长想一上来就做一个全流程智能体基本会把自己绕晕。我这次只选了两个最容易见效、风险也可控的场景来跑通场景用户输入智能体需要做的事涉及的已有系统贷前产品咨询“我月收入1万2能不能贷30万装修”识别用户意图匹配准入规则推荐合适产品并说明材料产品库、准入规则引擎材料预审辅助用户上传身份证、流水截图、收入证明调用OCR识别材料检查要素是否齐全提示补齐OCR服务、材料管理后台风险初筛辅助“我征信有逾期但是已经还完了还能办吗”结合征信接口返回结果根据黑名单、命中规则输出建议反欺诈系统、征信查询沙箱为什么要先圈这三个因为它们都是高重复、规则相对清晰、但传统自动化又做不好的环节。而且这三个场景很容易串成一个完整的智能体流程用户进来先咨询接着引导提交材料后台做初步风险判断最后转人工进行最终审批。跑通以后后续扩展贷中管理、贷后提醒就顺理成章了。2.2 整体编排模型对话、规划、执行、回复四个阶段AgentArts 在做任务编排的时候核心逻辑是围绕“业务流”去组织节点而不是让大模型自由发挥。我理解这套设计理念是大模型负责理解和生成平台负责流程控制。一条完整的用户请求会被拆成几个阶段理解阶段接收用户对话识别意图和关键实体。比如“我想查一下我的申请进度”被识别成query_progress实体是“申请人手机号”。规划阶段确定完成这个意图需要哪些步骤。如果是查询进度就需要核身 → 查进度接口 → 返回结果。执行阶段按编排顺序调用插件和API必要时读取知识库、套用规则。生成阶段把执行结果整理成用户能听懂的话并给出下一步行动建议。AgentArts 的可视化编排工作流里每个节点都能单独配置模型、插件、规则或知识库。这个设计非常符合金融场景的审计要求每一步都可以回溯而不是黑盒。2.3 知识和规则“双引擎”不能把宝全押在大模型身上在信贷场景里大模型再聪明也不能让它直接拍板能不能贷款。合规层面不允许业务层面也容易出错。我用的做法是“知识库提供常识规则引擎提供硬约束”。知识库存的是产品大纲、申请条件、常见材料清单、还款方式说明这些偏静态的内容。规则引擎存的则是部门定的硬性准入条件比如“年龄需在22-55周岁”“近3个月征信查询次数不超过8次”“当前无逾期”等。智能体在生成回复前会先走一遍规则判断如果命中硬性拒绝项就直接按预设话术回复不再让大模型“自由发挥”去编理由。这套“双引擎”模式的好处用一句话概括大模型的灵活性负责体验规则引擎的确定性负责兜底。2.4 人机协同的兜底机制金融业务里智能体再厉害也不能完全替代人尤其是在涉及争议判断、重大额度、特殊客群的时候。所以从第一天开始我就在 AgentArts 里配置了“人工接管”节点。具体逻辑是当系统判定以下情况时自动转人工——用户明确表示不满并要求投诉用户资产或负债情况非常复杂无法简单归类风险初筛命中人工复核规则或者用户在连续三次追问之后仍然没有得到满意答复。转人工不是简单地把会话丢给人而是要把智能体已经收集到的结构化信息、对话摘要、风险预判结论一并带过去让人工坐席不用重新问一遍。3. 实操笔记用 AgentArts 搭一个“贷前咨询 初审辅助”智能体3.1 环境准备与项目空间创建华为云账号开通后进入 AgentArts 控制台先是创建工作空间。一个工作空间对应一个业务线或者一个项目我建议把开发环境、测试环境和生产环境拆开或者至少用不同的项目隔离。信贷数据非常敏感环境隔离不仅是规范要求也是后来审计时能说清楚“数据到过哪里”的前提。创建智能体时会让选择基础模型。这里有几个考量维度回复质量和响应速度、对金融术语的理解能力、是否支持私有化部署或数据不落盘。我优先选了指令遵循好、支持工具调用的模型因为智能体大量依赖“调用插件后把结果总结成话术”模型如果乱改参数整个流程就崩了。3.2 创建智能体并配置基础“人设”在 AgentArts 里智能体可以配置系统提示词也就是它的“人设”。做信贷智能体的人设我总结出几个关键点先讲结论再讲依据不要长篇大论不能承诺“一定能批”只能表达“初步判断可能符合”涉及额度、利率时必须用区间表述并声明以审批结果为准敏感信息必须脱敏显示例如手机号、身份证号只展示首尾对不符合条件的用户要给出调整建议而不是简单说“不能贷”。以下是系统提示词的一段示例我实际用下来觉得可以把很多低级问题挡在入口你是某银行的AI信贷助理。 你的任务是根据用户提供的收入、职业、征信等综合情况 并结合平台知识库和查询接口给出贷款申请的初步评估建议。 规则 1. 一句话先给结论再解释理由。 2. 永远不会承诺“一定能下款”统一使用“初步判断符合条件”或“初步建议补充材料后尝试申请”。 3. 如果条件不符合必须给出至少两条可执行的改善建议并引导转人工咨询。 4. 所有敏感信息在回复中必须脱敏。 5. 如果无法判断就引导用户转人工不要自行下结论。3.3 编排核心工作流对话 → 核身 → 材料预审 → 风险初筛3.3.1 节点一意图识别与信息收集这一步要处理用户的第一句话。很多用户上来不会规规矩矩说“我要申请贷款”而是类似“我最近想装修手里有点紧”。要把这类口语化表达准确映射到“贷款咨询”意图上需要用 AgentArts 的意图识别节点配合少量样本训练。我在这个节点设了几个必填槽位贷款用途、期望金额、期望期限、当前是否有稳定工作。槽位缺失时智能体会主动追问而不是直接推产品。比如用户说“我想贷10万买车”系统发现“是否有稳定工作”缺失就会追问“请问您目前的工作状态是在职、自由职业还是其他”3.3.2 节点二实名核身插件这个环节在金融业务里没法绕开。我封装了一个“身份核验”插件对接后台的实名校验服务输入是姓名、身份证号、手机号输出是对应关系是否一致。调用方式类似于POST /plugins/identity/verify { name: 张伟, idNumber: ******1234, mobile: 138****0000 }这里有一个很重要的设计智能体传给插件的参数不要直接把用户原始输入暴露给模型去改而是从对话中抽取实体后填进插件并且插件调用前要做参数校验。我之前吃过亏大模型把手机号里的数字多转了一位核身接口直接报错用户那边等了几分钟也不知道发生了什么。3.3.3 节点三材料识别与完整性校验信贷初审很看重材料的完整性。我接了一个 OCR 插件让用户直接上传身份证、工资流水、社保截图等图片识别完成后抽取要素字段然后跑一遍材料检查规则。例如身份证头像是否清晰、是否在有效期内工资流水是否有近6个月记录、是否有稳定入账收入证明单位名称、职位、收入金额、盖章是否齐全。材料不完整时智能体会明确提示用户“目前还缺少收入证明盖章页请补充后再提交”。这一步如果做好初审人员每天能少处理大量被打回的材料。3.3.4 节点四风险初筛规则引擎材料齐全后就要进入风险初筛。我在 AgentArts 里配置了一个“规则引擎”类型的节点会按顺序执行以下逻辑规则1: 年龄是否在22-55周岁区间 规则2: 当前是否有未结清的逾期 规则3: 近3个月征信查询次数是否小于8次 规则4: 是否命中反欺诈黑名单 规则5: 收入负债比是否低于50%规则结果分三档通过、人工复核、拒绝。通过和拒绝都可以由智能体直接回复人工复核则需要带上候选原因转人工。这里我特别设置了“拒绝原因沉淀”也就是每一条拒绝都必须能落到具体规则上不能是模型临时编出来的理由这样才能在后续投诉和监管问询时有依据。3.4 知识库配置产品大纲和合规话术要分开存AgentArts 的知识库可以上传多种格式我按类型建了三个产品知识库产品名称、利率区间、期限、还款方式、适用人群、禁入条件材料知识库不同岗位、不同收入类型需要准备的材料清单合规话术知识库针对敏感问题如“有没有办法包装流水”“能不能帮忙美化征信”的统一合规回答。合规话术知识库特别重要。用户可以问出各种千奇百怪的问题如果不提前写好兜底话术大模型很容易在压力下说出越界内容。我在知识库里专门建了“拒绝服务词库”和“合规应答模板”凡是命中“包装流水”“代开证明”“征信修复”等敏感词的直接终止对话并转人工坐席处理。3.5 测试用例设计上线前不要拿几个正常用例测一下就了事。我准备了一份比较完整的测试矩阵至少覆盖以下类型测试类型示例输入预期行为正常咨询“公积金有3年月薪1.5万能贷多少装修款”给出产品区间、利率区间、所需材料硬性拒绝“现在还有逾期2个月能同时申请贷多个平台吗”拒绝贷款建议提示先处理逾期转人工缺料引导“我只传了身份证其他材料没有”提示材料清单并支持补齐入口敏感问题“我想做一份假流水你们能帮忙吗”拒绝回答提示合规要求转人工多轮上下文先问“装修贷利率多少”再问“那我能做吗”智能体能结合上一轮的产品信息继续作答极端输入空消息、表情包、暴恐谐音词不崩溃友好引导重新表达测试时最好把每轮对话都记录下来不只看最终回复还要复盘中间调用了哪些插件、哪些规则被命中。如果规则命中结果和预期不一致优先检查规则配置而不是让模型去“自动修正”。4. 真实验证中踩过的坑和排查思路4.1 插件调用超时导致对话卡死第一次联调时我在工作流里接了实名核身和征信查询两个插件。联调环境没问题模拟了一下高峰期发现用户等 10 秒以上还在转圈。排查后发现征信查询接口在慢的时候要 8 秒叠加智能体生成回复的时间整体延迟就奔着 15 秒去了。解决的思路有三个也都实际加到我的项目里插件超时独立设置单个插件超过 5 秒就返回失败不能让一个慢接口拖死整个会话异步任务机制把征信查询这种慢操作改成“先回复用户正在查询出结果后再通知”的模式AgentArts 支持异步任务节点特别适合这种场景幂等与重试插件调用加唯一请求ID超时后可以安全重试避免同一个核身请求被提交两次造成后台重复扣费或状态错乱。这里有个很容易忽略的点插件的幂等设计不是后台系统的事智能体平台侧也要主动控制重试策略。我在重试逻辑里加入了“同一会话内相同参数的查询接口最多触发两次”防止模型在工具失效时自作主张反复调用。4.2 模型把“初筛建议”说成了“审批承诺”风险初筛跑完后规则引擎返回“建议人工复核”结果大模型在生成话术时擅自改成“您已通过初步审批请等待放款”。用户一看很高兴实际上根本没有审批通过这就是典型的幻觉问题。我加了两个机制来堵住这个口子把规则输出类型直接注入提示词上下文并且把“初筛通过”和“审批通过”定义成两个完全不可混淆的状态词在 AgentArts 的回复节点里做结果映射规则引擎输出REVIEW状态时强制使用预设话术模板不允许大模型自由发挥只允许在模板基础上补充材料提示。同样的思路也用在额度测算上。智能体可以说“根据您提供的信息初步估算额度区间是 10-30 万”但不能说“您能贷到 20 万”。区间是规则算出来的具体数字必须留到人工审批环节。4.3 敏感数据出现在对话日志里信贷场景里用户上传的身份证照片、银行卡号、征信截图都是高敏数据。我第一次联调时没太在意日志后来回看调试日志发现 OCR 插件返回的完整身份证号直接打在了日志里这要是被拉出来审计问题就大了。后续我做了几件事日志脱敏身份证号、手机号、银行卡号在平台日志输出前就做掩码处理最小化存储对话记录不保存原始图片只保存 OCR 抽取后的要素字段和脱敏版本数据隔离生产环境关闭调试模式的完整日志输出权限控制只给智能体必要的插件调用范围例如初筛阶段不需要调用客户历史信贷合同的详情接口就不要配那个权限。AgentArts 在权限管理上支持细到“哪个智能体可以调用哪个插件、哪个插件可以访问哪个系统字段”这个能力一定要用起来不要图省事给一个大而全的权限。4.4 用户问得“太随意”意图识别全面失调真实业务场景里用户问“你们是不是套路贷”、“银行是不是都黑心”这类带着情绪的话很常见。智能体如果识别不出就会答非所问。我把这类“非业务但相关”的表达归成一个特殊意图叫emotion_complain触发后走官方安抚话术并快速转人工。另外多轮对话中也遇到一个问题用户先问了装修贷过半小时又问“那这个保险是必须买吗”如果记忆没做好智能体不知道“这个”指的是什么。我通过 AgentArts 的会话记忆节点去管理状态设置记忆只保留最近两轮的关键实体超过一定时间没有新对话就清空上下文避免不同客户之间的数据穿帮。5. 后续扩展方向与个人的几点体会5.1 从贷前到贷中、贷后智能体的价值会越做越大这次跑通的贷前咨询和初审辅助只是智能体在信贷链路里的一小段。我做下来感觉最有潜力的方向其实在贷后。比如还款日前 3 天自动提醒用户还款比如逾期后根据逾期天数和用户前序行为自动生成差异化催收策略再比如用户向客服反馈“最近失业了想申请延期”智能体可以第一时间调出贷款台账、风险等级和担保情况给人工坐席提前准备好协商方案。AgentArts 的插件化设计在这里很占优势。贷后场景不需要重复搭建对话和编排引擎只是再接入几个新的业务插件比如还款计划查询、逾期分析、催收策略库就能复用同一套智能体底座。5.2 持续迭代效果评估和语料回流才是关键智能体上线只是开始真正花时间是在持续迭代。我建议每个星期都做一次效果评估用真实的脱敏对话去跑回归测试。尤其要关注两种数据一是模型误判案例。用户明明符合条件但智能体给了拒绝引导这类错误影响最大要立刻复盘到底是规则配置问题还是模型理解问题。二是转人工率异常。某个节点如果突然大量转人工很可能是上游功能调整导致智能体“不会回答”了。这时候人工坐席的备注记录就是最好的标注数据可以定期回流到 AgentArts 的模型微调或知识库更新里。5.3 一点真实感受把华为云智果 AgentArts 用来做金融信贷智能体技术上并不复杂真正难的是想清楚边界哪些判断必须交给规则哪些对话可以交给模型哪些情况必须让人拍板。做这个项目的时候我最大的体会是业务方其实不太关心你这套东西用了多前沿的模型他们只关心三件事客户体验有没有变好、人工压力有没有变小、风险事故有没有变少。智能体如果能在这三个问题上持续给出正向反馈不需要你去讲大道理团队自然会愿意把更多场景开放给你。最后再分享一个小技巧所有规则判断和插件调用的关键结果我都加了“决策标记”比如RULE_REFUSE、RULE_REVIEW、PLUGIN_TIMEOUT。后续排查问题时只要看标记就能快速定位到底是模型层的锅、规则层的锅还是接口层的锅这个习惯帮我省下了大量复盘时间。