企业官网建设流程全解析

做这个项目之前，我其实一直对“智能体”这个概念持观望态度，总觉得有点过度包装。直到公司丢给我一个真实的信贷审批场景，让我在系统里试着用华为云智果 AgentArts 把流程跑通，我才发现过去想的很多“智能体怎么做”,其实已经被平台简化成了“业务怎么拆”的问题。这篇笔记记录的就是这次实战的完整过程，从设计思路、平台配置、工作流编排，到数据脱敏和幻觉治理这些绕不开的合规细节，全部分享出来，给打算在金融方向试水 AI 智能体的同学一个参照。

这个项目本身不算复杂，但胜在场景真实。客户提交小额消费贷申请后，系统需要自动完成资料核验、征信初评、额度预审和风险提示，能直接给结论的直接给，拿不准的必须转人工。整条链路我用华为云智果 AgentArts 分阶段搭完，前后折腾了两周，这中间踩的坑、调过的参、推翻过的设计，我觉得比最终跑通的结果更有价值。

1. 这项目到底在做什么：金融信贷场景的痛点和 AgentArts 的价值

1.1 信贷审批流程的普遍痛点

金融信贷审批是典型的“规则密集 + 非结构化输入 + 多系统协作”场景，这正是 AI 智能体最能发力的地方，也是它最容易翻车的地方。先说痛点。

审批链条实在太长。客户提交申请后，资料核验、征信查询、收入负债计算、额度测算、风险初评这些环节分布在不同的系统里，人工处理时需要在信贷系统、征信平台、反欺诈服务之间来回切换。我们内部统计过，一笔正常的消费贷申请，纯人工审批平均要 30 分钟以上，高峰时段积压严重，客户体验自然好不了。

第二，规则执行太僵硬。传统审批系统把准入规则写死成代码，客户情况稍微特殊一点就被“一刀切”拒绝，但又不敢随便放宽，因为缺少一个能把复杂规则盘活的弹性层。

第三，审批经验很难复制。老客户经理几秒钟就能判断一笔单子的风险，但这种判断依赖个人经验，说不清道不明，换个人结果可能完全不一样。

智能体在这些环节上的价值，是它能把“核验资料、查征信、算额度、做判断”这类流程拆成明确任务，逐步调用工具完成，再通过规则节点兜底，而不是像传统聊天机器人那样只做问答。换句话说，它做的事情是把原来人工在系统间来回切换的活，变成一条自动化流水线，同时保留人工复核的口子。

1.2 AgentArts 到底提供了什么

华为云智果 AgentArts 在我理解里，就是一个专门做智能体编排和运行的一站式平台。它把搭建智能体需要的几大件都做成了可视化能力，对我们这种既要快速验证、又不想从零造轮子的团队来说，非常关键。

一是模型层，可以直接接入盘古大模型，也可以按需选择其他主流模型，我们当时两个都试了，根据场景特点和响应速度做了取舍。二是知识库，把信贷产品说明书、审批规则手册、合规问答这些文档上传后，平台会自动完成向量化，模型在对话或分析过程中可以去检索，相当于给模型配了一套随时可查的“内部资料库”。三是工作流编排，通过拖拽节点的方式，把“意图识别、工具调用、规则判断、结果输出”串成一个完整的处理链路，这是整个智能体的骨架。四是插件与 API 接入，用来对接收贷系统、征信查询接口、反欺诈服务这些外部能力。五是发布与监控，构建完成后一键发布成在线服务，并且记录完整的调用日志，方便后续排查问题。

这套能力对金融信贷场景的价值，在于把过去需要自己写的 RAG 检索链路、任务规划逻辑、外部工具封装都变成了平台能力。当然，不是说完全不用写代码，业务系统的接口还是要自己开发，复杂的规则节点我后面也用到了代码块，但整体工程成本确实低了很多。

1.3 平台型智能体和代码自建的差别

做技术选型的时候，团队内部专门讨论过：直接用代码自建 agent 框架，还是用平台型智能体？这个问题没有标准答案，但结合这次场景来看，对比非常明显。

从实施节奏看，自建方案要自己解决向量数据库、任务编排、日志链路、部署运维一系列问题，以我们团队现有的人力，一到两周能出一个能演示的原型就算不错。平台方案则把这些基础设施托管了，我在 AgentArts 上从零搭出第一版，其实只用了不到两天。

