金融信贷这个行业有个特点业务规则密集、合规要求严、数据敏感度高但同时又存在大量重复性判断工作。过去两年我跟不少做信贷系统的团队聊过大家普遍的痛点是风控规则越堆越多审批流程越拉越长一线业务人员被各种制度文件、产品细则、合规条款淹没真正花在客户身上的时间反而被压缩。华为云智果 AgentArts 这套 AI 智能体平台恰好切中了这个场景——它不是让你从零训练一个大模型而是提供一个智能体的编排、工具调用、知识库挂载和流程编排能力把信贷业务里那些查规则、对条款、算额度、写报告的活儿交给智能体去跑。这篇内容我会围绕金融信贷 AI 智能体的实战搭建展开从平台能力边界、场景拆解、工作流设计、知识库构建、工具接入到上线后的调优把整个链路讲透。适合正在做信贷系统智能化改造的研发、产品以及想了解 AI 智能体在垂直行业怎么落地的技术同学。1. 为什么金融信贷场景适合用智能体而不是纯大模型1.1 纯大模型在信贷业务里的三个硬伤很多人第一反应是信贷问答嘛接个大模型 API 不就行了。我实测下来纯大模型直接上信贷场景至少有三个绕不过去的坑。第一个是规则幻觉。信贷产品的利率、期限、准入条件、征信要求这些是硬性规则错一个数字就是合规事故。大模型的概率生成机制决定了它会编——你问它某产品的最高额度它可能给你一个看起来合理但完全错误的数字。这不是模型不够强的问题是架构问题规则类知识必须走检索不能靠模型记忆。第二个是数据时效。信贷政策调整频繁今天降准明天调息产品细则可能一周一变。纯大模型的训练数据有截止日期你没法让它实时知道最新的产品政策。而智能体可以挂载知识库知识库更新了智能体的回答就更新了。第三个是流程缺失。信贷业务不是单轮问答是识别意图→查询客户资质→匹配产品→计算额度→生成审批意见→输出报告这样一条链路。纯大模型只能做其中一环智能体的价值在于把多环节串起来每个环节调用不同的工具和数据源。提示判断一个场景该不该用智能体有个简单标准——如果这个任务需要查外部数据按规则判断多步骤执行那智能体就是对的如果只是开放域闲聊或创意生成纯大模型更划算。1.2 AgentArts 在信贷链路里扮演什么角色华为云智果 AgentArts 的定位是智能体开发与运行平台它提供的能力可以拆成四层最底层是模型接入层支持多种大模型往上是知识库层负责文档解析、向量化、检索再往上是工具与插件层让智能体能调用外部 API最上面是编排层用工作流把意图识别、知识检索、工具调用、结果生成串起来。放到信贷场景里这四层分别对应模型层负责语言理解和生成知识库层存放产品细则和合规制度工具层对接核心系统的客户查询和额度计算接口编排层定义审批流程的逻辑。这个分层很重要因为它决定了你后续排查问题时该往哪一层找——回答不准先查知识库调用失败先查工具配置流程走不通先查编排逻辑。1.3 信贷智能体的能力边界要提前划清我见过不少团队一上来就想做全自动审批结果踩了一堆坑。这里必须说清楚智能体在信贷场景里适合做辅助决策不适合做最终决策。它可以帮你快速检索规则、初步匹配产品、生成审批意见草稿、整理尽调报告但最终的授信决策必须有人工复核环节。原因有两个一是监管要求信贷决策需要可追溯、可解释智能体的推理链路虽然可以记录但责任主体必须是人二是模型能力边界智能体在处理边界案例、异常情况时判断力还不如有经验的信贷员。把智能体定位成超级助理而不是自动审批员这个心态摆正了后面的设计才不会跑偏。2. 信贷智能体的场景拆解与优先级排序2.1 从高频低风险场景切入最稳信贷业务链条很长从贷前营销、贷中审批到贷后管理能塞智能体的地方很多。但我的建议是先做高频、低风险、规则明确的场景。什么叫高频低风险就是每天发生很多次、做错了也不会造成重大损失、判断标准相对清晰的任务。按这个标准排下来优先级最高的是三类产品咨询问答客户经理天天问产品细则、制度条款检索合规和审批人员查制度、尽调报告辅助生成客户经理写报告耗时最长。这三类的共同点是知识密集、重复度高、容错空间相对大。而像额度终审、风险定价这种高风险决策前期不要碰。2.2 三类核心场景的具体拆解产品咨询问答客户经理在展业时经常需要确认这个客户能不能做某产品某产品的准入条件是什么。传统做法是翻产品手册或者问产品经理效率低。智能体可以做到识别客户经理的问题意图检索对应产品的最新细则结合客户的基本资质给出初步判断。注意这里给的是初步判断最终还是要人工确认。制度条款检索信贷业务涉及的制度文件动辄几百页合规人员查一个条款要翻半天。智能体可以把制度文件向量化支持自然语言检索比如小微企业贷款展期的条件是什么直接定位到具体条款并给出原文引用。这个场景的关键是引用可溯源回答必须带出处不能只给结论。尽调报告辅助生成客户经理做尽调要写大量报告很多内容是模板化的。智能体可以根据客户基本信息、财务数据、征信情况自动生成报告框架和初稿客户经理在此基础上修改。这个场景能显著提效但要注意生成内容必须标注AI辅助生成需人工核实。2.3 场景优先级评估表场景发生频率风险等级规则明确度建议优先级产品咨询问答极高低高P0制度条款检索高低高P0尽调报告辅助中中中P1客户资质初筛高中高P1额度初步测算中中高高P2授信终审决策低极高中暂不做这张表是我实际项目里用过的评估框架四个维度打分后综合排序。注意规则明确度这一列很关键——规则越明确智能体越容易做对规则模糊的场景智能体容易给出模棱两可的答案反而增加人工负担。3. 用 AgentArts 搭建信贷问答智能体的完整流程3.1 知识库构建文档处理比模型选择更重要很多人把精力花在选模型上但我实测下来知识库的质量对最终效果的影响远大于模型选择。信贷知识库构建有几个关键动作。第一步是文档清洗。信贷制度文件往往是 Word 或 PDF里面夹杂大量表格、页眉页脚、修订标记。直接扔进去向量化检索效果会很差。我的做法是先用脚本把文档转成结构化文本去掉页眉页脚和无关标记表格单独处理成 Markdown 格式。这一步偷懒后面检索就会各种答非所问。第二步是分块策略。信贷文档的分块不能简单按字数切要按语义单元切。一个完整的条款是一个块一个产品的准入条件是一个块。块太大检索不精准块太小上下文不完整。我的经验值是每块 300 到 500 字同时保留条款编号作为元数据方便检索后定位原文。第三步是元数据标注。每个知识块要打上标签属于哪个产品、哪个制度、生效日期、适用范围。这些元数据在检索时可以用于过滤比如只检索2024年生效的小微企业产品相关的内容。# 知识块元数据标注示例结构 knowledge_chunk { content: 小微企业贷款展期条件借款人经营正常无欠息..., metadata: { doc_type: 制度文件, product_line: 小微企业贷款, effective_date: 2024-01-01, clause_id: 第三章第十二条, risk_level: normal } }3.2 意图识别节点的设计要点智能体接到用户问题后第一步是判断用户想干什么。信贷场景的意图分类不用太细我一般分五类产品咨询、制度查询、资质判断、报告生成、闲聊兜底。意图识别可以用小模型做分类也可以用大模型做 few-shot 判断。这里有个坑意图识别不要追求百分百准确要设计兜底路径。用户的问题可能跨多个意图或者表述模糊。我的做法是设置一个置信度阈值低于阈值就走澄清流程反问用户您是想咨询产品条件还是查询制度条款而不是硬猜。意图识别的 prompt 设计也有讲究。不要只给意图标签要给每个意图配上典型问法和边界说明。比如产品咨询要说明是问产品本身的条件而资质判断是问某个具体客户能不能做这两个容易混。3.3 检索增强生成在信贷问答里的参数调优检索增强生成RAG是信贷问答的核心。AgentArts 的知识库检索支持调整 top-k、相似度阈值等参数。我的调优经验是这样的top-k 不要设太大3 到 5 比较合适。设太大检索回来的内容里混入不相关条款模型容易被干扰设太小可能漏掉关键信息。相似度阈值我一般设在 0.7 左右低于这个值的检索结果宁可不要让模型基于已有信息回答或者走兜底。还有一个关键参数是重排序。AgentArts 支持对初步检索结果做重排序用更精细的模型重新打分。信贷场景里这个很有用因为很多条款表述相似但适用范围不同重排序能把最相关的排到前面。注意RAG 调优没有万能参数必须用真实业务问题做测试集反复验证。我一般会准备 50 到 100 个真实问题覆盖各类场景每次调参后跑一遍看准确率变化。3.4 回答生成环节的合规约束信贷智能体的回答生成必须加约束不能让它自由发挥。我的做法是在生成 prompt 里明确几条规则只基于检索到的知识回答检索不到就说未找到相关条款回答必须引用条款出处涉及具体数字的必须原文引用不能改写不确定的地方要明确标注。这几条约束看起来简单但能挡掉大部分合规风险。特别是检索不到就说不知道这条很多团队为了体验好让模型硬答结果编出错误条款这是大忌。4. 工具调用让智能体真正连上信贷业务系统4.1 哪些能力必须做成工具而不是塞进知识库知识库适合放静态的、文本类的知识但信贷业务里有很多动态的、需要实时查询的能力这些必须做成工具。判断标准很简单数据会变、需要计算、需要访问外部系统的都做成工具。具体到信贷场景至少这几类要做成工具客户信息查询从核心系统拉客户基本信息和征信、产品匹配根据客户资质匹配可做产品、额度测算按规则计算初步额度、利率查询实时利率、报告模板填充把数据填进报告模板。这些能力塞进知识库是没用的因为知识库是静态文本没法做实时计算和查询。4.2 工具接口的入参出参设计工具接口设计有个原则入参要少而明确出参要结构化。入参太多模型容易填错出参太随意模型不好解析。以客户信息查询工具为例入参只需要客户 ID 或身份证号不要让它传一堆筛选条件。出参用 JSON 结构字段命名清晰比如 customer_name、credit_score、existing_loans 这样。模型解析结构化出参的准确率远高于解析自然语言。{ tool_name: query_customer_info, input: { customer_id: C12345678 }, output: { customer_name: 张三, credit_score: 720, existing_loans: 2, overdue_records: 0, monthly_income: 15000 } }4.3 工具调用的异常处理与降级策略工具调用一定会失败——接口超时、数据缺失、权限不足各种情况都有。智能体必须有异常处理和降级策略不能一失败就整个流程卡死。我的做法是给每个工具配一个降级方案。客户信息查询失败降级为提示用户系统暂时无法获取客户信息请稍后重试或手动查询额度测算失败降级为只给规则说明不给具体数字。关键是降级后要明确告知用户当前状态不能让用户以为拿到的是完整结果。还有一个细节工具调用的超时时间要设置合理。信贷核心系统的查询接口可能比较慢超时设太短会频繁失败设太长用户体验差。我一般设 5 到 8 秒超过就走降级。4.4 多工具协同的编排逻辑复杂场景需要多个工具协同。比如判断某客户能否做某产品并测算额度需要先查客户信息再匹配产品再测算额度三步串行。AgentArts 的工作流编排支持这种串行和并行逻辑。这里的设计要点是明确工具间的依赖关系和数据传递。第一步的输出要能作为第二步的输入字段要对齐。我见过因为字段名不一致导致数据传不过去的情况排查半天才发现是命名问题。建议在编排前先画一张数据流转图把每个节点的输入输出列清楚。5. 上线后的效果评估与持续调优5.1 信贷智能体的评估指标怎么定智能体上线不是终点是起点。评估指标要分两层技术指标和业务指标。技术指标包括意图识别准确率、检索命中率、回答准确率、工具调用成功率、平均响应时间。这些指标反映系统健康度。业务指标包括问题解决率用户问题是否被解决、人工转接率多少问题需要转人工、用户满意度、单次交互节省时间。这些指标反映业务价值。我的经验是技术指标里最该盯的是回答准确率和人工转接率。准确率低于 85% 就要排查知识库和检索转接率高于 30% 说明智能体覆盖的场景不够或者回答质量不行。5.2 用真实 badcase 驱动迭代调优最有效的方法是收集 badcase。每次用户反馈答得不对或者转人工都要记录用户问了什么、智能体答了什么、正确答案是什么、错在哪一环。badcase 分析下来问题分布大概是这样的知识库缺失或过时占 40%检索没命中占 25%意图识别错误占 15%工具调用失败占 10%生成环节出错占 10%。这个分布说明大部分问题出在知识库和检索而不是模型本身。所以迭代重点应该放在知识库维护和检索调优上而不是频繁换模型。5.3 知识库的持续维护机制信贷知识库不是建一次就完事必须持续维护。我的做法是建立三条维护通道一是产品/制度更新时同步更新知识库这个要跟业务部门建立联动机制二是定期比如每周跑一遍测试集发现准确率下降就排查三是收集用户反馈把新出现的问题补充进知识库。维护知识库最麻烦的是版本管理。同一个产品可能有多个版本的政策检索时必须用最新版本。我的做法是给每个知识块打生效日期和失效日期检索时自动过滤掉失效的。这个机制看起来简单但能避免很多用了旧政策的错误。5.4 从单智能体到多智能体协作的演进单智能体跑顺之后可以考虑多智能体协作。比如产品咨询一个智能体、制度查询一个智能体、报告生成一个智能体由一个调度智能体根据意图分发给对应的专业智能体。多智能体的好处是每个智能体可以专注自己的领域知识库和 prompt 都可以更精简准确率更高。但代价是复杂度上升调度逻辑、上下文传递、错误处理都要重新设计。我的建议是单智能体能满足需求就不要上多智能体等单智能体确实遇到瓶颈了再演进。6. 实操中踩过的坑和几条硬经验6.1 知识库文档格式的坑最开始我们直接把 PDF 扔进知识库结果检索效果惨不忍睹。排查发现 PDF 里的表格被解析成了乱码条款编号丢失页眉页脚混进正文。后来改成先转 Markdown 再入库效果立刻好转。还有一个坑是扫描版 PDF。有些老制度文件是扫描件直接解析出来是空白或者乱码。这种必须先做 OCR而且 OCR 后要人工校对因为信贷文件里的数字错一个就是大问题。6.2 模型选择的实际考量AgentArts 支持多种模型选哪个我的经验是意图识别和检索可以用小模型回答生成用大模型。意图识别任务简单小模型够用还快回答生成需要理解和组织语言大模型效果明显更好。全部用大模型成本高、响应慢全部用小模型回答质量又不够。另外要注意模型的上下文长度。信贷问答经常需要把多个条款一起放进上下文上下文太短的模型放不下。选模型时这个参数要重点看。6.3 提示词工程的信贷特化技巧通用提示词技巧网上很多我说几个信贷场景特有的。第一在系统提示词里明确角色和边界比如你是一名信贷业务助理只回答信贷相关问题不提供投资建议。第二给出回答格式模板让模型按固定格式输出方便后续解析。第三加入反例告诉模型哪些回答方式是错误的比如不要编造条款编号。提示词不是写一次就完事要跟着 badcase 迭代。我一般每两周 review 一次提示词把新发现的问题补充进去。6.4 上线节奏的把控智能体上线不要一次性全量放开。我的做法是分三步先内部小范围试用比如一个业务团队收集反馈调优再扩大到多个团队观察稳定性最后才全量上线。每一步之间留出足够的观察期别急着推。灰度期间要重点盯人工转接率和用户投诉。转接率高说明智能体没接住场景投诉多说明回答质量有问题。这两个指标稳定了再考虑扩大范围。6.5 合规审查不能省信贷是强监管行业智能体上线前必须过合规审查。审查重点包括回答是否有误导性、是否泄露客户信息、是否有不当承诺、引用条款是否准确。我们当时的做法是让合规部门参与测试他们提的问题往往比技术人员更刁钻能发现很多隐藏风险。还有一点智能体的所有交互要留痕。谁问了什么、智能体答了什么、调用了哪些工具、检索了哪些知识都要记录。这既是合规要求也是后续调优的数据来源。7. 关于成本与性能的平衡7.1 智能体运行的主要成本构成智能体的成本主要来自三块模型调用费用、知识库存储和检索费用、工具调用带来的系统资源消耗。模型调用是大头尤其是回答生成环节每次都要调大模型。控制成本的关键是减少不必要的模型调用。比如意图识别用小模型简单问题直接走规则不走模型检索结果为空时直接返回兜底话术不调生成模型。这些优化能省下不少。7.2 响应速度的优化思路信贷场景对响应速度有要求客户经理等着答案呢等太久体验就差。优化思路有几个一是并行化能并行的工具调用和检索并行执行二是缓存高频问题的答案缓存起来三是流式输出让用户先看到部分内容减少等待感。实测下来一个设计良好的信贷问答智能体平均响应时间能控制在 3 到 5 秒复杂场景多工具调用可能到 8 到 10 秒。超过 10 秒用户就会明显感觉卡顿需要优化。7.3 高并发场景的应对如果智能体要服务大量客户经理高并发是必须考虑的。AgentArts 本身有弹性能力但工具调用对接的核心系统可能扛不住高并发。我的做法是给工具调用加限流和队列避免把核心系统打挂。同时准备降级方案核心系统压力大时智能体降级为只提供知识检索不做实时查询。这块的经验是智能体的性能瓶颈往往不在智能体本身而在它对接的外部系统。设计时要把外部系统的承载能力考虑进去。8. 从信贷场景延伸出去的通用方法论8.1 垂直行业智能体的通用搭建框架信贷智能体的搭建思路其实可以迁移到其他垂直行业。核心框架是知识库打底、工具做手脚、编排做大脑、评估做眼睛。知识库解决知道什么工具解决能做什么编排解决怎么串起来评估解决做得好不好。这个框架放到医疗、法律、政务等知识密集行业都适用。区别在于每个行业的侧重点不同。信贷重合规和实时数据医疗重准确性和隐私法律重条款引用和逻辑推理。搭建时要根据行业特点调整知识库结构、工具设计和约束条件。8.2 智能体与人工的协作边界设计智能体不是替代人是增强人。协作边界的设计原则是智能体做它擅长的检索、计算、初稿人做人擅长的判断、决策、异常处理。具体到信贷智能体负责信息收集和初步分析人负责最终判断和客户沟通。这个边界不是固定的随着智能体能力提升可以逐步扩大它的职责。但扩大的前提是评估数据证明它在扩大后的范围内表现可靠。不要凭感觉扩大边界。8.3 后续可以探索的方向信贷智能体跑顺之后有几个方向可以探索。一是多模态比如识别客户提供的财务报表图片自动提取数据。二是主动服务智能体不只被动回答问题还能主动提醒客户经理某客户的贷款快到期了某产品政策变了。三是跨系统协同智能体打通更多业务系统实现更复杂的自动化流程。不过这些都要在基础能力扎实之后再考虑。我见过太多团队基础还没打好就追新功能结果哪个都没做好。稳扎稳打把问答和检索做扎实再往上叠能力。我在实际项目里最大的体会是金融信贷智能体的成败八成取决于知识库和业务理解两成才是技术实现。技术同学容易陷入调模型、调参数的细节但真正决定效果的是你有没有把业务规则吃透、把知识库建对。多跟业务人员聊多收集真实问题比闷头调参有用得多。