前段时间我一直在和华为云智果 AgentArts 死磕一件事把金融信贷场景里的贷前初审流程从人工填表、人工翻材料改造成一个真正能跑的AI智能体。起因很现实——一条消费信贷产品线的申请量翻了一倍之后初审团队已经忙到需要周末加班补材料而大部分时间都在做重复核对收入证明和流水是否对得上、联系人信息是否完整、有没有明显多头借贷的迹象。业务方说能不能让大模型帮我先筛一遍把明显不合格的直接拦掉把需要斟酌的送到人面前复审。直接丢给一个通用聊天机器人是不太现实的。这类问题不只是模型会不会出错更在于审批动作必须可回溯、可解释、可审计。当时我梳理了一圈华为云智果 AgentArts 刚好提供了一个面向智能体编排的落地环境支持把模型能力、规则校验、工具调用、人工复核都串在同一个工作流里。于是我用脱敏业务样本模拟着跑了一遍完整流程这篇学习笔记就是把从需求拆解到工作流搭建、再到测试调优的过程完整记录下来。如果你正在做AI智能体应用又关心信贷风控或审核自动化这篇内容应该能帮你少踩几个坑。1. 为什么要用AI智能体来做金融信贷初审1.1 信贷流程里那些真正耗人的环节先说业务端。信贷审批通常分贷前、贷中、贷后三段。贷前是用户申请和资料进件贷中是风险评估和审批决策贷后是放款后的监控和催收管理。大多数人理解的“智能审批”集中在贷中也就是拿到一堆资料后判断这个人能不能借、借多少。但真正占人力的恰恰是贷前的资信初筛申请人提交的身份证件、收入流水、社保截图、联系方式、工作证明格式五花八门有的还是拍照件需要人工识别、补录、汇总然后才能进入评分环节。一个初审专员一天处理几十份已经是极限而且看久了容易漏。Agent 擅长做的正好就是这类“信息收集—结构化—校验—初判—给结论”的工作。它不是替风控专家做最终决策而是先把脏活累活接过来把机器能明确判断的规则跑完再让人把精力集中在复杂案例和人工沟通上。我这次选择用“消费信贷贷前初审”作为切入点原因很简单流程清晰、规则明确、材料模式相对固定容易验证智能体效果也很容易衡量它的业务价值。当然真实信贷场景非常严谨。我这里做的所有演示都是基于脱敏模拟数据不会涉及真实客户信息真正生产环境中调用征信、流水核验等数据源必须走持牌机构的合规通道。这些在后面工程环节还会反复强调。1.2 智能体、规则脚本、纯大模型这三条路的差别先说传统做法。很多机构现在跑的是“埋点表单规则引擎人工复核”用户填入前端表单后端用一组 if-else 规则判断收入、年龄、行业等硬性指标不满足的直接拒绝满足的推到人工。这个方案的好处是稳定、可解释坏处是僵化——用户填错了几个字段就要来回退件材料是图片时规则引擎根本处理不了。纯大模型方案呢把材料全部丢给 Chat 模型让它直接输出“通过/拒绝”。这在一两个样例上看着聪明但放到生产里就露怯了模型既不会去调外部接口取数也不会稳定地按固定格式返回更说不清自己每一步判断用了哪些材料导致复核变得很困难。Agent 智能体则处于中间外部行为上它有“规划—调用工具—观察结果—再决策”的循环可以一边分析材料一边调用 OCR、人脸核身、黑名单查询等接口内部输出上又可以通过系统提示词和结构化约束强制模型给出 JSON 结果和依据 ID。加上 AgentArts 这类平台本身提供工作流编排和节点状态保存整个执行过程可以一步一步留痕满足了信贷场景非常看重的可解释和可回溯要求。这也是我最后选择智能体路线而不是堆 Prompt 的核心原因。2. 整体设计先拆角色再编排工作流2.1 从信审专员到Agent角色的映射一个信审团队的岗位分工大致是客服接待负责解释流程、收集材料初审专员负责材料完整性和硬性门槛校验反欺诈专员查黑名单和关联风险风控审批人看评分卡和授信额度贷后专员做监控和提醒。对应到智能体设计我建议不要只做一个大而全的万能 Agent而是拆成一组职责单一的小 Agent。我这次拆了四个角色受理 Agent 负责接待和材料收集识别用户意图并引导上传初筛 Agent 负责材料完整度校验、OCR 识别结果核对、硬性准入规则判断风控 Agent 负责调用反欺诈接口结合信用评分模型给出风险等级决策 Agent 负责汇总前面所有结果生成审批建议和复核要点。每个 Agent 的提示词都不一样工具权限也不一样单独调优、单独压测都方便。刚开始我也想少拆几个用一个大模型力挽狂澜。结果发现当几个任务混在同一个提示词里时模型经常在“到底应该拒绝还是转人工”的分支上反复横跳。拆角色之后每个 Agent 只管一个窄边界出错概率明显下降。这就像团队里为什么要有独立风控岗一样——职责边界清晰了责任才清晰。2.2 为什么我把工作流作为第一优先形态AgentArts 上可以两种方式搭建智能体一种是“对话式智能体”让模型自由编排工具调用适合开放域任务另一种是“工作流式编排”把节点用有向无环图串起来步骤执行顺序固定支持条件分支、规则节点、人工审批节点。这在信贷场景下几乎是标准答案。风控流程不接受模型自由发挥提交材料之后必须先查完整性再到反欺诈再到额度评估顺序反了结论就可能错。工作流还有一个好处是每步都有状态和日志出了合规问题可以直接从平台导出执行轨迹。市场上一些纯模型的 Agent 框架跑对话很顺但真要落地金融业务时缺少“强制节点人工审核节点”反而要自己写很多胶水代码。AgentArts 这里能直接托底省了不少事。当然自由编排不是完全不用。比如用户问“我的材料要补什么”这类非结构化咨询我仍然用对话式智能体去回答但所有会产生审批结论的动作全部走工作流。一句话总结对话只负责沟通决策只走流程。2.3 每个Agent的职责边界与数据权限设计 Agent 时还有一个容易被忽略的点数据权限隔离。初筛 Agent 只需要看到材料元数据和 OCR 结果不需要看到用户的完整社交关系风控 Agent 才允许访问反欺诈接口决策 Agent 最后汇总时可以看到所有环节的结果但它的输出只能写到合规的审批结果表中。如果所有 Agent 共享同一个大模型环境变量很容易因为一次越权调用导致数据泄漏。在 AgentArts 平台上我建议把敏感数据的读取放在“工具节点”层面工具是封装好的Agent 只能调用工具接口拿不到底层数据库连接。这样即使模型在提示词里被诱导它能调用的范围也是受限的。再加一层节点级访问控制谁能读哪个字段就由权限模型管不由模型的判断管。这一点对金融场景来说不是加分项是必须项。提示真实生产环境的数据源申请、密钥管理、接口调用合规都需要跟机构的安全团队一起过。员工权限和 Agent 权限要分开管别把管理员账号直接配给智能体用。3. 实操落地从0到1搭一个贷前资信初筛Agent3.1 开通平台与创建智能体时的基础配置第一次打开 AgentArts 控制台时先别急着写提示词把基础信息设好。名称、描述、模型选择、使用场景这几个字段直接影响平台后续给智能体推荐的能力范围。我选的模型偏好里文本理解、工具调用、结构化输出三个能力都要开尤其是结构化输出后面判断结果是否合规全靠它。数据接入方面我用的是离线脱敏样本表一份申请材料 JSON、一份 OCR 识别结果、一份评分卡字段。这些数据放在云上的对象存储里智能体通过平台配置的数据源节点读取不直接对业务库开放。如果生产环境要接真实系统记得先在 IAM 里建好最小权限账号密钥走凭据管理不要直接写在环境变量里。这是金融项目上线前的底线。这一步看起来琐碎但它决定后面跑流程时能不能快速定位问题。我第一版配置时图省事把所有 Agent 挂在同一个项目空间下结果日志串在同一个执行轨迹里排查问题要翻半天。后来按角色拆成四个子应用每个子应用独立发布问题定位立刻快了很多。3.2 核心工作流节点的设计与参数我的主工作流“贷前资信初筛”一共六个节点串成一个有向无环图。节点名称输入处理逻辑参数/阈值输出材料接收用户上传文件校验格式和数量触发 OCR支持 png/jpg/pdf单个文件≤5MB文件清单内容结构化OCR 文本调用文档解析模型抽取收入、单位、家庭住址等字段置信度≥0.9结构化 JSON硬性规则校验结构化 JSON年龄、申请地区、行业黑名单、多头借贷标记年龄18-60多头标记≤3校验结果表反欺诈查询申请人标识调用合规反欺诈接口演示环境用模拟接口风险等级A/B/C/D风险标签风险评分规则结果反欺诈标签评分卡模型阈值600评分与建议人工复核全部环节结果推送给有权限审批人补充意见-最终审批建议表格里的阈值不是拍脑袋定的。年龄 18-60、多头标记≤3这些规则先原样搬过来等积累了踩坑数据再调。“置信度≥0.9”这一步很关键OCR 识别结果低于这个阈值的材料不做自动判断直接进人工避免图片模糊导致误判。在 AgentArts 里每个节点都可以设置超时和重试次数像外部接口调用我习惯设三次重试、每次超时 5 秒超时后节点标记为失败并转人工。参数配置方面的取舍是宁可多转人工不要错杀漏杀。金融场景里漏过一个高风险客户带来的损失远比多复核一份材料的成本高。这也是为什么我把“置信度不足”和“外部接口异常”都归类到“转人工”而不是简单地“拒绝”。3.3 提示词设计与模型行为约束工作流搭好后最关键的就是每个节点的模型提示词。我总结了一套相对稳定的写法角色约束、任务边界、输入输出格式、异常处理、禁止行为。以初筛 Agent 为例系统提示词大概长这样你是一名银行信贷初审助理只负责贷前材料初审不做最终审批决策。 输入申请人OCR识别后的结构化材料JSON。 任务 1. 检查必填字段是否齐全缺字段时列出缺项。 2. 按给定硬性规则逐项判断规则以JSON数组形式提供。 3. 输出固定结构不允许额外解释或编造字段。 输出格式 {decision:approve/review/reject,reason_code:[MATERIAL_INCOMPLETE],missing_fields:[],risk_flags:[],summary:一句话说明} 禁止行为 - 不得读取或猜测与材料无关的个人信息。 - 不得输出空泛建议。 - 不确定时输出review并说明需要人工关注的原因。这个提示词里的关键在于规则以 JSON 数组形式传入而不是全部写在自然语言里。这样模型不会被修辞带偏规则变更时也不需要重新调提示词只要改规则表就行。结构化输出我同时要求平台开启 JSON Schema 校验不符合格式的直接触发重试重试两次还失败就转人工。还有一个细节我刻意要求模型在摘要里写“一句话说明”。这是为了让复核人员不用逐个字段去对直接读取摘要就能判断模型当时的决策思路。先输出结构再输出解释可解释性问题就解决了一大半。反过来让模型先自由解释再自己解析解释内容容易和结论脱节。3.4 结构化输出让模型开口说人话更要开口说准话金融审批结果就三种状态通过、复核、拒绝。分类一一对应到输出层的 decision 字段。为了不出现模型自创的边界情况我在输出节点多做了一层后处理用一段规则代码把模型输出映射到标准枚举包括对未知枚举值的兜底映射。def map_decision(raw): # 标准化模型输出到审批枚举 mapping { approve: PASS, reject: REJECT, review: MANUAL_REVIEW, } # 兜底任何未识别结果一律进入人工复核 return mapping.get(str(raw).strip().lower(), MANUAL_REVIEW)为什么需要这个兜底因为模型大概率会按提示词输出但在异常用词、多语言混合情况下仍可能出现非预期值。如果系统直接把未知枚举当拒绝处理风险就是误伤客户如果当通过处理风险更大。所以兜底到人工复核是最稳妥的。结构化输出之外我还做了字段级置信度回传。评分节点不仅给出分数还给出“材料可信度”0-1 数值字段置信度低于 0.8 的不参与自动决策。这一步看起来增加了输出复杂度但实际上帮我减少了很多误判排查工作。4. 测试调优与上线前的那些坑4.1 用脱敏历史样本建一套评估基线任何 Agent 落地前必须有一份量化基线否则你不知道它到底是变好了还是变坏了。我拿了业务方提供的 200 条脱敏历史记录其中 80 条为最终通过、70 条为拒绝、50 条是转人工后人工通过。让智能体在离线环境重跑一遍把决策和真实结果对齐。评估指标方面我不只看准确率。对于审批场景核心是三组指标通过率一致性模型自动通过的比例应该和历史通过率大致接近避免模型放水或从严。高风险拦截率在历史拒绝样本中模型能识别出多少。这一项是风控最关心的我实测首批在 87% 左右调优后到 91.3%。人工复核率自动判断中需要转人工复核的比例。初版经常到 40%瓶颈是 OCR 置信度不足调优后稳定在 15% 以下。这里强调一下我用的“历史通过”指的是真实业务中通过并正常还款的样本“历史拒绝”里既包含硬性规则拒绝也包含人工综合判断拒绝。如果你手头没有这种带标签的数据至少也要先人工抽 100 条典型样本跑一遍否则后面每次调 Prompt 都不知道改对了没有。4.2 第一轮自测就暴露的三个问题第一轮自测结束时我整理出三个问题估计大家自己做也会撞上。第一个是模型幻觉导致错误标记。有一条材料里申请人实际年龄 39 岁OCR 把身份证年份识别成“19”开头还是没问题的但模型在规则判断时受训练语料影响输出了一个不存在的风险标签。后来我在规则节点前先跑一层确定性校验把硬性规则从模型判断里剥出来模型只负责综合语义判断。规则归规则模型归模型这句话真的是跑通了才懂。第二个是工具调用参数幻觉。模型在调用反欺诈接口时有个参数本该传“申请人姓名身份证号”它有时候会漏传身份证号导致接口报错。排查发现不是模型不会调而是多轮工具返回后上下文过长参数复制错了。我的解法是在工具定义里加上必填参数校验由平台在调用前拦截并让模型重组请求不是等返回结果后才发现问题。这个机制后来几乎没有再触发过。第三个是转人工理由写得太模糊。初版摘要经常是“材料存在风险请人工复核”这种废话复核人员拿到单子还要自己去翻材料。后来我在提示词里强制要求输出 risk_flags 枚举并在后处理里映射成“流水与收入不匹配”“申请人地址在限制区域”等标准话术复核效率才真正上来。4.3 上线之前还得补的合规与工程细节测试通过并不代表能直接上线尤其金融场景。我在正式发布前补了几件事按优先级列出来。审计日志AgentArts 平台本身有执行日志但业务侧还需要把“每次调用、输入材料脱敏 ID、决策结果、复核人 ID”落到独立审计表避免只依赖平台日志。一旦出现争议可以拿审计表说话。人工复核兜底不管模型结果多好我始终保留“高风险客户必须人工决策”的开关。系统里给决策 Agent 加了一条策略风险等级为 D 或置信度低于 0.8直接进人工不允许走自动通过。灰度发布先在 5% 真实流量上跑一周对比模型判断和历史审核的一致性再逐步放大到全量。即便一周平稳之后每次改 Prompt 或规则都要再走一轮灰度。会话隔离不同 Agent 之间不共享上下文防止资料信息被其他场景错误引用。成本会高一点但值得。还有一条要提醒任何涉及个人金融信息的 AI上线前要和合规、法务一起过一遍个人信息保护影响评估。这部分不是技术债是业务能不能活下来的前提。5. 学习笔记的最后一点体会与后续扩展方向5.1 回头再看这次实战我最大的收获整个项目跑下来我最深的体会是做金融信贷 AI 智能体难点不在于让模型变聪明而在于给聪明套上缰绳。AgentArts 这类平台提供的价值也在于此——它把规则节点、工具节点、人工节点和模型输出串成了一根可审计的链条。你可以先让模型负责理解模糊信息再用规则和人工兜底处理不确定性既享受 AI 的效率又保留合规的余地。如果只拿一个模型裸上哪怕加了再长的提示词在这个领域都很难让人放心。5.2 接下来我准备往这几个方向继续折腾后续我还有几个想继续做的方向一是把贷后监控做成 Agent用定时任务跑还款行为数据发现异常自动生成预警工单二是给受理 Agent 配上语音能力让用户可以口述补充收入情况再自动转成结构化字段三是把反欺诈 Agent 从单一黑名单查询扩展成基于关系图谱的关联风险识别。这些都还在探索等跑通一版再专门开一篇。最后再说一个很小的技巧AgentArts 平台里模型输出的 token 长度在金融场景里尽量设置得小一些比如 512 或 1024。固定格式的审批意见根本不需要长文本输出。限制长度不仅省钱还能有效减少模型在尾部生成无关解释的概率。我调小上限之后单次调用耗时下降了大概 30%输出稳定性反而更好。这个经验在其他 Agent 场景里同样适用。 
长河君 · 2026/10/8 20:39:25 · 阅读 1.2k 金融信贷贷前初审AI智能体实战：AgentArts工作流编排与落地全记录
前段时间我一直在和华为云智果 AgentArts 死磕一件事把金融信贷场景里的贷前初审流程从人工填表、人工翻材料改造成一个真正能跑的AI智能体。起因很现实——一条消费信贷产品线的申请量翻了一倍之后初审团队已经忙到需要周末加班补材料而大部分时间都在做重复核对收入证明和流水是否对得上、联系人信息是否完整、有没有明显多头借贷的迹象。业务方说能不能让大模型帮我先筛一遍把明显不合格的直接拦掉把需要斟酌的送到人面前复审。直接丢给一个通用聊天机器人是不太现实的。这类问题不只是模型会不会出错更在于审批动作必须可回溯、可解释、可审计。当时我梳理了一圈华为云智果 AgentArts 刚好提供了一个面向智能体编排的落地环境支持把模型能力、规则校验、工具调用、人工复核都串在同一个工作流里。于是我用脱敏业务样本模拟着跑了一遍完整流程这篇学习笔记就是把从需求拆解到工作流搭建、再到测试调优的过程完整记录下来。如果你正在做AI智能体应用又关心信贷风控或审核自动化这篇内容应该能帮你少踩几个坑。1. 为什么要用AI智能体来做金融信贷初审1.1 信贷流程里那些真正耗人的环节先说业务端。信贷审批通常分贷前、贷中、贷后三段。贷前是用户申请和资料进件贷中是风险评估和审批决策贷后是放款后的监控和催收管理。大多数人理解的“智能审批”集中在贷中也就是拿到一堆资料后判断这个人能不能借、借多少。但真正占人力的恰恰是贷前的资信初筛申请人提交的身份证件、收入流水、社保截图、联系方式、工作证明格式五花八门有的还是拍照件需要人工识别、补录、汇总然后才能进入评分环节。一个初审专员一天处理几十份已经是极限而且看久了容易漏。Agent 擅长做的正好就是这类“信息收集—结构化—校验—初判—给结论”的工作。它不是替风控专家做最终决策而是先把脏活累活接过来把机器能明确判断的规则跑完再让人把精力集中在复杂案例和人工沟通上。我这次选择用“消费信贷贷前初审”作为切入点原因很简单流程清晰、规则明确、材料模式相对固定容易验证智能体效果也很容易衡量它的业务价值。当然真实信贷场景非常严谨。我这里做的所有演示都是基于脱敏模拟数据不会涉及真实客户信息真正生产环境中调用征信、流水核验等数据源必须走持牌机构的合规通道。这些在后面工程环节还会反复强调。1.2 智能体、规则脚本、纯大模型这三条路的差别先说传统做法。很多机构现在跑的是“埋点表单规则引擎人工复核”用户填入前端表单后端用一组 if-else 规则判断收入、年龄、行业等硬性指标不满足的直接拒绝满足的推到人工。这个方案的好处是稳定、可解释坏处是僵化——用户填错了几个字段就要来回退件材料是图片时规则引擎根本处理不了。纯大模型方案呢把材料全部丢给 Chat 模型让它直接输出“通过/拒绝”。这在一两个样例上看着聪明但放到生产里就露怯了模型既不会去调外部接口取数也不会稳定地按固定格式返回更说不清自己每一步判断用了哪些材料导致复核变得很困难。Agent 智能体则处于中间外部行为上它有“规划—调用工具—观察结果—再决策”的循环可以一边分析材料一边调用 OCR、人脸核身、黑名单查询等接口内部输出上又可以通过系统提示词和结构化约束强制模型给出 JSON 结果和依据 ID。加上 AgentArts 这类平台本身提供工作流编排和节点状态保存整个执行过程可以一步一步留痕满足了信贷场景非常看重的可解释和可回溯要求。这也是我最后选择智能体路线而不是堆 Prompt 的核心原因。2. 整体设计先拆角色再编排工作流2.1 从信审专员到Agent角色的映射一个信审团队的岗位分工大致是客服接待负责解释流程、收集材料初审专员负责材料完整性和硬性门槛校验反欺诈专员查黑名单和关联风险风控审批人看评分卡和授信额度贷后专员做监控和提醒。对应到智能体设计我建议不要只做一个大而全的万能 Agent而是拆成一组职责单一的小 Agent。我这次拆了四个角色受理 Agent 负责接待和材料收集识别用户意图并引导上传初筛 Agent 负责材料完整度校验、OCR 识别结果核对、硬性准入规则判断风控 Agent 负责调用反欺诈接口结合信用评分模型给出风险等级决策 Agent 负责汇总前面所有结果生成审批建议和复核要点。每个 Agent 的提示词都不一样工具权限也不一样单独调优、单独压测都方便。刚开始我也想少拆几个用一个大模型力挽狂澜。结果发现当几个任务混在同一个提示词里时模型经常在“到底应该拒绝还是转人工”的分支上反复横跳。拆角色之后每个 Agent 只管一个窄边界出错概率明显下降。这就像团队里为什么要有独立风控岗一样——职责边界清晰了责任才清晰。2.2 为什么我把工作流作为第一优先形态AgentArts 上可以两种方式搭建智能体一种是“对话式智能体”让模型自由编排工具调用适合开放域任务另一种是“工作流式编排”把节点用有向无环图串起来步骤执行顺序固定支持条件分支、规则节点、人工审批节点。这在信贷场景下几乎是标准答案。风控流程不接受模型自由发挥提交材料之后必须先查完整性再到反欺诈再到额度评估顺序反了结论就可能错。工作流还有一个好处是每步都有状态和日志出了合规问题可以直接从平台导出执行轨迹。市场上一些纯模型的 Agent 框架跑对话很顺但真要落地金融业务时缺少“强制节点人工审核节点”反而要自己写很多胶水代码。AgentArts 这里能直接托底省了不少事。当然自由编排不是完全不用。比如用户问“我的材料要补什么”这类非结构化咨询我仍然用对话式智能体去回答但所有会产生审批结论的动作全部走工作流。一句话总结对话只负责沟通决策只走流程。2.3 每个Agent的职责边界与数据权限设计 Agent 时还有一个容易被忽略的点数据权限隔离。初筛 Agent 只需要看到材料元数据和 OCR 结果不需要看到用户的完整社交关系风控 Agent 才允许访问反欺诈接口决策 Agent 最后汇总时可以看到所有环节的结果但它的输出只能写到合规的审批结果表中。如果所有 Agent 共享同一个大模型环境变量很容易因为一次越权调用导致数据泄漏。在 AgentArts 平台上我建议把敏感数据的读取放在“工具节点”层面工具是封装好的Agent 只能调用工具接口拿不到底层数据库连接。这样即使模型在提示词里被诱导它能调用的范围也是受限的。再加一层节点级访问控制谁能读哪个字段就由权限模型管不由模型的判断管。这一点对金融场景来说不是加分项是必须项。提示真实生产环境的数据源申请、密钥管理、接口调用合规都需要跟机构的安全团队一起过。员工权限和 Agent 权限要分开管别把管理员账号直接配给智能体用。3. 实操落地从0到1搭一个贷前资信初筛Agent3.1 开通平台与创建智能体时的基础配置第一次打开 AgentArts 控制台时先别急着写提示词把基础信息设好。名称、描述、模型选择、使用场景这几个字段直接影响平台后续给智能体推荐的能力范围。我选的模型偏好里文本理解、工具调用、结构化输出三个能力都要开尤其是结构化输出后面判断结果是否合规全靠它。数据接入方面我用的是离线脱敏样本表一份申请材料 JSON、一份 OCR 识别结果、一份评分卡字段。这些数据放在云上的对象存储里智能体通过平台配置的数据源节点读取不直接对业务库开放。如果生产环境要接真实系统记得先在 IAM 里建好最小权限账号密钥走凭据管理不要直接写在环境变量里。这是金融项目上线前的底线。这一步看起来琐碎但它决定后面跑流程时能不能快速定位问题。我第一版配置时图省事把所有 Agent 挂在同一个项目空间下结果日志串在同一个执行轨迹里排查问题要翻半天。后来按角色拆成四个子应用每个子应用独立发布问题定位立刻快了很多。3.2 核心工作流节点的设计与参数我的主工作流“贷前资信初筛”一共六个节点串成一个有向无环图。节点名称输入处理逻辑参数/阈值输出材料接收用户上传文件校验格式和数量触发 OCR支持 png/jpg/pdf单个文件≤5MB文件清单内容结构化OCR 文本调用文档解析模型抽取收入、单位、家庭住址等字段置信度≥0.9结构化 JSON硬性规则校验结构化 JSON年龄、申请地区、行业黑名单、多头借贷标记年龄18-60多头标记≤3校验结果表反欺诈查询申请人标识调用合规反欺诈接口演示环境用模拟接口风险等级A/B/C/D风险标签风险评分规则结果反欺诈标签评分卡模型阈值600评分与建议人工复核全部环节结果推送给有权限审批人补充意见-最终审批建议表格里的阈值不是拍脑袋定的。年龄 18-60、多头标记≤3这些规则先原样搬过来等积累了踩坑数据再调。“置信度≥0.9”这一步很关键OCR 识别结果低于这个阈值的材料不做自动判断直接进人工避免图片模糊导致误判。在 AgentArts 里每个节点都可以设置超时和重试次数像外部接口调用我习惯设三次重试、每次超时 5 秒超时后节点标记为失败并转人工。参数配置方面的取舍是宁可多转人工不要错杀漏杀。金融场景里漏过一个高风险客户带来的损失远比多复核一份材料的成本高。这也是为什么我把“置信度不足”和“外部接口异常”都归类到“转人工”而不是简单地“拒绝”。3.3 提示词设计与模型行为约束工作流搭好后最关键的就是每个节点的模型提示词。我总结了一套相对稳定的写法角色约束、任务边界、输入输出格式、异常处理、禁止行为。以初筛 Agent 为例系统提示词大概长这样你是一名银行信贷初审助理只负责贷前材料初审不做最终审批决策。 输入申请人OCR识别后的结构化材料JSON。 任务 1. 检查必填字段是否齐全缺字段时列出缺项。 2. 按给定硬性规则逐项判断规则以JSON数组形式提供。 3. 输出固定结构不允许额外解释或编造字段。 输出格式 {decision:approve/review/reject,reason_code:[MATERIAL_INCOMPLETE],missing_fields:[],risk_flags:[],summary:一句话说明} 禁止行为 - 不得读取或猜测与材料无关的个人信息。 - 不得输出空泛建议。 - 不确定时输出review并说明需要人工关注的原因。这个提示词里的关键在于规则以 JSON 数组形式传入而不是全部写在自然语言里。这样模型不会被修辞带偏规则变更时也不需要重新调提示词只要改规则表就行。结构化输出我同时要求平台开启 JSON Schema 校验不符合格式的直接触发重试重试两次还失败就转人工。还有一个细节我刻意要求模型在摘要里写“一句话说明”。这是为了让复核人员不用逐个字段去对直接读取摘要就能判断模型当时的决策思路。先输出结构再输出解释可解释性问题就解决了一大半。反过来让模型先自由解释再自己解析解释内容容易和结论脱节。3.4 结构化输出让模型开口说人话更要开口说准话金融审批结果就三种状态通过、复核、拒绝。分类一一对应到输出层的 decision 字段。为了不出现模型自创的边界情况我在输出节点多做了一层后处理用一段规则代码把模型输出映射到标准枚举包括对未知枚举值的兜底映射。def map_decision(raw): # 标准化模型输出到审批枚举 mapping { approve: PASS, reject: REJECT, review: MANUAL_REVIEW, } # 兜底任何未识别结果一律进入人工复核 return mapping.get(str(raw).strip().lower(), MANUAL_REVIEW)为什么需要这个兜底因为模型大概率会按提示词输出但在异常用词、多语言混合情况下仍可能出现非预期值。如果系统直接把未知枚举当拒绝处理风险就是误伤客户如果当通过处理风险更大。所以兜底到人工复核是最稳妥的。结构化输出之外我还做了字段级置信度回传。评分节点不仅给出分数还给出“材料可信度”0-1 数值字段置信度低于 0.8 的不参与自动决策。这一步看起来增加了输出复杂度但实际上帮我减少了很多误判排查工作。4. 测试调优与上线前的那些坑4.1 用脱敏历史样本建一套评估基线任何 Agent 落地前必须有一份量化基线否则你不知道它到底是变好了还是变坏了。我拿了业务方提供的 200 条脱敏历史记录其中 80 条为最终通过、70 条为拒绝、50 条是转人工后人工通过。让智能体在离线环境重跑一遍把决策和真实结果对齐。评估指标方面我不只看准确率。对于审批场景核心是三组指标通过率一致性模型自动通过的比例应该和历史通过率大致接近避免模型放水或从严。高风险拦截率在历史拒绝样本中模型能识别出多少。这一项是风控最关心的我实测首批在 87% 左右调优后到 91.3%。人工复核率自动判断中需要转人工复核的比例。初版经常到 40%瓶颈是 OCR 置信度不足调优后稳定在 15% 以下。这里强调一下我用的“历史通过”指的是真实业务中通过并正常还款的样本“历史拒绝”里既包含硬性规则拒绝也包含人工综合判断拒绝。如果你手头没有这种带标签的数据至少也要先人工抽 100 条典型样本跑一遍否则后面每次调 Prompt 都不知道改对了没有。4.2 第一轮自测就暴露的三个问题第一轮自测结束时我整理出三个问题估计大家自己做也会撞上。第一个是模型幻觉导致错误标记。有一条材料里申请人实际年龄 39 岁OCR 把身份证年份识别成“19”开头还是没问题的但模型在规则判断时受训练语料影响输出了一个不存在的风险标签。后来我在规则节点前先跑一层确定性校验把硬性规则从模型判断里剥出来模型只负责综合语义判断。规则归规则模型归模型这句话真的是跑通了才懂。第二个是工具调用参数幻觉。模型在调用反欺诈接口时有个参数本该传“申请人姓名身份证号”它有时候会漏传身份证号导致接口报错。排查发现不是模型不会调而是多轮工具返回后上下文过长参数复制错了。我的解法是在工具定义里加上必填参数校验由平台在调用前拦截并让模型重组请求不是等返回结果后才发现问题。这个机制后来几乎没有再触发过。第三个是转人工理由写得太模糊。初版摘要经常是“材料存在风险请人工复核”这种废话复核人员拿到单子还要自己去翻材料。后来我在提示词里强制要求输出 risk_flags 枚举并在后处理里映射成“流水与收入不匹配”“申请人地址在限制区域”等标准话术复核效率才真正上来。4.3 上线之前还得补的合规与工程细节测试通过并不代表能直接上线尤其金融场景。我在正式发布前补了几件事按优先级列出来。审计日志AgentArts 平台本身有执行日志但业务侧还需要把“每次调用、输入材料脱敏 ID、决策结果、复核人 ID”落到独立审计表避免只依赖平台日志。一旦出现争议可以拿审计表说话。人工复核兜底不管模型结果多好我始终保留“高风险客户必须人工决策”的开关。系统里给决策 Agent 加了一条策略风险等级为 D 或置信度低于 0.8直接进人工不允许走自动通过。灰度发布先在 5% 真实流量上跑一周对比模型判断和历史审核的一致性再逐步放大到全量。即便一周平稳之后每次改 Prompt 或规则都要再走一轮灰度。会话隔离不同 Agent 之间不共享上下文防止资料信息被其他场景错误引用。成本会高一点但值得。还有一条要提醒任何涉及个人金融信息的 AI上线前要和合规、法务一起过一遍个人信息保护影响评估。这部分不是技术债是业务能不能活下来的前提。5. 学习笔记的最后一点体会与后续扩展方向5.1 回头再看这次实战我最大的收获整个项目跑下来我最深的体会是做金融信贷 AI 智能体难点不在于让模型变聪明而在于给聪明套上缰绳。AgentArts 这类平台提供的价值也在于此——它把规则节点、工具节点、人工节点和模型输出串成了一根可审计的链条。你可以先让模型负责理解模糊信息再用规则和人工兜底处理不确定性既享受 AI 的效率又保留合规的余地。如果只拿一个模型裸上哪怕加了再长的提示词在这个领域都很难让人放心。5.2 接下来我准备往这几个方向继续折腾后续我还有几个想继续做的方向一是把贷后监控做成 Agent用定时任务跑还款行为数据发现异常自动生成预警工单二是给受理 Agent 配上语音能力让用户可以口述补充收入情况再自动转成结构化字段三是把反欺诈 Agent 从单一黑名单查询扩展成基于关系图谱的关联风险识别。这些都还在探索等跑通一版再专门开一篇。最后再说一个很小的技巧AgentArts 平台里模型输出的 token 长度在金融场景里尽量设置得小一些比如 512 或 1024。固定格式的审批意见根本不需要长文本输出。限制长度不仅省钱还能有效减少模型在尾部生成无关解释的概率。我调小上限之后单次调用耗时下降了大概 30%输出稳定性反而更好。这个经验在其他 Agent 场景里同样适用。