华为云AgentArts金融信贷智能体实战：从架构设计到合规留痕

1. 金融信贷场景下智能体落地的整体设计思路

1.1 为什么金融信贷是智能体最值得啃的硬骨头

金融信贷这个领域，表面上看流程高度标准化，进件、初审、面签、审批、放款、贷后，每个环节都有厚厚的制度文件兜底。但真正在一线做过信贷系统的人都知道，标准化只是外壳，里面全是非标准化的判断。一个客户经理拿到一笔小微企业贷款申请，他要看的材料可能包括营业执照、近半年流水、纳税记录、征信报告、上下游合同、抵押物评估报告，甚至还要打电话核实经营场地。这些动作里，有大量环节是"查规则、对条款、填表单、写意见"，恰恰是智能体最擅长接管的部分。

我之所以盯上华为云智果 AgentArts 这个平台来做金融信贷方向的智能体，核心原因是它在工作流编排、工具调用、知识库挂载这三件事上的完成度比较高。信贷场景不像通用问答，它要求智能体必须能"查得到制度、算得清指标、留得下痕迹"。AgentArts 提供的可视化编排能力，让一个懂信贷业务但不懂代码的人，也能把审批逻辑拆成节点串起来，这一点在实际项目里非常关键。

这个实战适合三类人参考：一是金融科技团队里负责信贷系统智能化改造的工程师，二是银行或消金公司里想用智能体提效的业务产品经理，三是正在研究 AI 智能体在垂直行业落地路径的技术爱好者。不管你之前有没有搭过智能体，只要跟着把信贷这个场景走通一遍，后面换到保险、理财、风控任何一个方向，底层方法论都是通的。

1.2 整体架构：把信贷审批拆成"感知—决策—执行"三层

我在设计这套信贷智能体的时候，没有一上来就堆功能，而是先把信贷审批的完整链路画出来，然后按"感知层、决策层、执行层"三层来切分。

感知层负责"看懂材料"。信贷进件材料格式极其混乱，有 PDF 扫描件、有 Excel 流水、有拍照上传的合同。这一层要解决的是把非结构化数据转成结构化字段，比如从银行流水中提取月均进账、从征信报告中提取逾期次数、从营业执照中提取成立年限。AgentArts 里可以通过挂载 OCR 工具和文档解析工具来实现，每个工具就是一个可调用的节点。

决策层负责"按规则判断"。这是信贷智能体的核心，也是最容易出问题的地方。信贷规则往往不是一条 if-else 能写完的，它涉及多条件组合、阈值判断、优先级覆盖。我的做法是把决策层再拆成"硬规则校验"和"软评分辅助"两条线。硬规则是那些一票否决的红线，比如当前逾期、涉诉、年龄超限；软评分则是根据流水、纳税、征信查询次数等维度加权打分，给出建议额度区间。

执行层负责"输出结果并留痕"。信贷是强监管行业，每一个审批动作都要可追溯。所以执行层不只是生成一段审批意见，还要把命中的规则、调用的工具、参考的知识库片段全部记录下来，形成一份结构化的审批日志。AgentArts 的工作流天然支持节点级日志，这一点在合规审计时能省掉大量扯皮。

提示：三层架构不是必须严格物理隔离，在 AgentArts 里可以放在同一个工作流中，用节点分组来体现层次。关键是逻辑上要分清，否则后期规则一多，工作流会变成一团乱麻。

1.3 平台选型背后的三个硬指标

市面上做智能体的平台不少，我最终选华为云智果 AgentArts，是拿三个硬指标卡出来的。

第一个指标是工具调用的稳定性。信贷场景要调用的外部服务很多，征信查询接口、工商信息接口、流水解析服务，任何一个调用超时或返回异常，整个审批链路就断了。AgentArts 在工具节点上支持重试策略和超时配置，这个在实测中救过我好几次。有一次工商接口返回慢，如果没有重试机制，那批进件全部会卡在决策层。

第二个指标是知识库的检索精度。信贷制度文件动辄几百页，智能体要能精准定位到"小微企业授信额度测算办法"里的某一条，而不是把整章内容都塞给模型。AgentArts 的知识库支持分段检索和相似度阈值调节，我一般把阈值设在 0.75 左右，太低会召回无关条款，太高会漏掉关键规则。

