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 里放威胁性表达这类引导。下表是我做业务拆解时整理的一个简版规划表方便你理解智能体的分工逻辑阶段场景原人工处理耗时智能体介入方式人工兜底位置贷前材料完整性预审5-8 分钟/单OCR 规则 模型判断预审结论确认贷前征信报告结构化解析10-15 分钟/单OCR 模型 Schema 抽取关键字段抽检贷中补件通知生成3-5 分钟/单缺失项识别 话术生成发送前人工确认贷中审批意见草稿15-20 分钟/单多节点信息汇总 生成审批人复核签字贷后舆情预警抽取人工不可行定时触发 事件抽取风控研判贷后催收话术辅助2-3 分钟/单画像 天数 话术模板催收员修改后发送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.9 - 1.0自动通过进入下一节点0.7 - 0.9附带模型低置信度提示并允许通过0.4 - 0.7进入人工抽检池0 - 0.4强制人工复核这套机制一开始执行时会发现模型特别喜欢给 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 工程体系。上面这些方法和坑是我在真实项目里摸底摸出来的希望对准备在这条路上动手的你有实际帮助。