前段时间我一直在和华为云智果 AgentArts 死磕一件事：把金融信贷场景里的贷前初审流程，从人工填表、人工翻材料，改造成一个真正能跑的AI智能体。起因很现实——一条消费信贷产品线的申请量翻了一倍之后，初审团队已经忙到需要周末加班补材料，而大部分时间都在做重复核对：收入证明和流水是否对得上、联系人信息是否完整、有没有明显多头借贷的迹象。业务方说，能不能让大模型帮我先筛一遍，把明显不合格的直接拦掉，把需要斟酌的送到人面前复审。
直接丢给一个通用聊天机器人是不太现实的。这类问题不只是模型会不会出错，更在于审批动作必须可回溯、可解释、可审计。当时我梳理了一圈，华为云智果 AgentArts 刚好提供了一个面向智能体编排的落地环境，支持把模型能力、规则校验、工具调用、人工复核都串在同一个工作流里。于是我用脱敏业务样本模拟着跑了一遍完整流程，这篇学习笔记就是把从需求拆解到工作流搭建、再到测试调优的过程完整记录下来。如果你正在做AI智能体应用，又关心信贷风控或审核自动化，这篇内容应该能帮你少踩几个坑。
1. 为什么要用AI智能体来做金融信贷初审
1.1 信贷流程里那些真正耗人的环节
先说业务端。信贷审批通常分贷前、贷中、贷后三段。贷前是用户申请和资料进件，贷中是风险评估和审批决策，贷后是放款后的监控和催收管理。大多数人理解的“智能审批”集中在贷中，也就是拿到一堆资料后判断这个人能不能借、借多少。但真正占人力的恰恰是贷前的资信初筛：申请人提交的身份证件、收入流水、社保截图、联系方式、工作证明，格式五花八门，有的还是拍照件，需要人工识别、补录、汇总，然后才能进入评分环节。
一个初审专员一天处理几十份已经是极限，而且看久了容易漏。Agent 擅长做的正好就是这类“信息收集—结构化—校验—初判—给结论”的工作。它不是替风控专家做最终决策，而是先把脏活累活接过来，把机器能明确判断的规则跑完，再让人把精力集中在复杂案例和人工沟通上。我这次选择用“消费信贷贷前初审”作为切入点，原因很简单：流程清晰、规则明确、材料模式相对固定，容易验证智能体效果，也很容易衡量它的业务价值。
当然，真实信贷场景非常严谨。我这里做的所有演示都是基于脱敏模拟数据，不会涉及真实客户信息；真正生产环境中调用征信、流水核验等数据源，必须走持牌机构的合规通道。这些在后面工程环节还会反复强调。
1.2 智能体、规则脚本、纯大模型这三条路的差别
先说传统做法。很多机构现在跑的是“埋点表单+规则引擎+人工复核”：用户填入前端表单，后端用一组 if-else 规则判断收入、年龄、行业等硬性指标，不满足的直接拒绝，满足的推到人工。这个方案的好处是稳定、可解释，坏处是僵化——用户填错了几个字段就要来回退件；材料是图片时，规则引擎根本处理不了。
纯大模型方案呢？把材料全部丢给 Chat 模型，让它直接输出“通过/拒绝”。这在一两个样例上看着聪明，但放到生产里就露怯了：模型既不会去调外部接口取数，也不会稳定地按固定格式返回，更说不清自己每一步判断用了哪些材料，导致复核变得很困难。
Agent 智能体则处于中间：外部行为上它有“规划—调用工具—观察结果—再决策”的循环，可以一边分析材料，一边调用 OCR、人脸核身、黑名单查询等接口；内部输出上又可以通过系统提示词和结构化约束，强制模型给出 JSON 结果和依据 ID。加上 AgentArts 这类平台本身提供工作流编排和节点状态保存，整个执行过程可以一步一步留痕，满足了信贷场景非常看重的可解释和可回溯要求。这也是我最后选择智能体路线而不是堆 Prompt 的核心原因。
2. 整体设计：先拆角色，再编排工作流
2.1 从信审专员到Agent角色的映射
一个信审团队的岗位分工大致是：客服接待负责解释流程、收集材料；初审专员负责材料完整性和硬性门槛校验；反欺诈专员查黑名单和关联风险；风控审批人看评分卡和授信额度；贷后专员做监控和提醒。对应到智能体设计，我建议不要只做一个大而全的万能 Agent，而是拆成一组职责单一的小 Agent。
我这次拆了四个角色：受理 Agent 负责接待和材料收集，识别用户意图并引导上传；初筛 Agent 负责材料完整度校验、OCR 识别结果核对、硬性准入规则判断；风控 Agent 负责调用反欺诈接口，结合信用评分模型给出风险等级；决策 Agent 负责汇总前面所有结果，生成审批建议和复核要点。每个 Agent 的提示词都不一样，工具权限也不一样，单独调优、单独压测都方便。
刚开始我也想少拆几个，用一个大模型力挽狂澜。结果发现当几个任务混在同一个提示词里时，模型经常在“到底应该拒绝还是转人工”的分支上反复横跳。拆角色之后，每个 Agent 只管一个窄边界，出错概率明显下降。这就像团队里为什么要有独立风控岗一样——职责边界清晰了，责任才清晰。
2.2 为什么我把工作流作为第一优先形态
AgentArts 上可以两种方式搭建智能体：一种是“对话式智能体”，让模型自由编排工具调用，适合开放域任务；另一种是“工作流式编排”，把节点用有向无环图串起来，步骤执行顺序固定，支持条件分支、规则节点、人工审批节点。
这在信贷场景下几乎是标准答案。风控流程不接受模型自由发挥：提交材料之后，必须先查完整性，再到反欺诈，再到额度评估，顺序反了结论就可能错。工作流还有一个好处是每步都有状态和日志，出了合规问题可以直接从平台导出执行轨迹。市场上一些纯模型的 Agent 框架跑对话很顺，但真要落地金融业务时缺少“强制节点+人工审核节点”，反而要自己写很多胶水代码。AgentArts 这里能直接托底，省了不少事。
当然，自由编排不是完全不用。比如用户问“我的材料要补什么”这类非结构化咨询，我仍然用对话式智能体去回答，但所有会产生审批结论的动作全部走工作流。一句话总结：对话只负责沟通，决策只走流程。
2.3 每个Agent的职责边界与数据权限
设计 Agent 时还有一个容易被忽略的点：数据权限隔离。初筛 Agent 只需要看到材料元数据和 OCR 结果，不需要看到用户的完整社交关系；风控 Agent 才允许访问反欺诈接口；决策 Agent 最后汇总时可以看到所有环节的结果，但它的输出只能写到合规的审批结果表中。如果所有 Agent 共享同一个大模型环境变量，很容易因为一次越权调用导致数据泄漏。
在 AgentArts 平台上，我建议把敏感数据的读取放在“工具节点”层面：工具是封装好的，Agent 只能调用工具接口，拿不到底层数据库连接。这样即使模型在提示词里被诱导，它能调用的范围也是受限的。再加一层节点级访问控制，谁能读哪个字段就由权限模型管，不由模型的判断管。这一点对金融场景来说不是加分项，是必须项。
提示：真实生产环境的数据源申请、密钥管理、接口调用合规，都需要跟机构的安全团队一起过。员工权限和 Agent 权限要分开管，别把管理员账号直接配给智能体用。
3. 实操落地：从0到1搭一个贷前资信初筛Agent
3.1 开通平台与创建智能体时的基础配置
第一次打开 AgentArts 控制台时先别急着写提示词，把基础信息设好。名称、描述、模型选择、使用场景，这几个字段直接影响平台后续给智能体推荐的能力范围。我选的模型偏好里，文本理解、工具调用、结构化输出三个能力都要开，尤其是结构化输出，后面判断结果是否合规全靠它。
数据接入方面，我用的是离线脱敏样本表：一份申请材料 JSON、一份 OCR 识别结果、一份评分卡字段。这些数据放在云上的对象存储里，智能体通过平台配置的数据源节点读取，不直接对业务库开放。如果生产环境要接真实系统，记得先在 IAM 里建好最小权限账号，密钥走凭据管理，不要直接写在环境变量里。这是金融项目上线前的底线。
这一步看起来琐碎，但它决定后面跑流程时能不能快速定位问题。我第一版配置时图省事，把所有 Agent 挂在同一个项目空间下，结果日志串在同一个执行轨迹里，排查问题要翻半天。后来按角色拆成四个子应用，每个子应用独立发布，问题定位立刻快了很多。
3.2 核心工作流节点的设计与参数
我的主工作流“贷前资信初筛”一共六个节点，串成一个有向无环图。
| 节点名称 | 输入 | 处理逻辑 | 参数/阈值 | 输出 |
|---|---|---|---|---|
| 材料接收 | 用户上传文件 | 校验格式和数量，触发 OCR | 支持 png/jpg/pdf，单个文件≤5MB | 文件清单 |
| 内容结构化 | OCR 文本 | 调用文档解析模型，抽取收入、单位、家庭住址等字段 | 置信度≥0.9 | 结构化 JSON |
| 硬性规则校验 | 结构化 JSON | 年龄、申请地区、行业黑名单、多头借贷标记 | 年龄18-60；多头标记≤3 | 校验结果表 |
| 反欺诈查询 | 申请人标识 | 调用合规反欺诈接口（演示环境用模拟接口） | 风险等级A/B/C/D | 风险标签 |
| 风险评分 | 规则结果+反欺诈标签 | 评分卡模型 | 阈值600 | 评分与建议 |
| 人工复核 | 全部环节结果 | 推送给有权限审批人，补充意见 | - | 最终审批建议 |
表格里的阈值不是拍脑袋定的。年龄 18-60、多头标记≤3，这些规则先原样搬过来，等积累了踩坑数据再调。“置信度≥0.9”这一步很关键，OCR 识别结果低于这个阈值的材料不做自动判断，直接进人工，避免图片模糊导致误判。在 AgentArts 里每个节点都可以设置超时和重试次数，像外部接口调用，我习惯设三次重试、每次超时 5 秒，超时后节点标记为失败并转人工。
参数配置方面的取舍是：宁可多转人工，不要错杀漏杀。金融场景里，漏过一个高风险客户带来的损失，远比多复核一份材料的成本高。这也是为什么我把“置信度不足”和“外部接口异常”都归类到“转人工”，而不是简单地“拒绝”。
3.3 提示词设计与模型行为约束
工作流搭好后，最关键的就是每个节点的模型提示词。我总结了一套相对稳定的写法：角色约束、任务边界、输入输出格式、异常处理、禁止行为。以初筛 Agent 为例，系统提示词大概长这样：
你是一名银行信贷初审助理，只负责贷前材料初审，不做最终审批决策。 输入：申请人OCR识别后的结构化材料JSON。 任务： 1. 检查必填字段是否齐全，缺字段时列出缺项。 2. 按给定硬性规则逐项判断，规则以JSON数组形式提供。 3. 输出固定结构，不允许额外解释或编造字段。 输出格式： {"decision":"approve/review/reject","reason_code":["MATERIAL_INCOMPLETE"],"missing_fields":[],"risk_flags":[],"summary":"一句话说明"} 禁止行为： - 不得读取或猜测与材料无关的个人信息。 - 不得输出空泛建议。 - 不确定时输出"review"，并说明需要人工关注的原因。这个提示词里的关键在于规则以 JSON 数组形式传入，而不是全部写在自然语言里。这样模型不会被修辞带偏，规则变更时也不需要重新调提示词，只要改规则表就行。结构化输出我同时要求平台开启 JSON Schema 校验，不符合格式的直接触发重试，重试两次还失败就转人工。
还有一个细节：我刻意要求模型在摘要里写“一句话说明”。这是为了让复核人员不用逐个字段去对，直接读取摘要就能判断模型当时的决策思路。先输出结构，再输出解释，可解释性问题就解决了一大半。反过来让模型先自由解释再自己解析，解释内容容易和结论脱节。
3.4 结构化输出：让模型开口说人话，更要开口说准话
金融审批结果就三种状态：通过、复核、拒绝。分类一一对应到输出层的 decision 字段。为了不出现模型自创的边界情况，我在输出节点多做了一层后处理：用一段规则代码把模型输出映射到标准枚举，包括对未知枚举值的兜底映射。
def map_decision(raw): # 标准化模型输出到审批枚举 mapping = { "approve": "PASS", "reject": "REJECT", "review": "MANUAL_REVIEW", } # 兜底：任何未识别结果一律进入人工复核 return mapping.get(str(raw).strip().lower(), "MANUAL_REVIEW")为什么需要这个兜底？因为模型大概率会按提示词输出，但在异常用词、多语言混合情况下仍可能出现非预期值。如果系统直接把未知枚举当拒绝处理，风险就是误伤客户；如果当通过处理，风险更大。所以兜底到人工复核是最稳妥的。
结构化输出之外，我还做了字段级置信度回传。评分节点不仅给出分数，还给出“材料可信度”0-1 数值，字段置信度低于 0.8 的不参与自动决策。这一步看起来增加了输出复杂度，但实际上帮我减少了很多误判排查工作。
4. 测试调优与上线前的那些坑
4.1 用脱敏历史样本建一套评估基线
任何 Agent 落地前必须有一份量化基线，否则你不知道它到底是变好了还是变坏了。我拿了业务方提供的 200 条脱敏历史记录，其中 80 条为最终通过、70 条为拒绝、50 条是转人工后人工通过。让智能体在离线环境重跑一遍，把决策和真实结果对齐。
评估指标方面，我不只看准确率。对于审批场景，核心是三组指标：
- 通过率一致性：模型自动通过的比例应该和历史通过率大致接近，避免模型放水或从严。
- 高风险拦截率：在历史拒绝样本中，模型能识别出多少。这一项是风控最关心的，我实测首批在 87% 左右，调优后到 91.3%。
- 人工复核率：自动判断中需要转人工复核的比例。初版经常到 40%，瓶颈是 OCR 置信度不足，调优后稳定在 15% 以下。
这里强调一下：我用的“历史通过”指的是真实业务中通过并正常还款的样本，“历史拒绝”里既包含硬性规则拒绝，也包含人工综合判断拒绝。如果你手头没有这种带标签的数据，至少也要先人工抽 100 条典型样本跑一遍，否则后面每次调 Prompt 都不知道改对了没有。
4.2 第一轮自测就暴露的三个问题
第一轮自测结束时，我整理出三个问题，估计大家自己做也会撞上。
第一个是模型幻觉导致错误标记。有一条材料里，申请人实际年龄 39 岁，OCR 把身份证年份识别成“19”开头还是没问题的，但模型在规则判断时受训练语料影响，输出了一个不存在的风险标签。后来我在规则节点前先跑一层确定性校验，把硬性规则从模型判断里剥出来，模型只负责综合语义判断。规则归规则，模型归模型，这句话真的是跑通了才懂。
第二个是工具调用参数幻觉。模型在调用反欺诈接口时，有个参数本该传“申请人姓名+身份证号”，它有时候会漏传身份证号，导致接口报错。排查发现不是模型不会调，而是多轮工具返回后上下文过长，参数复制错了。我的解法是在工具定义里加上必填参数校验，由平台在调用前拦截并让模型重组请求，不是等返回结果后才发现问题。这个机制后来几乎没有再触发过。
第三个是转人工理由写得太模糊。初版摘要经常是“材料存在风险，请人工复核”这种废话，复核人员拿到单子还要自己去翻材料。后来我在提示词里强制要求输出 risk_flags 枚举，并在后处理里映射成“流水与收入不匹配”“申请人地址在限制区域”等标准话术，复核效率才真正上来。
4.3 上线之前还得补的合规与工程细节
测试通过并不代表能直接上线，尤其金融场景。我在正式发布前补了几件事，按优先级列出来。
审计日志：AgentArts 平台本身有执行日志，但业务侧还需要把“每次调用、输入材料脱敏 ID、决策结果、复核人 ID”落到独立审计表，避免只依赖平台日志。一旦出现争议，可以拿审计表说话。
人工复核兜底：不管模型结果多好，我始终保留“高风险客户必须人工决策”的开关。系统里给决策 Agent 加了一条策略：风险等级为 D 或置信度低于 0.8，直接进人工，不允许走自动通过。
灰度发布：先在 5% 真实流量上跑一周，对比模型判断和历史审核的一致性，再逐步放大到全量。即便一周平稳，之后每次改 Prompt 或规则都要再走一轮灰度。
会话隔离：不同 Agent 之间不共享上下文，防止资料信息被其他场景错误引用。成本会高一点，但值得。
还有一条要提醒：任何涉及个人金融信息的 AI，上线前要和合规、法务一起过一遍个人信息保护影响评估。这部分不是技术债，是业务能不能活下来的前提。
5. 学习笔记的最后：一点体会与后续扩展方向
5.1 回头再看这次实战，我最大的收获
整个项目跑下来，我最深的体会是：做金融信贷 AI 智能体，难点不在于让模型变聪明，而在于给聪明套上缰绳。AgentArts 这类平台提供的价值也在于此——它把规则节点、工具节点、人工节点和模型输出串成了一根可审计的链条。你可以先让模型负责理解模糊信息，再用规则和人工兜底处理不确定性，既享受 AI 的效率，又保留合规的余地。如果只拿一个模型裸上，哪怕加了再长的提示词，在这个领域都很难让人放心。
5.2 接下来我准备往这几个方向继续折腾
后续我还有几个想继续做的方向：一是把贷后监控做成 Agent，用定时任务跑还款行为数据，发现异常自动生成预警工单；二是给受理 Agent 配上语音能力，让用户可以口述补充收入情况，再自动转成结构化字段；三是把反欺诈 Agent 从单一黑名单查询扩展成基于关系图谱的关联风险识别。这些都还在探索，等跑通一版再专门开一篇。
最后再说一个很小的技巧：AgentArts 平台里模型输出的 token 长度在金融场景里尽量设置得小一些，比如 512 或 1024。固定格式的审批意见根本不需要长文本输出。限制长度不仅省钱，还能有效减少模型在尾部生成无关解释的概率。我调小上限之后，单次调用耗时下降了大概 30%，输出稳定性反而更好。这个经验在其他 Agent 场景里同样适用。
