做金融信贷场景的AI智能体不是光接一个大模型API就完事。去年年底我带着团队在华为云AgentArts上把一套信贷审批辅助和贷前咨询的智能体从原型推到了生产整个过程踩了不少坑也沉淀下来一套可复用的搭建方法。这篇就围绕这次实战把AgentArts在金融信贷这类强合规、强流程场景里的能力边界、搭建流程和调优经验完整梳理一遍给正在做智能体落地的同行一些参考。先说结论AgentArts这类一站式智能体开发平台解决的不是模型能力问题而是把模型安全地编排进业务流程的问题。金融信贷恰恰是对业务流程、数据安全、可解释性和人工兜底要求极高的领域单纯靠提示词去调一个大模型根本无法满足合规审计的要求。AgentArts把知识库、插件、工作流、评估调试这些环节集合在一起才让智能体真正具备企业级落地的条件。1. 为什么信贷场景需要智能体以及为什么选AgentArts1.1 信贷业务里那些低效又必须做的事情做信贷的人都有体感一个客户从提交申请到放款中间有大量重复性工作消耗着客户经理的时间。比如客户反复问同一个产品的准入门槛、利率区间、还款方式比如客户上传的收入证明、银行流水、征信报告需要人工逐项核对又比如审批环节初审人员要翻阅风控手册、政策文件把客户情况逐条对照规则。这些工作不是不能做而是做起来太慢而且人为判断容易出错。这些场景天然适合智能体介入因为它们有固定的流程、明确的规则、大量的文档知识最重要的是都配有人的审核节点。AI在这里不是替代决策者而是做一个阅读理解信息整理初步筛查的助手把需要人看的东西整理好、标识好压缩人的处理时间。1.2 AgentArts与其他方案的关键差异可能有人会说用LangChain不也能做吗自己在服务器上部署一套Dify或者开源的Agent框架也一样能干这些事。没错通用能力上大家差距不大但真正进入金融信贷场景时有几个问题是自建方案很难绕开的。首先是环境合规问题。银行、消金公司、助贷平台的IT环境审查非常严格自建开源框架意味着要自己维护一系列组件从模型网关到向量库到日志系统每一层都要过安全审计。AgentArts作为一个云上的托管平台底层的安全基线、通信加密、审计日志能力开箱即用省掉大量合规沟通成本。其次是生生态整合的问题。信贷业务跑在ESB、微服务、RPA、OCR等一堆系统上面AgentArts插件市场和华为云的相关服务比如OCR、搜索天然打通接插件比从零写一套工具调用框架要快得多。还有一点很实际AgentArts提供了可视化的Agent编排界面和效果评估工具。金融场景里业务人员和开发人员是两类人业务听不懂代码开发搞不清业务规则可视化编排至少让两边能坐下来对着一个流程图画框架、改分支协调成本低一大截。1.3 这次实战的最终目标我们最终交付的智能体覆盖三个具体场景贷前咨询智能助手面向客户的常见问题问答包括产品准入、利率、还款方式、材料要求回答必须引用最新政策文档禁止自由发挥。贷前材料预审助手面向客户经理的辅助工具识别客户上传的材料清单是否齐全对收入证明、工作证明做初步校验把缺失项和异常项标出来。审批辅助决策摘要面向审批人员把客户基本信息、征信摘要信息、材料审核结果、命中风险规则汇总成一份结构化摘要供审批人参考。这三个场景覆盖了信贷全流程里最耗人力的两个环节——客服重复问答和材料初审而且都不触碰最终放款决策的红线是智能体切入信贷场景最合理的第一步。2. 整体设计思路先把流程拆开再让Agent嵌入2.1 流程梳理是智能体设计的地基我们最初犯过一个错误急着在AgentArts上搭Agent搭到一半发现流程边界模糊Agent不知道该在哪个环节退出交给人工。后来我们重新做了一件事把信贷业务的核心流程画出来标注每个环节的输入、输出、责任人、耗时。这一步非常关键。最后梳理出的核心链路是客户咨询 → 意向登记 → 提交材料 → 材料初审 → 征信查询 → 风险评估 → 人工审批 → 放款 → 贷后管理。确定智能体切入点的原则有两条一是这个环节的输入是否标准化比如材料、文档、固定字段二是这个环节是否允许机器做初步处理、人工做最终决策。凡是可以标准判断但牵涉主观裁量的场景最适合智能体先做一遍预处理。2.2 Agent的三层能力架构在AgentArts上我们最终把智能体拆成了三层逻辑结构入口层负责意图识别和会话管理判断用户是来咨询的客户还是内部业务人员。任务层负责编排具体动作比如查知识库、调用插件做OCR识别、组装结构化输出。数据层负责对接各类数据源包括产品政策的知识库、客户系统数据、征信查询接口。这个三层结构带来的好处是每一层可以独立升级。政策文档变更时只更新知识库不影响对话逻辑新增一个审批系统的接口时只是换插件不需要改动意图识别的逻辑。2.3 用最小可行闭环起步不贪大做生物医药、做客服、做营销的智能体可以一上来就做大而全的助手但金融信贷不行——试错成本高、合规压力大。我们第一次上线只做了贷前咨询和材料预审两个功能审批辅助摘要放到第二个迭代再做。这个决策后来被验证是对的。最初的贷前咨询智能体回答质量并不高经过两轮知识库调优后才稳定下来如果同时上线三个功能调整起来会非常混乱。智能体项目上线速度不重要稳定性和可控性更重要一个功能一个功能推进每个功能跑稳了再接下一个。3. AgentArts实操从创建项目到工作流配置全记录3.1 项目创建与模型选择在华为云控制台找到AgentArts服务入口后创建项目的流程很简单填项目名选运行环境就完成了。比较重要的是模型选择环节。AgentArts支持多个模型选项包括华为云盘古系列模型、业界开源商用模型等。我们最终做了双模型配置面向客户的对话场景使用速度优先的模型控制在2秒内返回首字面向内部审批摘要场景使用推理能力更强的模型保证输出逻辑严谨、格式稳定。这个配置思路可以借鉴不要把所有场景都塞给一个模型。对话问答追求的是快、稳、不跑偏结构化分析追求的是准、深、有依据。两者需求不同用同一个模型两头都不讨好。3.2 工作流编排把Agent的思考过程显性化AgentArts的工作流编排是拖拽式的我们搭建的贷前咨询Agent主流程是输入节点接收客户消息。意图识别节点判断消息类别——产品咨询、利率咨询、材料咨询、转人工、闲聊。知识库检索节点根据意图检索对应分类下的政策文档。生成回答节点基于检索结果生成回复要求必须引用文档原文出处。兜底节点当意图识别置信度不足时回复已为你转接人工客户经理并生成工单。这个流程看似简单但有几个设计细节值得展开。知识库检索是按意图分域检索的。最开始我们用一个统一的向量索引检索全部文档结果客户问利率返回了几条产品准入的内容答非所问。后来在AgentArts里对不同文档做分类标签检索时按意图限定标签范围回答准确率立刻提上去了。生成回答时系统提示词里我们明确规定了禁止输出知识库之外的利率、额度、期限等数字信息所有数字必须来自检索到的文档如果检索结果为空直接说明无法回答。这相当于给大模型戴了一道紧箍咒——可以自由组织语言但关键数字必须是真实来源的。材料预审助手的工作流则偏重插件调用客户经理上传材料扫描件。OCR插件提取身份证、收入证明、银行流水中的关键字段。规则节点校验材料完整性身份证必须有、收入证明必须含单位盖章。生成校验结果清单标注每项材料的状态通过、缺失、待补充。OCR识别的字段准确性是这里的关键。盖过章的材料、倾斜拍摄的照片提取效果经常打折扣。AgentArts里OCR插件支持做字段校验对识别置信度低的字段打标记宁可标记存疑也不允许直接判为正常这是材料预审场景必须守住的原则。3.3 知识库构建文档处理比想象中重要信贷知识库的内容主要是产品手册、业务流程指引、风控规则说明、合规政策文件。这些都是存量文档整理起来是体力活但恰恰是智能体回答质量的命根子。AgentArts支持PDF、Word、网页等多种格式的知识库导入但导入之后不代表能用。我们把每份文档做了分段清洗表格型内容拆成独立段落防止向量化时表格和正文混在一起带编号的政策条文保留原文层级方便引用时给出精确条目版本过期的文件移到归档库不参与检索。这个过程非常枯燥但直接影响效果。第一版我们直接把几十份PDF原封不动导入结果向量检索出来的内容经常是截断的半句话。后来改成按文档逻辑重新分段合并回答引用准确率明显提升。知识库参数的调整也很讲究。AgentArts里可以配置检索返回条数和相似度阈值。信贷问答场景里回答宁可少给也不能给错所以相似度阈值我们调得比较高低于阈值的检索结果直接丢弃命中不到就触发兜底话术。同时我们把返回条数控制在一个适中数量既保证回答有足够上下文又避免引入太多不相关片段干扰模型。3.4 插件与工具接入打通业务闭环AgentArts的插件体系是另一个核心力量。除了平台预置的OCR、文本识别、图片理解等插件我们把内部的征信查询API封装成了自定义插件。封装自定义插件的要点有两条入参和出参要结构化定义。插件接收JSON格式的请求体返回JSON格式的结果第一步是定义清楚字段结构。我们定义了request_id、id_number、name作为入参返回credit_score、overdue_records、query_times等字段。错误码要有兜底策略。征信接口偶尔超时或返回异常插件里定义了对错误码的处理逻辑超时重试一次再失败就触发人工介入流程不能让Agent假装查询成功了。插件接入本身在AgentArts控制台里走几步就能完成但往往最花时间的是协调外部系统开放接口。这事没有技术难度却有大量的跨团队沟通。务实一点的做法是先把接口协议文档拿到手里插件本地调试通了再挂到平台上别在平台上反复试错。3.5 测试与效果评估别只看答得好不好AgentArts提供了评估测试工作台可以批量跑对话场景来检验效果。我们做的第一轮测试用了超过两百条真实客户咨询记录重点看三类指标意图识别准确率最初只有91%大部分错误集中在我能贷多少和每月要还多少这类相近表达上。回答引用准确率抽查回答中的数字信息是否与知识库原文一致这个指标必须做到100%即使漏答也不允许错答。兜底触发率理想情况是20%以内。如果兜底太多说明知识库覆盖不足太少说明可能回答了一些不该答的。第一轮测试结果并不理想答复中出现了知识库之外的虚构利率好在系统提示词里的禁止规则拦截了一部分。后续用评估数据反推动了知识库的补充和提示词优化意图识别通过增加few-shot示例从91%提升到了接近96%虚构输出也清零了。这个调优循环是整个智能体上线前质量最关键的保障。4. 金融信贷场景的红线合规与风控细节4.1 智能体只能做辅助决策不能做自动决策在所有金融信贷智能体项目中有一条红线绝对不能碰机器不能做最后的授信决策。智能体的输出只是参考信息审批权必须保留在持牌机构的人工审批人员手里。我们在AgentArts上做了一层硬约束审批摘要助手生成的结论里风险等级和建议方向只是参考标签审批系统里不会直接采信Agent的任何结论字段所有字段需要审批人手动确认后才生效。这种参考但不可直接执行的设定让整个项目在业务和安全评审时顺利很多。4.2 数据安全与隐私保护金融数据是敏感数据客户身份证号、手机号、收入资产信息一旦泄露后果是非常严重的。我们在方案里坚持了几个原则日志脱敏AgentArts的对话日志中身份证号、银行卡号、手机号、家庭住址等字段在日志展示时做掩码处理。最小化传输插件调用只传必要字段。比如征信插件只传姓名身份证号不需要传家庭住址。传输加密平台到云端接口之间的传输通道启用加密协议防止网络层数据泄露。这几个原则看似基础落地时跟运维、网络部门的沟通反而花了最多时间。金融机构的网络策略通常很严外部接口的域名要加白名单AgentArts承载的智能体在访问内网征信系统前还要过一层专线网关。这部分合规工作在项目排期里要预留至少一周不能压缩。4.3 可解释性与审计追溯信贷审批有一个特点出了问题是事后追责的所以每一步操作都要有迹可循。AgentArts的日志和Trace功能此时发挥了作用——每次Agent回答了什么、引用了知识库的哪些段落、调用了哪个插件、传入了什么参数都记录在案。这一点决定了金融智能体和普通聊天机器人本质的不同。普通聊天机器人回答错了话道歉就结束了金融场景回答错了利率哪怕是一句随口的话后面追责和客诉处理都非常麻烦。所以上线前我们把审计可追溯列为和回答准确性同等重要的考核项所有Agent的关键输出都会以结构化的方式留存备查。4.4 建立人机协作的话术边界智能体的话术设计也很讲究。机器人应当主动告知自己不是人工客服同时在用户情绪激动、投诉类问题出现时第一时间转人工。我们在系统提示词里规定涉及投诉、纠纷、征信异议等敏感话题时智能体不解释、不辩解直接转人工处理。这个边界画清楚之后客服团队对智能体的信任度大幅提升。5. 常见问题与排查技巧实录5.1 问题速查表现象可能原因排查方法问能贷多少返回利率内容意图识别混淆了额度类与利率类问题增加分类学习的示例将两个相近意图做区分回答出现文档之外的数字模型幻觉知识库证据不足时自由发挥了收紧提示词限制提高相似度阈值无证据时强制兜底检索到的文档对不上问题文档分块策略不合理表格或长文被切断调整分段策略按逻辑单元重新切分添加标签插件调用后结果为空外部接口超时或参数格式不匹配查看插件日志先本地重放接口确认参数结构客户问为什么我征信没过合规禁区不允许Agent输出审批细节系统提示词中明确规定转人工话术并发高峰期响应变慢对话场景模型推理速度与并发量不匹配拆分快慢模型高峰期启用平台弹性伸缩能力这是我们实测中最常出现的六个问题其中第二个和第五个是金融场景的核心难题。回答中的虚假数字会直接误导客户形成预期事后引发大量客诉而审批被拒原因的追问如果交由Agent解释极易触碰合规边界。这两个问题的处理原则就是宁可不答不可乱答。5.2 意图识别不准的系统性解法意图识别是入口环节它的准确率决定了下游所有环节的上限。实测中发现单纯靠大模型的零样本分类能力在信贷专业术语密集的对话里确实不够用。提升路径有三条一是增加更多分类示例。AgentArts里可以为每个意图补充少量经典问法比如每月还多少利率怎么算你们利息几个点归为一类。样本不需要很多关键是把变化形态教给模型。二是对相近意图做归并处理。比如我能贷多少和我的额度是多少从Agent角度可以归并为额度查询一个意图处理结果都指向额度规则只是话术表达不同。归并之后模型做分类的难度大大降低。三是增强追问机制。当意图置信度不高时Agent应当反问一句您是想要了解贷款额度还是我们目前可批的最高金额而不是猜测着回答。实测这是一个很好的缓冲手段把模型可能犯的错转换成了一次澄清对话。5.3 知识库检索质量的排查思路有不少团队在自建RAG时都会遇到搜不到或搜不准的问题向量检索按语义匹配但语义相似不等于业务相关。我们在排查时发现AgentArts的知识库检索质量很大程度上取决于文档切分粒度。切得太细语义上下文分裂检索出一个片段却看不清来龙去脉切得太粗多主题混在一个大块里向量表示变得模糊。我们的经验是按条目粒度切分比如一个产品政策的准入条件作为一段一条利率说明作为一段每条都保持语义的完整性和独立性。这样既不会信息错乱也方便回答时给出精确的引用定位。另外可以打开检索召回的内容去检查看它是否引用了与问题语义相关但业务上无关的段落。这类问题靠调参数是调不好的唯一的根治办法是重新清洗和切分知识库文档。5.4 低成本排查技巧先日志后模型遇到Agent回答异常先查的是AgentArts的运行日志看整个流程中检索命中了什么、插件返回了什么、大模型最终用了哪些上下文。90%以上的问题到这一步就能看到原因反射影射错在哪个环节。只有日志看起来一切正常但回答依然离谱时才怀疑到大模型自身的问题。这时把同样的输入在模型调试页单独跑一遍排除掉工作流干扰因素。记住一个原则先查流程再调模型。直接改系统提示词的解法经常越调越乱把问题的根子掩盖在工作流的某个环节里。6. 实测效果与投入产出复盘6.1 业务指标变化智能体上线两轮迭代后模型的一些数据开始展示真实效果贷前咨询场景约70%的常见问题由Agent直接解决无需转人工客户等待时间从原来的平均2分钟降到了10秒以内。材料预审场景一份材料预审从人工平均6分钟压缩到Agent完成初筛后人工复核平均1分钟同时材料完整性问题误判率没有明显上升。审批摘要场景审批人平均阅读材料时间缩短约30%因为摘要已经把客户的关键信息和风险点一条条列好了。这三个数字谈不上惊天动地但在不改变原有审批流程、不增加业务人员的前提下确实腾出了不少人力。6.2 投入情况的客观评估坦白说这次的投入不能算小。业务和技术的联合梳理耗时大约两周知识库清洗和质量调优持续了一个月合规评审和跨部门协调又是半个月。真正在AgentArts上拖拽编排的时间反而不长大概五个工作日就完成了三套工作流的搭建。这个投入分布很有代表性智能体项目的重心根本不在写Agent而在理流程和备知识。平台解决的是怎么把Agent跑起来而怎么让Agent跑得对、跑得合规靠的是业务规则的梳理和文档的质量管理。很多团队上来就调模型调了很久发现效果上不去回头一看是知识库太乱、流程边界没定义清楚这是比较常见的弯路。6.3 对生产环境的稳定性观察上线初期我们也担心过Agent回答的稳定性。金融场景对错误容忍度极低一次离谱的问答就可能让业务部门对智能体失去信心。我们的策略是渐进放量先让智能体在一个支行试用观察两周回答质量和投诉情况确认没问题后再逐步扩大到全部网点。AgentArts在生产环境的表现整体平稳弹性扩缩容能力在业务高峰时段也确实扛住了压力。但更关键的是我们把知识库的更新机制做成了版本化发布——政策文件变更时先在测试库验证再切到生产库。智能体系统的质量本质上依赖知识数据的版本管理这一点和传统软件系统的发版思路完全一致。7. 后续扩展的方向思考实战跑通之后我们内部在讨论几个扩展方向。一个是贷后管理场景。目前贷后催收和还款提醒还在用传统外呼加人工的方式量大效率低。用智能体做还款日提醒、逾期后的标准话术外呼、特殊情况分类有还款意愿但暂时困难、恶意拖欠可以极大程度上分流催收工作。但这个场景涉及客户处于还款压力期的情绪沟通话术设计要求比贷前咨询更高目前还在评估可行性。另一个是多Agent协作。AgentArts支持多个智能体的协同编排未来可以把贷前咨询、材料预审、审批摘要三个Agent统一到一个工作流里让客户从咨询到提交材料到查询进度全程自助完成。目前三个Agent还是各自独立工作中间串联还需要业务人员手动触发这也是下一个迭代要突破的点。还有一个方向是把智能体的辅助决策能力往上游做深。比如结合更多的历史审批数据和风险记录让审批摘要从罗列风险点升级为给出风险解释和同类案例参考进一步压缩审批人员的决策时间。不过这一步对数据质量和模型能力的要求都会上一个台阶需要在合规框架下稳步推进。这次实战给我最大的感受是AgentArts这类平台的最大价值是把智能体从模型API包了一层壳变成了可编排、可治理、可追溯的业务流程组件。金融信贷场景里技术能力从来不是智能体落地的唯一瓶颈流程的严谨性、知识的准确性、审计的完整性才是真正的分水岭。最后分享一个实现过程中最深切的体会给业务方演示智能体回答流畅、对答如流并不难难的是让业务方形成这个系统出错了也能被及时兜住的信任感。后续再做金融场景智能体的朋友上线前别急着展示对话效果先花时间把兜底机制、审计日志、知识版本管理这三件事做实它们才是金融智能体项目活下来的根基。