金融信贷这个场景我一直觉得是大模型落地最“实在”的领域之一。原因很简单信贷流程天然是结构化的——有明确的步骤、明确的输入输出、明确的风险控制要求而且每一个环节都伴随着大量的人力重复劳动。正因为如此它特别适合用智能体来重构。华为云的AgentArts智果平台就是我在这个方向上的主要实验场地。它不是一个单纯的“聊天机器人搭建工具”而是一个面向复杂业务流的智能体开发与运行平台支持多Agent协作、工作流编排、知识库注入、工具调用还能把模型能力封装成业务API。我用它把一套信贷审批的前置流程做成了可运行的智能体包括客户资质初筛、资料清单自动核验、反欺诈规则预判、风险提示生成等几个核心模块。这篇文章就把我在实践里完整趟过一遍的路——从场景拆解、智能体设计、工作流编排、模型调参到部署监控、问题排查——原原本本记录下来希望能给正在考虑用智能体做金融业务的团队一些可参考的细节。1. 信贷场景拆解先搞清楚智能体该干什么1.1 信贷流程里的“人肉环节”到底在哪在动笔写智能体之前我花了大量时间蹲在业务同事旁边看一笔贷款从进件到放款到底经历了什么。金融信贷的完整链条大致是客户提交申请、客户经理录入资料、系统做征信查询、风控模型跑评分、人工审核员复核、审批人终审、放款。看起来每个环节都有系统在管但实际操作里有大量工作其实是靠人在系统之间“搬运信息”和“做判断辅助”。举个例子客户提交一份收入证明PDF审核员要做的是打开PDF看内容、把关键字段月收入、公司名称、入职时间人工录入到信贷系统、然后去比对流水数据是否一致。这个动作看起来简单但一天几十笔单子全是这种重复劳动而且极其容易出错——漏看一行数字、录错一个小数点后面风控模型跑出来的评分就全偏了。再比如反欺诈预审。有经验的风控老手拿到一份申请表看几个关键信号就知道这单要不要重点核查联系方式是否处于高危地区、单位电话和工商注册信息能否对应、紧急联系人的手机号是不是在多个申请里反复出现。这些判断本身不是特别复杂的推理但需要一个能“同时看多个数据源、快速交叉比对”的执行者。这就是智能体最合适的切入点。它不替代风控模型做最终决策而是把人从“信息搬运工”和“简单规则执行者”的角色里解放出来把审核员的精力留给真正需要经验的判断。1.2 AgentArts能在里面扮演什么角色AgentArts智果平台给我的感觉它不是为了“演示人工智能”而存在的而是真的按生产系统的思路在做智能体托管。核心能力我归纳成四个词编排、记忆、工具、评测。编排是说你能把多个子Agent串成一条业务流水线每个Agent负责一个明确的小任务上游Agent的输出直接变成下游Agent的输入。记忆解决的是多轮交互里的状态保持比如客户在对话里补充了年收入信息之后的流程能自动用上这个新信息。工具层面AgentArts提供了思维链式的插件调用机制可以接知识库检索、可以调外部HTTP API、可以执行SQL查询——这对我后面接金融数据服务至关重要。评测则是一整套对智能体效果做量化评估的机制这个在金融场景里尤为重要后面我会专门讲。如果只是一个单体的对话机器人这些需求很多平台也能做但信贷流程的复杂性在于分支多、状态多、容错要求高。AgentArts胜在把“流程”和“模型能力”解耦了业务逻辑的变化改在工作流编排里完成不需要重新训练模型这在金融业务迭代飞快的情况下价值巨大。2. 环境准备与平台基础把地基打牢2.1 开通AgentArts服务与IAM权限规划实操的第一步永远是环境准备。华为云账号是前提然后在控制台里搜索“AgentArts”就能找到智果服务。开通本身不复杂按引导操作即可但有几个细节我建议提前规划。第一个是区域选择。AgentArts依赖OBS、ModelArts等周边服务不同区域的资源是隔离的我一开始就在区域A开通了AgentArts却在区域B建了OBS桶等配置知识库导入的时候才发现跨区域访问要额外配置IAM委托绕了一圈。建议用之前先确认好Bucket、Agent、模型部署在同一个Region能省掉大量网络配置的麻烦。第二个是IAM权限。金融场景下权限控制必须细致不能图省事用admin账号来跑。我的做法是拆成三组角色角色需要的最小权限用途Agent开发者AgentArts全量权限、OBS读写、ModelArts推理服务调用日常开发、调试智能体业务运营人员AgentArts运行态只读权限、对话日志查看权限日常监控、处理异常会话审计人员日志服务只读权限、无Agent编辑权限合规审计、抽查对话记录这么做的好处是出了问题能快速定位是谁在哪个环节改了什么避免了一锅端式的责任不清。金融行业对操作审计有硬性要求这个习惯最好从第一天就养成。2.2 三个核心概念Agent、Flow、KnowledgeAgentArts里有三个基本概念必须理解透否则后面排流程的时候会一头雾水。Agent是一个具备独立能力的单元。它有自己的系统提示词、可以挂模型、可以绑定工具。类比的话Agent像一个“岗位”——信贷资料核验专员、反欺诈预审专员、风险提示生成专员每个岗位有自己明确的职责描述和工作方式。**Flow工作流**是Agent之间协作的路径编排。Flow描述了任务如何从一个Agent流向下一个Agent什么条件下走分支什么条件下结束。它不是写代码而是图形化的节点连接有点像在画一张业务流程图但每个节点绑定的是智能体能力。**Knowledge知识库**是Agent的外部记忆。信贷业务有大量的政策规则、产品手册、操作指引这些内容不可能全部塞进模型上下文里。知识库负责把文档切分、向量化、存储在需要的时候把最相关的内容检索出来喂给模型。我一开始犯过的一个错误是把所有业务规则写进Agent的system prompt结果提示词膨胀到几千字模型在长上下文的压力下开始“忽略”后面的规则回答质量明显下滑。后来改成把规则放知识库里靠检索获取把Agent的角色定义和关键约束精简地留在系统提示词里效果立刻不一样了。这是Agent开发里一个很重要的取舍什么放提示词什么放知识库什么放工具逻辑需要根据场景反复权衡。3. 智能体设计把信贷审核流程拆成Agent协作网3.1 用“岗位思维”做Agent边界划分做信贷智能体最容易踩的坑是“一个Agent搞定所有事”。我见过有团队把资料核验、信用评估、额度建议全塞进一个Agent里结果是在对话里经常出现角色混乱——上一句还在做资料格式检查下一句就开始聊额度审批业务语义边界彻底模糊。我用的是“岗位思维”来划分Agent边界。每个Agent只负责一个业务岗位的工作内容岗位之间通过Flow串起来。针对信贷场景我划分了四个Agent第一个是客户交互Agent负责和申请人的对话收集基础信息、解答流程性问题语气亲和不涉及任何审核判断。第二个是资料核验Agent接收客户上传的各类证明材料调用OCR能力识别关键字段然后和申请表里的信息做交叉比对输出差异清单。第三个是反欺诈预审Agent把申请表里的联系方式、单位信息、关联人员等数据与黑名单库、关联图谱做匹配生成风险标记。第四个是风险提示Agent汇总前三个Agent的输出结合预置的风控规则库生成“人工审核关注要点”给审核员提供决策辅助。这样划分的好处是每个Agent的职责清晰、提示词简洁、工具列表明确测试起来也容易——出了问题直接定位到具体Agent不用在一团糨糊里找原因。3.2 用Flow编排信贷进件主流程四个Agent划分好了接下来要解决的是“谁先谁后”“什么条件下走哪条路”。这就是Flow编排的用武之地。我的主流程设计是这样的客户在入口提交申请后先进入客户交互Agent做信息采集。采集完成触发“资料上传”事件此时Flow把控制权交给资料核验Agent。资料核验有两个分支如果核验通过进入反欺诈预审如果发现关键材料缺失或信息不一致走“补充材料”分支回流到客户交互Agent继续对话。反欺诈预审的结果也有分支高危案件标记出来直接转人工紧急处理一般风险或者低风险案件进入风险提示Agent生成审核关注要点最后统一汇总输出到信贷系统的人工任务队列。这里要特别强调Flow里的“分支条件”可不是随便写写。我在编排的时候把分支条件的判断逻辑放到了专门的“规则节点”里而不是让模型自由发挥。原因很简单信贷场景下的流程走向必须确定、必须可审计模型判断会存在一定概率的漂移而规则节点跑的是程序化逻辑保证同一种情况永远走同一条路。这其实是Agent落到严肃业务里的一个关键思想能用代码写死的分支就不要依赖模型判断把模型的能力集中在理解、归纳、生成这些真正的智能环节上。3.3 金融数据服务的接入方式信贷智能体必须能实时获取外部数据比如征信报告摘要、工商信息、黑名单列表。AgentArts里接入这类服务主要是通过“工具”来实现。我走的方案是把金融数据服务封装成一个RESTful API然后以“自定义插件”的形式接入AgentArts。这里有几个细节值得提一下。认证方式我选用了API Key认证而不是长期Token设置较短的过期时间定期轮换降低泄漏风险。金融机构对API调用的安全防护要求严格我对外部接口一律走HTTPS且在平台侧开启了流量加密。超时设置也是个大坑。征信查询接口有时响应慢我一开始设置的是5秒超时结果模型等着等着就“焦虑”了频繁重试白白消耗token。后来调整策略把外部API默认超时拉长到15秒并在接口查询期间给Agent一个提示“数据查询中请稍候”让交互体验顺畅很多。还有一个重要心得是把所有工具调用结果统一转成结构化JSON再给模型。如果直接传一段杂乱的文本给模型它会花精力去“理解”这段文本的结构产生幻觉的概率也会上升。JSON化的好处是字段清晰、含义明确模型的提取和推断准确率明显提高。4. 核心能力实现让智能体真正“能干活”4.1 资料核验Agent的OCR与字段比对资料核验这个环节核心是OCR识别的准确性。客户上传的身份证照片、收入证明、银行流水质量参差不齐有反光的、有倾斜的、有拍照模糊的。AgentArts里可以直接调用华为云的OCR服务这里我建议不要把OCR能力直接暴露给Agent对话层而是用“结构化抽取”的方式。具体做法是OCR识别出文字之后再用一个信息抽取模型可以直接用大模型把关键字段抽出来比如“月收入”“公司名称”“任职岗位”生成一个JSON对象。这样后面与申请表的比对就变成一个字段级的JSON diff而不是让模型去“读”两份文本然后做判断可靠性高很多。字段比对规则我写在Flow的规则节点里姓名、身份证号必须完全一致手机号允许尾号相同但号码不同则标记差异月收入与银行流水均值允许正负10%的浮动超过这个范围就提示人工核查。这类规则非常重要——它们让智能体的判断结果可解释、可追溯在金融合规审计时能拿得出依据。4.2 反欺诈预审Agent的图谱与名单匹配反欺诈预审不能只做简单的名单匹配更要关注“关联关系”。举例来说一笔小额信贷申请里的紧急联系人与另外三笔历史不良申请共用同一手机号这就是一个强风险信号。这类关联信息通常存在信贷系统的关系图谱里Agent需要能去查询图结构并把结果转化成风险判断的依据。我在AgentArts里给反欺诈Agent配置了一个图谱查询工具输入维度是姓名和身份证号返回这个人的一度关联、二度关联的风险事件。Agent拿到返回结果后会结合预置规则生成风险标记比如“命中高危关联群体”“联系方式属于高风险区域”“单位对公电话为空号”。这里要提醒一点不要让模型自己决定“什么算风险”。模型负责把图谱返回的数据整理清晰但最终的“是否标记为高风险”必须走规则判断。我的实现是图谱工具返回原始数据后Flow里的规则节点做判定只把判定结果交给模型去生成解释文本。这样既保留了模型的表达优势又保证了决策标准的一致性。4.3 用知识库承载信贷合规政策信贷业务的政策变动频繁与其频繁改提示词不如把政策内容放在知识库里随时更新。我在AgentArts里建了三个知识库公开产品规则库、内部审批指引库、合规红线清单库。知识库配置的关键在于文档切分方式。一开始我用的默认切分参数结果很多政策条款被切得七零八落——一条完整的规则被拆成了两段检索的时候只召回一半导致Agent“断章取义”。后来我把切分策略调成“按照条目标题切分”每条政策作为一个独立chunk再叠加上下文重叠30%召回质量明显改善。另一个心得是知识库内容要做“风控友好化”处理。原始政策文件里经常有“原则上”“一般情况”这类模糊表达放进知识库后模型在生成回答时会模仿这种语气导致给审核员的建议不清晰。我在上传前先对文本做了预处理把模糊表述转换为带条件的清晰条款比如“原则上禁止”转成“除下列特殊情况外禁止”。这个动作虽然费一点人工但值得做。5. 智能体评测上线之前先过“考试”5.1 搭建金融场景评测集很多人在搭建智能体时忽略评测上线后模型回答不稳才来救火。金融场景对输出的稳定性要求极高所以我花了大量精力在评测上。我搭了一套评测集包含三个维度流程正确性、知识准确性、风险敏感性。流程正确性是指Agent是否按预期走完了每一步知识准确性是指回答内容是否与政策条款一致风险敏感性是指面对诱导性、试探性的提问Agent能否坚守合规底线。评测集的实际样本包括正常进件的完整对话记录、缺少材料的半截申请、涉及特殊客群的敏感案例、以及专门用来“对抗”的诱导性问题例如套取内部审批规则、询问规避风控的方法等。这些样本的数量我做到了几百条覆盖了主要业务分支。5.2 关键指标解析别只盯着对话流畅度评测指标里我最关注三个任务完成率、工具调用准确率、合规越界率。任务完成率衡量的是流程的完整闭环率——比如资料核验Agent在评测集里完成了多少笔完整的核验动作没有中途“跑飞”。工具调用准确率衡量的是Agent在需要调API时是否正确选择了工具、传参是否正确。合规越界率这是金融场景特有的指标统计Agent面对对抗性提问时是否有不当回复。这里面我要特别讲一下工具调用准确率。大模型在调用工具时经常出现“参数幻觉”比如把数字字段传成字符串、把日期格式传错。我通过评测发现这个问题集中在“金额”“日期”这类有严格格式要求的字段上。解决办法是在工具描述里把字段格式写得极其明确并给出示例值。比如接口query_credit_report 参数id_card身份证号18位字母大写 loan_amount贷款金额单位元整数在描述里明确注明“身份证号码中若含X必须大写”就能把这类错误的出现频率大幅压下来。这些细节就是评测的价值——不跑一遍你根本不知道模型会在哪个不起眼的地方犯低级错误。6. 部署与运维从Demo到生产环境的基本功6.1 发布策略灰度、版本与回滚AgentArts支持将智能体发布为在线服务也支持通过API集成到既有信贷系统。我的经验是先走“旁路模式”上线初期不直接让智能体的输出进入决策链路而是让它和人工审核并行跑对人工结论做比对验证准确率稳定后再逐步切换。版本管理是另一个不能忽略的点。AgentArts的每一次改动我都打一次版本发布时走灰度流程先在测试环境跑评测集再放量到5%的流量观察线上表现确认无误后全量切换。这一套流程和传统软件开发保持一致但在智能体场景里有一个额外的坑——模型版本不是固化的。基座模型升级后同样的Agent编排可能产生不同的行为表现。所以每次基座模型版本有更新哪怕Agent代码没动我也强制要求重跑一遍评测集绝不能默认“没动就没问题”。6.2 日志、监控与告警体系金融场景对可观测性要求非常高。AgentArts提供了完整的运行日志我建议在接入手把对话全链路日志做结构化上报——对话内容、Token消耗、工具调用参数、延迟、分支走向全部记录。我在监控上重点设置了几类告警规则接口响应时间超过阈值、单Agent连续失败超过5次、合规词命中频率突增、工具调用错误率高于5%。其中合规词告警是我特别定制的一旦监测到客户对话内容里出现某些敏感词立即发送告警给运营人员确保第一时间介入。另一点心得是Token消耗监控。大模型应用的Token费用在规模上来之后不可忽视我按月统计了每个Agent的Token消耗发现客户交互Agent占了总消耗的一半以上因为它是对话轮次最多的环节。据此对交互Agent做了优化把问候语和历史信息自动填充减少无效提问轮次单会话Token消耗降了约三成。7. 常见问题与排查技巧实录7.1 意图识别不准导致流程走错分支实践中出现最频繁的问题是Agent把用户意图识别错了导致走了错误的分支。比如客户说“我明天再传材料吧”正常应该走挂起、等待补充但有一次模型理解成“取消申请”流程直接终止了。排查思路是先看日志里的置信度分数再看模型输入输出。我后来在客户交互Agent的分支节点前加了一个“意图确认”环节当某类非标准操作意图的置信度低于阈值时Agent会先反问一句“您是想暂停申请还是取消申请”让客户明确确认。虽然多了一次对话但流程正确率提升非常明显。7.2 工具调用参数经常传错这个在上文提过但我还想再强调一下它的普遍性。模型经常在时间类参数上出错比如把“2025-03-01”传成“2025-3-1”或者在金额上犯单位错误把“万元”当“元”。除了优化工具描述之外我还用了一个“强约束”的方法在Flow的规则节点里做参数校验发现格式不对就自动纠偏。身份号码可以通过校验位规则校验金额字段可以由Agent正则提取后再做转换多了一层兜底之后工具调用的成功率从最初的83%提高到97%以上。这类工程化的兜底逻辑是Agent走向生产环境的关键不能完全依赖模型的自觉性。7.3 知识库检索召回质量不佳知识库检索不到相关内容是另一个高频问题。现象是Agent答非所问或者回答的内容看似相关但关键点缺失。排查后发现大部分情况是query与知识库文本的语义距离过远。比如客户问“我现在换工作了还能贷吗”而知识库里对应的政策标题是“在职状态变更对审批结果的影响说明”语义检索结果排名靠后。我的改进方式是做关键词扩展和同义改写在query输入检索前先让一个轻量模型对问题做“检索意图改写”把口语化表达改写成关键词组合再送进向量检索。这个做法简单有效检索命中率提升显著。另外知识库的定期更新也要纳入运营流程。我发现信贷政策更新后旧版本的内容如果没有及时下线Agent有时会引用过时条款。现在每次政策变更我都会同时完成新条款的入库和旧条款的标记下线确保知识库内容始终和现行制度对齐。8. 最后聊几句实在话这套系统从搭建到稳定运行最深的体会是做金融领域的智能体重点永远不是让模型显得“聪明”而是让整个流程“靠得住”。模型负责感知、理解和生成但决策判断、分支走向、风险红线都需要用工程化的手段牢牢锁住。AgentArts这个平台给了我比较好的编排自由度把复杂的业务逻辑做成了可视化的流程排查问题也不再是无头苍蝇。如果你也在考虑把智能体引入到自己的业务系统里我的建议是先找一个人工成本最高、规则最清晰的小场景切入比如资料核验、表单预填、风险预审跑通之后再横向扩展。不要一上来就想做个“万能信贷助手”那种项目大概率会卡在多需求纠缠的泥潭里。最后再分享一个小技巧每次AgentArts的模型版本一更新你别急着切线上先在评测集上跑一遍对比结果用数据说话。模型升级可能是提升也可能是退化在AI应用里“稳定”有时候比“先进”更值钱。