金融信贷这个场景，做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. 关于这套方案的一些个人体会
搭完这套东西，我最大的感受是：金融信贷智能体的难点不在模型，而在工程。模型能力现在都够用，真正决定成败的是知识库建得好不好、工作流拆得合不合理、容错机制全不全。我见过太多项目把精力全花在调提示词上，结果知识库一团糟，工作流一锅粥，最后效果上不去还找不到原因。
另一个体会是别追求全自动。人机协同不是妥协，而是现阶段最务实的选择。智能体把信息整合、初步筛查、意见草拟这些累活干了，人专注于关键决策，整体效率提升反而比追求全自动更明显，风险也可控。
最后说个具体的：如果你也在做类似的东西，建议先把知识库的切分和元数据设计做扎实，这是地基。地基不牢，后面工作流编排得再漂亮，检索召回不准，整个智能体的输出质量都上不去。我这次返工最多的地方就是知识库，前期图快，后期补元数据补到怀疑人生。
