1. 金融信贷场景下智能体落地的整体设计思路1.1 为什么金融信贷是智能体落地的高价值场景金融信贷业务有一个非常鲜明的特点流程长、角色多、规则密、合规要求高。从贷前获客、贷中审批到贷后管理每一个环节都涉及大量的信息采集、资料核验、风险评估和决策判断。传统做法要么依赖人工逐条审核要么用规则引擎硬编码前者效率低、成本高后者僵化、难以应对复杂多变的业务场景。我过去两年参与过几个信贷风控系统的搭建最大的感受是规则引擎能解决“确定性判断”但解决不了“理解性判断”。比如客户提交的收入证明是一张截图规则引擎只能判断“有没有上传”但判断不了“这张截图里的数字和申请表是否一致”“这个收入水平在所在城市是否合理”。这类需要阅读理解、跨信息源比对、结合常识推理的任务恰恰是AI智能体擅长的地方。华为云智果AgentArts平台提供的智能体编排能力核心价值就在于把大模型的语义理解、工具调用、多步推理能力和信贷业务已有的数据接口、规则引擎、审批系统串联起来形成一个能“看懂材料、会查数据、能给出判断建议”的智能助手。它不是要替代审批人员而是把审批人员从大量重复性、低价值的材料核验工作中解放出来让他们聚焦在真正需要经验判断的疑难案例上。1.2 智能体架构的核心分层在AgentArts上搭建金融信贷智能体我习惯把它拆成四层来看这样无论是设计阶段还是排查问题阶段思路都会清晰很多。第一层是交互层负责接收用户输入。信贷场景的输入形式很杂有文本客户填写的申请信息、有图片身份证、收入证明截图、有PDF银行流水、征信报告、还有结构化数据从核心系统拉取的客户历史数据。交互层要做的就是把这些多模态输入统一转化成智能体能处理的格式。第二层是理解与规划层这是智能体的“大脑”。它基于大模型对输入内容进行语义理解判断当前任务是什么类型比如“资料完整性检查”“收入合理性评估”“风险信号识别”然后规划出需要调用哪些工具、按什么顺序执行。这一层的核心是提示词工程和任务分解策略。第三层是工具与执行层这是智能体的“手脚”。它包含一系列可被调用的工具函数比如“查询征信接口”“调用反欺诈评分”“计算负债收入比”“比对身份证OCR结果与填写信息”等。每个工具都有明确的输入输出定义智能体根据规划层的指令依次调用。第四层是数据与知识层为整个智能体提供支撑。包括信贷政策知识库不同产品的准入规则、额度计算方式、历史审批案例库用于few-shot参考、以及业务规则库硬性红线规则。这一层决定了智能体的判断是否“懂业务”。注意很多团队一上来就急着调模型、写提示词忽略了工具层和知识层的建设。结果智能体“能说会道”但“干不了活”——问它什么都能聊但让它真正去查一条征信记录、算一个负债比就卡住了。我的经验是先把工具接口和知识库准备好再调智能体的编排逻辑效率会高很多。1.3 方案选型为什么选AgentArts而不是自己从零搭市面上搭建智能体的路径大致有三种纯提示词工程用GPTs这类产品、低代码编排平台AgentArts、Dify等、纯代码框架LangChain、AutoGen等。金融信贷场景对稳定性、可审计性、数据安全的要求极高纯提示词工程太“飘”纯代码框架开发周期又太长。AgentArts的定位刚好在中间它提供了可视化的编排界面同时支持自定义工具接入和知识库挂载底层又能对接华为云的数据安全能力。对于信贷这种“既要灵活又要可控”的场景是比较务实的选择。具体来说它解决了三个关键问题一是工具调用的标准化每个工具用JSON Schema定义好输入输出智能体调用时不会“自由发挥”二是执行过程可追溯每一步调用了什么工具、返回了什么结果、模型基于什么信息做出的判断都有日志可查三是知识库的权限隔离不同信贷产品的政策知识可以分库管理避免信息串扰。2. 核心细节解析与实操要点2.1 信贷智能体的任务边界定义在动手搭建之前有一件事比写提示词重要十倍明确智能体做什么、不做什么。信贷业务涉及资金和合规智能体一旦越界给出不该给的承诺或判断后果很严重。我的做法是画一张“任务边界表”把信贷流程拆成若干环节逐个标注智能体的参与程度。以个人消费贷为例业务环节智能体参与方式人工介入程度风险等级资料完整性检查全自动判断输出缺失清单无需介入低身份信息核验自动比对OCR结果与填写信息异常时转人工中收入合理性评估输出评估建议和依据人工复核确认中反欺诈信号识别输出风险标签和命中规则人工复核确认高最终审批决策不参与完全人工极高贷后预警监测自动生成预警提示人工跟进中这张表的核心逻辑是智能体做“信息加工和初步判断”人做“最终决策和责任承担”。凡是涉及资金发放、额度终审、拒贷结论的环节智能体只提供参考意见不直接输出结论。这样既发挥了智能体的效率优势又守住了合规底线。2.2 提示词设计的核心原则信贷场景的提示词和通用聊天场景完全不同。通用场景追求“回答得漂亮”信贷场景追求“判断得准确、依据可查、格式规范”。我总结了几个原则第一角色定义要具体到岗位。不要写“你是一个金融助手”而要写“你是一名有5年经验的消费贷初审专员负责对客户提交的申请材料进行完整性和一致性检查你的判断需要严格依据《个人消费贷准入政策V3.2》”。角色越具体模型的输出越贴近业务实际。第二输出格式要结构化。信贷审批需要的是可录入系统的结构化结果不是一段散文。提示词里要明确要求输出JSON格式并给出字段定义。比如{ check_type: 资料完整性检查, result: 不通过, missing_items: [收入证明, 居住证明], risk_level: 中, suggestion: 请客户补充近6个月银行流水或单位开具的收入证明 }第三判断依据要可追溯。要求模型在输出判断结果的同时标注依据来源。比如“收入合理性评估不通过依据——客户填写月收入20000元但银行流水显示近6个月平均入账8500元差异率135%超出合理波动范围±30%”。这样审批人员才能快速复核。第四边界情况要显式处理。提示词里要明确告诉模型当信息不足时输出“信息不足需补充XX材料”当遇到政策未覆盖的情况时输出“超出知识库范围建议转人工”而不是强行编一个答案。2.3 工具接口的设计与接入工具是智能体真正“干活”的手段。在AgentArts上接入工具核心是定义好每个工具的输入输出Schema。以“查询征信报告”这个工具为例输入是客户身份证号和授权书编号输出是结构化的征信数据。这里有几个实操要点接口幂等性。信贷场景经常需要重复查询同一客户的征信如果接口不幂等可能产生重复查询记录影响客户征信。所以工具设计时要加缓存层同一客户同一时间段内的查询结果直接返回缓存。超时与降级。征信接口、反欺诈接口这些外部依赖响应时间不稳定。工具要设置合理的超时时间我一般设3-5秒超时后返回明确的错误码智能体收到错误码后走降级逻辑比如提示“征信查询超时请稍后重试或转人工”而不是卡死。敏感信息脱敏。工具返回的数据在进入模型上下文之前要做脱敏处理。身份证号只保留前6后4手机号中间4位用星号替代银行卡号只保留后4位。这既是合规要求也能减少模型被敏感信息干扰的概率。调用频次控制。单个客户在一次审批流程中同一工具的调用次数要有上限。比如征信查询最多2次反欺诈评分最多1次。防止智能体陷入循环调用浪费资源。2.4 知识库的构建与维护信贷政策更新频繁知识库的维护成本往往被低估。我的经验是采用“三层知识库”结构第一层是硬规则库存放不可协商的红线规则比如“年龄低于22周岁或高于60周岁不予准入”“当前有逾期记录直接拒绝”。这类规则用结构化表格存储智能体通过工具查询不依赖语义检索。第二层是政策文档库存放各类产品的准入政策、额度计算规则、所需材料清单。这类文档用RAG方式挂载智能体根据用户问题检索相关段落。文档要定期更新建议每月核对一次。第三层是案例库存放历史审批中的典型case包括通过案例和拒绝案例。这类案例用于few-shot学习帮助模型理解“什么样的收入证明是可接受的”“什么样的流水模式是异常的”。案例库要脱敏后使用且定期补充新案例。实操心得知识库最怕“建了不管”。我见过一个团队政策文档更新了但知识库没同步结果智能体还在按旧政策给建议差点造成合规问题。后来我们定了个规矩任何信贷政策变更必须同步更新知识库并在智能体日志里记录知识库版本号。这样出了问题能快速定位是哪个版本的知识库导致的。3. 实操过程与核心环节实现3.1 环境准备与平台配置在AgentArts上创建智能体应用第一步是配置基础环境。登录华为云控制台进入智果AgentArts服务创建一个新的智能体应用。应用类型选择“任务型智能体”因为信贷审批是典型的目标导向任务不是开放式对话。基础配置包括几个关键参数模型选择信贷场景对准确性和稳定性要求高建议选择推理能力较强的模型版本。如果平台支持可以配置主模型备用模型的降级策略主模型超时或异常时自动切换。温度参数信贷判断需要确定性温度值建议设低0.1-0.3减少输出的随机性。最大轮次限制智能体的最大推理轮次防止无限循环。我一般设8-10轮足够完成一次完整的资料审核流程。超时时间单次任务的总超时时间设为30-60秒超时后返回“处理超时请转人工”。3.2 工具函数的注册与调试在AgentArts的工具管理页面逐个注册信贷审批所需的工具函数。每个工具需要填写工具名称、功能描述、输入参数Schema、输出参数Schema、调用地址如果是HTTP接口。以“计算负债收入比”这个工具为例输入参数是客户月收入、现有月供、本次申请月供输出是DTI比值和是否超标的判断。这个工具逻辑简单可以直接用平台的内置代码编辑器实现def calculate_dti(monthly_income, existing_payment, new_payment): if monthly_income 0: return {error: 月收入必须大于0, dti: None, exceed: None} total_payment existing_payment new_payment dti total_payment / monthly_income # 一般要求DTI不超过50%优质客户可放宽至55% exceed dti 0.55 return { dti: round(dti, 4), exceed: exceed, threshold: 0.55, detail: f月总收入{monthly_income}元月总负债{total_payment}元DTI{dti:.2%} }工具注册完成后一定要在平台的调试面板里逐个测试。测试时要覆盖正常输入、边界输入如收入为0、异常输入如负数确保工具在各种情况下都能返回预期结果。3.3 智能体编排逻辑的实现编排逻辑是智能体的核心。在AgentArts的可视化编排界面我用的是“意图识别→任务规划→工具调用→结果整合”的四段式结构。意图识别节点接收用户输入后先判断任务类型。信贷场景的意图大致分为资料完整性检查、身份信息核验、收入评估、反欺诈检查、综合审批建议。意图识别用提示词实现要求模型输出意图标签和置信度置信度低于阈值时转人工。任务规划节点根据意图标签规划需要调用的工具序列。比如“收入评估”意图对应的工具序列是查询征信→获取银行流水→计算DTI→比对收入证明。规划结果是一个有序的工具调用列表。工具调用节点按规划顺序依次调用工具每次调用后判断返回结果。如果某个工具返回错误或超时根据预设的降级策略处理重试、跳过、转人工。结果整合节点所有工具调用完成后把结果汇总结合知识库中的政策规则生成最终的结构化输出。输出内容包括检查项、结果、依据、风险等级、建议。整个编排逻辑在平台上是以流程图形式呈现的每个节点可以单独配置提示词和参数。调试时可以在每个节点查看输入输出方便定位问题。3.4 端到端测试与调优智能体搭建完成后必须经过严格的端到端测试。我的测试策略是“三组数据两类场景”三组数据第一组是历史真实审批案例脱敏后覆盖通过、拒绝、转人工三种结果验证智能体的判断与人工判断的一致性第二组是边界案例比如收入刚好卡在准入线、征信有少量查询记录但不逾期验证智能体的边界处理能力第三组是异常案例比如材料模糊不清、信息前后矛盾验证智能体的异常识别和转人工机制。两类场景单任务场景只做资料完整性检查和多任务串联场景资料检查→收入评估→反欺诈→综合建议验证智能体在多步推理中的稳定性。测试过程中要记录每个案例的智能体输出、人工判断、是否一致、不一致的原因。根据测试结果迭代优化提示词和工具逻辑。我一般会迭代3-5轮直到一致率达到可接受水平资料检查类95%评估建议类85%。4. 常见问题与排查技巧实录4.1 智能体“答非所问”的排查思路这是最常见的问题用户问的是收入评估智能体却去查了征信。排查思路是逐层检查先看意图识别节点的输出确认意图标签是否正确。如果意图识别错了检查提示词里的意图定义是否清晰是否有容易混淆的意图类别。我遇到过“收入评估”和“资料完整性检查”混淆的情况原因是两个意图的提示词描述有重叠后来把“收入评估”的描述改为“对客户提供的收入证明和银行流水进行合理性分析”区分度就上来了。如果意图识别正确但后续步骤跑偏检查任务规划节点的提示词。规划逻辑要明确告诉模型当前意图是X可用工具是A/B/C请按业务逻辑排列调用顺序。有时候模型会“自作聪明”调用不必要的工具这时要在提示词里加约束“只调用与当前意图直接相关的工具不要调用无关工具”。4.2 工具调用失败的降级处理工具调用失败的原因很多网络超时、接口返回格式变化、参数校验不通过等。我的处理原则是能重试的重试不能重试的降级降级不了的转人工。具体策略如下表失败类型处理策略用户提示网络超时自动重试1次仍失败则降级“系统繁忙正在为您转接人工”参数校验失败不重试记录日志降级“信息校验未通过请核对后重试”接口返回格式变化不重试触发告警降级“系统维护中请稍后重试”业务规则拒绝不重试直接返回拒绝原因返回具体拒绝原因注意降级逻辑一定要在编排层面实现不要依赖模型自己判断。模型有时候会“强行”继续执行导致输出不可靠的结果。我在编排里加了一个“工具调用失败计数器”同一任务中失败超过2次就直接转人工不继续尝试。4.3 输出格式不稳定的解决技巧信贷场景要求输出结构化JSON但模型有时候会输出多余的解释文字或者JSON格式不规范。解决方法有三层第一层是在提示词里强化格式要求给出完整的JSON示例并明确“只输出JSON不要输出任何其他文字”。第二层是在编排里加一个“格式校验节点”用代码校验模型输出是否为合法JSON不合法则触发重新生成。第三层是设置最大重试次数一般2次仍不合法则降级为文本输出并标记“格式异常需人工复核”。我实测下来加了格式校验节点后JSON输出合规率从85%左右提升到99%以上。这个节点的代码很简单import json def validate_json_output(model_output): try: parsed json.loads(model_output) required_fields [check_type, result, risk_level] for field in required_fields: if field not in parsed: return {valid: False, reason: f缺少字段: {field}} return {valid: True, data: parsed} except json.JSONDecodeError as e: return {valid: False, reason: fJSON解析失败: {str(e)}}4.4 知识库检索不准的优化方法RAG检索不准通常有两个原因一是文档切分粒度不合适二是检索时的query和文档表述差异大。我的优化步骤是先检查文档切分。信贷政策文档适合按“条款”切分每个条款是一个独立的检索单元不要按固定字数切。比如“收入认定标准”这个条款完整切分为一段包含所有收入类型的认定规则。再优化检索query。用户输入往往是口语化的“这个人收入够不够”而文档是正式表述“月均收入认定标准”。可以在检索前加一个“query改写”步骤用模型把口语化问题改写成正式表述再去做检索。实测改写后检索命中率能提升20-30%。最后是加“重排序”步骤。检索出Top-K文档后用一个轻量模型对文档与query的相关性重新打分取Top-3送入模型上下文。这样能过滤掉一些“关键词匹配但语义不相关”的文档。4.5 常见问题速查表问题现象可能原因排查动作解决措施智能体不调用工具工具描述不清/提示词未要求检查工具描述和规划提示词补充工具使用场景说明调用工具但参数错误Schema定义与实际不符查看工具调用日志修正Schema定义输出JSON格式错误提示词格式约束不够检查格式校验节点日志强化格式要求加重试知识库检索不到文档切分/query表述问题查看检索日志的Top-K结果优化切分query改写多轮对话后“失忆”上下文超长被截断检查上下文长度精简历史关键信息摘要判断结果与人工差异大提示词业务逻辑不完整对比分析差异案例补充业务规则到提示词5. 智能体在信贷场景的扩展方向5.1 从单点辅助到流程嵌入目前多数团队的智能体还是“单点辅助”模式——审批人员遇到问题主动去问智能体。下一步的扩展方向是“流程嵌入”把智能体直接嵌入信贷审批系统的工作流中在特定节点自动触发。比如客户提交申请后系统自动调用智能体做资料完整性检查检查结果直接回写到审批工单里审批人员打开工单就能看到智能体的检查报告。这种模式的关键是系统间的接口对接。智能体需要提供标准的API接口审批系统通过接口调用智能体并接收结构化结果。AgentArts支持将编排好的智能体发布为API对接成本不高。5.2 多智能体协作的探索信贷审批涉及多个专业领域身份核验、收入评估、反欺诈、合规审查单个智能体承担所有任务会导致提示词过于臃肿、判断准确率下降。更合理的架构是“多智能体协作”每个专业领域一个智能体由一个“调度智能体”负责协调。调度智能体接收审批任务后根据任务类型分发给对应的专业智能体收集各专业智能体的输出后汇总成综合报告。这种架构的好处是每个专业智能体的提示词可以更聚焦、更深入维护起来也更方便。AgentArts目前支持多智能体的编排可以通过“子智能体”节点实现。5.3 持续学习与反馈闭环智能体上线后不是终点而是起点。要建立反馈闭环审批人员对智能体输出的每条建议进行“采纳/不采纳”标记这些标记数据定期回流用于优化提示词和知识库。我一般建议每周做一次反馈分析统计采纳率、分析不采纳的原因、找出高频错误模式。如果某个类型的判断错误率持续偏高就要针对性优化。这个闭环跑起来后智能体的准确率会随着使用时间的增长而逐步提升。最后分享一个小技巧在智能体的输出里加一个“置信度”字段让模型对自己的判断给出置信度评分高/中/低。审批人员可以优先处理低置信度的案例高置信度的快速通过。这样既保证了安全性又提升了整体效率。实测下来置信度高的案例中智能体判断与人工判断的一致率超过95%审批人员基本可以快速确认。