第三个指标是工作流的可调试性。搭智能体最怕的是"黑盒"，输入进去输出不对，但不知道哪一步错了。AgentArts 支持单节点调试和中间结果查看，我可以单独跑"流水解析"这个节点，看它提取的月均进账对不对，而不用每次都把整个流程跑一遍。这个功能在规则调试阶段至少帮我省了一半时间。

2. 核心细节解析与实操要点

2.1 知识库构建：把信贷制度"喂"对方式

信贷智能体的知识库不是把 PDF 丢进去就完事了。我踩过的第一个坑就是直接上传了一整套信贷管理办法，结果智能体检索出来的内容要么是目录页，要么是无关章节。后来我调整了策略，按"制度层级+业务场景"两个维度来组织知识库。

制度层级上，我把知识库分成三层：第一层是基本制度，比如《信贷业务管理办法》，这是总纲；第二层是产品制度，比如《小微企业流动资金贷款实施细则》；第三层是操作规范，比如《授信审批操作手册》。每一层单独建一个知识库，在工作流里根据进件类型选择挂载哪个库。这样做的好处是检索范围收窄了，精度自然就上去了。

业务场景上，我按"贷前、贷中、贷后"打标签。贷前主要挂载准入制度和反欺诈规则，贷中挂载额度测算和利率定价规则，贷后挂载预警和催收制度。AgentArts 的知识库支持标签过滤，我在工作流里通过条件节点判断当前处于哪个阶段，然后只检索对应标签下的内容。

分段策略也很关键。信贷制度里一条规则往往包含"适用对象、准入条件、额度上限、期限要求"多个要素，如果按固定字数切分，很容易把一条完整规则切碎。我的做法是按"条"切分，一条制度作为一个知识片段，如果某条特别长，再按"款"二次切分。实测下来，这种切法让检索命中率从原来的六成左右提升到了八成五以上。

注意：知识库更新频率要跟上制度修订节奏。信贷制度每年至少修订一次，有些产品制度季度就在调。我一般设置每月检查一次制度版本，发现更新就重新上传对应片段，避免智能体拿着旧规则做判断。

2.2 工作流节点设计：从进件到审批意见的完整链路

这套信贷智能体的工作流，我前后重构了三版，最终稳定下来的节点链路是这样的：

进件接收节点：接收外部传入的申请编号，调用信贷系统接口拉取该笔进件的所有材料清单。这个节点不涉及复杂逻辑，但要做好异常处理，如果申请编号不存在或材料未齐，直接走拒绝分支并输出原因。

材料解析节点组：这是最重的一组节点，下面挂载了四个子节点。营业执照解析节点提取企业名称、统一社会信用代码、成立日期、注册资本；银行流水解析节点提取近六个月月均进账、月均出账、期末余额；征信报告解析节点提取当前逾期次数、历史最大逾期天数、近三个月查询次数；纳税记录解析节点提取近一年纳税总额、纳税连续性。每个子节点都配置了失败重试和默认值兜底，比如流水解析失败时，月均进账默认置为 0 并标记"需人工复核"。

硬规则校验节点：把解析出来的字段逐条比对红线规则。我在这里用了一个"规则表"的设计，把红线规则写成 JSON 配置存在知识库里，节点运行时动态加载。这样做的好处是规则调整不用改工作流，改配置就行。红线规则包括：当前逾期次数大于 0、成立年限小于 1 年、近三个月查询次数大于 6 次、年龄大于 65 岁或小于 22 岁。任何一条命中，直接跳转到拒绝分支。

软评分节点：没被红线拦住的进件进入这里，按加权模型打分。我的评分模型包含五个维度：流水稳定性占 30 分、纳税贡献占 25 分、征信表现占 25 分、经营年限占 10 分、行业景气度占 10 分。每个维度下再细分档位，比如流水稳定性按"月均进账波动率"分三档，波动率低于 15% 得满分，15% 到 30% 得一半分，高于 30% 得零分。总分算出来后，映射到建议额度区间和利率档位。

审批意见生成节点：把前面所有节点的输出汇总，调用大模型生成一段结构化的审批意见。这段意见不是随便写的，我给它定了模板：先写"经系统自动审核"，然后分点列出关键指标，再写"建议授信额度 XX 万元，期限 XX 个月，利率 XX%"，最后附上"本意见由智能体生成，需人工复核确认"。模板化的好处是输出稳定，不会今天一个格式明天一个格式。

日志归档节点：把整个流程的输入、中间结果、输出、命中的规则、调用的工具全部打包成 JSON，写入审批日志表。这个节点是合规审计的命根子，千万不能省。