从灵活性看，自建方案自由度更高，可以魔改框架内部任何逻辑；平台方案在节点类型、编排规则、插件扩展上受平台设计边界影响，遇到平台不支持的场景，就得在能力范围内换一种思路绕过去。

从运维成本看，自建要自己盯模型服务的稳定性、知识库增量更新、日志监控，平台则统一兜底，但相应地，整个智能体的运行也会更加依赖云端服务。

我的判断是，初创项目或业务验证阶段优先考虑平台型智能体，等业务逻辑复杂到平台边界明显不够用了，再考虑吸收自建方案的思路。这次实战也验证了这个判断，AgentArts 默认能力覆盖了这个场景大概 80% 的需求，剩下 20% 通过接口调用和规则节点也能补齐。

2. 实战前的设计：从业务流程到智能体模块拆解

2.1 先别急着配置平台，先把信贷流程拆到能写进工作流

打开 AgentArts 控制台之前，我花了大半天的时间把业务流程画清楚，这一步现在回头看是整个项目里最值得投入的时间。如果上来就直接排工作流，后面大概率反复返工。

我们当时把信贷审批的流程拆成了六个环节：

客户申请提交后触发后续动作，进入反欺诈初筛，对申请人身份、设备环境、行为数据做初步风控校验；然后做征信资料核验，读取征信报告关键字段，判断资料是否齐全；下一步是额度与利率测算，根据规则和历史数据算出预授信区间；接着做风险提示和决策，结合规则与模型输出建议结论；最后是人工复核出口，命中不确定或高风险场景的申请，转入人工队列处理。

这个流程不是全部交给大模型处理的。我的设计原则是：能靠规则就用规则，能靠接口就用接口，大模型只负责理解输入、处理非结构化信息、汇总证据并生成结论。这样一来，工作流里每一个节点都有明确的归属，不至于变成“大模型一锅炖”。

2.2 把智能体的能力拆成五块来设计

真正动手配置之前，我按五个模块把智能体拆了一遍，后面配置 AgentArts 时就是按这个框架落到平台能力上的。

输入理解模块负责识别用户意图和关键信息抽取。信贷场景里用户会发一段口语化诉求，比如“我想申请三万的消费贷，还款分十二期”，系统要从这句话里抽取出金额、期限、用途，还得判断资料里缺了什么。任务规划模块则负责把整体任务拆成有序子任务，决定要不要查征信、要不要重新核验资料。在 AgentArts 上，这个模块用工作流节点天然实现了，不需要让模型自己规划，对金融场景来说更可控。

工具调用模块连接反欺诈接口、征信接口、额度测算脚本等外部能力，每个工具都有清晰的输入输出定义，出了问题能快速定位到是哪个环节。知识检索模块负责从产品规则、审批手册里检索相关内容，供模型生成结论时引用。输出生成模块把前几步结果汇总成结构化结论，包括是否建议通过、额度区间、风险点和需人工复核的原因。

这五块设计完成后，我再去看 AgentArts 的能力，基本是“平台有现成能力就用现成的，没有现成的就用节点配置拼出来”，目标非常明确。

2.3 关键决策点：人工介入的兜底规则怎么定

信贷场景的智能体，最忌讳的是全自动、黑箱、没有出口。所以设计阶段就要确定一套兜底规则，我把它理解为给智能体画了一条安全边界。

第一，硬性拒绝由规则兜底。命中反欺诈黑名单、基本信息不完整、征信逾期次数超阈值等场景，直接给拒绝结论并生成原因清单。这类操作在 AgentArts 上用规则节点实现，稳定可控，不依赖模型发挥。

第二，置信度兜底。模型给出的结论如果置信度低，或者知识检索找不到有效依据，宁可转人工，也不要硬给一个结论。我设的转人工阈值是置信度低于 0.7 就必须走人工复核，后面实际运行证明这个阈值挺合适。

第三，异常兜底。外部接口超时、参数校验失败、知识库检索为空，这些情况都要有明确的异常出口，绝不能让模型在信息不全的情况下自由发挥凑一个答案。

