1. 金融信贷场景下智能体落地的整体设计思路1.1 为什么金融信贷是智能体最值得啃的硬骨头金融信贷这个领域表面上看流程高度标准化进件、初审、面签、审批、放款、贷后每个环节都有厚厚的制度文件兜底。但真正在一线做过信贷系统的人都知道标准化只是外壳里面全是非标准化的判断。一个客户经理拿到一笔小微企业贷款申请他要看的材料可能包括营业执照、近半年流水、纳税记录、征信报告、上下游合同、抵押物评估报告甚至还要打电话核实经营场地。这些动作里有大量环节是查规则、对条款、填表单、写意见恰恰是智能体最擅长接管的部分。我之所以盯上华为云智果 AgentArts 这个平台来做金融信贷方向的智能体核心原因是它在工作流编排、工具调用、知识库挂载这三件事上的完成度比较高。信贷场景不像通用问答它要求智能体必须能查得到制度、算得清指标、留得下痕迹。AgentArts 提供的可视化编排能力让一个懂信贷业务但不懂代码的人也能把审批逻辑拆成节点串起来这一点在实际项目里非常关键。这个实战适合三类人参考一是金融科技团队里负责信贷系统智能化改造的工程师二是银行或消金公司里想用智能体提效的业务产品经理三是正在研究 AI 智能体在垂直行业落地路径的技术爱好者。不管你之前有没有搭过智能体只要跟着把信贷这个场景走通一遍后面换到保险、理财、风控任何一个方向底层方法论都是通的。1.2 整体架构把信贷审批拆成感知—决策—执行三层我在设计这套信贷智能体的时候没有一上来就堆功能而是先把信贷审批的完整链路画出来然后按感知层、决策层、执行层三层来切分。感知层负责看懂材料。信贷进件材料格式极其混乱有 PDF 扫描件、有 Excel 流水、有拍照上传的合同。这一层要解决的是把非结构化数据转成结构化字段比如从银行流水中提取月均进账、从征信报告中提取逾期次数、从营业执照中提取成立年限。AgentArts 里可以通过挂载 OCR 工具和文档解析工具来实现每个工具就是一个可调用的节点。决策层负责按规则判断。这是信贷智能体的核心也是最容易出问题的地方。信贷规则往往不是一条 if-else 能写完的它涉及多条件组合、阈值判断、优先级覆盖。我的做法是把决策层再拆成硬规则校验和软评分辅助两条线。硬规则是那些一票否决的红线比如当前逾期、涉诉、年龄超限软评分则是根据流水、纳税、征信查询次数等维度加权打分给出建议额度区间。执行层负责输出结果并留痕。信贷是强监管行业每一个审批动作都要可追溯。所以执行层不只是生成一段审批意见还要把命中的规则、调用的工具、参考的知识库片段全部记录下来形成一份结构化的审批日志。AgentArts 的工作流天然支持节点级日志这一点在合规审计时能省掉大量扯皮。提示三层架构不是必须严格物理隔离在 AgentArts 里可以放在同一个工作流中用节点分组来体现层次。关键是逻辑上要分清否则后期规则一多工作流会变成一团乱麻。1.3 平台选型背后的三个硬指标市面上做智能体的平台不少我最终选华为云智果 AgentArts是拿三个硬指标卡出来的。第一个指标是工具调用的稳定性。信贷场景要调用的外部服务很多征信查询接口、工商信息接口、流水解析服务任何一个调用超时或返回异常整个审批链路就断了。AgentArts 在工具节点上支持重试策略和超时配置这个在实测中救过我好几次。有一次工商接口返回慢如果没有重试机制那批进件全部会卡在决策层。第二个指标是知识库的检索精度。信贷制度文件动辄几百页智能体要能精准定位到小微企业授信额度测算办法里的某一条而不是把整章内容都塞给模型。AgentArts 的知识库支持分段检索和相似度阈值调节我一般把阈值设在 0.75 左右太低会召回无关条款太高会漏掉关键规则。第三个指标是工作流的可调试性。搭智能体最怕的是黑盒输入进去输出不对但不知道哪一步错了。AgentArts 支持单节点调试和中间结果查看我可以单独跑流水解析这个节点看它提取的月均进账对不对而不用每次都把整个流程跑一遍。这个功能在规则调试阶段至少帮我省了一半时间。2. 核心细节解析与实操要点2.1 知识库构建把信贷制度喂对方式信贷智能体的知识库不是把 PDF 丢进去就完事了。我踩过的第一个坑就是直接上传了一整套信贷管理办法结果智能体检索出来的内容要么是目录页要么是无关章节。后来我调整了策略按制度层级业务场景两个维度来组织知识库。制度层级上我把知识库分成三层第一层是基本制度比如《信贷业务管理办法》这是总纲第二层是产品制度比如《小微企业流动资金贷款实施细则》第三层是操作规范比如《授信审批操作手册》。每一层单独建一个知识库在工作流里根据进件类型选择挂载哪个库。这样做的好处是检索范围收窄了精度自然就上去了。业务场景上我按贷前、贷中、贷后打标签。贷前主要挂载准入制度和反欺诈规则贷中挂载额度测算和利率定价规则贷后挂载预警和催收制度。AgentArts 的知识库支持标签过滤我在工作流里通过条件节点判断当前处于哪个阶段然后只检索对应标签下的内容。分段策略也很关键。信贷制度里一条规则往往包含适用对象、准入条件、额度上限、期限要求多个要素如果按固定字数切分很容易把一条完整规则切碎。我的做法是按条切分一条制度作为一个知识片段如果某条特别长再按款二次切分。实测下来这种切法让检索命中率从原来的六成左右提升到了八成五以上。注意知识库更新频率要跟上制度修订节奏。信贷制度每年至少修订一次有些产品制度季度就在调。我一般设置每月检查一次制度版本发现更新就重新上传对应片段避免智能体拿着旧规则做判断。2.2 工作流节点设计从进件到审批意见的完整链路这套信贷智能体的工作流我前后重构了三版最终稳定下来的节点链路是这样的进件接收节点接收外部传入的申请编号调用信贷系统接口拉取该笔进件的所有材料清单。这个节点不涉及复杂逻辑但要做好异常处理如果申请编号不存在或材料未齐直接走拒绝分支并输出原因。材料解析节点组这是最重的一组节点下面挂载了四个子节点。营业执照解析节点提取企业名称、统一社会信用代码、成立日期、注册资本银行流水解析节点提取近六个月月均进账、月均出账、期末余额征信报告解析节点提取当前逾期次数、历史最大逾期天数、近三个月查询次数纳税记录解析节点提取近一年纳税总额、纳税连续性。每个子节点都配置了失败重试和默认值兜底比如流水解析失败时月均进账默认置为 0 并标记需人工复核。硬规则校验节点把解析出来的字段逐条比对红线规则。我在这里用了一个规则表的设计把红线规则写成 JSON 配置存在知识库里节点运行时动态加载。这样做的好处是规则调整不用改工作流改配置就行。红线规则包括当前逾期次数大于 0、成立年限小于 1 年、近三个月查询次数大于 6 次、年龄大于 65 岁或小于 22 岁。任何一条命中直接跳转到拒绝分支。软评分节点没被红线拦住的进件进入这里按加权模型打分。我的评分模型包含五个维度流水稳定性占 30 分、纳税贡献占 25 分、征信表现占 25 分、经营年限占 10 分、行业景气度占 10 分。每个维度下再细分档位比如流水稳定性按月均进账波动率分三档波动率低于 15% 得满分15% 到 30% 得一半分高于 30% 得零分。总分算出来后映射到建议额度区间和利率档位。审批意见生成节点把前面所有节点的输出汇总调用大模型生成一段结构化的审批意见。这段意见不是随便写的我给它定了模板先写经系统自动审核然后分点列出关键指标再写建议授信额度 XX 万元期限 XX 个月利率 XX%最后附上本意见由智能体生成需人工复核确认。模板化的好处是输出稳定不会今天一个格式明天一个格式。日志归档节点把整个流程的输入、中间结果、输出、命中的规则、调用的工具全部打包成 JSON写入审批日志表。这个节点是合规审计的命根子千万不能省。2.3 提示词工程让模型说人话也说对话信贷智能体的提示词跟通用聊天机器人的提示词完全不是一个写法。通用场景你可以让模型自由发挥信贷场景你必须把它的输出框死。我在系统提示词里做了四件事。第一件是角色定义明确告诉模型你是一名信贷审批辅助助手你的输出将作为人工审批的参考不得直接作为最终审批结论。这句话是免责也是定位防止模型越权。第二件是输出格式约束。我要求模型必须按 JSON 格式输出字段包括decision建议结论、reason理由列表、suggested_amount建议额度、suggested_rate建议利率、risk_flags风险提示。JSON 的好处是下游系统可以直接解析不用再做文本抽取。第三件是知识引用约束。我要求模型在给出每一条理由时必须标注引用了知识库中的哪一条制度。比如根据《小微企业流动资金贷款实施细则》第十二条建议额度不超过年纳税额的 3 倍。这样做既增加了可信度也方便人工复核时快速定位依据。第四件是兜底话术。当模型遇到知识库中没有覆盖的情况时不允许它编造规则必须输出当前知识库未覆盖该情形建议转人工审批。这条约束在实测中触发过几次都是些比较偏的行业或特殊的股权结构模型老老实实转人工比瞎给结论强得多。实操心得提示词不是写一次就完事的。我一般会在工作流里加一个提示词版本字段每次调整提示词就升一个版本号日志里记录用的是哪个版本。这样后面发现某批审批意见质量下降可以快速定位是不是提示词改坏了。3. 实操过程与核心环节实现3.1 环境准备与平台基础配置开始搭之前先把平台侧的基础配置做扎实。登录华为云智果 AgentArts 控制台后第一件事是创建应用。应用名称我建议按业务域-场景-版本来命名比如credit-approval-v1后面应用多了不至于混淆。创建完应用先配工具。信贷场景需要的工具分三类文档解析类、外部接口类、计算类。文档解析类我用了平台内置的 OCR 和 PDF 解析工具直接在工作流里添加节点即可。外部接口类需要自己配在工具管理里新建 HTTP 工具填入接口地址、请求方法、请求头、参数映射。这里有个细节信贷系统的接口一般都有签名校验我是在工具配置里加了一个前置脚本节点用 JavaScript 算好签名再传给接口。计算类工具我单独写了一个云函数把额度测算、利率定价、评分卡计算这些逻辑封装进去。为什么不直接在工作流里用代码节点算因为信贷计算逻辑经常变封装成独立函数后改逻辑不用动工作流重新部署函数就行。这个函数我用了 Python 写入参是解析后的结构化字段出参是评分和额度建议。知识库配置前面已经讲过分层策略这里补充一个操作细节上传文档时AgentArts 支持自定义分段规则。我一般用正则表达式按第X条来切分切完后人工抽检十条看看有没有切歪的。切歪的片段手动合并或拆分别嫌麻烦知识库质量直接决定智能体的上限。3.2 工作流编排的完整操作步骤工作流编排是这套智能体的核心操作我按实际搭建顺序一步步说。第一步拖入开始节点定义输入参数。我定义了三个入参application_id申请编号字符串、channel进件渠道枚举值、priority优先级整数。channel这个参数后面会用来决定走哪套规则比如线上渠道和线下渠道的准入标准略有差异。第二步拖入HTTP 请求节点调用信贷系统接口拉取进件详情。这个节点的输出是一个 JSON包含材料列表和基本信息。配置时要注意设置超时时间为 10 秒重试次数为 2 次。信贷系统偶尔会有慢查询不设重试容易误杀。第三步拖入条件分支节点判断材料是否齐全。判断逻辑是检查返回 JSON 中的materials数组长度是否大于 0以及是否包含必需的四个材料类型。不齐全的走拒绝分支输出材料不齐请补充后重新提交。第四步拖入四个并行的文档解析节点分别处理营业执照、流水、征信、纳税材料。AgentArts 支持并行节点四个解析同时跑比串行快不少。每个解析节点后面跟一个字段映射节点把解析结果映射成统一的字段名比如把月均进账和月均收入统一成monthly_income。第五步拖入代码节点执行硬规则校验。我把红线规则写成一个 JSON 数组存在节点代码里遍历检查。这个节点的输出是pass或reject以及命中的规则列表。代码我用 JavaScript 写大概三十行左右逻辑很直白。第六步拖入云函数调用节点执行软评分。把解析后的字段传给之前部署的评分函数拿回总分和建议额度。这个节点要设置超时时间为 5 秒因为评分函数里有几次数据库查询。第七步拖入大模型节点生成审批意见。这个节点的提示词就是前面 2.3 节讲的那套。模型我选的是平台默认的通用模型温度参数设成 0.1让输出尽量稳定。温度太高的话同样的输入每次输出都不一样审批意见就没法用了。第八步拖入日志归档节点把所有中间结果汇总写入数据库。这个节点用 HTTP 工具调用日志服务接口把整个流程的上下文打包传过去。第九步拖入结束节点定义输出参数。输出包括decision、suggested_amount、suggested_rate、reason、log_id。整个工作流跑通后我在测试环境用历史进件数据回测了 200 笔通过率跟人工审批的吻合度在 87% 左右。不吻合的主要是些边缘案例比如流水波动大但实际经营正常的这类本来人工也会纠结智能体给个参考意见反而有帮助。3.3 参数计算与阈值设定的依据信贷智能体里有一堆阈值参数这些数不是拍脑袋定的每一个都有依据。先说流水波动率的阈值。我设的是 15% 和 30% 两档。这个数是从历史数据里跑出来的。我拉了 500 笔已结清的小微贷款算它们放款前六个月的流水波动率发现波动率低于 15% 的客户逾期率是 1.2%15% 到 30% 之间的逾期率 3.5%高于 30% 的逾期率跳到 8.7%。所以 15% 和 30% 是两个自然的分档点。再说征信查询次数的红线。我设的是近三个月大于 6 次直接拒绝。这个依据是行业通行标准三个月内查询超过 6 次通常意味着客户在多头借贷。我自己回测的数据也支持这个阈值查询次数 7 次以上的客户逾期率是查询 3 次以下客户的 4 倍多。建议额度的计算公式是min(年纳税额 × 3, 月均进账 × 6, 抵押物评估值 × 0.7)。三个上限取最小值这是为了控制风险敞口。年纳税额乘 3 是参考了税贷产品的常见倍数月均进账乘 6 是覆盖半年的经营周转抵押物打七折是留出处置折价空间。利率定价用的是基准利率加点模式。基准利率取 LPR加点幅度根据评分结果来评分 90 分以上加 50 个基点80 到 90 分加 100 个基点70 到 80 分加 150 个基点70 分以下加 200 个基点。这个加点幅度是跟资金成本和风险成本挂钩的评分越低风险溢价越高。提示这些参数不是一成不变的。我一般每季度用新数据回测一次看看阈值要不要调。经济环境变了同样的流水波动率对应的风险可能就不一样了。4. 常见问题与排查技巧实录4.1 智能体输出不稳定的排查思路智能体输出不稳定是搭信贷智能体最常见的问题表现就是同样的进件今天跑出来建议额度 50 万明天跑出来 45 万。这个问题我遇到过好几次排查下来主要有三个原因。第一个原因是模型温度参数设高了。大模型节点默认温度可能是 0.7 或 0.8这个值在创意写作场景没问题在信贷场景就是灾难。我把温度降到 0.1 之后输出稳定性明显提升。如果平台支持还可以设置随机种子进一步固定输出。第二个原因是知识库检索结果波动。如果知识库分段不合理同一个问题可能这次召回第三条下次召回第五条模型参考的依据变了输出自然就变了。解决办法是优化分段策略并且在检索节点设置相似度阈值下限低于阈值的片段直接丢弃宁可少召回也不要召回错的。第三个原因是上游解析结果不稳定。比如流水解析节点如果 OCR 识别质量时好时坏提取的月均进账每次不一样下游评分和额度自然跟着变。这个问题要在解析节点加校验比如识别置信度低于 0.8 的字段标记为待复核不参与自动评分。排查的时候我一般用固定输入法找一笔历史进件把它的所有材料固定下来然后连续跑十次看输出是否一致。如果不一致再逐个节点看中间结果定位是哪个节点在波动。4.2 工具调用失败的兜底策略信贷智能体依赖的外部工具很多任何一个挂了都会影响主流程。我总结了几种常见失败场景和对应的兜底策略。失败场景表现兜底策略征信接口超时节点报超时错误重试 2 次仍失败则标记征信待查转人工复核流水解析失败返回空字段月均进账置 0标记流水需人工核验不参与自动评分工商接口返回异常企业信息为空用进件时填写的企业名称做模糊匹配匹配不上转人工知识库检索无结果返回空列表模型输出知识库未覆盖建议转人工不编造规则日志写入失败归档节点报错本地缓存日志定时任务补写主流程不阻塞这张表是我在实际运维中慢慢攒出来的每一条都对应过一次真实的故障。最惊险的一次是征信接口批量超时如果没有兜底策略那批进件全部会卡死。后来加了征信待查标记智能体照常出审批意见只是把征信维度空着人工复核时补上就行。注意兜底策略的核心原则是不阻塞主流程。信贷审批有时效要求智能体可以给不完整的意见但不能因为一个工具挂了就整个停摆。当然兜底产生的待复核标记必须在日志里醒目标注不能悄悄混过去。4.3 合规留痕的实操细节信贷是强监管行业智能体做的每一个判断都要能解释、能追溯。我在日志归档节点上花了不少心思最终定下来的日志结构包含以下字段application_id申请编号关联业务系统workflow_version工作流版本号每次改流程升版本prompt_version提示词版本号input_snapshot输入快照进件材料的原始解析结果rule_hits命中的硬规则列表没命中就是空数组score_detail软评分各维度得分明细knowledge_refs引用的知识库片段 ID 列表model_output模型原始输出未经处理的final_decision最终输出给业务系统的结论timestamp时间戳这份日志我要求保留至少三年跟信贷档案的保存期限对齐。实际用起来最大的价值是在监管检查时能快速还原每一笔智能体审批的完整链路。有一次检查问某笔进件为什么给了 80 万额度我直接调出日志看到评分明细里流水稳定性满分、纳税贡献满分引用了制度第十二条和第十五条检查人员看了就认可了。还有一个细节是模型输出的原始记录。有些人为了好看把模型输出清洗一遍再存日志我不建议这么做。原始输出里可能包含模型的一些思考痕迹比如它为什么排除了某个风险点这些信息在复盘时很有价值。清洗后的结果可以另存一个字段但原始的一定要留着。4.4 从单场景到多场景的扩展经验这套信贷智能体跑稳之后我试着往其他场景扩展踩了一些坑也攒了一些经验。第一个扩展方向是贷后预警。贷后预警的逻辑跟贷前审批不一样它更关注变化而不是状态。比如客户流水突然下降 50%、纳税中断、征信新增逾期这些是预警信号。我把贷前的工作流复制了一份把硬规则校验节点换成变化检测节点对比当期数据和历史数据超过阈值就触发预警。知识库也换成了贷后管理制度。整个改造大概花了三天比从零搭快得多。第二个扩展方向是制度学习助手。这个场景跟审批正好相反审批是用制度学习助手是学制度。我把知识库挂载到对话式智能体上员工可以问小微企业贷款的准入条件是什么智能体检索制度片段后给出回答。这个场景对输出格式要求没那么严但对知识库覆盖度要求高我把所有信贷制度都传了进去还加了一个制度更新提醒功能制度修订后自动推送通知给相关岗位。第三个扩展方向是反欺诈辅助。这个场景我还在摸索目前的做法是把反欺诈规则也做成一个规则表跟审批规则并行跑。反欺诈规则更关注关联关系比如同一手机号关联多个申请、同一地址注册多家企业。这些规则需要查外部数据调用量比较大我还在优化性能。扩展过程中最大的体会是工作流的骨架可以复用但规则和知识库必须重做。贷前和贷后的逻辑差异很大直接套用会出问题。我的做法是把公共部分材料解析、日志归档、异常处理抽成子工作流场景特有的部分单独编排这样既复用了代码又保证了场景适配。5. 智能体在信贷场景的边界与人工协同5.1 哪些环节必须保留人工搭了这套智能体之后我最大的感受是智能体不是来取代人的是来把人从重复劳动里解放出来的。信贷审批里有几个环节我坚持保留人工。首次合作客户的大额授信必须人工。智能体可以给出参考意见但最终决策要人来做。原因很简单首次合作没有历史数据支撑智能体的评分模型对这类客户预测能力有限。我设的规则是单笔超过 100 万且无历史合作记录的智能体只输出参考意见不输出建议额度。涉及抵押物的复杂结构必须人工。抵押物评估涉及产权、变现能力、法律瑕疵等多个维度智能体目前只能处理标准化的住宅和厂房遇到在建工程、股权质押、应收账款质押这些解析和评估都力不从心。我的做法是智能体识别到非标准抵押物就自动转人工。客户主动申诉必须人工。智能体拒绝的进件客户如果申诉必须转人工复核。智能体的拒绝理由可能是流水波动率过高但客户可能解释说是季节性因素这种上下文智能体理解不了得人来判断。监管有明确要求的环节必须人工。有些监管规定要求面签面谈、双人调查这些是智能体替代不了的。我在工作流里把这些环节标记为人工必做智能体只负责准备材料清单和预填表单。5.2 人机协同的工作流设计人机协同不是简单地把智能体输出丢给人看而是要设计好交接点。我在工作流里设了三个交接点。第一个交接点是智能体输出后的确认环节。智能体给出审批意见后不是直接生效而是进入待确认状态由客户经理或审批人确认。确认界面上智能体的意见和依据都展示出来人工可以采纳、修改或驳回。修改和驳回的原因要记录下来这些数据后面可以用来优化智能体。第二个交接点是异常转人工环节。前面说的兜底策略产生的待复核标记会触发转人工。转人工时智能体把已经完成的工作材料解析、部分评分都带过去人工不用从头再来只需要处理异常部分。第三个交接点是定期复盘环节。我每月会抽一批智能体审批的进件跟人工审批的结果做对比看看智能体的判断跟人工的差异在哪里。差异大的案例我会分析是规则问题还是模型问题然后针对性调整。这个复盘机制让智能体的准确率在三个月里从 87% 提升到了 92%。实操心得人机协同的关键是让人的时间花在刀刃上。智能体把能做的都做了人只处理智能体做不了的。我算过一笔账搭了智能体之后单笔进件的平均处理时间从 45 分钟降到了 18 分钟客户经理的时间更多花在客户沟通和实地调查上而不是埋头查制度填表单。5.3 效果评估与持续优化智能体上线不是终点是起点。我建了一套评估指标来持续跟踪效果。准确率是最核心的指标定义是智能体建议结论与最终人工审批结论一致的比例。我按周统计目前稳定在 92% 左右。准确率下降的时候要警惕可能是制度变了知识库没更新也可能是模型版本升级导致行为变化。转人工率是辅助指标定义是触发转人工的进件占比。这个指标太高说明智能体能力不足太低可能说明兜底策略太宽松。我目前控制在 15% 左右其中大部分是首次合作大额授信和复杂抵押物。处理时长是效率指标定义是从进件到出审批意见的平均时间。智能体上线前是 45 分钟现在是 18 分钟其中智能体自动处理部分平均 3 分钟人工确认部分平均 15 分钟。人工修改率是质量指标定义是人工对智能体意见做了修改的进件占比。这个指标反映智能体的建议质量修改率越低说明智能体越靠谱。我目前是 8% 左右修改的主要是额度微调比如智能体建议 50 万人工改成 48 万。优化方向上我主要做两件事。一是规则迭代把人工修改的案例拿出来分析看看是不是某条规则设得太松或太紧然后调整阈值。二是知识库更新制度修订后第一时间更新知识库并且用历史进件回测看看新制度对审批结果的影响。最后分享一个我在实操中体会很深的小技巧给智能体加一个置信度输出。我让模型在输出审批意见的同时给一个 0 到 1 的置信度分数。置信度低于 0.7 的进件自动标记为建议人工重点复核。这个分数不是模型随便给的我在提示词里要求它根据知识库覆盖程度、字段完整度、规则命中明确度三个维度来评估。实测下来低置信度的进件确实问题更多人工重点看这些效率提升很明显。
