企业官网建设流程全解析

1. 金融信贷AI智能体到底在解决什么问题

1.1 从一笔信贷审批说起

传统信贷审批的流程，做过的人都知道有多碎。客户提交资料之后，风控要查征信、核流水、验发票、比对工商信息、评估抵押物，一套下来少说两三天，遇到资料不全或者信息矛盾的，来回沟通能拖一周。这里面大量的时间不是花在“判断”上，而是花在“找信息”和“对信息”上。

华为云AgentArts要干的事情，本质上是把这条链路上那些重复性的信息采集、交叉验证、规则初筛工作，交给一个能自主编排工具、能容错重试的AI智能体来完成。人只负责最终决策和异常处理。这不是什么遥远的设想，AgentArts提供的工具编排、记忆管理、多轮推理能力，已经能支撑一个可用的信贷辅助审批智能体落地。

我最近花了两周时间，基于华为云AgentArts搭了一套金融信贷场景的智能体原型，从数据接入到工具编排再到容错控制，踩了不少坑，也摸出了一些门道。这篇文章就把整个实战过程拆开来讲，包括架构设计的取舍、关键参数的配置、容错机制怎么搭、以及那些文档里不会写的实操细节。

1.2 谁适合看这篇实战记录

如果你正在做金融科技相关的AI应用，或者手头有信贷风控、贷后管理、反欺诈这类场景想用智能体来提效，这篇内容应该对你有直接参考价值。如果你只是对AI智能体好奇，想看看一个真实业务场景下智能体是怎么搭起来的，也能从里面看到不少工程化的思路。

需要说明的是，我搭建的是一个原型验证系统，不是直接上生产的方案。但原型阶段遇到的很多问题——比如工具调用失败怎么重试、多轮对话中上下文怎么管理、LLM输出不稳定怎么兜底——这些在生产环境同样会遇到，解决思路是相通的。

2. 整体架构设计与技术选型思路

2.1 为什么选AgentArts而不是自己撸一套

市面上搭智能体的框架不少，LangChain、AutoGPT、Dify这些各有各的玩法。我最终选华为云AgentArts，主要基于三个现实考量。

第一是数据接入的便利性。信贷场景要对接的数据源特别杂——征信接口、工商数据、银行流水解析、发票验真，这些如果自己一个个写连接器，工作量巨大。AgentArts本身提供了工具注册和编排的能力，把外部API封装成智能体可调用的工具，这个过程的标准化程度比较高，省去了大量胶水代码。

第二是华为云生态内的数据流转更顺。如果本身业务数据就在华为云上，比如用OBS存影像件、用RDS存结构化数据，AgentArts跟这些服务的对接是原生的，不需要额外做数据搬运。这一点在实际操作中省了很多事，尤其是涉及敏感金融数据的时候，少一次搬运就少一个风险点。

第三是容错和可观测性。AgentArts在智能体执行链路里内置了执行追踪和状态管理，工具调用失败之后的重试策略、超时控制、降级逻辑，这些都有现成的机制可以用。自己从零搭的话，光这套容错框架就够写两周。

当然也有取舍。AgentArts的灵活性肯定不如完全自研，某些定制化的推理链路可能需要绕一下。但对于快速验证一个场景能不能跑通来说，这个 trade-off 是划算的。

2.2 智能体的角色拆解与编排逻辑

一个信贷审批智能体，如果只用一个LLM从头干到尾，效果一定好不了。我的做法是把整个审批流程拆成几个专职的子智能体，每个子智能体负责一段相对独立的逻辑，通过主智能体来编排调度。

具体拆成了四个角色：

• 资料采集智能体：负责从各个数据源拉取客户信息，包括身份核验、工商信息、征信报告、银行流水。它的核心能力是工具调用，把外部API的返回结果结构化。
• 交叉验证智能体：拿到采集结果之后，做信息一致性检查。比如流水里的收入跟征信报告里的负债能不能对上，发票金额跟合同金额是否一致。这个环节需要一定的推理能力，但不是特别复杂。
• 规则初筛智能体：根据预设的风控规则做第一轮筛选，比如负债率超过阈值、近期查询次数过多、存在当前逾期等，直接给出风险标签。
• 报告生成智能体：把前面几个环节的结论汇总成一份结构化的审批建议报告，供人工复核。

