企业官网建设流程全解析

上周用华为云智果 AgentArts 搭完了一个金融信贷场景的 AI 智能体——贷前资质预审与材料核验助手。说实话，最开始我以为这又是一个"套壳大模型"的对话平台，但真正上手跑完一轮之后才发现，AgentArts 的核心价值不是聊天，而是把"会思考的模型"和"能办事的工具"在一个画布里真正闭环起来。这篇学习笔记我会完整记录我从平台入门、业务拆解、工作流搭建到实测翻车的全过程，也把一些合规和数据安全上踩过的坑一并写出来。无论你是准备华为 ICT 大赛云赛道、想在企业内部快速落地一个带业务动作的 AI 助手，还是单纯想弄清楚智能体和普通对话机器人到底差在哪，这篇笔记应该都能给你一些可复用的经验。

1. 智果 AgentArts 初印象：它解决的不只是"对话"，而是业务闭环

1.1 AgentArts 到底是干什么的

打开华为云智果 AgentArts 的控制台，我的第一感觉是"熟悉又陌生"。熟悉的是里面有模型管理、知识库、在线调试这些常见组件，陌生的是它多了整套"智能体编排"的概念，入口排在比较显眼的位置。

用一句话概括：AgentArts 是一个面向 AI 智能体的一站式开发与运行平台。你可以在上面配置大模型、注册业务工具、挂接知识库，然后把它们编排成一个能自主完成任务的智能体。这里的关键词是"自主完成任务"——模型不再只是回答你"应该怎么做"，而是可以直接调用工具把事做了，比如查客户信息、核验材料清单、计算预授信额度，最后把结果按业务口径整理出来。

我第一次跑通一个最简单的智能体时，在画布里拖了四个节点：开始节点、大模型节点、工具调用节点、结束节点。流程是"用户提问 -> 模型判断需要调哪个工具 -> 工具执行并返回结果 -> 模型根据结果生成回答"。整个过程约等于给大模型配了一个"工具箱"，让它自己决定什么时候打开哪个箱子。就这么一个简单的机制，已经能处理很多传统对话机器人完全搞不定的事情。

我整理了一个概念对照表，新人上手前建议先把这个记牢：

这个类比对我理解 AgentArts 帮助很大。智能体平台做的事，就是帮我把一个"实习生"快速培养起来：给它接上内线电话（工具）、塞一本业务手册（知识库）、写清楚作业流程（工作流），然后放手让它干活。

1.2 为什么需要专门的智能体平台，而不是直接调 API

很多人会问：我直接用大模型 API，自己写代码去调工具、做检索，不也一样吗？这个问题我在学习过程中反复想过，答案是：一样，也不一样。

一样的是底层原理——都是让大模型做意图理解和规划，然后通过函数调用或工具调用来完成动作。不一样的是工程成本和迭代效率。拿信贷场景举例：如果我用裸 API 的方式自己搭，我需要考虑模型怎么知道有哪些工具可用、工具的参数格式怎么约定、调用失败怎么重试、知识库怎么切分和召回、提示词怎么统一管理、日志和评测怎么做。这些工作单独拿出来都不难，但叠在一起很容易变成一个"每天都在补漏洞"的工程泥潭。

AgentArts 这类平台的价值，是把这些能力变成可配置的组件，让开发者的精力集中在业务逻辑上。我在 AgentArts 上添加一个"客户信息查询"工具，只需要在插件配置里填好接口地址、入参出参定义和鉴权方式，模型就能在需要时自动调用它；我想让智能体掌握产品准入规则，上传文档后配置好切分策略就能被检索。这些步骤在自研体系里往往要写几百行甚至上千行代码。

还有一个容易被忽略的点：评测和灰度。自研方案里要搭一套评测集和回归机制，需要自己写脚本。AgentArts 内置了智能体评测能力，我可以在里面维护一批真实的用户问法，每次改了提示词或工具定义之后，一键跑回归看指标变化。这个功能在我后面迭代时帮了大忙，本地的调试效率至少翻了一倍。

1.3 平台的基本编排逻辑

AgentArts 的工作流画布是核心操作入口，我建议第一次接触的人在动手搭业务之前，先花半小时把画布上的节点类型过一遍。主要的节点类型包括：

• 开始节点：定义用户输入参数和会话初识信息。
• 意图识别 / 大模型节点：让模型做判断、生成文本、抽取信息。
• 工具调用节点：挂接插件或 API，执行具体的业务动作。
• 条件分支节点：根据模型输出或工具结果走不同的后续流程。
• 代码节点：写少量脚本做数据加工。
• 结束节点：定义返回给用户的最终内容。

