信贷初审AI智能体实战：AgentArts选型与工作流编排全解析

去年年中，我们团队接到一个信贷业务系统的改造需求：贷前初审每天几百笔进件，客户经理要反复核对身份证明、收入流水、征信报告，再套评分卡模板写初审意见，加班成了常态。一开始我们打算让算法同事从零用 Python 写一套 Agent，但评估完开发周期和合规成本后，决定改用华为云智果 AgentArts 来搭金融信贷 AI 智能体。整套东西从原型到上线花了不到一个季度，上线后初审时效从平均 40 分钟压到了 8 分钟以内，自动过滤了约六成明显不达标的进件，人工复核量不升反降。当然，这中间踩过的坑比预想的多。这篇文章就围绕这次实战，讲讲为什么选 AgentArts、信贷流程里哪些环节能上智能体、具体怎么搭、跑起来后遇到哪些翻车现场，以及信贷场景绕不开的安全和审计红线。如果你也在评估用类似平台做业务智能体，这篇应该对你有用。

1. 信贷场景里为什么用AgentArts：平台选型背后的真实理由

1.1 先搞清楚AgentArts到底解决的是什么问题

AgentArts 这类平台，说白了是把“大模型 + 规则 + 业务流程 + 外部工具”装进一个可编排的容器里。金融信贷项目不是要做一个会聊天的机器人，而是要把“读材料、查数据、判断风险、输出结论”这一整套动作串成可追溯、可回滚的流程。传统做法是让算法工程师把每个环节写死在代码里，模型升级要发版，规则调整要改代码，一两个环节变了整个流程都要回归测试。AgentArts 的价值在于把工作流可视化、模型路由、工具调用、知识库这些能力打包，同时天然带了运行日志、版本管理、权限控制这类生产环境才需要的东西。

我们在选型时其实比较过三套方案：一是纯 Python 自研 Agent 框架，二是通用低代码智能体平台，三是华为云智果 AgentArts。信贷场景有个很特殊的地方，就是每一步操作都要有依据，出问题后要能回溯到“当时模型为什么这么判断”。自研方案在能力和灵活性上最强，但团队当时没有人专职维护 Agent 基础设施，光是链路追踪、工具调用失败重试、模型版本灰度这几件事就能吃掉一半人力。通用低代码平台对聊天类场景很友好，但涉及大量结构化数据、复杂分支、人工审批节点时，明显感觉设计逻辑是“对话优先”，不太适合我们这种“流程优先”的业务。

最终选中 AgentArts，还有一个很实际的考量：我们一部分存量数据本来就在华为云上，OCR、数据库、对象存储这些组件可以直接复用，不用再造一套连接器。智能体运行时的模型调用、工具凭证、日志存储也都在同一个安全边界内，省掉了很多跨云访问的安全审查流程。

1.2 平台搭建的智能体，和用Python手写Agent到底差在哪

很多做算法的人会质疑：低代码、可视化编排出来的东西，是不是只是把 Python 里的if-else换成了界面里的连线？我这次的体会是，两者本质差别不在“能不能写复杂逻辑”，而在“生产环境需要的配套能力”是否齐备。

用 Python 手写一个 Agent，核心代码可能只有几百行，但上线要面对的是：模型调用失败怎么退避重试、工具调用参数怎么校验、每个节点的输入输出怎么落库、不同版本的 Prompt 怎么灰度、出了责任事故怎么定位是哪一轮模型输出导致。这些在 AgentArts 里是平台内置能力，而在自研方案里每一项都要自己造轮子。当然，这不意味着 Python 方案没有价值。如果业务非常特殊，需要深度定制模型推理逻辑、需要精细控制每一步的 token 开销，自研依然是更好的选择。我们的经验是：信贷初审这类规则相对成熟、流程相对固定的场景，平台搭建的性价比远高于 Python 自研。

和通用低代码平台比，AgentArts 更贴近“企业级智能体运行时”这个概念。它支持把工具调用分为只读和写两类，支持在流程中插入人工审批节点，支持对身份证号、手机号这类敏感字段做脱敏后传入模型。这些能力对信贷场景不是加分项，而是准入门槛。

1.3 我最终锁定它的三个理由

第一个理由是“混合决策”模式。信贷初审不是所有判断都该交给大模型，硬性规则比如黑名单命中、身份证格式错误，用正则或简单的规则节点就能秒级判断。AgentArts 的工作流支持在设计时就让规则节点和大模型节点并存，先跑规则，规则判断不了再让模型上。这种混合架构在信贷场景里既省钱又安全。

