企业官网建设流程全解析

1. 先弄清楚 AgentArts 是什么：它不只是一个低代码平台，而是一个可落地的 Agent 工程框架

先说我第一次接触华为云 AgentArts 时的感受。当时我在做一个信贷审批流程自动化的项目，最初的想法是用 LangChain 或自研的调度框架来组装一个 AI 智能体，把资料核验、征信解析、风险初筛串起来。但项目推进两周后，我发现自己低估了一件非常棘手的事：金融场景对链路可观测性、审计追溯、权限管控的要求，根本不是开源框架开箱即用的。

后来我换到了华为云智果 AgentArts，才理解了为什么这类一站式 AI 智能体平台在金融行业里更适合落地。AgentArts 的核心定位不是让你画几个流程图就完事，它提供的是 Agent 从构建、编排、运行到运营的一整套工程闭环。简单说，它解决的是"模型怎么变成业务可用系统"的中间层问题。

1.1 为什么不用 LangChain 自己搭，而要用 AgentArts

我不否认 LangChain 这类框架在原型验证阶段的效率。我自己也在个人项目里用它写过不少 Demo。但一旦进入金融信贷领域，你会立刻碰到几个绕不过去的现实问题：

第一，工具调用的稳定性保障。信贷场景中智能体要调用 OCR 识别、征信报告解析接口、黑名单查询服务、规则引擎等外部依赖。LangChain 的插件生态参差不齐，有些 Tool 的实现质量不高，调用超时、返回结构异常、鉴权失败这些情况，代码里都要自己处理。而在 AgentArts 里，工具节点和模型节点是平台层面统一管理的，内置了超时、重试、并发控制策略，这些能力金融级在线业务非常看重。

第二，审计与权限。金融机构的合规要求决定了每一次 AI 决策过程都必须可回放。谁在什么时间调用了什么模型，喂了什么输入，拿到了什么输出，AgentArts 都有完整的调用链日志。自研框架要做到同样程度，至少得额外投入两个后端人力去做日志落库和权限模型设计。

第三，模型切换成本。国内金融企业对数据合规非常敏感，很多机构要求推理必须跑在私有化环境或指定云专区。AgentArts 底层支持华为云盘古系列模型，也能对接主流的开源模型。相比在自研框架里为每个模型写适配层，平台在模型路由和切换上的成本低得多。

我当时的结论是：原型阶段用开源工具链没问题，但一旦涉及金融生产级场景，平台化的 Agent 工程体系是更稳妥的起点。这不是说 AgentArts 完美到什么都替你做了，而是它把"工程地基"替你打好了，你可以把精力集中在业务编排本身。

1.2 AgentArts 的原子能力拆解：模型、工具、工作流、知识库、记忆

如果你第一次打开 AgentArts 的控制台，看到的其实是几个核心模块：模型服务、智能体编排、知识库、工具管理、运行观测。想用好它，要对每一个模块的边界有清晰认知。

• 模型节点：负责语义理解、生成、推理决策。在金融场景里，我不会把业务规则直接怼进 Prompt 让模型去执行，而是让模型做"意图识别 + 信息抽取 + 调用决策"，规则部分交给代码节点或传统决策引擎。
• 工具节点：支持 API 类插件、代码片段、数据库查询、人工确认节点。工具节点的输入输出建议都用标准 JSON Schema 约束，这样模型生成的调用参数才能被严格校验。
• 工作流编排：这是 AgentArts 区别于普通 Prompt 调优工具的关键。你可以用有向无环图的方式编排多个节点，节点之间通过变量传递上下文。这意味着一条信贷审批流程中，OCR 节点、征信解析节点、风险规则节点、人工复核节点可以被串成一条确定性链路，而不是让模型信马由缰。
• 知识库：用于挂载信贷政策、产品手册、反欺诈规则等非结构化文档，让 RAG（检索增强生成）能基于内部规范回答。
• 记忆机制：在多轮对话中保存客户画像、前序问答摘要。信贷场景中我通常只开短期记忆，避免跨会话保留过多敏感信息。

1.3 金融信贷场景为什么"吃"平台能力

