做信贷业务的同学都清楚一个客户从提交申请到放款中间要过资料审核、征信查询、反欺诈校验、额度测算好几道关。这些环节规则密集、重复度高、文档又多是最适合上AI智能体的地方。我最近在华为云的智能体开发平台 AgentArts中文品牌叫“智果”上把一条消费贷预审流程做成了可落地的智能体从搭建、调试到发布跑通全走了个遍。这篇笔记就是我自己的实战记录重点讲清楚 AgentArts 到底能做什么、信贷智能体该怎么拆、每一步配什么参数以及我踩过哪些坑。想用AI智能体改造信贷流程、又不想一开始就碰底层模型训练的同学可以把它当作一份参考模板。1. 项目背景与 AgentArts 平台认知1.1 为什么偏偏是金融信贷先做智能化金融信贷大概是所有AI落地场景里最“吃规则”的业务线之一。客户提交申请后信审员要先核对身份资料是否齐全、征信报告有没有异常、收入流水是否稳定、负债比有没有超标再结合机构自己的准入政策给出意见。这一套流程看起来简单实际跑起来极其消耗人力。我所在的团队之前统计过一个初级信审员每天平均只能处理三四十单消费贷申请其中七成都是资料齐全、规则清晰的标准化件真正需要人工判断的只有那两三成。这种“大量重复少量决策”的结构天然适合AI智能体介入。更重要的是信贷政策的调整频率很高。以前政策一变就要改规则引擎、改审批系统上线周期按周算如果用智能体做预审把政策文件丢进知识库改一段提示词就能让系统跟着新政策走。再加上监管对信贷审批的可解释性要求越来越细智能体按结构化字段输出“拒绝原因”“风险提示”反而比传统黑盒规则引擎更容易留痕。我决定上手 AgentArts就是看中它对“业务人员可操作”的定位。不需要从头训模型不需要写复杂的前后端系统把一个智能体当成一个可对话、可调用工具、可嵌入业务流程的组件来用。对金融机构的中后台团队来说这是当前最现实的一条落地路径。1.2 AgentArts 到底解决什么问题三个平台能力拆开看如果你还没用过 AgentArts可以先把它理解成一间“智能体组装车间”。它不是给用户聊天的玩具而是面向企业级场景的一站式智能体开发平台。我实际用下来觉得最核心的能力有三块第一块是智能体编排。你可以创建一个智能体给它起名、设定角色配一套系统提示词再挂上模型。它的本质是把“人设、任务边界、输出规范”固化成一份可执行的配置模型在这个边界内干活。编排层面它还支持多智能体协作、工作流调用不是单点对话那么简单。第二块是知识库接入。做信贷智能体最头疼的就是政策文档太多而且很多是PDF、Word表格。AgentArts 的知识库功能可以直接上传这些材料平台会做切片、向量化、建立索引智能体在回答问题时先检索知识库再生成答案。我在项目里把《个人消费贷准入政策》《反欺诈规则手册》《贷后管理实施细则》三份文档全部灌了进去效果比把全部条款写进提示词好得多。第三块是工具与插件生态。智能体要真正干活光会说话不够得能调用外部系统。AgentArts 支持定义工具相当于给智能体加“手脚”。我在项目里接了OCR识别插件、征信查询接口、反欺诈评分接口、额度测算服务智能体在对话过程中自动判断什么时候调用哪个工具把结果拿回来继续加工。这样看AgentArts 解决的核心问题不是“让模型变聪明”而是“让模型在可控条件下干活”。金融机构最怕的模型乱说话、数据乱取、流程不可追踪正好是它想解决的。1.3 不直接调大模型 API选 AgentArts 的五个理由之前我也试过直接用大模型API写代码做智能体写了工具调用、上下文管理、记忆轮次、日志系统工作量不小。对比下来AgentArts 的价值在于把通用工程封装好让我把精力放在业务本身。当时说服团队选它主要基于五个理由一是开发效率。在 AgentArts 控制台里点几下就能创建智能体配好知识库和工具后立刻调试验证自己写代码至少要一周搭框架。二是工具调用的可靠性。平台把函数调用、参数校验、结果回传这些流程标准化了模型输出格式错误时还有自动纠错不需要我自己处理一堆异常。三是企业级发布能力。智能体可以发布成API服务接入现有信贷系统时用标准接口调用同时有鉴权和限流。四是审计与可观测。智能体每一步调了什么工具、取了什么数据、生成了什么决策都有日志可查金融场景必须这样。五是生态。AgentArts 和华为云的数据服务、OCR、短信、OBS存储直接打通少了艰难的集成环节。当然它不是万能的。如果你需要极致的推理控制或者有极其特殊的私有化部署要求可能要配合代码和底层模型一起搞。但对一个标准信贷预审、客服问答、资料解析场景平台化的性价比非常高。2. 信贷智能体的架构设计与方案拆解2.1 先分清确定性流程和智能决策点信贷业务拆解的正确姿势在碰AgentArts之前我踩过最大的坑就是想把整个信贷审核流程交给AI判断。后来拆了一遍业务发现这是严重误区。信贷审批流程里有大量步骤是确定性的比如“身份证信息是否识别成功”“征信授权书是否上传”“资产负债比是否超过阈值”这些根本不需要模型判断用工作流和规则就能跑。真正需要智能体发挥价值的是那些没有明确规则、需要综合判断的点比如“资料不完整时该优先补哪一项”“征信报告里的异常记录有多严重”“客户情况特殊但整体风险可控要不要转人工复核”。所以我的架构原则是确定性步骤交给工作流模糊判断交给智能体。AgentArts 恰好两个能力都支持。我在主流程里用工作流做资料校验、字段清洗、规则初筛命中“硬拒绝”条件就直接走拒绝通道只有规则无法定论的部分才交给智能体做语义分析和风险评估。这套设计不仅让系统跑起来更稳也大大降低了模型幻觉导致的误判概率。这背后有一个很朴素的道理AI智能体适合做“从不确定中找线索”不适合做“精确计算”。信贷审批里的金额、日期、比例必须交给确定性的代码和规则去算而“这份流水显示客户经营状态如何”这种问题才是模型发挥的地方。把两者混在一起系统就变成了一团浆糊。2.2 消费贷预审智能体五个子Agent的角色与协作方式我这次做的案例是一个消费贷预审智能体输入是客户提交的申请资料输出是一份预审意见包含“建议通过、建议拒绝、转人工复核”三种结论以及风险点说明和置信度评分。为了让每个环节都可控我没有做一个“万能Agent”而是拆成了五个子Agent由主控Agent统一调度。第一个是“资料解析Agent”专门负责把OCR识别出来的身份证、银行卡、流水图片转成结构化字段同时判断资料是否齐全。它要处理的是图片清晰度差、字段不全这些脏数据问题输出一份解析结果。第二个是“反欺诈评估Agent”负责对客户命中黑名单、多头借贷、历史欺诈关联进行判断。它不产生最终结论只输出风险标签和证据链。第三个是“额度测算Agent”读取流水和收入信息结合机构定价模型输出建议额度范围同时标记收入波动大的情况。第四个是“合规检查Agent”负责核对预审结论是否引用了最新的政策条款拒绝和转人工的理由是否有依据。最后一个是主控Agent它相当于调度经理统一接收任务、分配子任务、汇总结果、生成最终预审意见。这种多Agent协作方式好处是每个Agent职责单一提示词容易收敛工具调用链路也清晰。坏处是上下文管理复杂子Agent之间不能乱说话。我通过让子Agent只输出结构化结果JSON主控Agent统一组装把协作成本降到了最低。2.3 主流程与知识库规划让智能体知道“去哪里找答案”有了子Agent分工还需要一条主线把他们串起来。我在AgentArts 里配置的主流程是工单触发 - 资料解析Agent - 规则初筛 - 反欺诈评估Agent - 额度测算Agent - 合规检查Agent - 输出预审报告。每一步都有条件分支比如规则初筛发现征信授权缺失就直接退回营销端补件不再往后跑。知识库规划上我做了三个维度的设计。第一层是“政策问答库”存放准入条件、额度规则、利率政策供合规检查Agent引用。第二层是“产品知识库”存放信贷产品说明、常见FAQ供客服和营销使用。第三层是“历史审批案例库”把脱敏后的历史预审报告做成文档让智能体参照过往尺度。知识库不要一次性把所有文档都灌进去要按场景分开建。我一开始把所有材料堆在一个知识库里结果智能体检索时经常把“催收话术”当成“审批政策”来引用输出质量一塌糊涂。后来把知识库按业务域拆分限制了每个Agent的检索范围效果立刻好了很多。3. 实操过程与核心环节实现3.1 开通环境与IAM权限动手前的半小时准备开始建智能体之前先别急着打开控制台花半小时把环境和权限准备好。登录华为云后需要完成实名认证然后在控制台搜索“AgentArts”进入智能体开发平台。首次进入会提示开通服务权限按流程走就可以了。这里有一点容易被忽略AgentArts 的推理能力和单独开通的盘古大模型服务在权限上不是完全等价的建议在“权限管理”里确认ModelArts、OBS、CBS这些关联服务都做了委托授权。金融场景下千万不要在个人主账户里直接操作。我建议单独创建一个IAM子账号只授AgentArts、OBS、文字识别OCR这几个服务的最低权限。这样即使某个API Key泄漏损失范围也能控制住。同时记下账号ID后面发布API服务时需要配置访问密钥。另外金融项目的敏感数据存储尽量选择与客户数据合规要求匹配的Region并开启OBS桶加密。AgentArts 调用知识库时默认走内网传输不用额外操心网络完全性问题但桶的访问权限要设置为“仅授权服务访问”不能设成公开读。3.2 创建智能体并设置模型参数从控制台开始的完整操作在 AgentArts 控制台左侧点击“智能体” - “创建智能体”然后填写基本信息。名称我建议直接用业务场景命名比如“消费贷预审助手”不要用“Agent1”这种开发期名字后面API发布、日志排查都会用到这个名字。描述字段写上“用于消费贷贷前资料解析、反欺诈评估、额度测算与预审意见输出”方便后续维护的人理解。模型选型上我选了盘古-Lite。这里讲下我的思考盘古-Nano轻量、便宜、响应快但复杂指令遵循和多步推理能力偏弱处理征信报告语义分析时容易跑偏盘古-Pro更聪明但长上下文场景下单位成本高。信贷预审既要一定推理能力又要有性价比Lite是平衡点。如果你的机构有足够的预算、场景比较复杂也可以选Pro但建议先用Lite验证流程。参数配置里最核心的是温度和max_tokens。信贷场景的答案必须是稳定、保守的所以温度我设置为0.2越低越好避免同一个案件跑两次结论差异过大。max_tokens设置为2048预审报告的内容一般不会超过这个长度设置得太大反而增加无效计算。如果Agent需要调用多个工具并生成长报告再适当调高到4096。3.3 写好信贷员提示词一份可直接套用的模板提示词是智能体的灵魂。我写信贷预审Agent的提示词时最重要的原则是“告诉它不能做什么比告诉它能做什么更有效”。下面这份模板是我实际跑过的你可以直接抄去改你是某银行的消费贷预审助手具备多年信贷审批经验。你的任务是根据客户提交的资料、征信数据和反欺诈结果输出一份结构化的预审意见。 你必须遵守以下规则 1. 你只能依据工具返回的数据和知识库中的政策文件做出判断禁止自行编造客户的收入、负债、逾期记录。 2. 如果工具调用失败或数据缺失输出 decision REVIEW不得强制给出通过或拒绝结论。 3. 只有在规则明确命中硬拒绝条件如黑名单、虚假资料时才可以输出 decision REJECT并给出对应政策条款编号。 4. 输出必须使用 JSON 格式字段包含decision、credit_score、risk_tags、limit_suggestion、reason_codes、summary。 5. reason_codes 必须从政策知识库中的标准原因代码列表里选取禁止自由发挥。 6. 当客户情况存在争议、证据不足或涉及人工经验判断时必须输出 decision REVIEW。这样写提示词等于给智能体画了一圈护栏。它不是一个自由发挥的信贷员而是一个严格执行标准的“助理”。你需要注意系统提示词里写的每一条规则AgentArts 都会在推理时反复强化因此规则要少而准不要塞太多琐碎要求否则模型会顾此失彼。3.4 知识库接入与切片策略让政策文件真正被搜到知识库是让智能体“懂政策”的关键。AgentArts 的知识库创建入口在“知识库管理”里创建后可以上传PDF、Word、文本文件。上传后平台会自动做切片和向量化这个过程一般需要几分钟大文件更久。切片参数我是这样调的每个分块500字符分块重叠50字符。不要觉得这个参数不重要它直接决定检索命中率。如果切片太大一段文本里混了多条政策向量检索时无法精准定位如果切片太小又缺乏上下文语义检索出来像断章取义。500字符对信贷政策文本来说折中效果最好。重叠部分是为了防止政策条款被拦腰截断检索时漏掉关键句。金融文档里大量存在“征信”“授信”“代偿”“核销”这些专业词它们的同义表达很多。为了保证检索命中率我在AgentArts的知识库里开启“关键词向量”双路召回并配置了金融术语词表。实操下来纯向量检索对“逾期90天”这种精确条款容易跑偏双路召回能显著提升准确率。上传后一定要做验证测试。在知识库页面提问一个只存在于文档里的小众问题看能否命中。我当时上传附件后直接上线结果智能体回答政策问题时引用了抓取错误的上下文后来才发现是文档里有扫描版PDF文字没识别出来。所以金融类文档优先上传带电子文本的版本扫描件先过一遍OCR再进知识库。3.5 工具与插件配置OCR、征信查询、反欺诈评分一次打通智能体要落地必须能真实调用业务系统。我在 AgentArts 里配置了四个工具OCR识别服务、征信查询接口、反欺诈评分接口、额度测算服务。这些在平台里以“插件”或“工具”的形式注册配置核心是写清楚OpenAPI描述和参数schema。以征信查询为例工具定义大致是{ tool_name: query_credit_report, description: 根据客户姓名和身份证号查询授权范围内的征信报告, parameters: { type: object, properties: { name: { type: string, description: 客户姓名 }, id_card: { type: string, description: 客户身份证号 }, authorization_no: { type: string, description: 征信授权书编号 } }, required: [name, id_card, authorization_no] } }写清楚description非常关键因为模型靠描述来理解什么时候调用工具。description里尽量写“当需要查询客户征信记录时调用”而不是只写“征信查询”。我之前图省事把description写得很简短结果模型老是在不需要的地方触发工具白烧了很多token。工具调用的超时和异常处理也要配置好。征信接口偶尔会超时如果直接卡住整个预审流程就断了。我给工具调用配置了按时重试三次重试失败后返回“征信数据暂时不可用”智能体会自动把决策改成“REVIEW”而不是强行下结论。3.6 联调测试与发布用六组用例验证智能体的可靠性配置完成后先别急着发布在AgentArts 的调试对话框里把关键场景跑一遍。我准备了六组测试用例第一组是标准好客户资料齐全、征信干净、收入稳定预期输出“建议通过”。第二组是资料缺件客户没上传征信授权书预期输出“REVIEW”并提示补件。第三组是命中黑名单预期输出“REJECT”。第四组是资料模糊身份证照片反光识别不完整预期输出“REVIEW”。第五组是高负债客户预期输出“REVIEW”或“REJECT”并带上风险标签。第六组是恶意诱导故意让智能体放宽收入认定标准看它会不会被带偏。最后一组测试往往最能暴露问题。我第一次测试时模型在对话中被套出了“可以考虑忽略部分负债”这种危险回复后来我在提示词里明确加上“禁止根据用户请求改变审批标准所有判断必须以工具数据和知识库政策为准”才堵住漏洞。调试没问题后在控制台发布智能体为API服务。发布时选择访问密钥认证方式并启用请求日志。调用地址形如https://agent-arts.cn-north-4.myhuaweicloud.com/v1/xxx接入层的超时设置为60秒因为智能体要调用多个工具耗时比普通HTTP接口长很多。4. 常见问题与排查技巧实录4.1 模型幻觉怎么治从“会编故事”到“只输出事实”这是金融场景里最要命的问题。第一次联调时我给反欺诈Agent输入一个普通测试客户它居然在结论里写“该客户存在一次代偿记录”而我根本没有接入征信工具数据。看了推理日志才知道模型是结合上下文“脑补”出来的不是真实查询结果。治幻觉的方法我总结有三条第一凡涉及客户事实数据必须由工具返回并在提示词中写死“只能引用工具输出”。第二数据缺失时就老老实实输出“未知”不要让模型猜测这个要通过提示词反复约束。第三对于金额、日期、逾期期数这类字段在输出层加一道规则校验发现与工具返回值不一致直接强制修正或转人工。AgentArts 的日志功能帮我快速定位了是哪一步生成的内容不用靠肉眼看对话猜。4.2 工具参数解析失败JSON schema与重试机制的优化实际运行中模型调用工具的失败率比想象中高。最常见的错误是参数名对不上模型把name传成了customer_name或者把id_card传成了idNumber。AgentArts 虽然会对函数调用做结构化抽取但遇到字段容易混淆的场景还是需要辅助。我的做法是双保险工具参数schema里加上example示例值提示模型按原样参考同类字段名统一成平台侧的标准命名避免一个工具叫idCard另一个叫id_card。另外测试时发现工具调用偶尔返回“参数校验失败”我查看了推理日志发现模型传进来的authorization_no是“未提供”这个空值不该发请求。于是我在工具定义里增加前置条件校验必填参数为空时直接返回“参数缺失”智能体收到后自动转REVIEW。这比让模型硬调一次接口再报错要快很多。4.3 知识库检索不到切片与多路召回的经验知识库建好之后我发现智能体回答政策问题时偶尔会说“知识库中未找到相关内容”但政策文档里明明写着。排查后定位到三个原因第一PDF版本是扫描图片没有可提取的文本层向量化后全是空内容第二切片边界把所有“逾期率阈值”切成了两半导致语义不完整第三关键词检索和向量检索的权重没配合好。解决扫描件的方法是把PDF先OCR转成文本再上传这一步别偷懒。切片边界问题靠调整重叠窗口解决我把重叠字符从50调到了80同时专门检查了包含数字和百分比的段落是否完整。关键词和向量权重方面我在知识库配置里开启了混合检索并让“政策条款编号”这类精确匹配优先走关键词通道效果提升非常明显。4.4 多Agent上下文混乱摘要化与记忆清理五个子Agent协作时主控Agent的上下文很容易被撑爆也容易丢失关键信息。我一开始让每个子Agent把详细报告都回传给主控几十轮之后主控开始“忘记”前面的结论把反欺诈结果和合规检查结果混在一起。后来改成“子Agent只回传摘要结构化结论”。比如反欺诈Agent只回传{ fraud_level: medium, hit_tags: [multi_loan_high], evidence_ids: [E123, E124] }不再回传分析过程的长文本。主控Agent拿到结构化结果后直接组装需要细节时再从证据ID索引原始记录。这样上下文干净很多协作稳定性大幅提升。AgentArts 的会话历史里可以做“记忆清理”操作对临时工具结果保留几分钟就够了不用长期驻留。4.5 金融合规与留痕智能体必须开“上帝视角的监控”金融信贷场景的特殊性在于你不能只追求准确率还必须让每一个决策可以被追溯。第一版上线时我忽略了这点结果审计问询时拿不出“智能体为什么拒绝这个客户”的完整链条整个项目差点被叫停。事后我把合规能力补齐了四块一是全链路日志AgentArts 的日志记录了每一次用户输入、工具调用、模型输出这些日志在“可观测性”里可以查询导出二是决策版本管理每次修改提示词或知识库都要留版本记录注明修改人和原因三是人工复核通道凡是REVIEW的工单自动流转到人工审批台系统保留智能体的原始意见和置信度方便信审员参考和推翻四是关键字段的不可篡改校验把决策结果、政策条款编号、工具返回摘要做哈希入库防止事后被内网人员修改。这块经验我想特别强调上智能体前先和合规部门对一遍留痕要求。不要等技术跑完再补回头补审计日志的成本远远高于一开始就做好。5. 实战后的几点体会这套流程跑下来最大的感受是AgentArts把“智能体工程化”的门槛降得很低但金融业务里的难点从来不在技术而在“边界控制”。你能让模型很聪明地说话更难的是让它在该闭嘴的时候闭嘴、该交回人工的时候交回人工。我给同样在做信贷AI智能体的朋友三条建议第一从“预审”和“客服”这种低风险场景切入不要一上来就想全自动审批第二把每一个Agent当成一个“实习生”给它明确的权限范围和复核机制而不是甩给它最终决策权第三知识库的质量决定智能体的下限花时间清洗文档、调切片参数比反复改提示词更值得。最后分享一个小技巧AgentArts 的调试日志其实是最好的“老师”。每次模型输出不如预期时不要只看最终结论点开推理日志看它到底怎么理解的、为什么调用某个工具、在哪里丢失了信息。我大部分优化点都来自这些日志比看十篇文档都有用。