金融信贷这个行当过去十年我见过太多团队在智能化三个字上栽跟头。不是技术不行是方向错了——把AI当成一个更快的规则引擎结果发现它既不够快也不够准。华为云智果 AgentArts 这套东西真正有意思的地方在于它把智能体这个概念从演示视频里拽了出来摁进了信贷审批这种容错率极低的场景里。这篇内容适合三类人看正在选型信贷AI方案的技术负责人、想搞清楚智能体到底怎么落地的产品经理以及被各种AI信贷方案绕晕的业务口同事。我会把从环境搭建到策略调优的完整链路拆开讲包括那些文档里不会写的坑。1. 信贷场景为什么需要智能体而不是模型1.1 传统风控模型的天花板在哪里先把这个前提说清楚不然后面全是空中楼阁。传统信贷风控的核心是一套评分卡体系逻辑回归也好梯度提升树也好本质上是把借款人拆成几百个特征维度每个维度给一个权重加权求和出一个分数再对照阈值做通过/拒绝/人工复核的决策。这套东西跑了几十年稳定、可解释、监管友好但它的硬伤在于静态。一个评分卡模型上线之后它的权重就固定了。经济环境变了、客群结构变了、欺诈手法变了模型不会自己调整得靠人重新标注数据、重新训练、重新部署。这个周期在成熟团队里最快也要两到三周慢的按月算。而信贷欺诈的对抗节奏是以天甚至小时计的。更麻烦的是评分卡只能处理结构化特征对于借款人的经营流水描述、征信报告里的非标准备注、客服通话记录这些半结构化甚至非结构化的信息它基本无能为力。我见过一个真实案例某小微贷团队的风控模型对经营年限这个特征给了很高的权重结果一批实际经营了五六年但工商注册只有一年的个体户被大量误拒。原因很简单这些商户之前是无照经营后来才补办的执照。模型看不到实际经营历史这个维度因为征信和工商数据里都没有。这种信息只能从流水备注、进货单据、甚至和客户的沟通记录里推断。传统模型做不了这件事。1.2 智能体在信贷链路里的真实定位AgentArts 这类智能体平台解决的不是算得更准的问题而是看得更全、反应更快的问题。它的核心能力是多源信息融合和动态决策编排。具体到信贷场景一个智能体可以同时做几件事解析借款人的非结构化资料、调用外部数据接口做交叉验证、根据中间结果决定下一步查什么、最后给出一个带推理链的决策建议。这里的关键词是编排。传统模型是一个函数输入特征输出分数。智能体是一个流程控制器它知道在什么情况下该调用哪个工具、该问什么问题、该查什么数据。比如一个借款人的流水显示月均进账不错但征信查询次数在近三个月激增智能体会自动触发多头借贷风险核查子流程去查这个人在其他平台的申请记录而不是简单地给一个低分。华为云智果 AgentArts 在这个环节提供的价值是把工具调用、知识库检索、多轮推理这些能力封装成了可配置的组件。你不需要从零写一个 ReAct 框架也不需要自己维护向量数据库和检索链路。对于信贷团队来说这意味着可以把精力放在业务逻辑和策略调优上而不是基础设施上。1.3 一个具体的决策对比拿小微企业主经营贷审批这个场景来说传统模型和智能体的处理路径差异非常明显。维度传统评分卡模型AgentArts 智能体输入数据结构化特征表结构化非结构化混合决策逻辑加权求和阈值多步推理工具调用异常处理命中规则转人工自动触发核查子流程更新周期周级/月级策略级实时调整可解释性特征贡献度推理链证据引用覆盖场景标准信贷产品复杂经营场景这个对比不是要否定评分卡而是说两者是互补关系。实际落地中我通常建议把评分卡作为智能体的一个工具来调用而不是替代它。智能体负责编排和推理评分卡负责提供基准分数这样既保留了可解释性又增加了灵活性。2. 在 AgentArts 上搭建信贷智能体的完整链路2.1 环境准备与账号体系对接第一步是账号和权限。华为云智果 AgentArts 的控制台入口在华为云 AI 开发平台下面需要先开通 ModelArts 和 AgentArts 两个服务。这里有个容易忽略的点AgentArts 的智能体运行时需要独立的 IAM 委托不能直接用主账号的 AK/SK。我见过有团队图省事直接用主账号密钥结果在调用外部数据接口时权限过大审计过不了。正确的做法是创建一个专用的 IAM 用户只授予 AgentArts 运行时必需的最小权限集包括模型调用权限、对象存储读写权限用于存放知识库文件、以及你实际需要调用的外部 API 的访问权限。然后在 AgentArts 的委托管理里绑定这个 IAM 用户。# 创建 IAM 用户并授权示例实际以控制台操作为准 # 1. 在 IAM 控制台创建用户 credit-agent-runner # 2. 授予策略ModelArts User OBS OperateAccess 自定义API策略 # 3. 在 AgentArts 控制台绑定委托知识库的存储建议用 OBS 的独立桶不要和别的业务混用。信贷资料涉及敏感信息桶策略要设置为私有并且开启服务端加密。这些是合规底线不是可选项。2.2 知识库构建把信贷政策变成可检索的资产信贷智能体的知识库和通用问答机器人的知识库有本质区别。通用知识库追求召回率高信贷知识库追求召回准且可追溯。因为一旦智能体引用了一条过时的政策条款来支持审批决策后果是合规风险。我的做法是把知识库分成三层监管层银保监、央行发布的信贷相关管理办法、通知。这部分更新频率低但权威性最高检索权重设为最高。产品层自家银行的信贷产品说明书、准入条件、额度测算规则。这部分更新频率中等需要版本管理。案例层历史审批案例的脱敏摘要包括通过和拒绝的典型样本。这部分用于few-shot推理帮助智能体理解审批尺度。在 AgentArts 里上传文档时分块策略很关键。信贷政策文档往往有复杂的条款嵌套简单的固定长度分块会把一个完整条款切碎。我建议用按标题层级分块重叠窗口的方式每个块保留所属章节的标题路径作为元数据。这样检索时可以通过元数据过滤比如只检索小微企业相关的条款。# 知识库分块配置示例伪代码展示逻辑 chunk_config { strategy: hierarchical, max_chunk_size: 800, overlap: 150, metadata_fields: [chapter, section, effective_date, product_line], preserve_headers: True }注意知识库里的政策文档必须标注生效日期和失效日期。智能体在引用时应该优先使用当前生效的版本。我见过一个案例智能体引用了一份已经废止的利率上限规定导致审批建议出现偏差。2.3 工具编排让智能体学会查什么和怎么查AgentArts 的工具编排能力是这套方案的核心。在信贷场景里智能体需要调用的外部工具通常包括征信查询接口、工商信息接口、司法涉诉接口、反欺诈名单接口、以及内部的额度计算服务。配置工具时参数描述的质量直接决定调用准确率。很多人写工具描述就一句话查询征信报告这样智能体根本不知道什么时候该调、传什么参数。正确的做法是把工具描述写成一个小型的使用说明书{ name: query_credit_report, description: 查询借款人的央行征信报告。适用于需要了解借款人历史还款记录、负债情况、查询记录的场景。当借款人提供了身份证号且授权查询时调用。返回结构化征信数据。, parameters: { id_number: 借款人身份证号18位, query_reason: 查询原因可选值loan_approval, post_loan_check, risk_review } }这里有个经验工具描述里要写清楚什么时候不该调用。比如征信查询接口如果借款人还没签署授权书就不该调用。把这个约束写进描述里智能体能避免很多无效调用。工具之间的依赖关系也要在编排层处理好。比如额度计算工具依赖征信查询和收入核实的结果那么在流程设计上就要确保前置工具执行完成后再触发。AgentArts 支持在编排画布上设置条件分支和依赖关系建议把关键依赖显式画出来不要依赖智能体自己判断。2.4 提示词工程信贷场景的特殊写法信贷智能体的系统提示词和通用助手完全不同。通用助手追求友好、有帮助信贷智能体追求严谨、可追溯、不越权。我的提示词模板通常包含这几个模块角色定义明确智能体是信贷审批辅助助手不是决策者。最终决策必须由人做出智能体只提供建议和证据。行为约束列出绝对不能做的事。比如不得在未经授权的情况下查询征信、不得引用已失效的政策条款、不得对借款人做出承诺性表述。推理格式要求智能体按固定格式输出推理过程。我通常要求它输出观察-分析-结论三段式每个结论都要标注证据来源。不确定性处理明确告诉智能体当信息不足时应该输出信息不足建议补充XX材料而不是强行给一个结论。你是一个信贷审批辅助智能体。你的职责是收集信息、分析风险、提供审批建议。 你必须遵守以下规则 1. 所有结论必须有证据支撑证据来源需标注征信报告/工商数据/知识库条款编号 2. 当关键信息缺失时明确列出需要补充的材料不得猜测 3. 不得引用生效日期晚于当前日期的政策条款 4. 你的输出是建议最终决策由审批人员做出这套提示词看起来啰嗦但实测下来能显著降低幻觉率。特别是在引用政策条款时智能体会更倾向于说根据知识库中的XX条款而不是编造一个条款号。3. 实测中暴露的问题与调优过程3.1 工具调用过于频繁一个反直觉的发现智能体上线第一周我们发现一个奇怪的现象平均每个审批案例触发了 7.3 次工具调用而人工审批平均只需要查 3 到 4 个数据源。多出来的调用主要是重复查询和无效查询。排查下来根因在提示词里。我最初写的提示词强调尽可能收集全面信息结果智能体把这句话理解成了能查的都查一遍。它会在已经拿到征信报告的情况下再去查一次工商信息然后发现没有新增风险点又去查司法涉诉。修复方案是在提示词里加入成本意识和边际收益判断在决定调用工具前先判断当前已有信息是否足以支撑决策 如果已有信息能得出明确结论通过/拒绝/需补充材料则不再调用额外工具。 只有当存在关键信息缺口且该缺口会影响决策时才调用工具补充。调整之后平均工具调用次数降到 4.1 次审批时效提升了约 35%。这个经验说明智能体的勤奋需要被约束否则它会用穷举的方式替代推理。3.2 知识库检索的近义陷阱信贷政策里有大量近义但含义不同的术语。比如授信额度和贷款额度、保证人和担保人、逾期和欠息。智能体在检索时经常把包含近义词的条款召回导致引用错误。我们试过几种方案。第一种是加同义词词典效果一般因为信贷术语的差异往往是法律意义上的不是语言意义上的。第二种是在检索后加一个条款相关性校验步骤让智能体自己判断召回的条款是否真的适用于当前场景。这个方案效果好但增加了延迟。最终采用的方案是混合检索元数据过滤。在向量检索的基础上增加关键词精确匹配的权重同时利用知识库分块时保留的元数据产品线、适用客群、条款类型做前置过滤。比如当前审批的是小微企业抵押贷就只在小微企业和抵押相关的分块里检索。方案准确率延迟实施成本纯向量检索72%低低加同义词词典76%低中检索后校验89%高中混合检索元数据过滤86%中中高最终选了第四种方案准确率略低于第三种但延迟可控且不依赖额外的模型调用。3.3 多轮对话中的上下文漂移信贷审批往往需要和客户经理多轮交互补充材料、确认信息。在这个过程中智能体容易出现上下文漂移——聊到后面忘了前面的约束条件。比如一开始客户经理说这个客户是首贷户聊了五轮之后智能体在给建议时按有贷款记录的客群来分析了。这种错误在长对话里很常见。解决办法是在 AgentArts 的会话管理里开启关键信息锚定。具体做法是在对话过程中把已经确认的关键事实客群类型、贷款用途、抵押物情况等提取出来存到一个结构化的会话状态对象里每一轮推理时都把这个状态注入到上下文中。# 会话状态锚定示例 session_state { customer_type: first_loan, loan_purpose: equipment_purchase, collateral: residential_property, confirmed_facts: [首贷户, 设备采购用途, 住宅抵押] } # 每轮对话时将 session_state 注入 system prompt这个机制加上之后长对话的上下文一致性明显改善。实测 10 轮以上的对话关键信息丢失率从 18% 降到了 4% 左右。3.4 审批建议的可解释性打磨监管对信贷审批的可解释性要求很高。智能体给出的建议不能是黑箱必须能说清楚为什么。AgentArts 本身支持输出推理链但默认的推理链格式对业务人员不够友好。我们做了一层后处理把推理链转换成审批人员习惯看的格式风险点列表证据建议动作。【风险点1】征信查询次数异常 证据近3个月机构查询8次其中贷款审批类6次 分析查询频率显著高于同类客群均值2.1次 建议要求补充说明查询原因或降低授信额度 【风险点2】经营流水与申报收入差异 证据申报月收入5万流水显示月均进账3.2万 分析差异率36%超过30%的预警线 建议要求提供其他收入证明或调整授信额度这种格式让审批人员能快速抓住重点而不是去读一大段自然语言推理。后处理逻辑不复杂但显著提升了业务侧的接受度。4. 从单点智能体到信贷智能体矩阵的演进思路4.1 为什么单智能体不够用一个智能体包揽所有信贷环节短期能跑通长期一定会遇到瓶颈。原因有三个提示词膨胀、工具冲突、迭代耦合。提示词膨胀很好理解当你要在一个智能体里同时处理贷前调查、贷中审批、贷后监控三个环节的逻辑时提示词会变得极其冗长而且不同环节的约束条件可能互相干扰。工具冲突是指贷前需要调用营销类接口贷后需要调用催收类接口这些工具放在一个智能体里调用准确率会下降。迭代耦合是指你改贷后监控的逻辑可能会影响贷前审批的表现测试成本很高。4.2 按信贷生命周期拆分智能体我的建议是按信贷生命周期拆成三个智能体各司其职贷前调查智能体负责资料收集、信息核验、初步风险筛查。它的工具集主要是查询类接口输出是结构化的客户画像和风险提示。贷中审批智能体负责额度测算、利率定价、审批建议。它的工具集包括评分卡调用、额度计算、政策检索。输出是审批建议书。贷后监控智能体负责还款行为监控、风险预警、催收策略建议。它的工具集包括流水监控、舆情监测、催收记录查询。三个智能体之间通过结构化的数据对象传递信息而不是通过自然语言。这样每个智能体的提示词可以保持精简工具集也可以独立优化。4.3 智能体之间的协作机制拆分之后协作机制的设计是关键。AgentArts 支持智能体之间的调用但直接调用容易形成链式依赖一个环节出问题全链路挂掉。更稳妥的做法是事件驱动状态机。每个智能体完成自己的任务后把结果写入一个共享的状态存储比如 OBS 上的 JSON 文件或者数据库记录然后发布一个事件。下一个环节的智能体监听事件触发自己的处理流程。# 事件驱动的智能体协作示例 def on_pre_loan_complete(case_id, result): # 贷前调查完成触发贷中审批 state load_state(case_id) state[pre_loan_result] result state[stage] credit_approval save_state(case_id, state) publish_event(credit_approval_ready, {case_id: case_id})这种架构的好处是每个智能体可以独立部署、独立扩缩容一个环节的故障不会阻塞其他环节。而且状态是持久化的出了问题可以回溯。4.4 效果监控与持续迭代智能体上线不是终点是起点。信贷场景的监控指标和通用AI应用不同我通常关注这几类决策质量指标审批建议采纳率、人工推翻率、坏账率变化。这些是最终的业务指标但反馈周期长。过程质量指标工具调用准确率、知识库引用准确率、推理链完整率。这些指标反馈快能提前发现退化。效率指标平均审批时长、单案例工具调用次数、人工复核触发率。我建议在 AgentArts 之外搭一个简单的监控看板每天跑一批测试案例对比智能体输出和人工审批结果。发现偏差及时调整提示词或知识库。这个迭代节奏比传统模型快得多但需要专人负责不能指望它自己变好。5. 几个容易踩的坑和对应的处理经验5.1 知识库更新后的缓存问题AgentArts 的知识库检索有缓存机制更新文档后不会立即生效。我们有一次更新了利率政策但智能体还在引用旧版本导致审批建议里的利率算错了。排查了半天才发现是缓存没刷新。处理办法知识库更新后在控制台手动触发一次索引重建并且在提示词里加入当前知识库版本号的校验。如果智能体引用的条款版本和当前版本不一致输出一个警告。5.2 工具接口的超时与降级外部数据接口不稳定是常态。征信查询接口偶尔会超时如果智能体没有超时处理逻辑整个审批流程会卡住。我的做法是在工具编排层设置超时和降级策略。比如征信查询超时 5 秒后自动降级为使用最近一次查询结果如有或者标记为待补充材料继续其他流程。不要让一个接口的超时阻塞整个审批。# 工具调用超时降级示例 try: result call_tool(query_credit_report, timeout5) except TimeoutError: result get_cached_result(case_id, credit_report) if result is None: result {status: pending, message: 征信查询超时需人工补充}5.3 敏感信息的脱敏处理信贷场景涉及大量个人敏感信息。智能体在处理这些信息时必须做脱敏。AgentArts 本身不提供自动脱敏需要自己在工具层处理。我的建议是在数据进入智能体之前就脱敏而不是在输出时脱敏。比如身份证号只保留前6位和后4位手机号中间4位用星号替代。这样即使智能体的日志被泄露也不会造成实质性的信息泄露。注意脱敏后的数据仍然要保证智能体能正常推理。比如身份证号脱敏后智能体无法判断性别和出生日期这些信息需要在脱敏时单独提取出来作为结构化字段传入。5.4 多智能体协作时的状态一致性前面提到用事件驱动做协作但事件驱动有个经典问题事件丢失或重复消费。如果贷前调查完成的事件丢了贷中审批就永远不会触发。处理办法是加一个定时对账任务定期扫描处于中间状态的案例检查是否有超时未推进的。如果有重新发布事件或标记为异常。这个对账任务不复杂但能避免很多卡单问题。6. 关于成本与性能的实测数据6.1 单案例的Token消耗信贷智能体的Token消耗比通用问答高不少因为推理链长、工具调用多。实测一个完整的小微贷审批案例平均消耗约 12000 到 18000 个Token含输入输出。其中系统提示词占约 2000 Token知识库检索结果占约 4000 Token工具调用结果占约 5000 Token推理输出占约 3000 Token。优化空间主要在知识库检索结果上。通过元数据过滤减少召回数量可以把这部分降到 2500 Token 左右。另外工具返回结果可以做摘要压缩只保留关键字段不要整个JSON塞进去。6.2 响应延迟的构成端到端的审批建议生成延迟平均在 8 到 12 秒。拆解下来知识库检索约 1.5 秒工具调用约 3 到 5 秒取决于外部接口模型推理约 3 到 4 秒后处理约 0.5 秒。工具调用是最大的延迟来源。优化方向有两个一是并行调用无依赖的工具比如工商信息和司法涉诉可以同时查二是对高频查询做结果缓存比如同一借款人在短时间内重复查询征信可以直接用缓存。6.3 并发处理能力AgentArts 的智能体运行时支持弹性扩缩容但实际并发能力受限于外部接口的QPS限制。我们实测下来在外部接口QPS充足的情况下单实例可以处理约 5 到 8 个并发审批请求。超过这个量级需要增加实例数。建议在编排层加一个简单的限流器避免突发流量把外部接口打挂。限流阈值根据外部接口的实际承载能力设置不要拍脑袋。7. 这套方案适合什么样的团队AgentArts 这套信贷智能体方案不是万能的。它适合的团队有几个特征已经有基本的信贷业务系统数据接口相对完善有专门的人负责AI应用的迭代。如果连基础的数据治理都没做好上来就搞智能体大概率会变成演示项目。从投入产出比来看我建议先从贷前调查环节切入。这个环节的规则相对明确工具调用模式清晰容易看到效果。跑通之后再往贷中审批和贷后监控扩展。一上来就做全链路周期长、风险高、团队容易失去信心。另外智能体不能替代审批人员至少在现阶段不能。它的定位是辅助把审批人员从重复的信息收集和初步筛查中解放出来让他们专注于复杂案例的判断。这个定位想清楚了期望值就合理了落地阻力也会小很多。我在实际项目里最大的体会是智能体的效果不取决于模型有多强而取决于你对业务的理解有多深。提示词里的每一条约束、工具描述里的每一个参数、知识库分块的每一个策略背后都是对信贷业务的理解。技术只是把这些理解固化下来的手段。那些指望靠一个通用大模型加几份文档就能搞定信贷审批的想法基本都会在实测中碰壁。