把这三条兜底规则写清楚之后，整个智能体的设计才算闭环。AI 在边界内跑得快，边界外一定要有人接管，这是金融智能体跟普通客服机器人最本质的区别。

3. 手把手实操：在 AgentArts 上搭一个信贷审批智能体

3.1 创建智能体和基础配置

进入华为云控制台，打开 AgentArts 服务，第一步是创建智能体实例，要填业务名称、选择模型、设定角色描述。业务名称我当时填的是“金融信贷审批辅助”，没有简单写成“信贷机器人”，因为后续团队协作、日志筛选和权限管理都靠这个名字检索，起得太宽泛后面会很难受。

模型选择上，如果场景以知识检索和结构化输出为主，不一定要选最强通用推理的模型版本，反而应该关注响应速度和输出稳定性。我们最后选的是响应更快的模型版本，效果完全够用。关键还是在角色设定这里，这部分直接影响所有后续输出质量。

我给智能体的角色设定大概是这样：你是信贷审批辅助分析助手，基于客户申请信息和业务知识库，完成资料核验、征信初评、额度测算和风险提示。你不得直接给出最终放款决定，只输出建议结论和依据；当信息不足或存疑时，必须明确提示人工复核。

这段话看着简单，但它把智能体的职责边界、行为红线、输出要求全说清楚了。基础配置里还可以定义变量，比如申请金额、还款期限、客户风险分，把这些变量提前定义好，工作流节点可以直接引用，模型就不会每次都重新抽取，输出更稳定。

3.2 数据接入与知识库构建

知识库是给大模型查资料用的，构建质量直接决定模型回答质量。信贷场景要整理三类资料上传。

第一类是产品规则类，比如消费贷的准入年龄区间、贷款额度上限、期限与利率对应关系、收入负债比要求。这类资料最常被系统检索到，必须保证准确。第二类是操作规范类，比如“遇到身份证有效期过期的客户，需补充材料后重新提交申请”这类流程要求。第三类是合规问答类，客户常问的征信影响、提前还款费用、进度查询等标准问答对，也放进去。

上传之后有几个细节要注意。默认切分策略对长文档按固定长度切，很容易切在关键句话的中间，导致检索出来的片段语义断裂。我手工调整了分片逻辑，按章节和句子边界切，每段控制在三百到五百字。同时给每条知识补上业务标签，比如“产品规则”“额度测算”“合规问答”，检索时就能按标签过滤，减少无关内容干扰。

还有一个很现实的问题，数据脱敏必须在入知识库之前完成。身份证号、手机号、详细地址这些敏感字段，要么直接去掉，要么用脱敏算法替换掉，不能等上线了再补。知识库一旦变成数据泄露口，后果比智能体效果差更严重。

3.3 核心工作流编排与关键参数

AgentArts 的工作流编排是整个实战的重头戏。我把流程设计成了一条完整链路：开始节点 -> 意图识别 -> 资料完整性核验，并行执行身份校验和反欺诈查询，然后进入征信初评，这里结合知识检索和规则判断，接着做额度测算，走规则节点，再做风险等级判定，最后输出结论或者转人工。

这个结构里最重要的设计，是把无依赖的节点拆成并行，把有条件关系的节点排好前后置。比如身份校验和反欺诈查询彼此没有依赖，并行执行就能省时间；征信初评之后要根据结果走不同分支，命中硬性拒绝的直接走拒绝通道，其他情况再进入额度测算，最后统一汇总到输出节点。

配置节点时有几个参数我是锁死的，先说温度参数，也就是随机性。信贷场景里所有需要生成结论的节点，我都把温度调到了 0.1 到 0.2，最低设到 0.1，保证模型不做无谓的自由发挥。带检索的节点还要调 topK 和相似度阈值。topK 我控制在 5 到 8，太高会把不相关内容拖进来，太低又会漏掉关键规则。相似度阈值设到 0.6 到 0.7 比较合适，太严会检索不到内容导致转人工率变高，太松又会引入噪声。

还有一个容易忽略的配置，就是外部接口的超时时间。征信查询接口偶尔会超过 10 秒才返回，如果超时参数跟着默认值走，工作流会频繁走到异常分支。我最后把查询类接口的超时单独放宽到了 15 秒，并设置了 2 次重试，链路稳定性立刻上来了。