信贷智能体和一般客服机器人最大的区别在于：它做的每个决定都涉及真金白银和合规责任。因此对智能体平台的要求有两个维度：

一是确定性优先。凡是可以通过规则完成的校验（比如身份证号格式、年龄限制、征信查询授权有效期），绝不让模型自由发挥。只有在规则无法覆盖的开放语义理解环节，才交给大模型。

二是人机协同链路。智能体不能是"黑盒自动决策机"，它应该是一个"自动化辅助执行体 + 人工复核闸门"的组合。AgentArts 的工作流编排天然支持在任意节点插入人工确认环节，这是我在选型时非常看重的一点。

2. 信贷业务拆解：AI 智能体到底接管哪些环节

在动手搭建智能体之前，我花了整整两天做业务复盘，把信贷全生命周期里的每个环节都列了一遍。很多人一上来就想做一个"全能信贷助手"，结果发现 AgentArts 编排链路复杂无比，而且效果不可控。正确的做法是先圈定 2 到 3 个高频、规则较清晰的场景做切入。

2.1 贷前阶段：可以快速落地的三个智能体

贷前是信贷环节里最缺人力的环节，也是最值得自动化的部分。

第一个是进件材料完整性预审智能体。客户提交身份证、收入证明、银行流水后，智能体调用 OCR 识别材料类型，检查关键词和格式完整性，比如流水是否包含近六个月记录、关键页是否缺失。这些工作让信贷员来做，平均一单要 5 到 8 分钟，智能体压到 30 秒以内。

第二个是征信报告解析智能体。人行征信报告的 PDF 版式非常固定，但字段多、语义复杂。传统 OCR 解析经常漏字段，让大模型介入做结构化抽取，准确率高很多。我在 AgentArts 里的做法是：先用 OCR 把 PDF 转成文本，再让模型按预设 Schema 抽取逾期次数、未结清贷款笔数、对外担保金额等关键字段。

第三个是预审问答助手。面向客户经理的辅助问答，例如"客户当前负债率是否超过 70% 红线""反欺诈规则命中了几条"。这个助手接知识库和规则引擎，返回结果时附上规则编号和命中逻辑。

2.2 贷中阶段：审批辅助与照会生成

贷中环节最难自动化的是信息补录与照会。客户提交的材料缺项时，需要向客户发起补充要求。以往信贷员要手工写补充材料清单，现在智能体可以根据缺失项自动生成话术，并且通过工作流推送到客户经理复核后再发出。

同时，审批意见书草稿生成也很适合智能体接管。AgentArts 里我会把风险评估结果、征信统计指标、合规检查结论通过变量拼接进提示词，让模型生成结构化的审批意见草稿。这里有一个红线：草稿必须经过人工审批节点确认后才能归档。

2.3 贷后管理：风险预警与催收话术分级

贷后和贷前贷中相比，容错空间更小，因为面向的是已签约客户。我在实践里主要做两类智能体：

一类是贷后风险预警信息抽取智能体。它监测客户经营异常新闻、涉诉信息、关联企业风险变动，抽取事件类型、涉及金额、发生时间，并按照严重程度打标。这些结果推送风控人员做研判，而不是直接触发人工催收，避免误伤。

另一类是催收话术辅助生成智能体。系统根据逾期天数和客户历史还款行为，生成不同力度的催收话术草稿，由催收员修改后使用。这个场景大家都不陌生，很多平台都有类似功能。但要注意合规边界：话术内容要严格遵守监管规定，不能在 Prompt 里放"威胁性表达"这类引导。

下表是我做业务拆解时整理的一个简版规划表，方便你理解智能体的分工逻辑：

3. 实战搭建：在 AgentArts 里从零编排一个"进件材料核验"智能体

业务拆解做完后，落到 AgentArts 平台上的实操环节。我在第一个项目里选的是"进件材料完整性预审"这个最轻量的场景，因为它规则清晰、可量化、最容易验证效果。下面把我的搭建过程拆给你看。

3.1 创建项目：先想清楚入口形态

