华为云AgentArts实战：金融信贷审批智能体从搭建到调优全记录

做金融信贷类的AI智能体，最怕的就是只会在演示环境里"能说会道"，一到真实业务场景就露馅。这篇笔记记录的是我在华为云 AgentArts 平台上，把金融信贷审批流程往智能体方向落地的完整过程——从场景拆解、工作流编排，到参数调优和问题排查。AgentArts 是华为云面向智能体编排与运行的可视化平台，正好覆盖了我需要的那套能力：插件工具封装、知识库挂载、多模型调度，以及最关键的流程编排与人工审批兜底。如果你也在搞金融信贷相关的AI应用，或者准备在云上搭建一个能真正跑业务逻辑的智能体，这篇笔记值得从头看一遍。

1. 选型逻辑：金融信贷场景为什么需要AgentArts

1.1 信贷业务不是"问答"，而是"流程"

金融信贷和聊天机器人有本质区别。一个真实的信贷审批任务，要经历客户信息采集、数据校验、征信与银行流水分析、风险规则匹配、额度建议、人工复核等多个环节，每个环节的数据源和计算逻辑都不一样。普通的大模型对话应用根本接不住这种复杂度，因为大模型本身没有事务意识，不会因为一次查询失败就自动重试，也不会主动把数据库里的结构化数据跟政策文档里的非结构化知识融合起来判断。很多团队一开始直接调大模型API做信贷问答，结果发现：问一句答一句可以，但要让它"查一下客户近三个月的流水，结合风控规则给出审批建议"，它就彻底乱了。

我选择智能体平台的核心理由就在这里：要把大模型嵌进业务流程里，得有编排、有状态、有兜底。AgentArts 这类平台提供的不是"一个大模型聊天窗口"，而是一整套智能体生命周期管理能力。你可以把多个模型、插件、知识库、人工节点串成一条清晰的业务链路，让大模型在链路中扮演"调度大脑"的角色，而不是从头到尾自己硬扛。这一点对信贷场景尤其重要，因为信贷链路天然是分段的：信息收集段、分析段、决策段、复核段，每段的容错要求完全不同。

1.2 AgentArts的能力底座与我选它的三个理由

先说清楚，AgentArts 不是一个只能拖拖拽拽的玩具级编排工具。它底层把插件系统、知识库检索（RAG）、大模型调度、流程编排、日志监控这些能力整合在了同一个平台上。我实际用下来的体感是，它解决了金融信贷类智能体落地时的三个扎心问题。

第一个是"插件接入成本"。信贷场景要查数据库、调征信接口、跑评分卡，AgentArts 支持把 API 和函数封装成标准插件，你说清楚输入输出参数，它就能在对话流里被大模型按需调用。省掉了自己写 Agent 框架和 Tool Calling 协议的一大堆底层代码。

第二个是"流程与模型的解耦"。同一个智能体里，信息抽取节点用一个轻量模型就够，风险评估节点换更严谨的大模型，AgentArts 支持按节点配置模型，而不是整个智能体绑死一个模型。这点在控制成本和提升效果上非常关键，后面我会专门展开说。

第三个是"可观察性"。平台自动记录每一轮调用的输入、中间工具返回、模型输出和 Token 消耗，所有日志可以导出。金融场景上线前要过内部审计，这种完整的调用轨迹几乎是刚需——出了问题能回溯，哪个环节错了，一眼就能定位。

1.3 常见技术路线对比，别急着动手

在决定用 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 上搭一个信贷审批智能体，技术门槛其实不高，真正难的是把业务流程的边界、数据的责任、人工的兜底想清楚。平台解决的是"怎么组装"，而核心价值永远在"为什么这样组装"。最后分享一个小技巧：每次调整提示词或插件，一定要保留版本记录，把"调整前-调整后"的测试结果贴在工单里。智能体的效果不是一步到位调出来的，是靠一次次对比迭代堆起来的，没有版本记录，你连自己前面哪一步做对了都不知道。