客户经理每天要重复回答几十遍“你们利率多少”“征信花了能不能贷”“抵押物到底要交哪些材料”。信贷政策每更新一版话术就要跟着改一遍改漏一处就是合规风险。这正是金融信贷场景里最值得做AI智能体的地方不是让AI替人做决策而是把人从重复问答和材料初审里解放出来。我最近在一个信贷项目中用华为云智果AgentArts完整搭建了一套信贷咨询智能体从业务建模、工作流编排、知识库准备到灰度上线都走了一遍。这篇复盘不打算讲平台宣传页上的概念只说我在实际落地中遇到的选择、参数、坑和判断给准备在金融信贷领域碰智能体的团队做参考。1. 为什么信贷业务需要智能体以及我为什么选AgentArts这个平台1.1 信贷业务里那些高频、重复、低容错的工作信贷咨询本身是一个强规则、弱自由发挥的业务。同样一个利率问题不同产品、不同区域、不同客群的答案完全不同但它又有非常明确的规则和文档可查。这种“高重复、强规则、高容错成本”的组合恰恰是AI智能体最能发挥价值的地方也是纯聊天机器人搞不定的地方——因为规则藏在几十份制度文档里人要靠记忆和文件来回切换一个新员工至少要培训两个月才能独立回答客户的常规咨询。比问答更耗人的是材料初审。客户申请贷款时客户经理需要核对身份证、收入流水、工作证明、征信授权书等一堆材料。材料缺不缺、格式对不对、有没有明显造假痕迹这些问题看起来简单但每天面对上百个客户时非常消磨人力。我见过一个网点的客户经理在下班后还要手工录入材料清单这种工作完全可以交给智能体配合OCR去完成初筛让人只复核异常件。还有一个高频痛点是政策传导。监管口径、总行制度、区域细则经常更新一线人员理解不一致就会出风险。传统做法是发通知、开会、考试但落到日常咨询里还是会有人答错。智能体在这类场景里的价值不在于“答得多聪明”而在于“每次都按最新版本答”并且每一步回答都有据可查。这种确定性比模型能力本身更稀缺。1.2 我为什么没有从零自建也没有选偏消费级的开源方案一开始团队里也有声音说直接用开源框架自己搭Agent毕竟模型API、向量库、工作流引擎这些组件都能找到。但我算了一笔账自建一个可用级别的Agent系统至少要处理模型调用封装、会话记忆、工具协议、知识库更新、日志审计、权限控制六块基础设施。金融场景下还要额外满足审计留痕、私有化部署、人工复核闸门这些合规要求工程量和维护成本远超想象。我也对比过一些偏消费级的智能体平台。这类平台做营销文案、闲聊问答很顺手但一旦涉及结构化工作流、外部信贷系统接口对接、细颗粒度的权限和审计能力就明显吃力。AgentArts让我觉得踏实的地方主要有四点一是工作流编排是可视化的能把信贷业务的判断逻辑显式画出来而不是全藏在提示词里二是插件体系能接企业内部的征信、OCR、试算服务三是知识库和模型路由是一体的换模型不用重构流程四是整个平台和华为云的底座衔接紧密私有化部署和审计方案相对成熟。2. 动手之前的业务建模把信贷流程拆成智能体能干活的单元2.1 贷前、贷中、贷后哪些环节最适合先落地我接手项目后第一件事不是打开平台画工作流而是先把信贷业务的完整旅程拆了一遍。贷前环节包括营销获客、产品咨询、资质预审、材料收集、反欺诈初筛、信用评估辅助贷中环节包括合同生成、抵质押办理、放款条件审核贷后环节包括还款提醒、逾期预警、客户服务、结清证明。逐个评估下来贷后客户服务的自动化程度相对高但很多已经跑在传统IVR和工单系统里改造动力不足贷中的合同和放款审核容错率极低短期很难说服业务方放手交给智能体。真正适合先落地的是贷前的咨询问答和材料预审。原因有几个第一这类工作业务方本来就缺人痛点足够痛第二问答和材料初筛不直接产出审批结论风险等级低业务方更容易接受第三这两块都依赖制度文档和规则正好是知识库加工具调用的强项第四一旦跑通复用性极强同一个智能体可以扩展到不同产品线。2.2 我锁定的第一个落地点贷前咨询与材料预审智能体最终我们选定的场景是“房贷类产品的贷前咨询与材料预审”智能体。为什么锁定房贷而不是经营贷或者消费贷因为房贷的产品结构相对标准利率、期限、首付比例、申请材料都有明确规则而且客户的咨询问题高度集中评测集和答案标准都好定义。经营贷反而涉及经营实体、税务、发票等多维信息规则分散第一版做容易失控。这个智能体要完成三件事回答客户关于房贷利率、额度、首付、材料清单的咨询引导客户补全贷款条件对客户上传的材料做初步完整性检查并给出待补清单。审批结论、额度承诺、利率承诺这三类内容从第一天起就明确了智能体绝对不能碰这是红线。2.3 能力边界清单什么交给模型什么必须走系统调用做业务建模时我画了一张能力边界表这比任何架构图都管用。我把智能体的每一项能力分为三类模型生成、工具调用、知识库检索。产品利率和月供试算必须走工具调用让模型算利率等于让它背利率表一次升级就会错一批征信情况解读必须走工具调用征信数据属于强合规信息模型不能凭客户自述做判断材料完整性校验走OCR加规则脚本哪些材料必须传、格式要求是什么由规则判断制度条款问答走知识库检索加模型总结答案必须带引用话术寒暄和客户意图澄清才放手让模型自由生成但也要套上合规模板。这个能力边界的核心原则是能用规则和工具解决的绝不让模型自由发挥。模型负责的是理解客户意图、组织语言、从检索到的材料里提炼答案而不是记忆事实和计算数字。3. 核心实战在AgentArts上编排信贷智能体的工作流3.1 先理解AgentArts工作流的基本构成在AgentArts上智能体不等于一个对话框它更像一个带状态的流程执行引擎。用户消息进入后会被路由到工作流里工作流可以调模型、调插件、调知识库最后把结果返回给用户。这一点在信贷场景里特别重要因为信贷业务不允许模型自由发挥每一步都要能回溯到具体节点和参数。我理解的工作流基本节点包括开始节点、意图识别节点、条件分支节点、工具调用节点、代码或函数节点、知识库检索节点、大模型生成节点、人工审核节点和回复节点。实际使用中还有一个容易被忽略的节点是“变量赋值”它用来维护会话状态比如客户是否已经确认了所在城市、贷款用途、抵押物类型。多轮对话里如果状态没存住客户说了一半又换个问题智能体很容易断片。3.2 一条典型流程房贷咨询加材料预审的工作流设计我搭的第一版工作流路径比较直接核心链路如下用户消息 - 意图识别贷款咨询 / 材料预审 / 还款服务 / 转人工 - 条件分支贷款咨询 - 收集条件贷款类型、所在城市、抵押物类型 - 工具调用利率试算服务 - 知识库检索对应版本的产品制度 - LLM生成带引用的回复 - 合规校验是否存在保证性承诺 - 输出 - 条件分支材料预审 - 引导客户上传材料 - 工具调用OCR材料识别 - 规则脚本完整性校验 - LLM生成待补清单和说明 - 人工复核节点 - 输出这个流程看起来不复杂但有几个配置细节值得展开。意图识别节点不能只依赖模型默认能力。信贷客户的话术非常分散同一个“我想贷多少钱”可能被说成“我能申请多少”“你们最多批多少”“额度大概多少”。我在意图识别节点里维护了一个标注样本集把真实客服聊天记录里的常见问法全部喂进去模型才能稳定分对。实测下来不做这个步骤的意图准确率大概能到80%做了之后能稳定在94%以上。条件收集节点设计成“缺什么问什么”的漏斗。客户进来先给一句话我们先用模型抽取已知条件再看看还缺哪几个关键字段缺哪个就问哪个。这里要注意别把客户问烦了一次最多追问两个条件如果客户表示不清楚直接转人工比继续逼问更稳妥。知识库检索节点有一个容易踩的坑不能检索完了不管结果直接让模型答。我加了召回数量限制和阈值判断如果最相关的切片得分低于设定值就不让模型硬答而是走兜底话术“这个情况需要客户经理进一步核条件我已经帮您记录了会有人联系您”。这个兜底救了不少场子。3.3 插件封装征信查询、OCR这些外部能力怎么接进来工作流里真正决定业务价值的是工具调用。AgentArts的插件体系支持把外部服务封装成标准化的可调用节点我们在里面接了两个最核心的服务征信授权校验和材料OCR识别。征信接口封装时遇到的实际问题比想象中多。首先是鉴权信贷系统内部走的是双向证书加签名不能简单拿一个AK/SK就完事需要在插件配置里维护证书信息和报文加解密逻辑。其次是超时征信接口偶尔会因为上游系统慢导致长时间不返回如果不在插件层设置合理超时时间工作流会被SQL查询拖死。我把超时设成了5秒超过就返回失败智能体再向客户表达“系统繁忙请稍后重试”。第三是幂等这一条做不好会出事。重试场景下如果重复发起征信查询既浪费额度又可能触发合规问题所以每次调用都要带上链路追踪ID重试时先查这个ID是否已经处理过处理过就直接返回原结果。OCR材料识别插件更偏向批量处理。客户可能一次上传五六张图片工作流要先把图片压缩、转码再逐个调用OCR服务最后把识别出来的文本汇总到变量里交给规则脚本做完整性判断。这里我调过的一个参数是图片分辨率阈值太低会识别不出小字体的银行流水太高又会增加服务耗时折中下来控制在单张不超2MB、最低宽800像素比较合适。4. 让智能体“懂行”的关键信贷知识库与RAG检索优化4.1 信贷语料怎么准备才算合格信贷智能体能不能用七成取决于知识库干不干净。我们当时收了几十份文档包括产品手册、利率表、审查审批指引、客户常见问题FAQ。这些文档直接灌进去是不行的里面最大的隐患是版本冲突同一个产品三月份的政策和七月份的政策可能完全相反新老政策同时入库模型就会答出前后矛盾的内容。清洗阶段我给每一份文档打了三个标签生效日期、适用产品、适用区域然后强制要求检索时带标签过滤。比如检索“杭州首套房按揭利率”知识库只会命中“生效日期在最近、适用产品为按揭、适用区域为杭州”的切片老版本直接不参与排序从源头避免新旧混淆。切片策略上我踩过一个典型误区一开始按固定字数切每512个字一段。信贷文档里经常出现“但上述规定不适用于以下情况”这种倒装逻辑固定切分很容易把例外条款和适用条件拆到两段里检索只召回到一半模型拿着半截规则去回答就可能会错。后来改成按文档结构块切分产品说明、适用条件、利率、期限、申请材料、例外条款各成一段语义完整性好了很多召回率也上来了。4.2 一次完整的召回率优化过程从70%多到超90%当时看到华为云另一个码道检视智能体项目公开的实测召回率能做到91.3%我给自己定的目标就是稳定压过90%最后确实在信贷咨询评测集上做到了。这个结果不是一步到位的过程中经历了五轮调整。第一轮纯向量检索基线召回率只有70%出头。排查发现很多客户问题里口语表达和制度用词完全对不上比如客户问“工资流水行不行”制度文档里写的是“代发工资入账记录”语义上是一回事向量检索却召不回来。第二轮做query改写把口语问题先让模型转成文档风格的标准问法再去做向量检索召回率涨到78%。代价是响应时间多了几百毫秒但这个代价值得。第三轮改成混合检索向量召回加BM25关键词召回结果集做加权融合。这一步解决了专业术语的精确匹配问题召回率到了83%左右。第四轮加了rerank重排把召回的前50个切片用更精细的模型重新打分取Top5喂给生成模型。到这里召回率到了87%。第五轮的提升来自元数据过滤。我把产品、区域、生效日期做成强制过滤条件检索阶段就排除掉不该出现的版本这一步让召回率最终稳定在90%以上。整个过程的核心心得是向量检索只是起点真正决定信贷知识召回质量的是检索策略和元数据过滤的组合拳。4.3 生成侧约束没有依据就不答且必须带来源知识库再好生成侧不约束一样会翻车。我在AgentArts的模型生成节点里做了三条硬性约束。第一条回答必须引用知识库切片编号。要求模型输出答案时附带“依据材料编号xxx”没有引用信息的回答一律不返回给客户。第二条关键数据后置校验。利率、期限、首付比例这类硬数据在回复出去之前用脚本比对知识库原文对不上就拦截。第三条明确设置“无依据即拒答”指令。模型找不到答案时默认输出兜底话术而不是靠自身参数里的常识硬编。金融场景里模型的“拒答能力”比“聪明程度”重要得多。5. 测试、评测与上线前的反复打磨5.1 信贷智能体的评测指标别只看对话流畅度很多团队评测智能体会陷进“对话挺流畅”的错觉里但信贷业务要的是可量化的安全性。我建了一套五维指标每周固定跑一遍。指标口径目标准确率回答与业务专家标准答案一致的比例90%以上召回率关键制度信息被成功检索的比例90%以上合规率回答中无绝对化承诺、无歧视性表述、无超出业务边界内容的比例100%人转率触发引导转人工的会话占比25%以内首答时长从用户发问到首次有效回复的耗时10秒以内其中合规率是零容忍指标一条不合规的回答都出不去。人转率倒不是越低越好转人工太频繁说明智能体能力不足完全不转又说明它可能在硬撑、在越界回答健康区间是15%到25%。评测集的构建比想象中费人力。我从客服系统的真实会话记录里抽取了200个典型问题由业务专家逐个标注标准答案和引用材料编号再按季度补充新政策带来的新问题。这套评测集最后成了整个项目最有价值的数据资产每次改模型、改提示词都靠它来回归验证。5.2 我遇到并解决的几个高频Badcase第一个Badcase是客户问“我征信有一笔逾期记录还能贷款吗”。模型直接回答“不能”这是典型的一刀切错误。征信逾期能不能贷要看金额、时点、是否已结清业务上绝大部分此类情况都要人工核实。我们在知识库里加入了一条强制指引涉及征信异常智能体只能解释影响因素禁止给出通过与不通过的判断必须转人工。第二个典型问题是“你们利率是多少”。模型容易报一个确定数字但实际情况是利率跟客户资质、区域、产品都有关系。修复方案是在产品利率工具节点里加入反向确认逻辑客户没提供完整条件时先输出“利率根据您的贷款类型和资质综合评估”再反问三到四个关键问题。第三个是客户反复追问“最低能到多少”模型被绕进去后容易给出保证性承诺。这个光靠提示词约束不够我在合规校验节点写了一条正则加语义规则凡是输出中出现“最低”“保证”“肯定能批”这类词一律拦截并转人工。第四个是材料清单问题模型凭记忆答漏了新增的收入证明要求。修复后材料清单类问题强制走知识库检索禁止模型直接生成。5.3 上线前必须做的三件事上线前有三件事必须做完少一件都不要放出去。第一件业务专家全量审核。把智能体所有知识条目、回复模板、边界话术整理成台账让信贷业务专家逐条签字确认这个环节比技术测试更关键。第二件灰度策略设计。我们没有直接对外开放而是先在内部员工渠道跑了两周让客户经理用真实业务问题去测把测试阶段暴露的badcase收集回来再迭代。这个阶段收集到的问题分布远比评测集丰富很多意想不到的客户问法都是这时候发现的。第三件全量留痕和审计配置。智能体的每一次问答、每一个知识引用、每一次工具调用、每一个转人工动作都记录日志日志里包含用户会话ID、时间戳、命中的知识切片版本、模型参数量和输入输出摘要。金融场景的审计要求是“事后要能把一次对话完整还原”这个能力必须在上线前验证通过。6. 踩坑实录与个人经验总结6.1 文档里不会写清楚的平台细节有几个细节是实际用了几个版本之后才摸清楚的写在这里供参考。第一长上下文不等于高准确率。初期试过把多份制度文档直接塞进模型上下文效果反而变差因为关键信息被海量文字稀释了。显式拼接知识库检索出的关键切片比一股脑全塞进去效果好得多。第二平台自带的调试面板能跑通流程但不能验证业务语义。它告诉你节点调用成功、返回时间正常但不会告诉你答案对不对。真正的质量保证还得靠外部评测集。第三灰度期间要重点盯“未命中日志”也就是用户问了很多轮智能体始终没答出来的会话。这个日志比任何指标都宝贵它直接暴露知识库缺口和意图识别盲区。我每天都翻发现一个补一个。第四多Agent协作时上下文传递要显式设计。我们在流程里还拆了一个“提前还贷助手”子智能体两个智能体之间靠会话ID对齐一开始没做状态同步经常出现上一个问题聊的是按揭咨询下一个问题跑到材料预审里客户信息却串了。后来统一在会话入参里带上业务场景字段才解决。第五模型版本升级后输出格式会发生漂移。大模型厂商升级版本后同样的提示词可能不再遵守JSON格式这会导致下游工具解析失败。升级前必须拿评测集做全量回归不能只看几个示例对话就放行。6.2 如果再让我做一次我会从哪几件事做起如果时间能倒流我第一步不会是急着搭工作流而是先把知识库和评测集建起来。工作流随时可以改但没有一套靠谱的评测集改来改去都是凭感觉。第二个调整是第一个场景选得更小一点聚焦到“利率试算加材料清单问答”这种最窄最容易闭环的任务跑通后再向外扩展。第三个调整是说服业务方更早地参与知识条目审核而不是等知识库做好了再让他们看因为真正常出现的规则异动和例外条款只有业务专家知道。最后说一句个人感受在金融信贷里做AI智能体成功的标准不是它多像人而是它多像一台严谨、可靠、不出格的业务机器。每次输出都有依据每个边界都清晰每条记录都可追溯这些才是信贷智能体真正值钱的地方。踩过一圈坑之后我反而更相信一件事这类场景里克制比炫技重要拒答比硬答安全。 
长河君 · 2026/10/4 5:23:44 · 阅读 1.2k 基于华为云AgentArts搭建信贷咨询智能体的实战复盘
客户经理每天要重复回答几十遍“你们利率多少”“征信花了能不能贷”“抵押物到底要交哪些材料”。信贷政策每更新一版话术就要跟着改一遍改漏一处就是合规风险。这正是金融信贷场景里最值得做AI智能体的地方不是让AI替人做决策而是把人从重复问答和材料初审里解放出来。我最近在一个信贷项目中用华为云智果AgentArts完整搭建了一套信贷咨询智能体从业务建模、工作流编排、知识库准备到灰度上线都走了一遍。这篇复盘不打算讲平台宣传页上的概念只说我在实际落地中遇到的选择、参数、坑和判断给准备在金融信贷领域碰智能体的团队做参考。1. 为什么信贷业务需要智能体以及我为什么选AgentArts这个平台1.1 信贷业务里那些高频、重复、低容错的工作信贷咨询本身是一个强规则、弱自由发挥的业务。同样一个利率问题不同产品、不同区域、不同客群的答案完全不同但它又有非常明确的规则和文档可查。这种“高重复、强规则、高容错成本”的组合恰恰是AI智能体最能发挥价值的地方也是纯聊天机器人搞不定的地方——因为规则藏在几十份制度文档里人要靠记忆和文件来回切换一个新员工至少要培训两个月才能独立回答客户的常规咨询。比问答更耗人的是材料初审。客户申请贷款时客户经理需要核对身份证、收入流水、工作证明、征信授权书等一堆材料。材料缺不缺、格式对不对、有没有明显造假痕迹这些问题看起来简单但每天面对上百个客户时非常消磨人力。我见过一个网点的客户经理在下班后还要手工录入材料清单这种工作完全可以交给智能体配合OCR去完成初筛让人只复核异常件。还有一个高频痛点是政策传导。监管口径、总行制度、区域细则经常更新一线人员理解不一致就会出风险。传统做法是发通知、开会、考试但落到日常咨询里还是会有人答错。智能体在这类场景里的价值不在于“答得多聪明”而在于“每次都按最新版本答”并且每一步回答都有据可查。这种确定性比模型能力本身更稀缺。1.2 我为什么没有从零自建也没有选偏消费级的开源方案一开始团队里也有声音说直接用开源框架自己搭Agent毕竟模型API、向量库、工作流引擎这些组件都能找到。但我算了一笔账自建一个可用级别的Agent系统至少要处理模型调用封装、会话记忆、工具协议、知识库更新、日志审计、权限控制六块基础设施。金融场景下还要额外满足审计留痕、私有化部署、人工复核闸门这些合规要求工程量和维护成本远超想象。我也对比过一些偏消费级的智能体平台。这类平台做营销文案、闲聊问答很顺手但一旦涉及结构化工作流、外部信贷系统接口对接、细颗粒度的权限和审计能力就明显吃力。AgentArts让我觉得踏实的地方主要有四点一是工作流编排是可视化的能把信贷业务的判断逻辑显式画出来而不是全藏在提示词里二是插件体系能接企业内部的征信、OCR、试算服务三是知识库和模型路由是一体的换模型不用重构流程四是整个平台和华为云的底座衔接紧密私有化部署和审计方案相对成熟。2. 动手之前的业务建模把信贷流程拆成智能体能干活的单元2.1 贷前、贷中、贷后哪些环节最适合先落地我接手项目后第一件事不是打开平台画工作流而是先把信贷业务的完整旅程拆了一遍。贷前环节包括营销获客、产品咨询、资质预审、材料收集、反欺诈初筛、信用评估辅助贷中环节包括合同生成、抵质押办理、放款条件审核贷后环节包括还款提醒、逾期预警、客户服务、结清证明。逐个评估下来贷后客户服务的自动化程度相对高但很多已经跑在传统IVR和工单系统里改造动力不足贷中的合同和放款审核容错率极低短期很难说服业务方放手交给智能体。真正适合先落地的是贷前的咨询问答和材料预审。原因有几个第一这类工作业务方本来就缺人痛点足够痛第二问答和材料初筛不直接产出审批结论风险等级低业务方更容易接受第三这两块都依赖制度文档和规则正好是知识库加工具调用的强项第四一旦跑通复用性极强同一个智能体可以扩展到不同产品线。2.2 我锁定的第一个落地点贷前咨询与材料预审智能体最终我们选定的场景是“房贷类产品的贷前咨询与材料预审”智能体。为什么锁定房贷而不是经营贷或者消费贷因为房贷的产品结构相对标准利率、期限、首付比例、申请材料都有明确规则而且客户的咨询问题高度集中评测集和答案标准都好定义。经营贷反而涉及经营实体、税务、发票等多维信息规则分散第一版做容易失控。这个智能体要完成三件事回答客户关于房贷利率、额度、首付、材料清单的咨询引导客户补全贷款条件对客户上传的材料做初步完整性检查并给出待补清单。审批结论、额度承诺、利率承诺这三类内容从第一天起就明确了智能体绝对不能碰这是红线。2.3 能力边界清单什么交给模型什么必须走系统调用做业务建模时我画了一张能力边界表这比任何架构图都管用。我把智能体的每一项能力分为三类模型生成、工具调用、知识库检索。产品利率和月供试算必须走工具调用让模型算利率等于让它背利率表一次升级就会错一批征信情况解读必须走工具调用征信数据属于强合规信息模型不能凭客户自述做判断材料完整性校验走OCR加规则脚本哪些材料必须传、格式要求是什么由规则判断制度条款问答走知识库检索加模型总结答案必须带引用话术寒暄和客户意图澄清才放手让模型自由生成但也要套上合规模板。这个能力边界的核心原则是能用规则和工具解决的绝不让模型自由发挥。模型负责的是理解客户意图、组织语言、从检索到的材料里提炼答案而不是记忆事实和计算数字。3. 核心实战在AgentArts上编排信贷智能体的工作流3.1 先理解AgentArts工作流的基本构成在AgentArts上智能体不等于一个对话框它更像一个带状态的流程执行引擎。用户消息进入后会被路由到工作流里工作流可以调模型、调插件、调知识库最后把结果返回给用户。这一点在信贷场景里特别重要因为信贷业务不允许模型自由发挥每一步都要能回溯到具体节点和参数。我理解的工作流基本节点包括开始节点、意图识别节点、条件分支节点、工具调用节点、代码或函数节点、知识库检索节点、大模型生成节点、人工审核节点和回复节点。实际使用中还有一个容易被忽略的节点是“变量赋值”它用来维护会话状态比如客户是否已经确认了所在城市、贷款用途、抵押物类型。多轮对话里如果状态没存住客户说了一半又换个问题智能体很容易断片。3.2 一条典型流程房贷咨询加材料预审的工作流设计我搭的第一版工作流路径比较直接核心链路如下用户消息 - 意图识别贷款咨询 / 材料预审 / 还款服务 / 转人工 - 条件分支贷款咨询 - 收集条件贷款类型、所在城市、抵押物类型 - 工具调用利率试算服务 - 知识库检索对应版本的产品制度 - LLM生成带引用的回复 - 合规校验是否存在保证性承诺 - 输出 - 条件分支材料预审 - 引导客户上传材料 - 工具调用OCR材料识别 - 规则脚本完整性校验 - LLM生成待补清单和说明 - 人工复核节点 - 输出这个流程看起来不复杂但有几个配置细节值得展开。意图识别节点不能只依赖模型默认能力。信贷客户的话术非常分散同一个“我想贷多少钱”可能被说成“我能申请多少”“你们最多批多少”“额度大概多少”。我在意图识别节点里维护了一个标注样本集把真实客服聊天记录里的常见问法全部喂进去模型才能稳定分对。实测下来不做这个步骤的意图准确率大概能到80%做了之后能稳定在94%以上。条件收集节点设计成“缺什么问什么”的漏斗。客户进来先给一句话我们先用模型抽取已知条件再看看还缺哪几个关键字段缺哪个就问哪个。这里要注意别把客户问烦了一次最多追问两个条件如果客户表示不清楚直接转人工比继续逼问更稳妥。知识库检索节点有一个容易踩的坑不能检索完了不管结果直接让模型答。我加了召回数量限制和阈值判断如果最相关的切片得分低于设定值就不让模型硬答而是走兜底话术“这个情况需要客户经理进一步核条件我已经帮您记录了会有人联系您”。这个兜底救了不少场子。3.3 插件封装征信查询、OCR这些外部能力怎么接进来工作流里真正决定业务价值的是工具调用。AgentArts的插件体系支持把外部服务封装成标准化的可调用节点我们在里面接了两个最核心的服务征信授权校验和材料OCR识别。征信接口封装时遇到的实际问题比想象中多。首先是鉴权信贷系统内部走的是双向证书加签名不能简单拿一个AK/SK就完事需要在插件配置里维护证书信息和报文加解密逻辑。其次是超时征信接口偶尔会因为上游系统慢导致长时间不返回如果不在插件层设置合理超时时间工作流会被SQL查询拖死。我把超时设成了5秒超过就返回失败智能体再向客户表达“系统繁忙请稍后重试”。第三是幂等这一条做不好会出事。重试场景下如果重复发起征信查询既浪费额度又可能触发合规问题所以每次调用都要带上链路追踪ID重试时先查这个ID是否已经处理过处理过就直接返回原结果。OCR材料识别插件更偏向批量处理。客户可能一次上传五六张图片工作流要先把图片压缩、转码再逐个调用OCR服务最后把识别出来的文本汇总到变量里交给规则脚本做完整性判断。这里我调过的一个参数是图片分辨率阈值太低会识别不出小字体的银行流水太高又会增加服务耗时折中下来控制在单张不超2MB、最低宽800像素比较合适。4. 让智能体“懂行”的关键信贷知识库与RAG检索优化4.1 信贷语料怎么准备才算合格信贷智能体能不能用七成取决于知识库干不干净。我们当时收了几十份文档包括产品手册、利率表、审查审批指引、客户常见问题FAQ。这些文档直接灌进去是不行的里面最大的隐患是版本冲突同一个产品三月份的政策和七月份的政策可能完全相反新老政策同时入库模型就会答出前后矛盾的内容。清洗阶段我给每一份文档打了三个标签生效日期、适用产品、适用区域然后强制要求检索时带标签过滤。比如检索“杭州首套房按揭利率”知识库只会命中“生效日期在最近、适用产品为按揭、适用区域为杭州”的切片老版本直接不参与排序从源头避免新旧混淆。切片策略上我踩过一个典型误区一开始按固定字数切每512个字一段。信贷文档里经常出现“但上述规定不适用于以下情况”这种倒装逻辑固定切分很容易把例外条款和适用条件拆到两段里检索只召回到一半模型拿着半截规则去回答就可能会错。后来改成按文档结构块切分产品说明、适用条件、利率、期限、申请材料、例外条款各成一段语义完整性好了很多召回率也上来了。4.2 一次完整的召回率优化过程从70%多到超90%当时看到华为云另一个码道检视智能体项目公开的实测召回率能做到91.3%我给自己定的目标就是稳定压过90%最后确实在信贷咨询评测集上做到了。这个结果不是一步到位的过程中经历了五轮调整。第一轮纯向量检索基线召回率只有70%出头。排查发现很多客户问题里口语表达和制度用词完全对不上比如客户问“工资流水行不行”制度文档里写的是“代发工资入账记录”语义上是一回事向量检索却召不回来。第二轮做query改写把口语问题先让模型转成文档风格的标准问法再去做向量检索召回率涨到78%。代价是响应时间多了几百毫秒但这个代价值得。第三轮改成混合检索向量召回加BM25关键词召回结果集做加权融合。这一步解决了专业术语的精确匹配问题召回率到了83%左右。第四轮加了rerank重排把召回的前50个切片用更精细的模型重新打分取Top5喂给生成模型。到这里召回率到了87%。第五轮的提升来自元数据过滤。我把产品、区域、生效日期做成强制过滤条件检索阶段就排除掉不该出现的版本这一步让召回率最终稳定在90%以上。整个过程的核心心得是向量检索只是起点真正决定信贷知识召回质量的是检索策略和元数据过滤的组合拳。4.3 生成侧约束没有依据就不答且必须带来源知识库再好生成侧不约束一样会翻车。我在AgentArts的模型生成节点里做了三条硬性约束。第一条回答必须引用知识库切片编号。要求模型输出答案时附带“依据材料编号xxx”没有引用信息的回答一律不返回给客户。第二条关键数据后置校验。利率、期限、首付比例这类硬数据在回复出去之前用脚本比对知识库原文对不上就拦截。第三条明确设置“无依据即拒答”指令。模型找不到答案时默认输出兜底话术而不是靠自身参数里的常识硬编。金融场景里模型的“拒答能力”比“聪明程度”重要得多。5. 测试、评测与上线前的反复打磨5.1 信贷智能体的评测指标别只看对话流畅度很多团队评测智能体会陷进“对话挺流畅”的错觉里但信贷业务要的是可量化的安全性。我建了一套五维指标每周固定跑一遍。指标口径目标准确率回答与业务专家标准答案一致的比例90%以上召回率关键制度信息被成功检索的比例90%以上合规率回答中无绝对化承诺、无歧视性表述、无超出业务边界内容的比例100%人转率触发引导转人工的会话占比25%以内首答时长从用户发问到首次有效回复的耗时10秒以内其中合规率是零容忍指标一条不合规的回答都出不去。人转率倒不是越低越好转人工太频繁说明智能体能力不足完全不转又说明它可能在硬撑、在越界回答健康区间是15%到25%。评测集的构建比想象中费人力。我从客服系统的真实会话记录里抽取了200个典型问题由业务专家逐个标注标准答案和引用材料编号再按季度补充新政策带来的新问题。这套评测集最后成了整个项目最有价值的数据资产每次改模型、改提示词都靠它来回归验证。5.2 我遇到并解决的几个高频Badcase第一个Badcase是客户问“我征信有一笔逾期记录还能贷款吗”。模型直接回答“不能”这是典型的一刀切错误。征信逾期能不能贷要看金额、时点、是否已结清业务上绝大部分此类情况都要人工核实。我们在知识库里加入了一条强制指引涉及征信异常智能体只能解释影响因素禁止给出通过与不通过的判断必须转人工。第二个典型问题是“你们利率是多少”。模型容易报一个确定数字但实际情况是利率跟客户资质、区域、产品都有关系。修复方案是在产品利率工具节点里加入反向确认逻辑客户没提供完整条件时先输出“利率根据您的贷款类型和资质综合评估”再反问三到四个关键问题。第三个是客户反复追问“最低能到多少”模型被绕进去后容易给出保证性承诺。这个光靠提示词约束不够我在合规校验节点写了一条正则加语义规则凡是输出中出现“最低”“保证”“肯定能批”这类词一律拦截并转人工。第四个是材料清单问题模型凭记忆答漏了新增的收入证明要求。修复后材料清单类问题强制走知识库检索禁止模型直接生成。5.3 上线前必须做的三件事上线前有三件事必须做完少一件都不要放出去。第一件业务专家全量审核。把智能体所有知识条目、回复模板、边界话术整理成台账让信贷业务专家逐条签字确认这个环节比技术测试更关键。第二件灰度策略设计。我们没有直接对外开放而是先在内部员工渠道跑了两周让客户经理用真实业务问题去测把测试阶段暴露的badcase收集回来再迭代。这个阶段收集到的问题分布远比评测集丰富很多意想不到的客户问法都是这时候发现的。第三件全量留痕和审计配置。智能体的每一次问答、每一个知识引用、每一次工具调用、每一个转人工动作都记录日志日志里包含用户会话ID、时间戳、命中的知识切片版本、模型参数量和输入输出摘要。金融场景的审计要求是“事后要能把一次对话完整还原”这个能力必须在上线前验证通过。6. 踩坑实录与个人经验总结6.1 文档里不会写清楚的平台细节有几个细节是实际用了几个版本之后才摸清楚的写在这里供参考。第一长上下文不等于高准确率。初期试过把多份制度文档直接塞进模型上下文效果反而变差因为关键信息被海量文字稀释了。显式拼接知识库检索出的关键切片比一股脑全塞进去效果好得多。第二平台自带的调试面板能跑通流程但不能验证业务语义。它告诉你节点调用成功、返回时间正常但不会告诉你答案对不对。真正的质量保证还得靠外部评测集。第三灰度期间要重点盯“未命中日志”也就是用户问了很多轮智能体始终没答出来的会话。这个日志比任何指标都宝贵它直接暴露知识库缺口和意图识别盲区。我每天都翻发现一个补一个。第四多Agent协作时上下文传递要显式设计。我们在流程里还拆了一个“提前还贷助手”子智能体两个智能体之间靠会话ID对齐一开始没做状态同步经常出现上一个问题聊的是按揭咨询下一个问题跑到材料预审里客户信息却串了。后来统一在会话入参里带上业务场景字段才解决。第五模型版本升级后输出格式会发生漂移。大模型厂商升级版本后同样的提示词可能不再遵守JSON格式这会导致下游工具解析失败。升级前必须拿评测集做全量回归不能只看几个示例对话就放行。6.2 如果再让我做一次我会从哪几件事做起如果时间能倒流我第一步不会是急着搭工作流而是先把知识库和评测集建起来。工作流随时可以改但没有一套靠谱的评测集改来改去都是凭感觉。第二个调整是第一个场景选得更小一点聚焦到“利率试算加材料清单问答”这种最窄最容易闭环的任务跑通后再向外扩展。第三个调整是说服业务方更早地参与知识条目审核而不是等知识库做好了再让他们看因为真正常出现的规则异动和例外条款只有业务专家知道。最后说一句个人感受在金融信贷里做AI智能体成功的标准不是它多像人而是它多像一台严谨、可靠、不出格的业务机器。每次输出都有依据每个边界都清晰每条记录都可追溯这些才是信贷智能体真正值钱的地方。踩过一圈坑之后我反而更相信一件事这类场景里克制比炫技重要拒答比硬答安全。