2.3 提示词工程：让模型"说人话"也"说对话"

信贷智能体的提示词，跟通用聊天机器人的提示词完全不是一个写法。通用场景你可以让模型自由发挥，信贷场景你必须把它的输出框死。

我在系统提示词里做了四件事。第一件是角色定义，明确告诉模型"你是一名信贷审批辅助助手，你的输出将作为人工审批的参考，不得直接作为最终审批结论"。这句话是免责也是定位，防止模型越权。

第二件是输出格式约束。我要求模型必须按 JSON 格式输出，字段包括decision（建议结论）、reason（理由列表）、suggested_amount（建议额度）、suggested_rate（建议利率）、risk_flags（风险提示）。JSON 的好处是下游系统可以直接解析，不用再做文本抽取。

第三件是知识引用约束。我要求模型在给出每一条理由时，必须标注引用了知识库中的哪一条制度。比如"根据《小微企业流动资金贷款实施细则》第十二条，建议额度不超过年纳税额的 3 倍"。这样做既增加了可信度，也方便人工复核时快速定位依据。

第四件是兜底话术。当模型遇到知识库中没有覆盖的情况时，不允许它编造规则，必须输出"当前知识库未覆盖该情形，建议转人工审批"。这条约束在实测中触发过几次，都是些比较偏的行业或特殊的股权结构，模型老老实实转人工，比瞎给结论强得多。

实操心得：提示词不是写一次就完事的。我一般会在工作流里加一个"提示词版本"字段，每次调整提示词就升一个版本号，日志里记录用的是哪个版本。这样后面发现某批审批意见质量下降，可以快速定位是不是提示词改坏了。

3. 实操过程与核心环节实现

3.1 环境准备与平台基础配置

开始搭之前，先把平台侧的基础配置做扎实。登录华为云智果 AgentArts 控制台后，第一件事是创建应用。应用名称我建议按"业务域-场景-版本"来命名，比如credit-approval-v1，后面应用多了不至于混淆。

创建完应用，先配工具。信贷场景需要的工具分三类：文档解析类、外部接口类、计算类。文档解析类我用了平台内置的 OCR 和 PDF 解析工具，直接在工作流里添加节点即可。外部接口类需要自己配，在"工具管理"里新建 HTTP 工具，填入接口地址、请求方法、请求头、参数映射。这里有个细节，信贷系统的接口一般都有签名校验，我是在工具配置里加了一个"前置脚本"节点，用 JavaScript 算好签名再传给接口。

计算类工具我单独写了一个云函数，把额度测算、利率定价、评分卡计算这些逻辑封装进去。为什么不直接在工作流里用代码节点算？因为信贷计算逻辑经常变，封装成独立函数后，改逻辑不用动工作流，重新部署函数就行。这个函数我用了 Python 写，入参是解析后的结构化字段，出参是评分和额度建议。

知识库配置前面已经讲过分层策略，这里补充一个操作细节：上传文档时，AgentArts 支持自定义分段规则。我一般用正则表达式按"第X条"来切分，切完后人工抽检十条，看看有没有切歪的。切歪的片段手动合并或拆分，别嫌麻烦，知识库质量直接决定智能体的上限。

3.2 工作流编排的完整操作步骤

工作流编排是这套智能体的核心操作，我按实际搭建顺序一步步说。

第一步，拖入"开始"节点，定义输入参数。我定义了三个入参：application_id（申请编号，字符串）、channel（进件渠道，枚举值）、priority（优先级，整数）。channel这个参数后面会用来决定走哪套规则，比如线上渠道和线下渠道的准入标准略有差异。

第二步，拖入"HTTP 请求"节点，调用信贷系统接口拉取进件详情。这个节点的输出是一个 JSON，包含材料列表和基本信息。配置时要注意设置超时时间为 10 秒，重试次数为 2 次。信贷系统偶尔会有慢查询，不设重试容易误杀。

第三步，拖入"条件分支"节点，判断材料是否齐全。判断逻辑是检查返回 JSON 中的materials数组长度是否大于 0，以及是否包含必需的四个材料类型。不齐全的走"拒绝"分支，输出"材料不齐，请补充后重新提交"。

第四步，拖入四个并行的"文档解析"节点，分别处理营业执照、流水、征信、纳税材料。AgentArts 支持并行节点，四个解析同时跑，比串行快不少。每个解析节点后面跟一个"字段映射"节点，把解析结果映射成统一的字段名，比如把"月均进账"和"月均收入"统一成monthly_income。

