基于华为云AgentArts的信贷AI智能体实战指南：从编排到上线

在信贷行业做AI落地，最大的感受不是模型不够聪明，而是场景里大量问题已经"标准化"了，却依然靠人一次次回答。华为云智果 AgentArts 这套智能体工具链，我今年在金融信贷项目上实际跑通了一条从角色定义、知识库挂载、工具调用到评测上线的链路。这篇文章想把这套经验原原本本写清楚，给后面准备搭信贷 AI 智能体的同学一条参考路径。不管你是刚接触到 Agent 概念、打算做POC验证，还是已经搭过一两个Demo想往生产环境推，这篇实战笔记应该都能给出一些有用的判断。

金融信贷场景有个很特殊的地方：它不是单纯追求"答得对"，还要答得合规、答得有边界。同一个问题，对普通用户和对信贷审核员的回答口径完全不一样。如果只是接一个大模型做闲聊式问答，大概率会翻车。真正能落地的形态，是把知识库、业务规则、内部API串成一个可以上下班接力的"数字员工"——这正是 AgentArts 这类智能体平台想解决的。下面我把完整过程拆开讲。

1. 信贷客服和风控初审被大量重复问题淹没时，我决定做个智能体

先还原一下业务背景。我们当时做的是消费信贷产品的贷前辅助，客户经理和客服每天要面对几十种重复询问：授信额度为什么只有这些、资料补件该怎么补、征信查询记录里哪几条会影响审批。这些问题答案都写在产品手册、审批指引、监管要求和过去的客服话术里，但散落在Word、PDF、飞书文档和内部页面里，真要用的时候还得人肉翻找。

我最初试过用传统对话机器人做意图分类加关键词匹配，效果很一般。原因在于用户问法太灵活，同一个"为什么额度这么低"，背后可能对应收入认定方式、信用评分模型、负债收入比、产品准入门槛四类问题。关键词机器人通常会命中一个最宽泛的答案，然后让用户"找人工"，体验很差。后来换成大模型做端到端的开放问答，虽然理解力上来了，但一个新的问题出现了：模型会一本正经地编造审批规则，比如自己虚构一个"连续三个月信用卡使用率超过70%即拒绝"的规定。这在信贷场景是不能接受的，因为客户可能据此投诉甚至起诉，审核员也可能被误导。

所以真正让我决定用 AgentArts 的契机，不是它比大模型更聪明，而是它能把"模型理解力""知识库可信源""工具执行结果"三样东西拆开再串起来。换句话说，智能体不是靠记忆回答业务问题，而是靠检索业务知识、调用业务接口、执行固定规则来回答。这样即便模型给出的措辞有差异，最终依据仍然落在可控的知识文档和真实返回数据上。

1.1 我们整理出来的信贷场景需求清单

动手之前，我花了两天跟业务方开了三轮需求会，把上线第一期的功能边界圈定成下面这几类：

• 产品与额度咨询：解释产品利率、期限、还款方式、授信逻辑，但不对个案做最终承诺。
• 补件与材料指引：根据客户已提交材料缺失情况，给出补件清单和标准要求。
• 征信报告辅助解读：帮助审核员定位报告中的关键记录，提示可能影响审批的要点。
• 审批规则查询：回答内部制度允许范围内的规则类问题，敏感审核细节支持拒答。
• 额度试算：接入现有试算接口，根据输入的收入、负债、期限计算参考额度区间。

这个清单的用途是给智能体划分"能力边界"。AgentArts 里每个智能体都可以在开场提示词和工作流节点中做权限约束，业务上没有授权的方向宁可直接拒答，也不要让模型自由发挥。我一贯的原则是，信贷智能体最需要的不是"能力上限"，而是"能力下限兜住"。

1.2 传统聊天机器人和 Agent 在信贷场景里的本质差异

我经常拿一个类比解释这件事：聊天机器人像一本智能目录，翻到哪页念哪页；Agent 像一个学徒，手上拿着目录、规则卡、计算器，遇到问题知道先查哪本手册、按哪个流程走、什么时候必须问师傅。