第二个理由是“人工兜底”节点。信贷业务不可能全自动，总有模型拿不准、客户情况特殊的时候。平台提供了人工审核节点，流程跑到这里会生成一个任务推送给审核员，审核员在界面上能看到模型判断的依据，可以做“通过/驳回/修改后继续”的操作。这个节点以前我们要自己开发一套工单系统，现在直接编排进智能体流程里就行。

第三个理由是“可观测性”。上线后每笔进件都会留下完整链路：模型用的什么版本、读到了哪些字段、调用了哪个工具、输出了什么内容、最终走了哪个分支。信贷监管审计时，这套日志就是最核心的解释材料。如果自己用 Python 搭，这套链路追踪系统至少要多开发两周。

2. 拆解信贷全流程：哪些环节值得塞智能体，哪些坚决不能碰

2.1 可以先动起来的三个高价值环节

信贷业务链条很长，不是所有环节都适合做智能体。我们做了三周的业务访谈后，圈定了三个“高价值 + 高可行”的场景。

第一个是贷前资料预审。客户提交的身份证、银行卡、收入证明、工作证明大多是图片或 PDF，传统做法是人工逐张看，再把关键信息录入系统。这个环节本质是“信息抽取 + 规则校验”，非常适合 OCR 识别加规则引擎，再让大模型对非结构化文本做补充理解。比如个人收入证明里写了“年终奖按绩效浮动计算”，这种口语化表述规则引擎很难处理，大模型可以读懂并标出“收入构成中包含不确定性因素”。

第二个是反欺诈初筛。进件后需要查黑名单、查多头借贷、查司法涉诉记录。规则命中只是第一步，大量的欺诈特征藏在材料细节里：地址频繁变更、联系人电话与工作单位电话相同、收入证明开具时间异常接近申请日期。这类交叉比对靠人查很慢，靠规则硬写容易漏。智能体可以把多路查询结果汇总，由模型给出一个可疑程度评级。

第三个是贷后预警监测。放款后要持续关注客户还款行为、征信查询频率、涉诉信息变化。这部分事件驱动、文本信息多、重复性强，完全可以自动化成“预警工单生成器”，把原始风险信号整理成结构化的工单内容，再按等级推送给贷后管理人员。

2.2 必须留给人的决策红线

我们在项目第一天就约定了一条铁律：智能体只能做“建议”，不能做“决定”。最终授信额度、利率定价、拒绝客户的最终决定，坚决不放进智能体自动执行链路。这些决策涉及资金损失和法律风险，一旦模型判断出错，责任无法解释。

此外还有两类场景也没有自动化：涉及客户投诉和争议申诉的进件，必须跳过智能体直接进人工；政策豁免类特殊审批，比如绿色通道、白名单客户，需要客户经理在人工界面手动标记原因。为什么这些不能碰？因为它们的共同特点是“个案性强、自由裁量权大、需要溯因解释”。智能体擅长处理有规律、有边界的问题，而不是处理规则外、博弈性的问题。

2.3 怎么切出最小可行性闭环

很多团队一上来就想做一个“全流程智能体”，把贷前、贷中、贷后全包了，结果项目拖了半年上不了线。我们当时反着来，先用一套历史上沉淀的 2000 笔已结案进件做筛选，找到“单笔处理耗时最长、人工最容易产生疏漏”的贷前初审环节，作为 MVP。

切分标准有四条：业务发生频率高，每天至少上百笔；现有规则基础好，有清晰的评分卡和审批指引；数据可结构化，绝大部分材料能被 OCR 和数据库读取；错误影响可控，初审环节之后还有人工复审兜底。最终，我们把 MVP 边界定义为“输出三档建议”：建议通过预审、建议转人工、建议拒绝。所有建议都不直接生效，必须有复核人在系统中确认后才进入下一流程。这样既验证了技术可行性，又不触碰业务红线。

3. 从零搭一个贷前初审智能体：AgentArts里的完整拆解

3.1 数据源接入与字段治理

在开始画工作流之前，我们先把数据源理清楚。智能体不是凭空干活，它需要接入四类数据：进件系统里的申请信息、OCR服务识别出的材料文本、征信报告解析服务输出的结构化数据、黑名单和多头借贷查询API。