第五步，拖入"代码"节点，执行硬规则校验。我把红线规则写成一个 JSON 数组存在节点代码里，遍历检查。这个节点的输出是pass或reject，以及命中的规则列表。代码我用 JavaScript 写，大概三十行左右，逻辑很直白。

第六步，拖入"云函数调用"节点，执行软评分。把解析后的字段传给之前部署的评分函数，拿回总分和建议额度。这个节点要设置超时时间为 5 秒，因为评分函数里有几次数据库查询。

第七步，拖入"大模型"节点，生成审批意见。这个节点的提示词就是前面 2.3 节讲的那套。模型我选的是平台默认的通用模型，温度参数设成 0.1，让输出尽量稳定。温度太高的话，同样的输入每次输出都不一样，审批意见就没法用了。

第八步，拖入"日志归档"节点，把所有中间结果汇总写入数据库。这个节点用 HTTP 工具调用日志服务接口，把整个流程的上下文打包传过去。

第九步，拖入"结束"节点，定义输出参数。输出包括decision、suggested_amount、suggested_rate、reason、log_id。

整个工作流跑通后，我在测试环境用历史进件数据回测了 200 笔，通过率跟人工审批的吻合度在 87% 左右。不吻合的主要是些边缘案例，比如流水波动大但实际经营正常的，这类本来人工也会纠结，智能体给个参考意见反而有帮助。

3.3 参数计算与阈值设定的依据

信贷智能体里有一堆阈值参数，这些数不是拍脑袋定的，每一个都有依据。

先说流水波动率的阈值。我设的是 15% 和 30% 两档。这个数是从历史数据里跑出来的。我拉了 500 笔已结清的小微贷款，算它们放款前六个月的流水波动率，发现波动率低于 15% 的客户，逾期率是 1.2%；15% 到 30% 之间的，逾期率 3.5%；高于 30% 的，逾期率跳到 8.7%。所以 15% 和 30% 是两个自然的分档点。

再说征信查询次数的红线。我设的是近三个月大于 6 次直接拒绝。这个依据是行业通行标准，三个月内查询超过 6 次，通常意味着客户在多头借贷。我自己回测的数据也支持这个阈值，查询次数 7 次以上的客户，逾期率是查询 3 次以下客户的 4 倍多。

建议额度的计算公式是：min(年纳税额 × 3, 月均进账 × 6, 抵押物评估值 × 0.7)。三个上限取最小值，这是为了控制风险敞口。年纳税额乘 3 是参考了税贷产品的常见倍数，月均进账乘 6 是覆盖半年的经营周转，抵押物打七折是留出处置折价空间。

利率定价用的是基准利率加点模式。基准利率取 LPR，加点幅度根据评分结果来：评分 90 分以上加 50 个基点，80 到 90 分加 100 个基点，70 到 80 分加 150 个基点，70 分以下加 200 个基点。这个加点幅度是跟资金成本和风险成本挂钩的，评分越低风险溢价越高。

提示：这些参数不是一成不变的。我一般每季度用新数据回测一次，看看阈值要不要调。经济环境变了，同样的流水波动率对应的风险可能就不一样了。

4. 常见问题与排查技巧实录

4.1 智能体输出不稳定的排查思路

智能体输出不稳定是搭信贷智能体最常见的问题，表现就是同样的进件，今天跑出来建议额度 50 万，明天跑出来 45 万。这个问题我遇到过好几次，排查下来主要有三个原因。

第一个原因是模型温度参数设高了。大模型节点默认温度可能是 0.7 或 0.8，这个值在创意写作场景没问题，在信贷场景就是灾难。我把温度降到 0.1 之后，输出稳定性明显提升。如果平台支持，还可以设置随机种子，进一步固定输出。

第二个原因是知识库检索结果波动。如果知识库分段不合理，同一个问题可能这次召回第三条，下次召回第五条，模型参考的依据变了，输出自然就变了。解决办法是优化分段策略，并且在检索节点设置相似度阈值下限，低于阈值的片段直接丢弃，宁可少召回也不要召回错的。

第三个原因是上游解析结果不稳定。比如流水解析节点，如果 OCR 识别质量时好时坏，提取的月均进账每次不一样，下游评分和额度自然跟着变。这个问题要在解析节点加校验，比如识别置信度低于 0.8 的字段标记为"待复核"，不参与自动评分。

