金融信贷智能体实战：基于AgentArts构建贷前资料预审助手

这两年做金融信贷系统我最大的感受是业务方对 AI 的态度已经从“要不要上”变成“怎么上”。信贷审批、资料审核、客户回访、贷后预警几乎每个环节都在问能不能用 AI 智能体来提效。正好这段时间在华为云智果 AgentArts 上把一个信贷资料预审智能体从零搭到了能跑通踩了不少坑也摸出了一些门道今天把整个实战过程拆开讲讲。先给不熟悉的朋友交代一下背景。AgentArts 是华为云上的智能体开发平台定位是让开发者用更低门槛的方式构建 AI 智能体核心能力包括智能体编排、工作流、知识库、插件工具和记忆管理。我理解的智能体不是简单的“聊天机器人”而是能自己拆任务、调工具、查资料、做判断的 AI 应用。金融信贷恰恰是特别适合智能体落地的场景因为流程长、文档多、规则复杂、人工操作重复每一处都值得用 AI 重新做一遍。这篇文章不是官方教程而是我在真实项目里的操作记录和思考适合正在做金融数字化、信贷系统改造、或者刚开始接触智能体开发的同学参考。1. 先搞清楚智能体在信贷里到底解决什么问题1.1 信贷流程里的“人力黑洞”在哪里信贷业务看起来是标准化的但真正跑过一线就知道里面有大量非结构化、需要人来判断的环节。就拿贷前资料审核来说客户经理收上来一堆材料包括营业执照、身份证、银行流水、财务报表、纳税记录信审员要一份份打开看确认是否齐全、是否清晰、是否在有效期内再对照产品制度判断有没有明显不符合准入条件的地方。这个过程极度依赖经验又极度重复。我见过一个真实场景一个客户经理一天要处理几十份贷款申请每份材料平均七八个文件光“资料齐全性检查”就要花十几分钟遇到缺材料的还要来回打电话补件。如果再碰上财报里的数字对不上、营业执照的经营范围跟贷款用途不一致人工核对的时间更没法估。传统规则引擎能做一部分自动校验但它看不懂自然语言也读不懂PDF扫描件里的表格和印章更没法根据上下文判断材料之间的逻辑关系。这就是智能体的切入点。它跟RPA、规则引擎最大的区别在于RPA擅长的是“按固定路径操作”规则引擎擅长的是“按固定公式判断”而 AI 智能体可以做到“理解任务、拆解步骤、调用工具、整合信息、给出结论”。信贷预审恰好需要这种组合能力——既要有 OCR 识别材料又要有规则校验还要有模型理解语义最后还要把结论以结构化形式输出给业务系统。1.2 AgentArts 在这个场景里凭什么合适选择 AgentArts不是因为“华为云”三个字而是这个平台解决了金融团队做智能体时最常见的几个障碍。第一是设施成本。金融企业想用大模型通常要先考虑模型部署、算力、运维这一套下来周期很长。AgentArts 托管了智能体运行环境开发前期不用自己搭推理服务可以把精力放在业务流程上。第二是可视化编排。信贷预审这个场景不是“问一句答一句”的聊天而是要按步骤走完“采集材料、识别内容、校验规则、生成结论”的完整链路。AgentArts 的工作流画布可以直接把 OCR、规则校验、模型判断串成一个流程拖拽节点就行比纯代码开发直观很多。第三是企业级能力。知识库、插件、记忆、权限管理、日志审计这些都是平台内置的金融场景天生对权限和审计有要求不用再额外造轮子。这里要说明一下AgentArts 不是“低代码到不用写代码”的神器复杂逻辑仍然需要写函数、调API但它把智能体应用最繁琐的“框架部分”处理掉了让团队能把时间花在业务规则和模型调优上。1.3 智能体在信贷项目里的使用边界在金融信贷场景里我必须反复强调一个原则智能体做辅助判断不做最终决策。信贷审批涉及资金安全、客户隐私、机构合规任何一个环节出错都可能造成实质损失。所以我们在设计目标时把智能体定位成“信审员的助理”它负责把重复劳动做完把可疑点标出来把结论和建议给到人但最终批不批还是要人工来定。这个边界不是业务上的保守而是工程上必须遵守的安全底线。智能体再强它仍然是概率模型存在幻觉、理解偏差、工具调用异常的可能。所以在做架构时我会刻意把“智能体的输出”和“业务系统的决策”解耦智能体的预审结论只作为参考字段进入待办列表不会直接触发审批通过或拒绝的动作。这一点想清楚后面整个设计方案才不会跑偏。2. 动手前的方案设计从业务场景到智能体拆解2.1 场景选择为什么先做“贷前资料预审”AgentArts 上能做的信贷智能体很多客服问答、贷后催收提醒、客户经理助手、反欺诈辅助都可以做。但我的建议是第一个场景不要铺太大选一个“价值高、风险低、可验证”的切入点。我这次选的是贷前资料预审原因有三个第一是价值直观。资料审核占信审员大量时间做好了立刻能看见效率提升。第二是风险可控。预审本身不涉及最终放款决策即使模型判断错了后面还有人工复核兜底不会直接造成资金风险。第三是效果可验证。预审结果可以跟人工审核结果做对比准确率、召回率、耗时这些指标都能量化团队能明确知道智能体到底有没有用。反过来看贷后预警、反欺诈这类场景虽然价值更大但涉及的系统多、数据杂、误报成本高不适合作为第一个智能体项目。等流程跑顺了再把智能体能力延伸到这些环节。2.2 把业务能力拆成智能体的四个组成部分明确了场景之后要做的是把业务需求翻译成智能体技术方案。我习惯用一个简单框架来拆智能体 任务规划模型能力 领域知识知识库 执行动作工具/插件 上下文记忆。对应到信贷资料预审这个场景就是任务规划由大模型完成负责理解“你是信贷预审助理请根据资料和规则判断申请是否完整合规”领域知识放在知识库里包括信贷产品制度、准入要求、材料规范、常见退件原因执行动作是一组工具包括 OCR 识别、联网核验、规则引擎调用、信贷系统接口查询上下文记忆用来记录当前客户已经提交了什么材料、哪一项还没补。这个拆分很重要。很多人做智能体失败是因为把所有东西都塞进提示词里结果提示词越长模型越混乱。正确做法是各司其职知识库管静态规则工具管动态数据模型管理解和决策。AgentArts 把这几块都做成了独立配置项设计的时候按这个思路去填逻辑会清晰很多。2.3 提前想清楚数据链路和合规边界金融信贷场景里数据链路的设计比模型选型更值得花时间。我在动手之前画了一条完整的数据流客户提交材料 → 文件进入对象存储 → 智能体从存储拉取文件 → OCR节点识别内容 → 结构化数据进入规则校验 → 校验结果和模型判断汇总 → 输出预审报告 → 写入信贷系统待办。这条链路里有两点必须提前确认。第一是数据出域问题客户证件、流水、联系方式都属于敏感信息进入大模型之前要做好脱敏。有些数据甚至不能离开机构内部网络那就需要在私有化环境里部署智能体或者用平台提供的安全通道来做传输。第二是日志留存问题AI 的判断过程和调用记录要完整保留出问题的时候能回溯“为什么这个客户被标记了风险”。AgentArts 的调试和审计能力在这一块能帮上忙但具体日志字段的规范还是要按机构内部要求来设计。3. AgentArts 实战搭建以“信贷资料预审助手”为例3.1 创建智能体先定角色再定工作流打开 AgentArts 控制台后第一步是创建应用。我在平台上新建的是“智能体应用”不是普通的对话机器人因为后续需要编排工具调用。填写的名称叫“信贷资料预审助手”描述里写清楚它的职责面向信贷初审人员对贷款申请材料进行完整性检查、格式校验、关键风险点提示。关键在系统提示词。金融场景的提示词不能太“放飞”我给智能体定义了几个强制约束只能使用提供的工具和知识库内容不允许主观推断客户的还款能力对不确定的信息必须明确说“无法确认”所有结论都要标注依据来源最终输出必须是结构化JSON方便业务系统解析。提示词示例大概长这样你是一位严谨的信贷资料预审助理。你的任务是基于客户提交的申请材料、机构信贷制度和知识库规则输出资料预审结论。你必须遵守以下规则 1. 只依据知识库和工具返回的信息作答禁止猜测客户资质。 2. 对每一份材料检查完整性、清晰度、有效期。 3. 如果发现材料缺失、文件模糊、关键信息不一致在风险提示中明确列出。 4. 最终输出格式为JSON包含材料清单、完整性结论、风险提示列表、建议操作。 5. 不确定的信息一律标注“无法确认”不得生成不确定的结论。创建完基础智能体后我在平台上配置了一个开场白和几个建议问题方便测试时快速进入场景。这里多说一句开场白不是给用户看的装饰它也是模型理解任务边界的一部分。写得越具体模型后续的回复越不容易跑偏。3.2 工作流编排串起 OCR、校验和模型判断AgentArts 的工作流画布是整个项目里最实用的部分。我搭的工作流从“开始”节点出发先做意图识别判断用户输入是“提交新申请预审”“查询预审进度”还是“补充材料”然后根据意图走不同分支。默认分支是资料预审主线先调用 OCR 插件识别上传的身份证、营业执照、银行流水等文件把识别出来的结构化字段传给下一节点接着进入规则校验节点这一步我用的不是大模型而是一段规则代码判断“身份证是否过期”“营业执照经营范围是否与贷款用途匹配”“流水文件是否包含足够时间段”等硬性条件。规则校验节点的好处是结果稳定、可控、有明确代码依据不会像模型一样飘忽不定。最后所有信息汇总到“风险判断”节点由大模型结合知识库规则输出预审结论。这个编排顺序是我反复调整后才确定的。最开始我把规则校验也交给大模型做结果模型在判断“文件是否清晰”“盖章是否可见”这类视觉特征时表现不稳定而且每次输出格式都有细微差异很难直接对接业务系统。后来改成“OCR负责结构化提取代码负责硬校验模型负责语义理解和风险提示”每条链路的责任边界清晰了整体稳定性和可解释性立刻上来了。3.3 知识库挂载把制度文档变成模型能查的东西信贷预审离不开行内的信贷制度、产品准入条件、材料规范说明这些文档。在 AgentArts 的知识库功能里我把这些 PDF、Word 文档上传进去系统会自动切片和向量化运行的时候模型会从中检索相关内容作为回答依据。这里有几个实操细节值得记录。第一是文档切分粒度。我之前上传过一份很长的产品制度手册系统自动切分后模型每次检索出来的片段要么太碎只有一两句话要么太粗把多个产品混在一起。后来我在上传时做了人工预处理把文档按“单一产品准入条件”“单一操作流程”切成独立小节再上传检索准确率明显提高。第二是检索阈值。知识库默认的相似度阈值比较宽松在金融场景里要调高一点宁可漏召回也不要把错误知识喂给模型。第三是知识库的更新机制。信贷制度会调整知识库必须同步更新我在实践里会在每次制度变更后重新上传并做一次端到端回归测试避免模型拿着旧规则给结论。3.4 工具接入让智能体真正“动手做事”智能体不能只靠嘴说要能调用外部系统完成真实动作。在信贷预审助手这个项目里我接入的工具主要有三类OCR识别、内部信贷系统查询、规则计算服务。OCR识别用的是标准接口调用在 AgentArts 的插件市场上可以直接找到对应插件也可以在自定义工具里封装自己的服务地址。内部信贷系统查询需要把现有接口封装成工具描述这一步最考验细节。模型并不知道你的接口参数要怎么填它只能靠工具描述来理解“这个工具能做什么、需要什么参数”。所以工具描述写得越清楚调用成功率越高。比如“查询客户征信概要”这个工具描述里我会写明入参是客户身份证号出参包含征信查询结果和风险标识如果查询失败返回错误码503。规则计算服务我是用代码节点实现的写成函数接收 OCR 出来的结构化字段返回校验结果。这里要注意工具节点和代码节点在 AgentArts 里都是可以设置超时和重试的。金融系统接口偶尔不稳定我给关键工具都加了超时时间和两次重试避免因为一次网络抖动导致整条流程失败。3.5 测试与调优用真实脱敏数据跑通闭环搭建完成后真正的挑战才开始。我把测试集分成三类标准通过案例、缺料案例、高风险案例各准备十条脱敏样本。跑下来发现几个典型问题第一意图识别偶尔把“补充材料”误判成“新申请”导致走错分支第二OCR 识别营业执照上的小字号文字偶尔出错导致后续规则校验误判第三模型生成的JSON格式不总是合法解析时偶发报错。针对这些问题我做了三件事。先把意图识别的示例加了更多尤其是在提示词里补充了“补充材料”说法的近义表达其次在 OCR 节点后加了人工确认环节识别置信度低于阈值的文件转人工处理而不是让模型强行判断最后给大模型输出加了一层“JSON修复器”用代码对模型返回内容做容错解析保证输出能稳定对接业务系统。这些调优做完之后测试集的流程通过率从最初的六成提升到了九成以上。4. 关键难点与参数调优心得4.1 提示词设计给模型套上“金融从业者的缰绳”金融场景的提示词设计核心不是“让模型更聪明”而是“让模型更克制”。信贷预审助手在运行过程中出现过一次事故一位测试客户在备注里写了“目前收入不稳定但有房产”模型在风险提示里直接给出了“疑似还款能力不足建议拒绝”的判断。这个结论严格来说不算错但它属于模型的主观推测没有经过机构准入规则的校验直接出现会影响业务判断导向。我后来在提示词里加了更严格的限制“只允许根据知识库中的准入条件和工具返回的客观数据生成结论不得对客户还款意愿和还款能力做主观推测涉及客户负面信息的表述必须引用具体材料或数据来源。”同时把模型温度参数调低减少随机性。提示词还规定如果知识库里找不到对应依据必须输出“未找到相关制度依据”而不是自己编一个合理解释。这个“强制引用”的思路是金融智能体跟普通聊天机器人最大的区别。4.2 结构化输出让模型返回业务系统能用的数据信贷系统对接智能体最怕的就是模型返回一段散文业务系统没法解析。所以从第一天开始我就要求模型输出严格的结构化JSON并且在提示词里给出了明确的格式模板{ apply_id: 申请编号, materials: [ {name: 身份证, status: complete, note: } ], completeness: pass, risk_flags: [营业执照经营范围与贷款用途不符], suggestion: manual_review, confidence: high }实际测试中模型偶尔会多输出一个字段名、把字符串写成带引号的数字、或者漏掉某个必填字段。光靠提示词没法100%解决这个问题所以我加了一个后处理函数用代码对模型的输出做清理和纠错先提取JSON片段再尝试解析如果失败就按字段截取。这套“模型生成 代码兜底”的组合保证了智能体输出永远能落入业务系统的字段里。4.3 多轮对话与记忆管理别让上下文“记糊涂”信贷预审不是一个一次性对话就能完成的场景。客户第一次提交材料后往往几天后又来补件这时候智能体需要记得上次审核到哪一步、缺了什么材料。AgentArts 提供了记忆能力可以设置会话级记忆或业务级记忆变量。我在这个项目里用了一个“材料清单”变量把客户已经提交的材料列表保存下来每轮对话开头先读取这个变量再判断当前新增了什么材料。这里有个容易被忽略的问题上下文窗口是有限的。如果每轮对话都把全部历史消息塞给模型先不说费用模型很容易被无关内容干扰。我的做法是在对话轮次较多时只保留当前申请单的摘要信息和最近一轮用户输入历史细节靠记忆变量去恢复而不是靠聊天记录。这样既节约上下文又保持了核心状态。4.4 安全与合规金融智能体的生命线金融场景下的智能体安全合规不是上线前补一个检查项而是要从架构上设计进入。我在这个项目里做了三层防护。第一层是数据入口脱敏客户身份证号、手机号、银行卡号在进入模型之前先做掩码处理需要用完整证件号查询时只把脱敏后的数据传给工具侧。第二层是工具调用白名单智能体只能调用预设插件不允许动态生成任意HTTP请求。第三层是日志审计所有智能体判断、工具调用、上下文内容都记录到独立日志系统满足内部审计要求。另外我还加了内容安全审核的兜底防止模型在极端输入下生成不符合公序良俗的内容。这可能让部分响应变得保守但在金融行业保守才是安全的。宁可智能体拒绝回答也不能让它给出一个看似合理但没有依据的结论。5. 常见问题与排查技巧实录5.1 智能体“答非所问”怎么排查智能体跑起来之后最常见的异常就是答非所问。比如用户问“营业执照不清楚能不能补交”模型却开始讲“贷款申请流程”。遇到这类情况我一般按三个顺序排查先看提示词里有没有明确限定回答范围再看知识库检索有没有返回相关内容最后看意图识别是不是出了问题。大部分答非所问并不是模型“笨”而是任务边界没有约束住。一个非常有效的做法是在提示词里加“不相关场景的默认回复”。我写了一句“如果用户问题与信贷资料预审无关请回复该问题不在我的职责范围内建议咨询客户经理。”加了这句话之后跑偏比例下降非常明显。因为它给了模型一个明确出口否则模型会倾向于尽量回答用户的所有问题。5.2 工具调用失败先看参数定义再看网络状态工具调用是智能体项目里报错最多的地方。我遇到过三种情况参数名对不上、参数格式不对、外部服务超时。在 AgentArts 的调试日志里能看到模型为某个工具生成的参数JSON大部分报错一眼就能定位。比如模型把“customer_id”拼成了“customerId”这时候不要怪模型要回去改工具描述里的参数示例写得越标准模型拼错概率越低。外部服务超时的问题我在工具配置里把超时时间从默认的几秒调到了十五秒并且加了重试机制。这里要注意金融系统的部分查询接口比较慢如果上游服务本身没有做幂等设计重试可能会产生重复记录。所以重试前一定要确认接口是否幂等不确定的话就不要自动重试转人工处理。5.3 知识库检索不准从切分和查询两头调知识库召回不准模型给出来的答案就会“一本正经地胡说”。排查时先看检索结果AgentArts 可以打出每个回答对应的引用来源如果引用的片段跟问题无关就是检索问题如果引用了正确片段但答案不对就是模型理解问题。检索不准的优先调文档切分粒度把大文档拆成主题明确的小段其次调相似度阈值把阈值从默认值往上提过滤掉低质量召回内容最后如果平台支持重排序可以打开重排序让最相关的内容排在最前面。我在实际操作中发现知识库数据本身的“措辞”也很影响召回。信贷制度文档里用的都是正式表达而用户提问往往是口语化的两者在向量空间里可能离得比较远。后来我在知识库里补充了一批“常见问法映射”把“流水不够怎么办”“材料不齐能批吗”这类口语问题和正式制度条款做了关联召回准确率又提升了一截。5.4 并发与性能别让智能体变成新的瓶颈预审助手如果只给一个部门用低并发够用但一旦推广到全行客户经理就必须考虑性能。AgentArts 本身有弹性扩容能力但外部依赖的接口和服务不一定扛得住。我给整条链路加了一个前置接口层由业务后端来控制并发数超过阈值的请求进入排队或提示稍后重试。OCR 接口的并发尤其要注意图片识别是耗时操作我把批量提交改成逐份提交避免一次性压垮下游。还建议在运行一段时间后持续记录响应耗时和成功率。我跑了两周之后发现规则校验节点偶尔会因为数据库连接池打满而失败后来把连接池参数调大问题就消失了。这些性能问题在测试阶段通常暴露不出来只有真实业务流量进来才会出现所以上线后一定要保留一段观察期不要上线就撒手。写在最后我的实战体会这个项目跑通之后我最大的体会是AI 智能体在金融信贷里的价值不在于它能不能“像人一样思考”而在于它能不能把重复劳动接过去让人的精力放在真正需要判断力的事情上。AgentArts 这类平台降低了智能体的开发门槛但门槛低不代表没有门槛业务理解、数据治理、提示词约束、工具设计每一块都需要实打实投入。如果让我给后来者一个建议我会说第一个智能体项目一定要选一个足够小、足够具体、效果可量化的场景。不要一上来就追求“全能助手”先把一条链路跑通把输出质量、稳定性、审计机制这些基本功练扎实再往更多业务场景复制。智能体不是魔法它是需要持续调优的工程系统理解了这一点后面走的每一步都会稳很多。