金融信贷这个场景做AI智能体跟做通用问答完全是两码事。通用场景下模型答错一句话用户顶多觉得这AI不太聪明但在信贷审批、贷后管理、合规质检这些环节里一次错误的判断可能直接对应一笔坏账或者一次监管问责。我最近花了两周时间基于华为云AgentArts平台搭了一套金融信贷方向的AI智能体从知识库构建、工作流编排到工具调用和容错兜底踩了不少坑也攒了一些能直接复用的经验。这篇笔记不讲虚的就把整个搭建过程、关键决策背后的逻辑、以及实测中暴露的问题摊开来说适合正在做金融方向智能体落地的同行参考也适合刚接触AgentArts、想搞清楚RAG和智能体编排怎么配合的开发者。1. 为什么金融信贷场景不能直接套通用智能体方案1.1 信贷业务的三个硬约束先说清楚这个场景到底特殊在哪。我一开始也想过直接用现成的对话式智能体加个提示词不就行了实际跑下来发现根本行不通核心卡在三个地方。第一是准确性要求极高且错误代价不对称。信贷业务里通过和拒绝这两个判断的代价完全不一样。误拒一个优质客户损失的是业务机会误批一个高风险客户损失的是真金白银。这种不对称性意味着智能体不能只追求答得像而要在关键节点上做到宁可保守不可冒进。通用智能体的设计思路是尽量给出流畅回答这在信贷场景里是危险的。第二是知识来源必须可追溯。监管对信贷决策的可解释性有明确要求任何一条审批意见、任何一个风险提示都得能说清楚依据是什么。这就要求智能体不能凭模型内部参数编而必须从结构化的知识库、制度文件、历史案例里检索出依据再组织语言。这就是RAG在这个场景里不是可选项而是必选项的原因。第三是流程有强状态依赖。信贷不是一问一答而是一个多步骤流程客户信息采集、资质初筛、风险评估、额度测算、审批意见生成。每一步的输入依赖上一步的输出中间还可能因为资料不全而回退。这种有状态、多分支的流程用单纯的对话式智能体很难管好必须靠工作流编排来兜住。1.2 AgentArts在这个场景里扮演什么角色华为云AgentArts本质上是一个智能体的编排和运行平台它把大模型能力、知识库检索、工具调用、流程控制这几块拼在一起。放到信贷场景里我的理解是它承担了三个职责一是调度中枢决定当前这一步该走检索、该调工具还是该让模型直接生成二是知识网关把RAG检索的结果规范化地喂给模型保证输出有据可依三是流程容器用工作流把多步骤的信贷逻辑串起来管理状态和分支。搞清楚这个定位很重要因为它决定了你后面怎么分配工作——哪些交给模型哪些交给检索哪些交给代码逻辑。我的经验是凡是能用确定性规则判断的绝不交给模型。比如客户年龄是否在18到65之间这种判断写个条件节点就行让模型去判断纯属给自己找麻烦。1.3 一个常见的认知误区我见过不少同行一上来就想着把整个信贷审批都交给智能体自动完成。这个想法在现阶段是不现实的也不安全。更务实的做法是人机协同智能体负责信息整合、初步筛查、意见草拟、合规检查这些辅助决策环节最终审批权还是留给人。这样既发挥了智能体处理信息快、不知疲倦的优势又保留了人在关键决策上的把关作用。我这次搭的这套定位就是信贷审批辅助智能体而不是自动审批机器人这个定位一确定后面很多设计就顺了。2. 知识库构建RAG在信贷场景里的落地细节2.1 信贷知识库该放什么、不该放什么RAG的效果七分靠知识库三分靠检索。我见过太多项目把一堆PDF往知识库里一扔就完事结果检索出来的内容驴唇不对马嘴。信贷场景的知识库我建议按用途分成几类分开管理。知识类型具体内容用途更新频率制度规范类信贷政策、审批标准、监管要求提供判断依据低季度级产品规则类各类贷款产品的准入条件、额度规则产品匹配中月度级案例经验类历史审批案例、典型风险案例辅助参考高可周级话术模板类客户沟通话术、意见书模板输出组织低这里有个关键点制度规范类和案例经验类必须物理隔离。因为它们的权威性完全不同——制度是必须遵守案例是仅供参考。如果混在一起检索模型很可能把某个历史案例的做法当成制度依据这就出大事了。我在AgentArts里是建了两个独立的知识库检索时分别召回再在提示词里明确标注来源类型。2.2 文档切分别让一个chunk跨越两个意思文档切分是RAG里最容易被忽视、又最影响效果的环节。信贷制度文件有个特点条款之间逻辑独立但经常一个大条款下面挂好几个小项。如果按固定字数切很容易把一个完整条款切成两半检索时召回半截内容模型理解就偏了。我的做法是按语义结构切分而不是按字数。具体来说优先按文档的标题层级切——一级标题下的内容作为一个父块二级标题下的作为子块。AgentArts的知识库支持配置切分规则我设置的是按标题切分为主、超长段落再按句号二次切分。实测下来这样切出来的chunk语义完整性明显更好。还有个细节每个chunk都要带上上下文路径。比如一个chunk来自第三章 个人贷款 3.2 准入条件 3.2.1 年龄要求那这个路径信息要作为元数据附在chunk上。检索命中后模型看到的不只是内容还有它在文档里的位置这样组织回答时能说清楚依据第三章3.2.1条。这个元数据设计是后面做可追溯的基础。2.3 检索策略单路召回不够用一开始我只用了向量检索效果一般。问题在于信贷场景里有很多精确匹配需求比如客户问我这个情况能不能申请XX产品产品名称是精确的向量检索反而可能召回一堆语义相近但产品不对的内容。后来我改成了混合检索向量检索负责语义匹配关键词检索负责精确命中两路结果做融合排序。AgentArts支持配置多路召回我设置的是向量召回Top10、关键词召回Top10然后用重排序模型统一打分取Top5。这个改动之后产品匹配的准确率提升很明显。提示重排序这一步别省。向量检索的相似度分数和关键词检索的匹配分数不在一个量纲上直接合并会出问题必须有个统一打分的环节。2.4 一个关于图片的坑热词里有人问RAG知识库能存储图片吗我正好踩过这个坑。信贷材料里有大量扫描件、身份证、流水截图这些如果直接进知识库纯文本RAG是处理不了的。我的处理方式是图片类材料走OCR提取文字后再入库图片本身作为附件单独存储在chunk元数据里记录附件地址。这样检索命中的是文字内容需要看原图时再通过元数据里的地址调取。AgentArts本身对多模态的支持在演进中但现阶段我的建议还是文字归文字、图片归图片别指望一个知识库全搞定。3. 工作流编排把信贷流程拆成可管理的节点3.1 为什么用工作流而不是纯对话前面说过信贷是有状态的多步骤流程这里展开讲为什么工作流编排是必须的。纯对话式智能体的问题是它没有显式的状态管理多轮对话里很容易忘记前面已经采集过的信息或者重复询问。而工作流把流程拆成一个个节点每个节点的输入输出都是明确的状态在节点之间传递这就稳了。我在AgentArts里搭的工作流大致是这样的节点序列信息采集 → 完整性校验 → 资质初筛 → 知识检索 → 风险评估 → 意见生成 → 合规检查。每个节点干一件事节点之间用条件分支连接。比如完整性校验不通过就回到信息采集节点并提示缺什么资质初筛不通过直接走拒绝分支不再往下走。3.2 节点设计的一个原则单一职责每个节点只干一件事这个原则听起来简单做起来容易违反。我一开始图省事把资质初筛和风险评估合在一个节点里结果这个节点的提示词写得巨长模型经常顾此失彼。后来拆成两个节点每个节点的提示词聚焦一个任务准确率立刻上来了。具体拆法上我的经验是凡是判断逻辑能用规则表达的就单独做成条件节点凡是需要模型理解和生成的才做成LLM节点。比如年龄、收入、负债率这些硬性指标的判断全是条件节点用代码逻辑判断又快又准。模型只负责那些需要理解的环节比如从客户描述里提取关键信息、根据检索结果组织审批意见。3.3 状态传递别让信息在节点间丢失工作流里节点之间的数据传递是个容易出问题的地方。我的做法是定义一个统一的状态对象所有节点都从这个对象里读、往这个对象里写。这个状态对象包含客户基本信息、已采集材料清单、各环节判断结果、检索到的依据、生成的中间结论。这样做的好处是任何一个节点需要什么信息直接从状态对象里取不依赖上一个节点的输出格式。我踩过的坑是早期让节点直接依赖上一个节点的输出结果中间某个节点改了输出结构后面全崩。改成统一状态对象后节点之间解耦了维护起来轻松很多。3.4 分支与回退信贷流程的常态信贷流程里回退是常态不是异常。客户资料不全要回退补充信息有疑问要回退核实。所以工作流设计时必须把回退路径想清楚。我在每个校验节点都设置了明确的回退条件和回退目标并且限制最大回退次数我设的是3次超过就转人工。这个限制很重要否则可能陷入死循环。4. 工具调用与容错让智能体在出错时体面地失败4.1 信贷智能体需要哪些工具智能体光有知识和模型还不够很多操作得靠工具完成。我这次接入了几个工具征信查询接口模拟、额度计算器、利率查询、材料OCR识别。这些工具通过AgentArts的工具调用能力接入模型在需要时自主决定调用哪个。这里有个设计要点工具的描述要写得极其清楚。模型决定调不调工具、调哪个工具全靠工具描述。我一开始工具描述写得很简略结果模型经常该调不调、或者调错。后来把每个工具的用途、输入参数、返回格式、适用场景都写清楚调用准确率明显提升。比如额度计算器我明确写了当需要根据客户收入和负债计算可贷额度时调用输入为月收入、月负债、贷款期限。4.2 工具调用失败的兜底工具调用失败是必然会发生的——接口超时、返回异常、参数错误。关键是失败之后怎么办。我的处理是三层兜底第一层工具调用失败自动重试一次第二层重试还失败检查是不是参数问题如果是参数缺失回到信息采集节点补参数第三层如果工具彻底不可用降级为提示人工处理绝不让模型瞎编一个结果。这个降级逻辑特别重要。我见过有的实现工具调用失败后模型自己猜了个结果继续往下走这在信贷场景里是灾难。宁可中断流程转人工也不能让智能体在关键数据上编造。4.3 模型输出的容错模型输出也不总是可靠的可能格式不对、可能内容跑偏。我的做法是在关键节点后面加输出校验节点。比如意见生成节点之后加一个校验节点检查生成的审批意见是否包含必要的要素依据条款、风险提示、结论格式是否符合模板。校验不通过就触发重新生成重新生成还不行就转人工。这套容错机制搭下来整个智能体的体面失败能力就具备了——它不会因为某个环节出错就整个崩掉而是能在出错时给出明确的、可处理的信号。5. 实测中暴露的问题与调优记录5.1 检索召回不准的排查过程上线测试第一周发现一个高频问题客户问我月收入8000能贷多少智能体检索出来的却是某个不相关产品的额度规则。排查下来发现两个原因一是知识库里产品规则文档的标题太相似向量检索区分不开二是查询本身太短语义信息不足。解决办法有两个一是给每个产品规则的chunk补充更细的元数据标签产品类型、适用人群检索时先按标签过滤再向量召回二是在检索前加一个查询改写节点把月收入8000能贷多少改写成个人消费贷款 月收入8000元 可贷额度测算补充了产品类型和意图检索准确率立刻上来了。这个查询改写节点是我这次做下来觉得最值的一个优化。5.2 模型过度自信的抑制测试中发现模型在信息不全的情况下也倾向于给出一个明确结论而不是说信息不足无法判断。这在信贷场景里很危险。我的抑制办法是在提示词里明确要求当关键信息缺失时必须输出信息不足并列出缺失项禁止在信息不全时给出审批倾向。同时在校验节点里加了一条规则检查输出里是否包含信息不足的标识如果关键字段缺失但输出没有这个标识就判定为不合格输出触发重新生成。5.3 响应延迟的优化加了RAG检索、工具调用、多轮校验之后单次响应延迟上来了。优化上我做了几件事一是把不依赖上下文的检索提前做比如产品规则检索可以在信息采集阶段就并行发起二是给工具调用设了超时时间避免一个慢接口拖垮整个流程三是把一些固定的规则判断从LLM节点挪到条件节点减少模型调用次数。这几项下来平均响应时间降了大概四成。6. 关于这套方案的一些个人体会搭完这套东西我最大的感受是金融信贷智能体的难点不在模型而在工程。模型能力现在都够用真正决定成败的是知识库建得好不好、工作流拆得合不合理、容错机制全不全。我见过太多项目把精力全花在调提示词上结果知识库一团糟工作流一锅粥最后效果上不去还找不到原因。另一个体会是别追求全自动。人机协同不是妥协而是现阶段最务实的选择。智能体把信息整合、初步筛查、意见草拟这些累活干了人专注于关键决策整体效率提升反而比追求全自动更明显风险也可控。最后说个具体的如果你也在做类似的东西建议先把知识库的切分和元数据设计做扎实这是地基。地基不牢后面工作流编排得再漂亮检索召回不准整个智能体的输出质量都上不去。我这次返工最多的地方就是知识库前期图快后期补元数据补到怀疑人生。