1. 从信贷审批的痛点说起为什么要在云上搭一个AI智能体做过金融信贷系统的人都有一个共同感受这个领域的业务逻辑复杂到让人头皮发麻。一笔贷款从进件到放款中间要过反欺诈、征信查询、收入核实、负债计算、额度定价、风险分级、合规审查等十几道关卡每一道关卡背后都是一堆规则引擎和评分卡。传统做法是把这些规则硬编码到Java服务里用Drools或者自研的规则引擎跑维护起来极其痛苦——业务改一个阈值开发改一次代码测试回归一轮上线走一次变更流程快则三天慢则两周。更麻烦的是信贷场景里有大量非结构化判断。比如客户提供的收入证明是一张截图工作单位名称写的是简称银行流水里有一笔备注为“报销”的大额入账——这些信息用规则引擎根本处理不了只能靠人工审核。一个成熟的信贷工厂人工审核团队动辄上百人成本高不说不同审核员的判断标准还不一致同一份材料两个人给出不同结论的情况并不罕见。AI智能体的出现恰好切中了这两个痛点。它能把自然语言理解、多轮对话、工具调用、知识检索这些能力串起来用一个“数字员工”去承接那些既需要理解语义又需要执行动作的环节。而华为云智果AgentArts这个平台提供的正是搭建这类智能体的工程化底座——你不用从零去搭LLM推理服务、不用自己写工具调用的编排逻辑、不用操心会话状态管理平台把这些脏活累活都封装好了你专注在业务逻辑和提示词工程上就行。这篇学习笔记记录的是我在金融信贷场景下用AgentArts搭建一个“信贷预审助手”智能体的完整过程。从需求拆解、工具设计、提示词调优到上线后的效果评估每一步都踩过坑也总结了一些在官方文档里找不到的经验。适合正在做金融AI落地、或者对智能体编排感兴趣的同行参考。不管你是刚接触AgentArts的新手还是已经用过其他智能体平台的老手这里面的思路和避坑点应该都能用得上。2. 需求拆解与方案选型信贷预审助手到底要做什么2.1 业务场景的边界划定动手之前先想清楚一件事智能体不是万能的别指望它把整个信贷审批流程全包了。我的做法是把场景收窄到“预审”环节——也就是客户提交申请后、进入人工审核前的那段自动化处理。具体包括四件事第一解析客户提交的材料。身份证、收入证明、银行流水、工作证明这些格式五花八门有PDF有图片有手填表格需要提取关键字段并做初步校验。第二回答客户的常见问题。比如“我的贷款进度到哪了”“需要补充什么材料”“利率是多少”这些高频问题用智能体承接能省掉大量客服人力。第三做初步的风险信号识别。比如发现客户填写的月收入与银行流水明显不符、工作单位在多个申请中反复出现但名称略有差异这些异常信号标记出来推给人工。第四生成预审报告。把上面三步的结果汇总成结构化摘要人工审核员看一眼就能快速判断。这个边界划定的逻辑是智能体擅长的是“理解提取初步判断”不擅长的是“最终决策承担责任”。信贷审批的最终决定必须由人来做这是监管要求也是风控底线。智能体的价值在于把人工从繁琐的信息整理中解放出来让人专注于真正需要判断力的环节。2.2 为什么选AgentArts而不是自己搭市面上搭智能体的方案大致三类纯代码框架LangChain、LlamaIndex这类、低代码平台、以及AgentArts这种全托管平台。我选AgentArts主要基于三个考量。一是工具调用的编排能力。信贷场景里智能体要调用的外部服务很多——征信查询接口、OCR识别服务、内部风控系统、工单系统。AgentArts的工具注册和调用机制比较成熟支持RESTful API、函数计算、数据库查询等多种工具类型而且有内置的重试和降级策略。自己用LangChain搭的话光工具调用的异常处理就要写不少代码。二是会话状态管理。信贷预审是一个多轮交互过程客户可能分几次提交材料智能体需要记住上下文。AgentArts内置了会话记忆机制支持按用户维度隔离还提供了记忆的过期策略配置。这个如果自研得引入Redis做会话存储还要处理并发和一致性问题。三是合规与审计。金融场景对日志和审计的要求极高每一次智能体的决策都要可追溯。AgentArts的调用链路追踪做得比较完整每个工具的输入输出、每次LLM的请求响应都有记录导出后可以直接对接内部的审计系统。这一点在金融行业是刚需自己搭的话日志埋点就是个大工程。当然也有代价。全托管平台意味着定制化空间受限比如你想改一下底层的推理参数、换一个非平台支持的模型就比较麻烦。但对于大多数信贷预审场景来说平台提供的能力已经够用了没必要为了极致的灵活性牺牲开发效率。2.3 智能体的能力矩阵设计把需求翻译成智能体的能力矩阵大概是这么个结构能力模块具体功能依赖的工具/服务优先级材料解析身份证OCR、收入证明字段提取、流水解析OCR服务、正则提取工具P0信息核验单位名称标准化、收入一致性校验内部主数据服务、校验规则工具P0风险信号异常模式识别、重复申请检测风控系统接口、历史申请查询P1客户问答进度查询、材料清单、利率说明知识库检索、工单系统P1报告生成结构化摘要、风险提示、建议模板引擎、LLM生成P0P0是首版必须有的P1可以二期迭代。这个优先级排序的逻辑是材料解析和信息核验是预审的基础没有这两块后面都无从谈起报告生成是交付物人工审核员直接看这个客户问答虽然重要但可以先用人工兜底不阻塞主流程。3. 核心细节解析工具设计与提示词工程3.1 工具注册的关键参数AgentArts里注册一个工具需要填的东西比想象中多。以OCR识别工具为例除了基本的API地址和认证信息还有几个参数直接影响调用效果。超时时间设置。OCR服务处理一张身份证图片通常1-2秒但遇到模糊图片或者大尺寸扫描件可能到5秒以上。我一开始设的3秒超时结果大量请求失败。后来改成8秒成功率从72%提升到96%。这个值的经验公式是P99处理时间乘以1.5。你可以先跑一批样本测出P99再留50%的余量。重试策略。AgentArts支持配置重试次数和退避间隔。对于OCR这种幂等操作重试是安全的我设了2次重试退避间隔1秒。但要注意如果是扣费接口或者有副作用的操作重试要谨慎可能造成重复扣款。信贷场景里查询征信报告是有次数限制的这种工具就不能随便重试。参数映射。工具定义的入参和智能体提取的实体之间需要做映射。比如智能体从对话中提取到“身份证正面照片”这个实体要映射到OCR工具的image_url参数。这里有个坑实体提取的结果可能是多种格式有时候是URL有时候是base64需要在工具层做兼容处理。我的做法是在工具前面加一个“参数预处理”步骤用一段简单的脚本把格式统一。注意工具注册时的描述字段非常关键LLM是根据这个描述来决定什么时候调用哪个工具的。描述要写清楚“这个工具做什么、什么时候用、输入输出是什么”不要偷懒写一句“OCR识别”就完事。3.2 提示词的分层设计信贷预审的提示词不能写成一大坨要分层。我分成三层系统提示词、任务提示词、工具提示词。系统提示词定义智能体的角色和边界。比如“你是一个信贷预审助手负责协助审核员整理客户材料。你不能做出最终的审批决定所有风险判断仅供参考。遇到不确定的情况标记为‘需人工复核’。”这段话看起来简单但很重要——它约束了智能体的行为边界防止它越权做决定。任务提示词针对每个具体任务写。比如材料解析任务的提示词要说明从图片中提取哪些字段、每个字段的格式要求、遇到模糊不清怎么处理。这里有个技巧是用few-shot示例。我放了3个正例和2个反例正例展示正确的提取结果反例展示常见的错误比如把“月收入”和“年收入”搞混。加了示例之后字段提取准确率从81%提升到93%。工具提示词是给每个工具单独写的调用说明。比如调用征信查询工具时提示词要说明“当客户授权查询征信且提供了身份证号时调用此工具查询结果中的逾期记录需要重点关注”。这个说明会作为工具描述的一部分传给LLM影响它的调用决策。三层提示词的维护是个体力活但值得。我见过太多人把所有逻辑塞进一段提示词里结果就是改一处崩三处。分层之后改材料解析的逻辑不会影响到客户问答维护成本低很多。3.3 会话记忆的粒度控制AgentArts的会话记忆默认是全量保留的但信贷场景里这样不行。客户可能一次对话里聊了十几个话题如果全部塞进上下文token消耗大不说还会干扰LLM的判断。我的做法是按“申请单”维度做记忆隔离。每个申请单一个会话会话内的记忆按时间窗口截断——只保留最近5轮对话和关键实体。关键实体包括客户姓名、身份证号、申请金额、当前状态这些用AgentArts的“变量”功能单独存储不随对话轮次滚动。还有一个细节敏感信息的处理。身份证号、银行账号这些不能明文存在记忆里。AgentArts支持对变量做脱敏存储我配置了身份证号只保留前6后4中间用星号代替。这样即使日志被导出也不会泄露完整信息。4. 实操过程从零搭建一个可用的预审智能体4.1 环境准备与基础配置先在AgentArts控制台创建一个新应用选“智能体”类型。基础配置里有几个选项需要留意。模型选择。AgentArts支持多种基础模型信贷场景我选的是推理能力较强的版本。原因是预审涉及多步逻辑判断弱模型容易在“收入与流水不一致时该怎么标记”这类问题上出错。代价是推理成本高一些但预审场景的调用量不大成本可控。温度参数。默认是0.7我调到了0.3。信贷场景要的是稳定和一致不需要创造性。温度低一些同样的输入每次输出更接近便于测试和审计。实测下来温度从0.7降到0.3之后同一批测试用例的输出一致性从68%提升到91%。最大输出长度。预审报告可能比较长默认的1024token不够我设成了4096。但要注意输出越长LLM“跑偏”的概率越大。我的做法是在提示词里明确要求“报告控制在500字以内只列关键信息”用提示词约束比单纯限制token更有效。4.2 工具链的搭建与联调工具链的搭建顺序建议从简到繁。先接一个最简单的工具跑通链路再逐步加复杂的。我先接的是“身份证OCR”工具。在AgentArts的工具市场里找现成的OCR模板填入自己的API密钥就能用。联调的时候用Postman先测一遍接口确认返回格式再在AgentArts里配置参数映射。这一步跑通大概花了半小时。然后是“收入一致性校验”工具。这个没有现成的得自己写。我用AgentArts的“函数计算”功能写了一段Python脚本逻辑是取客户填写的月收入取银行流水里近6个月的入账金额计算平均值如果偏差超过30%就标记异常。代码不长核心就十几行def check_income_consistency(declared_income, bank_flows): if not bank_flows: return {status: no_data, message: 无流水数据} avg_flow sum(bank_flows) / len(bank_flows) deviation abs(declared_income - avg_flow) / avg_flow if deviation 0.3: return {status: abnormal, deviation: round(deviation, 2)} return {status: normal, deviation: round(deviation, 2)}这个工具注册的时候描述写的是“校验客户申报收入与银行流水的一致性当偏差超过30%时返回abnormal”。LLM看到这个描述就知道在什么时候调用它。最后接的是“风控系统查询”工具。这个走的是内部API需要配置内网访问。AgentArts支持VPC内网调用把工具的网络配置改成内网模式就行。这里踩过一个坑内网调用的超时时间要设长一些因为内部系统有时候响应慢我设了15秒。4.3 提示词的迭代过程提示词不是一次写好的我迭代了大概七八版。记录几个关键的改进点。第一版提示词写得很笼统“请解析客户材料并生成预审报告”。结果智能体经常漏掉字段报告也写得乱七八糟。改进方法是把任务拆细每个子任务单独写提示词用AgentArts的“任务编排”功能串起来。第三版的时候发现一个问题智能体在客户没有提供某项材料时会自己“脑补”一个值填进去。比如客户没传收入证明它就在报告里写“月收入约8000元”。这是LLM的幻觉问题。解决办法是在提示词里加一条硬约束“如果某项信息客户未提供必须填写‘未提供’严禁推测或编造。”加了这条之后幻觉率大幅下降。第五版优化了风险信号的描述方式。之前是让智能体自由发挥结果它把一些正常情况也标成风险。改成给一个明确的风险清单让智能体只在这个清单里选。清单包括收入流水偏差超30%、单位名称与工商注册不一致、近3个月有逾期记录、同一身份证多笔在途申请。这样标记的准确率和一致性都好了很多。4.4 测试与效果评估测试用例的设计很关键。我准备了50个模拟申请单覆盖各种边界情况材料齐全的、缺材料的、收入异常的、有逾期记录的、重复申请的。每个申请单跑一遍智能体人工核对输出结果。评估指标定了四个字段提取准确率、风险信号召回率、报告可用率、平均处理时间。第一轮测试结果字段提取准确率81%风险信号召回率67%报告可用率58%平均处理时间12秒。报告可用率低是因为格式不统一有的用表格有的用段落。后来在提示词里固定了报告模板可用率提升到89%。风险信号召回率低是因为漏掉了“单位名称不一致”这种情况。分析发现是提示词里对“不一致”的定义太模糊。改成“单位名称与工商注册名称的编辑距离大于2时标记异常”召回率提升到91%。整个测试迭代了三轮最终指标字段提取准确率94%风险信号召回率91%报告可用率92%平均处理时间8秒。这个水平已经可以上线试运行了。5. 常见问题与排查技巧实录5.1 工具调用失败的高频原因工具调用失败是最高频的问题我整理了一个排查表现象可能原因排查方法解决方案工具超时超时设置过短/下游服务慢看工具调用日志的耗时分布调大超时时间加P99余量参数映射错误实体格式与工具入参不匹配打印实体提取结果和工具入参加参数预处理步骤认证失败密钥过期/权限不足检查密钥有效期和权限范围更新密钥确认权限返回格式解析失败下游返回格式变更对比接口文档和实际返回加格式兼容层调用频率超限下游有QPS限制看错误码是否为429加限流或排队机制其中参数映射错误最隐蔽因为AgentArts的日志里实体提取和工具调用是分开记录的要对着看才能发现。我的经验是在工具调用前加一个日志节点把入参打印出来出问题的时候一眼就能看到。5.2 智能体“不听话”的几种表现智能体不按预期执行通常有三种表现。一种是该调工具的时候不调。比如客户明明提供了身份证照片智能体却不去调OCR工具。原因通常是工具描述写得不够清晰LLM没理解什么时候该用。解决办法是把工具描述改得更具体加上“当用户提供了XX时调用此工具”这样的触发条件说明。另一种是不该调的时候乱调。比如客户只是问“利率是多少”智能体却去调了征信查询工具。这是工具描述过于宽泛导致的。解决办法是给工具加“前置条件”在描述里写明“仅在客户授权且提供了身份证号时调用”。还有一种是调了工具但不用结果。工具返回了数据智能体在生成回答时却忽略了。这通常是提示词里没有明确要求“必须基于工具返回结果作答”。加一句“你的回答必须引用工具返回的数据不得自行推测”就能解决。5.3 性能优化的几个实操技巧智能体的响应时间主要花在LLM推理和工具调用上。优化也是从这两块入手。LLM推理方面减少不必要的上下文。会话记忆里只保留最近5轮和关键实体历史对话做摘要压缩。实测上下文从4000token降到1500token推理时间从4秒降到1.8秒。工具调用方面能并行的就并行。比如OCR识别和征信查询没有依赖关系可以同时发起。AgentArts支持并行工具调用在编排里把这两个工具配成并行节点总耗时从5秒降到3秒。还有一个技巧是缓存。对于同一客户短时间内重复提交的材料OCR结果可以缓存。AgentArts支持工具结果缓存配置一个5分钟的TTL重复请求直接返回缓存结果省掉一次OCR调用。5.4 合规审计的注意事项金融场景的审计要求很严有几个点必须注意。所有智能体的输入输出都要留痕。AgentArts默认会记录但要确认日志的保留周期符合内部要求。我们内部要求保留3年需要在控制台把日志存储周期调大。敏感信息要脱敏。身份证号、银行账号、手机号在日志里不能明文。AgentArts支持日志脱敏规则配置我配了正则匹配把18位身份证号替换成前6后4加星号。决策依据要可追溯。智能体为什么标记某个申请为异常这个判断依据要能查到。我的做法是在报告里要求智能体写明“风险信号收入流水偏差35%依据申报月收入8000元流水月均入账5200元”。这样审计的时候一目了然。提示上线前一定要做一次合规审查把日志导出给合规部门看一遍。我见过因为日志里明文存了身份证号被要求整改的案例返工成本很高。6. 上线后的效果与后续迭代方向试运行两周处理了大概300笔预审申请。几个关键数据人工审核员的单笔处理时间从平均15分钟降到6分钟主要省在材料整理和报告撰写上客户咨询的人工介入率从100%降到35%智能体独立解决了大部分进度查询和材料清单问题风险信号的准确率在人工复核后确认是89%有11%的误报主要是把一些正常的收入波动标成了异常。误报的问题正在优化。分析发现主要是自由职业者的收入流水波动本来就大用固定的30%阈值不合适。后续打算按职业类型做差异化阈值自由职业者放宽到50%工薪族收紧到20%。这个逻辑要加到校验工具里同时提示词也要相应调整。另一个迭代方向是增加“材料补全提醒”功能。现在智能体发现材料缺失只是标记出来后续想让它主动生成补全清单甚至自动给客户发短信提醒。这需要对接短信网关和工单系统工具链要再扩一扩。还有一个想法是把预审智能体的经验复用到贷后管理场景。贷后要做的事情和预审有相似之处——也是材料解析、信息核验、风险信号识别只是材料类型和风险规则不同。如果能把工具链和提示词模板抽象出来复用到贷后场景边际成本会低很多。这个还在规划阶段等预审场景跑稳了再动手。整体感受是AgentArts这类平台确实把智能体开发的门槛降下来了但金融场景的落地难点不在技术在业务理解和合规把控。技术上的坑踩一踩就过去了业务上的坑如果没想清楚做出来的东西就是花架子。建议准备入手的同行先花时间把业务逻辑理清楚把边界划明白再动手搭智能体会顺畅很多。