3.4 接入业务系统与联调部署

工作流编排完成之后，功能还停留在平台内部，要真正被业务系统调用，需要发布成在线服务。AgentArts 发布后会生成一个 API 地址，业务系统按照约定格式发起请求。

我当时的调用请求长这样：

{ "input": { "intent": "credit_apply", "amount": 30000, "term": 12, "customer_scores": { "risk_score": 68 } } }

期望的输出也必须是结构化 JSON，方便业务系统直接解析取字段：

{ "approved_flag": "manual_review", "suggested_limit": 20000, "risk_points": ["收入证明不完整", "历史逾期1次"], "confidence": 0.72, "reason": "资料存在疑点，建议人工复核" }

联调阶段最大的提醒是，智能体输出字段一定要固定，结构不能天天变。我一开始没加严格的输出格式约束，模型经常把自然语言和 JSON 混在一起，解析层天天报错。后来在提示词里给了固定 JSON 输出示例，又在工作流节点里做了字段映射，问题才彻底解决。配置好之后，建议先用模拟数据跑通全链路，再拿真实脱敏数据做回归，一步步来。

4. 踩坑实录：从数据脱敏到幻觉治理

4.1 数据安全红线：敏感信息不能进模型上下文

这个问题必须先讲，信贷场景的数据安全不是技术问题，是底线问题。AgentArts 的知识库、工作流变量、对话日志，每一个环节都可能包含敏感数据，如果配置阶段无视脱敏，真实业务上线就是事故现场。

我测试时就发现，直接上传原始沟通记录会导致模型在回答中引用客户的真实手机号和身份证号，非常恐怖。更隐蔽的是日志里也会留存这些敏感字段，等于把客户数据敞开在后台。所以我们的方案是：所有进知识库和工作流的数据先经过脱敏管道处理，手机号只保留后四位，身份证号替换成虚拟序列号，地址只保留到城市级别；在 AgentArts 的接口对接层，再加一层加解密转发，敏感信息在进入模型上下文之前先替换成占位符，业务系统需要时再做反向还原。

这步是整个项目里最不能省的。宁可功能简单一点，也不能让一个敏感字段因为配置失误流到大模型上下文里。上线前我们还专门做了一次脱敏专项检查，逐字段过了一遍日志和知识库，确保没有漏网的信息。

4.2 幻觉治理：让模型说话有依据

大模型在信贷场景里产生幻觉，后果可能是灾难性的。它凭空给你一个“存在逾期记录”或者“客户评分较高”，都有可能直接改变审批方向。所以我做了三层幻觉控制。

第一层是强制引用。凡是涉及规则或客户信息的结论，必须在输出里带上知识库来源或接口调用的原始字段，没有来源的内容不允许出现在结论区。第二层是结构化抽取。模型先把客户信息抽取成独立字段，再交给规则节点去判断，而不是让模型直接给“能不能审批”这种主观结论。第三层是置信度阈值。生成结论的置信度低于设定值，就转入人工复核，不冒任何风险。

我在 AgentArts 的提示词里专门加了一段“证据约束”，要求模型在输出结论时必须引用来源编号，效果特别明显。加了强制引用之后，测试阶段基本没有出现凭空捏造的征信结论，整个系统变得可以解释、可以审计，这对金融场景来说是必须达到的状态。

4.3 工作流串并行结构设计不当会出大问题

第一次编排工作流的时候，我把所有节点按串行顺序排，结果一个接口超时就把整条链路卡死，客户申请的响应时间直接飙升到十几秒。后来我把无依赖的节点拆成并行，比如身份校验和反欺诈查询并行跑，征信初评和额度测算拆成有条件的前后置，整体响应时间从 15 秒以上压到了 6 秒左右。

这个调整的教训是，并行是提升性能的关键，但也不是越并行越好。如果两个节点同时修改同一个变量，会产生写冲突；如果两个并行分支各自复制一份上下文，又会浪费资源。要按变量依赖关系算清楚哪些节点能并行，哪些必须串行。

还有一个细节，异常分支尽量收敛。我给每个接口调用节点都加了异常路径，但异常其实不只一种，有超时、有参数错、有返回格式错。一开始每种异常都单独建分支，工作流复杂到后面自己都看不懂。后来统一成一套策略：重试一次，仍失败就转人工复核。清晰了，排查问题也容易了。

