最近一段时间我把华为云智果AgentArts在金融信贷方向上的实战案例完整啃了一遍又专门用测试数据从零搭了一个信贷资料审核智能体。这篇笔记就是这次实战的记录为什么选它、架构怎么设计、每一个节点怎么配、踩了哪些坑都会说到。AgentArts是华为云上的一套AI智能体开发与编排平台核心价值在于把大模型的语义理解能力和传统的规则、流程、工具调用组合成一个能稳定跑业务的闭环。金融信贷是一个特别典型的“规则优先”的行业——额度怎么算、逾期怎么定义、黑名单怎么命中都是确定性逻辑但同时又有大量非确定性判断比如资料里有没有异常表述、客户更适合哪种还款方案。如果你正准备把AI智能体引入信贷流程或者刚开通AgentArts不知道从哪里下手这份笔记应该能帮你省掉不少摸索成本。1. 想清楚再动手AgentArts在金融信贷里到底解决什么问题1.1 信贷流程里的智能体缺口在哪里做过信贷业务系统的人都知道最耗人的环节往往不是最终的审批决定而是审批前那些重复劳动。以贷前资料审核为例初审专员一天要打开几十份申请资料核对身份证、银行卡、银行流水、收入证明把关键字段登记进系统再做一轮基础校验。这个岗位不是不需要经验恰恰是经验全部消耗在高重复操作上。早期大家想用技术解决第一代方案是“OCR加规则引擎”。身份证识别、银行卡识别确实能跑但识别出来的东西只是结构化字段没法理解业务含义。比如流水里出现了多笔固定金额转入规则引擎判断不了这到底是工资代发还是可疑的刷流水行为客户工作单位是“某某科技有限公司”规则引擎也说不清这个行业在当前业务策略下属于什么风险倾向。后来有人开始直接调大模型API让模型看资料、写摘要。模型在理解能力上确实强很多但新的问题来了模型输出不稳定今天给A结论明天同样输入给了B结论它不会主动去调业务系统接口审批流程中必须保留的记录、复核、留痕它天然做不到。这个时候就很需要一个能把模型、规则、工具、流程和人工串起来的底座。1.2 AgentArts的解题思路工作流编排AgentArts解决的不是“模型跑得好不好”的问题而是“怎么让模型在一套业务流程里稳定产出价值”的问题。它提供的是智能体编排能力把一次完整的业务处理拆成若干节点每个节点可以是模型调用的LLM节点可以是执行固定逻辑的规则节点可以是调用外部系统的插件节点也可以是在异常情况下需要人工介入的审查节点。这些节点通过工作流串联起来。支持串行、并行、条件分支、循环、人工确认等多种编排方式。实际效果相当于把“审核员的一天”变成了“一张可配置的流程图”先做资料识别再做规则校验再查询反欺诈系统模型生成风险摘要最后根据风险等级决定自动通过、转人工复核还是直接拒绝。这种设计对信贷业务特别友好因为信贷审批的核心诉求不是“让AI替人做决定”而是“让AI替人把确定性的活做了把需要判断的活整理好交给人来拍板”。AgentArts把这条边界画得很清楚。1.3 和直接调大模型API相比为什么选平台我见过不少团队的第一反应是我们不缺开发能力直接用大模型API写个服务把流程串起来不就行了能但代价不低。这里列一个我自己的对比经验对比项直接调大模型API自研用AgentArts编排流程可维护性逻辑散落在代码里改一个规则要发版控制台上直接改节点和连线秒级生效人工复核需要自己开发工单系统有现成的人工节点支持任务派发与超时处理插件工具接入每个外部系统都要单独写集成代码平台统一管理插件OCR、消息通知等开箱即用决策留痕需要额外设计日志表执行过程自动记录节点输入输出便于审计模型切换代码里改接口还要考虑兼容性配置层面切换模型版本工作流不用重搭不是说自研不行而是对大多数信贷团队来说业务侧的精力应该放在规则、阈值、话术和客群理解上而不是放在“怎么把两个系统连通”这种基础设施问题上。AgentArts的价值是把基础设施问题前置解决让我们能直接专注在业务本身。2. 准备工作与核心概念2.1 开通AgentArts之前需要准备什么我的建议是不要一上来就进控制台点开通先花十分钟梳理一下自己的使用条件。基本上需要三样东西华为云账号、已经实名认证的主体、以及一个用于测试的资源空间比如华为云账号下的某个企业项目或者独立项目空间。如果你所在团队有统一的IT管理建议先向管理员申请开通AgentArts服务并且给实际操作的子账号配置好相应权限。权限控制在信贷场景里很重要因为后面要接入的插件和知识库可能涉及客户数据IAM账号的权限边界最好遵循最小授权原则——谁用、能看哪些数据、能不能发布工作流分开管理。开通后在控制台搜索“AgentArts”进入服务页面。不同账号的控制台入口名称可能略有差异以你开通后看到的实际界面为准。首次进入会有一些引导任务跟着创建一个测试智能体把界面上的工作流画布、插件列表、知识库菜单都点一遍建立体感再说。2.2 五个核心概念智能体、工作流、插件、知识库、人工节点第一次打开AgentArts的人普遍会被一堆术语弄晕。我梳理下来真正干活前只需要抓住五个词。智能体Agent不是指一个模型而是一个业务能力的封装体。你可以把它理解成一个“数字员工”有名字、有职责描述、有一整套处理问题的工作流。一个信贷业务系统里可以有多个智能体比如“资料初审助手”“贷后提醒助手”“反欺诈排查助手”。工作流Workflow是智能体的执行蓝图。所有节点按顺序或并行连接起来每个节点处理完数据后把结果传给下一个节点。画布上的连线就是数据流动的方向。插件Tool解决“模型做不到的事”。模型不会真的打开身份证照片去识别也不能自动发送短信。OCR识别、银行卡四要素验证、企业信息查询、消息通知这些都属于插件能力在工作流里作为节点被调用。知识库Knowledge Base是做检索增强的知识容器。信贷制度、产品说明、常见问题答案、催收话术模板都可以放进去。智能体在处理请求时先检索相关知识再结合上下文生成回答这能大幅减少模型“凭空发挥”的问题。人工节点Human Review是最容易被忽略但最关键的概念。它代表流程中的“人机交接点”当模型输出不确定或者规则命中了需要人工判断的条件时工作流会暂停并创建一个人工任务。信贷场景永远需要这类节点兜底。2.3 先理解这个设计直觉规则管确定模型管开放我在动手搭流程之前想明白的一件事就是不要把什么事都丢给大模型。信贷场景里有一类判断是确定性的比如“身份证号码校验位对不对”“近三个月逾期次数是不是超过2次”“客户年龄是否落在产品准入区间”。这类逻辑应该写进规则节点执行结果100%可复现。另一类判断是开放性的比如“从银行流水中总结客户的资金往来特征”“根据客户情况生成一份委婉的还款提醒文案”。这类任务没有唯一正确答案适合交给模型。AgentArts的最佳实践是让规则和模型各管一段规则负责把能算清楚的指标算清楚模型负责把算不清楚的情况用自然语言表达出来。我在后面实操部分给出的工作流就是按这个逻辑设计的。如果你一开始就能建立这个“双引擎”的直觉后面调整节点会顺利很多。3. 金融信贷智能体的架构拆解3.1 从贷前、贷中到贷后三个场景一张图信贷业务的常规流程是贷前、贷中、贷后三段式智能体在每一段都能找到切入位置。贷前环节主要处理的是“这个客户能不能放款、放多少”。典型任务包括资料完整性和真伪校验、反欺诈规则检查、额度试算、风险等级初判。贷中环节主要处理的是“放了款之后风险变没变”。典型任务包括资金流向监控、客户负债变化提醒、额度动态调整。贷后环节主要处理的是“怎么还款、还不上怎么办”。典型任务包括还款日程提醒、逾期客户分层、催收话术生成。三个场景可以在AgentArts里做成一个大的智能体也可以用两到三个独立的智能体分开管理。我更偏向用独立智能体因为贷前、贷中、贷后处理的数据源不同、使用人员不同、风险控制策略也不同放成一个智能体反而会让工作流变得臃肿。这里给出我常用的分工方式业务阶段智能体名称主要输入主要输出贷前信贷资料初审助手申请资料、OCR结果、征信报告摘要初审结论、风险提示、建议动作贷中贷中监控助手放款后交易流水、外部风险信号风险预警、额度调整建议贷后贷后服务助手还款状态、客户画像、历史沟通记录提醒话术、客户分层、跟进优先级3.2 贷前审核智能体有哪些核心节点以“信贷资料初审助手”为例我会把工作流拆成下面这些节点。第一个节点是资料接收与OCR识别。客户上传身份证、银行卡、银行流水等影像件之后调用OCR插件提取关键字段。第二个节点是字段结构化与规则校验。把OCR结果转成统一结构的业务字段然后执行固定校验规则比如手机号位数、身份证校验位、年龄区间、申请金额上下限等。第三个节点是反欺诈查询插件。把姓名、证件号、手机号等发给反欺诈系统返回黑名单命中情况、历史申请频率、异常行为标签。第四个节点是风险评分计算。这里通常是一个规则节点或代码节点基于前面输出的负债率、逾期次数、申请频率等指标计算风险分。第五个节点是模型生成审核意见。把结构化字段、规则校验结果、风险评分统一拼进提示词让模型生成风险摘要、主要疑点和建议动作。最后接一个条件分支风险分在自动通过区间的直接输出“通过”在建议复核区间的创建人工任务在拒绝区间的输出“拒绝并附原因”。整个流程走完一个申请人的初审就完成了。这个架构的好处是每个环节都有明确输入和输出出了问题能很快定位到具体节点。3.3 贷中监控与贷后提醒的延伸设计贷中监控智能体和贷前不太一样它更多是事件驱动型。新的银行流水进来、外部征信数据更新、客户在其他机构新增了贷款这些都可以成为触发条件。触发之后工作流先做规则判断比如“月负债收入比是不是有明显抬升”“是否出现与申报用途不符的转账记录”再看是否存在风险信号。如果风险信号较多就让模型生成一份风险说明最后推送提醒给客户经理。贷后服务智能体则可以调知识库匹配话术模板。注意催收性质的话术必须谨慎我的建议是先从“还款提醒”开始不要把智能体设计成直接进行施压型沟通。在AgentArts里可以用客户分层节点把客户分成正常、关注、重点三类每类对应不同的话术模板再由模型结合客户历史还款记录做个性化改写。这样既保留标准化又避免每条短信都写得一模一样。4. 实操记录从零搭一个信贷资料审核智能体4.1 第一步创建智能体并配置模型提示词进入AgentArts控制台后找到“智能体”管理页点击创建。名称我建议直接叫“信贷资料初审助手_测试版”这样在日志和告警里一眼能认出来。创建后第一步是配置模型。模型选择上AgentArts默认会对接华为云盘古系列模型同时也支持接入其他主流商用或开源模型。我用的是平台默认模型来处理测试数据。信贷场景说明文字多客户资料里的表述往往不规整选模型时我优先关注长文本理解能力和指令遵循能力不一定追求最大的参数量。配置系统提示词是关键。我第一版提示词里只写了“你是信贷审核助理”效果不稳定后来改成明确的输出格式约束稳定很多。可以参考下面的版本你是一位信贷审核助理。输入内容是一组已经结构化的客户信息和规则校验结果。 请严格按以下三部分输出 1. 风险摘要用不超过80字概括客户基本情况与主要风险点。 2. 主要疑点列出最多三项需要人工关注的异常项没有则写“无明显疑点”。 3. 建议动作只能从“通过”、“转人工复核”、“拒绝”中选择一个并写一句支撑理由。 注意只描述业务事实使用中性、客观的语言不要出现任何主观评价或与信贷无关的信息。实际测试下来把输出格式写死后续接人工节点时解析结果就容易多了。如果你在后面接了自动化系统这个提示词里的输出格式可以直接被下游解析。4.2 第二步搭工作流五个节点跑通主流程创建好智能体后进入工作流编辑器。我搭的主流程是五个节点加一个条件分支。第一个节点是输入节点定义该智能体的触发参数。我的参数包括客户编号、申请金额、身份证号、手机号、OCR识别后的原始文本。这里建议所有参数都用字符串类型后面需要计算的地方再转换。第二个节点是规则校验节点。用条件表达式完成硬性校验。我会把身份证号校验位、手机号位数、年龄区间、申请金额上下限都放在这里。校验失败的样例直接走“终止”分支返回明确的拒绝原因不再进入后续流程。第三个节点是反欺诈查询插件节点。选择平台集成的反欺诈查询插件或者在插件仓库里找到相应的HTTP调用插件。配置好请求地址和参数映射把客户编号、证件号传出去返回的结果里有黑名单状态、近30天申请次数等字段。第四个节点是风险评分计算节点。这里我用的还是规则节点加代码块得先把评分逻辑定清楚。我测试时用的简单评分公式如下基础分100分负债率月还款总额/月收入。负债率小于等于30%不扣分30%到50%之间扣15分超过50%扣35分近12个月逾期记录M1逾期一次扣5分M2逾期一次扣15分M3及以上直接拒绝近30天申请查询次数超过6次扣10分反欺诈黑名单命中直接拒绝。根据上面规则默认通过阈值是75分人工复核区间是55到74分55分以下拒绝。这些阈值不是凭空拍出来的最好拿历史已审批样本跑一遍看这个切分点能不能把过去拒绝的样例尽量拦在低分区把过去通过的样例尽量放进高分区。第五个节点是LLM节点。把第二个节点的校验结果、第四个节点的评分结果、反欺诈结果拼接成一段输入文本传给模型。模型按照提示词要求输出风险摘要、主要疑点、建议动作。第五个节点之后加一个条件分支。如果建议动作是“通过”且风险分大于等于75直接进入输出节点如果是“转人工复核”或风险分落在55到74之间进入人工节点如果是“拒绝”或风险分低于55进入拒绝输出节点。这里要注意一个细节规则判断和模型建议冲突时我倾向于以规则为准模型结果只作为参考和说明文本。4.3 第三步接入OCR、知识库和消息通知插件工作流跑通之后再接入OCR插件。实际项目中OCR识别不是一次性调用而是先对图片做质量检测再识别、再纠错。我会在OCR节点后加一个“字段校验”步骤银行卡号识别结果里如果出现字母“O”或“I”基本可以断定是误识别需要修正为数字0或1。知识库方面我把产品准入规则、常用术语解释、还款计划模板整理成十几个文档上传到知识库每个文档控制在几百字以内。这样检索的命中率更高。在实际配置LLM节点时可以勾选“引用知识库”让模型在生成审核说明时参考相关制度。我特别提醒一点知识库内容要脱敏不能把真实客户样例原封不动传进去否则模型在生成内容时可能把别人家的信息串进来。消息通知插件在人工节点后面接一个就行。当人工任务完成或者自动拒绝产生时调用消息通知插件把结果发送到值班群或工单系统。这里记得配上通知模板把关键信息压缩到一两句话比如“客户编号、申请金额、初审结论、需要处理人”。4.4 第四步测试、调优与灰度上线测试不是随便喂几条数据看输出顺不顺眼。我的做法是准备三组测试数据一组是明确通过的历史样例一组是明确拒绝的历史样例一组是边界案例比如负债率在50%边缘、黑名单疑似命中但信息不完整。每一条都要记录通过、转人工、拒绝的结果并和人工历史结论对比。第一轮跑下来最容易出现的问题是“模型太宽松”。模型生成的建议动作经常是“转人工复核”因为它不敢拒绝客户。解决办法有两个一是调整提示词明确“如果评分低于55且规则校验失败请不要犹豫直接选择拒绝”二是把风险分阈值作为主导判断模型建议动作即使写“转人工复核”只要规则评分低于55最终出口仍然走拒绝分支。测试通过后在灰度环境跑旁路验证也就是智能体照常运算但结果不直接作用于业务只做记录。运行一周左右人工比对该智能体结论与原审核员结论重点看“智能体判通过但人工拒绝”和“智能体判拒绝但人工通过”这两类不一致样本的数量。不一致比例收敛后再逐步切真实流量。整个过程中每次修改工作流我都要重新跑一遍三组测试数据防止改了A环节导致B环节的结果变化。5. 常见问题、排查技巧与三点经验5.1 高频问题速查表实操中遇到的大部分问题都有明确规律。我把常见情况整理成一个速查表排查时按表格走会快很多。问题现象可能原因排查建议OCR识别结果里数字被识别成字母图片质量差或OCR模型误判加字段校验步骤对银行卡号、身份证号做规则纠错模型输出和结构化字段不一致提示词对输出格式约束不够把输出格式在提示词里写死必要时加上“只输出JSON”知识库召回内容不相关文档分块过大或检索阈值太低每个知识文档控制在500字以内调整检索Top K参数并行节点返回结果互相覆盖变量命名冲突或节点顺序错误检查每个节点的输出变量名不要复用同一个key人工节点一直挂起没有配置超时和备用人设置人工任务超时时间超时后自动转给备选处理人模型回答带有主观贬低表述提示词缺少中性化约束在系统提示词中增加“只描述事实不做主观评价”调用插件偶尔超时外部接口响应不稳定在插件节点后增加重试逻辑或降级策略超时走人工成本增长明显输入文本太长或重复调用模型精简输入上下文对静态内容做缓存减少无效调用我排查这类问题时有个习惯先看单个节点的输入输出再回看整体工作流日志。AgentArts每个节点都有日志记录能很快锁死是哪个环节出了偏差不用盲猜。5.2 我被问得最多的三个设计原则很多人在培训时会问我同一个问题智能体会不会失控我的回答是如果设计得当它的行为边界比人更清晰。前提是遵守三个原则。第一先规则后模型。一切能明确计算的风险指标都不要交给模型判断。模型只负责规则的补充说明。这样即使模型“说错话”最终结果也被规则兜住。第二决策链路留痕。每个节点输入输出要进日志尤其是模型节点和人工节点。信贷业务里“为什么得到这个结论”和“谁最终确认了这个结论”同样重要。如果未来出现争议一条完整的链路能省去大量扯皮成本。第三人工兜底不能省。人工节点不是摆设是智能体的“刹车”。我的建议是宁可让智能体多转几单给人工也不要追求一个过高的自动通过率。先跑稳定再逐步扩大自动化范围。5.3 别忘了数据安全这个底座最后说数据安全。信贷场景里的客户身份证号、手机号、收入流水都是高度敏感信息在AgentArts这类平台上处理时要注意三点一是对输入日志做脱敏例如手机号中间四位打码、身份证号只保留前后几位二是知识库和插件权限要严格隔离谁有权限看哪些知识库要提前设计好三是接入外部插件时确认数据不出业务合规边界。我自己的习惯是在配置好工作流之后再单独检查一遍每个节点的输出日志字段凡是不需要在下游使用的敏感字段一律在节点输出映射里去掉。这一步虽然不起眼但能避免很多因为“多存了一个字段”而产生的麻烦。顺着这个方向如果你所在的团队正在备赛华为ICT大赛云赛道或者在公司内部做AI智能体课题验证我觉得拿信贷资料初审这类场景当作“样板间”特别合适规则清晰、数据可得、效果能量化做完之后无论汇报还是比赛都能拿出完整链路。我个人在这次实操里最大的体会是AgentArts解决的不只是“AI能不能用”的问题而是“AI怎么在一个有规则、有责任、有流程的行业里被用好”的问题。金融信贷不缺数据和规则缺的是把规则、模型、插件、人工协作封装成一个可复用产品的工程能力。我试下来最顺手的一点是改一个节点的阈值或者换一个模型版本整个工作流都会跟着调整这在传统手写服务代码的流程里要动好几个地方。建议你也挑一个非核心场景先从旁路跑起来跑顺了再往核心流程里走。