金融信贷智能体落地实战：基于AgentArts的三层架构与核心实现

1. 金融信贷场景下智能体落地的整体设计思路1.1 为什么金融信贷是智能体最值得啃的硬骨头金融信贷这个领域表面上看流程标准化程度很高——进件、初审、征信查询、额度测算、审批、放款、贷后管理每一步都有明确的制度文件撑着。但真正在一线做过信贷系统的人都知道这套流程里藏着大量制度写了但人没完全照做的灰色地带。比如客户经理在进件环节对经营流水的主观判断、风控人员在审批环节对异常指标的弹性解释、贷后催收阶段对客户还款意愿的定性评估这些东西很难用传统的规则引擎覆盖却恰恰是信贷业务里最消耗人力的部分。我过去两年参与过三个信贷风控系统的智能化改造最大的感受是传统方案要么做成死板的规则引擎要么做成黑盒的评分卡模型前者应付不了非结构化信息后者解释性差到业务部门不敢用。而智能体AI Agent这套东西的价值在于它能把制度理解信息抽取推理判断动作执行串成一条链并且每一步的推理过程都能留痕。华为云智果 AgentArts 这个平台本质上就是给这条链提供了一个可编排、可观测、可迭代的底座。这个项目适合谁看如果你是金融科技公司的技术负责人正在评估智能体平台选型如果你是信贷业务的产品经理想搞清楚智能体到底能替业务人员分担哪些活或者你是刚接触 AgentArts 的开发者想找一个有业务纵深感的场景练手——这篇内容都会给你可复现的路径。我会把整个搭建过程拆到照着做就能跑起来的颗粒度同时把每个设计决策背后的原因讲透。1.2 整体架构三层结构撑起一个信贷智能体在 AgentArts 上搭信贷智能体我建议采用感知层—决策层—执行层的三层结构这不是为了套概念而是因为信贷业务的输入输出天然就是分层的。感知层负责把各种形态的原始材料转成智能体能理解的结构化信息。信贷场景的输入特别杂有客户填的申请表结构化表单、有上传的营业执照和银行流水PDF/图片、有征信报告半结构化文本、还有客户经理的尽调笔记自由文本。这一层要做的就是多模态解析和关键字段抽取。决策层是智能体的核心大脑它要完成三件事一是把感知层抽出来的字段跟信贷制度做比对判断是否满足准入条件二是对模糊地带做推理比如流水波动大但行业季节性明显的情况该怎么定性三是生成审批建议和风险提示。这一层我会用 AgentArts 的工作流编排能力把大模型的推理能力和规则判断结合起来避免纯大模型一本正经胡说八道。执行层负责把决策结果落到具体动作上生成审批意见书、触发人工复核工单、更新客户风险标签、推送贷后检查任务。这一层的关键是可回滚和可审计每一笔智能体做出的动作都要有日志方便事后追溯。三层之间通过 AgentArts 的上下文变量传递数据我实测下来这种结构比把所有逻辑塞进一个大 prompt 里要稳定得多尤其是当信贷制度更新时只需要改决策层的规则配置感知层和执行层基本不用动。1.3 平台选型的几个关键考量市面上智能体平台不少我选 AgentArts 主要看中三点。第一是它跟华为云的数据底座打通得比较顺信贷场景对数据安全要求高数据不出云这点很关键。第二是它的工作流编排支持人在回路Human-in-the-loop也就是智能体跑到关键节点可以暂停等人工确认这对信贷审批这种不能全自动的场景太重要了。第三是它的工具调用框架比较开放我能把行内已有的征信查询接口、额度计算服务直接封装成工具挂上去不用重写。当然也有需要妥协的地方。AgentArts 的可视化编排对复杂条件分支的支持不如纯代码灵活所以我在决策层里把特别复杂的规则判断写成了自定义函数节点。这个取舍后面会详细讲。2. 核心细节解析与实操要点2.1 信贷制度知识的结构化处理智能体要懂信贷业务第一步是把制度文件喂给它。但直接把几十页的《信贷业务管理办法》PDF 丢给大模型做知识库效果会很差——检索出来的片段经常答非所问。我的做法是做两层处理。第一层是制度条款的原子化拆解。把每个制度条款拆成适用条件判断规则所需材料例外情况四元组。举个例子某条制度写小微企业信用贷款申请人近12个月经营流水月均不低于5万元且近3个月无连续断缴记录拆解后就是适用条件小微企业、信用贷款判断规则近12个月月均流水≥5万 且 近3个月无连续断缴所需材料银行流水例外情况季节性行业可放宽至月均4万需客户经理说明第二层是向量化入库时的元数据标注。每个原子条款在存入知识库时除了文本向量还要打上业务环节风险等级是否可自动化判断等标签。这样智能体在检索时可以先按标签过滤再做语义匹配准确率能提升一大截。我实测过加了标签过滤后制度检索的命中准确率从大概六成提升到了九成以上。注意制度条款拆解这步千万别偷懒让大模型全自动做我试过它会把且和或的逻辑关系搞混导致判断规则出错。正确做法是大模型先拆一版人工逐条核对逻辑连接词。2.2 多模态材料的字段抽取策略信贷进件材料里银行流水和征信报告是两块最难啃的骨头。银行流水各家银行格式不一样有的 PDF 是文本层可直接提取有的是扫描件得走 OCR。我的策略是分而治之。对于文本层 PDF直接用 AgentArts 的文档解析工具提取表格然后按交易日期、摘要、收入、支出、余额四列做规整。这里有个坑很多流水的收入支出是合并在一列里的靠正负号区分解析时要判断符号。对于扫描件走 OCR 后要加一步表格结构还原因为 OCR 出来的往往是散落的文本块。我用的是基于坐标的还原方法先识别表头位置再按行高切分数据行最后按列坐标对齐。这套逻辑我封装成了一个自定义工具节点在 AgentArts 里注册后可以直接调用。征信报告的抽取更麻烦因为它有固定的版式但各家银行报送的细节有差异。我的做法是先按信贷交易信息明细查询记录公共信息三大块做区域切分然后在每块里用正则大模型结合的方式抽字段。纯正则太脆纯大模型太慢且不稳定两者结合效果最好——正则负责抽格式固定的字段如账户数、逾期月数大模型负责抽描述性字段如当前状态的具体表述。材料类型抽取方式关键字段常见问题文本层流水PDF文档解析列规整月均流水、断缴月份收支合并列符号判断扫描件流水OCR坐标还原同上表格线识别失败征信报告区域切分正则/大模型混合逾期次数、负债率版式差异导致区域偏移营业执照OCR关键词匹配注册资本、成立日期印章遮挡文字2.3 决策层的规则与大模型协同决策层是整个智能体最容易出问题的地方。我的核心原则是能用规则判断的绝不用大模型必须用大模型的必须给规则兜底。具体来说像月均流水是否达标逾期次数是否超限这种有明确数值标准的判断直接写成规则函数又快又准。而像经营流水波动是否属于行业正常季节性波动这种需要结合行业知识的判断才交给大模型推理但推理结果要经过一个合理性校验规则——比如大模型说属于正常波动那校验规则会检查该行业是否真的在知识库里有季节性标签没有的话就转人工。这种协同方式的好处是智能体的输出既有大模型的灵活性又有规则系统的确定性。我在 AgentArts 里是用条件分支函数节点大模型节点组合实现的工作流大致是这样先走规则判断节点如果所有硬性条件都满足且无模糊项直接出通过建议如果有模糊项路由到大模型推理节点大模型出结果后再走校验节点校验不过转人工。实操心得大模型节点的 prompt 里一定要明确要求它输出结构化的 JSON包含判断结论推理依据置信度三个字段。置信度低于阈值的自动转人工这个阈值我设的是 0.75实测下来误判率可控。3. 实操过程与核心环节实现3.1 环境准备与平台基础配置开始搭建前先把 AgentArts 上的基础环境配好。登录平台后第一件事是创建应用空间我建议按信贷智能体-生产和信贷智能体-测试分开建两个空间避免调试时污染生产数据。然后是配置模型。AgentArts 支持接入多种大模型信贷场景我建议用推理能力强的模型做决策用轻量模型做字段抽取。具体配置时要注意 temperature 参数做字段抽取时设成 0.1保证输出稳定做风险推理时设成 0.3留一点灵活性但别太高太高了容易发散。接下来是知识库的创建。在平台的知识库模块新建一个上传前面处理好的制度原子条款。这里有个细节上传时要选自定义分段把每个原子条款作为独立分段不要用自动分段否则条款会被切碎。分段后的向量化模型选平台默认的就行信贷文本不是特别专业的领域通用向量模型够用。最后是工具注册。把行内的征信查询接口、额度计算服务、工单系统接口封装成 HTTP 工具在 AgentArts 的工具管理里注册。注册时要写清楚每个工具的入参和出参 schema这个 schema 会直接影响大模型调用工具时的准确率别嫌麻烦写详细点。3.2 感知层工作流的搭建步骤感知层我搭了一个独立的工作流输入是进件材料包输出是结构化字段集合。具体节点顺序如下。第一步是材料分类节点。用一个轻量模型判断上传的文件分别是什么类型流水/征信/执照/其他。这里可以用文件扩展名做初筛但别完全依赖扩展名因为客户经理上传时经常命名混乱还是得靠内容判断。第二步是并行解析节点。AgentArts 支持并行分支我把流水解析、征信解析、执照解析放在三个并行分支里同时跑能省不少时间。每个分支里再根据文件是文本层还是扫描件走不同的子路径。第三步是字段汇总与校验节点。把三个分支的输出合并成一个 JSON然后做基础校验必填字段是否缺失、数值字段是否在合理范围比如流水金额不可能是负数、日期字段格式是否统一。校验不通过的字段标记出来在后续决策时作为信息不完整处理。第四步是上下文组装节点。把校验后的字段集合、原始材料的文本摘要、以及材料完整性标记组装成决策层的输入上下文。这里我会控制上下文的长度太长了会影响大模型推理质量一般控制在 4000 token 以内超出的部分做摘要压缩。整个感知层工作流我实测跑一单材料大概 15 到 30 秒主要耗时在 OCR 和征信报告解析上。如果材料都是文本层 PDF能压到 10 秒以内。3.3 决策层工作流的关键节点配置决策层是重头戏我把它拆成了四个核心节点。准入判断节点是个函数节点里面写的是硬性规则的代码。输入是感知层传来的字段集合输出是通过/不通过/待定三态结果加上不通过的具体原因。这个节点我建议用 Python 写逻辑清晰好维护。核心逻辑就是遍历制度里拆出来的硬性条件逐条比对。风险推理节点是大模型节点只在准入判断为待定时触发。prompt 我打磨了很多版核心结构是先给大模型交代角色资深信贷审批专家再给制度依据从知识库检索相关条款再给客户信息最后要求它输出结构化判断。这里有个技巧把制度条款作为判断依据显式放在 prompt 里比让大模型自己去知识库检索要准因为检索环节可能引入噪声。合理性校验节点是函数节点对大模型的输出做二次检查。检查项包括结论是否与硬性规则冲突、推理依据是否引用了不存在的制度条款、置信度是否达标。任何一项不过就转人工。建议生成节点是模板大模型的混合节点。审批意见书的格式是固定的用模板填充但风险提示部分需要结合具体客户情况生成用大模型写。这样既保证了格式规范又有针对性。3.4 执行层动作的落地与审计执行层的动作我分了四类每类都封装成独立工具。第一类是文档生成生成审批意见书 PDF 并归档。这个用平台的文档生成工具就能做模板提前配好。第二类是工单触发需要人工复核时往工单系统推一条记录。这里要注意工单里要带上智能体的完整推理链路方便复核人员理解决策依据。第三类是标签更新把智能体判断出的风险标签写回客户画像系统。标签的命名要跟行内现有标签体系对齐别自己造新词。第四类是任务推送贷后检查任务推给对应的客户经理。每一类动作执行后都要写审计日志日志里记录动作类型、输入参数、执行结果、时间戳、关联的智能体会话 ID。这个日志我建议单独存一张表别跟业务日志混在一起方便后续做智能体效果分析。注意执行层的工具调用一定要加超时和重试机制。我踩过的坑是工单系统偶尔响应慢智能体卡在那里等导致整个会话超时。后来给每个工具调用设了 10 秒超时超时后走降级逻辑比如先存本地待推送队列。4. 常见问题与排查技巧实录4.1 字段抽取准确率上不去的排查路径字段抽取是信贷智能体最基础也最容易出问题的环节。如果发现抽取准确率低按这个顺序排查。先看原始材料质量。扫描件模糊、印章遮挡、表格线断裂这些都会直接拉低 OCR 效果。这种情况没有太好的技术解法只能在前端进件环节加材料质量检测不合格的打回去重传。再看解析规则。文本层 PDF 的表格解析如果列对不齐多半是 PDF 里用了不规范的表格结构。这时候要调整列识别逻辑我一般会打印出解析后的坐标信息人工看几单找出规律。最后看大模型抽取的 prompt。如果字段是让大模型抽的检查 prompt 里有没有给示例few-shot。信贷字段的表述差异大给两三个示例能明显提升准确率。另外要检查输出格式约束够不够强大模型有时候会自作主张加字段。问题现象可能原因排查方法解决手段流水金额抽取错误收支列符号判断错打印解析后表格修正符号判断逻辑征信逾期次数漏抽区域切分偏移可视化切分区域调整区域定位规则执照日期格式乱OCR 识别错抽查 OCR 原文加日期格式归一化字段整体缺失材料分类错误看分类节点输出优化分类 prompt4.2 大模型推理结果不稳定的应对大模型推理不稳定是智能体落地绕不开的问题。同一个客户今天问和明天问结论可能不一样。我的应对策略是约束校验兜底三件套。约束是在 prompt 层面做的。把推理的步骤固定下来要求大模型按第一步看什么、第二步看什么的顺序思考别让它自由发挥。另外把制度条款作为硬约束写进去明确告诉它以下结论必须在这些条款范围内。校验是在输出层面做的。前面提到的合理性校验节点就是干这个的。校验规则要覆盖结论与硬性规则的一致性、推理链条的完整性、引用条款的真实性。兜底是在流程层面做的。置信度低的、校验不过的一律转人工。别心疼转人工的比例信贷场景宁可多转人工也不能出错。我实测下来转人工比例控制在 15% 到 25% 之间是比较健康的太低了说明校验太松太高了说明智能体没起到减负作用。4.3 智能体与现有系统的对接坑信贷智能体不是孤立系统它要跟行内一堆老系统打交道。对接这块我踩的坑最多挑几个典型的说。接口鉴权方式不统一。有的系统用 token有的用签名有的用白名单 IP。封装工具时要针对每种鉴权方式写适配层别想着统一老系统改不动。数据格式不一致。同样是客户 ID有的系统用字符串有的用数字有的带前缀。工具入参出参要做格式转换这个转换逻辑要写单元测试不然很容易出隐蔽 bug。并发限制。老系统的接口往往有并发限制智能体如果并发调用容易被限流。我的做法是在工具层加一个令牌桶限流器控制调用频率。事务一致性。智能体执行多个动作时如果中间某个动作失败了前面的动作要不要回滚信贷场景我建议是能回滚的回滚不能回滚的记补偿任务。比如文档已生成但工单没推成功就记一条补偿任务定时重推。4.4 效果评估与持续迭代方法智能体上线不是终点得持续盯着效果。我建了一套评估指标体系分三层。准确性指标字段抽取准确率、准入判断准确率、风险推理与人工复核的一致率。这些指标靠人工抽样标注来算每周抽 100 单。效率指标单均处理时长、转人工比例、工具调用成功率。这些从审计日志里自动统计。业务指标智能体辅助审批的通过率、不良率、客户经理满意度。这些要跟业务部门一起看周期长一点按月看。迭代的节奏我建议是每周看准确性和效率指标发现问题就调 prompt 或规则每月看业务指标评估智能体的整体价值。每次调整都要做 A/B 对比别凭感觉改。实操心得建一个bad case 库把每次出错或转人工的案例存下来定期分析。我坚持了三个月发现 80% 的问题集中在 20% 的场景上针对性地优化这些场景效果提升最明显。5. 从能跑到好用几个提升智能体实战表现的经验5.1 上下文管理的取舍智能体跑信贷业务上下文管理是个容易被忽视但影响很大的点。信贷一单涉及的材料信息量很大全塞进上下文既贵又慢还容易让大模型抓不住重点。我的做法是分层上下文。第一层是决策必需字段就是硬性规则判断要用的那些必须完整。第二层是推理参考信息比如流水摘要、征信概要做压缩后放入。第三层是背景信息比如行业分类、地区经济数据按需检索不默认加载。压缩这块我用的是结构化摘要而不是文本摘要。比如流水不是让大模型写一段话总结而是直接算好月均、最大单月、最小单月、波动率这些指标用数值形式放入上下文。数值比文字更省 token也更容易被大模型准确使用。5.2 人工复核环节的设计信贷场景不可能全自动人工复核环节的设计直接决定智能体好不好用。我的原则是复核人员看到的应该是决策依据而不是原始材料。具体来说复核界面里要展示智能体的判断结论、推理链路每一步看了什么、得出什么、引用的制度条款、置信度、以及触发复核的原因。原始材料作为附件可查但不默认展开。这样复核人员能快速理解决策逻辑复核效率高很多。另外复核结果要回流。复核人员改了智能体的结论这个修改要记录下来作为后续优化的样本。我建了个机制每周把复核修改的案例拿出来分析看是智能体哪里判断错了针对性调整。5.3 制度更新时的快速响应信贷制度是会变的监管要求、行内政策调整都会导致制度更新。智能体如果不能快速响应制度变化很快就会失效。我的做法是把制度相关的逻辑尽量配置化。制度条款的原子化拆解结果存在知识库里判断规则的参数比如流水阈值、逾期次数上限存在配置表里制度更新时改配置和知识库就行不用改代码。只有制度发生结构性变化比如新增了一个判断维度才需要动工作流。这套机制我实测下来一次常规制度更新调整几个阈值从收到通知到智能体生效半天就能搞定。结构性变化大概需要两三天。5.4 智能体能力的边界认知最后说个心态层面的经验。智能体在信贷场景能做的事很多但别指望它包打天下。我总结下来智能体最擅长的是信息密集但判断逻辑相对清晰的环节比如材料审核、初步准入、标准化审批。而需要大量隐性经验的环节比如复杂企业的授信方案设计、疑难客户的谈判策略智能体目前还替代不了人。把智能体放在它擅长的位置上让它做人做起来枯燥、重复、易出错的部分人专注于需要经验和判断的部分这个分工才是健康的。我见过一些项目非要把智能体做成全能审批员结果效果不好还打击了团队信心。认清边界反而能把智能体的价值发挥到最大。这个信贷智能体我前后迭代了大概四个月从最初只能做材料抽取到现在能覆盖七成的标准化审批场景中间踩的坑基本都写在上面的内容里了。后续我打算把贷后管理的场景也接进来比如自动生成贷后检查报告、识别早期风险信号这块的挑战在于数据更稀疏、反馈周期更长等跑出点结果再跟大家分享。