4.4 高频问题速查表

我把自己和团队在这个项目里遇到的高频问题整理成了表格，对刚接触 AgentArts 的人应该很有参考价值。

| 现象 | 排查方向 | 解决建议 | | 知识库检索结果不相关 | 切片策略和标签过滤 | 按章节和句子边界重新分片，检索加标签过滤 | | 模型回答凭空捏造规则 | 提示词缺证据约束 | 强制要求输出知识库来源和接口字段 | | 接口偶尔超时导致链路中断 | 节点超时时间设置 | 查询类接口超时放宽到15秒，增加重试 | | 转人工比例过高 | 知识库质量和阈值设置 | 检查知识文档覆盖度，调整相似度阈值 | | 输出字段解析经常报错 | 输出格式未固定 | 强制 JSON 模板输出并做好变量映射 | | 日志中出现敏感字段 | 脱敏管道缺失 | 所有入站数据先脱敏再进入工作流 |

这张表里的每一个问题，都是真实项目中反复折腾出来的，建议直接保存下来，遇到相同现象的时候逐个对照排查，比自己从头摸索快得多。

5. 复盘与扩展：这套方案还能用到哪

5.1 上线后的关键指标复盘

这个智能体在测试环境连续跑了一周，用一批脱敏历史申请单做了回归。虽然没有正式生产上线，但数据趋势已经有足够的参考价值。

自动处理率大约 54%，也就是一半以上的测试申请可以由智能体直接给出建议结论，其余转入人工。单笔审批的响应耗时，从人工平均 30 分钟降到了 6 分钟左右。转人工单的重命中率，就是人工复核后跟智能体建议一致的占比，约 76%，说明大部分判断方向是对的。测试过程中我还做了一次失败样例分析，发现转人工单里相当一部分是因为知识库对复杂场景覆盖不足，并不完全是模型能力不够。所以后来我优先补知识库文档，而不是调模型参数，收益反而更大。

这里想提醒一下，这个结果离不开高质量规则库和接口的支持，单纯靠模型能力扛不到这个水平。业务规则是下限，模型是上限，两者配合才是完整方案。

5.2 这套方案的扩展方向

金融信贷之外，AgentArts 这套智能体思路同样能迁移到不少场景。

贷后管理可以做催收预判智能体，根据客户还款行为数据生成回款概率预测，辅助催收策略制定。合规审查可以做制度问答智能体，把内外部规章制度这一大堆文档变成可检索的知识库，审计人员拿问题直接提问就能得到带来源的答案。客户服务可以做智能客服加业务办理入口，在对话中完成资料补件提醒和进度查询。这些场景本质上都满足同一个特征：存在大量规则判断、有非结构化输入、需要调用多个系统。

扩展时有一句实话得说：每个新场景都得重新走一遍数据脱敏、知识建设、兜底规则设计。不能直接把信贷智能体的知识库和工作流复制过去，业务规则差一点，结论就会差很远。

5.3 再聊聊平台方案和自建方案的选择

第 1 节我讲过平台方案的优势，复盘之后再补一点。AgentArts 这类平台真正的甜点区，是先解决“快速跑通和上线验证”的问题。信贷这类强合规场景，自建方案最大的负担不是写代码，而是版本治理、安全审计、知识库更新这套工程体系。平台把这些托管了，你才能把精力全部放在业务逻辑上。

反过来说，如果业务形态高度特殊，需要极其细粒度的控制权，或者你们已经有一套完整自研的 agent 基础设施，那平台反而会变成一种约束。选择本质上是取舍，没有绝对的好坏，关键是清楚自己处在什么阶段、最缺什么能力。

最后分享一个我这次项目里最深的体会：智能体的上限从来不是模型版本，而是你对业务拆解的深度。AgentArts 把智能体的工程门槛降得很低，真正难的是想清楚每个节点该做什么、什么交给规则、什么交给模型、什么坚决交给人工。把这些想明白了，工作流是配出来的；想不明白，再强的模型也会在信贷这种强合规场景里翻车。如果你也准备做类似的场景，建议先把你最头疼的一段流程跑通，再从边缘场景慢慢扩，稳扎稳打比一步到位靠谱得多。