主智能体的职责是管理整个流程的状态，决定下一步调用哪个子智能体，处理子智能体返回的异常，以及在必要时向人工发起确认请求。

这种拆法有个好处：每个子智能体的提示词可以写得很聚焦，不需要在一个提示词里塞进所有规则和上下文。实测下来，拆分之后的准确率比单体智能体高了不止一个档次。

2.3 数据流与状态管理设计

整个智能体运行过程中的数据流，我设计成“黑板模式”。主智能体维护一个共享的上下文对象，每个子智能体完成自己的任务后，把结果写回这个上下文，下一个子智能体从上下文里读取自己需要的信息。

这样做的好处是解耦。资料采集智能体不需要知道交叉验证智能体会怎么用它的数据，它只管把数据按约定格式放好。交叉验证智能体也不需要关心数据是从哪个API来的，它只从上下文里取。

上下文对象的结构大概长这样：

{ "case_id": "CR20260115-001", "applicant": { "name": "张三", "id_number": "***", "company": "某某贸易有限公司" }, "collected_data": { "credit_report": {}, "bank_statement": {}, "business_info": {}, "invoice_records": [] }, "verification_results": { "income_consistency": true, "debt_ratio": 0.65, "anomalies": [] }, "risk_flags": [], "final_report": null, "status": "collecting" }

状态字段用来控制流程走向。比如status是“collecting”的时候，主智能体知道该调资料采集；变成“verifying”之后，就转到交叉验证环节。如果某个环节返回了需要人工介入的标记，状态就切到“pending_review”，整个流程暂停。

注意：上下文对象里不要存原始的大文本，比如整个征信报告的PDF内容。存结构化后的关键字段和原始数据的引用地址就行。否则上下文会迅速膨胀，既影响LLM的推理效果，也增加存储成本。

3. 核心环节的实操配置与参数调优

3.1 工具注册与API接入的细节

AgentArts里把外部API封装成工具，需要定义工具的名称、描述、入参schema和出参schema。这几个字段看着简单，但写得好不好直接影响智能体能不能正确调用。

工具描述要写得像给一个新员工交代任务一样具体。比如“查询企业工商信息”这个工具，描述不能只写“查询企业工商信息”，要写清楚：输入企业名称或统一社会信用代码，返回注册资本、成立日期、经营范围、股东信息、是否有经营异常。这样LLM在决定是否调用这个工具的时候，才能准确判断。

入参schema用JSON Schema定义，每个字段都要写description。我踩过一个坑：有个工具的入参字段叫“id”，description写的是“标识”，结果LLM有时候传客户身份证号，有时候传案件编号，完全乱套。后来把description改成“客户身份证号码，18位”，就再没出过错。

出参schema同样重要。如果API返回的字段很多，建议在工具层面就做一层裁剪，只返回智能体真正需要的字段。一方面减少token消耗，另一方面也降低LLM被无关信息干扰的概率。

工具的超时设置也要注意。信贷场景涉及的一些外部接口，比如征信查询，响应时间可能比较长。超时设太短会导致频繁失败重试，设太长又会拖慢整个流程。我的经验值是：普通查询类接口设10秒，征信类接口设30秒，文件解析类接口设60秒。

3.2 提示词工程在信贷场景的落地要点

信贷场景的提示词跟通用场景有个很大的区别：对准确性和一致性的要求极高，不能有模棱两可的输出。

我在写交叉验证智能体的提示词时，采用了“角色+任务+规则+输出格式+示例”的结构。角色定义成“你是一名资深信贷审核员，擅长发现申请材料中的逻辑矛盾”。任务描述要具体到检查哪些维度，比如“检查银行流水中的月均收入与征信报告中填报的收入是否一致，偏差超过20%则标记为异常”。

规则部分要穷举可能的情况。比如收入一致怎么输出、收入不一致怎么输出、流水缺失怎么输出、征信缺失怎么输出。每种情况都给出明确的输出格式，不要让LLM自由发挥。

