1. 金融信贷场景下智能体落地的真实挑战金融信贷这个领域做过的人都知道它跟通用问答机器人完全是两码事。我在消费金融和银行助贷方向摸爬滚打了几年最大的感受是信贷业务的每一个环节都绑着强合规、强风控、强审计任何一句对外输出的话、任何一个审批建议都可能成为日后被追责的证据。所以当我们谈“金融信贷 AI 智能体”的时候谈的绝不是接个大模型 API 让它自由发挥而是要把它当成一个有边界、有记忆、有工具调用能力、有可追溯链路的数字员工来设计。华为云智果 AgentArts 这个平台是我近期在智能体工程化落地里比较关注的一套东西。它本质上是一个智能体开发与运行平台把大模型的推理能力、工具编排、知识库检索、流程控制这几件事打包成可配置的组件让开发者不用从零去搭一套 Agent 框架。放到金融信贷场景里它能覆盖的需求非常具体贷前资料预审、贷中风险评估辅助、贷后催收话术生成、合规问答、制度条例学习助手等等。这些活儿以前要么靠人工要么靠规则引擎硬编码现在可以用智能体的方式重新组织。这篇文章我想聊的不是“智能体有多牛”这种空话而是把我实际搭建一个金融信贷智能体的完整思路、关键参数、踩过的坑、以及华为云智果 AgentArts 上那些真正影响成败的配置细节掰开揉碎讲清楚。适合两类人看一类是正在做金融科技产品、想把大模型能力接进信贷流程的工程师和产品经理另一类是想理解“智能体到底怎么从 Demo 变成生产系统”的技术爱好者。哪怕你之前只玩过在 AI Studio 上搭个简单的制度条例学习助手这篇文章里的工程化思路也能直接迁移过去。先说结论性的判断金融信贷智能体的核心难点从来不是模型本身而是意图路由的准确性、知识检索的召回质量、工具调用的可靠性、以及全链路的可审计性。这四件事任何一件没做好智能体在信贷场景里就是不可用的。下面我按搭建顺序一层一层拆。2. 智能体整体架构设计与选型逻辑2.1 为什么金融信贷智能体不能做成“一个大模型包打天下”很多人第一次搭智能体习惯性地把系统提示词写得巨长把所有业务规则、话术模板、风控要点全塞进去然后指望模型一次性搞定。我早期也这么干过结果非常惨上下文一长模型对关键约束的注意力就衰减前面写的“不得承诺放款额度”这种硬性合规要求聊到第五轮就忘了而且每次请求都带着几千 token 的系统提示成本和延迟都下不来。金融信贷业务的正确做法是分层解耦。我在华为云智果 AgentArts 上的架构大致是这样的最外层是一个意图识别与路由层负责判断用户这句话属于哪类业务咨询、申请、查询、投诉、催收应答等中间是专业子智能体层每个子智能体只负责一个窄领域比如“征信知识问答智能体”“贷款产品匹配智能体”“合规话术生成智能体”底层是工具与知识层包括产品数据库查询、征信规则引擎、制度条例知识库、以及各类 API。这么设计的好处很直接每个子智能体的系统提示可以写得很短很聚焦合规约束不容易被稀释知识库可以按业务域分开建检索精度更高某个子智能体出问题也不会拖垮整个系统。AgentArts 支持多智能体编排这一点在信贷场景里是刚需不是锦上添花。2.2 华为云智果 AgentArts 在信贷场景的组件选型AgentArts 提供的核心能力我梳理成一张表方便对照信贷业务需求来选平台能力信贷场景对应需求选型建议大模型推理意图理解、话术生成、风险点归纳选支持长上下文且指令遵循强的模型合规类任务优先知识库检索RAG制度条例、产品说明、征信规则必须做分块优化和元数据过滤不能直接整篇灌工具/函数调用查询额度、计算利率、调征信接口每个工具要有严格的入参校验和超时兜底工作流编排贷前预审多步骤流程用显式流程控制不要全靠模型自主决策记忆管理多轮对话中的用户信息保持敏感信息脱敏后再入记忆设置过期策略可观测与日志合规审计、问题回溯全量记录输入输出和工具调用链这是硬要求这里我要特别强调工作流编排这一项。信贷业务里有大量“必须按顺序来”的环节比如先核验身份、再查征信、再算额度、最后给建议。如果让模型自主决定调用顺序它可能跳过核验直接算额度这在合规上是致命的。AgentArts 的工作流能力允许我把这些步骤画成显式的有向流程模型只在每个节点内部做它擅长的事理解、生成、判断节点之间的跳转由流程控制。这个设计思路是我踩过坑之后才彻底想明白的。2.3 意图路由的设计信贷智能体的“第一道闸门”意图路由做不好后面全白搭。我见过太多智能体用户问“我征信有点花能不能贷”它直接开始生成贷款建议完全没意识到这句话背后可能涉及征信查询授权问题。路由层要做的第一件事是分类第二件事是风险拦截。我的做法是在路由层放一个轻量级的分类模型或者用大模型做 few-shot 分类把用户输入映射到预定义的意图标签上。信贷场景的意图标签我一般设这么几类产品咨询、资格预判、申请引导、进度查询、还款问题、投诉建议、以及一个兜底的“其他/需转人工”。每个标签对应不同的子智能体和不同的合规约束。提示路由层一定要有一个“高风险意图”的独立分支比如涉及“协商还款”“减免利息”“征信异议”这类话题不要交给普通子智能体处理直接走人工或专门流程。这是合规底线。路由的准确率我用一个土办法验证拿历史客服对话记录做测试集人工标注真实意图然后跑路由看混淆矩阵。实测下来few-shot 分类在信贷这种垂直领域只要标签定义清晰、每类给够 5-8 个示例准确率能到 90% 以上。低于这个数就得回去检查标签是不是有重叠、示例是不是有歧义。3. 核心细节解析与实操要点3.1 知识库构建制度条例学习助手的正确打开方式热词里提到“实现制度条例学习助手应用的构建”这其实是金融信贷智能体最基础也最重要的一块。信贷业务涉及的制度文件极多监管规定、内部风控手册、产品说明书、催收话术规范。把这些灌进知识库让智能体基于它们回答问题是 RAG 的典型应用。但直接整篇灌进去是灾难。我试过把一份 80 页的信贷管理制度直接上传结果检索出来的片段经常是目录页或者无关章节。问题出在分块策略上。我的经验是按语义结构分块不要按固定字数切。制度文件天然有章节、条款的层级按“第X条”这种粒度切每块 200-500 字保留条款编号作为元数据。给每块打上业务域标签。比如“贷前”“贷中”“贷后”“征信”“催收”检索时先用标签过滤再算相似度召回质量提升非常明显。表格和附件单独处理。制度里的利率表、额度对照表用普通文本分块会丢结构最好转成结构化数据单独存需要时用工具调用而不是 RAG 检索。在 AgentArts 的知识库配置里我一般会把相似度阈值设在 0.75 左右低于这个值的检索结果直接丢弃宁可让智能体说“这个问题我需要转人工确认”也不要让它基于低质量片段胡编。金融场景里答错比不答的代价大得多。3.2 工具调用的可靠性设计别让智能体“想当然”智能体调用工具是它区别于普通聊天机器人的核心能力。在信贷场景里工具可能是“查询用户可用额度”“计算等额本息月供”“校验身份证格式”“调征信规则接口”。这些工具一旦被错误调用或者传入错误参数后果很严重。我总结了几条硬性规则每个工具必须有严格的入参 schema。比如“计算月供”工具本金、利率、期数三个参数都要有类型和范围校验利率传个负数进来必须直接拒绝。工具调用前要有确认环节。对于会产生副作用的操作比如提交申请、发起查询智能体要先向用户确认得到明确同意再执行。这既是合规要求也是用户体验。工具超时和失败要有兜底话术。征信接口偶尔会超时这时候智能体不能卡死或者乱编结果要能说“系统暂时繁忙请稍后再试或转人工”。工具返回结果要经过二次校验。比如额度计算返回了一个异常大的数字智能体应该能识别出这可能是接口异常而不是直接告诉用户“您可以贷 500 万”。注意工具调用的日志必须全量记录包括入参、出参、耗时、调用者身份。金融审计的时候这些日志就是你的证据链。AgentArts 的可观测能力可以帮上忙但你要主动去配置记录粒度默认配置往往不够细。3.3 提示词工程合规约束怎么写才不会被模型“遗忘”系统提示词是智能体的行为准则。信贷场景的提示词里合规约束是重中之重。我踩过的坑是把约束写成一大段模型记不住。后来我改成结构化、短句、带优先级的写法效果好很多。我的提示词模板大致长这样角色你是XX信贷机构的智能助手只处理与信贷业务相关的问题。 硬性约束最高优先级任何情况下不得违反 1. 不得承诺具体放款额度、利率、放款时间。 2. 不得对征信结果做主观评价。 3. 涉及协商还款、减免、征信异议一律引导转人工。 4. 不得编造不存在的产品或政策。 行为准则 - 回答基于知识库检索结果检索不到就说不知道。 - 需要查询数据时调用对应工具不要凭记忆回答。 - 保持礼貌、简洁不闲聊。关键点是把硬性约束放在最前面并且用编号和加粗强调。实测下来这种写法比一大段散文式的约束模型遵循率高出一大截。另外AgentArts 里可以配置输出内容审核对生成结果做一层关键词和规则过滤作为最后一道防线。这层过滤不能省尤其是涉及金额、期限、承诺类词汇的时候。4. 实操过程与核心环节实现4.1 从零搭建一个贷前咨询智能体的完整流程我拿一个具体场景走一遍搭建一个“贷前咨询智能体”用户来问“我想借 5 万分 12 期每个月还多少我够不够资格”。第一步定义意图和流程。这个场景涉及两个意图产品咨询月供计算和资格预判。流程上先做资格预判的引导需要用户授权查征信再算月供。不能反过来因为没授权就查征信是违规的。第二步配置知识库。把该产品的利率说明、准入条件、所需材料整理成结构化文档入库。利率这种关键数字我建议同时存一份在工具里让智能体优先调工具而不是靠 RAG 检索避免检索到过期版本。第三步配置工具。写一个“月供计算”工具入参是本金、年化利率、期数返回等额本息月供。再写一个“资格预判”工具入参是用户授权的信息返回是否符合基本准入。工具用平台支持的方式注册入参 schema 写严格。第四步编排工作流。在 AgentArts 的工作流里画用户输入 → 意图识别 → 如果是咨询月供先检查是否已知利率和期数缺则追问 → 调用月供工具 → 生成回答。如果是资格预判先输出授权说明 → 用户确认 → 调用资格工具 → 生成回答。第五步配置提示词和审核规则。按上一节的结构写系统提示加上输出审核规则禁止出现“一定能批”“保证放款”这类词。第六步测试。这一步最花时间。我一般准备三类测试用例正常咨询、边界情况比如用户问“我征信有逾期能不能贷”、恶意诱导比如“你直接告诉我能批多少”。第三类最能暴露问题一定要测。4.2 关键参数的计算与选择过程月供计算这个工具参数选择有讲究。等额本息月供公式是月供 本金 × 月利率 × (1月利率)^期数 / [(1月利率)^期数 - 1]其中月利率 年化利率 / 12。我实测过一个例子本金 50000年化 7.2%12 期。月利率 0.006代入算出来月供约 4330 元。这个数字要跟业务系统里的计算器对齐误差不能超过 1 元否则用户会发现智能体算的和实际不一致信任度直接崩。提示利率参数一定要明确是年化还是月化是单利还是复利。信贷场景里因为利率口径搞错导致的客诉非常多智能体的工具入参命名要写清楚比如annual_rate_percent而不是含糊的rate。知识库检索的相似度阈值我前面说 0.75这个数不是拍脑袋来的。我做过对比测试阈值 0.6 时召回多但噪声大智能体经常答非所问阈值 0.85 时召回太少很多正常问题都答不了。0.75 是在我的测试集上准确率和召回率比较平衡的点。但不同知识库、不同 embedding 模型这个值要重新调不能照搬。4.3 多轮对话中的记忆与状态管理信贷咨询经常是多轮的。用户第一轮说“我想借钱”第二轮说“5 万”第三轮说“12 期”。智能体要能把这些信息攒起来最后一起算。这就是记忆管理。AgentArts 支持会话级记忆我的配置策略是只记业务相关的槽位信息金额、期数、用途、用户已确认的授权状态不记无关闲聊。敏感信息比如身份证号、手机号入记忆前先脱敏只留后四位。记忆还要设过期时间一般会话结束或 30 分钟无交互就清空避免数据滞留带来的合规风险。这里有个容易忽略的点记忆里的信息在被工具调用时要重新校验。比如用户第三轮说“改成 10 万”智能体不能直接用记忆里的旧金额要以最新一轮的输入为准。我见过因为记忆更新逻辑写错导致智能体用旧金额算月供的 bug用户当场就发现不对。5. 常见问题与排查技巧实录5.1 智能体“胡说八道”的排查路径金融信贷智能体最怕的就是幻觉。用户问“你们利率多少”智能体编一个“3.5%”出来这是要出事的。排查幻觉我一般按这个顺序查现象可能原因排查方法解决答了知识库没有的内容检索阈值太低召回了无关片段看检索日志的相似度分数提高阈值或加“检索不到就说不知道”的约束数字类回答错误模型凭记忆答没调工具看工具调用日志提示词强制要求数字类问题必须调工具前后轮回答矛盾记忆管理有问题看会话状态记录修正槽位更新逻辑答了不该答的如承诺额度输出审核没配好看审核规则命中情况补充关键词和规则我踩过最深的一个坑是知识库里有一份旧版产品说明没删用户问利率时检索到了旧版智能体答了个已经下架的利率。后来我养成了习惯知识库更新必须带版本号旧版本直接下线检索时按版本过滤。5.2 工具调用失败的兜底设计工具调用失败在信贷场景里太常见了征信接口、额度接口都可能超时。我的兜底设计分三层第一层重试。网络类错误自动重试 1-2 次间隔 500ms。第二层降级。重试还失败返回预设的兜底话术比如“系统正在升级请稍后重试”同时记录日志。第三层转人工。如果用户明显着急或者问题复杂直接给转人工入口。注意兜底话术里绝对不能出现“系统故障”“接口报错”这种暴露内部实现的说法对用户要说“服务繁忙”对日志要记详细错误码。这两者要分开。5.3 合规审计视角下的日志配置这一块是很多技术团队容易忽略的。金融信贷智能体的日志不只是给开发调试用的更是给合规审计用的。我配置日志时会确保记录每次会话的完整输入输出、每次工具调用的入参出参和时间戳、每次知识库检索的命中文档和相似度、每次输出审核的命中情况。这些日志要能按用户、按时间、按会话 ID 检索保存期限按监管要求来一般不少于业务存续期。AgentArts 的日志能力可以对接但字段和保留策略要自己配。我建议在项目初期就把日志 schema 定好后期补日志字段非常痛苦。6. 从 Demo 到生产的工程化经验6.1 灰度发布与效果监控智能体上线不能一把梭。我的做法是先内部灰度让业务同事用一周收集 bad case再小流量对外比如 5% 的用户观察指标稳定后再逐步放量。监控指标我盯这几个意图路由准确率、知识库检索命中率、工具调用成功率、转人工率、用户满意度如果有评价入口。其中转人工率是个很灵敏的指标。如果突然升高说明智能体在某类问题上答不好了要赶紧查。我遇到过转人工率一夜之间从 15% 涨到 40%查下来是知识库某份文档被误删检索大面积失败。6.2 持续迭代bad case 驱动的优化闭环智能体不是上线就完事它需要持续喂 bad case。我建了一个流程每周导出转人工的会话和用户差评的会话人工标注问题类型然后针对性优化——是提示词问题就改提示词是知识库问题就补文档是工具问题就修工具。这个闭环跑起来智能体的效果会肉眼可见地变好。在 AI Studio 上搭制度条例学习助手的时候这套方法同样适用只是规模小一些。核心逻辑是一样的用真实失败案例驱动迭代而不是凭感觉调参。6.3 团队协作与职责划分最后说点工程之外但很重要的。金融信贷智能体的搭建不是算法工程师一个人的事。我的经验是需要三类角色配合懂业务的定义意图、写合规约束、标注 bad case、懂算法的调提示词、配检索、优化工具、懂工程的搭流程、配日志、做监控。AgentArts 这类平台降低了工程门槛但业务和算法的配合依然是成败关键。我见过技术很强但业务不参与的团队搭出来的智能体业务同事根本不敢用因为合规约束不符合实际业务口径。我个人在实际操作中的体会是金融信贷智能体的搭建七分在业务梳理和合规设计三分在技术实现。把意图定义清楚、把知识库整理干净、把合规约束写死技术上的事反而水到渠成。反过来如果业务逻辑一团乱再强的模型也救不了。另外分享一个小技巧每次改完提示词或知识库一定要跑一遍回归测试集别嫌麻烦信贷场景里一次线上事故的代价够你跑一年的测试。 金融信贷AI智能体工程化落地：华为云智果AgentArts架构设计与合规实践
1. 金融信贷场景下智能体落地的真实挑战金融信贷这个领域做过的人都知道它跟通用问答机器人完全是两码事。我在消费金融和银行助贷方向摸爬滚打了几年最大的感受是信贷业务的每一个环节都绑着强合规、强风控、强审计任何一句对外输出的话、任何一个审批建议都可能成为日后被追责的证据。所以当我们谈“金融信贷 AI 智能体”的时候谈的绝不是接个大模型 API 让它自由发挥而是要把它当成一个有边界、有记忆、有工具调用能力、有可追溯链路的数字员工来设计。华为云智果 AgentArts 这个平台是我近期在智能体工程化落地里比较关注的一套东西。它本质上是一个智能体开发与运行平台把大模型的推理能力、工具编排、知识库检索、流程控制这几件事打包成可配置的组件让开发者不用从零去搭一套 Agent 框架。放到金融信贷场景里它能覆盖的需求非常具体贷前资料预审、贷中风险评估辅助、贷后催收话术生成、合规问答、制度条例学习助手等等。这些活儿以前要么靠人工要么靠规则引擎硬编码现在可以用智能体的方式重新组织。这篇文章我想聊的不是“智能体有多牛”这种空话而是把我实际搭建一个金融信贷智能体的完整思路、关键参数、踩过的坑、以及华为云智果 AgentArts 上那些真正影响成败的配置细节掰开揉碎讲清楚。适合两类人看一类是正在做金融科技产品、想把大模型能力接进信贷流程的工程师和产品经理另一类是想理解“智能体到底怎么从 Demo 变成生产系统”的技术爱好者。哪怕你之前只玩过在 AI Studio 上搭个简单的制度条例学习助手这篇文章里的工程化思路也能直接迁移过去。先说结论性的判断金融信贷智能体的核心难点从来不是模型本身而是意图路由的准确性、知识检索的召回质量、工具调用的可靠性、以及全链路的可审计性。这四件事任何一件没做好智能体在信贷场景里就是不可用的。下面我按搭建顺序一层一层拆。2. 智能体整体架构设计与选型逻辑2.1 为什么金融信贷智能体不能做成“一个大模型包打天下”很多人第一次搭智能体习惯性地把系统提示词写得巨长把所有业务规则、话术模板、风控要点全塞进去然后指望模型一次性搞定。我早期也这么干过结果非常惨上下文一长模型对关键约束的注意力就衰减前面写的“不得承诺放款额度”这种硬性合规要求聊到第五轮就忘了而且每次请求都带着几千 token 的系统提示成本和延迟都下不来。金融信贷业务的正确做法是分层解耦。我在华为云智果 AgentArts 上的架构大致是这样的最外层是一个意图识别与路由层负责判断用户这句话属于哪类业务咨询、申请、查询、投诉、催收应答等中间是专业子智能体层每个子智能体只负责一个窄领域比如“征信知识问答智能体”“贷款产品匹配智能体”“合规话术生成智能体”底层是工具与知识层包括产品数据库查询、征信规则引擎、制度条例知识库、以及各类 API。这么设计的好处很直接每个子智能体的系统提示可以写得很短很聚焦合规约束不容易被稀释知识库可以按业务域分开建检索精度更高某个子智能体出问题也不会拖垮整个系统。AgentArts 支持多智能体编排这一点在信贷场景里是刚需不是锦上添花。2.2 华为云智果 AgentArts 在信贷场景的组件选型AgentArts 提供的核心能力我梳理成一张表方便对照信贷业务需求来选平台能力信贷场景对应需求选型建议大模型推理意图理解、话术生成、风险点归纳选支持长上下文且指令遵循强的模型合规类任务优先知识库检索RAG制度条例、产品说明、征信规则必须做分块优化和元数据过滤不能直接整篇灌工具/函数调用查询额度、计算利率、调征信接口每个工具要有严格的入参校验和超时兜底工作流编排贷前预审多步骤流程用显式流程控制不要全靠模型自主决策记忆管理多轮对话中的用户信息保持敏感信息脱敏后再入记忆设置过期策略可观测与日志合规审计、问题回溯全量记录输入输出和工具调用链这是硬要求这里我要特别强调工作流编排这一项。信贷业务里有大量“必须按顺序来”的环节比如先核验身份、再查征信、再算额度、最后给建议。如果让模型自主决定调用顺序它可能跳过核验直接算额度这在合规上是致命的。AgentArts 的工作流能力允许我把这些步骤画成显式的有向流程模型只在每个节点内部做它擅长的事理解、生成、判断节点之间的跳转由流程控制。这个设计思路是我踩过坑之后才彻底想明白的。2.3 意图路由的设计信贷智能体的“第一道闸门”意图路由做不好后面全白搭。我见过太多智能体用户问“我征信有点花能不能贷”它直接开始生成贷款建议完全没意识到这句话背后可能涉及征信查询授权问题。路由层要做的第一件事是分类第二件事是风险拦截。我的做法是在路由层放一个轻量级的分类模型或者用大模型做 few-shot 分类把用户输入映射到预定义的意图标签上。信贷场景的意图标签我一般设这么几类产品咨询、资格预判、申请引导、进度查询、还款问题、投诉建议、以及一个兜底的“其他/需转人工”。每个标签对应不同的子智能体和不同的合规约束。提示路由层一定要有一个“高风险意图”的独立分支比如涉及“协商还款”“减免利息”“征信异议”这类话题不要交给普通子智能体处理直接走人工或专门流程。这是合规底线。路由的准确率我用一个土办法验证拿历史客服对话记录做测试集人工标注真实意图然后跑路由看混淆矩阵。实测下来few-shot 分类在信贷这种垂直领域只要标签定义清晰、每类给够 5-8 个示例准确率能到 90% 以上。低于这个数就得回去检查标签是不是有重叠、示例是不是有歧义。3. 核心细节解析与实操要点3.1 知识库构建制度条例学习助手的正确打开方式热词里提到“实现制度条例学习助手应用的构建”这其实是金融信贷智能体最基础也最重要的一块。信贷业务涉及的制度文件极多监管规定、内部风控手册、产品说明书、催收话术规范。把这些灌进知识库让智能体基于它们回答问题是 RAG 的典型应用。但直接整篇灌进去是灾难。我试过把一份 80 页的信贷管理制度直接上传结果检索出来的片段经常是目录页或者无关章节。问题出在分块策略上。我的经验是按语义结构分块不要按固定字数切。制度文件天然有章节、条款的层级按“第X条”这种粒度切每块 200-500 字保留条款编号作为元数据。给每块打上业务域标签。比如“贷前”“贷中”“贷后”“征信”“催收”检索时先用标签过滤再算相似度召回质量提升非常明显。表格和附件单独处理。制度里的利率表、额度对照表用普通文本分块会丢结构最好转成结构化数据单独存需要时用工具调用而不是 RAG 检索。在 AgentArts 的知识库配置里我一般会把相似度阈值设在 0.75 左右低于这个值的检索结果直接丢弃宁可让智能体说“这个问题我需要转人工确认”也不要让它基于低质量片段胡编。金融场景里答错比不答的代价大得多。3.2 工具调用的可靠性设计别让智能体“想当然”智能体调用工具是它区别于普通聊天机器人的核心能力。在信贷场景里工具可能是“查询用户可用额度”“计算等额本息月供”“校验身份证格式”“调征信规则接口”。这些工具一旦被错误调用或者传入错误参数后果很严重。我总结了几条硬性规则每个工具必须有严格的入参 schema。比如“计算月供”工具本金、利率、期数三个参数都要有类型和范围校验利率传个负数进来必须直接拒绝。工具调用前要有确认环节。对于会产生副作用的操作比如提交申请、发起查询智能体要先向用户确认得到明确同意再执行。这既是合规要求也是用户体验。工具超时和失败要有兜底话术。征信接口偶尔会超时这时候智能体不能卡死或者乱编结果要能说“系统暂时繁忙请稍后再试或转人工”。工具返回结果要经过二次校验。比如额度计算返回了一个异常大的数字智能体应该能识别出这可能是接口异常而不是直接告诉用户“您可以贷 500 万”。注意工具调用的日志必须全量记录包括入参、出参、耗时、调用者身份。金融审计的时候这些日志就是你的证据链。AgentArts 的可观测能力可以帮上忙但你要主动去配置记录粒度默认配置往往不够细。3.3 提示词工程合规约束怎么写才不会被模型“遗忘”系统提示词是智能体的行为准则。信贷场景的提示词里合规约束是重中之重。我踩过的坑是把约束写成一大段模型记不住。后来我改成结构化、短句、带优先级的写法效果好很多。我的提示词模板大致长这样角色你是XX信贷机构的智能助手只处理与信贷业务相关的问题。 硬性约束最高优先级任何情况下不得违反 1. 不得承诺具体放款额度、利率、放款时间。 2. 不得对征信结果做主观评价。 3. 涉及协商还款、减免、征信异议一律引导转人工。 4. 不得编造不存在的产品或政策。 行为准则 - 回答基于知识库检索结果检索不到就说不知道。 - 需要查询数据时调用对应工具不要凭记忆回答。 - 保持礼貌、简洁不闲聊。关键点是把硬性约束放在最前面并且用编号和加粗强调。实测下来这种写法比一大段散文式的约束模型遵循率高出一大截。另外AgentArts 里可以配置输出内容审核对生成结果做一层关键词和规则过滤作为最后一道防线。这层过滤不能省尤其是涉及金额、期限、承诺类词汇的时候。4. 实操过程与核心环节实现4.1 从零搭建一个贷前咨询智能体的完整流程我拿一个具体场景走一遍搭建一个“贷前咨询智能体”用户来问“我想借 5 万分 12 期每个月还多少我够不够资格”。第一步定义意图和流程。这个场景涉及两个意图产品咨询月供计算和资格预判。流程上先做资格预判的引导需要用户授权查征信再算月供。不能反过来因为没授权就查征信是违规的。第二步配置知识库。把该产品的利率说明、准入条件、所需材料整理成结构化文档入库。利率这种关键数字我建议同时存一份在工具里让智能体优先调工具而不是靠 RAG 检索避免检索到过期版本。第三步配置工具。写一个“月供计算”工具入参是本金、年化利率、期数返回等额本息月供。再写一个“资格预判”工具入参是用户授权的信息返回是否符合基本准入。工具用平台支持的方式注册入参 schema 写严格。第四步编排工作流。在 AgentArts 的工作流里画用户输入 → 意图识别 → 如果是咨询月供先检查是否已知利率和期数缺则追问 → 调用月供工具 → 生成回答。如果是资格预判先输出授权说明 → 用户确认 → 调用资格工具 → 生成回答。第五步配置提示词和审核规则。按上一节的结构写系统提示加上输出审核规则禁止出现“一定能批”“保证放款”这类词。第六步测试。这一步最花时间。我一般准备三类测试用例正常咨询、边界情况比如用户问“我征信有逾期能不能贷”、恶意诱导比如“你直接告诉我能批多少”。第三类最能暴露问题一定要测。4.2 关键参数的计算与选择过程月供计算这个工具参数选择有讲究。等额本息月供公式是月供 本金 × 月利率 × (1月利率)^期数 / [(1月利率)^期数 - 1]其中月利率 年化利率 / 12。我实测过一个例子本金 50000年化 7.2%12 期。月利率 0.006代入算出来月供约 4330 元。这个数字要跟业务系统里的计算器对齐误差不能超过 1 元否则用户会发现智能体算的和实际不一致信任度直接崩。提示利率参数一定要明确是年化还是月化是单利还是复利。信贷场景里因为利率口径搞错导致的客诉非常多智能体的工具入参命名要写清楚比如annual_rate_percent而不是含糊的rate。知识库检索的相似度阈值我前面说 0.75这个数不是拍脑袋来的。我做过对比测试阈值 0.6 时召回多但噪声大智能体经常答非所问阈值 0.85 时召回太少很多正常问题都答不了。0.75 是在我的测试集上准确率和召回率比较平衡的点。但不同知识库、不同 embedding 模型这个值要重新调不能照搬。4.3 多轮对话中的记忆与状态管理信贷咨询经常是多轮的。用户第一轮说“我想借钱”第二轮说“5 万”第三轮说“12 期”。智能体要能把这些信息攒起来最后一起算。这就是记忆管理。AgentArts 支持会话级记忆我的配置策略是只记业务相关的槽位信息金额、期数、用途、用户已确认的授权状态不记无关闲聊。敏感信息比如身份证号、手机号入记忆前先脱敏只留后四位。记忆还要设过期时间一般会话结束或 30 分钟无交互就清空避免数据滞留带来的合规风险。这里有个容易忽略的点记忆里的信息在被工具调用时要重新校验。比如用户第三轮说“改成 10 万”智能体不能直接用记忆里的旧金额要以最新一轮的输入为准。我见过因为记忆更新逻辑写错导致智能体用旧金额算月供的 bug用户当场就发现不对。5. 常见问题与排查技巧实录5.1 智能体“胡说八道”的排查路径金融信贷智能体最怕的就是幻觉。用户问“你们利率多少”智能体编一个“3.5%”出来这是要出事的。排查幻觉我一般按这个顺序查现象可能原因排查方法解决答了知识库没有的内容检索阈值太低召回了无关片段看检索日志的相似度分数提高阈值或加“检索不到就说不知道”的约束数字类回答错误模型凭记忆答没调工具看工具调用日志提示词强制要求数字类问题必须调工具前后轮回答矛盾记忆管理有问题看会话状态记录修正槽位更新逻辑答了不该答的如承诺额度输出审核没配好看审核规则命中情况补充关键词和规则我踩过最深的一个坑是知识库里有一份旧版产品说明没删用户问利率时检索到了旧版智能体答了个已经下架的利率。后来我养成了习惯知识库更新必须带版本号旧版本直接下线检索时按版本过滤。5.2 工具调用失败的兜底设计工具调用失败在信贷场景里太常见了征信接口、额度接口都可能超时。我的兜底设计分三层第一层重试。网络类错误自动重试 1-2 次间隔 500ms。第二层降级。重试还失败返回预设的兜底话术比如“系统正在升级请稍后重试”同时记录日志。第三层转人工。如果用户明显着急或者问题复杂直接给转人工入口。注意兜底话术里绝对不能出现“系统故障”“接口报错”这种暴露内部实现的说法对用户要说“服务繁忙”对日志要记详细错误码。这两者要分开。5.3 合规审计视角下的日志配置这一块是很多技术团队容易忽略的。金融信贷智能体的日志不只是给开发调试用的更是给合规审计用的。我配置日志时会确保记录每次会话的完整输入输出、每次工具调用的入参出参和时间戳、每次知识库检索的命中文档和相似度、每次输出审核的命中情况。这些日志要能按用户、按时间、按会话 ID 检索保存期限按监管要求来一般不少于业务存续期。AgentArts 的日志能力可以对接但字段和保留策略要自己配。我建议在项目初期就把日志 schema 定好后期补日志字段非常痛苦。6. 从 Demo 到生产的工程化经验6.1 灰度发布与效果监控智能体上线不能一把梭。我的做法是先内部灰度让业务同事用一周收集 bad case再小流量对外比如 5% 的用户观察指标稳定后再逐步放量。监控指标我盯这几个意图路由准确率、知识库检索命中率、工具调用成功率、转人工率、用户满意度如果有评价入口。其中转人工率是个很灵敏的指标。如果突然升高说明智能体在某类问题上答不好了要赶紧查。我遇到过转人工率一夜之间从 15% 涨到 40%查下来是知识库某份文档被误删检索大面积失败。6.2 持续迭代bad case 驱动的优化闭环智能体不是上线就完事它需要持续喂 bad case。我建了一个流程每周导出转人工的会话和用户差评的会话人工标注问题类型然后针对性优化——是提示词问题就改提示词是知识库问题就补文档是工具问题就修工具。这个闭环跑起来智能体的效果会肉眼可见地变好。在 AI Studio 上搭制度条例学习助手的时候这套方法同样适用只是规模小一些。核心逻辑是一样的用真实失败案例驱动迭代而不是凭感觉调参。6.3 团队协作与职责划分最后说点工程之外但很重要的。金融信贷智能体的搭建不是算法工程师一个人的事。我的经验是需要三类角色配合懂业务的定义意图、写合规约束、标注 bad case、懂算法的调提示词、配检索、优化工具、懂工程的搭流程、配日志、做监控。AgentArts 这类平台降低了工程门槛但业务和算法的配合依然是成败关键。我见过技术很强但业务不参与的团队搭出来的智能体业务同事根本不敢用因为合规约束不符合实际业务口径。我个人在实际操作中的体会是金融信贷智能体的搭建七分在业务梳理和合规设计三分在技术实现。把意图定义清楚、把知识库整理干净、把合规约束写死技术上的事反而水到渠成。反过来如果业务逻辑一团乱再强的模型也救不了。另外分享一个小技巧每次改完提示词或知识库一定要跑一遍回归测试集别嫌麻烦信贷场景里一次线上事故的代价够你跑一年的测试。