在 AgentArts Studio 里创建项目时，系统会让你选择 Agent 类型。我选了"工作流 + Agent 混合编排"模式，而不是纯交互式对话智能体。区别在于：进件材料核验是一个确定性的任务流，不应该让模型自由决定先做什么后做什么。

入口形态我做了两个：一个是对内的 API 接口，供信贷系统直接调用；另一个是 Web 页面入口，供信贷员手动上传材料包。两者最终都走同一条工作流。

3.2 编排核心工作流：六节点完整链路

这条工作流的完整链路是：材料上传 → OCR 识别 → 材料分类 → 完整性规则校验 → 大模型语义判断 → 输出结果结构化。

节点一，材料上传与格式转换。接入对象存储服务，允许上传 PDF、图片格式。我的经验是让转换节点先把各种格式统一转成高清 PDF 再进 OCR，识别率会明显提升。

节点二，OCR 识别。这个节点我用的是华为云 OCR 服务的通用表格识别和身份证识别。这里有个坑：材料分类不能靠 OCR 的坐标硬编码，因为不同客户扫描的文件版式千差万别。正确做法是 OCR 出全文文本后，进入模型分类节点。

节点三，大模型材料分类。模型根据全文内容判断每个文件的类型：身份证明类、收入证明类、资产证明类、其他补充类。我定义了四个枚举值，让模型以 JSON 格式输出分类结果。为了防止模型乱写，在输出节点前接一个校验节点：如果模型输出的分类不属于枚举集合，直接置为"待人工判别"。

节点四，完整性规则校验。一个纯代码节点，不触发大模型。它接收分类结果，对照当前产品对应的材料清单判断：缺了哪些类型、哪些材料页数不足。比如客户申请的是抵押经营贷，材料清单要求必须包含房产证复印件和近半年对公流水，代码节点会逐一检查。

节点五，大模型语义补判。这个节点专门处理边界情况。举个例子，客户上传了一份"收入证明"，但文件里全是空白模板没有填写任何金额。OCR 和规则都看不出问题，只有模型语义理解能识别出"盖章区域为空""关键字段未填写"这类异常。

节点六，结果输出与人工兜底。最后把所有节点的结果汇总成 JSON，通过企业微信或内部工单系统推送。如果规则节点或语义节点判定为"异常"，工作流会进入人工复核分支。

3.3 节点配置里关于提示词的设计细节

在 AgentArts 里给模型节点写 Prompt 时，我总结了一句经验：给模型的是决策空间，而不是业务规则。

比如分类节点的 Prompt 我不写"收入证明必须要有公司盖章"，而是写"请识别文件类别并输出 JSON，注意区分正式文件与空白模板"。完整性校验的硬规则全部放在代码节点里，用正则和条件表达式处理。原因很简单：大模型在生成任务上很强，但在精确计数和逻辑判断上并不可靠，把规则硬编码到 Prompt 里既浪费 token，又容易幻觉。

另一个设计要点是规定输出格式。我在每个模型节点都要求输出 JSON Schema 化的结果，并且关闭了"流式输出"选项。对于信贷这类下游系统要做结构化解析的场景，一定要让输出保持严格可解析的状态。

3.4 测试阶段注意：边界样本比正常样本更重要

工作流编排完，先别急着跑黄金路径。我第一轮测试跑的都是正常材料包，效果看起来很好，准确率 98% 以上。但后来把几十个历史拒件样本喂进去后，问题立刻暴露了。

拒绝件里最常见的干扰是：客户上传了过期身份证、模糊的银行流水截图、带水印的非原件。OCR 识别这类低质量图片时，文字会大量出错。模型分类倒是稳住了，但完整性校验却经常因为 OCR 漏字给客户"误判缺少材料"。

解决思路是双管齐下：一方面在 OCR 节点后加了图片质量分检测，低质量图像走"人工预筛"分支；另一方面给完整性校验节点加了容错逻辑，对"疑似漏识别"的情况输出告警而不是直接拒绝，交由人工确认。

4. 容错设计、灰度发布与观测：金融级智能体上线的三道闸门