这一步最容易被低估的是字段治理。同一个“手机号”，进件系统里叫mobile，OCR识别结果里叫phone，征信报告里叫telephone_no，如果不统一映射，后面模型提示词里就得写一堆“字段别称”，既容易出错又浪费上下文窗口。我们在 AgentArts 里先建了一个字段映射表，把业务字段统一定义为customer_mobile、id_card_no、monthly_income这样的标准命名，再将每个数据源做适配。实测下来，这个前期工作至少减少了后期 30% 的调试时间。

还要注意数据格式。例如金额字段，进件系统里单位是元，征信报告里单位是万元，模型一旦把单位搞混，收入负债比的结论就全错了。我们在数据接入节点就统一转换成“元”并保留两位小数，绝不让模型自己去猜单位。身份证号、银行卡号这类字段，进件后先做校验，长度不对直接进入工单，不让大模型参与判断。

3.2 工作流编排：规则节点、大模型节点、工具节点怎么串

AgentArts 的工作流支持串行、并行、分支判断，我们最终跑通的主流程是这样的：

1. 触发节点：新进件创建后，启动智能体流程。
2. 数据汇聚节点：从进件系统、OCR服务、征信解析服务同步拉取数据。
3. 规则校验节点：先跑硬性规则，比如证件号码格式、黑名单命中、重复申请检测。
4. 分支判断：如果硬性规则命中致命项，直接输出“建议拒绝”，不进大模型；否则进入下一步。
5. 模型分析节点：将结构化数据和 OCR 文本按提示词模板组合，生成风险摘要和授信建议。
6. 置信度判断节点：模型输出的结果里必须携带置信度字段，低置信度自动转人工。
7. 人工审批节点：复核人对模型建议做确认或修改，流程结束并回写结论。

这个顺序不是随便排的。把规则节点放在大模型之前，是因为很多硬性风险根本不需要模型参与判断，用规则解决更稳定、更快、更便宜。比如黑名单命中，一条精确匹配就能决定结果，让大模型分析反而可能被上下文里其他信息干扰，产生“虽然命中黑名单但客户解释合理”这类不该有的联想。

后端的容错也要考虑。征信查询接口偶尔超时，工具节点上设置了 5 秒超时和两次重试；重试仍失败时，流程走“数据待补”分支，标记人工处理。下面这段是工作流里工具调用节点的核心配置片段，供参考：

tool_call: tool_name: credit_report_query timeout_ms: 5000 retry_times: 2 on_failure: action: route_to_manual reason: credit_report_unavailable notify_group: credit_initial_review_team

3.3 提示词和知识库配置：信贷场景的提示词不是聊天提示词

信贷场景的提示词和通用客服机器人完全不一样。客服提示词追求对话自然、语气友好，信贷初审提示词追求的是“结构化输出 + 严格边界”。我们在模型分析节点用了一套固定模板，核心内容包括五个部分：角色定义、任务清单、输入数据说明、输出格式约束、禁止越权行为。

角色定义非常重要。我们不是让模型扮演“信贷审批官”，而是让模型扮演“初审资料分析员”，注意措辞上强调“分析”而不是“决定”。因为一旦让模型觉得自己是审批官，它就会倾向于输出“批准”或“拒绝”这类决策性结论。改成“分析员”后，模型更愿意输出事实和风险点，最终决策留给人工。

输出格式我们都用 JSON Schema 约束，模型必须返回结构化结果，拿不到关键字段就返回 UNKNOWN，而不是自己编。下面是一段实际使用的输出结构模板：

{ "risk_summary": "简要描述发现的实质性风险，不超过150字", "income_stability": "STABLE | UNSTABLE | UNKNOWN", "debt_burden_ratio": "数值，缺失则为 UNKNOWN", "suspected_fraud_signals": ["信号1", "信号2"], "initial_review_suggestion": "PASS | MANUAL | REJECT", "confidence": 0.0, "disclaimers": ["本次分析仅供复核参考"] }

知识库方面，我们把行内的贷款产品政策、初审操作手册和常见问题处理指引做成了检索知识库。这里要特别提醒：知识库只用于帮助模型理解业务上下文和产品口径，不能让它自己“解释”监管法规或行内红头文件。我们在提示词里明确写了一句“如知识库内容与内部制度原文冲突，以人工复核为准，模型不得自行裁决”。

3.4 人工兜底与审核闭环

即使前面做了这么多规则和约束，模型一定还会有判断不准的时候。我们的策略是“默认不信任，按置信度分流”：置信度高于 0.85 且没有命中任何高风险信号，才允许输出自动建议；其余全部转人工。