输出格式我强制要求JSON，并且定义了严格的schema。LLM有时候会在JSON外面包一层解释文字，这个要在提示词里明确禁止：“只输出JSON，不要输出任何其他内容”。

还有一个技巧：在提示词里加入“如果你不确定，输出unknown而不是猜测”。金融场景下，一个错误的确定判断比一个unknown的危害大得多。unknown会触发人工复核，而错误判断可能直接导致审批失误。

3.3 容错控制机制的搭建

智能体自主容错控制是这次实战里花时间最多的部分。信贷场景对可靠性的要求高，不能因为某个工具调用失败就整个流程卡死。

我搭了三层容错：

第一层是工具调用层面的重试。AgentArts本身支持配置重试策略，我设置的是最多重试3次，重试间隔采用指数退避，第一次等1秒，第二次等2秒，第三次等4秒。这个策略对网络抖动类的临时故障很有效。但要注意，不是所有失败都适合重试。比如“客户不存在”这种业务逻辑上的失败，重试多少次结果都一样，应该直接返回错误让上层处理。

第二层是子智能体层面的降级。如果资料采集智能体在重试之后仍然拿不到征信数据，它不会直接报错退出，而是把征信数据标记为“unavailable”，继续往下走。交叉验证智能体拿到这个标记后，会跳过依赖征信数据的检查项，并在最终报告里注明“征信数据缺失，相关验证未执行”。这样整个流程不会因为一个数据源的问题而中断。

第三层是主智能体层面的兜底。如果某个子智能体连续多次返回异常，或者整个流程超时，主智能体会把案件状态置为“需要人工介入”，并生成一份异常说明，把已经完成的部分和卡住的部分都列清楚，交给人工处理。

实操心得：容错机制的设计原则是“能降级就不要中断，能标注就不要猜测”。金融场景里，一个标注了“数据缺失”的报告，比一个基于不完整数据强行给出的结论要有价值得多。

3.4 多轮对话与上下文窗口的管理

信贷审批过程中，有时候需要跟客户做多轮交互来补充资料。比如流水不清晰需要重新上传，或者某个信息需要客户确认。这就涉及到多轮对话的上下文管理。

AgentArts的会话管理支持设置上下文窗口大小。我的设置是保留最近10轮对话的完整内容，更早的对话做摘要压缩。摘要的提示词是：“把以下对话历史压缩成不超过200字的摘要，保留所有关键事实和数字，去掉寒暄和重复内容。”

但这里有个坑：金融场景下，客户在对话中提供的某些信息可能具有法律效力，比如“我确认这笔贷款用于经营周转”。这种确认性语句不能只保留在摘要里，需要在原始对话中标记并单独存储。我的做法是在上下文对象里加一个“confirmations”数组，专门存这类关键确认，不参与摘要压缩。

另外，多轮对话中LLM容易“遗忘”之前的约束条件。比如第一轮说了“负债率超过70%直接拒绝”，到第五轮LLM可能就忘了这个规则。解决办法是把关键规则放在系统提示词里，而不是放在对话历史里。系统提示词每一轮都会重新加载，不会被压缩掉。

4. 实操全流程拆解与关键步骤记录

4.1 环境准备与AgentArts项目初始化

在华为云控制台创建AgentArts项目的过程不复杂，但有几个配置项需要提前想清楚。

首先是区域选择。AgentArts目前支持多个区域，建议选跟你的数据源在同一个区域的实例，这样内网调用延迟低，也避免跨区域数据传输的合规问题。

创建项目之后，第一件事是配置工具库。我把信贷场景需要的工具分成了三类：数据查询类（征信、工商、司法）、文件解析类（流水解析、发票OCR）、规则计算类（负债率计算、评分卡）。每类工具在AgentArts里注册的时候，建议加统一的前缀，比如“credit_”、“parse_”、“calc_”，这样在编排的时候一眼就能看出工具的类型。

然后是模型选择。AgentArts支持接入不同的LLM。信贷场景我建议用推理能力强的模型来做交叉验证和规则判断，用响应快的模型来做资料采集和报告生成。实测下来，混合使用比全部用同一个模型在成本和效果上都更优。