在信贷场景里，这种差异能直接转化为业务结果。传统机器人回答"贷款最长能分多少期"是靠关键词命中；Agent 是先定位到产品参数表，再根据当前产品类型去读对应的分期规则，如果用户还追加一句"45岁能分36期吗"，Agent 可能会再去调用年龄准入校验工具。整个过程链路更长，但每一步都有据可依。AgentArts 的价值正是把这套链路做成了可视化编排和可复用组件，而不是让每个开发者从零实现调度逻辑。

2. AgentArts 平台里必须搞清楚的五个概念，搞清楚才能少走弯路

第一次进 AgentArts 控制台，我有点懵，因为它把大量能力模块铺在左侧菜单里。我后来总结出五个最核心的概念：智能体、组件/插件、知识库、工作流、调测试。如果你还没接触过这个平台，先把这五个概念在脑子里串成一条线：智能体是壳，组件是手，知识库是记性，工作流是日程，调测试是验收。

2.1 智能体编排：低代码画布和代码编排怎么选

AgentArts 提供两种编排形态，一种偏低代码的流程画布，另一种是支持 Python/JSON 的代码编排。我实测下来的建议是：业务链路复杂但分支规则明确时，用流程画布；需要做批量数据处理、循环遍历、复杂条件判断时，用代码编排。

我们信贷额度试算这个能力，最早是在流程画布里拖了六个节点：接收参数、校验输入、调用额度试算API、合并知识库规则、生成解释、格式化返回。业务流程的人和开发都能看懂。但后来要让智能体自动从客户聊天记录中提取月收入、负债、工作单位，再判断这些数据是否可信，再决定是否调用额度试算，节点太多后画布显得很乱，我就把这一段抽出来写成了自定义组件，注册到 AgentArts 的插件中心里，一个节点代替十个节点。

2.2 模型配置：不是所有问题都要最强模型

金融场景对成本敏感，尤其智能体同时服务几百个坐席时，每次调用如果都走最大参数模型，费用会很难看。AgentArts 的模型配置里可以针对不同节点选择不同模型。我的用法是这样的：

这个组合下来，整体成本大约比全链路都使用最强模型低30%-40%，关键是回答质量没有明显滑坡。不过这里有个前提：你需要保证每个节点的输入输出边界足够清晰，不能让弱模型承担它不该承担的推理任务。

2.3 知识库和组件是金融智能体的两条腿

知识库解决的是"知道什么"，组件解决的是"能做什么"。在 AgentArts 里，知识库支持上传文档后自动切片、向量化，然后把检索结果作为上下文注入给模型。这里我必须多说一句：文档本身的质量直接决定智能体表现。你上传一份扫描件和上传一份带标注的 Markdown 版本，效果可能差出一大截。

组件这块，AgentArts 支持接入 API 服务，也支持创建自定义工具。我们内部模拟了一个征信要素查询接口，把征信报告里的核心字段通过 API 暴露给智能体。实际使用时，智能体先判断用户问题是否涉及征信解读，再决定是否调用该组件，拿到 JSON 返回后再结合知识库中的解读口径生成回答。组件的输入参数里我严格定义了枚举值和必填项，比如"查询类型"只能传 personal_summary 或 overdue_record，防止模型乱造参数值。

3. 搭建第一版信贷智能体：角色设定、知识库、工具链是怎么一步步接上的

这一段我尽量按操作顺序说，方便你照着在 AgentArts 上复现。我们的第一版目标很简单：上线一个"贷前咨询助理"，能回答产品问题、补件问题、征信要素解读，并支持额度试算，所有回答不允许超出预设边界。

3.1 第一步：把智能体的角色和人设写清楚

很多人会低估开场 Prompt 的重要性。AgentArts 的智能体配置里有一段"人设与任务描述"，我写的不是一句"你是信贷助手"，而是一段结构化约束：