人工复核界面不是简单的“看一遍”，而是把智能体每一步的依据都展示出来：命中了哪条规则、模型读了哪些字段、风险摘要引用的是哪段原文、置信度是多少。复核人可以在界面上对比原始材料和模型结论，然后选择“确认”“修改”或“驳回”。所有人工操作同样记录到操作日志里，形成“机器先初审、人工终审”的闭环。

这里有一个经验：模型输出的“风险摘要”如果太简短，人工复核者不会信任；如果太长，复核者又看不完。我们最终把摘要控制在 150 字以内，按“关键风险 + 数据缺口 + 建议动作”三段式排列，人工复核平均时长从 6 分钟降到了 2 分钟。

4. 跑通之后才遇到的坑：实测翻车现场与修复

4.1 长文本截断导致征信报告解读失真

第一个坑出现在征信解读环节。征信报告经常是几千字的长文本，超过模型上下文窗口后，我们的第一版做法是简单截取前 2000 字。结果上线第一周就发现，不少客户偏偏在报告后段有逾期记录，被截断后模型完全没看到，风险摘要里写“未发现明显逾期记录”。我们抽查了 100 笔转人工的进件，发现 35 笔存在类似漏读情况。

修复不是简单拉长截断长度，而是改成“分块摘要再汇总”：先把征信报告按“贷款记录”“逾期记录”“查询记录”三个板块切分，每块单独送入模型提取结构化字段，最后再把三块结果汇总给主模型做整体判断。这样既绕开了上下文窗口限制，又能保证每段风险都被覆盖。这个改动上线后，逾期记录召回率从 76% 直接升到 91.3%。

4.2 大模型对“模糊收入”的过度推断

另一个翻车现场是收入判断。有些客户的收入证明只写了“月收入约 8000 元”，或者只有基本工资流水没有奖金流水。模型在作答时经常会给出一个精确数字，比如“预计月收入 12000 元”，并直接参与负债比计算。这看起来是能力很强，实际是过度推断，因为 12000 这个数字可能是模型从行业平均猜出来的，完全没有数据支撑。

我们的修复方案是给输出结构加了三个字段：数据质量标记、证据引用、推断置信度。凡是没有直接证据支撑的收入，必须返回 UNKNOWN，不参与后续计算。如果月收入字段为 UNKNOWN，流程直接转人工，不让模型硬算。这个改动把“模型虚构数据”类问题从每周十几例降到了接近于零。

4.3 工具调用失败和超时的容错设计

最开始我们天真地以为外部接口都是可靠的，结果上线第二天就遇到征信 API 超时，整个智能体流程挂起，没有走到人工分支，工单无声无息地消失了。这比模型答错更危险，因为答错至少还留了记录，流程挂起连记录都没有。

后来我们对所有工具调用节点统一做了三层容错：网络层超时设置、业务层重试次数、失败后路由策略。征信查询这种关键接口超时后，不再让流程继续往下走，而是生成一个“数据待补”的人工工单，并通知初审团队。一个 Agent 如果工具调用失败没有任何降级方案，就不能说具备上生产环境的资格。

4.4 测试评估：不能只测“答得对不对”，要测“业务指标”

智能体的测试和传统单元测试完全是两回事。你不能只问“模型回答是否合理”，还要关心“这个回答在业务流程里会产生什么后果”。我们建了一套面向业务的评测集：选了 2000 笔已结案进件，每笔都有真实初审结果和最终审批结果。智能体的每个版本上线前，都要在这个评测集上跑一遍，对比四个核心指标。

这套评测机制帮我们发现了隐藏最深的坑：模型版本迭代后，总体准确率没变，但对“征信报告里有多次贷款审批查询记录但无逾期”这种特殊类型的判断变激进了，误拦率从 6% 升到 14%。如果只盯着平均准确率，这个回退根本发现不了。所以做智能体测试的时候，一定要拆细维度，尤其要监控边界类型和异常类型的指标变化。

5. 信贷智能体上线的红线：数据安全、审计与OWASP智能体风险

5.1 敏感信息脱敏与数据不出域

信贷数据是所有行业里最敏感的那一档，身份证号、手机号、银行卡号、收入负债信息，哪个泄露都是事故。我们的处理原则是“最小必要 + 数据不出域”。Agent 运行时部署在企业内部环境，模型调用也走内部网关，原始数据不传到公网。

同时，在把数据组装进提示词之前，先做脱敏处理。姓名保留姓氏、手机号只保留前三位和后四位、身份证号只在规则校验节点使用，不进入大模型上下文。我们最初也担心脱敏之后模型会丢失判断信息，实测影响不大，因为征信解读真正依赖的是逾期次数、负债金额分布、查询机构数量这类结构化特征，而不是能直接定位到人的原始字段。

