上周用华为云智果 AgentArts 搭完了一个金融信贷场景的 AI 智能体——贷前资质预审与材料核验助手。说实话最开始我以为这又是一个套壳大模型的对话平台但真正上手跑完一轮之后才发现AgentArts 的核心价值不是聊天而是把会思考的模型和能办事的工具在一个画布里真正闭环起来。这篇学习笔记我会完整记录我从平台入门、业务拆解、工作流搭建到实测翻车的全过程也把一些合规和数据安全上踩过的坑一并写出来。无论你是准备华为 ICT 大赛云赛道、想在企业内部快速落地一个带业务动作的 AI 助手还是单纯想弄清楚智能体和普通对话机器人到底差在哪这篇笔记应该都能给你一些可复用的经验。1. 智果 AgentArts 初印象它解决的不只是对话而是业务闭环1.1 AgentArts 到底是干什么的打开华为云智果 AgentArts 的控制台我的第一感觉是熟悉又陌生。熟悉的是里面有模型管理、知识库、在线调试这些常见组件陌生的是它多了整套智能体编排的概念入口排在比较显眼的位置。用一句话概括AgentArts 是一个面向 AI 智能体的一站式开发与运行平台。你可以在上面配置大模型、注册业务工具、挂接知识库然后把它们编排成一个能自主完成任务的智能体。这里的关键词是自主完成任务——模型不再只是回答你应该怎么做而是可以直接调用工具把事做了比如查客户信息、核验材料清单、计算预授信额度最后把结果按业务口径整理出来。我第一次跑通一个最简单的智能体时在画布里拖了四个节点开始节点、大模型节点、工具调用节点、结束节点。流程是用户提问 - 模型判断需要调哪个工具 - 工具执行并返回结果 - 模型根据结果生成回答。整个过程约等于给大模型配了一个工具箱让它自己决定什么时候打开哪个箱子。就这么一个简单的机制已经能处理很多传统对话机器人完全搞不定的事情。我整理了一个概念对照表新人上手前建议先把这个记牢概念说明生活化类比智能体面向一个业务目标、能自主规划并调用工具的 AI 执行单元一个带工具箱的实习生工作流对思考、工具调用、分支判断、结束出口的流程化编排给实习生写的标准作业程序插件 / 工具智能体获取外部能力的接口本质是函数或 API 封装实习生的内线电话知识库将私域文档向量化后供模型检索调用的组件实习生的业务手册这个类比对我理解 AgentArts 帮助很大。智能体平台做的事就是帮我把一个实习生快速培养起来给它接上内线电话工具、塞一本业务手册知识库、写清楚作业流程工作流然后放手让它干活。1.2 为什么需要专门的智能体平台而不是直接调 API很多人会问我直接用大模型 API自己写代码去调工具、做检索不也一样吗这个问题我在学习过程中反复想过答案是一样也不一样。一样的是底层原理——都是让大模型做意图理解和规划然后通过函数调用或工具调用来完成动作。不一样的是工程成本和迭代效率。拿信贷场景举例如果我用裸 API 的方式自己搭我需要考虑模型怎么知道有哪些工具可用、工具的参数格式怎么约定、调用失败怎么重试、知识库怎么切分和召回、提示词怎么统一管理、日志和评测怎么做。这些工作单独拿出来都不难但叠在一起很容易变成一个每天都在补漏洞的工程泥潭。AgentArts 这类平台的价值是把这些能力变成可配置的组件让开发者的精力集中在业务逻辑上。我在 AgentArts 上添加一个客户信息查询工具只需要在插件配置里填好接口地址、入参出参定义和鉴权方式模型就能在需要时自动调用它我想让智能体掌握产品准入规则上传文档后配置好切分策略就能被检索。这些步骤在自研体系里往往要写几百行甚至上千行代码。还有一个容易被忽略的点评测和灰度。自研方案里要搭一套评测集和回归机制需要自己写脚本。AgentArts 内置了智能体评测能力我可以在里面维护一批真实的用户问法每次改了提示词或工具定义之后一键跑回归看指标变化。这个功能在我后面迭代时帮了大忙本地的调试效率至少翻了一倍。1.3 平台的基本编排逻辑AgentArts 的工作流画布是核心操作入口我建议第一次接触的人在动手搭业务之前先花半小时把画布上的节点类型过一遍。主要的节点类型包括开始节点定义用户输入参数和会话初识信息。意图识别 / 大模型节点让模型做判断、生成文本、抽取信息。工具调用节点挂接插件或 API执行具体的业务动作。条件分支节点根据模型输出或工具结果走不同的后续流程。代码节点写少量脚本做数据加工。结束节点定义返回给用户的最终内容。编排逻辑本质上是在模拟一个思考—行动—观察的循环。用户输入进入智能体后模型先思考该干什么如果需要外部信息就调用工具工具执行后把结果返回给模型观察到结果后再继续规划下一步直到满足结束条件。这个模式后来我在资料里看到正式名称叫 ReActReasoning Acting是当前构建能思考、能行动的 AI 智能体的主流范式之一。明白了这一层再看 AgentArts 的界面就不会迷路画布上每一个节点都是在为这个循环服务。2. 信贷场景怎么切先拆业务再谈技术2.1 信贷链路里哪些环节适合智能体金融信贷是天然适合智能体落地的领域但不是什么环节都适合。我一开始的想法很冲动——想把信贷全流程塞进智能体里后来跟有信贷业务经验的朋友聊完才冷静下来。信贷业务链路很长从获客、贷前预审、材料收集、反欺诈、额度测算到审批、签约、放款再到贷后监控、还款提醒甚至催收每个环节的复杂度、合规要求、人工介入程度都不一样。我按三个标准筛选适合上智能体的环节高频、规则相对明确、低合规风险。分析结果如下表信贷环节是否适合智能体原因贷前资质预审与咨询非常适合重复问答多、规则相对标准化、影响面可控材料收集与核验适合流程机械、规则清晰但需注意核验准确性反欺诈初筛谨慎尝试逻辑复杂且涉敏智能体只能做辅助不能做决策额度测算可以辅助公式明确但结果需人工复核不能直接承诺最终审批不适合涉及风险判断和合规责任必须人工决策贷后监控与预警适合线索分类、信息汇总能力强可以大幅提效催收沟通谨慎涉及大量合规约束初期不建议触碰对比下来最适合我练手的场景浮出水面贷前资质预审与材料核验。这个环节业务规则清晰客户经理每天都在做机械性重复工作而且即使智能体偶尔答错也有客户经理在中间把关不会直接触达客户风险相对可控。2.2 我选的切入点贷前预审与材料核验我这次选择的具体场景是贷前预审与材料核验助手服务对象是信贷客户经理而不是C端客户。这个选择帮我规避了很多合规麻烦。业务痛点三个字就能总结完——重复烦。客户经理每天要回答大量重复问题我这个条件能申请吗要准备哪些材料收入证明怎么开同时还要人工核对申请材料是否齐整、是否符合清单要求。材料缺了要在系统里逐项登记再电话通知客户补交来回沟通成本非常高。智能体的目标因此很明确自动回答准入条件、材料要求、利率区间类的常见咨询。根据客户录入的基本信息自动判断初步准入状态通过 / 存疑 / 不通过。对客户提交的电子材料自动核对清单输出缺失项和格式问题。所有结论都带上初步判断、仅供参考、以人工审批为准的限定语。这里我想强调一点智能体的输出边界必须在设计阶段就定死不能让它变成什么都知道的半仙。我在提示词和流程里都做了约束凡是涉及最终审批、额度承诺、利率承诺的内容一律不允许输出直接引导用户联系客户经理。这是金融场景的底线也是我后面避免很多麻烦的根本原因。2.3 把业务目标翻译成智能体任务业务目标明确了接下来要拆成智能体能执行的任务。我在 AgentArts 里把它拆成了四个子任务任务一意图识别——判断用户输入是准入咨询材料核验还是其他问题。任务二信息抽取与准入判断——从对话中抽取收入、年龄、职业、负债等关键信息匹配准入规则。任务三材料清单核验——根据准入子类拉取对应材料清单逐项核验提交材料是否齐全。任务四结果生成与输出——按合规模板生成回复缺失项用结构化列表呈现。每个子任务对应到 AgentArts 里的具体组件意图识别用大模型节点加条件分支准入判断用工具节点查规则库材料核验用插件调用 OCR 和清单比对能力最终回复用大模型节点搭配固定模板。下面是我做的映射表方便后面照着搭业务目标智能体能力AgentArts 对应组件自动回答准入咨询意图识别 知识库检索大模型节点 知识库组件初步准入判断规则匹配 条件分支工具节点 分支节点材料逐项核验文件比对 结果结构化插件节点 代码节点合规回复输出模板化生成 敏感词过滤大模型节点 校验节点拆完这些平台的搭建工作基本变成了一道填空题往画布里拖节点、配置参数、联调工具。3. AgentArts 上的核心搭建过程从画布到跑通3.1 工作流骨架模拟思考—行动—观察循环搭建的第一步是搭工作流骨架。我设计的主流程如下开始节点接收用户文本和可选的客户编号。意图识别大模型节点判断用户输入属于哪类任务输出一个结构化意图标签。条件分支节点按意图标签分流分别是准入咨询材料核验转人工。工具调用链准入咨询分支调用客户信息查询工具和准入规则匹配工具材料核验分支调用材料清单拉取工具和文件核验插件。结果加工节点用代码节点或大模型节点把工具结果整理成统一格式。合规校验节点对输出文本做敏感词和承诺性语句检查。结束节点返回最终回复。这个流程的核心逻辑就是 ReAct 模式的产品化落地。模型在意图识别节点完成第一轮思考然后进入工具调用链每一步执行完的结果都被带回模型上下文模型基于新的信息继续判断——整个过程像一个循环直到走到结束节点。我当时踩的一个小坑是一开始把工具调用设计成一次调用查完全部信息结果发现单个工具接口返回的数据量大而且杂模型反而不容易聚焦。后来我拆成先查客户基本信息再根据结果决定是否查准入规则多了一次调用但每个工具返回的数据都更干净模型生成的结果质量明显上升。这个经验也算是对平台编排方式会影响模型效果的直观验证。3.2 插件与工具编排把查询、核验、测算接进来工具是智能体的手脚在 AgentArts 里配置工具的核心工作是定义参数协议。模型本身不知道你的系统里有哪些函数你需要把每个工具的入参、出参和功能描述写得足够清楚模型才能正确选择并生成规范化的调用参数。我配置了三个核心工具这里展示一个材料清单核验工具的简化参数定义{ tool_name: materials_check, description: 根据客户准入子类核验提交材料是否齐全返回缺失项列表, params: { customer_id: { type: string, required: true, description: 客户唯一编号 }, sub_type: { type: string, required: true, enum: [工资代发, 自雇经营, 公积金贷] }, materials_uploaded: { type: array, items: { type: string, enum: [id_card, income_proof, bank_statement, work_certificate] }, required: true, description: 已上传的材料类型代码列表 } } }配置工具时有两个心得非常关键。第一工具的 description 一定要写清楚什么时候该调用和不调用会怎样。因为模型是靠 description 来选工具的写得太笼统会导致该调的时候不调、不该调的时候瞎调。我把材料清单核验的 description 写成了当用户想确认材料是否齐全、缺少哪些材料时调用如果只是咨询产品本身不要调用此工具实测下来误调用大幅减少。第二参数的 enum 枚举值能有效降低模型的自由发挥空间。比如准入子类我限定为工资代发、自雇经营、公积金贷三个值模型就不会自己发明出第四种。金融场景尤其需要这种约束宁可多花点时间把定义写细也不要让模型去猜。工具调用链跑通之后你还能在平台的调试日志里看到每一步的输入输出这对我排查问题帮助极大。后面第 5 部分会专门讲我用日志挖出的一串翻车事故。3.3 提示词与知识库金融场景的关键约束在 AgentArts 里提示词和知识库决定了智能体的性格和知识边界。金融场景的特殊性在于回复不仅要准确还要合规、口径统一、不带误导性。我写的系统提示词核心内容大致是这样你是信贷预审助理服务对象是银行信贷客户经理。你的职责 1. 只回答与准入资格、材料清单、基础流程相关的问题 2. 涉及审批结论、利率承诺、额度承诺时一律不输出具体数字引导对方走人工审批流程 3. 所有判断必须以初步判断冠名不得使用一定肯定保证等绝对化表述 4. 回答中不得出现任何涉及地域、年龄、性别、职业等维度的负面评价性描述 5. 输出材料核验结果时用列表逐项列出缺失项和补充建议。这套提示词是在一次翻车之后迭代出来的具体细节放到第 5 部分。这里想提醒的是提示词不是一次写好的而是结合真实案例持续打磨出来的。建议把每条提示词都当成代码来维护加版本号配合评测集做回归。知识库方面我上传了三类资料产品准入规则文档按产品线整理每条规则带产品名称和适用客群标签。材料清单说明每个准入子类对应的标准材料目录和格式要求。常见问答对QA把客户经理日常被问的高频问题整理成标准问答。知识库配置里有一个容易被忽略的细节——给文档打元数据标签。我最开始把所有文档混在一起上传结果模型在回答工资代发客户需要什么材料时把自雇经营的材料也混了进来。后来我给每条规则加了产品线客群类型材料清单编号三个标签并在查询时按主语境过滤这个问题就解决了。向量检索不是扔进去就能用文档结构和元数据往往决定成败。4. 数据链路与安全边界智能体不能只会聊天还要会查数4.1 从华为云取数的几种姿势智能体要干活数据必须打通。我在 AgentArts 上配置数据连接的实践中总结出三种典型姿势数据源类型适用场景我推荐的使用方式对象存储 OBS存放文档、图片、OCR 识别结果等非结构化数据材料文件统一走 OBS智能体按路径读取云数据库RDS / GaussDB存放客户信息、申请记录、准入规则表通过工具节点封装 SQL 查询接口API 网关对接内部系统的业务接口如征信查询、额度计算把 API 包装成 AgentArts 插件统一鉴权我在这个项目里主要用的是云数据库 工具封装的组合。客户基本信息和准入规则表存在云数据库里AgentArts 的工具节点通过一个标准的查询接口去取数。这个接口的设计重点是返回干净的结果不要让模型去理解数据库表结构而是直接返回模型回答问题需要的语义化结果。比如查询客户准入初筛状态这个接口返回的就是{ customer_id: C20240001, sub_type: 工资代发, default_ratio: 0.48, age: 32, status: PASS }而不是一堆带 join 关系的原始表。这样大模型拿到的信息越结构化它犯错的概率越低。补充一个实操经验如果你要从外部系统拉数据尽量把鉴权放在工具层而不是提示词层。也就是说让工具在调用时自动携带凭证模型不需要知道 token 是什么。之前我图省事把 token 直接写在提示词里调试日志里能看到完整上下文当场吓出一身冷汗——这个做法绝对是安全红线。4.2 知识库向量化的工程细节知识库不是简单上传几个 PDF 就完事切分和召回策略直接决定了回答质量。我踩过的坑和调整过程可以归纳为三步调整切分粒度一开始按固定长度切比如 512 字符结果准入规则横跨两个切分片段召回时总缺一半。改成按标题和章节切分之后完整度提升明显。设置元数据过滤给每个切分片段打上产品线、客群、材料编号标签召回时先做标签过滤再走向量相似度。加了这块之后交叉答错的情况几乎消失。调整 top_k 和相似度阈值初始用默认的 top_k3结果两个相似片段挤掉了一个真正相关的片段。我把 top_k 调到 5、阈值设为 0.68用一批真实问法逐条验证后召回覆盖度上了近十个百分点。这里给一个小白也能用的判断方法打开平台的检索调试面板随机抽十句真实用户问题看每一句召回的文档片段是不是专业对口。如果发现经常召回无关内容优先检查切分粒度和元数据不要急着调模型参数。4.3 数据脱敏、权限与审计金融数据的合规要求远高于一般行业。虽然我这个项目跑在测试环境但从第一行配置起就把安全习惯养成了下面几条建议直接抄作业敏感字段脱敏客户手机号、身份证号在工具返回结果中默认打码模型拿不到完整明文。最小权限原则智能体使用的数据库账号只开放查询权限不开放写入和删除API 接口只授权这个业务域内的方法。日志审计所有工具调用、模型生成、外部接口请求都保留日志至少 180 天。输出校验结束节点前加一道校验禁止输出包含身份证号、完整手机号等个人信息。我一直觉得在金融场景里技术能力排第二数据安全和合规边界排第一。平台给的脱敏、权限、审计组件如果你不用等于在雷区里裸奔。宁可功能做得保守一点也绝不能在数据上留下隐患。5. 实测翻车与容错补救可靠智能体是怎么磨出来的5.1 合规翻车模型说出不该说的话测试第三天的下午我用一条真实话术试出了第一个严重问题。用户问为什么我上次贷款被拒了 我的智能体回答根据您的年龄、户籍所在地和职业综合评估您的风险评分未达到准入门槛。这句话单看像模像样但放在金融合规框架里是绝对的翻车——年龄、户籍、职业如果被当成拒贷理由涉嫌违反消费者权益保护相关要求也踩了公平授信的红线。模型基于概率生成内容它并不知道这类表述在金融语境里有多敏感。我的补救措施分三层加固提示词明确禁止输出涉及地域、年龄、性别、职业等维度的负面评价性描述。拒贷理由模板化所有不通过的结论从知识库里拉固定模板只显示综合评估结果未达当前产品准入要求具体原因可咨询您的客户经理这类中性表述。敏感词检测兜底在输出节点前增加一个校验环节凡是命中敏感词的回复一律拦截改走人工复核节点。经过三层防御之后合规率从第一版的 82% 提升到 99%。这件事给我的教训是在金融场景里智能体的自由发挥空间越小越安全。宁可让它听起来有点笨也不能让它口无遮拦。5.2 工具调用中断参数格式引发的连环问题第二个高频问题是工具调用中断。最典型的一次模型生成的工具参数里materials_uploaded 字段输出成了字符串 id_card, income_proof而我在工具定义里要求的是数组 [id_card, income_proof]工具执行直接报错。这个问题看似小但影响链路很长。工具报错后智能体为了让对话继续会硬编一个答案这个答案很可能是不准确的。我在调试日志里看到过一次典型的幻觉输出工具其实没查到材料核验结果模型却编了一个材料齐全的结论简直离谱。解决思路有三个在工具描述里加 few-shot 示例明确写materials_uploaded 参数必须是 JSON 数组格式例如 [id_card,income_proof]。配置参数纠错节点平台支持对模型生成参数做规则校验格式不对时自动转换或重新生成。增加失败处理分支工具调用失败后不让模型自己硬答而是让流程走到再次调用工具或转人工分支。加了这套机制之后工具调用成功率从 71% 涨到 95%回复时延也从平均 8.2 秒降到了 3.5 秒——因为模型不再重复生成错误的参数了。5.3 容错设计超时、重试、降级、人工兜底一个真正可用的智能体必须把失败当成常态来设计。我在这轮实践里把容错分成了四层每层解决不同的问题层次手段场景说明模型层超时重试、备用模型切换主模型响应超时或不可用时自动切到备用模型工具层超时熔断、默认值兜底外部系统不可用时返回默认值或明确错误码绝不静默流程层条件分支降级大模型或工具连续失败时走到规则引擎做基础兜底人工层转人工工单高风险、高复杂度问题强制流转到人工客服队列我特别想强调的是工具层不要静默失败。很多初版智能体最常见的毛病是工具报错了模型假装没事继续硬聊。这非常危险尤其在信贷这种场景一次硬编的回答可能引发后续一连串误判。正确的做法是显式告诉用户当前信息查询暂时不可用请稍后重试或联系客户经理同时把失败日志抛到监控平台。5.4 用真实 case 做回归评测智能体的优化是一个持续迭代过程不能靠感觉变好了来判断。我在 AgentArts 的评测模块里维护了一组测试集包含 100 条真实用户问法覆盖准入咨询、材料核验、边缘问题、恶意输入四类。每次修改提示词、知识库或者工具定义之后我都会先跑一遍回归评测重点盯四个指标意图识别准确率判断用户意图是否正确错误会导致整个流程走偏。工具调用成功率工具是否被正确选择、参数是否正确生成。合规率输出是否命中敏感词或绝对化承诺性表述。平均响应时延端到端耗时是否在可接受范围。我第一版和优化后的对比数据指标第一版优化后意图识别准确率86%94%工具调用成功率71%95%合规率82%99%平均响应时延8.2s3.5s评测通过之后才发布到测试环境再拿少量真实用户流量小范围灰度。这个流程保证了我每次改动都是有依据的而不是好像有道理就改了试试。建议所有做智能体落地的人都养成这个习惯没有评测集的优化都是耍流氓。最后再分享一点我的个人体会。跑完这个信贷预审智能体我最大的感触是智能体落地最大的瓶颈从来不是模型能力而是业务边界的定义和兜底机制的设计。业务规则说不清楚智能体越聪明越容易翻车兜底机制跟不上一次偶发故障就能让业务方失去信心。如果你也想在华为云智果 AgentArts 上尝试做一个智能体我的建议是先把平台的工作流和插件机制玩熟然后选一个边界清晰的场景快速试错像我这次的材料核验助手从搭建到评测出第一版一个星期足够。下一步我准备把贷后还款提醒和风险线索分类加进来到时候有新经验再继续更新这篇笔记。