做金融信贷类的AI智能体最怕的就是只会在演示环境里能说会道一到真实业务场景就露馅。这篇笔记记录的是我在华为云 AgentArts 平台上把金融信贷审批流程往智能体方向落地的完整过程——从场景拆解、工作流编排到参数调优和问题排查。AgentArts 是华为云面向智能体编排与运行的可视化平台正好覆盖了我需要的那套能力插件工具封装、知识库挂载、多模型调度以及最关键的流程编排与人工审批兜底。如果你也在搞金融信贷相关的AI应用或者准备在云上搭建一个能真正跑业务逻辑的智能体这篇笔记值得从头看一遍。1. 选型逻辑金融信贷场景为什么需要AgentArts1.1 信贷业务不是问答而是流程金融信贷和聊天机器人有本质区别。一个真实的信贷审批任务要经历客户信息采集、数据校验、征信与银行流水分析、风险规则匹配、额度建议、人工复核等多个环节每个环节的数据源和计算逻辑都不一样。普通的大模型对话应用根本接不住这种复杂度因为大模型本身没有事务意识不会因为一次查询失败就自动重试也不会主动把数据库里的结构化数据跟政策文档里的非结构化知识融合起来判断。很多团队一开始直接调大模型API做信贷问答结果发现问一句答一句可以但要让它查一下客户近三个月的流水结合风控规则给出审批建议它就彻底乱了。我选择智能体平台的核心理由就在这里要把大模型嵌进业务流程里得有编排、有状态、有兜底。AgentArts 这类平台提供的不是一个大模型聊天窗口而是一整套智能体生命周期管理能力。你可以把多个模型、插件、知识库、人工节点串成一条清晰的业务链路让大模型在链路中扮演调度大脑的角色而不是从头到尾自己硬扛。这一点对信贷场景尤其重要因为信贷链路天然是分段的信息收集段、分析段、决策段、复核段每段的容错要求完全不同。1.2 AgentArts的能力底座与我选它的三个理由先说清楚AgentArts 不是一个只能拖拖拽拽的玩具级编排工具。它底层把插件系统、知识库检索RAG、大模型调度、流程编排、日志监控这些能力整合在了同一个平台上。我实际用下来的体感是它解决了金融信贷类智能体落地时的三个扎心问题。第一个是插件接入成本。信贷场景要查数据库、调征信接口、跑评分卡AgentArts 支持把 API 和函数封装成标准插件你说清楚输入输出参数它就能在对话流里被大模型按需调用。省掉了自己写 Agent 框架和 Tool Calling 协议的一大堆底层代码。第二个是流程与模型的解耦。同一个智能体里信息抽取节点用一个轻量模型就够风险评估节点换更严谨的大模型AgentArts 支持按节点配置模型而不是整个智能体绑死一个模型。这点在控制成本和提升效果上非常关键后面我会专门展开说。第三个是可观察性。平台自动记录每一轮调用的输入、中间工具返回、模型输出和 Token 消耗所有日志可以导出。金融场景上线前要过内部审计这种完整的调用轨迹几乎是刚需——出了问题能回溯哪个环节错了一眼就能定位。1.3 常见技术路线对比别急着动手在决定用 AgentArts 之前我把市面上几种主流做法都梳理了一遍结论是不同路线适合不同团队没有绝对的好坏但选型之前一定要想清楚自己的约束条件。技术路线优点缺点适合场景直接调用大模型 API上手快、最灵活无流程控制、无工具管理、输出不稳定概念验证、纯文本问答自研 Agent 框架如 LangChain、自写工具调用高度可控、可深度定制开发量大、维护成本高、调试困难有专职 AI 工程团队的机构开源工作流引擎 模型网关可控性较好需要自己解决部署、监控、高可用对数据主权有严格要求的内部平台AgentArts 托管智能体平台编排可视化、插件/模型统一管理、开箱即用的监控平台能力受限于云厂商业务想快速上线的市场化团队信贷业务对稳定性和审计要求高但又不至于高到必须全自研。AgentArts 这类托管平台相当于把AI 基础设施外包出去让我集中精力做业务逻辑本身。这个取舍对我来说是划算的毕竟信贷场景里真正的壁垒在风控规则和业务理解不在模型部署。2. 场景拆解信贷审批智能体到底解决什么问题2.1 贷前审批辅助最核心的场景在跟业务同事聊需求的时候我发现贷前审批辅助是痛点最集中、价值最直接的场景。客户经理提交一笔贷款申请后审批专员要翻材料、查系统、对规则单笔业务光信息核对就要花二十到三十分钟碰上材料不全的还要来回沟通。智能体介入后可以把这些重复劳动压缩到几分钟。我设计的贷前审批辅助智能体核心职责是四段式作业意图识别、信息抽取、数据核验、建议生成。客户经理把客户资料身份证号、收入证明、流水截图等丢给智能体它先判断这是新申请还是补充材料然后抽取关键字段自动去数据库核对客户基本信息、去征信接口获取报告最后结合风控规则库生成审批建议。注意这里我做了一个明确的设计约束智能体永远不直接下审批结论它只输出建议通过建议拒绝需人工复核三档之一并给出完整的依据链。这不是技术做不到而是业务规则要求。信贷审批是强监管场景最终决策权必须在持证审批人手里AI 只能做辅助。这个边界在场景设计阶段就要划清楚别等到上线了才被合规部门打回。2.2 贷后风险预警与合规审查贷后管理是另一个非常适合智能体的场景但它的工作方式跟贷前完全不同。贷前是一次性的流程处理贷后是持续性的监控上报。AgentArts 在工作流里支持定时触发和事件触发我可以用它做一个贷后预警智能体每天定时跑一遍客户名单检查还款行为异常、多头借贷新增、抵押物状态变更等信号一旦命中预警规则就自动生成风险报告并推送给对应客户经理。合规审查场景则更依赖知识库的能力。信贷政策更新频繁每家机构还有自己的内部制度一线业务人员根本记不住所有条款。我挂载了一个包含最新信贷政策、内部操作手册、历史处罚案例的知识库智能体收到这笔客户是否符合某个特定政策这类问题时先检索相关政策文档再结合上下文给出带引用来源的结论。这个场景的价值在于它把查制度这个高频动作从人工翻文档变成了对话式检索准确率还比人高——毕竟人翻文档会看漏检索不会。2.3 客户咨询应答降本最直观的场景很多团队做金融AI第一个想到的就是客服确实该做但我把它放在最后说是想强调一个排序问题先做审批辅助和风控再上客户咨询因为前两个场景直接关联核心业务ROI 更高。客户咨询应答智能体做起来反而最简单。贷款产品介绍、利率查询、申请进度查询、材料清单问答这些都是高频且答案相对标准的需求。我给它接了一个查询插件客户问我的贷款申请到哪一步了智能体查完数据库直接回复状态不用人工翻系统。这里有一个细节咨询场景的用户情绪波动比较大智能体提示词里我会强调语气温和、不主动引导投诉、遇到敏感问题转人工这算是金融客服智能体的底线配置能省掉很多舆情风险。3. 从零搭建贷前审批辅助智能体实操全记录3.1 创建智能体角色设定与提示词打磨打开 AgentArts 控制台创建智能体的第一步是设定角色和指令。这一步很多新手不重视随便写一两句话就开始下一步后面全部返工。我的建议是把系统提示词当成一份岗位说明书来写越具体越好。以下是我在贷前审批辅助场景里使用的提示词核心结构你可以直接参考你是一位从事信贷审批工作超过十年的资深风控助理服务对象是银行信贷审批专员。 你的任务是针对给定的客户资料完成信息汇总、风险评估并输出结构化的审批建议。 规则 1. 只提供建议不做最终审批决定最终决定权在人工审批专员 2. 若客户命中黑名单关键词直接标记 REJECT 3. 若检测到多头借贷或征信查询次数异常建议降额或补充材料 4. 所有金额必须带单位时间必须标明年份 5. 输出必须使用 JSON 格式字段见 schema。写提示词有三个容易踩的坑。第一不要只写你是信贷审批助手这种万能开场大模型做不到在你没给规则的情况下自动理解业务边界第二每条规则必须是可执行的指令而不是模糊的目标比如注意风险这种话没用要写成若命中黑名单则REJECT才有约束力第三一定要声明输出格式约束否则后续解析工具拿到的文本就是一团乱麻。3.2 知识库挂载把信贷政策文档装进去信贷审批辅助智能体要能回答政策类问题就必须挂知识库。我把机构最新的《信贷业务管理办法》、产品细则、常见问题解答整理成 PDF 和 Word 文档上传到 AgentArts 的知识库平台会自动做文档解析和向量化。这里要说一下切片参数。文档不是整本丢进去就能用的平台会把文档切成片段并向量化切片大小直接影响检索效果。我实测的经验是切片大小设置在 500 到 700 个 token 之间比较合适太小了语义不完整太大了检索噪音高。切片重叠一般控制在 60 到 80 个 token保证相邻切片间的语义衔接。检索参数上topK 我设置的是 6 到 8相似度阈值 0.6 到 0.7。阈值设太低会召回一堆无关内容设太高又什么都查不到这个值最好用一批真实问题做测试后确定别拍脑袋。挂载完知识库一定要做一件事用业务同事真实会问的问题去测试检索质量。我当时的测试问题是个体工商户申请经营性贷款需要提供哪些材料系统能检索到对应政策并给出准确回答。如果你发现答非所问十有八九是切片或者阈值的问题先看检索返回的前几篇文档是不是相关的再倒推调整。3.3 插件配置数据查询与现实世界的连接信贷智能体不能只会说它得能动手查数据。我在 AgentArts 里配置了三个插件这是整个智能体真正体现业务价值的地方。第一个是客户信息查询插件封装了对内部客户主数据表的查询逻辑。我给它定义了清晰的输入参数customer_id客户号输出参数姓名、年龄、职业、所在地区、开户时间。插件内部实现的是自然语言到 SQL 的转换大模型负责把用户的问题翻译成 SQL插件负责执行。举个例子用户问客户 A0001 的月均收入是多少系统解析出的 SQL 大致是SELECT AVG(monthly_income) FROM customer_income WHERE customer_id A0001 AND stat_month DATE_SUB(CURDATE(), INTERVAL 6 MONTH);第二个是征信报告解析插件对接外部征信数据接口。这个插件比较特殊它不直接返回原始征信文本而是由大模型从征信报告中抽取关键特征字段比如逾期次数、当前负债总额、查询次数再以结构化 JSON 输出。抽取任务用大模型来做比传统规则靠谱得多因为征信报告的表达方式太灵活了。第三个是额度测算插件内部实现了一套简化的规则引擎输入客户的收入、负债、征信情况输出建议额度区间。这其实就是把审批专家的经验转化成可执行的代码逻辑智能体负责收集输入插件负责按公式计算各司其职。3.4 工作流编排把智能体变成业务流程插件配置好之后重头戏是工作流编排。AgentArts 提供了可视化编排画布我把贷前审批辅助智能体设计成了五个串行节点的流程意图识别 → 信息抽取 → 数据核验 → 风险评估 → 建议输出。意图识别节点用大模型判断输入属于哪类任务是新申请还是补充材料还是查询进度不同意图走不同的下游分支这样能避免一个智能体处理所有请求导致逻辑混乱。信息抽取节点从客户提交的文本或上传的材料中提取客户号、申请金额、贷款期限等关键字段。这个节点我用的是轻量级模型因为抽取任务的复杂度不高没必要上大模型成本能省三分之一左右。数据核验节点是纯工具型节点调用前面配置的三个插件完成客户信息查询、征信解析、额度测算。这个节点是流程里最不能出错的环节我给它设置了超时重试和失败旁路——如果征信接口暂时不可用流程不会整体卡死而是标记待人工补录后继续往下走。风险评估节点是智能体决策的核心。它会综合数据核验节点的输出结合知识库里的风控规则给出高风险、中风险、低风险三档评价并输出理由列表。这个节点的提示词是我整个智能体里打磨最久的因为它直接影响审批建议的质量。建议输出节点把前面所有信息压缩成一份结构化报告包含客户基本信息、风险评估、建议额度、建议结论、需要人工复核的理由以 JSON 格式返回给调用方。到这里完整的贷前审批辅助智能体就串起来了。3.5 人工复核与发布最后一道安全阀流程跑通后我在风险评估节点和最终输出节点之间加了一个人工复核分支。业务规则是凡是命中建议拒绝或需人工复核的申请必须由审批专员在系统里确认后才会进入下一步。这一步在 AgentArts 里实现起来很简单相当于在编排画布上加一个等待人工审批的网关节点系统会自动生成一条待办推送给指定角色。这个设计带来的直接好处是智能体可以放开手脚去分析因为它知道自己不是最终决策者不需要为了安全而过度保守错误率反而降下来了。同时人工复核产生的每一次确认或驳回都会成为后续调优的重要数据——哪些情况智能体判断过于激进哪些过于保守一目了然。发布上线前我做了两件事。一是配置了完整的日志与监控AgentArts 自动记录每个节点的调用时延、Token 消耗和失败原因这些数据对后续成本优化至关重要。二是做了压力测试模拟了 50 个并发请求确认系统在高峰期的响应时间还在接受范围内并提前打开了限流开关防止突发流量把插件接口打爆。4. 调优实录模型、参数与结构化输出的细节4.1 模型选择不同环节用不同档位的大脑这一点很多人忽略但它对成本和效果的影响非常直观。AgentArts 支持在智能体内部按节点配置模型我实际是按任务复杂度-模型档位匹配的原则来分配的。信息抽取、意图识别这类结构化任务我用的是响应快、单价低的模型因为它们本质上是模式匹配不需要太高智商风险评估、建议生成这种需要综合判断和逻辑推导的任务换更强大的大模型。实测下来把简单任务从大模型换成轻量模型整体 Token 成本能下降三到四成而整体输出质量几乎没有变化。我在不同的客户群体测试过抽取准确率和风险评估的一致性都保持在可接受范围内。这里还有一个经验不要迷信最强的模型一定最好。在信贷评估这类对稳定性和逻辑严谨性要求高的场景强模型的表现确实好但在文档摘要和信息抽取场景它的优势会被轻量模型的成本优势抵消而且强模型偶尔还会输出一些不必要的发散内容反而需要额外清洗。4.2 温度与上下文控制随机性管理记忆模型参数里温度是最需要花心思调的。温度控制的是输出的随机性数值越高回答越多样但也越不稳定。在信贷审批场景我的建议是所有输出评估结论的节点温度设置在 0.1 到 0.2 之间让模型尽量收敛不要天马行空。客户咨询应答场景可以稍微放开到 0.4让话术更有温度。这个参数没有绝对标准但金融场景的原则永远是稳定优先随机性越低越好。上下文管理是另一个容易出问题的点。做过长对话的人都知道上下文越长越贵而且越靠后的内容模型注意力越弱。智能体跑的每轮流程其实不都是长对话有些节点根本不需要历史记忆。我在编排时明确每个节点的上下文策略数据核验节点只携带当前客户的抽取字段风险评估节点带上数据核验结果和检索到的政策片段不把客户历史闲聊内容带进来。这样既控制了成本也避免了无关信息干扰模型判断。另外一个细节是要控制知识库填充的上下文体量。检索返回的 top 6 个片段全部塞给模型的话有时会把真正的关键信息淹没。我后来在检索和模型之间加了一个重排过滤层先按相似度粗召回再用规则过滤掉与问题主题明显无关的片段只保留最相关的 3 到 4 个片段传给模型评估准确率反而提升了。4.3 结构化输出从自由文本到 JSON Schema信贷场景最怕模型输出一段话而不是一组数据。审批系统要的是 customer_id、risk_level、suggested_amount 这些字段不是我建议您考虑批贷这样的散文。所以我在智能体的建议输出节点强制使用 JSON Schema 约束实测下来效果立竿见影。我定义的输出结构大致是这样的{ customer_id: A0001, risk_level: MEDIUM, suggested_amount: 10000, suggested_term_months: 12, decision: MANUAL_REVIEW, reasons: [ 客户存在一次30天以内的逾期记录, 月负债收入比处于边界区间 ], need_manual_review: true }加了 JSON Schema 约束之后模型输出的格式错误率从最初的百分之十几降到了接近零。但要注意Schema 约束只能保证格式不能保证字段内容的正确性。我专门写了一个后校验逻辑对关键字段做类型和取值范围校验比如 amount 必须大于 0 且小于 100 万客户号必须匹配 4 位字符加数字格式。任何一条不通过就直接打回重试而不是让错误数据流到下游系统里。这也是我给金融场景同学的一条核心建议大模型输出的东西永远要经过一道程序化校验才能进业务系统。格式是最后一道坎但内容逻辑靠的是前期的抽取和校验节点。5. 常见问题与排查技巧实录5.1 查询结果为空先查表名映射我在联调阶段遇到最频繁的问题是客户信息插件返回空结果但数据库里明明有数据。一开始我以为是 SQL 生成错了后来打开日志发现大模型把数据库表名猜错了——客户主表在库里叫cust_main模型却解析成了customer。这个问题本质上是自然语言转 SQL里的表名/字段名映射问题。解决办法有两个一是在插件配置里显式声明表名和字段名的语义说明告诉模型客户主表叫 cust_main不要用 customer二是在提示词里加入字段对照表。经过这两步处理后表名解析错误率明显下降。排查这类问题最有效的方式永远是看执行日志——AgentArts 会在插件调用节点完整记录大模型生成的中间 SQL一眼就能看出解析错在哪一步。5.2 RAG检索不到新政策查索引更新有一次我更新了知识库里的某个产品细则第二天测试发现智能体还在引用旧版本的政策。排查后发现新文档上传后向量索引没有自动重建系统检索到的还是旧切片。这个坑非常典型尤其是频繁更新政策的机构。解决方法是在知识库管理页面每次上传更新版本后手动触发一次索引重建并检查新版本是否已经生效。更稳妥的做法是建立文档版本管理规范不同版本用不同的文档名旧版本及时停用或删除避免同主题的多篇文章互相干扰。我后来在流程里加了一个索引重建质检环节每次更新后跑一遍预设的检索清单确保所有关键问题都能命中新文档。5.3 插件调用超时同步逻辑改异步压测的时候发现当同时有 20 多个用户触发数据核验节点时征信接口调用的平均耗时从 800 毫秒飙到了 4 秒以上直接把流程卡住。根因是插件的同步阻塞调用占用了大量连接把下游接口的资源池打满了。处理方法分两层。第一层AgentArts 插件配置里我打开了异步调用让流程在等待外部 API 返回时不阻塞其他节点第二层给插件调用设置了超时时间默认 5 秒超时后自动走旁路标记待人工补录不让单个接口故障拖垮整条流程。另外我的经验是对外部接口做并发控制限流设置在 10 QPS 以内给下游系统留出喘息空间。高并发场景下稳定比快重要。5.4 输出格式漂移加程序化校验兜底即使是加了 JSON Schema 约束某些边界情况下模型的输出偶尔还是会出现字段缺失或者值类型不对。比如有次抽到的评估结果里suggested_amount是字符串一万而不是数字 10000程序直接报错。我再强调一次格式校验不能只依赖模型自觉。我在输出节点后加了一个轻量级的程序化校验函数专门处理大模型输出的边界异常。校验函数做的事情很简单检查字段是否存在、类型是否正确、取值范围是否合规不合规就触发一次修正重试让模型根据校验错误信息重新输出。实测下来加了这层兜底之后输出到下游系统的数据完整率达到 99.9% 以上。金融系统的数据干净程度就靠这种笨功夫堆出来。结尾踩过几次坑之后我最大的体会是在 AgentArts 上搭一个信贷审批智能体技术门槛其实不高真正难的是把业务流程的边界、数据的责任、人工的兜底想清楚。平台解决的是怎么组装而核心价值永远在为什么这样组装。最后分享一个小技巧每次调整提示词或插件一定要保留版本记录把调整前-调整后的测试结果贴在工单里。智能体的效果不是一步到位调出来的是靠一次次对比迭代堆起来的没有版本记录你连自己前面哪一步做对了都不知道。