一个信贷审核项目差点被 Agent 平台的选择拖死。当时我们团队对比了好几家智能体开发平台有的是模型壳子换皮有的编排能力弱得连条件分支都要写半天最后还是落到华为云智果 AgentArts 上。这套东西把金融信贷 AI 智能体实战跑通之后我最大的感受是选平台真不是在选“模型有多强”而是看它能不能把业务拆成可控的智能体链路并且真的让金融场景的合规要求落地。这篇就把我们怎么从 0 到 1 搭一个信贷审核智能体的过程完整写出来结合项目中踩过的坑、调过的参数、改过的流程给想用 AgentArts 做金融信贷场景的朋友一个可以抄作业的参考。1. 为什么是 AgentArts金融信贷场景的选型思路1.1 信贷 AI 智能体到底要解决什么问题金融信贷的业务链条很长从进件、反欺诈、信用评估到审批、放款、贷后每个环节都涉及大量文档和规则判断。过去靠人工处理一份完整的信贷进件材料平均需要 20 到 40 分钟这还不算多轮补件、交叉核验的时间。我们最初想用大模型 API 直接做写一个 Prompt 把材料丢进去让模型给结论结果发现完全不是那么回事。模型输出不稳定、材料解析不彻底、规则一变就得改代码而且审批链条涉及多个系统光靠一个模型根本衔接不起来。后面我们把问题重新定义了一遍与其说需要“一个模型”不如说需要“一个能编排模型、工具、规则和人的系统”也就是智能体。信贷审核智能体的核心价值不是替代审批经理而是把材料接收、信息抽取、初步核验、风险提示这些确定性高、重复性强的工作自动化。比如客户上传身份证、银行流水、征信授权书智能体先做 OCR 识别再做字段抽取然后自动比对反欺诈规则列表最后生成一份带风险点的初审摘要。整个过程可回溯、可审计审批经理只需要看摘要和风险点做最终决策工作量能减掉一半以上。AgentArts 平台在这类场景里的价值是它可以让你把一个完整的信贷流程拆成多个智能体每个智能体负责一个相对聚焦的任务再用工作流把它们串起来。任务之间可以传变量、跑条件分支、调外部工具整个链路的状态是可见的。这和单纯调大模型 API 完全是两个量级的工程问题。1.2 对比直接调大模型 APIAgent 平台多给了什么如果只是写代码调大模型 API你也能做出一个“看起来会干活”的东西但一旦进入金融信贷这种生产环境差距立刻拉开。我总结 AgentArts 这类平台相对裸调 API 的几个核心增量第一是工作流编排能力。信贷审核不是单轮问答是“先解析材料→再验真→再查规则→再生成报告”的多级流水线。AgentArts 的可视化编排界面支持串行、并行、条件分支、循环、人工审批节点这些在代码里要写很多胶水逻辑但平台里拖拽就能完成而且每一步运行日志都有记录方便排查问题。第二是知识库和工具的一体化管理。信贷政策、合规条款、反欺诈规则这些内容需要以稳定可控的方式挂给模型而不是靠 Prompt 里塞一大堆文本。AgentArts 的知识库组件支持文档切分、向量化、检索增强模型回答时会自动引用知识库内容减少幻觉。同时平台内置了函数调用和连接器机制可以对接 OCR 服务、征信解析接口、评分卡系统Agent 能主动调用工具完成实操动作。第三是人在回路的控制能力。金融场景绝对不能接受“全自动跑飞”。AgentArts 支持在流程里插入人工审批节点智能体运行到某个步骤时暂停等人确认再继续。这个机制对合规审计特别关键——每一次人工介入都有留痕Agent 的输出和人的复核记录完整保存在流程实例里后续审计直接调日志。第四是部署和多环境管理。测试环境、预发环境、生产环境可以隔离模型版本、知识库版本、工作流版本都可以单独管理和回滚。这个对金融项目的上线流程来说基本上是刚需。1.3 AgentArts 的几个关键设计特点实际用下来AgentArts 有几个设计特别贴合智能体开发的实际需要。它的核心抽象是把“智能体”当成一个可编排的单元。一个智能体有系统提示词、绑定的模型、挂载的知识库、可调用的工具集合、输入输出参数定义。你可以针对信贷进件审核建一个“材料解析 Agent”针对风控规则建一个“规则核验 Agent”两个 Agent 的模型、知识库、工具完全隔离互不干扰。对话历史管理做得也不错。在多轮补件场景里客户可能上午传了身份证下午补充了银行流水晚上又上传了新的收入证明。Agent 需要记住之前处理到哪一步、还缺哪些材料。AgentArts 支持会话级变量和状态存储Agent 可以在多轮交互中保持上下文连贯不会每次请求都从头算。还有一点值得提平台的调试模式。你可以在测试环境里把某个节点的输入输出单独拎出来看Prompt 实际传给模型的内容、工具的返回值、知识库检索到的片段都一目了然。这个对定位问题太重要了省掉的排查时间可能在 30% 以上。2. 整体方案设计信贷审核智能体怎么拆2.1 业务侧信贷流程里哪些环节适合交给智能体动手搭智能体之前我们先把业务侧的场景做了梳理。并不是所有环节都适合立刻上智能体有些环节能力边界还撑不住硬上只会让项目烂尾。我们最终圈了四块适合先落地的一是材料接收与分类。客户提交的进件材料五花八门有 PDF 扫描件、拍照图片、Excel 流水、手写说明。智能体在这里做文件格式识别、文档类型分类、基本完备性检查确认材料清单是否齐全。这个环节规则明确、容错率高很适合自动化。二是关键信息抽取。从身份证、营业执照、银行流水、征信报告中抽取出结构化字段比如姓名、证件号、收入金额、负债率、逾期记录。传统做法是 OCR 加正则模板维护成本高用大模型做抽取可以容忍一定程度的版式变化再加上字段校验规则准确率能做到生产可用。三是反欺诈规则初筛。把命中黑名单、关联高风险实体、短期内频繁申请等规则做成可查询的工具Agent 调用工具完成初筛输出命中情况和风险等级。四是初审摘要生成。把前面几步的结果整合成一份结构化的初审报告包含客户基本信息、关键财务指标、风险点提示、建议补充材料清单。审批经理基于这份报告做判断。2.2 智能体拆解材料解析、反欺诈核验、额度试算、报告生成基于业务场景我们把系统拆成了四个核心智能体。每个智能体的职责边界非常明确避免一个 Agent 什么都干导致提示词臃肿、行为不可控。材料解析 Agent 负责接收原始文件调用 OCR 工具转文本再用抽取提示词把字段结构化。这个 Agent 挂接了银行业务领域的知识库主要用来识别不同格式的银行流水以及处理“收入证明”这类非标文档的常见表述。反欺诈核验 Agent 比较轻它的任务是把解析结果中的关键字段姓名、手机号、身份证号、单位名称逐个编码后调用反欺诈接口批量查询把所有返回结果整理成一份命中列表。这个 Agent 不需要太多推理重点是稳定地调用工具、准确地拼接参数。额度试算 Agent 负责按信贷政策计算初步可贷额度。它需要从知识库里读取最新的评级规则和额度系数表再综合客户的收入、负债、评分卡结果输出一个区间而不是固定值。为了控制风险我们在设计上强制它输出“额度区间测算依据”不允许直接给精确数字替代人工判断。报告生成 Agent 是链路的收口它把前几个 Agent 的输出、OCR 结果、规则命中、试算结论汇总起来生成最终初审报告。这个 Agent 对语言表达要求高我们给它设计了严格的输出模板防止出现遗漏。2.3 人机协同哪些点必须留人工审批即使智能体再强金融信贷里依然有几个点我们坚决保留人工审批。第一是最终授信结论。智能体可以测算额度、可以提示风险但最终批不批、批多少必须由有授权资质的审批经理确认。AgentArts 的人工审批节点在这里插入流程会暂停并通知审批人等待确认后继续或终止。第二是异常材料处理。OCR 识别率不是 100%当 Agent 检测到关键字段置信度低、证件照片模糊、材料之间逻辑矛盾时不能自行决定“按某个值继续算”。我们把这类情况设计成流转到人工核实队列由人工查看原图或联系客户确认。第三是模型分与人工复核。对于评分卡输出的高分或低分群体规则上允许自动决策但为了满足内部审计要求我们对一定比例比如 10% 到 20%的申请会抽样进入人工复核。自动化不是追求 100% 去掉人而是把人的精力集中到真正需要判断力的事务上。AgentArts 支撑这种“人机混合”流程的方式是靠节点级的状态控制而不是一个黑盒全自动跑完整个流程。3. 实操搭建从 0 到 1 落地一个信贷审核智能体3.1 环境准备与项目创建AgentArts 在华为云上的开通方式比较直接账号开通后进入控制台找到智能体开发平台的服务入口。需要先在项目空间里创建一个项目金融场景建议按环境分开建项目sit、uat、prod 每个环境一套避免测试数据污染生产数据。项目创建后平台会让你选择默认模型供应商。这里有个细节模型不一定要选最强的要选“足够好且成本可控”的。金融信贷的文档抽取任务中等参数的模型表现往往已经足够反而响应速度快、单价低。关键字段抽取用的是 7B 到 13B 级别的模型也够用但生成最终初审报告需要更强的语言组织能力我们给报告生成 Agent 单独配了更大参数的模型。然后是权限配置。信贷数据属于敏感数据我们严格按照最小权限原则分配开发人员只能访问 sit 环境测试人员可以操作 uat 但看不到生产数据生产环境的发布权掌握在运维负责人手里。AgentArts 的权限体系支持按用户、按项目、按资源粒度控制这个在金融合规审查里很加分。3.2 模型配置与提示词设计模型配置这一步最容易踩坑。很多人一上来就把所有 Agent 的模型选成同一个导致轻量任务跑得又慢又贵。我们在 AgentArts 里把每个 Agent 的模型独立配置材料解析和反欺诈核验用高吞吐模型额度试算用中等模型报告生成用高质量模型。提示词设计是另一个重点。金融场景的提示词我建议遵循“角色 任务 输入格式 输出格式 边界约束”的结构。拿材料解析 Agent 来说系统提示词我会写成类似这样的逻辑角色定义为信贷材料解析员任务是从上传的银行流水中提取收入、支出、交易对手等字段输入格式明确说明可能收到的是 OCR 后的文本或 PDF 转出的字符串输出格式严格规定为 JSON并列出每个字段的类型、取值范围、是否必填边界约束强调不确定的字段输出 null 而不是猜测遇到多币种交易记录时不要私自折算。实测下来边界约束这一条是减少幻觉的关键。你不明确告诉模型“不知道就说不知道”它一定会给你编一个值。在信贷审批里一个编出来的“月收入”可能会误导整个风险评估流程。还要注意一点提示词里不要写过于复杂的推理要求。如果任务确实需要多步骤推理应该把推理拆到工作流里的多个节点完成而不是指望模型在一步里全部想清楚。比如额度试算先让 Agent 查知识库拿到评级系数再让它调用评分卡工具拿分数最后让它在工作流里做乘法计算——计算交给代码或工具不要让模型做数学题。3.3 知识库接入信贷政策与合规条款金融信贷的信贷政策更新频率不低而且不同产品条款差异很大。我们把产品说明、准入规则、额度系数表、催收指引、合规红线条款整理成文档上传到 AgentArts 知识库做向量化处理。知识库建设有几个经验。首先是文档切分策略不要把整份 PDF 塞成一个向量块检索效果会很差。我们用“章节段落”粒度切分对于一些表格类内容单独处理转成 Markdown 表格后再入库保证检索时表格关系不丢失。其次是知识库的版本管理。信贷政策每个月都可能调整如果不做版本管理Agent 可能引用过期条款。AgentArts 知识库支持版本发布和回滚每次政策更新走“上传新文档→测试环境验证→发布生产”的流程。我们在测试环境专门做了一组“政策引用检查用例”让测试 Agent 输出引用的条款文档编号人工核对编号是否与最新政策一致。还有个细节是知识库的权限隔离。信贷政策分为公开产品和内部风控策略两类内部风控策略绝不能挂到所有 Agent 都能访问的知识库里。我们按团队建了知识库分组额度试算 Agent 和反欺诈核验 Agent 只能访问自己需要的子库。3.4 工具编排OCR、征信解析、评分卡调用Agent 要干活离不开工具调用。AgentArts 里可以用自定义函数或连接器封装外部服务。我们在项目里接了三类关键工具。第一类是 OCR 服务。客户上传的身份证、营业执照、流水往往是图片或扫描件Agent 的第一步动作通常是触发 OCR 工具把图片转成带坐标的文本再进入字段抽取环节。OCR 服务返回的置信度信息一定要保留后续字段校验规则要用。第二类是征信解析工具。这个工具封装了征信报告解析服务的 API 调用传入授权书编号和报告文件返回解析后的结构化征信数据包括信贷记录、逾期情况、查询次数等。由于征信数据极其敏感工具内部接入了脱敏逻辑Agent 只能拿到模型生成报告所需的最小字段集。第三类是评分卡调用工具。信贷机构内部通常有评分卡系统输入客户特征向量输出 PD违约概率或评分。我们把它封装成 AgentArts 的自定义工具输入输出都用 JSON Schema 定义清楚工作流里可以直接把解析 Agent 的输出字段映射到评分卡的入参。工具编排的注意点是超时和重试策略。外部接口不稳定时工作流会卡住甚至失败。我们在所有工具节点上都配置了超时时间和失败重试策略OCR 类重试 2 次征信解析类不自动重试、失败直接转人工处理——因为征信查询涉及授权书有效性问题盲目重试可能产生合规风险。3.5 工作流设计多 Agent 协作的完整链路工作流是整个系统的骨架。我们搭的信贷审核主流程大概是这样串的第一步是触发节点。客户在 APP 提交贷款申请并上传材料后系统调用 AgentArts 的工作流 API 发起一次实例运行带入客户编号和材料文件列表。第二步调用材料解析 Agent产出结构化字段 JSON同时把 OCR 置信度一并输出。第三步是分支判断。根据解析结果里的“材料是否齐全”“关键字段置信度是否达标”两个条件分流置信度高且材料齐全的进入自动化链路置信度低或材料异常的进入人工补件节点流程暂停。第四步是并行调起反欺诈核验 Agent 和额度试算 Agent。这两个环节互相独立用并行分支可以显著缩短整体耗时。反欺诈核验 Agent 调外部接口额度试算 Agent 读知识库调评分卡两边完成后汇聚结果。第五步是报告生成 Agent 汇总所有信息输出初审报告。报告里必须包含基本信息摘要、关键财务指标、风险命中列表、额度测算区间、建议补充材料清单。第六步是人工审批节点。审批经理在 AgentArts 待办中心看到初审报告做同意、拒绝、退回补件三个操作。如果同意且额度在授权范围内工作流会接着触发后续放款流程的接口如果拒绝流程终止并记录拒绝原因如果退回补件工作流回到材料补充节点通知客户补传材料。这个流程跑顺之后单笔进件的初审耗时从人工平均 25 分钟降到 3 到 5 分钟而且全程留痕、可追溯风控部门对过程的信任度远高于从前“模型直接出结论”的方案。4. 实测效果跑一个真实进件样本4.1 测试样本设计搭建完成后我们设计了一套覆盖常见场景的测试样本。不是随便拿几份材料跑一下就算完而是针对信贷审核的典型分支做覆盖正常申请、缺少材料、材料模糊、征信有逾期记录、命中反欺诈名单、提交超高清流水大文件、提交多页合并 PDF。其中“材料模糊”这种 case 特别重要很多团队测试时只测理想路径一上线遇到模糊材料Agent 乱猜字段流程直接失控。我们把低置信度分支的触发条件调成了“关键字段置信度低于 0.75 或材料缺失”一旦触发就进入人工补件而不是让 Agent 自己硬编一个值来继续。4.2 跑批过程与结果分析我们用 300 条脱敏样本做了一轮全流程跑批。结果大概是这样材料解析 Agent 的字段抽取准确率在正常样本上达到 96.5%在模糊样本上降到 82%但低置信度分支正确拦截了这些低质量输入反欺诈核验 Agent 的工具调用成功率 99.3%偶发超时都通过重试恢复了额度试算 Agent 输出的测算区间与人工审核结果的匹配度约 91%——不吻合的案例集中在收入凭证特殊、政策条款边界模糊的情况这些全部被人工审批节点接住了。最需要关注的是端到端耗时和成本。单笔进件平均耗时 3 分 42 秒比人工快了很多。但成本要按照 token 用量仔细核算材料解析是大头因为流水 PDF 动不动几十页OCR 后文本量很大报告生成虽然模型更强但输出长度可控成本占比反而小。实测下来的优化手段是控制输入侧把 OCR 文本按关键字段区域截断不要让 Agent 读完整份上千行的流水明细。4.3 性能优化与成本控制性能调优这块有几个实际有效的操作。第一个是减少不必要的二次解析。最初版本里报告生成 Agent 为了“保险”会重新读一遍原始材料文本结果重复解析导致 token 翻倍。后来我们把解析 Agent 的输出缓存成中间态 JSON报告生成 Agent 只读 JSON 不再读原文成本降了 40% 左右输出稳定性还更好了。第二个是知识库检索的阈值调优。额度试算 Agent 检索政策条款时相关度阈值设得太低会拉入大量无关段落既浪费 token 又干扰输出。我们通过试跑把阈值定在 0.4 左右检索片段数量限制在 3 到 5 段效果比较平衡。第三个是并发控制。工作流里的并行分支虽然快但外部接口的并发能力有限。我们按外部接口的 QPS 上限给工作流设置了最大实例数超出部分排队等待避免把征信解析服务打爆。这个在压测阶段必须测出来否则生产环境容易出事故。5. 常见问题与排查技巧实录5.1 智能体“答非所问”怎么办信贷场景下 Agent 偶尔会输出和任务无关的内容比如材料解析 Agent 突然解释起了银行流水是什么。排查思路很明确先看工作流日志里这个节点实际收到的 Prompt 是什么再对比输出内容。最常见的原因是解析后文本里有大段无关信息比如 PDF 里的页眉页脚、客服电话、广告文案模型被带偏了。解决办法是在提示词边界约束里明确列出“忽略页眉页脚、水印、广告文本”同时把 OCR 文本按区域裁掉无关内容后再传给模型。我们在前处理脚本里加了几个过滤规则之后答非所问的问题基本消失了。5.2 字段抽取出现幻觉这是最不能容忍的问题。抽取出的“月收入”“在职单位”与原始材料不符一旦进入额度试算会直接影响结果。我们做了三道防线第一道是置信度过滤OCR 置信度低的字段直接不让模型抽取第二道是字段校验规则比如月收入必须匹配数字模式、证件号必须通过校验位检查不合格的值置空第三道是交叉验证当收入字段与流水摘要中反映的金额差异超过阈值时自动触发人工复核。这三道防线全部配置在 AgentArts 的后处理节点里模型只负责理解语义确定性的校验交给代码错误率降到了 1% 以下。5.3 工具调用失败和参数拼错工具调用失败的问题集中在参数拼错上。比如评分卡工具要求入参是“customer_id_encrypted”Agent 传成了“customer_id”接口直接报 400。这类问题的排查技巧是看工具定义的 JSON Schema 校验报错信息。我们在工具描述里写清楚了每个字段的示例值和来源节点并且给 Agent 示范了“调用工具前先确认参数名称与来源”的用法。外部接口超时也是一个高发问题。我们统一给外部工具调用配置了 fetch 重试和超时断路器连续失败 3 次就把该笔申请标记为“技术异常待人工处理”避免流程悬挂。“技术异常待人工处理”这个状态在监控面板上要有明显告警信贷流程里静默失败是最危险的。5.4 权限与安全敏感数据的红线信贷数据天然敏感这块必须单独强调。AgentArts 项目里所有涉及敏感数据的 Agent 都配置了数据脱敏策略日志中不记录完整身份证号、手机号、银行卡号。测试环境使用脱敏数据生产环境的日志访问权限只开放给合规审计角色。还有一个容易忽略的点是模型提供商的日志和数据留存政策。金融场景要在合同层面确认数据是否会被用来做模型训练如果不能保证要关闭相关选项。AgentArts 支持配置私有化部署或专属资源池我们在生产环境直接用了专属资源池避免数据出域风险。6. 一点实操经验给后来者的建议如果现在让我重新做一遍这个项目有几件事会在第一天就确定下来一是把“边界约束”写进每一个 Agent 提示词里宁可不输出也不能乱输出二是把外部工具全部抽象成可控的 JSON Schema 接口别让 Agent 自己去猜参数三是把人工审批节点放到合规敏感的位置不要为了炫技追求全自动。另外别忽略监控面板的建设。AgentArts 的运行日志和实例状态要接到告警系统里重点监控几个指标工作流失败率、工具调用成功率、低置信度拦截率、人工复核通过率。这些指标的变化能直观反映智能体质量是否在退化效果比看几个示例输出可靠得多。这次实战下来我最大的体会是AI 智能体要落地到金融信贷真正的瓶颈不是模型智商而是工程化能力——能不能把流程拆干净、把边界管住、把人的判断留在正确的位置。AgentArts 在这套工程化体系里给了我们很顺手的支撑但最终确保业务不出问题的还是业务规则本身和人机协同的设计。希望这篇实战笔记能帮你少走几步弯路。