排查的时候，我一般用"固定输入法"：找一笔历史进件，把它的所有材料固定下来，然后连续跑十次，看输出是否一致。如果不一致，再逐个节点看中间结果，定位是哪个节点在波动。

4.2 工具调用失败的兜底策略

信贷智能体依赖的外部工具很多，任何一个挂了都会影响主流程。我总结了几种常见失败场景和对应的兜底策略。

这张表是我在实际运维中慢慢攒出来的，每一条都对应过一次真实的故障。最惊险的一次是征信接口批量超时，如果没有兜底策略，那批进件全部会卡死。后来加了"征信待查"标记，智能体照常出审批意见，只是把征信维度空着，人工复核时补上就行。

注意：兜底策略的核心原则是"不阻塞主流程"。信贷审批有时效要求，智能体可以给不完整的意见，但不能因为一个工具挂了就整个停摆。当然，兜底产生的"待复核"标记必须在日志里醒目标注，不能悄悄混过去。

4.3 合规留痕的实操细节

信贷是强监管行业，智能体做的每一个判断都要能解释、能追溯。我在日志归档节点上花了不少心思，最终定下来的日志结构包含以下字段：

• application_id：申请编号，关联业务系统
• workflow_version：工作流版本号，每次改流程升版本
• prompt_version：提示词版本号
• input_snapshot：输入快照，进件材料的原始解析结果
• rule_hits：命中的硬规则列表，没命中就是空数组
• score_detail：软评分各维度得分明细
• knowledge_refs：引用的知识库片段 ID 列表
• model_output：模型原始输出，未经处理的
• final_decision：最终输出给业务系统的结论
• timestamp：时间戳

这份日志我要求保留至少三年，跟信贷档案的保存期限对齐。实际用起来，最大的价值是在监管检查时能快速还原每一笔智能体审批的完整链路。有一次检查问某笔进件为什么给了 80 万额度，我直接调出日志，看到评分明细里流水稳定性满分、纳税贡献满分，引用了制度第十二条和第十五条，检查人员看了就认可了。

还有一个细节是模型输出的原始记录。有些人为了好看，把模型输出清洗一遍再存日志，我不建议这么做。原始输出里可能包含模型的一些"思考痕迹"，比如它为什么排除了某个风险点，这些信息在复盘时很有价值。清洗后的结果可以另存一个字段，但原始的一定要留着。

4.4 从单场景到多场景的扩展经验

这套信贷智能体跑稳之后，我试着往其他场景扩展，踩了一些坑也攒了一些经验。

第一个扩展方向是贷后预警。贷后预警的逻辑跟贷前审批不一样，它更关注"变化"而不是"状态"。比如客户流水突然下降 50%、纳税中断、征信新增逾期，这些是预警信号。我把贷前的工作流复制了一份，把"硬规则校验"节点换成"变化检测"节点，对比当期数据和历史数据，超过阈值就触发预警。知识库也换成了贷后管理制度。整个改造大概花了三天，比从零搭快得多。

第二个扩展方向是制度学习助手。这个场景跟审批正好相反，审批是"用制度"，学习助手是"学制度"。我把知识库挂载到对话式智能体上，员工可以问"小微企业贷款的准入条件是什么"，智能体检索制度片段后给出回答。这个场景对输出格式要求没那么严，但对知识库覆盖度要求高，我把所有信贷制度都传了进去，还加了一个"制度更新提醒"功能，制度修订后自动推送通知给相关岗位。

第三个扩展方向是反欺诈辅助。这个场景我还在摸索，目前的做法是把反欺诈规则也做成一个规则表，跟审批规则并行跑。反欺诈规则更关注"关联关系"，比如同一手机号关联多个申请、同一地址注册多家企业。这些规则需要查外部数据，调用量比较大，我还在优化性能。

扩展过程中最大的体会是：工作流的骨架可以复用，但规则和知识库必须重做。贷前和贷后的逻辑差异很大，直接套用会出问题。我的做法是把公共部分（材料解析、日志归档、异常处理）抽成子工作流，场景特有的部分单独编排，这样既复用了代码，又保证了场景适配。

5. 智能体在信贷场景的边界与人工协同

5.1 哪些环节必须保留人工

搭了这套智能体之后，我最大的感受是：智能体不是来取代人的，是来把人从重复劳动里解放出来的。信贷审批里有几个环节，我坚持保留人工。