4.2 资料采集智能体的搭建与调试

资料采集智能体的核心逻辑是：根据案件信息，判断需要调用哪些工具，按什么顺序调用，以及如何处理调用结果。

我给它写的系统提示词大致是这样的：

你是一名信贷资料采集专员。你的任务是根据案件信息，调用合适的工具获取客户资料。 可用工具： - credit_query: 查询征信报告，入参为身份证号 - business_query: 查询工商信息，入参为企业名称或统一社会信用代码 - bank_parse: 解析银行流水，入参为流水文件地址 - invoice_parse: 解析发票，入参为发票文件地址 采集顺序： 1. 先调用credit_query获取征信 2. 再调用business_query获取工商信息 3. 如果有流水文件，调用bank_parse 4. 如果有发票文件，调用invoice_parse 每个工具调用后，检查返回结果。如果返回为空或报错，记录错误信息，继续调用下一个工具。 所有工具调用完成后，把结果汇总成JSON输出。

调试的时候发现一个问题：LLM有时候会“自作主张”地跳过某个工具，理由是“根据已有信息判断不需要”。比如看到客户是企业法人，就跳过了工商查询。这在信贷场景是不能接受的，每个必查项都必须执行。

解决办法是在提示词里加一句：“无论你是否认为必要，都必须调用所有适用的工具。不允许跳过任何工具调用。”加了之后就没再出现过跳过的情况。

4.3 交叉验证智能体的规则配置

交叉验证是信贷审批里最体现专业性的环节。我配置了以下几类验证规则：

这些规则在提示词里以自然语言描述，LLM负责执行。但纯靠LLM执行规则有个问题：同样的输入，两次运行可能给出不同的结果。对于信贷场景来说，这种不确定性是不可接受的。

我的解决方案是“LLM+代码”混合模式。LLM负责从非结构化数据中提取关键字段，比如从流水文本里提取月均收入。提取完成后，把结构化字段传给一个代码工具来做实际的计算和比较。代码工具的输出是确定性的，这样就保证了规则执行的一致性。

4.4 报告生成与人工复核的衔接

报告生成智能体的任务是把前面所有环节的结果汇总成一份审批建议。我设计的报告结构包括：客户基本信息、资料采集情况、交叉验证结果、风险标签、审批建议。

审批建议分三档：建议通过、建议拒绝、建议人工复核。分档逻辑是：如果所有验证项都通过且无风险标签，建议通过；如果有高风险标签，建议拒绝；如果存在数据缺失或中等风险标签，建议人工复核。

报告生成之后，会推送到人工复核队列。复核界面里，审核员可以看到智能体的完整推理链路——调用了哪些工具、每个工具的返回是什么、验证规则是怎么执行的、最终建议是怎么得出的。这个可追溯性很重要，一方面让审核员能快速判断智能体的结论是否合理，另一方面在出现争议时也有据可查。

注意：智能体的输出永远只是“建议”，最终决策权必须在人手里。这不是技术限制，是合规要求。报告里要明确标注“本报告由AI智能体生成，仅供参考，最终审批决定需由人工做出”。

5. 常见问题与排查技巧实录

5.1 工具调用失败的高频原因与处理

在实际运行中，工具调用失败是最常见的问题。我整理了几种典型情况：

情况一：入参格式错误。LLM传过来的参数类型跟schema定义的不一致，比如schema要求string，LLM传了number。这种错误在调试阶段很常见。解决办法是在工具层面做参数类型转换，能转的就转，不能转的返回明确的错误信息让LLM重新生成。

情况二：外部API限流。征信查询这类接口通常有QPS限制。如果短时间内大量案件并发处理，很容易触发限流。我的处理方式是在工具层面加一个令牌桶限流器，超过阈值的请求排队等待，而不是直接失败。

情况三：返回结果过大。有些API返回的JSON有几百个字段，全部塞给LLM会超出上下文窗口。解决办法是在工具层面做字段裁剪，只保留智能体需要的字段。如果确实需要保留原始返回，就存到OBS，只把引用地址返回给智能体。