你是消费信贷产品的贷前咨询助理，服务对象包括客户、客户经理和信审员。 你的任务范围包括： 1. 解释产品利率、期限、还款方式等公开信息； 2. 指导用户完成材料补件和申请进度查询； 3. 基于内部知识库解读征信报告中的关键要素； 4. 调用额度试算API给出参考范围。 严格禁止事项： 1. 不对具体申请结果做出承诺； 2. 不透露审批阈值、拒绝原因中的内部规则； 3. 不引导用户提供虚假材料； 4. 如果问题超出任务范围，请答复“需要转人工处理”。 在回答中，涉及金额、期限、利率的信息必须从知识库或工具返回值中引用，不得自行编造。

这段人设不仅告诉模型该做什么，更关键的是告诉它不该做什么。金融场景里，模型一旦越界，业务就可能投诉到监管层面。我后面在评测阶段专门造了一批"越界问题"来测，比如"我征信有一点逾期，能不能找内部关系消除"，智能体必须拒绝并建议走正常申诉流程。这类要求不写进 Prompt 是肯定不行的。

3.2 第二步：知识库文件准备与切片策略

我把分散在各处的制度文件汇总到一个文件夹里，包含产品手册、贷前审批指引、征信报告解读规范、常见拒件原因说明、客服话术模板。在上传到 AgentArts 知识库之前，重点做了两个处理：一是把 PDF 转成结构化 Markdown，保留标题层级和表格；二是给文档打标签，比如 docs/loan_product.md、docs/credit_review_guide.md，这样智能体在检索时能按照标签缩小范围。

切片参数我调了几轮。最开始用默认的 512 字符切片，效果不好：很多规则条款被切成两半，检索时只命中前半句，导致回答明显缺上下文。后来改成按语义段落切片，切片重叠设置为 50-100 字符，明显感觉引用的完整性提升了。这里没有固定最优值，只能拿你自己文档里的典型问题反复测。我测下来 512 切成金融条款时太碎，800 到 1200 字符一“章”更合适。

3.3 第三步：把内部接口以工具形式接入 AgentArts

我们当时在 AgentArts 的自定义组件里花了最长时间的就是接口接入。原因很现实：内部系统接口字段命名跟平台默认的 REST 风格不太一样，需要做一层参数映射。我们的额度试算接口长这样：

POST /api/loan/estimate { "annual_income": 360000, "monthly_debt": 9000, "age": 32, "city_level": "1", "loan_term_months": 24 }

返回结果是一个 JSON 对象，包含可借额度区间和建议利率区间。我把这个接口封装成一个 AgentArts 工具后，还有一个头疼问题：模型不会生成合法的 city_level 枚举值，有时候从用户对话里提取到的城市是"北京"，但它直接传成"北京"而不是代码"1"。解决办法是在工具的输入描述里写清楚枚举映射：城市等级 1 代表一线城市，2 代表二线，3 代表三线及以下。我还添加了一个前置处理节点，把城市名先用规则字典转换成城市等级，再交给试算接口。这个处理放在 Agent 之前的意图判定阶段，模型只负责做实体抽取，转换交给代码，稳定性一下就上来了。

3.4 第四步：用工作流把"材料初审"串起来

我们第二期加了一个比较有代表性的工作流：自动解读用户提交的申请材料，按规则返回"材料是否齐备、是否有明显疑点"。工作流里的节点顺序是：解析材料文本 -> 信息抽取 -> 与知识库中的材料清单比对 -> 生成补件建议 -> 如果命中疑点规则，进入人工复核推荐。

这个流程在 AgentArts 里配置成：第一个节点用知识库检索补件标准，第二个节点用模型抽取材料中的身份证号、工作证明日期、收入金额，第三个节点调用代码做日期有效性和金额完整性校验。所有判断里的“硬逻辑”我都没有交给模型去推理，比如日期是否在有效期内、金额是否大于起贷门槛，这些是确定性规则，直接用代码算。模型只做信息抽取和自然语言生成，这大大降低了乱答的概率。

4. 调优阶段最值得记录的：提示词、推理参数和幻觉抑制

智能体能跑通是一回事，跑得好是另一回事。调优阶段我把精力放在三个地方：提示词模板、模型推理参数、幻觉抑制策略。下面是不涉及业务敏感信息但可以直接复用的经验。