编排逻辑本质上是在模拟一个"思考—行动—观察"的循环。用户输入进入智能体后，模型先"思考"该干什么，如果需要外部信息就调用工具，工具执行后把结果返回给模型，"观察"到结果后再继续规划下一步，直到满足结束条件。这个模式后来我在资料里看到，正式名称叫 ReAct（Reasoning + Acting），是当前构建能思考、能行动的 AI 智能体的主流范式之一。

明白了这一层，再看 AgentArts 的界面就不会迷路：画布上每一个节点，都是在为这个循环服务。

2. 信贷场景怎么切：先拆业务再谈技术

2.1 信贷链路里哪些环节适合智能体

金融信贷是天然适合智能体落地的领域，但不是什么环节都适合。我一开始的想法很冲动——想把"信贷全流程"塞进智能体里，后来跟有信贷业务经验的朋友聊完才冷静下来。信贷业务链路很长，从获客、贷前预审、材料收集、反欺诈、额度测算，到审批、签约、放款，再到贷后监控、还款提醒甚至催收，每个环节的复杂度、合规要求、人工介入程度都不一样。

我按三个标准筛选适合上智能体的环节：高频、规则相对明确、低合规风险。分析结果如下表：

对比下来，最适合我练手的场景浮出水面：贷前资质预审与材料核验。这个环节业务规则清晰，客户经理每天都在做机械性重复工作，而且即使智能体偶尔答错，也有客户经理在中间把关，不会直接触达客户，风险相对可控。

2.2 我选的切入点：贷前预审与材料核验

我这次选择的具体场景是"贷前预审与材料核验助手"，服务对象是信贷客户经理，而不是C端客户。这个选择帮我规避了很多合规麻烦。

业务痛点三个字就能总结完——重复烦。客户经理每天要回答大量重复问题"我这个条件能申请吗""要准备哪些材料""收入证明怎么开"；同时还要人工核对申请材料是否齐整、是否符合清单要求。材料缺了要在系统里逐项登记，再电话通知客户补交，来回沟通成本非常高。

智能体的目标因此很明确：

1. 自动回答准入条件、材料要求、利率区间类的常见咨询。
2. 根据客户录入的基本信息，自动判断初步准入状态（通过 / 存疑 / 不通过）。
3. 对客户提交的电子材料自动核对清单，输出缺失项和格式问题。
4. 所有结论都带上"初步判断、仅供参考、以人工审批为准"的限定语。

这里我想强调一点：智能体的输出边界必须在设计阶段就定死，不能让它变成"什么都知道的半仙"。我在提示词和流程里都做了约束，凡是涉及最终审批、额度承诺、利率承诺的内容，一律不允许输出，直接引导用户联系客户经理。这是金融场景的底线，也是我后面避免很多麻烦的根本原因。

2.3 把业务目标翻译成智能体任务

业务目标明确了，接下来要拆成智能体能执行的任务。我在 AgentArts 里把它拆成了四个子任务：

1. 任务一：意图识别——判断用户输入是"准入咨询""材料核验"还是"其他问题"。
2. 任务二：信息抽取与准入判断——从对话中抽取收入、年龄、职业、负债等关键信息，匹配准入规则。
3. 任务三：材料清单核验——根据准入子类拉取对应材料清单，逐项核验提交材料是否齐全。
4. 任务四：结果生成与输出——按合规模板生成回复，缺失项用结构化列表呈现。

每个子任务对应到 AgentArts 里的具体组件：意图识别用大模型节点加条件分支，准入判断用工具节点查规则库，材料核验用插件调用 OCR 和清单比对能力，最终回复用大模型节点搭配固定模板。

下面是我做的映射表，方便后面照着搭：

拆完这些，平台的搭建工作基本变成了一道"填空题"：往画布里拖节点、配置参数、联调工具。

3. AgentArts 上的核心搭建过程：从画布到跑通

3.1 工作流骨架：模拟"思考—行动—观察"循环

搭建的第一步是搭工作流骨架。我设计的主流程如下：

1. 开始节点：接收用户文本和可选的客户编号。
2. 意图识别大模型节点：判断用户输入属于哪类任务，输出一个结构化意图标签。
3. 条件分支节点：按意图标签分流，分别是"准入咨询""材料核验""转人工"。
4. 工具调用链：
   • 准入咨询分支调用"客户信息查询"工具和"准入规则匹配"工具；
   • 材料核验分支调用"材料清单拉取"工具和"文件核验"插件。