情况四：网络超时。这个前面提过，设置合理的超时时间和重试策略就能解决大部分问题。

5.2 LLM输出不稳定的兜底方案

LLM输出不稳定表现在几个方面：格式不对、内容遗漏、逻辑矛盾。针对每种情况我都有对应的兜底。

格式不对的兜底是“解析+重试”。如果LLM输出的JSON解析失败，把解析错误信息附加上去，让LLM重新生成。重试两次还失败的话，就降级到人工处理。

内容遗漏的兜底是“检查清单”。在提示词里附上一个必须包含的字段清单，LLM输出之后用代码检查清单里的字段是否都存在。缺失的字段让LLM补充生成。

逻辑矛盾的兜底是“交叉检查”。比如报告里说“建议通过”，但风险标签里有一个“高风险”，这就是矛盾。代码层面做一个简单的规则检查，发现矛盾就标记出来让人工复核。

5.3 性能瓶颈的定位与优化

原型系统跑起来之后，我发现单笔案件的处理时间在3-5分钟，其中大部分时间花在等外部API返回上。优化方向有几个：

一是并行化。资料采集阶段的几个工具调用之间没有依赖关系，可以并行发起。AgentArts支持并行工具调用，配置之后采集阶段的时间从平均90秒降到了35秒。

二是缓存。同一客户在短时间内重复查询的情况不少，比如客户补充资料后重新提交。对于征信查询这类结果在一定时间内稳定的接口，加了缓存之后重复查询直接命中缓存，省去了等待时间。

三是模型选择。报告生成这种对推理能力要求不高的环节，换用响应更快的轻量模型，单次生成时间从20秒降到了5秒。

优化之后，单笔案件的平均处理时间降到了90秒左右，对于辅助审批场景来说已经够用了。

5.4 常见问题速查表

6. 踩坑记录与实战经验总结

6.1 那些文档里不会写的细节

第一个坑是工具命名的冲突。AgentArts里工具名称是全局唯一的，如果两个项目用了同一个工具名会冲突。建议在工具名前加项目前缀，比如“credit_”、“loan_”，避免后期混乱。

第二个坑是上下文对象的序列化。上下文对象里如果存了datetime类型的数据，序列化的时候会报错。统一转成ISO格式的字符串再存，省去很多麻烦。

第三个坑是LLM对数字的敏感度。在提示词里写“负债率超过70%拒绝”，LLM有时候会把70.5%判断成不超过70%。解决办法是把阈值判断交给代码工具，LLM只负责提取数值。

第四个坑是并发情况下的状态隔离。多个案件同时处理时，如果上下文对象没有做好隔离，会出现A案件的数据跑到B案件里的情况。确保每个案件有独立的上下文实例，不要用全局变量。

6.2 关于智能体自主容错的几点体会

自主容错不是让智能体“随便试”，而是要有策略地处理失败。我的体会是：能重试的重试，能降级的降级，能标注的标注，实在不行的才中断。

重试要有上限，不能无限重试。降级要有记录，不能静默失败。标注要醒目，让下游环节和人工都能看到。中断要有交代，说清楚卡在哪里、已经完成了什么。

还有一点很重要：容错机制本身也需要被监控。如果某个工具的重试率突然升高，说明可能上游接口出了问题，需要及时排查。我在AgentArts里配了告警，重试率超过10%就发通知。

6.3 后续可以扩展的方向

这套原型跑通之后，有几个方向可以继续深入。一是接入更多数据源，比如税务数据、水电煤缴费数据，丰富验证维度。二是把审批结果反馈回智能体，做持续的提示词优化和规则调优。三是探索多模态能力，比如直接解析影像件里的文字和印章，减少人工录入环节。

信贷场景对准确性和合规性的要求决定了智能体只能做辅助，不能做最终决策。但把那些重复性的信息采集和交叉验证工作交给智能体，让审核员把精力集中在真正需要人类判断的环节上，这个价值已经足够大了。我在实际跑完整个流程之后，最大的感受是：智能体不会取代信贷审核员，但会用智能体的审核员，效率确实比不用的人高出一截。