华为云AgentArts实战：信贷审批智能体搭建全记录

做这个项目之前我其实一直对“智能体”这个概念持观望态度总觉得有点过度包装。直到公司丢给我一个真实的信贷审批场景让我在系统里试着用华为云智果 AgentArts 把流程跑通我才发现过去想的很多“智能体怎么做”,其实已经被平台简化成了“业务怎么拆”的问题。这篇笔记记录的就是这次实战的完整过程从设计思路、平台配置、工作流编排到数据脱敏和幻觉治理这些绕不开的合规细节全部分享出来给打算在金融方向试水 AI 智能体的同学一个参照。这个项目本身不算复杂但胜在场景真实。客户提交小额消费贷申请后系统需要自动完成资料核验、征信初评、额度预审和风险提示能直接给结论的直接给拿不准的必须转人工。整条链路我用华为云智果 AgentArts 分阶段搭完前后折腾了两周这中间踩的坑、调过的参、推翻过的设计我觉得比最终跑通的结果更有价值。1. 这项目到底在做什么金融信贷场景的痛点和 AgentArts 的价值1.1 信贷审批流程的普遍痛点金融信贷审批是典型的“规则密集 非结构化输入 多系统协作”场景这正是 AI 智能体最能发力的地方也是它最容易翻车的地方。先说痛点。审批链条实在太长。客户提交申请后资料核验、征信查询、收入负债计算、额度测算、风险初评这些环节分布在不同的系统里人工处理时需要在信贷系统、征信平台、反欺诈服务之间来回切换。我们内部统计过一笔正常的消费贷申请纯人工审批平均要 30 分钟以上高峰时段积压严重客户体验自然好不了。第二规则执行太僵硬。传统审批系统把准入规则写死成代码客户情况稍微特殊一点就被“一刀切”拒绝但又不敢随便放宽因为缺少一个能把复杂规则盘活的弹性层。第三审批经验很难复制。老客户经理几秒钟就能判断一笔单子的风险但这种判断依赖个人经验说不清道不明换个人结果可能完全不一样。智能体在这些环节上的价值是它能把“核验资料、查征信、算额度、做判断”这类流程拆成明确任务逐步调用工具完成再通过规则节点兜底而不是像传统聊天机器人那样只做问答。换句话说它做的事情是把原来人工在系统间来回切换的活变成一条自动化流水线同时保留人工复核的口子。1.2 AgentArts 到底提供了什么华为云智果 AgentArts 在我理解里就是一个专门做智能体编排和运行的一站式平台。它把搭建智能体需要的几大件都做成了可视化能力对我们这种既要快速验证、又不想从零造轮子的团队来说非常关键。一是模型层可以直接接入盘古大模型也可以按需选择其他主流模型我们当时两个都试了根据场景特点和响应速度做了取舍。二是知识库把信贷产品说明书、审批规则手册、合规问答这些文档上传后平台会自动完成向量化模型在对话或分析过程中可以去检索相当于给模型配了一套随时可查的“内部资料库”。三是工作流编排通过拖拽节点的方式把“意图识别、工具调用、规则判断、结果输出”串成一个完整的处理链路这是整个智能体的骨架。四是插件与 API 接入用来对接收贷系统、征信查询接口、反欺诈服务这些外部能力。五是发布与监控构建完成后一键发布成在线服务并且记录完整的调用日志方便后续排查问题。这套能力对金融信贷场景的价值在于把过去需要自己写的 RAG 检索链路、任务规划逻辑、外部工具封装都变成了平台能力。当然不是说完全不用写代码业务系统的接口还是要自己开发复杂的规则节点我后面也用到了代码块但整体工程成本确实低了很多。1.3 平台型智能体和代码自建的差别做技术选型的时候团队内部专门讨论过直接用代码自建 agent 框架还是用平台型智能体这个问题没有标准答案但结合这次场景来看对比非常明显。从实施节奏看自建方案要自己解决向量数据库、任务编排、日志链路、部署运维一系列问题以我们团队现有的人力一到两周能出一个能演示的原型就算不错。平台方案则把这些基础设施托管了我在 AgentArts 上从零搭出第一版其实只用了不到两天。从灵活性看自建方案自由度更高可以魔改框架内部任何逻辑平台方案在节点类型、编排规则、插件扩展上受平台设计边界影响遇到平台不支持的场景就得在能力范围内换一种思路绕过去。从运维成本看自建要自己盯模型服务的稳定性、知识库增量更新、日志监控平台则统一兜底但相应地整个智能体的运行也会更加依赖云端服务。我的判断是初创项目或业务验证阶段优先考虑平台型智能体等业务逻辑复杂到平台边界明显不够用了再考虑吸收自建方案的思路。这次实战也验证了这个判断AgentArts 默认能力覆盖了这个场景大概 80% 的需求剩下 20% 通过接口调用和规则节点也能补齐。2. 实战前的设计从业务流程到智能体模块拆解2.1 先别急着配置平台先把信贷流程拆到能写进工作流打开 AgentArts 控制台之前我花了大半天的时间把业务流程画清楚这一步现在回头看是整个项目里最值得投入的时间。如果上来就直接排工作流后面大概率反复返工。我们当时把信贷审批的流程拆成了六个环节客户申请提交后触发后续动作进入反欺诈初筛对申请人身份、设备环境、行为数据做初步风控校验然后做征信资料核验读取征信报告关键字段判断资料是否齐全下一步是额度与利率测算根据规则和历史数据算出预授信区间接着做风险提示和决策结合规则与模型输出建议结论最后是人工复核出口命中不确定或高风险场景的申请转入人工队列处理。这个流程不是全部交给大模型处理的。我的设计原则是能靠规则就用规则能靠接口就用接口大模型只负责理解输入、处理非结构化信息、汇总证据并生成结论。这样一来工作流里每一个节点都有明确的归属不至于变成“大模型一锅炖”。2.2 把智能体的能力拆成五块来设计真正动手配置之前我按五个模块把智能体拆了一遍后面配置 AgentArts 时就是按这个框架落到平台能力上的。输入理解模块负责识别用户意图和关键信息抽取。信贷场景里用户会发一段口语化诉求比如“我想申请三万的消费贷还款分十二期”系统要从这句话里抽取出金额、期限、用途还得判断资料里缺了什么。任务规划模块则负责把整体任务拆成有序子任务决定要不要查征信、要不要重新核验资料。在 AgentArts 上这个模块用工作流节点天然实现了不需要让模型自己规划对金融场景来说更可控。工具调用模块连接反欺诈接口、征信接口、额度测算脚本等外部能力每个工具都有清晰的输入输出定义出了问题能快速定位到是哪个环节。知识检索模块负责从产品规则、审批手册里检索相关内容供模型生成结论时引用。输出生成模块把前几步结果汇总成结构化结论包括是否建议通过、额度区间、风险点和需人工复核的原因。这五块设计完成后我再去看 AgentArts 的能力基本是“平台有现成能力就用现成的没有现成的就用节点配置拼出来”目标非常明确。2.3 关键决策点人工介入的兜底规则怎么定信贷场景的智能体最忌讳的是全自动、黑箱、没有出口。所以设计阶段就要确定一套兜底规则我把它理解为给智能体画了一条安全边界。第一硬性拒绝由规则兜底。命中反欺诈黑名单、基本信息不完整、征信逾期次数超阈值等场景直接给拒绝结论并生成原因清单。这类操作在 AgentArts 上用规则节点实现稳定可控不依赖模型发挥。第二置信度兜底。模型给出的结论如果置信度低或者知识检索找不到有效依据宁可转人工也不要硬给一个结论。我设的转人工阈值是置信度低于 0.7 就必须走人工复核后面实际运行证明这个阈值挺合适。第三异常兜底。外部接口超时、参数校验失败、知识库检索为空这些情况都要有明确的异常出口绝不能让模型在信息不全的情况下自由发挥凑一个答案。把这三条兜底规则写清楚之后整个智能体的设计才算闭环。AI 在边界内跑得快边界外一定要有人接管这是金融智能体跟普通客服机器人最本质的区别。3. 手把手实操在 AgentArts 上搭一个信贷审批智能体3.1 创建智能体和基础配置进入华为云控制台打开 AgentArts 服务第一步是创建智能体实例要填业务名称、选择模型、设定角色描述。业务名称我当时填的是“金融信贷审批辅助”没有简单写成“信贷机器人”因为后续团队协作、日志筛选和权限管理都靠这个名字检索起得太宽泛后面会很难受。模型选择上如果场景以知识检索和结构化输出为主不一定要选最强通用推理的模型版本反而应该关注响应速度和输出稳定性。我们最后选的是响应更快的模型版本效果完全够用。关键还是在角色设定这里这部分直接影响所有后续输出质量。我给智能体的角色设定大概是这样你是信贷审批辅助分析助手基于客户申请信息和业务知识库完成资料核验、征信初评、额度测算和风险提示。你不得直接给出最终放款决定只输出建议结论和依据当信息不足或存疑时必须明确提示人工复核。这段话看着简单但它把智能体的职责边界、行为红线、输出要求全说清楚了。基础配置里还可以定义变量比如申请金额、还款期限、客户风险分把这些变量提前定义好工作流节点可以直接引用模型就不会每次都重新抽取输出更稳定。3.2 数据接入与知识库构建知识库是给大模型查资料用的构建质量直接决定模型回答质量。信贷场景要整理三类资料上传。第一类是产品规则类比如消费贷的准入年龄区间、贷款额度上限、期限与利率对应关系、收入负债比要求。这类资料最常被系统检索到必须保证准确。第二类是操作规范类比如“遇到身份证有效期过期的客户需补充材料后重新提交申请”这类流程要求。第三类是合规问答类客户常问的征信影响、提前还款费用、进度查询等标准问答对也放进去。上传之后有几个细节要注意。默认切分策略对长文档按固定长度切很容易切在关键句话的中间导致检索出来的片段语义断裂。我手工调整了分片逻辑按章节和句子边界切每段控制在三百到五百字。同时给每条知识补上业务标签比如“产品规则”“额度测算”“合规问答”检索时就能按标签过滤减少无关内容干扰。还有一个很现实的问题数据脱敏必须在入知识库之前完成。身份证号、手机号、详细地址这些敏感字段要么直接去掉要么用脱敏算法替换掉不能等上线了再补。知识库一旦变成数据泄露口后果比智能体效果差更严重。3.3 核心工作流编排与关键参数AgentArts 的工作流编排是整个实战的重头戏。我把流程设计成了一条完整链路开始节点 - 意图识别 - 资料完整性核验并行执行身份校验和反欺诈查询然后进入征信初评这里结合知识检索和规则判断接着做额度测算走规则节点再做风险等级判定最后输出结论或者转人工。这个结构里最重要的设计是把无依赖的节点拆成并行把有条件关系的节点排好前后置。比如身份校验和反欺诈查询彼此没有依赖并行执行就能省时间征信初评之后要根据结果走不同分支命中硬性拒绝的直接走拒绝通道其他情况再进入额度测算最后统一汇总到输出节点。配置节点时有几个参数我是锁死的先说温度参数也就是随机性。信贷场景里所有需要生成结论的节点我都把温度调到了 0.1 到 0.2最低设到 0.1保证模型不做无谓的自由发挥。带检索的节点还要调 topK 和相似度阈值。topK 我控制在 5 到 8太高会把不相关内容拖进来太低又会漏掉关键规则。相似度阈值设到 0.6 到 0.7 比较合适太严会检索不到内容导致转人工率变高太松又会引入噪声。还有一个容易忽略的配置就是外部接口的超时时间。征信查询接口偶尔会超过 10 秒才返回如果超时参数跟着默认值走工作流会频繁走到异常分支。我最后把查询类接口的超时单独放宽到了 15 秒并设置了 2 次重试链路稳定性立刻上来了。3.4 接入业务系统与联调部署工作流编排完成之后功能还停留在平台内部要真正被业务系统调用需要发布成在线服务。AgentArts 发布后会生成一个 API 地址业务系统按照约定格式发起请求。我当时的调用请求长这样{ input: { intent: credit_apply, amount: 30000, term: 12, customer_scores: { risk_score: 68 } } }期望的输出也必须是结构化 JSON方便业务系统直接解析取字段{ approved_flag: manual_review, suggested_limit: 20000, risk_points: [收入证明不完整, 历史逾期1次], confidence: 0.72, reason: 资料存在疑点建议人工复核 }联调阶段最大的提醒是智能体输出字段一定要固定结构不能天天变。我一开始没加严格的输出格式约束模型经常把自然语言和 JSON 混在一起解析层天天报错。后来在提示词里给了固定 JSON 输出示例又在工作流节点里做了字段映射问题才彻底解决。配置好之后建议先用模拟数据跑通全链路再拿真实脱敏数据做回归一步步来。4. 踩坑实录从数据脱敏到幻觉治理4.1 数据安全红线敏感信息不能进模型上下文这个问题必须先讲信贷场景的数据安全不是技术问题是底线问题。AgentArts 的知识库、工作流变量、对话日志每一个环节都可能包含敏感数据如果配置阶段无视脱敏真实业务上线就是事故现场。我测试时就发现直接上传原始沟通记录会导致模型在回答中引用客户的真实手机号和身份证号非常恐怖。更隐蔽的是日志里也会留存这些敏感字段等于把客户数据敞开在后台。所以我们的方案是所有进知识库和工作流的数据先经过脱敏管道处理手机号只保留后四位身份证号替换成虚拟序列号地址只保留到城市级别在 AgentArts 的接口对接层再加一层加解密转发敏感信息在进入模型上下文之前先替换成占位符业务系统需要时再做反向还原。这步是整个项目里最不能省的。宁可功能简单一点也不能让一个敏感字段因为配置失误流到大模型上下文里。上线前我们还专门做了一次脱敏专项检查逐字段过了一遍日志和知识库确保没有漏网的信息。4.2 幻觉治理让模型说话有依据大模型在信贷场景里产生幻觉后果可能是灾难性的。它凭空给你一个“存在逾期记录”或者“客户评分较高”都有可能直接改变审批方向。所以我做了三层幻觉控制。第一层是强制引用。凡是涉及规则或客户信息的结论必须在输出里带上知识库来源或接口调用的原始字段没有来源的内容不允许出现在结论区。第二层是结构化抽取。模型先把客户信息抽取成独立字段再交给规则节点去判断而不是让模型直接给“能不能审批”这种主观结论。第三层是置信度阈值。生成结论的置信度低于设定值就转入人工复核不冒任何风险。我在 AgentArts 的提示词里专门加了一段“证据约束”要求模型在输出结论时必须引用来源编号效果特别明显。加了强制引用之后测试阶段基本没有出现凭空捏造的征信结论整个系统变得可以解释、可以审计这对金融场景来说是必须达到的状态。4.3 工作流串并行结构设计不当会出大问题第一次编排工作流的时候我把所有节点按串行顺序排结果一个接口超时就把整条链路卡死客户申请的响应时间直接飙升到十几秒。后来我把无依赖的节点拆成并行比如身份校验和反欺诈查询并行跑征信初评和额度测算拆成有条件的前后置整体响应时间从 15 秒以上压到了 6 秒左右。这个调整的教训是并行是提升性能的关键但也不是越并行越好。如果两个节点同时修改同一个变量会产生写冲突如果两个并行分支各自复制一份上下文又会浪费资源。要按变量依赖关系算清楚哪些节点能并行哪些必须串行。还有一个细节异常分支尽量收敛。我给每个接口调用节点都加了异常路径但异常其实不只一种有超时、有参数错、有返回格式错。一开始每种异常都单独建分支工作流复杂到后面自己都看不懂。后来统一成一套策略重试一次仍失败就转人工复核。清晰了排查问题也容易了。4.4 高频问题速查表我把自己和团队在这个项目里遇到的高频问题整理成了表格对刚接触 AgentArts 的人应该很有参考价值。| 现象 | 排查方向 | 解决建议 | | 知识库检索结果不相关 | 切片策略和标签过滤 | 按章节和句子边界重新分片检索加标签过滤 | | 模型回答凭空捏造规则 | 提示词缺证据约束 | 强制要求输出知识库来源和接口字段 | | 接口偶尔超时导致链路中断 | 节点超时时间设置 | 查询类接口超时放宽到15秒增加重试 | | 转人工比例过高 | 知识库质量和阈值设置 | 检查知识文档覆盖度调整相似度阈值 | | 输出字段解析经常报错 | 输出格式未固定 | 强制 JSON 模板输出并做好变量映射 | | 日志中出现敏感字段 | 脱敏管道缺失 | 所有入站数据先脱敏再进入工作流 |这张表里的每一个问题都是真实项目中反复折腾出来的建议直接保存下来遇到相同现象的时候逐个对照排查比自己从头摸索快得多。5. 复盘与扩展这套方案还能用到哪5.1 上线后的关键指标复盘这个智能体在测试环境连续跑了一周用一批脱敏历史申请单做了回归。虽然没有正式生产上线但数据趋势已经有足够的参考价值。自动处理率大约 54%也就是一半以上的测试申请可以由智能体直接给出建议结论其余转入人工。单笔审批的响应耗时从人工平均 30 分钟降到了 6 分钟左右。转人工单的重命中率就是人工复核后跟智能体建议一致的占比约 76%说明大部分判断方向是对的。测试过程中我还做了一次失败样例分析发现转人工单里相当一部分是因为知识库对复杂场景覆盖不足并不完全是模型能力不够。所以后来我优先补知识库文档而不是调模型参数收益反而更大。这里想提醒一下这个结果离不开高质量规则库和接口的支持单纯靠模型能力扛不到这个水平。业务规则是下限模型是上限两者配合才是完整方案。5.2 这套方案的扩展方向金融信贷之外AgentArts 这套智能体思路同样能迁移到不少场景。贷后管理可以做催收预判智能体根据客户还款行为数据生成回款概率预测辅助催收策略制定。合规审查可以做制度问答智能体把内外部规章制度这一大堆文档变成可检索的知识库审计人员拿问题直接提问就能得到带来源的答案。客户服务可以做智能客服加业务办理入口在对话中完成资料补件提醒和进度查询。这些场景本质上都满足同一个特征存在大量规则判断、有非结构化输入、需要调用多个系统。扩展时有一句实话得说每个新场景都得重新走一遍数据脱敏、知识建设、兜底规则设计。不能直接把信贷智能体的知识库和工作流复制过去业务规则差一点结论就会差很远。5.3 再聊聊平台方案和自建方案的选择第 1 节我讲过平台方案的优势复盘之后再补一点。AgentArts 这类平台真正的甜点区是先解决“快速跑通和上线验证”的问题。信贷这类强合规场景自建方案最大的负担不是写代码而是版本治理、安全审计、知识库更新这套工程体系。平台把这些托管了你才能把精力全部放在业务逻辑上。反过来说如果业务形态高度特殊需要极其细粒度的控制权或者你们已经有一套完整自研的 agent 基础设施那平台反而会变成一种约束。选择本质上是取舍没有绝对的好坏关键是清楚自己处在什么阶段、最缺什么能力。最后分享一个我这次项目里最深的体会智能体的上限从来不是模型版本而是你对业务拆解的深度。AgentArts 把智能体的工程门槛降得很低真正难的是想清楚每个节点该做什么、什么交给规则、什么交给模型、什么坚决交给人工。把这些想明白了工作流是配出来的想不明白再强的模型也会在信贷这种强合规场景里翻车。如果你也准备做类似的场景建议先把你最头疼的一段流程跑通再从边缘场景慢慢扩稳扎稳打比一步到位靠谱得多。