5. 结果加工节点：用代码节点或大模型节点把工具结果整理成统一格式。
6. 合规校验节点：对输出文本做敏感词和承诺性语句检查。
7. 结束节点：返回最终回复。

这个流程的核心逻辑就是 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 部分。这里想提醒的是：提示词不是一次写好的，而是结合真实案例持续打磨出来的。建议把每条提示词都当成代码来维护，加版本号，配合评测集做回归。

知识库方面，我上传了三类资料：

1. 产品准入规则文档：按产品线整理，每条规则带产品名称和适用客群标签。
2. 材料清单说明：每个准入子类对应的标准材料目录和格式要求。
3. 常见问答对（QA）：把客户经理日常被问的高频问题整理成标准问答。

知识库配置里有一个容易被忽略的细节——给文档打元数据标签。我最开始把所有文档混在一起上传，结果模型在回答"工资代发客户需要什么材料"时，把"自雇经营"的材料也混了进来。后来我给每条规则加了"产品线""客群类型""材料清单编号"三个标签，并在查询时按主语境过滤，这个问题就解决了。向量检索不是"扔进去就能用"，文档结构和元数据往往决定成败。

4. 数据链路与安全边界：智能体不能只会聊天还要会查数

4.1 从华为云取数的几种姿势

智能体要干活，数据必须打通。我在 AgentArts 上配置数据连接的实践中，总结出三种典型姿势：

我在这个项目里主要用的是"云数据库 + 工具封装"的组合。客户基本信息和准入规则表存在云数据库里，AgentArts 的工具节点通过一个标准的查询接口去取数。这个接口的设计重点是"返回干净的结果"，不要让模型去理解数据库表结构，而是直接返回模型回答问题需要的语义化结果。

比如"查询客户准入初筛状态"这个接口，返回的就是：

{ "customer_id": "C20240001", "sub_type": "工资代发", "default_ratio": 0.48, "age": 32, "status": "PASS" }

而不是一堆带 join 关系的原始表。这样大模型拿到的信息越结构化，它犯错的概率越低。

补充一个实操经验：如果你要从外部系统拉数据，尽量把鉴权放在工具层而不是提示词层。也就是说，让工具在调用时自动携带凭证，模型不需要知道 token 是什么。之前我图省事把 token 直接写在提示词里，调试日志里能看到完整上下文，当场吓出一身冷汗——这个做法绝对是安全红线。

4.2 知识库向量化的工程细节

知识库不是简单上传几个 PDF 就完事，切分和召回策略直接决定了回答质量。

我踩过的坑和调整过程可以归纳为三步：

1. 调整切分粒度：一开始按固定长度切（比如 512 字符），结果准入规则横跨两个切分片段，召回时总缺一半。改成按标题和章节切分之后，完整度提升明显。
2. 设置元数据过滤：给每个切分片段打上产品线、客群、材料编号标签，召回时先做标签过滤，再走向量相似度。加了这块之后，交叉答错的情况几乎消失。
3. 调整 top_k 和相似度阈值：初始用默认的 top_k=3，结果两个相似片段挤掉了一个真正相关的片段。我把 top_k 调到 5、阈值设为 0.68，用一批真实问法逐条验证后，召回覆盖度上了近十个百分点。

这里给一个小白也能用的判断方法：打开平台的检索调试面板，随机抽十句真实用户问题，看每一句召回的文档片段是不是"专业对口"。如果发现经常召回无关内容，优先检查切分粒度和元数据，不要急着调模型参数。

4.3 数据脱敏、权限与审计

金融数据的合规要求远高于一般行业。虽然我这个项目跑在测试环境，但从第一行配置起就把安全习惯养成了，下面几条建议直接抄作业：

• 敏感字段脱敏：客户手机号、身份证号在工具返回结果中默认打码，模型拿不到完整明文。
• 最小权限原则：智能体使用的数据库账号只开放查询权限，不开放写入和删除；API 接口只授权这个业务域内的方法。
• 日志审计：所有工具调用、模型生成、外部接口请求都保留日志，至少 180 天。
• 输出校验：结束节点前加一道校验，禁止输出包含身份证号、完整手机号等个人信息。

我一直觉得，在金融场景里技术能力排第二，数据安全和合规边界排第一。平台给的脱敏、权限、审计组件如果你不用，等于在雷区里裸奔。宁可功能做得保守一点，也绝不能在数据上留下隐患。

5. 实测翻车与容错补救：可靠智能体是怎么磨出来的

5.1 合规翻车：模型说出不该说的话

测试第三天的下午，我用一条真实话术试出了第一个严重问题。用户问："为什么我上次贷款被拒了？" 我的智能体回答：

