1. 金融信贷场景下的AI智能体，到底该怎么做
先说结论：我最近在华为云上用 AgentArts（智果）完整跑通了一个金融信贷场景的AI智能体项目，从需求拆解、智能体设计、数据接入到最终的可视化编排和调试，整体体验下来，这套平台解决的核心问题不是“能不能做出一个聊天机器人”，而是“怎么把大模型真正嵌进一个有严格规则、有数据隔离、有合规要求的业务流里”。
做金融信贷的都知道，这个领域和通用问答完全不一样。客户问“我能不能贷款”，背后牵扯的是客户资质校验、反欺诈规则、额度计算、还款能力评估、贷后催收话术合规性等等。过去这些逻辑散落在多个系统里：CRM 里有客户信息，风控系统里有评分卡和黑名单，核心系统里有额度和放款记录，催收系统里有催收策略。想让大模型直接回答这类问题，它既拿不到数据，也不敢保证回复合规。AgentArts 解决的就是这个衔接层的问题：让大模型只负责理解意图、拆解任务、组织对话，具体的数据查询和规则判断全部通过工具调用和插件完成，最后再把结果组织成自然语言回复给用户。这套思路，其实就是业界常说的“能思考、能行动的智能体”，而不是一个只会生成文本的模型接口。
这篇笔记我会把整个实战过程完整拆开，从智能体的设计思路、工作流编排方式、工具配置细节，到我在调试过程中踩过的坑和排查方法，全部记录下来。适合正在做金融信贷领域大模型应用的人参考，也适合刚接触 AgentArts、想理解智能体工程化落地逻辑的开发者阅读。我不讲官方文档里那些套话，只讲实际跑起来会遇到的问题。
2. 整体设计与平台选型：为什么选 AgentArts 做信贷智能体
2.1 信贷智能体与传统对话机器人的本质区别
先想清楚一个基础问题：信贷场景的智能体，难点到底在哪里。如果只是做一个“贷款产品介绍机器人”，那任何大模型套个 API 都能做，但实战项目绝对不是这个目标。我这次定的目标是做一个“贷前咨询与预审批助手”，用户可以在对话里表达自己的需求，比如“我想贷 20 万，分 3 年还，月收入大概 1.5 万，能不能贷”，智能体需要完成的任务包括以下四件事。
第一，理解用户输入中的关键信息，也就是通常说的意图识别与实体抽取。这里要抽取的不是简单的“时间”“地点”，而是带有金融语义的字段：贷款金额、期限、收入水平、是否有抵押物、征信预期状况等。第二，调用风控接口或查询静态规则表，判断客户是否满足准入条件，比如年龄是否在 18 到 60 岁区间、是否有当前逾期记录、是否命中黑名单等。第三，根据不同的结果分支，走不同的对话策略：准入通过就继续下一步，不满足则说明原因，条件模糊就引导用户补充信息。第四，所有回复必须符合合规要求，不能出现“包过”“百分百下款”这类违规话术。
这四件事如果全部写在提示词里，让大模型自由发挥，结果一定不可控。正确的做法是把它们拆解成不同组件：意图理解用大模型，规则判断用代码或插件，额度试算用公式计算，话术合规用固定模板约束。AgentArts 的多智能体编排能力正好支持这种拆法，这也是我选它的核心原因。它有完善的画布式编排界面，可以创建多个职能不同的智能体子模块，再通过逻辑连线把它们串成一个完整流程。
2.2 AgentArts 核心概念：工作流、插件、知识库、多智能体协作
在动手之前，先梳理一下 AgentArts（智果）里的几个核心概念，避免后面做的时候混淆。工作区里最基础的单元叫“应用”，一个应用就是一个完整的智能体服务，可以发布为 API 或对话界面。应用内部由四类组件构成。
工作流是核心编排逻辑，可以把多个步骤串联起来，步骤之间支持条件判断、循环、并行执行，类似低代码平台里的流程编排。插件负责工具调用，包括 HTTP 请求、数据库查询、函数计算等，信贷场景里最常见的插件类型就是“查询客户信息”和“调用风控规则引擎”。知识库用于挂载静态文档，比如产品说明、利率表、催收合规话术规范，大模型在生成回复时会先检索知识库内容，再结合检索结果作答。多智能体编排则允许一个应用内部创建多个智能体角色，比如一个负责资格审查，一个负责产品推荐，一个负责话术合规校验，各自有独立的系统提示词和工具权限，由主流程统一调度。
用一句话概括这个架构：大模型是大脑，负责思考；插件是手，负责做事；知识库是参考书，负责提供资料；工作流是骨架，负责把思考、做事和查资料按照业务逻辑串起来。信贷场景之所以适合这种架构，是因为它的每个环节都有明确的输入输出，而且对准确率要求极高，不能容忍大模型自由发挥。
2.3 几个关键选型决策与理由
这里有三个决策需要展开讲，因为很多人在做类似项目时容易在这些环节走弯路。
第一个决策是模型选择。AgentArts 平台内部可以配置多种大模型，包括华为盘古系列，也可以接入第三方模型。做信贷场景我不建议在初期追求最强智能的模型，反而应该优先考虑可控性。模型越强，自由发挥空间越大，越容易脱离预设规则。我这次选择的是盘古的对话模型，不是因为它的通用能力最强，而是因为它和平台自身的函数调用、结构化输出能力配合最顺畅，在把结果映射成固定 JSON 结构时出错率更低。
第二个决策是“规则优先，模型兜底”的原则。在信贷准入这类涉及资金安全的环节，我坚持用传统代码逻辑来判断，比如年龄、逾期次数、黑名单命中，这些全部写成插件函数，由工作流直接调用。大模型只负责两件事：把用户的原话解析成结构化参数，把系统的结构化结果转换成亲和力较强的回复文本。这样即使模型偶尔理解错了，也不会直接导致错误授信。
第三个决策是数据接口的封装方式。信贷系统内部的数据接口一般不会暴露成公网 HTTP API，AgentArts 提供了通过函数计算或私有网络连接内部服务的能力。我用了一个简单稳妥的做法：把客户名单和还款记录整理成标准化的 CSV 文件，挂在对象存储上，插件先读取文件再根据客户 ID 进行过滤查询。这种做法的好处是开发成本低、便于联调，在真实生产环境替换成数据库或内部 API 也只改插件内部逻辑，不影响上层工作流。
3. 从0到1搭建信贷智能体的完整实操
3.1 环境准备：账号、服务开通与基础资源创建
这部分看起来很简单，但实际踩坑不少，我按顺序梳理一遍。
第一步，在华为云官网完成实名认证并开通账号。如果你是企业用户做信贷项目，强烈建议使用主账号创建 IAM 子账号来操作，不要在主账号下直接开发。原因是 AgentArts 在调试过程中可能会创建多个临时资源，子账号隔离可以避免误操作影响其他业务；同时后续发布上线时，也便于通过 IAM 策略限制子账号的权限边界，让开发环境和生产环境分开。这一步对金融项目尤其重要，很多人图省事跳过，后面权限审计的时候补流程会非常痛苦。
第二步，开通 AgentArts 服务。在控制台搜索“AgentArts”或“智果”，进入产品页后点击“开通”。开通过程会要求你选择运行区域，我建议选择和业务数据所在区域一致的区域，可以降低跨区域网络延迟。开通之后，在控制台创建一个工作空间，给它命名，比如“信贷智能体实战”。工作空间里后续创建的所有应用、知识库、插件都会以资源形式挂在这个空间下。
第三步，配置模型服务。AgentArts 的对话能力需要依赖大模型服务，你必须先在 ModelArts 或云模型服务里开通并获取推理端点。这里有一个关键参数需要注意：推理端点有个“上下文长度”和“最大 token 数”配置，信贷智能体中用户输入可能包含大量数字信息和金额描述，我默认设置的是上下文 8192、最大输出 2048，实测下来对于这种结构化任务完全够用。如果你的对话里需要拼接很长的风控结果明细，可以适当调大输出上限，但要注意响应耗时也会相应增加。
第四步，准备数据源。我刚才提到用对象存储挂 CSV 文件，这里具体说一下文件格式。我建了两份表：第一份是客户基础信息表，字段有 customer_id、name、age、monthly_income、has_overdue、blacklist_flag；第二份是产品参数表，字段有 product_name、min_amount、max_amount、min_term_months、max_term_months、annual_rate。之所以要把产品参数独立成表，是因为后续做额度试算时需要频繁查表，独立表便于维护利率调整。CSV 文件上传后，在对象存储里记录它的访问路径，后续配置插件时会用到。
3.2 创建一个基础智能体应用，理解对话闭环
环境准备好之后，我开始创建第一个应用，这个应用先不做复杂流程，只跑通“用户提问—模型理解—系统回复”的最小闭环，验证平台链路是否通畅。这里我记录了完整的操作路径。
在 AgentArts 工作空间内点击“创建应用”，应用类型选择“对话型应用”，名称填“信贷咨询助手”。创建完成后进入应用编排界面，左侧是组件面板，中间是画布，底部有调试输入框。先不改任何配置，直接运行默认的空应用，在调试框输入“你好”，看它是否正常回复。这个步骤的作用是确认模型服务连通正常，如果这一步就报错，多半是模型服务注册或区域配置的问题，需要回去检查前面那几个环节。
通过最小闭环后，我给应用配置系统提示词。提示词的写法对信贷场景来说很关键，它决定了模型的口径，我分享一个经过实测有较好效果的版本：
你是一名银行的信贷产品咨询与预审批助手。你的职责是：根据客户提供的贷款需求，提取关键信息，结合系统工具返回的准入结果和产品参数，给出专业、合规、友好的建议。你只能回答与贷款咨询相关的问题，对于与贷款无关的问题，请你礼貌告知客户你无法回答。你的回答必须遵守以下规则：不得承诺贷款一定成功；不得使用"绝对""保证""百分百"等绝对化用语；对于利率、期限等信息，必须以系统工具返回或知识库中的内容为准，不得自行编造。当客户提供的信息不完整时，你需要列出缺少的字段并向客户确认。写好提示词后，再测试一轮：输入“我想贷款”，观察模型是否按提示词的要求追问补充信息。如果它没有追问而是直接给建议，说明提示词中的约束未被模型充分遵循，我会在工具调用阶段通过强制参数校验来兜底。
3.3 用插件把“真实数据查询”接入智能体
最小闭环跑通后，下一步就是接入真实查询能力，这是整个项目最重要的一环。如果智能体只能对话、查不到真实数据，那它就是空中楼阁。AgentArts 的插件能力在左侧组件面板里的“插件”分类下创建。
我创建了两个插件：一个是“客户信息查询”，一个是“产品参数查询”。先做“客户信息查询”插件，类型选择“函数计算”。在函数代码里，我用 Python 写了一个通过客户 ID 读取 CSV 并返回匹配行信息的函数。核心逻辑很简单，但我有两个建议值得借鉴。
第一个建议是输出格式强制用 JSON 并定义严格的字段类型。插件返回值会给到大模型，如果字段名含糊，模型在生成回复时容易误解。我定义的返回结构是：{"customer_found": true, "age": 35, "monthly_income": 15000, "has_overdue": false, "blacklist_flag": false}。customer_found这个字段非常关键，它告诉流程客户是否存在，存在才继续校验，不存在则直接走“无法查询到您的信息，请核对客户编号”的错误分支。
第二个建议是插件里不准许模型自主脑补参数。用户可能不会一次说全客户 ID，插件接收参数时如果为空就返回特殊错误码，由上层工作流处理，而不是让函数返回一个低质量的默认值。这样即使模型解析信息出错，也不会影响结果准确性。
产品参数查询插件的逻辑更简单，根据产品名称或贷款金额范围，从产品参数表里匹配最合适的产品。匹配规则我用的是“最小可满足金额优先”策略：如果用户要贷 20 万，先过滤最低额度小于等于 20 万的产品，再从中选择利率最低的那一个。这样有两个好处：利率低的产品对客户更有吸引力，也体现了信贷咨询服务中“以客户利益优先”的原则。
3.4 多智能体编排：让不同角色各司其职
当基础插件就绪后，我开始做区分度更大的设计：使用多智能体编排，在应用内部创建两个子智能体角色。
第一个叫“资格审核员”，它的系统提示词强调：只负责核对客户基本准入条件，包括年龄范围、逾期情况、黑名单状态，不负责讲产品；输出结论时，必须明确返回一个布尔值变量“资格是否通过”以及不通过的具体原因。第二个叫“产品推荐官”，它的职责是根据客户需求和产品参数表，推荐合适产品并计算预估还款额，但它的计算必须依赖系统返回数据，不能凭空生成。
为什么要把这两个角色拆开而不是让一个智能体顺路做完？核心原因是审计和可观测性。在信贷场景，领导层或合规部门一定会问：“这个客户为什么被拒？是哪个环节判断的？”如果都在一个模型回复里，你很难追溯。拆成两个子智能体后，工作流执行日志可以清楚记录：资格审核员基于哪些参数得出了拒绝结论，产品推荐官看到了哪些产品数据。每个环节的输入输出都可追踪，这才是企业级应用该有的样子。
编排方式是在画布上把用户输入先传给“资格审核员”，其输出接到一个条件分支节点。分支条件判断：如果资格通过，则跳到“产品推荐官”；如果拒绝，则直接触发拒绝话术分支，不再进入产品推荐环节。实际操作中，条件分支的输入参数要选择“资格审核员”返回 JSON 里的approval_status字段，类型是字符串，值可能是approved或rejected。这个分支判断用工作流的“条件判断”节点完成，不需要写代码，画布上点几下就行。
3.5 知识库挂载与合规回复约束
有了前几个环节，智能体已经能查数据、做判断了，真正的“金融味道”还需要知识库支撑。我在应用里挂载了一个知识库，里面放了三类文档：信贷产品说明书、利率与费用一览表、合规话术红线清单。这里单独说一下第三类文档为何重要。
金融消费者保护的要求越来越严格，回复时必须避免夸大宣传，不能使用误导性表述。我把常见违规话术整理成清单，比如“不用还利息”“无视征信”“百分百放款”“最低利率起”这类表达，全部标记为红色禁止项，并写明合规替代说法。知识库挂载后，模型回答问题时优先检索相关文档，再结合检索结果生成回复。实测下来，这种方法确实能明显降低模型自行编造话术的概率，因为知识库里提供了现成的规范表述，模型更倾向于参考。
但有一点必须讲清楚：知识库是提升合规率的辅助手段，不能作为唯一防线。我在工作流的最后一步又加了一个“合规检查”的确定性规则节点：对模型输出的文本做敏感词匹配，如果命中绝对化用语词表，系统会拦截该回复并返回预设的兜底话术。这个兜底设计成本低，但关键时刻救了我好几次，因为模型偶尔还是会绕开提示词输出一些激进表述。
4. 工作流完整实操：从用户输入到业务结果的全链路演示
4.1 完整工作流节点设计与连线逻辑
在对每个组件都有清晰认知后，我设计了一个覆盖完整业务场景的工作流，这里把每个节点和它们的功能说明列出来，你可以直接参考。整个流程从用户输入开始，到最终回复结束，一共经过 7 个主要环节。
第一环节“用户输入”是入口节点，不需要额外配置，用户的对话内容自动传递给下一节点。第二环节“主智能体意图分类”，这里我设置了三个意图：贷款咨询、进度查询、其他。意图分类的提示词要求模型输出一个要素：intent_type。第三环节“参数抽取函数”，当意图为“贷款咨询”时，走这个节点，抽取用户输入中的金额、期限、收入、有无抵押物字段。第四环节“条件分支”分两路：抽取成功进入“资格审核员”，抽取信息不完整进入“追问补全”。第五环节“资格审核员”，调用客户信息查询插件，并根据准入规则返回approval_status。第六环节“资格审核结果判断”也是条件分支：approved走“产品推荐官”，rejected走“拒绝话术节点”。第七环节“产品推荐官”调产品参数查询插件，计算推荐产品与预估月供，生成自然语言回复。如果用户意图是“进度查询”或“其他”，则分别走对应分支，甚至直接回复无法处理并建议转人工。
这个工作流结构看起来不复杂，但每一环都有明确的数据传递契约。做编排时一个容易出问题的点是：节点的输入参数名称必须严格等于上一个节点输出 JSON 里的字段名，如果大小写不一致或字段有额外空格，条件判断就会直接失败。我建议每个环节都在画布上用测试数据验证一次输出结构，确认都符合预期后再连下一环节，避免最后整体排错时不知道问题出在哪一环。
4.2 额度试算与还款参数计算
“产品推荐官”节点除了给出产品建议，还有一个很受用户关注的能力：估算每月还款额。这个计算如果让模型自己算，它大概率算不清楚，因为等额本息公式涉及年利率转月利率、期数次方等运算。正确做法是在插件函数里实现计算逻辑，传入参数：贷款金额、年利率、期限月数，返回每月还款额和总利息。
我用的等额本息公式是：月供 = 贷款本金 × 月利率 ×（1 + 月利率）^n / [（1 + 月利率）^n - 1]，其中 n 是还款期数，月利率 = 年利率 / 12。这里有一个隐藏参数值得注意：年利率在 CSV 里是百分数，比如 6.75 表示 6.75%，计算时必须先除以 100 再除以 12，否则结果会差 100 倍。我最初测试时发现计算结果异常偏高，排查了几分钟才意识到接口返回的是 6.75 而不是 0.0675，这是个非常容易忽略的问题。计算完成后，产品推荐官拿到月供结果，还要带上“预估”字样，强调最终利率和额度以银行审批结果为准。
4.3 模拟真实用户对话，跑一遍全流程
工作流配置好后，我拿几组典型的用户输入做联调测试，这里截取其中一组最有代表性的过程。
用户输入：“我今年 32 岁，月薪 1.2 万，想贷款 10 万，分两年还，能帮我看看合适的产品吗？”这个输入里包含了完整的抽参要素：年龄、收入、金额、期限。参数抽取函数成功识别出贷款金额 100000、期限 24 个月、月收入 12000。接着流程进入资格审核员，它调客户信息查询插件，假设查到该客户 has_overdue 为 false，blacklist_flag 为 false，年龄 32 在 18 到 60 范围内，于是返回approval_status: approved。条件分支走向产品推荐官。
产品推荐官拿到贷款金额 100000、期限 24 个月后，查产品参数表，匹配到一款年利率 7.2% 的产品。调用还款计算函数，得月供约 4488 元，总利息约 7712 元。最终模型生成的回复是：“根据您提供的信息，您初步符合我们的准入条件。为您推荐‘优享贷’产品，贷款金额 10 万元，期限 24 个月，参考年利率 7.2%，预估每月还款额约 4488 元。最终审批额度与利率以银行审批为准，如需继续申请，请补充您的常用联系方式和单位信息。”
这组测试通过后，我又测了几组异常场景，比如输入“我想贷款”只有意图没有参数，验证流程是否会走追问分支；输入“我 1 个月能赚 5 万，能贷多少全部贷出来”这种意图参数混杂的语句，验证抽取是否准确。整体下来，工作流在参数完整情况下的通过率很高，但残缺输入的处理还有优化空间，这也是下一节要讲的重点。
5. 常见问题与排查技巧实录
5.1 用户输入信息不完整，流程卡在抽参环节怎么办
这个问题几乎必然遇到。用户不会像测试人员一样把参数一次说全，最典型的场景是只说“我想贷款”，或者只给金额不给期限。我在最初版本里，抽参节点输出为空时，整个流程会直接报错。后来我在抽参节点后面加了一个“完整性检查”分支：检查金额和期限是否都有值，如果任一为空，就生成一个追问回复，列出缺少的字段，例如“请问您希望贷款的期限是多久呢？目前还缺少贷款期限信息。”这个追问的设计依赖模型从用户之后的回答里补参，所以追问话术必须明确指出缺失项，不能笼统地说“请补充信息”。实测中，大多数用户会顺着追问回答，两次以内即可补齐参数。
一个进阶的技巧：追问节点不要只做一次，可以设计最多三次追问循环，并记录追问次数。如果连续三次仍未补全，就转人工客服。信贷场景尤其忌讳反复追问导致客户体验下降，设置循环上限是必要的。
5.2 模型返回结构不符合预期，条件分支走错
条件分支是工作流里最容易出问题的位置。我遇到过这么一次：资格审核员在对话里明确说“该客户符合条件”，但分支还是走了拒绝路径。排查发现，模型在返回approval_status时，有时输出的是approved，有时则在一个句子里顺带描述了整体结论，遗漏了专用字段。原因是提示词对输出格式的约束不够严格。
我要专门强调：在 AgentArts 里，子智能体的输出不一定天然是结构化 JSON，你需要启用“结构化输出”模式或在提示词里明确要求只输出 JSON 对象。如果平台支持输出模板设置，建议直接拖一个 JSON Schema 模板，把所有字段类型固死。画面里能选“对象输出”就不要让对方自由文本输出，这一步不能省。加上约束后，我再也没遇到过字段值缺失的问题。
5.3 插件调用报错：密钥失效与参数传递错误
插件调用报错是排障中最耗时间的环节。我遇到的头号原因是环境变量中的访问密钥过期。函数计算服务在调用对象存储里的 CSV 时，需要临时密钥或长期密钥，密钥过期后表现不是直接报“密钥无效”，而是出现“运行时异常：获取对象元数据失败”这类模糊提示。排查这类问题的效率方法：先在插件测试面板直接运行该函数，输入一个测试参数，看函数本身是否通过；如果函数通过，问题就在上层传参；如果函数报错，再去看日志里的具体异常类型。不要把时间浪费在工作流界面里反复测，直接从底层往上一层一层定位。
第二个常见原因是参数类型不匹配。上层工作流传入的金额可能是字符串“100000”，而函数签名要求的是整型，在类型不匹配时有的运行环境会自行转换，有的会直接抛异常。同行之间调试这类问题多采用一个约定：所有插件函数内部自行加一层类型强转，入参统一先转字符串，再根据业务字段转成相应类型。
5.4 回复质量不佳或合规风险较高，快速调优方向
如果你测试后觉得智能体回复太死板，或者反过来太飘，给出几条快速调优的方向。
方向一，调整模型温度参数。AgentArts 模型服务配置里有 temperature，默认值偏高时模型更自由、更发散。信贷场景我直接把温度调到 0.2，这能让回复明显更稳定，更贴合预设规则。方向二，优化提示词中的“角色限定”措辞，把“你可以”改成“你必须”。方向三，扩充知识库里的“常见问题模板”，把高频问题的标准回答模板放进去，模型检索到模板后会优先模仿。方向四，如果是合规问题，把违规词表在合规检查节点里补充完整，这是最后一道防线。
5.5 信贷智能体性能观察与优化建议
最后说一下性能表现。在我这个配置下（盘古对话模型、单工作流、两个插件），单次完整对话链路端到端延迟大约在 2 到 3 秒，其中资格审核加产品推荐两个子智能体串联的部分占了大头。如果你对延迟敏感，有几个调优思路：尽量减少工作流里的串行模型调用次数，资格审核和产品推荐可以尝试并行处理，前提是两个节点真的互不依赖；调低模型最大 token 数量也会小幅降低生成时间，因为生成是逐 token 的；把插件函数和模型部署在同一个区域内也可以减少网络往返。
资金审批或正式授信这类高价值决策场景中，我不建议完全让智能体做出最终授信决策。我的做法是智能体完成“预沟通”与“信息收集整理”，输出结构化客户画像和推荐结论，人工坐席复核后再进入正式流程。这种人和智能体协作的模式，既提升了效率，又给风险留出了人工把控空间，是金融场景落地更稳妥的路径。
6. 写在最后：一点个人体会
整个项目做下来，我最大的一个体会是：AI 智能体在金融信贷场景的落地，难点从来不是大模型本身，而是你怎么把模型“关进笼子里”做流程化的事情。AgentArts 这类平台的价值在于，它提供了把模型、工具、知识、流程组合在一起的工程化环境，你可以像搭积木一样把业务规则逐步落到画布上。
再分享一个小技巧：做这样的项目时，每次改完提示词或工作流，我都会保留一个版本的完整截图和测试记录，标注“为什么改、改了之后效果变化”。这个习惯在后续排查问题时帮了我大忙，因为智能体是个复杂系统，有时候过了一周你根本记不清当初某个分支条件为什么那么连。好记性不如烂笔头。信贷场景尤其如此，任何变更都要能回溯、能解释。
如果你正准备在金融或者类似强规则行业里做智能体应用，我建议你按我这套思路，先把一个最小闭环跑通，再逐步加复杂度。先把数据查得到、规则判得准、话术说得合规这三件事做好，再谈其他花活。
