金融信贷这个行当，过去十年我见过太多团队在"智能化"三个字上栽跟头。不是技术不行，是方向错了——把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", timeout=5) 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应用的迭代。如果连基础的数据治理都没做好，上来就搞智能体，大概率会变成演示项目。
从投入产出比来看，我建议先从贷前调查环节切入。这个环节的规则相对明确，工具调用模式清晰，容易看到效果。跑通之后再往贷中审批和贷后监控扩展。一上来就做全链路，周期长、风险高、团队容易失去信心。
另外，智能体不能替代审批人员，至少在现阶段不能。它的定位是"辅助"，把审批人员从重复的信息收集和初步筛查中解放出来，让他们专注于复杂案例的判断。这个定位想清楚了，期望值就合理了，落地阻力也会小很多。
我在实际项目里最大的体会是：智能体的效果不取决于模型有多强，而取决于你对业务的理解有多深。提示词里的每一条约束、工具描述里的每一个参数、知识库分块的每一个策略，背后都是对信贷业务的理解。技术只是把这些理解固化下来的手段。那些指望靠一个通用大模型加几份文档就能搞定信贷审批的想法，基本都会在实测中碰壁。