"根据您的年龄、户籍所在地和职业综合评估，您的风险评分未达到准入门槛。"

这句话单看像模像样，但放在金融合规框架里是绝对的翻车——年龄、户籍、职业如果被当成拒贷理由，涉嫌违反消费者权益保护相关要求，也踩了公平授信的红线。模型基于概率生成内容，它并不知道这类表述在金融语境里有多敏感。

我的补救措施分三层：

1. 加固提示词：明确禁止输出涉及地域、年龄、性别、职业等维度的负面评价性描述。
2. 拒贷理由模板化：所有"不通过"的结论，从知识库里拉固定模板，只显示"综合评估结果未达当前产品准入要求，具体原因可咨询您的客户经理"这类中性表述。
3. 敏感词检测兜底：在输出节点前增加一个校验环节，凡是命中敏感词的回复一律拦截，改走人工复核节点。

经过三层防御之后，合规率从第一版的 82% 提升到 99%+。这件事给我的教训是：在金融场景里，智能体的"自由发挥空间"越小越安全。宁可让它听起来有点笨，也不能让它口无遮拦。

5.2 工具调用中断：参数格式引发的连环问题

第二个高频问题是工具调用中断。最典型的一次：模型生成的工具参数里，materials_uploaded 字段输出成了字符串 "id_card, income_proof"，而我在工具定义里要求的是数组 ["id_card", "income_proof"]，工具执行直接报错。

这个问题看似小，但影响链路很长。工具报错后，智能体为了让对话继续，会"硬编"一个答案，这个答案很可能是不准确的。我在调试日志里看到过一次典型的幻觉输出：工具其实没查到材料核验结果，模型却编了一个"材料齐全"的结论，简直离谱。

解决思路有三个：

1. 在工具描述里加 few-shot 示例：明确写"materials_uploaded 参数必须是 JSON 数组格式，例如 ['id_card','income_proof']"。
2. 配置参数纠错节点：平台支持对模型生成参数做规则校验，格式不对时自动转换或重新生成。
3. 增加失败处理分支：工具调用失败后不让模型自己硬答，而是让流程走到"再次调用工具"或"转人工"分支。

加了这套机制之后，工具调用成功率从 71% 涨到 95%，回复时延也从平均 8.2 秒降到了 3.5 秒——因为模型不再重复生成错误的参数了。

5.3 容错设计：超时、重试、降级、人工兜底

一个真正可用的智能体必须把失败当成常态来设计。我在这轮实践里把容错分成了四层，每层解决不同的问题：

我特别想强调的是"工具层不要静默失败"。很多初版智能体最常见的毛病是：工具报错了，模型假装没事继续硬聊。这非常危险，尤其在信贷这种场景，一次硬编的回答可能引发后续一连串误判。正确的做法是显式告诉用户"当前信息查询暂时不可用，请稍后重试或联系客户经理"，同时把失败日志抛到监控平台。

5.4 用真实 case 做回归评测

智能体的优化是一个持续迭代过程，不能靠"感觉变好了"来判断。我在 AgentArts 的评测模块里维护了一组测试集，包含 100 条真实用户问法，覆盖准入咨询、材料核验、边缘问题、恶意输入四类。

每次修改提示词、知识库或者工具定义之后，我都会先跑一遍回归评测，重点盯四个指标：

• 意图识别准确率：判断用户意图是否正确，错误会导致整个流程走偏。
• 工具调用成功率：工具是否被正确选择、参数是否正确生成。
• 合规率：输出是否命中敏感词或绝对化承诺性表述。
• 平均响应时延：端到端耗时是否在可接受范围。

我第一版和优化后的对比数据：

评测通过之后才发布到测试环境，再拿少量真实用户流量小范围灰度。这个流程保证了我每次改动都是有依据的，而不是"好像有道理就改了试试"。建议所有做智能体落地的人都养成这个习惯：没有评测集的优化都是耍流氓。

最后再分享一点我的个人体会。跑完这个信贷预审智能体，我最大的感触是：智能体落地最大的瓶颈从来不是模型能力，而是业务边界的定义和兜底机制的设计。业务规则说不清楚，智能体越"聪明"越容易翻车；兜底机制跟不上，一次偶发故障就能让业务方失去信心。如果你也想在华为云智果 AgentArts 上尝试做一个智能体，我的建议是：先把平台的工作流和插件机制玩熟，然后选一个边界清晰的场景快速试错，像我这次的材料核验助手，从搭建到评测出第一版一个星期足够。下一步我准备把贷后还款提醒和风险线索分类加进来，到时候有新经验再继续更新这篇笔记。