4.1 提示词的金融语感：让模型学会"留有余地"

在信贷场景里，AI 的回答风格不能像科技媒体那样笃定，也不能像销售那样激进。比如用户问"我这个条件批 10 万没问题吧"，智能体不能回答"肯定没问题"，而是要回答"根据您的收入、负债和产品规则测算，目前参考额度区间为8-12万元，最终结果以审批为准"。这需要的不是模型能力，而是提示词里明确写了"所有预测性表述必须包含区间、依据和免责声明"。

我在 AgentArts 的人设里加了三条输出规范：

1. 涉及额度、利率、期限等数字结论时，必须同时输出依据或来源；
2. 对审批结果不做确定性预测，使用"参考区间""可能影响因素""建议咨询客户经理"等措辞；
3. 当用户提供的信息不足以判断时，主动提示需要补充哪些材料。

这三条规范看起来简单，但实际跑出来的效果差别很大。没加之前，模型经常自信地给出"综合评分不足，拒绝申请"这种话；加上之后，它更愿意承认需要更多信息，也更愿意引导用户走人工流程，这在金融场景里是加分项。

4.2 温度和 TopP 的调节：信贷场景不能把随机性当聪明

我见过不少人把 temperature 调高到 1.2 拿去生成营销文案，效果好极了，但同样的参数放到信贷智能体上就是灾难。贷款解释类问题，用户需要的是稳定和一致，不是每次换个说法。所以我主流程里的生成节点 temperature 直接调成 0.2-0.3，TopP 调到 0.8 左右。这样在知识库不变的情况下，同一意图的问题得到的是措辞略有不同但内核一致的回答。

对于"综合客户前面多轮对话最终形成总结摘要"这类需要归纳的任务，temperature 可以适度调到 0.5，保留一点表达能力。但任何涉及利率、金额、期限的数字性输出，我仍然坚持用低温度，背后逻辑很简单：数字错了措辞再流畅也没意义。

4.3 幻觉抑制的完整链路，不是一个参数能搞定的

信贷场景里幻觉是个敏感话题。我处理幻觉不是靠"提示词里写别乱编"这种心理暗示，而是靠链路设计。具体分三层：知识库相关性门槛、工具结果强约束、兜底回退策略。

在 AgentArts 的检索参数里，我配置了相似度最低阈值，低于阈值的知识片段不会进入模型上下文。模型如果检索不到相关资料，必须按设置的兜底回答"该问题需要查阅最新的产品指引，我将为您转人工"。工具调用节点则要求模型必须使用真实返回结果生成答案，如果 API 返回异常，不允许模型自己补一个结果。

更细的一层是，我把所有用户问题先做一次"业务意图分类"，命中高风险意图（如承诺审批结果、套取内部规则）时直接跳转到固定话术模板，不经过生成模型。这样等于给智能体装了一个逻辑门，把最有风险的路径直接固化，而不是靠大模型临场发挥。这是我在金融场景里最推荐的做法：能走规则不走模型，能走工具不走记忆。

5. 从POC到生产环境：评测集、灰度发布和线上监控

搭出 Demo 只算完成了一半，真正费时间的是把它推到生产环境。这个阶段我们踩了不少坑，整理下来有三件事最值得讲。

5.1 把历史工单做成评测集，逼着智能体达到 90% 准确率

评测集我建议不要自己编，最好直接拿过去三个月的真实客服聊天记录和工单样本。我们把数据做脱敏处理后，人工标注了六百条测试问题，每条包含：输入、期望回答类型、期望工具调用、是否允许拒答、关键约束。然后在 AgentArts 的调测试平台里批量跑，自动统计意图准确率、检索命中率、回答规范率等指标。

我印象很深刻的是第一批测试，回答规范率只有 72%。出错最多的是"用户问 A，智能体答 A 但字里行间把 B 规则也带出来了"，这种宽泛发挥在金融场景里很危险。我们用这些失败用例反向修正知识库切片和人设约束，来回迭代了三轮，最终目标是至少 90% 的规范率，否则不上线。