5.2 操作审计和权限模型

智能体上线后，每一次执行都会留下完整操作日志，包括触发人、触发时间、使用的模型版本、读取的字段清单、调用的工具、返回的结果、最终走的分支。这套日志不是给技术人员自己看的，而是给审计人员准备的。在信贷场景里，宁可多记也不能漏记，因为一旦出现责任认定，没有日志就等于没有证据。

权限模型我们做了严格分级。智能体运行时使用的服务账号只有“只读”权限，只能查询数据，不能执行任何写操作。放款、调额、修改利率这类接口，只允许人工系统通过专属通道调用，智能体在工作流里根本无法引用这些工具。从技术上杜绝了“模型越权操作”的可能性。

5.3 从ASI Top 10看信贷智能体必须防什么

OWASP 已经在关注 AI Agent 特有的安全风险，也就是 Agent Security Risks 那类清单（ASI01-ASI10）。虽然这更多是生态早期的风险评估框架，但回头看我们的实践，很多条都能对上。

比如“未授权的代理行为”：我们通过权限模型确保 Agent 只能调用白名单内的只读工具，不能执行放款、修改、删除等敏感写操作。比如“过度授权”：Agent 的数据库账号只开放审核所需表，不能访问全量客户库。再比如“上下文泄露与数据污染”：提示词里明确禁止模型输出未脱敏信息，同时对历史知识库内容做了版本控制和定期审核，防止的错误政策文档被检索出来当作依据。

还有一条很容易被忽略，是“不完善的日志与可观测性”。如果智能体运行日志不完整，出了问题根本没办法定位是模型问题还是规则问题，更没办法满足监管审计。我们现在的日志保存周期是三年，任何一笔进件的智能体处理过程都能完整回溯。

6. 实测数据复盘与后续迭代思路

6.1 真实数据：看起来不错，但别只看指标

这个智能体上线三个月，累计处理了 1.2 万笔进件。从结果看，“建议通过预审”的占比是 33%，“建议转人工”的占比 41%，“建议拒绝”的占比 26%。初审人工处理时效从平均 40 分钟降到了 8 分钟，但这不是最让我惊喜的。真正有价值的是自动摘牌的那些“明显不合格”进件，它们不再需要客户经理逐字读材料才能发现。

当然，数据漂亮不代表没有隐患。我们发现模型对“收入不稳定但负债率低”的客户明显更宽容，这类客户被建议通过预审的比例偏高。这说明模型在学习历史数据时，可能把“低负债率”当成了过强的正向信号。人工复核的数据正在慢慢积累，后续需要用这些纠偏样本做针对性调整。

还有一个现实问题：智能体自动建议拒绝的进件里，仍有 18% 在人工复核后被放行了。这部分不算系统故障，但说明模型目前的“拒绝阈值”设置偏激进。我们已经把这个指标列为重点监控对象，后续会尝试降低模型建议拒绝的置信度门槛，让更多“灰色地带”进件进入人工复核，而不是被机器一刀切掉。

6.2 我后续会怎么迭代

接下来我们有三条迭代路线。第一条是横向复制，把贷前初审这套工作流模板复制到贷后预警场景，替换数据源和提示词后生成“贷后风险预警智能体”。第二条是纵向加深，在初审流程里接入更多维度的数据源，比如公积金缴存记录、纳税记录、企业经营流水，减少对单一收入证明的依赖。第三条是做评测集闭环，每月从实际业务里补充新的进件案例，尤其是人工复核结果与模型建议不一致的那部分，让评测集持续反映真实业务分布。

另外我还在尝试把 AgentArts 的调试能力用得更彻底。每次模型输出和人工复核结果不一致时，我们都会把日志拉出来对比，看是提示词没有约束到某类边界情况，还是知识库缺少相关业务规则。这类复盘的价值比调参数大得多，因为它促使我们不断把业务知识和经验沉淀到流程里，而不是依赖模型“碰运气”。

最后说点个人体会。AgentArts 这类平台确实把智能体从实验品变成了可上线的生产工具，但真正的难点从来不在搭流程，而在于怎么定义问题边界、怎么处理长尾数据、怎么守住合规底线。如果你也准备在信贷场景做智能体，我建议不要一上来就追求端到端全自动，先把“建议引擎 + 人工复核”这套闭环跑通，再逐步扩大自动化范围。这样哪怕模型偶尔犯傻，业务也不会崩。