前阵子跟一位城商行的信贷审批团队负责人聊天对方提到一个数字一笔个人消费贷的进件初审从材料齐全到出具初审报告平均要花40分钟其中一半时间耗在重复性的信息核对上。这个场景太典型了——信贷业务的本质是“风险判断”但一线人员大量时间被“材料录入、信息校验、规则比对、报告誊写”这些标准化动作占据。我正好在华为云AgentArts智果平台上把一个金融信贷AI智能体跑通了从进件到初审报告压缩到几分钟级别人工只需要复核关键结论。这篇文章就把整个实战过程拆开来讲包括为什么选AgentArts、工作流怎么搭、知识库怎么喂、外部系统怎么接以及我在落地过程中踩过的那几个坑。适合正在做金融AI落地的解决方案工程师、信贷系统开发以及想搞清楚智能体到底能在信贷业务里干多少活的业务负责人。1. 信贷流程里的AI落点不是替代审批而是把人从重复劳动里解放出来1.1 先盘点信贷业务中的重复性环节信贷业务的全流程大致分成获客、进件、初审、审批、放款、贷后管理几个阶段。我之前在多家金融机构做过流程梳理发现真正消耗人力的大头集中在这几类动作上进件材料处理客户提交的身份证、收入证明、银行流水、征信授权书大量是非结构化文件需要人工逐字段录入系统做格式校验、真实性初筛。信息交叉核验把OCR识别出来的身份证号、银行卡号、手机号、地址等信息与公安、征信、运营商等外部系统做比对确认“人是本人、材料是本人的”。硬性条件过滤年龄是否在区间内、是否命中黑名单、授信额度是否超上限、征信是否有当前逾期。这些规则是固定的但每单都要人去看。初审报告撰写把前面的核验结果和风险评估整理成一份结构化的初审报告供审批员决策。这个报告格式高度统一只是数据不同。这些环节的一个共同特点是规则明确、重复度高、容错率也高。它们占用了审批员大量的时间导致真正需要专业判断的部分反而被压缩。1.2 AI能切入的边界在哪里在动手之前我先明确了一个原则智能体做“能标准化的事”人做“需要判断的事”。这不是保守而是信贷业务的底线逻辑。审批是跟钱和法律责任直接挂钩的决策AI可以在信息处理和信息呈现层面大幅提效但最终的风险判断必须由持牌机构的人员来完成。环节AI介入度原因材料OCR识别与信息抽取高结构化信息提取技术成熟错误可校验数据格式校验与硬性规则过滤高规则明确适合自动化征信报告初读与异常标记中提取关键指标可行但综合判断需人工初审报告起草高格式固定数据可填充授信额度与利率定价低涉及风险偏好与模型策略需人来定复杂案件的最终审批低需要综合判断专家经验AI只能辅助所以我的定位很明确这个智能体不是一个“自动审批机器人”而是一个“信贷初审助手”。它把进件到初审报告这段路上的脏活累活全包了审批员拿到手的是一份已经核验过、标注过风险点的材料只需要做最后的判断。1.3 智能体技术上要解决哪几件事这个定位落实到技术实现就拆成了几个明确的任务多节点流程编排智能体要按顺序执行OCR、校验、规则过滤、风险评估、报告生成中间还有条件分支这不是单次大模型调用能搞定的。动态知识检索信贷政策和产品规则会变智能体要能根据客户实际情况检索到对应的政策条款而不是每次都重新写死在提示词里。外部工具调用需要调用OCR服务、征信接口、内部进件系统智能体要具备“工具使用能力”。结构化输出控制初审报告字段多、格式固定不能用自由文本糊弄要保证每次输出都能落到系统字段里。这四件事决定了不能拿一个裸的大模型API就去开发需要一个真正的智能体平台来承载。这也是我选择华为云AgentArts来做这件事的原因。2. 为什么最终选了AgentArts而不是自己拼一套2.1 裸大模型方案的问题在哪最开始我也考虑过“简单粗暴”的路线直接调用大模型的API写一个编排脚本来串流程。但仔细想了一下这条路有几个绕不开的坎流程状态管理一个初审流程涉及多个步骤每步的输入输出要做字段映射和上下文传递。自己写代码不是不行但一旦流程复杂起来状态维护的成本直线上升。工具调用的稳定性OCR接口超时怎么办征信接口返回错误码怎么处理要不要重试这些在生产环境里都是必须考虑的问题裸调大模型API解决不了。知识库的更新和检索信贷政策几个月一变每次改政策都要去改提示词既不安全也不可维护。需要一个独立的知识库组件让内容和代码解耦。评测和版本管理大模型输出不稳定换了模型版本或调了提示词效果是变好还是变坏需要有一套评测机制来兜底。自己从零搭这套东西投入很大。一句话总结做Demo可以拼代码做生产系统得用平台。企业级应用真正缺的不是模型能力而是把这些能力组件化、流程化、可运维化的平台层能力。2.2 AgentArts能提供什么AgentArts是华为云上的AI智能体开发平台。它的核心思路是把“智能体”拆成几个构件大模型能力、知识库、工具插件、工作流编排再加上调试和运营管理的配套。我在实际使用中最看重的几项能力可视化工作流编排用拖拽节点的方式把“OCR识别→信息校验→规则过滤→风险评估→报告生成”串起来每个节点可以单独配置提示词、参数和分支逻辑。这种编排方式对业务人员和开发人员都比较友好流程改起来也不动代码。知识库组件支持上传信贷政策文档自动完成切片和向量化检索时能关联引用来源。这对金融场景太重要了——你必须能说清楚“这个结论基于哪一条政策”。工具插件体系可以封装外部API为工具节点像OCR服务、征信查询接口都能挂进去智能体在流程中自动按需调用支持超时和错误处理配置。评测与调试可以建一组测试用例批量跑智能体对比不同版本的效果。这个功能在后期迭代时极其关键。另外一个隐性优势是它跟华为云生态的配合。数据存在OBS、数据库、云搜索服务里向量检索、权限管理、日志审计这些基础设施都是现成的不需要再从零搭一套。2.3 和自建LangChain生态的对比自建LangChain生态确实是很多技术团队的默认选项我也用过LangChain做原型优点很突出社区活跃、组件多、灵活度高。但放到金融生产环境里有几个问题比较现实维护成本LangChain版本迭代快组件API变动频繁每个版本升级都可能带来兼容性问题。团队需要持续投入精力跟进这在企业项目里是实打实的成本。企业级能力缺失权限管理、审计日志、多环境隔离这些能力需要自己开发而金融机构对这些有硬性要求。模型和基础设施绑定如果后续要切换到华为云的盘古大模型或者国产化算力环境自建方案要做不小的改动。AgentArts给我的感觉是“框架已经搭好我只需要往里面填业务逻辑”。它可能没有自建方案那么高的自由度但换来的是稳定性和可运维性。对于金融信贷这种“稳定压倒一切”的场景这个取舍是值得的。3. 开工前的地基账号开通、空间规划与团队分工3.1 服务开通与基础资源配置AgentArts的使用门槛并不高开通路径在华为云控制台里就能完成。但有几个细节建议提前确认否则后面容易卡壳区域选择优先选择离业务部署地最近的区域考虑到金融业务对数据驻留有要求区域选完之后尽量不要改后面知识库、工作流都在这个区域下管理。模型配置AgentArts平台本身是模型无关的可以对接华为云的盘古大模型也能对接其他主流模型服务。金融场景建议优先考虑对中文长文本理解、结构化输出控制能力强的模型并且要关注模型服务在业务时段的并发和响应耗时。存储规划提前创建OBS桶用来存放知识库原始文档和进件样本。知识库文档按“产品线政策类别”建目录方便后续管理和权限控制。我在实际项目里踩过一个小的点知识库文档的命名和版本管理一定要从第一天就规范起来。当时我们上传了几十份信贷政策文档文件名五花八门后面做版本更新时根本分不清哪份才是最新的最后花了一个下午重新整理。这件事虽小但越早规范化越好。3.2 项目空间与权限设计AgentArts支持多空间隔离。我在项目里按“开发环境”、“测试环境”、“生产环境”做了划分每个环境的数据和配置是隔离的流程改动先在开发环境验证再发布到生产。权限这块我的建议是遵从最小化原则管理员负责平台配置、模型管理、权限分配整个项目一两个人就够。开发者负责工作流编排、提示词调优、工具接入。业务标注者负责知识库内容维护、评测集标注这类角色通常是熟悉信贷业务的运营或产品同学。审计员金融机构内部通常会要求有独立的审计角色可查看日志和操作记录但不能修改配置。3.3 团队怎么配合才高效智能体项目跟传统软件开发最大的区别是它需要业务知识和高频迭代深度绑定。传统项目可以“业务提需求、开发写代码、测试验功能”但智能体的行为是靠提示词和知识库驱动的这些内容必须由懂业务的人持续打磨。我们当时的团队配置是一周内搭起来的角色人数主要职责产品/业务专家1梳理信贷流程节点提供真实进件样本和政策文档提示词工程师1负责各节点的提示词设计与调优平台开发1负责工作流编排、工具接入、字段映射风控专家1参与评测集设计对初版输出做业务验收这个配置在两周内就把第一个版本跑起来了。如果团队里没有专职的提示词工程师也可以让开发兼任但一定要有一位懂信贷业务的人深度参与否则智能体输出的东西很容易“技术上正确、业务上不可用”。4. 核心工作流搭建从进件到初审报告的全自动链路4.1 场景定义以“个人消费贷初审助手”为例为了让说明更具体我用一个实际的设计场景来讲个人消费贷初审助手。客户通过线上渠道提交申请上传身份证正反面、银行流水、收入证明等材料。系统需要完成从材料接收到初审报告生成的全过程供审批员复核。整个工作流我拆成了六个节点输入节点接收客户申请信息和上传的材料文件。OCR识别节点调用OCR服务识别身份证、银行卡、流水等材料输出结构化文本。信息校验节点校验识别结果包括字段完整性、格式合法性、身份证与姓名的一致性等。规则过滤节点跑一遍硬性准入规则比如年龄范围、黑名单查询、征信当前逾期情况。风险评估节点调用外部风控模型接口获取评分和风险标签。报告生成节点把前面所有节点的结果组装成一份结构化的初审报告并自动发送通知给审批员。这在AgentArts里就是一个串行的工作流配合几个条件分支节点比如“规则过滤不通过→直接生成拒绝建议报告”避免把不合格的进件继续往后推。4.2 各节点的配置细节每个节点在AgentArts里都是一个独立的可配置单元。挑几个关键节点说一下配置思路OCR识别节点。这里不是让大模型直接看图片而是通过工具节点调用专门的OCR服务。工具节点需要配置API地址、鉴权信息、输入输出字段映射。输出字段我定义成了结构化对象包括“证件类型”、“证件号码”、“姓名”、“签发日期”等方便后续节点直接引用。信息校验节点。这个节点用提示词驱动大模型执行校验逻辑同时配合函数调用做字段级校验。我的做法是把校验规则写进提示词让模型先给出“校验是否通过”的结论再用一个后置代码节点做二次强制校验。比如身份证号码的校验码规则是确定性的直接用代码算更靠谱不要依赖模型。【系统提示】 你是一名信贷进件审核助手。用户的身份证号码为{id_number} 姓名为{name}。请完成以下校验 1. 身份证号码格式是否合法18位最后一位校验位正确 2. 姓名与身份证号码是否逻辑一致性别位、出生日期是否与申请信息一致 3. 年龄是否在18-65周岁区间内 请输出JSON格式 {check_result: pass|fail, failed_fields: [], reason: ...}这里有个细节JSON格式的输出约定必须固化在提示词里同时要求模型只输出JSON、不输出任何解释文字。实际测试中发现如果不加“只输出JSON”这个约束模型偶尔会在JSON外面包一段废话后置的解析层就会报错。规则过滤节点。这个节点我用的是“代码节点大模型节点”的组合。硬性规则黑名单、年龄、额度上限用代码节点执行因为它们是确定性的逻辑规则的解释和补充建议用大模型节点生成。为什么这么分因为硬性规则如果交给大模型去判断存在概率性错误这在准入环节是不能接受的。确定性的规则就交给确定性的代码大模型只做它擅长的事——生成自然语言的解释和建议。4.3 报告生成节点结构化输出是生命线初审报告是整个流程的终点也是审批员最直接的使用界面。这个节点的提示词设计我花了最多时间打磨核心目标只有一个每次输出的字段都完整、格式都一致。报告我固定成五个区块客户基本信息、材料核验情况、硬性规则检查结果、风险评估摘要、审批建议。每个区块都有明确的字段约束缺一不可。【报告生成要求】 请根据以下数据生成初审报告严格使用JSON格式输出 { report_id: {report_id}, customer_name: ..., customer_id: ..., material_check: { ocr_status: ..., id_verified: true|false, income_verified: true|false, notes: ... }, rule_check: { passed: true|false, failed_rules: [], details: ... }, risk_assessment: { score: 0-100, risk_level: low|medium|high, key_factors: [...] }, approval_suggestion: approve|reject|manual_review, suggestion_reason: ... }字段对象的好处是后置处理可以直接把JSON解析进系统不需要再做大段文本清洗。但如果只靠提示词约定模型偶尔还是会漏字段。我在后置加了一个代码节点做字段完整性校验解析出来的JSON缺字段就自动打回重跑一次。这个“提示词兜底代码强制校验”的组合让报告生成的准确率稳定到了99%以上。4.4 为什么要强制保留人工复核节点工作流里我特意设计了一个人工复核节点智能体生成初审报告之后不会直接流转到放款环节而是先推送给审批员审批员在页面上看到报告可以同意、驳回或修改。这个设计有几个考虑一是合规要求。信贷决策链路必须保留人工环节这是监管的底线逻辑。二是信任积累。让审批员在系统上线初期有充分的控制权他们才会逐步信任这个智能体而不是把它当成一个来抢工作的对手。三是数据回流。审批员每一次“修改”都是一次标注我可以在后续迭代中分析这些修改持续优化提示词和知识库。这个闭环是整个智能体持续变好的关键。5. 知识库建设让智能体真正理解信贷业务5.1 知识库里应该放什么信贷智能体要回答的问题分两种一种是“基于客户数据的事实判断”比如年龄够不够、征信有没有当前逾期另一种是“基于政策条款的规则判断”比如这个产品允不允许学生申请、收入负债比的上限是多少。前一种靠数据和规则就能算出来后一种必须依赖知识库。我在知识库里主要放了四类内容产品政策文档每个信贷产品的管理办法、准入条件、额度利率区间。业务流程规范进件、审核、放款、贷后各环节的操作指引。合规要求说明消费者权益保护、信息授权、催收合规等相关内部制度。高频FAQ客户经理和客服日常遇到的常见问题标准答复。这些文档的来源通常都是金融机构内部已有的制度文件但原始格式五花八门有PDF、Word、Excel还有扫描件。需要先统一转换成文本格式再上传到知识库。5.2 文档切分这个环节直接影响检索质量知识库的检索效果一半取决于文档怎么切。我见过很多知识库效果差的情况根子都在切分上——要么一刀切成了几百字的碎片语义被割裂要么一个文档一整块塞进去检索时匹配不准。我在信贷知识库上用的策略是“按语义块切分以产品为粒度建索引”先把文档按章节拆成逻辑块比如“准入条件”、“额度规则”、“利率规则”各为一块。每个逻辑块控制在500-1000字左右保证语义完整。同一产品的所有切块打上产品标签检索时先按产品过滤再做向量召回。实际效果差别很大。最开始我直接用默认切分参数跑知识库命中率只有六七成改成按产品标签过滤之后命中率上了九成。原因也简单不同产品之间条款高度相似如果不先按产品隔离向量检索很容易把A产品的规则匹配到B产品的问题上。5.3 RAG调优的实操参数如果你之前没调过RAG这几个参数是必调的Top-K检索返回的候选片段数。信贷场景建议设3-5太大容易混入不相关内容太小可能漏掉关键条款。相似度阈值低于阈值的片段直接不返回宁可“答不上来”也不要“乱答”。这是金融场景的底线逻辑——不确定的事情要明确告诉用户不确定。引用来源AgentArts的检索结果会带上原始文档的引用信息。我在报告生成节点里强制要求模型把每条结论对应的引用来源一并输出审批员点开就能看到原文条款。5.4 知识库更新机制信贷政策是会变的而且往往说变就变。我建了一套简单的更新流程政策文档有更新时由业务专家确认新版本→上传新文档→在知识库里停用旧版本→用一组固定的测试问题跑回归。这套流程看起来朴素但保证了一件事智能体引用的永远是最新有效的政策版本不会出现“政策都改了、智能体还在按旧政策回答”的尴尬情况。6. 接外部系统OCR、征信与内部系统怎么打通6.1 信贷智能体离不开的几类工具智能体要真正替人干活必须“手”够长。我们在AgentArts里把外部能力统一封装成了工具节点目前接了四类OCR识别服务识别身份证、银行卡、银行流水、收入证明。征信查询接口获取客户征信报告的概要数据和关键异常项。内部进件系统写入初审结果下发审批任务。消息通知服务向审批员发送待办通知。工具节点在AgentArts里的配置方式很直接填API地址、配置鉴权、定义输入输出字段然后在工作流里像调用本地函数一样使用。输出数据结构同样定义成JSON方便后续节点直接引用字段。6.2 工具接入时的几个工程细节工具接入看起来是“填个URL就行”但生产环境里细节很多鉴权方式。金融系统之间的接口调用普遍用的是AK/SK签名或者OAuth。我在配置时最注意的一点是鉴权信息不要写在工作流配置里直接暴露给所有开发者而是放到凭证管理服务里工作流通过引用凭证ID来调用。这样既不影响使用权限也能收得住。超时重试。OCR服务和征信接口偶尔会超时如果不做处理一个环节卡住整个工单就卡住了。我的配置策略是设置合理的超时时间建议OCR 10秒、征信接口 5秒超时后自动重试2次重试仍然失败的走“人工兜底”分支——把工单标记为需要人工处理并通知对应审批员。宁可让人多干一单也不能让工单无声无息地卡死。错误码映射。外部接口返回的错误码在工具节点里要映射成业务可读的信息。比如征信接口返回“用户授权已过期”就不要让它变成一串技术人员才看得懂的代码而是直接转换成“该客户征信授权已过期请重新获取授权”的提示塞进初审报告的备注里。6.3 工具失败处理三层兜底设计我在工作流里对每个工具节点都做了三层兜底层级策略适用场景第一层超时自动重试网络抖动、服务瞬时不稳第二层降级为替代方案OCR失败改用人工录入入口第三层转人工处理征信接口异常转人工查询这套兜底逻辑保证了流程的韧性。实际运营数据里OCR服务偶发的失败率在1%左右有了重试和降级机制后真正需要人工介入的比例降到了千分之几。7. 金融合规与数据安全这三关不过别想上线7.1 数据脱敏与隐私保护信贷场景里跑的是最敏感的客户数据身份证号、手机号、银行卡号、收入流水、征信报告。这些东西一旦泄露不是罚钱的问题是机构信誉和法律责任的问题。我的做法是“三个层面”同时做第一层源数据脱敏。工具节点调用外部服务时返回的数据如果包含敏感字段在工作流的中间环节就做字段级脱敏。比如审批报告中只展示身份证号的前三位和后四位中间用星号代替。第二层日志脱敏。AgentArts的运行日志会记录每个节点的输入输出。我配了一套日志脱敏规则凡是匹配身份证号、手机号、银行卡号格式的字段在日志里自动脱敏。这样即使日志被导出敏感信息也不会完整暴露。第三层权限隔离。不是所有开发和运维人员都能看到完整的客户数据。工作流里每个节点的数据访问权限单独控制某些包含敏感数据的节点只有授权角色能查看。7.2 审计追踪每次决策都可回溯金融系统的核心原则是“可审计”智能体也不能例外。我在上线前特意确认了三个审计能力都具备谁调用了智能体操作人、时间、入口、输出了什么结论完整报告原文、依据了什么材料知识库引用来源、工具调用记录。这套审计日志的价值在事后复盘时特别明显。有一次风控部门质疑某笔进件的初审结果我能把当时的完整链路拉出来哪个OCR节点识别了什么、哪条规则被触发、哪份政策文档被引用一目了然。没有这套机制AI系统在金融场景里就是“黑盒”业务部门不会也不敢用。7.3 人机协同与解释性前面提到过“人工复核节点”现在多说一句“解释性”的设计。我要求报告生成节点输出建议理由时必须包含两个要素一是触发了哪条具体规则二是引用了哪条政策依据。比如“拒绝建议年龄52岁符合准入区间但有3笔当前逾期记录触发‘近6个月逾期次数不超过2次’规则引用《个人消费贷产品管理办法》第4.2条”。这种解释性的输出对业务人员非常友好。审批员看到的不再是“AI说要拒绝”这个冷冰冰的结论而是“AI说拒绝理由是这些依据是那条”。即使结论判断错了人也容易发现错在哪、怎么改。7.4 上线前的评测与回归测试AI系统上线前最怕的是“无标准验收”。我的做法是建立了一套固定的评测集从真实进件数据里筛选了100个典型样本覆盖正常件、材料不全、征信异常、规则触发等各类情况。每个样本标注好“期望结果”每次智能体版本更新后用这套评测集跑一遍回归对比输出准确率和字段完整率。这个过程不一定需要自动化框架开始的时候用Excel记录比对结果都行。关键是有一个固定的基准否则每一次调提示词都是“拍脑袋”改坏了都不知道。8. 三个让我印象深刻的生产事故与解法8.1 知识库召回“张冠李戴”A产品的规则答到B产品上第一个印象深刻的问题出现在知识库刚上线的时候。测试一个关于“教育分期产品”准入条件的问题智能体返回的答案里混进了“装修贷”的额度条款。当时的初版知识库把所有产品文档放在同一个索引下切分粒度也粗向量检索时A产品和B产品的高相似文本互相干扰导致召回内容混乱。排查链路是这样的先在AgentArts的后台看检索返回的Top-K结果发现返回的前5个片段里混了3个不同产品的条款再往下查发现切分逻辑没有按产品打标所有文档混在一起建了一个索引最后把索引策略改成“按产品拆分文档集合检索前按产品过滤”这个现象就消失了。这件事之后我养成了一个习惯每次知识库检索异常第一件事永远是看召回片段不要盯着生成的答案看。答案是果召回是因。8.2 流程编排超时OCR服务偶发变慢导致整单卡死第二个问题发生在联调阶段。OCR服务在高峰期偶发性地变慢单个任务从正常的3秒飙到15秒以上。我当时给节点设的超时时间是10秒超时直接报错整个工作流失败。结果就是高峰期一批工单连续失败审批员那边显示“系统异常”体验非常差。后来我做了两处调整一是把超时重试做成“递增式”——第一次超时等3秒重试第二次等6秒最多重试2次二是增加降级分支重试仍失败的工单不直接报错而是转入“人工录入”队列由后台人员手动处理。调整之后能跑通的任务比例回到了99%以上剩下的1%也有了明确的处理路径。8.3 长文本报告输出不稳定模型漏字段第三个问题是最让我头疼的报告生成节点在短输入下表现稳定一旦客户资料复杂、材料备注信息特别多模型偶尔会在生成报告时漏掉某个字段——比如漏掉“材料核验情况”区块里的收入核验结论。如果只靠人工质检这种偶发问题很难抓但漏字段的报告中转到审批员那里人家一眼就看出来不完整信任度一下就下来了。最后的解法是双保险提示词里把每个字段的必需性用“必填”明确标出来同时在代码节点里做“JSON Schema校验”解析出来的JSON如果缺指定字段自动触发一次“补全重跑”。重跑时把缺失字段单独作为重点提示词追加进去。这套组合下来字段完整率从95%左右提升到了99%以上后续再没出现过因为漏字段被打回的工单。这三件事给我的共同教训是智能体系统的问题大部分不是模型本身的问题而是工程链路的问题。知识库怎么组织、超时怎么处理、输出怎么校验这些“工程小事”恰恰决定了系统能不能在生产环境里稳定跑下去。9. 最后的经验沉淀这个信贷智能体上线后我最大的感受是它并没有让审批员“失业”而是把他们的工作内容从“录材料、盯格式、翻规则”变成了“看风险、做判断、查异常”。审批员的满意度反而提升了因为精力终于用在了人该做的事情上。如果要给后来者一个建议我会说别一开始就想做一个“全流程智能审批”那既复杂又危险。先从“初审助手”这样的高频、边界清晰、人工兜底能力强的场景切入跑通之后再逐步扩展。AI在金融领域能做的事很多但前提是每一步都走稳每一笔决策都可解释、可回溯、有人负责。