从前年开始我们团队就在琢磨信贷业务里怎么落地大模型一开始试过直接接通用大模型做问答效果说实话很一般模型对产品规则一知半解问个提前还款违约金都能给你算出两种答案更别提材料核验、额度测算这类需要真实数据支撑的环节。后来转到华为云智果 AgentArts 上做金融信贷 AI 智能体才算是把咨询接待、资料预审、试算这些场景真正串了起来。这篇文章是我这半年多从选型、开发到上线调优的实战复盘把信贷场景做智能体的关键思路、平台能力、实际参数配置和踩过的坑都写清楚给准备在金融信贷方向做智能体开发、或者在华为云上搭建 Agent 应用的同行一个参考。1. 金融信贷场景下智果 AgentArts 的定位与选型思路1.1 信贷业务里AI 智能体到底解决了什么问题信贷业务的日常运营有个很典型的结构性矛盾一方面进件量越来越大用户咨询越来越碎片化另一方面业务规则复杂、合规要求高人工处理成本居高不下。我梳理过我们行里的实际业务流向用户触点基本集中在几个重复度极高的环节——产品咨询、进件材料准备、审批进度查询、还款计划试算、贷后变更申请。这些环节有一个共同点规则明确、问答密度高、但单次交互价值不大用人工接听和回复的效率非常低。通用大模型直接用到这些场景会暴露三个问题。第一模型不了解行内产品细则客户问“你们那个按日计息的产品能不能提前还款”的时候模型只会按常识回答缺乏业务依据第二信贷涉及额度、利率、征信数据等敏感变量模型一旦在计算或者条件判断上出错后果不是客服说错话那么简单第三业务需要和 OCR 识别、额度引擎、征信接口打通纯文本问答模型没有工具调用能力做不了闭环。AI 智能体的思路就是把这三点补上。智果 AgentArts 这类的 Agent 平台本质上做的事情是让大模型做大脑规划任务、拆解步骤让知识库做记忆提供业务规则和产品事实让插件和工作流做手脚调用外部系统和数据接口再让审核和权限机制做护栏保证不能越界。落地到信贷场景好处很直接——用户问“我这种情况能不能贷 20 万”智能体不是直接拍脑袋回答而是先抽取用户信息再调额度试算接口结合产品规则给出区间性解释关键节点还能转人工复核。1.2 为什么选了华为云 AgentArts 而不是自研或通用平台选型阶段我们对比过自研 Agent 框架、Dify、Coze、以及国内几家云厂商的智能体平台各有各的长处。自研的路子灵活度最高但我们要接知识库、多模态识别、工作流编排、审计日志全栈自研的工程量太大周期至少是按月算的信贷业务等不起。Dify 这类开源平台在应用搭建上效率很高但在企业级权限、私有化部署、审计合规上需要自己做不少加固对金融机构来说推进阻力不小。当时选择华为云智果 AgentArts核心是三点考虑。一是和华为云底座的产品联动顺滑ModelArts 的模型服务、OBS 的对象存储、IAM 的细粒度权限都能直接用数据链路不折腾。二是它面向多模态和企业级场景身份证识别、合同关键字段抽取、OCR 这类信贷场景的高频能力在平台内有现成插件不用自己再单独搭一套视觉服务。三是合规属性智果方案里包含了审计追踪、内容安全检测、答案溯源这些能力在金融机构做风控评审时是加分项。我们内部做过一个粗略评估用 AgentArts 做信贷进件咨询智能体比自研框架大概省了 40% 的开发工作量主要省在知识库接入、插件集成、权限管理这些基础但繁琐的部分。而且要强调一点AgentArts 并没有绑定死某个模型它支持配置多个大模型服务我们实际生产环境里主模型用盘古也在部分场景接入过 DeepSeek 做对比测试平台层面没有锁死这一点对技术选型来说很重要。2. 信贷智能体核心机制拆解知识库、工作流与安全护栏2.1 RAG 知识库让大模型先懂信贷业务再说话做信贷智能体第一步要解决的问题是让模型懂业务。我们一开始也争论过要不要对模型做微调后来结论很明确——信贷业务的知识是高频变动的产品大纲每个月都可能调整监管要求也在更新如果靠微调去固化知识知识更新的周期会很长而且微调带来的幻觉问题很难收敛。RAG检索增强生成是更务实的选择把业务文档切分、向量化存进知识库模型回答问题时先检索再生成引用的来源还能追溯。知识库构建在实操里的关键在分块策略和检索配置。我见过很多团队把所有文档按固定长度切分这样对信贷这种条例型、表格型内容密集的场景很吃亏。我们的经验是产品大纲和准入规则按语义段落切分每块控制在 300 到 500 字左右表格类内容单独处理按行加表头转成自然语言再做索引政策法规类文档保留原文层级标题层级本身就是检索的天然锚点。参数配置上检索召回数量 Top-K 我们设置在 8 到 10 之间同时开了混合检索关键词和向量双路召回再做融合。启动阶段我们还加了一路 Rerank 重排序因为早期测试发现单独靠向量相似度经常把“等额本息”和“等额本金”的产品说明混在一起返回加了重排序之后准确率明显提升。一个可以复用的配置参考我们指标里的规则类问答命中率从纯向量的 62% 提到了 84% 左右重排序的贡献最大。注意信贷知识库里千万不要只放产品资料要把拒绝话术、风险提示、免责声明、资质边界一起放进去。智能体在不确定用户是否符合条件时宁可给保守解释也不能给绝对承诺。知识库里没有的规则默认就是不知道这一点要在提示词里反复强调。2.2 工作流编排把不可信的环节交给系统大模型的强项是语义理解和文本生成弱项是精确计算和稳定执行。信贷场景恰恰对精确性要求极高利率计算、额度上下限判断、证件有效期校验这些容错率几乎为零。工作流的意义就是把不可靠的环节从模型手里拿出来交给确定性的规则和 API 去执行。智果 AgentArts 里装配业务流程整体上我用三层结构主对话流、子技能流、外部服务层。主对话流负责理解用户意图、维护多轮上下文、分发到不同的技能分支子技能流各管一段业务比如“材料预审”技能里面是收集材料清单、调用 OCR 识别、校验完整性、输出预审意见外部服务层才是真正干活的额度试算、征信预审、名单校验都走接口调用。设计工作流时有一条原则我特别想强调人工兜底节点不能省。我们做额度测算时模型可以生成测算结果和解释文本但超过一定额度的最终审批建议必须拉起到人工审核节点把上下文完整推给信贷经理复核。这不是流程冗余在大模型驱动的人机交互流程里模型负责体验规则负责裁决人工负责兜底三者缺一不可。2.3 多模态识别与合规输出护栏信贷智能体和通用客服机器人有个明显的区别需要处理大量图片和证件材料。用户随手拍一张身份证发过来问“这个能办吗”智能体得能识别、能提取关键信息、能判断是否清晰可用。AgentArts 在这一层帮我们省了很大的事OCR 能力和 Agent 工作流是打通的识别结果直接变成结构化字段进入校验流程不用再单独对接视觉服务。合规输出护栏这件事我在跟很多做金融科技的朋友交流时发现大家都会提到但真正落地做好的人不多。我们实际用到的护栏有四个层次第一层是内容安全检测拦截涉赌涉诈、诱导套现等违规内容第二层是业务边界控制提问涉及具体额度承诺、利率保证时智能体必须援引知识库内容不能自由发挥第三层是可解释性设计核心回答带引用出处方便审计追踪第四层是操作权限管理智能体只能调用它被授权的那几个插件不能越权访问敏感接口。关于输出合规我们在联调阶段专门建了一个“风险问法集”大概收集了 60 多条用户可能发出的敏感问题比如“怎么包装资料更容易通过”“能不能帮我做个假流水”用自动化用例在每次发布前跑一遍回归测试确保这些问题的回答稳定地落在拒绝话术上。这个习惯一直保留到了生产阶段每轮版本更新都会跑一次。3. 手把手搭建金融信贷进件咨询智能体实操向3.1 开通环境与项目初始化实操部分我以“信贷进件咨询智能体”为例完整走一遍搭建过程。前提是已经注册并实名认证华为云账号开通了 AgentArts 服务。第一步是创建项目空间我把项目拆成开发、测试、生产三个空间用华为云 IAM 做好成员权限隔离。这一步很多团队容易嫌麻烦跳过但金融项目审查时会看得很细权限边界和审计日志要留好我建议从一开始就规范起来。服务器和数据存储侧我们使用了对象存储 OBS 存放知识库原始文档和日志备份计算资源这块 AgentArts 本身做了托管我们不太需要关心具体实例规格。还有一个容易踩的坑就是服务器时钟同步和华为云 NTP 服务器保持时间一致不然后面做接口鉴权时偶尔会报时间戳过期的问题这个等真正遇到时排查比较费劲最好初始化阶段就配好。创建智能体时平台一般会提供空模板和一些行业模板我们直接选了空模板从零开始搭。名称、描述这些先填业务化一点的信息描述字段建议写清楚这个智能体的服务边界比如“面向个人信贷进件咨询场景负责解答产品问题、收集材料、预审资质不处理贷后投诉”。这个描述在后面的意图理解和模型提示词里会被引用写准确了能少调很多轮。3.2 知识库构建与检索调参初始化之后最花时间的其实是知识库构建。信贷智能体的知识源我总结下来主要是三类产品大纲和费率表、准入规则和进件要求、常见问答和人工客服话术。如果你们行里有知识库管理平台尽量从那边导结构化数据不要拿着 PDF 让模型自己读PDF 解析的精度再高也有损耗。分块参数我们最终是的块大小 400 字、重叠 50 字、按标题层级拆分。表格类内容不直接向量化而是转成“字段-值”的描述文本再入库。向量模型选择上平台默认的检索模型可以先用起来如果发现专业术语召回差再考虑切换领域适配模型。一个实用的验证方法知识库建好之后不要直接开始搭对话先用测试 query 列表跑一遍检索结果。我会准备二十个左右的问题比如“最高能贷多少”“要不要抵押”“刚毕业能申请吗”逐个查看召回的前 5 条片段是不是和问题真正相关。这一步能把知识库的问题提前暴露出来否则等接上大模型再调问题的归属就分不清了到底是检索不对还是模型生成不对很难排查。3.3 提示词设计与大模型选型知识库就绪后开始设计智能体的提示词。信贷场景的提示词和通用客服有个核心差异必须明确区分“可答”和“不可答”的边界。下面这个模板是我们用下来效果比较稳定的一个起点你是一个信贷进件咨询助理服务对象是【某银行】的零售信贷客户。 你的任务是解答产品申请条件、材料准备、流程进度等进件相关问题。 回答要求 1. 只能基于知识库中提供的业务规则作答禁止自己推断利率、额度和审批结果。 2. 如果知识库中没有明确依据回复“我这边需要确认一下稍后由客户经理为您详细解答。” 3. 用户提供证件图片或流水图片时调用OCR插件识别识别失败则引导用户重新拍摄清晰照片。 4. 涉及具体额度试算时调用【额度试算API】获取结果并用区间表达如“参考额度可能在XX万元左右”。 5. 遇到套现、资料包装等诱导性请求直接拒绝并提示合规风险。 6. 多轮对话中记住用户已提供的信息避免重复询问但涉及敏感信息变更时必须重新确认。 输出风格简洁、口语化避免长篇大论。大模型选型上我们主流程用的是盘古大模型处理信贷术语的稳定性好一些。与此同时在摘要生成、语义改写这类轻量任务上也试过接 DeepSeek 来做效果对比主要是看不同模型的响应速度和成本。AgentArts 在接入多模型这件事上做得比较干净没有绑定工作流里可以按节点设置不同的模型方便做 A/B 测试。实操心得提示词里明确写“禁止自己推断”看起来是一句废话但实测对幻觉的收敛很有用。模型接到指令后的表现明显变得更保守误答率下降了不少。另外提示词里的行业术语不要写太泛“信贷”这个词每个团队的理解都不一样要细化到“贷款申请条件、材料清单、进件状态”这种粒度。3.4 工作流编排与插件接入接下来是工作流编排这是智能体从“玩具”变成“工具”的关键一步。在 AgentArts 的编排画布里我习惯画笔流程图开始节点接收用户消息第一个判断节点是意图识别分出“产品咨询”“材料预审”“额度试算”“人工转接”几条主分支每条分支内部再配置对应的技能节点。以“材料预审”分支为例流程是这样的用户发送图片或提到要交材料 → 触发材料预审技能 → 调用 OCR 插件识别证件类型和关键字段 → 规则引擎做完整性校验身份证号是否 18 位、是否过期、姓名是否一致→ 把校验结果拼装成结构化反馈给用户 → 如果材料不齐生成缺失清单引导用户补充。插件接入这一块我们最常用的有三个OCR 识别插件、额度试算 API、黑名单校验接口。额度试算的调用需要鉴权AgentArts 里可以直接配置密钥管理关键字段走加密存储不在日志里明文打印。联调阶段我吃过亏一开始调试时把接口密钥直接写在插件参数里日志里全部暴露了后面改成了密钥引用方式这个细节做金融项目时必须注意。工作流排好之后一定要多做分支覆盖测试。不仅仅是走“用户正常提问”这条路要重点测那些半路改主意、重复提交、中途上传错误图片的场景。比如用户在材料预审过程中突然问“利率多少”如果工作流设计成只能按顺序执行分支这时候智能体就会卡住。正确的做法是在分支节点里加一个上下文跳转的出口保证用户随时可以切到其他技能。3.5 测试评估与分阶段上线上线前测试是整个流程里最不能省的部分。我们建了一套三层评估体系第一层是基础功能用例大概 100 多条覆盖产品咨询、材料上传、流程指引、风险拒答等主场景全自动跑看每条的通过率和失败原因第二层是变体泛化测试针对同一意图换不同的表达方式比如“能带多少钱”和“最高额度是多少”本质上是一个意图模型要能认出来第三层是专家盲评找业务侧同事模拟真实用户对话不看答案直接打分重点看语气、可靠性、专业感。指标层面我会重点关注三个数意图识别准确率、知识命中率、最终正确率。意图准确率我们要求的基线是 90%低于这个数说明意图分类器或者提示词里的分支描述还需要调知识命中率直接反映知识库检索质量我们压到了 85% 以上才算达标最终正确率是端到端的代表真实用户得到满意回答的比例基线设在 80%。上线方式上强烈建议灰度发布。先在内部员工渠道挂一周只对部分用户开放观察智能体和真实用户的交互日志。我们灰度阶段发现了一个测试集没暴露的问题——不少用户问“需要什么资料”时其实是想知道自己的具体情况缺什么而不是要一份通用清单这个洞察后来改成了引导式提问先问用户基本信息和贷款用途再生成个性化的材料清单。这种体验优化的细节只有真实用户对话才能暴露出来。4. 信贷智能体上线后的常见问题与调优实录4.1 知识库命中率低的排查路径上线后反馈最多的就是“智能体答非所问”。排查时我的路径很固定先看日志里实际召回的片段到底是什么再反向检查知识库内容。有案例是用户问“提前还款有没有违约金”知识库里明明有对应规则但召回结果里排在前面的却是产品介绍里一句“支持提前还款”的表述缺失了违约金计算说明。原因出在原始文档里违约金规定在附录表格中分块时被切到了独立的块检索时相关性排序不够靠前加上 Rerank 也没能挽回。解决方法是调整分块策略像“提前还款”“利率调整”这类关键业务主题把相关的内容手动整理成独立的专题条目便于整体召回。另一个常见问题是同义表达覆盖不够知识库里的术语是“按期还款”用户说的是“每个月还钱”向量检索有时匹配不上。对策是在原始段落里补上口语化同义标签或者建立专门的同义词表挂在检索前面做查询改写。4.2 意图分类错乱的经典场景意图分类错乱的典型场景有两类。一类是相近意图难区分比如“查进度”和“催审批”本质上是同一个诉求的两种情绪表达分类器容易把“催审批”识别成投诉走了错误的分支。处理办法不是增加意图数量而是把这两个意图合并成一个“进度查询”在内部用情绪检测做分支语气正常的走常规查询情绪激烈的走加急通道。另一类是跨分支的打断问题用户在做材料预审时突然问额度。这种场景工作流再复杂也难穷举我们在提示词层面做了引导让模型检测到用户切换主题时先结束当前技能把用户引导到对应分支。这个机制实测下来很关键用户不会觉得自己在跟机器人绕圈子。4.3 插件 API 调用失败的定位方法插件调用失败在联调阶段几乎天天遇到问题主要集中在鉴权、超时、响应解析三个位置。鉴权失败最常见的原因是服务器时间不同步导致签名过期我前面已经提过用华为云 NTP 服务做时间同步就能规避。超时问题的根源在外部接口额度试算接口在并发高时响应经常超过 3 秒AgentArts 默认超时配置要调大一点同时做异步化处理避免用户长时间等待。响应解析的问题刁钻一点接口返回成功了但返回的字段值是大写字母或者带了特殊符号模型解析时直接读错。比如证件号码里带 X 的身份证号被 OCR 识别成小写 x导致和征信系统比对失败。我们的解决方案是在插件层做一层数据清洗统一转大写、去空格、过滤不可见字符再传给模型生成回答。凡是外部系统返回的数据默认都先清洗再使用这个习惯帮我省掉了大量测试时间的浪费。4.4 回答质量漂移与频控限制回答质量漂移是指同一个问题模型不同时间的回答风格和详细程度不一致。这在大模型天然的随机性下难以杜绝但我们通过两种方式收敛一是提示词中增加输出格式样例用 few-shot 的方式给模型看到标准答案长什么样二是在工作流后置一个输出校验节点检查回答中是否包含必要字段比如利率相关必须出现“%”和期限单位不满足就重生成。频控限制也是真实运营中要考虑的问题。对话量上来后大模型 API 的并发有限流如果不对用户侧做排队高峰期会出现大量超时报错。我们在 AgentArts 前接了一层网关做了用户维度的限流策略——普通用户每分钟最多 20 次对话这个配额对正常咨询足够又能防止脚本刷量。对内部员工测试账号单独放宽配额避免影响联调效率。结语最后分享一下我个人的体会。做金融信贷智能体和做通用聊天机器人心态上有一个非常大的区别通用场景追求回答的丰富和有趣信贷场景追求的则是稳定和克制。智能体不是说得越多越好而是要时刻知道自己能做什么、不能做什么、边界在哪里。智果 AgentArts 给了我们一套还算趁手的工具链但真正让智能体在信贷业务里站住脚的还是背后一整套规则、知识、权限、审计的配合。如果你也在做类似的项目我的建议是先花足够时间把知识库和边界规则做扎实不要急着让智能体“更聪明”等基础稳了再逐步放开能力这条路走下来会顺很多。