工作流在测试环境跑通，只代表"Demo 成了"，距离上线还有相当远的距离。金融信贷业务对稳定性的要求极其苛刻，一次接口超时、一次判定错乱，都可能造成客户投诉甚至监管合规问题。我在 AgentArts 上踩过的坑，几乎都集中在下面三个环节。

4.1 工具调用失败时的降级策略

智能体在运行过程中，依赖的外部服务随时可能出问题：征信查询接口限流、OCR 服务队列阻塞、知识库向量检索超时。AgentArts 默认有节点超时设置，但之前默认值通常是 30 秒到 60 秒。在信贷场景中，一个环节卡 60 秒用户体验是完全不能接受的。

我把第一版策略改成了"分级降级"：

• 依赖 OCR 的节点超时压到 15 秒，超时后自动降级为"转人工处理"，不让流程卡住。
• 依赖外部征信接口的节点重试 2 次，每次间隔 3 秒，仍失败则标记为"数据待补"，跳过该步骤并把缺失信息写入结果摘要。
• 知识库检索超时直接返回空结果，触发模型走"仅凭内部知识回答"的兜底分支，如果模型置信度不足则转人工。

这里有一个需要你特别注意的设计原则：金融智能体的降级方向应该永远是"保守的"。宁可让流程停止转人工，也不要在缺失关键信息的情况下让模型猜测着往下走。一旦模型在缺少征信数据时还给出了审批建议，这个错误就是不可接受的。

4.2 幻觉控制：模型输出必须经过双重校验

大模型在开放问答里偶尔说一下漂亮话没关系，但在信贷审批辅助中，幻觉是会出事故的。我在实践里总结了一套双重校验机制，你可以直接参考：

第一重，Schema 校验。所有模型输出先做 JSON 结构校验，字段缺失、枚举值越界、数值格式异常，一律打回重跑一次。AgentArts 的"模型输出校验"节点可以干这件事，如果没有现成节点，用一个 Lambda 函数代码节点也完全可以实现。

第二重，结果置信度分级。我在每个模型的 Prompt 里都要求模型输出一个confidence字段，取值区间为 0 到 1。工作流基于这个字段进行分支路由：

这套机制一开始执行时会发现模型特别喜欢给 0.95 分以上。后来我在 Prompt 里加了一个约束："如果你对输入信息的完整性或上下文语义存在任何不确定，请主动降低置信度"。加了这句话之后，置信度的区分度好了很多，这是我从业务侧实际跑出来的经验。

4.3 灰度发布：金融智能体不能"一把梭"全量上线

我第一次带着 AgentArts 工作流走上线流程时，被审批部门反复追问一个问题：你怎么证明这个智能体的判定不会比人更差？这个问题直接影响上线授权。

最后我们定了一套灰度策略，你可以直接抄作业：

第一阶段，影子模式。工作流照跑，但输出不进业务系统，只和人工结果做离线对比。这个阶段跑了两周，积累了约 3000 条对比样本。

第二阶段，人工辅助模式。智能体输出只作为建议展示给信贷员，由信贷员决定是否采纳。这个阶段核心观测一个指标：人工采纳率。如果信贷员 10 次有 8 次直接采用智能体结论，说明置信度已经达标。

第三阶段，小流量全自动。选取单一支行或单一产品线，开放 10% 的流量让智能体直接推送预审结论，同时保留完整人工复核通道两周。

第四阶段，全量上线。仅当第三阶段连续 7 天无重大差错时才放量。

现在回头总结，这套灰度方案最大的价值不是"技术证明自己"，而是让业务部门和合规部门建立了对系统的信任。信任这个东西，在金融风控领域比任何算法指标都值钱。

4.4 运行观测：盯住这几个业务指标，而不是只盯模型准确率

AgentArts 控制台自带运行观测看板，可以查看每个节点的调用量、耗时、失败率等基础指标。这些指标只是底线。我还额外加了几个业务侧的告警指标：

