金融信贷这个行业表面上看是资金生意骨子里其实是风险生意。我在这行摸爬滚打十来年见过太多团队在风控模型上砸重金却在客户交互和贷后管理环节掉链子。华为云智果AgentArts这套AI智能体平台出来之后我第一时间拿它跑了一个信贷全流程的智能体从贷前咨询到贷后催收提醒整个链路走下来有些心得确实值得拿出来聊聊。这篇文章不打算复述官方文档而是把我实际搭建过程中踩过的坑、调过的参数、想明白的设计逻辑原原本本摊开来讲。不管你是刚接触AI智能体的开发新手还是已经在金融科技领域有积累的老手应该都能从里面找到可以直接抄作业的东西。1. 金融信贷智能体的整体设计与选型思路1.1 为什么金融信贷场景需要专属智能体金融信贷业务有个很特殊的地方它既要求极高的合规严谨性又需要足够灵活的交互能力。传统的规则引擎能处理标准化的审批流程但面对客户五花八门的提问——“我上个月逾期了三天还能批吗”“提前还款违约金怎么算”“能不能帮我看看哪个产品利率最低”——规则引擎就捉襟见肘了。而通用大模型虽然能说会道却存在两个致命问题一是容易产生幻觉给出不符合监管要求的承诺二是无法直接对接核心业务系统查不了客户的真实征信数据和还款记录。华为云智果AgentArts的定位恰好卡在这个缝隙里。它提供了一套智能体编排框架让开发者可以把大模型的语言理解能力、工具调用能力和业务系统的数据能力串起来。说白了就是让AI既能“听懂人话”又能“办成人事”。我在设计信贷智能体时核心目标就三个第一所有涉及额度、利率、期限的回答必须来自真实业务系统不能由模型自己编第二多轮对话中要能记住客户之前说过的关键信息比如贷款用途、期望金额、还款方式偏好第三遇到超出权限的问题要能平滑转人工不能硬答。1.2 AgentArts平台的核心能力拆解AgentArts这个平台我理解它最核心的价值在于把智能体的构建过程“工程化”了。以前搭一个能用的对话机器人你得自己写意图识别、自己维护对话状态、自己封装API调用代码量不小而且很难维护。AgentArts把这些能力抽象成了几个关键模块意图理解与槽位填充平台内置了针对金融领域的预训练模型对“我想借五万块钱周转三个月”这类表述的解析准确率明显高于通用模型。我实测下来在信贷场景的意图识别上开箱即用的准确率大概在87%左右经过少量领域数据微调后能到94%以上。工作流编排这是我觉得最顺手的功能。你可以用拖拽的方式把“身份核验→征信查询→额度试算→产品推荐→申请提交”串成一条流水线每个节点可以是一个API调用、一段规则判断或者一次模型推理。工具调用框架平台支持把外部HTTP接口注册成“工具”模型在对话中会自动判断什么时候该调用哪个工具。比如客户问“我的额度是多少”模型会触发query_credit_limit工具把客户ID传进去拿到结果后再组织语言回复。知识库挂载信贷产品的费率表、申请条件、所需材料这些相对静态的信息可以放到知识库里模型回答时优先从知识库检索减少幻觉。我选择AgentArts而不是自己从零搭建主要考虑的是时间成本和维护成本。自己搭一套类似的框架至少需要两个后端加一个算法开发周期按月起算。而AgentArts把基础设施都做好了我只需要关注业务逻辑本身。当然平台也有它的约束比如工作流的节点数量有限制复杂逻辑需要拆成多个子工作流来调用这个后面会细说。1.3 信贷智能体的架构设计原则在动手之前我给自己定了三条设计原则后来证明这三条原则帮我省了很多返工的时间。第一条数据不出业务系统。客户的身份证号、银行卡号、征信报告这些敏感信息绝对不能进入大模型的上下文。我的做法是所有涉及敏感数据的操作都在工具内部完成模型只负责传递一个脱敏后的客户标识比如内部user_id工具返回的结果也是脱敏后的。比如查额度这个动作工具接收user_id内部去调核心系统返回的是“可贷额度范围3-8万”这样的区间信息而不是具体的征信分数。第二条关键决策必须有人工兜底。智能体可以完成80%的标准化咨询和操作但涉及大额审批、利率优惠、逾期豁免这些敏感决策一定要设置转人工的触发条件。我在工作流里加了一个“置信度判断”节点当模型对某个问题的回答置信度低于阈值我设的是0.75或者客户明确要求“找人工”就直接转接坐席。第三条对话状态要可追溯。金融信贷的监管要求很严每一笔业务的操作记录都要留痕。AgentArts本身提供了对话日志功能但我额外在工具调用层加了一层日志记录每次工具调用的入参、出参和时间戳。这样万一后面有争议可以完整还原当时的交互过程。2. 核心细节解析与实操要点2.1 意图体系的搭建与优化意图识别是智能体的入口这块如果做不好后面全是白搭。我一开始想偷懒直接用平台预置的通用意图集结果发现信贷场景的很多特定表达根本识别不了。比如客户说“我那个钱什么时候能到”通用模型会识别成“查询进度”但实际上客户可能是在问“放款时间”或者“到账时间”这两个对应的业务动作完全不同。我的做法是先梳理出信贷业务的全流程节点然后针对每个节点列出客户可能的问法。这个过程我用了笨办法但很有效把过去半年的人工坐席通话记录导出来随机抽了500通逐条标注客户意图。最后归纳出六大类、二十三个子意图意图大类子意图举例占比产品咨询利率询问、期限选择、额度范围32%申请操作材料准备、进度查询、信息修改28%还款相关还款方式、提前还款、逾期处理19%账户管理绑定银行卡、修改手机号、密码重置12%投诉建议服务投诉、利率异议、催收投诉6%其他转人工、闲聊、无法识别3%有了这个意图体系之后我在AgentArts里创建了对应的意图节点每个节点配置了至少15条训练语料。这里有个小技巧语料不要只写标准表述要把口语化的、带错别字的、甚至带情绪的表述都加进去。比如“你们这个利息也太高了吧”和“利率能不能便宜点”要归到同一个意图里。2.2 工作流节点的参数配置要点AgentArts的工作流编排看起来简单但每个节点的参数配置直接影响最终效果。我拿“额度试算”这个节点举例说明几个关键参数的设置逻辑。这个节点的作用是客户输入期望贷款金额和期限后系统调用内部风控接口返回一个可贷额度区间。配置界面里需要填几个东西接口地址内部风控系统的API端点这个没什么好说的。超时时间我设的是3000毫秒。为什么不是默认的5000因为信贷咨询场景对响应速度要求很高客户等超过3秒就会不耐烦。实测下来风控接口的P99响应时间是2.1秒设3秒既能覆盖绝大多数请求又不会让客户等太久。重试策略我配了一次重试间隔500毫秒。金融系统偶尔会有网络抖动一次重试能解决大部分偶发失败。但重试次数不能多否则客户等待时间会成倍增加。降级方案如果接口调用失败且重试也失败节点会走降级分支返回“当前系统繁忙请稍后再试或转人工”的提示。这个降级分支一定要配不然客户会卡在那里不知道发生了什么。还有一个容易忽略的参数是入参映射。AgentArts允许你把对话中提取的槽位值映射到接口的请求参数上。这里要注意类型转换客户说的“五万”要转成数字50000“三个月”要转成数字3。平台内置了常见的转换规则但中文数字和阿拉伯数字混用的情况需要额外配置。我的做法是在槽位定义时就限定类型为“数字”并在提示词里明确要求模型输出阿拉伯数字。2.3 知识库的构建与检索策略信贷产品的知识库和一般客服知识库不太一样它的更新频率高利率调整、活动上线而且对准确性要求极高。我采用的是“结构化非结构化”混合的方案。结构化的部分比如各产品的利率表、期限选项、申请条件我直接存成JSON格式通过工具调用来查询。这样做的好处是数据准确不会出现模型“记错”利率的情况。非结构化的部分比如常见问题解答、材料清单说明、注意事项我放到AgentArts的知识库里用向量检索的方式匹配。知识库的切分策略我调了好几版。一开始按固定长度切结果经常把一条完整的问答切成两半检索出来的片段不完整。后来改成按语义段落切每个问答对作为一个独立的chunk检索准确率明显提升。具体操作是在上传文档时用##标记每个问答对的分隔平台会按这个标记来切分。检索的相似度阈值我设的是0.72。这个值怎么来的我拿100个真实客户问题做了测试统计正确回答被检索到的比例和错误回答被检索到的比例。阈值设0.72时正确召回率是89%错误召回率是7%综合效果最好。阈值调高到0.8正确召回率降到76%调到0.65错误召回率升到15%。所以0.72是我实测下来的甜点值。注意知识库的更新不是实时的每次修改后需要手动触发重建索引。我一般是在非业务高峰期比如凌晨做这个操作避免影响线上服务。3. 实操过程与核心环节实现3.1 从零搭建一个贷前咨询智能体我拿一个具体的场景来演示完整的搭建过程客户想咨询个人消费贷款需要了解自己能贷多少、利率多少、怎么申请。第一步创建智能体并配置基础信息。在AgentArts控制台新建一个智能体名称填“信贷咨询助手”描述写“处理个人消费贷款的贷前咨询”。这里有个细节描述要写得具体因为平台会根据描述来推荐预置的意图模板。我写“个人消费贷款贷前咨询”比写“贷款咨询”得到的推荐模板更精准。第二步定义槽位。这个场景需要收集三个关键信息贷款用途、期望金额、期望期限。我在槽位定义里分别设置了这三个槽位类型分别是枚举用途、数字金额、数字期限。枚举值我列了装修、教育、医疗、旅游、其他。为什么要限定枚举因为后续的产品推荐逻辑会根据用途来匹配不同的产品如果让模型自由发挥可能会出现“买手机”这种不在产品范围内的用途。第三步编排工作流。工作流的主干是欢迎语→意图识别→槽位收集→信息确认→额度试算→产品推荐→申请引导。每个节点的配置我挑几个关键的说明。槽位收集节点我配置了追问话术。如果客户只说了“我想贷款”没有提供金额和期限节点会自动追问“请问您大概需要多少资金计划分多久还清”这里的话术要自然不能像审问一样。我试过几种追问方式发现把两个问题合并成一句话问客户的配合度更高。信息确认节点我会把收集到的信息复述一遍让客户确认“您计划贷款5万元用于装修分12期还清对吗”这个确认步骤很重要能减少后续因为信息错误导致的返工。确认节点的判断逻辑是如果客户回复“对”“是的”“没错”等肯定词进入下一步如果客户纠正了某个信息回到槽位收集节点重新收集。额度试算节点调用内部风控接口。这里我遇到过一个坑风控接口返回的额度是一个精确数字比如“可贷额度68000元”。但直接告诉客户这个数字有合规风险因为最终审批额度可能会变。我的处理方式是在工具返回结果后加一个格式化节点把精确数字转成区间“根据您的综合评估可贷额度范围大约在6-7万元之间最终额度以审批结果为准。”第四步配置转人工规则。我设置了三个触发条件客户主动说“转人工”“找客服”模型置信度低于0.75连续两轮无法识别客户意图。触发后智能体会把当前对话的摘要和已收集的槽位信息一起推送给人工坐席这样坐席不用从头问起。3.2 贷后还款提醒的自动化实现贷前咨询跑通之后我又把智能体扩展到了贷后场景。贷后还款提醒这个需求很明确在还款日前三天自动触达客户提醒还款金额和日期并引导客户完成还款操作。这个场景和贷前咨询最大的区别是它是主动触达而不是被动响应。AgentArts支持通过API触发智能体发起对话我用的方式是和内部的催收管理系统对接。系统每天跑批筛选出三天后到期的客户名单然后逐个调用AgentArts的对话发起接口。对话的流程设计是这样的首先发送提醒消息“尊敬的客户您有一笔贷款将于X月X日到期应还金额XXXX元请确保还款账户余额充足。”然后等待客户回复。如果客户回复“知道了”“好的”对话结束标记为“已提醒”。如果客户问“能不能延期”“还款方式是什么”进入问答流程。如果客户明确表示“还不上”触发转人工由坐席跟进协商。这里有个实操细节消息发送的时间窗口。我一开始设的是上午9点统一发送结果发现很多客户在上班路上回复率很低。后来改成两个时间段上午10-11点和晚上7-8点客户可以根据自己的情况选择。实测下来回复率从23%提升到了41%。还有一个合规上的考虑提醒话术不能带有威胁性语言。我见过一些催收话术写“再不还款将影响您的征信”虽然事实如此但直接这么说容易引发客户反感。我的写法是“为维护您的良好信用记录建议您按时还款”把“威胁”变成“建议”客户接受度更高。3.3 多轮对话中的上下文管理金融信贷的对话经常是多轮的客户可能先问利率再问期限然后问提前还款最后才决定申请。如果每一轮都当成独立的对话来处理客户会疯掉——每次都要重新说一遍自己的需求。AgentArts提供了对话上下文管理的能力但默认的上下文窗口有限。我的做法是在对话开始时生成一个session_id把客户的关键信息已收集的槽位、已确认的信息、当前所处的流程节点存到一个外部缓存里我用的是Redis。每次模型推理前从缓存里取出这些信息拼接到提示词里。提示词的结构我调了很多版最终稳定下来的模板是这样的你是一个信贷咨询助手。当前客户信息 - 贷款用途{purpose} - 期望金额{amount} - 期望期限{term} - 当前流程节点{node} - 历史对话摘要{summary} 请根据以上信息回答客户问题。如果客户提供了新的信息请更新对应的字段。这个模板的关键在于历史对话摘要。如果把完整的对话历史都塞进去token消耗大而且容易超限。我的做法是每5轮对话让模型生成一次摘要把之前的内容压缩成两三句话。这样既保留了关键信息又控制了上下文长度。实操心得摘要生成的质量直接影响多轮对话的连贯性。我试过让模型自己决定什么时候生成摘要结果它经常忘记。后来改成强制每5轮触发一次稳定性好很多。4. 常见问题与排查技巧实录4.1 意图识别不准的排查思路这是最常见的问题客户说的明明是这个意思模型偏偏识别成另一个意图。我总结了一套排查流程按顺序检查先看语料覆盖度。把识别错误的case拿出来看看对应的意图下有没有类似的训练语料。如果没有补充进去。我一般会为每个意图准备至少30条语料覆盖不同的表达方式。再看槽位冲突。有时候不是意图识别错了而是槽位提取错了。比如客户说“我想借三万”模型把“三万”提取成了期限而不是金额。这种情况要检查槽位定义的类型和提示词是否清晰。最后看模型版本。AgentArts的意图识别模型有多个版本不同版本在不同场景下的表现有差异。我实测下来金融领域的意图识别用finance-bert-v2版本比通用版本准确率高8个百分点左右。如果以上都排查了还是不准那就考虑上微调。AgentArts支持上传标注数据做微调我一般积累到500条以上的标注数据才会考虑微调数据太少容易过拟合。4.2 工具调用失败的常见原因工具调用是智能体和业务系统之间的桥梁这座桥断了智能体就变成了只会聊天的玩具。我遇到过的工具调用失败主要有这几种问题现象可能原因排查方法解决方案调用超时接口响应慢或网络抖动查看工具调用日志的耗时增加超时时间或优化接口性能参数错误槽位提取错误或类型不匹配检查入参日志修正槽位定义或添加强制转换权限拒绝接口鉴权失败检查API密钥和权限配置更新密钥或申请权限返回格式异常接口返回了非预期格式查看原始返回内容增加返回值的校验和容错处理频繁限流调用频率超过接口限制查看调用频率统计增加缓存或申请提高限额我印象最深的一次是参数错误客户说“贷五万”槽位提取出来是字符串“五万”但接口要求的是数字50000。模型没有自动转换导致接口报错。后来我在槽位定义里加了转换规则把中文数字统一转成阿拉伯数字问题就解决了。4.3 对话中断和异常恢复的处理线上环境什么情况都可能发生网络断了、服务重启了、客户突然不说话了。智能体需要能优雅地处理这些异常。客户长时间不回复我设了一个5分钟的等待窗口超过5分钟没有新消息智能体会发送一条“您还在吗如果需要继续咨询请回复任意内容。”如果再过5分钟还是没有回复对话自动结束标记为“超时未完成”。服务异常中断如果工具调用过程中服务挂了智能体会捕获异常返回“当前服务繁忙请稍后再试”。同时我会在后台记录这次异常方便后续排查。这里要注意异常信息不能直接暴露给客户比如“NullPointerException”这种客户看了只会更困惑。客户情绪激动信贷场景中客户因为逾期被催收情绪激动是常有的事。我配置了情绪识别当检测到客户消息中包含负面情绪词比如“投诉”“曝光”“骗子”智能体会立即转人工并且把对话优先级调高。4.4 性能优化的几个实用技巧智能体上线后响应速度直接影响客户体验。我做了几轮优化把平均响应时间从4.2秒压到了1.8秒。主要做了这几件事缓存高频查询结果。产品利率、期限选项这些信息短时间内不会变但查询频率很高。我在工具层加了一层Redis缓存缓存有效期设5分钟。这样大部分查询直接走缓存不用每次都调后端接口。并行化工具调用。有些场景需要同时查多个信息比如既查额度又查利率。我把这两个工具调用改成并行执行而不是串行等待。AgentArts的工作流支持并行节点配置一下就行。精简提示词。提示词越长模型推理越慢。我把提示词里不必要的说明和示例删掉只保留最核心的指令。实测下来提示词从800字压缩到300字推理时间减少了约40%。选择合适的模型规格。AgentArts提供了不同规格的模型大模型效果好但速度慢小模型速度快但效果差一些。我的策略是意图识别和槽位提取用中等规格的模型最终回复生成用大模型。这样在效果和速度之间取得了平衡。5. 智能体上线后的运营与迭代5.1 效果监控的关键指标智能体上线不是终点而是起点。我每天会看几个核心指标意图识别准确率随机抽100条对话人工标注正确的意图和模型识别的结果对比。这个指标我要求保持在90%以上。任务完成率客户发起的咨询中有多少比例在不转人工的情况下完成了目标比如查到了额度、提交了申请。目前我的智能体完成率是76%剩下的24%主要转人工了。平均对话轮次完成一个任务平均需要几轮对话。轮次太多说明智能体理解能力不够轮次太少可能说明收集的信息不充分。我的目标是控制在5-8轮。客户满意度每通对话结束后我会推送一个简单的满意度评价满意/不满意。目前满意率是82%。5.2 基于badcase的迭代方法我每周会整理一次badcase把识别错误、回答不当、工具调用失败的对话挑出来分类分析原因。常见的badcase类型和对应的迭代动作类型一知识盲区。客户问了一个知识库里没有的问题模型胡编了一个答案。解决方法是把这个问题补充到知识库里并检查是否有类似的问题也需要补充。类型二流程卡点。客户在某个节点反复徘徊无法进入下一步。比如客户一直说“我就想问问利率”但智能体非要先收集用途和金额才给查利率。这种流程设计不合理的地方需要调整工作流的顺序允许客户跳过某些非必要步骤。类型三语气不当。模型的回复太生硬或者太随意。比如客户说“我急用钱”模型回复“好的请问您需要多少金额”这个回复没有体现出对客户急迫心情的理解。我会调整提示词让模型在回复中先表达共情再进入正题。5.3 合规审查的注意事项金融信贷是强监管行业智能体的每一句话都可能被监管审查。我在上线前做了几轮合规检查重点看这几个方面不能承诺审批结果。智能体可以说“根据初步评估您可能符合申请条件”但不能说“您一定能贷到款”。所有涉及审批结果的表述都要加“以最终审批为准”。不能泄露客户信息。在对话中智能体不能主动说出客户的身份证号、银行卡号等敏感信息。即使是客户自己问“我的卡号是多少”也要引导客户通过安全渠道查询而不是直接在对话里展示。不能使用歧视性语言。智能体的回复不能因为客户的性别、年龄、地域等因素而有所不同。我在提示词里明确要求模型保持中立不做出任何带有偏见的表述。保留完整的对话记录。按照监管要求信贷业务的对话记录至少要保存5年。AgentArts的日志功能可以满足这个要求但我额外做了定期备份防止数据丢失。提示合规审查最好找法务部门的同事一起过一遍他们能从监管的角度发现一些技术人员注意不到的问题。6. 一些踩坑之后的个人体会这套智能体从搭建到上线前后花了大概六周时间其中前两周基本都在试错。如果让我重新来一遍有几个地方我会做得不一样。第一不要试图一次性把所有场景都覆盖。我一开始想把贷前、贷中、贷后全塞进一个智能体里结果工作流复杂到我自己都理不清。后来拆成了三个独立的智能体各自负责一个阶段通过统一的客户ID来关联维护起来清爽多了。第二语料的质量比数量重要。我一开始从网上爬了几千条信贷相关的问答想着语料越多越好。结果发现很多语料和实际业务不匹配反而干扰了模型。后来全部删掉用真实坐席通话记录重新标注了500条效果比之前几千条还好。第三转人工不是失败而是必要的兜底。我一开始追求转人工率越低越好后来发现有些复杂问题客户其实更愿意和真人沟通。强行让智能体处理反而降低了满意度。现在我把转人工率控制在20%左右客户满意度和坐席效率都更好了。第四工具调用的日志一定要记全。我遇到过好几次客户投诉说“你们系统说我能贷10万结果审批只批了5万”。查日志发现智能体当时说的是“可贷额度范围大约在5-10万”客户只记住了上限。有了完整的日志这种争议就能快速澄清。最后分享一个我觉得很实用的小技巧在智能体的欢迎语里加一句“本服务由AI提供重要信息请以最终审批为准”。这句话看起来简单但能省掉很多后续的合规麻烦。客户知道对面是AI期望值会更合理遇到问题也更容易接受转人工的安排。