5.2 灰度发布和 A/B 对比，别一上来就切全量

AgentArts 的发布功能支持多版本管理，我习惯先发布为灰度版本，只对内部20个测试账号开放。灰度期间除了看功能是否正常，还要盯两件事：一是接口时延，二是用户在真实对话里是否产生新意图但没有被识别。

我们灰度时发现了一个很典型的问题：真实用户会问"如果我妹妹的主贷人，我做共同还款人，会查我征信吗"，这类涉及多人借贷的问题在原有评测集里几乎没覆盖。模型虽然答出来了，但答得模棱两可。后来把这个意图单独增加为一个分类，并从知识库中抽了对应条款。

发全量之前，我偏好做三天左右的 A/B 对比：对照组用原来的纯人工客服，实验组用智能体辅助。主要看客服平均处理时长、转人工率、用户满意度评价。那段时间的对比结果让人松了一口气：平均处理时长降了 26%，转人工率降了 15%，但满意度没有明显波动。说明智能体确实解决了重复问题，同时没有因为答非所问让用户感到被敷衍。

5.3 线上监控和日志审计：金融场景的保命配置

上线后的监控，我在智能体配置里打开了完整的对话日志和工具调用日志。每一个回答、每一次额度试算、每一次知识库检索，都留痕。这不仅是给运维看，更是给合规审计准备的。有一次用户投诉说智能体给了错误利率，我们在日志里还原了完整的检索片段，发现是知识库文档里有一个旧版本产品利率表没被清理，模型检索到了旧数据。这件事直接推动了知识库增加版本号和生效日期字段，检索时优先取时效内版本。

监控指标上，我主要看三类：正常率、工具调用成功率、平均响应时长。工具调用成功率低于 80% 时，多半是接口侧网络或参数问题，我会收到告警去查；回答拒答率突增，通常说明知识库内容不足或分类规则太激进。总之，日志和指标不是为了好看，是为了出事时能自证清白、能快速定位。

6. 实战中反复踩过的坑和后续我可以接着扩展的方向

最后这部分不是完整教程，更像是我在项目里留下的一笔笔记。如果后面有人要做类似场景，希望这些坑能帮你节省几天时间。

第一个坑是知识库切片导致答案"丢尾巴"。尤其是制度文档中一条规则跨多个段落，切片策略没调好时，智能体引用到的内容不完整，于是在结尾补了一句"具体请参考内部制度"，这等于把问题踢回给用户。后来我改用按标题层级切片，并允许检索返回同一标题下的多个相邻片段，问题解决。

第二个坑是工具返回值和模型回答之间的口径不一致。额度试算接口返回的是一个 JSON 数组，里面包含多档方案，模型在生成自然语言时容易漏掉其中一个方案。最后我在工具描述里明确要求"返回所有方案，并按推荐顺序输出"，同时在输出层用一个模板校验是否包含了全部方案数量，不满足就让模型重新生成。

第三个坑是团队多人同时在线调试时，测试资源相互挤兑。AgentArts 的调试并发资源有上限，我们五个人一开在线调试，后进入的人就像在排队。后来养成了"调试完随手关掉调试会话"的习惯，重要测试统一写脚本走批量评测，避免占用在线资源。

我可以继续做的事情也很多。比如把智能体扩展到贷后催收提醒，让它根据用户还款状态生成温和的提醒话术；也可以给信审员做一个"材料初筛助手"，自动读取营业执照、流水文件，提取关键指标并标记异常点；再往后甚至可以跟内部合规系统打通，在智能体回答前先调用合规检查接口做一次合法性校验。这些方向都建立在 AgentArts 这套编排能力上，换汤不换药，只要把知识库、工具、工作流重新组合一遍就能跑起来。

按我自己的体会，做金融信贷类 AI 智能体，最重要的不是模型选得有多新，而是把边界划得有多清楚。AgentArts 给了一个很好的壳，让开发者能把规则、知识、模型和API稳稳地串起来。真正决定成败的，永远是你在业务端做了多少梳理、在测试端做了多少打磨。希望这篇实战笔记能给你一些可复用的思路。