• 转人工率：如果某一天转人工率突然飙升超过 20%，大概率是某个上游数据源出问题了，或者是知识库更新后检索质量下降。
• 平均处理时长：信贷员侧看到单笔智能体耗时超过 3 分钟就该告警，说明某个环节开始排队。
• 用户投诉相关性：把智能体处理过的单子与后续客户投诉做关联分析。虽然这个指标会有滞后，但它是衡量整体体验的最终标准。

5. 跑真实业务时踩过的五个坑，写在这里供你参考

到这一部分，我想分享一些从真实业务里趟出来的局限和教训。每一条的背后都是具体的线上事故或返工经历，按照重要程度排序。

5.1 RAG 检索不准，90% 的问题出在切片策略上，而不是模型上

信贷政策知识库里的文档动辄几十页，直接整篇塞进向量检索，结果就是模型经常答非所问。我最初直接把 PDF 按页切割存进 AgentArts 知识库，检索效果很差，模型无法把"收入负债比超过 70% 触发预警"这样的规则和客户实际数据关联起来。

后来我把切片策略改成"章节 + 条款"粒度，把每条规则单独切片，并给切片加上业务标签属性。检索召回率提升非常明显。如果你的知识库包含大量结构化的政策条款，建议强制按条款粒度切，而不是按页按段切。

5.2 不要试图让一个 Agent 干所有事，拆开才是出路

最初我把"贷前预审 + 征信解析 + 话术生成"塞进一个智能体里，Prompt 动辄两千字，模型经常顾此失彼，一次只能做好一件事。后来拆成三个独立 Agent，每个通过明确的触发条件串联，效果立刻改善。

AgentArts 里支持子 Agent 嵌套调用，本质上是把一个复杂任务拆成多个专门 Agent 协作，每个 Agent 只负责一个小而清晰的职责。在信贷场景中，职责越单一，幻觉越少，审计也越好解释。

5.3 外部工具鉴权与限流：集成第三方系统时最容易被忽视

信贷系统里的外部 API（征信、工商、司法）通常都有严格的 QPS 限制和鉴权时效。我在 AgentArts 里配置工具时，最初忽略了上游限流策略，结果高峰时段智能体频繁触发重试，把上游服务打爆了，随后被对方平台限制了调用权限。

解决方法是：在工具节点前加一个"流量整形"代码节点，维护一个本地令牌桶，控制每秒调用量不超过上游 QPS 的 80%。同时定期刷新鉴权凭证，提前 24 小时盯有效期，避免夜间批量任务因为凭证过期集体失败。

5.4 审计日志里必须保留原始输入，而不只是解析结果

AgentArts 的调用链日志会自动记录模型输入输出，但我在实际复盘时发现，模型输入往往经过了前序节点的变量转换，未必是客户提交的原始材料。比如 OCR 节点会把 PDF 转成文本，后续模型看到的就是文本，但当出现争议需要回溯"客户当时上传的到底是什么文件"时，只看文本是不够的。

所以我在关键入口节点增加了"原始材料存档"步骤，把客户上传的 PDF 原文存储到合规对象存储里，并在日志中关联文件 ID。这样在应对监管检查和客户投诉时，可以做到完整还原现场。一个小改动，却在后续审计评审中帮了大忙。

5.5 成本控制：推理 token 也是一笔真实的钱

信贷业务量大，单笔进件要跑多个模型节点，token 成本会随着业务量线性放大。我做过一次成本核算，在高峰期一天进件 3000 笔，每个节点平均消耗 1500 token，一天的光模型推理成本就相当可观。

控制成本的几个做法：把可复用的抽取结果缓存到本地存储，同一客户重复进件时直接复用；长文档只把关键段落喂给模型，不要整篇塞入；对简单分类任务选小尺寸模型，把大尺寸模型留给语义判断和话术生成类任务。这些优化做完后，单笔成本降了约 40%，效果还是很明显的。

最后想说的是，AgentArts 这类平台真正解决的问题不是"让模型变聪明"，而是让企业能够用工程化的方式把模型装进复杂的业务流程里。信贷行业尤其如此——这里不缺聪明的模型，缺的是可控、可管、可审计的 Agent 工程体系。上面这些方法和坑，是我在真实项目里摸底摸出来的，希望对准备在这条路上动手的你有实际帮助。