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 交叉验证智能体的规则配置交叉验证是信贷审批里最体现专业性的环节。我配置了以下几类验证规则验证项数据来源判断逻辑异常处理收入一致性银行流水 vs 征信报告月均收入偏差20%标记异常记录偏差比例负债率征信报告总负债/年收入70%标记高风险计算具体数值企业存续状态工商信息状态非“存续”标记异常记录具体状态发票真实性发票记录 vs 合同金额、日期、抬头不一致标记异常列出不一致项司法风险司法查询存在被执行记录标记高风险记录案件数量和金额这些规则在提示词里以自然语言描述LLM负责执行。但纯靠LLM执行规则有个问题同样的输入两次运行可能给出不同的结果。对于信贷场景来说这种不确定性是不可接受的。我的解决方案是“LLM代码”混合模式。LLM负责从非结构化数据中提取关键字段比如从流水文本里提取月均收入。提取完成后把结构化字段传给一个代码工具来做实际的计算和比较。代码工具的输出是确定性的这样就保证了规则执行的一致性。4.4 报告生成与人工复核的衔接报告生成智能体的任务是把前面所有环节的结果汇总成一份审批建议。我设计的报告结构包括客户基本信息、资料采集情况、交叉验证结果、风险标签、审批建议。审批建议分三档建议通过、建议拒绝、建议人工复核。分档逻辑是如果所有验证项都通过且无风险标签建议通过如果有高风险标签建议拒绝如果存在数据缺失或中等风险标签建议人工复核。报告生成之后会推送到人工复核队列。复核界面里审核员可以看到智能体的完整推理链路——调用了哪些工具、每个工具的返回是什么、验证规则是怎么执行的、最终建议是怎么得出的。这个可追溯性很重要一方面让审核员能快速判断智能体的结论是否合理另一方面在出现争议时也有据可查。注意智能体的输出永远只是“建议”最终决策权必须在人手里。这不是技术限制是合规要求。报告里要明确标注“本报告由AI智能体生成仅供参考最终审批决定需由人工做出”。5. 常见问题与排查技巧实录5.1 工具调用失败的高频原因与处理在实际运行中工具调用失败是最常见的问题。我整理了几种典型情况情况一入参格式错误。LLM传过来的参数类型跟schema定义的不一致比如schema要求stringLLM传了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 常见问题速查表问题现象可能原因排查方向解决方案智能体不调用工具工具描述不清晰检查工具description是否具体补充工具用途和入参说明工具调用参数错误schema定义不严检查JSON Schema的type和required完善schema加参数校验输出格式不稳定提示词约束不够检查是否明确要求JSON格式强化格式约束加示例流程中途卡住状态管理有误检查上下文status字段流转修复状态机逻辑重复调用同一工具缺少去重机制检查上下文是否记录已调用工具加已调用工具列表报告内容矛盾缺少一致性检查检查报告生成后的校验逻辑加代码层面的规则校验6. 踩坑记录与实战经验总结6.1 那些文档里不会写的细节第一个坑是工具命名的冲突。AgentArts里工具名称是全局唯一的如果两个项目用了同一个工具名会冲突。建议在工具名前加项目前缀比如“credit_”、“loan_”避免后期混乱。第二个坑是上下文对象的序列化。上下文对象里如果存了datetime类型的数据序列化的时候会报错。统一转成ISO格式的字符串再存省去很多麻烦。第三个坑是LLM对数字的敏感度。在提示词里写“负债率超过70%拒绝”LLM有时候会把70.5%判断成不超过70%。解决办法是把阈值判断交给代码工具LLM只负责提取数值。第四个坑是并发情况下的状态隔离。多个案件同时处理时如果上下文对象没有做好隔离会出现A案件的数据跑到B案件里的情况。确保每个案件有独立的上下文实例不要用全局变量。6.2 关于智能体自主容错的几点体会自主容错不是让智能体“随便试”而是要有策略地处理失败。我的体会是能重试的重试能降级的降级能标注的标注实在不行的才中断。重试要有上限不能无限重试。降级要有记录不能静默失败。标注要醒目让下游环节和人工都能看到。中断要有交代说清楚卡在哪里、已经完成了什么。还有一点很重要容错机制本身也需要被监控。如果某个工具的重试率突然升高说明可能上游接口出了问题需要及时排查。我在AgentArts里配了告警重试率超过10%就发通知。6.3 后续可以扩展的方向这套原型跑通之后有几个方向可以继续深入。一是接入更多数据源比如税务数据、水电煤缴费数据丰富验证维度。二是把审批结果反馈回智能体做持续的提示词优化和规则调优。三是探索多模态能力比如直接解析影像件里的文字和印章减少人工录入环节。信贷场景对准确性和合规性的要求决定了智能体只能做辅助不能做最终决策。但把那些重复性的信息采集和交叉验证工作交给智能体让审核员把精力集中在真正需要人类判断的环节上这个价值已经足够大了。我在实际跑完整个流程之后最大的感受是智能体不会取代信贷审核员但会用智能体的审核员效率确实比不用的人高出一截。 
长河君 · 2026/10/9 12:49:08 · 阅读 1.2k 华为云AgentArts实战：金融信贷AI智能体容错控制与工具编排
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 交叉验证智能体的规则配置交叉验证是信贷审批里最体现专业性的环节。我配置了以下几类验证规则验证项数据来源判断逻辑异常处理收入一致性银行流水 vs 征信报告月均收入偏差20%标记异常记录偏差比例负债率征信报告总负债/年收入70%标记高风险计算具体数值企业存续状态工商信息状态非“存续”标记异常记录具体状态发票真实性发票记录 vs 合同金额、日期、抬头不一致标记异常列出不一致项司法风险司法查询存在被执行记录标记高风险记录案件数量和金额这些规则在提示词里以自然语言描述LLM负责执行。但纯靠LLM执行规则有个问题同样的输入两次运行可能给出不同的结果。对于信贷场景来说这种不确定性是不可接受的。我的解决方案是“LLM代码”混合模式。LLM负责从非结构化数据中提取关键字段比如从流水文本里提取月均收入。提取完成后把结构化字段传给一个代码工具来做实际的计算和比较。代码工具的输出是确定性的这样就保证了规则执行的一致性。4.4 报告生成与人工复核的衔接报告生成智能体的任务是把前面所有环节的结果汇总成一份审批建议。我设计的报告结构包括客户基本信息、资料采集情况、交叉验证结果、风险标签、审批建议。审批建议分三档建议通过、建议拒绝、建议人工复核。分档逻辑是如果所有验证项都通过且无风险标签建议通过如果有高风险标签建议拒绝如果存在数据缺失或中等风险标签建议人工复核。报告生成之后会推送到人工复核队列。复核界面里审核员可以看到智能体的完整推理链路——调用了哪些工具、每个工具的返回是什么、验证规则是怎么执行的、最终建议是怎么得出的。这个可追溯性很重要一方面让审核员能快速判断智能体的结论是否合理另一方面在出现争议时也有据可查。注意智能体的输出永远只是“建议”最终决策权必须在人手里。这不是技术限制是合规要求。报告里要明确标注“本报告由AI智能体生成仅供参考最终审批决定需由人工做出”。5. 常见问题与排查技巧实录5.1 工具调用失败的高频原因与处理在实际运行中工具调用失败是最常见的问题。我整理了几种典型情况情况一入参格式错误。LLM传过来的参数类型跟schema定义的不一致比如schema要求stringLLM传了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 常见问题速查表问题现象可能原因排查方向解决方案智能体不调用工具工具描述不清晰检查工具description是否具体补充工具用途和入参说明工具调用参数错误schema定义不严检查JSON Schema的type和required完善schema加参数校验输出格式不稳定提示词约束不够检查是否明确要求JSON格式强化格式约束加示例流程中途卡住状态管理有误检查上下文status字段流转修复状态机逻辑重复调用同一工具缺少去重机制检查上下文是否记录已调用工具加已调用工具列表报告内容矛盾缺少一致性检查检查报告生成后的校验逻辑加代码层面的规则校验6. 踩坑记录与实战经验总结6.1 那些文档里不会写的细节第一个坑是工具命名的冲突。AgentArts里工具名称是全局唯一的如果两个项目用了同一个工具名会冲突。建议在工具名前加项目前缀比如“credit_”、“loan_”避免后期混乱。第二个坑是上下文对象的序列化。上下文对象里如果存了datetime类型的数据序列化的时候会报错。统一转成ISO格式的字符串再存省去很多麻烦。第三个坑是LLM对数字的敏感度。在提示词里写“负债率超过70%拒绝”LLM有时候会把70.5%判断成不超过70%。解决办法是把阈值判断交给代码工具LLM只负责提取数值。第四个坑是并发情况下的状态隔离。多个案件同时处理时如果上下文对象没有做好隔离会出现A案件的数据跑到B案件里的情况。确保每个案件有独立的上下文实例不要用全局变量。6.2 关于智能体自主容错的几点体会自主容错不是让智能体“随便试”而是要有策略地处理失败。我的体会是能重试的重试能降级的降级能标注的标注实在不行的才中断。重试要有上限不能无限重试。降级要有记录不能静默失败。标注要醒目让下游环节和人工都能看到。中断要有交代说清楚卡在哪里、已经完成了什么。还有一点很重要容错机制本身也需要被监控。如果某个工具的重试率突然升高说明可能上游接口出了问题需要及时排查。我在AgentArts里配了告警重试率超过10%就发通知。6.3 后续可以扩展的方向这套原型跑通之后有几个方向可以继续深入。一是接入更多数据源比如税务数据、水电煤缴费数据丰富验证维度。二是把审批结果反馈回智能体做持续的提示词优化和规则调优。三是探索多模态能力比如直接解析影像件里的文字和印章减少人工录入环节。信贷场景对准确性和合规性的要求决定了智能体只能做辅助不能做最终决策。但把那些重复性的信息采集和交叉验证工作交给智能体让审核员把精力集中在真正需要人类判断的环节上这个价值已经足够大了。我在实际跑完整个流程之后最大的感受是智能体不会取代信贷审核员但会用智能体的审核员效率确实比不用的人高出一截。