首次合作客户的大额授信必须人工。智能体可以给出参考意见，但最终决策要人来做。原因很简单，首次合作没有历史数据支撑，智能体的评分模型对这类客户预测能力有限。我设的规则是单笔超过 100 万且无历史合作记录的，智能体只输出参考意见，不输出建议额度。

涉及抵押物的复杂结构必须人工。抵押物评估涉及产权、变现能力、法律瑕疵等多个维度，智能体目前只能处理标准化的住宅和厂房，遇到在建工程、股权质押、应收账款质押这些，解析和评估都力不从心。我的做法是智能体识别到非标准抵押物就自动转人工。

客户主动申诉必须人工。智能体拒绝的进件，客户如果申诉，必须转人工复核。智能体的拒绝理由可能是"流水波动率过高"，但客户可能解释说是季节性因素，这种上下文智能体理解不了，得人来判断。

监管有明确要求的环节必须人工。有些监管规定要求"面签面谈"、"双人调查"，这些是智能体替代不了的。我在工作流里把这些环节标记为"人工必做"，智能体只负责准备材料清单和预填表单。

5.2 人机协同的工作流设计

人机协同不是简单地把智能体输出丢给人看，而是要设计好交接点。我在工作流里设了三个交接点。

第一个交接点是智能体输出后的确认环节。智能体给出审批意见后，不是直接生效，而是进入"待确认"状态，由客户经理或审批人确认。确认界面上，智能体的意见和依据都展示出来，人工可以采纳、修改或驳回。修改和驳回的原因要记录下来，这些数据后面可以用来优化智能体。

第二个交接点是异常转人工环节。前面说的兜底策略产生的"待复核"标记，会触发转人工。转人工时，智能体把已经完成的工作（材料解析、部分评分）都带过去，人工不用从头再来，只需要处理异常部分。

第三个交接点是定期复盘环节。我每月会抽一批智能体审批的进件，跟人工审批的结果做对比，看看智能体的判断跟人工的差异在哪里。差异大的案例，我会分析是规则问题还是模型问题，然后针对性调整。这个复盘机制让智能体的准确率在三个月里从 87% 提升到了 92%。

实操心得：人机协同的关键是"让人的时间花在刀刃上"。智能体把能做的都做了，人只处理智能体做不了的。我算过一笔账，搭了智能体之后，单笔进件的平均处理时间从 45 分钟降到了 18 分钟，客户经理的时间更多花在客户沟通和实地调查上，而不是埋头查制度填表单。

5.3 效果评估与持续优化

智能体上线不是终点，是起点。我建了一套评估指标来持续跟踪效果。

准确率是最核心的指标，定义是智能体建议结论与最终人工审批结论一致的比例。我按周统计，目前稳定在 92% 左右。准确率下降的时候要警惕，可能是制度变了知识库没更新，也可能是模型版本升级导致行为变化。

转人工率是辅助指标，定义是触发转人工的进件占比。这个指标太高说明智能体能力不足，太低可能说明兜底策略太宽松。我目前控制在 15% 左右，其中大部分是首次合作大额授信和复杂抵押物。

处理时长是效率指标，定义是从进件到出审批意见的平均时间。智能体上线前是 45 分钟，现在是 18 分钟，其中智能体自动处理部分平均 3 分钟，人工确认部分平均 15 分钟。

人工修改率是质量指标，定义是人工对智能体意见做了修改的进件占比。这个指标反映智能体的建议质量，修改率越低说明智能体越靠谱。我目前是 8% 左右，修改的主要是额度微调，比如智能体建议 50 万，人工改成 48 万。

优化方向上，我主要做两件事。一是规则迭代，把人工修改的案例拿出来分析，看看是不是某条规则设得太松或太紧，然后调整阈值。二是知识库更新，制度修订后第一时间更新知识库，并且用历史进件回测，看看新制度对审批结果的影响。

最后分享一个我在实操中体会很深的小技巧：给智能体加一个"置信度"输出。我让模型在输出审批意见的同时，给一个 0 到 1 的置信度分数。置信度低于 0.7 的进件，自动标记为"建议人工重点复核"。这个分数不是模型随便给的，我在提示词里要求它根据"知识库覆盖程度、字段完整度、规则命中明确度"三个维度来评估。实测下来，低置信度的进件确实问题更多，人工重点看这些，效率提升很明显。