做了这么久金融信贷风控系统我一直觉得传统规则引擎和人工审批的组合有点“笨重”规则写死了、人员流动大、口径不统一尤其在处理非结构化文本上更是吃力。最近团队把信贷进件和审批辅助流程搬到了华为云智果 AgentArts 上用 AI 智能体把“资料核验、反欺诈初筛、信用评估辅助、额度测算解释”串成一条自动化链路跑了几轮灰度实测下来效果和踩坑都相当有代表性。这篇笔记就把我们怎么拆业务、怎么编排智能体、怎么做容错和监控的完整过程记录下来给同样在金融信贷场景里折腾 AI 落地的朋友一个参考。这篇内容更适合三类人一是正在做信贷审批流程自动化的风控或研发同学二是刚接触 AgentArts、想找一个“能把 LLM 真正用进生产”的切入点的技术人三是做 AI 产品设计、想知道智能体在强合规场景里该怎么约束和兜底的产品经理。我会尽量把思路、配置细节和排障过程都写清楚不绕弯子。1. 金融信贷智能体的核心思路与AgentArts产品定位1.1 信贷场景的痛点正好是AgentArts擅长的事信贷业务天然适合智能体介入但这里的“适合”不是因为它能写诗聊天而是因为它需要大量“阅读理解规则判断多系统联动”的动作。传统进件流程里客户提交身份证、流水、征信报告业务员要把几十页 PDF 里关键信息抠出来填进系统再对照准入规则逐条判断最后还要写一段审批意见。这个过程表面上是“信息录入”实际上是一个多步骤决策推理过程先理解材料再提取关键要素再匹配规则最后输出结论。人来做的问题很明显一是慢二是不同人对同一条规则的理解有偏差三是材料里的隐含风险全靠个人经验根本沉淀不下来。AgentArts 刚好切中了这几个痛点。它做的是把大模型的能力阅读理解、归纳、生成解释和业务规则、外部工具、内部系统编排成一个个可执行的智能体任务。比如一道“自动识别客户收入稳定性”的任务传统代码需要写正则、维护关键词表、适配各种格式的银行流水而用智能体可以让 LLM 先去理解流水 PDF再交给一个数值计算工具去统计波动率最后把结论填进结构化字段。这套组合不是简单“提示词API”而是带状态、带工具、带规则约束的工程化编排。另一个关键点是可追溯性。信贷场景不能接受模型“凭空给个分数”每一步都要能回溯为什么判定这个客户风险偏高、哪份材料触发了警示、依据的是哪一条制度规则。AgentArts 的工作流结构天然适合做这件事因为每个节点都有输入输出日志大模型的每次推理也都能被记录和审计。这是它和直接调一通裸 LLM API 最大的区别。1.2 AgentArts 的核心组件与概念扫盲我在实际操作里的理解是AgentArts 本质是一个“AI 智能体的托管运行平台 可视化编排平台”。它围绕几个核心概念运作智能体Agent一个完整的任务执行单元有自己的系统提示词、模型配置、可用工具列表、知识库挂载以及允许触发的动作范围。一个信贷审批流程里可以拆出好几个智能体比如“资料解析智能体”“反欺诈初筛智能体”“额度测算解释智能体”。工作流Workflow把多个智能体、工具、人工审批节点串起来的有向流程。你可以在画布上拖节点、连边、定义条件分支类似一个低代码的流程引擎但每个节点的执行体可以是一个大模型调用。工具/插件Tool智能体可以调用的外部能力包括 HTTP API、数据库查询、规则引擎、OCR 识别等。AgentArts 里注册工具时需要声明输入输出 Schema这很重要后面我会讲为什么。知识库Knowledge Base用来挂载非结构化制度文档、产品手册、历史审批案例。系统会自动切片和向量化智能体在回答时基于知识库检索而不是靠模型“死记”。模型网关Model Gateway统一管理模型接入可以配盘古大模型也可以接入其他开源/商用模型支持按场景路由比如高风险判断走更保守的模型文本解析走更快的模型。理解了这五个概念基本就能看懂 AgentArts 的 90% 界面。实际项目里最难的不是节点拖拽而是“业务规则和模型边界的设计”也就是后面要展开的工作流规划。1.3 传统方案 vs AgentArts 方案的差异为了讲清楚为什么最终选了 AgentArts我列了一张对比表记录我们在选型评审时反复讨论过的几个方向维度纯规则引擎传统RPA 代码裸LLM API调用AgentArts 智能体编排文本理解能力弱依赖正则和关键词弱只能按固定模板处理强但容易失控强且可被工作流约束流程灵活性改规则要发版改脚本要排期无固定流程可视化调整实时生效可追溯性有日志有日志只有对话记录节点级日志全链路审计稳定性保障高高低幻觉、超时中高可加容错兜底业务口径一致性强强差每次回答可能不同可通过提示词和规则约束交付速度中等慢快但不生产可用快且生产可用实际对比下来纯规则引擎做不了非结构化材料解析裸 LLM API 又扛不住审计和稳定性要求RPA 则太僵硬。AgentArts 的定位正好卡在“智能”和“可控”之间这也是我们决定深挖它的核心原因。2. 信贷智能体的业务逻辑拆解与工作流设计2.1 先把信贷全流程拆成智能体能理解的任务在打开控制台拖节点之前我们花了两周做业务流程拆解。信贷全生命周期大致分这几段营销触达、客户准入、资料收集与核验、反欺诈初筛、信用评估、额度利率测算、签约放款、贷后监控、催收管理。不是所有环节都适合用智能体我的判断标准很简单这个环节是否需要“理解非结构化信息做决策判断联动多个系统”。纯事务性的动作比如推送短信、生成合同文件交给普通服务就好没必要让大模型介入。我们一期项目圈定了三个场景智能资料初审、反欺诈辅助识别、审批意见自动起草。三个场景串起来正好覆盖“进件→初筛→审批辅助”的主链路。拆解任务时有个经验不要让一个智能体做太多事情否则系统提示词会变得无比复杂模型行为也难收敛。更合理的做法是按业务职责拆成多个小智能体各自负责单一任务再通过工作流把它们串起来。比如“资料初审智能体”只负责“识别材料完整性和内容一致性”它不需要知道反欺诈规则不管是写提示词还是做容错都轻松很多。2.2 客户准入阶段资料核验与反欺诈的编排细节客户准入是我们设计的第一个工作流它要完成的任务包括接收客户上传的身份证、收入证明、银行流水、征信报告做 OCR 识别、信息抽取、格式校验、一致性比对然后输出一份“进件初审结果表”。这个流程在 AgentArts 里被编排成了一条包含八个节点的链路事件触发节点监听到业务系统推送的“新客户进件”事件后启动流程。资料解析节点调用 OCR 工具把 PDF/图片转为结构化文本这一步用的是华为云 OCR 服务身份证识别、银行卡识别都是现成的 API。LLM 抽取节点让大模型从解析后的文本里抽取关键字段姓名、证件号、月收入、工作单位、流水波动等输出为 JSON。这里有个关键细节AgentArts 的 LLM 节点支持配置字段级输出 Schema模型必须严格按 Schema 输出否则节点直接报错。这样就把“模型自由发挥”的坑堵死了一半。规则校验节点对抽取结果跑一套准入规则比如年龄区间、收入门槛、资料是否齐全。这个节点不调用模型直接用规则引擎执行保证确定性。一致性比对节点身份证上的姓名和征信报告上的姓名是否一致、流水上的入账方和雇主名称是否匹配。这一步我们让 LLM 做了“模糊判断”因为很多材料上的写法并不规范需要靠语义理解而不是字符串匹配。黑名单查询工具节点调用内部黑名单 API把身份证号和手机号送过去比对。人工复核节点对规则校验或一致性比对未通过的案件转人工处理。这个节点在 AgentArts 里被配置成“暂停等待人工输入”可以指定审批人在平台上直接查看上下文并填写复核结论。结果输出节点把整个流程的中间结果汇总成标准 Json 结构推送给下游审批系统。这里特别说一下第 3 点的 Schema 约束。我们第一次测试时没配这个字段级 Schema结果模型把“月收入”输出成“21,000元左右”把“雇主名称”输出成“某知名互联网公司”好看是好看但根本没法直接入库。后来把所有抽取字段都改成 enum 和 string 类型并且加上了“找不到对应信息则输出空字符串”的指令模型输出才变得规整可用。凡是模型输出要进数据库的一定在 AgentArts 节点里定义清楚 Schema最好是 json schema 校验级别而不是“请按照格式输出”这种软约束。反欺诈初筛则是在准入流程之上加了几个特殊节点设备指纹工具识别同一设备多次申请、多头借贷查询工具查客户在多个平台的申请记录、关联黑名单图谱工具。我们让“反欺诈初筛智能体”去编排这几个工具的调用顺序它会根据前一步结果自主决定是否继续查关联图谱。比如身份证命中黑名单就不再浪费时间调多头借贷接口直接转向人工复核。这种“会看情况掉头”的能力是传统硬编码流程很难做到的地方也是我们觉得智能体真正有价值的点。2.3 审批决策阶段如何让“规则模型LLM”各司其职到了审批决策环节最大的问题不是“让模型给结论”而是“给结论一个可解释的依据”。我们的方案是把决策过程拆成三层第一层是强规则比如“征信存在当前逾期直接拒绝”“年龄超过 60 岁需要增加担保人”。这类规则和模型无关必须硬编码不能交给 LLM 判断因为它承担不起这个确定性责任。第二层是量化模型也就是传统评分卡。我们训练了一个简单的信用打分模型输入维度包括收入负债比、征信查询次数、历史还款记录、工作稳定性等输出 0 到 100 的分值。这个模型跑在独立的推理服务里AgentArts 通过注册一个模型调用工具来使用它。第三层是语义判断和解释生成这层才轮到 LLM。比如客户提交了一份手写情况说明解释征信上为什么有一笔逾期模型需要阅读这段文字结合上下文判断解释是否合理然后生成一段“审批建议摘要”给到人工审批人。AgentArts 在这个环节的价值体现在工作流的条件分支和并行节点。我们把它编排成评分卡模型分数低于 40 分直接拒绝不进入 LLM 环节分数在 40 到 70 之间同时触发 LLM 解释分析和规则复核分数高于 70 且无任何命中项自动通过并生成“简化审批意见”。这套流程跑下来大概 35% 的案件可以全自动通过45% 进入人工复核20% 直接被拒人工审批量比之前少了差不多一半。不过也提醒一句这个比例是拿历史数据反复调阈值调出来的不同信贷产品差别很大。小额信贷可以更激进房贷这种大额低频产品建议把自动通过比例压到 20% 以下。灰度期间别追求全自动率优先保证复审率等模型和规则稳定了再逐步放开。3. 华为云 AgentArts 实操从零搭建信贷智能体3.1 环境准备与智能体的创建流程实操部分我按我们实际建项目时的操作顺序写一遍方便你照着走。第一步登录华为云控制台在 AI 服务或应用构建分类下找到 AgentArts不同期的控制台菜单位置可能会有调整建议直接搜索关键字。进入后先创建一个“项目空间”把整个信贷智能体工程都放在里面后面创建的工作流、智能体、工具注册都归到这个项目下这样做的好处是权限和审计日志可以按项目隔离。第二步创建一个智能体。创建时主要填四个东西智能体名称和描述、系统提示词System Prompt、模型配置、可用工具列表。系统提示词是重中之重后面单独讲。模型配置我们选了盘古大模型的一个推理实例并把温度参数调成了 0.1这是为了减少随机性。信贷场景所有判断类输出我都建议把温度压到最低因为创造性在这里是敌人不是朋友。第三步在智能体下挂工作流。这里有两种模式一种是“单智能体自主规划”就是你只给它一堆工具让它自己决定怎么调适合探索性的业务另一种是“编排模式”在画布上显式拖出每个步骤。我们生产场景基本只用了编排模式因为信贷流程不允许模型“自由发挥”顺序节点的先后是有业务强依赖的。AgentArts 上可以把一个智能体“绑定”到一个工作流里的指定节点这样既能用工作流控制流程又能在单个节点内给模型留一些自主决策空间比如自己决定调用哪些反欺诈工具。第四步做节点之间的数据传递配置。每个节点都有输入输出定义上游节点的输出会按字段映射到下游节点的输入。第一次用容易忽略字段类型匹配比如上游把“年龄”输出成字符串下游规则校验节点要的是整数运行时会直接报错。AgentArts 里可以配置一个“数据预处理节点”在传递前做类型转换和缺失值填充这个节点我们后续加了十个左右很值得用。3.2 工具调用、知识库与模型选型配置工具注册这块是 AgentArts 实操里最需要细心的地方。在“工具管理”页面点“注册工具”支持三种方式标准 API 导入填 URL、请求方法、Header、Body、OpenAPI 规范文件自动导入、Function Call 方式接入自定义代码。我们的大部分内部服务走的是 OpenAPI 导入华为云自身的 OCR、人脸核身等服务则直接选了预置插件。这里有个特别容易踩的坑AgentArts 的 LLM 节点在调用工具时对工具返回的响应体长度有限制一般超过 10 万字符的返回会被截断。但银行流水解析出来的 JSON 往往很大直接塞给模型会丢信息。我们当时的解决方案是在 OCR 解析和 LLM 理解之间加一个“压缩工具”先把流水明细聚合成月度汇总再统计转入转出笔数、大额交易次数、工资入账规律等结构化指标把十几万字压缩成几十行的摘要再交给模型做判断。这个思路后来成为整个项目数据交互的基本原则能预处理就不要让模型看原文能算摘要就不要让模型读明细。知识库配置相对简单但要注意“切片粒度”。我们上传了行内信贷审批手册、产品准入办法、历史审批意见案例系统默认按 500 字切片实际跑下来还是偏大很多审批规则分布在一个章节的不同段落里切片后语义被切断。后来改成了按标题层级切片并让知识库的检索字段支持跟业务标签联动比如“收入认定规则”这个标签能精确命中对应的制度片段。模型回答的依据会带上引用来源人工复核时点开就能看到原文这个功能在审计场景里非常加好感。模型选型上我们测试了盘古和几个开源模型最终生产用了盘古做判断解释类任务因为它在中文金融文本的指令遵循度上确实更稳。不过也保留了备用模型通道一旦主模型接口抖动模型网关可以切到备用模型只是延迟会高一些。在 AgentArts 里做模型选型不要只看跑分或演示效果要针对自己的 50 条典型 case 做回归测试把“指令遵循率”和“Schema 合法率”当 KPI而不是凭感觉。3.3 LLM 自主容错控制构建可靠 AI 系统的工程实践这一节是我们在实际生产中花时间最多的地方也是我觉得 AgentArts 这类平台最考验工程师水平的地方。LLM 的能力再强本质还是一个概率模型会超时、会输出错误格式、会产生幻觉、会在工具调用链路上卡住。所以智能体进生产前必须做一套完整的容错控制方案。第一个是超时和重试。AgentArts 工作流里每个节点都可以设置超时时间和重试次数。我们一开始把重试策略设成“失败即重试”后来发现模型节点偶发的限流误报会触发重试风暴把本来就紧张的额度拖垮。改成了“指数退避重试”第一次重试等待 1 秒第二次 4 秒第三次 16 秒超过三次直接转人工处理节点。在信贷场景宁可让用户多等 20 秒进入人工也不能让流程卡在一个重试循环里不可自拔。第二个是降级兜底。我们给工作流设计了两套执行路径主路径是“OCR - LLM 抽取 - 规则引擎”如果 LLM 抽取节点连续失败三次会触发降级跳过 LLM直接把 OCR 原始文本转发给人工预审队列。这样虽然自动化率掉了但业务不会中断。AgentArts 的条件分支节点支持这种“失败跳转”逻辑我强烈建议你在设计流程时先画一张“故障链路图”标出哪几个节点挂了会导致进件中断提前设计好每一条故障路径的逃生通道。第三个是输出自校验。我们在很多节点后面挂了一个轻量的“校验工具”用非常简单的正则和业务断言去检查模型的输出。比如“借款金额必须大于 0 且小于等于申请金额”“日期格式必须为 YYYY-MM-DD”任何一个条件不符合节点自动标记为失败并重新调用模型。这个机制看着很简单但它把模型输出的事故率降了一个数量级。举个例子模型经常把“身份证号”和“银行卡号”位置搞混这俩都是 16 到 19 位数字开头人眼看都会犯难但业务判断区别极大加了自校验之后这类错误至少不会再往下游流。第四个是上下文安全与敏感信息过滤。金融场景里大量数据涉及个人隐私我们通过 AgentArts 的代码节点和内置函数做了两层处理进件数据从上游进入工作流时先做字段级别的脱敏身份证、手机号、家庭住址这类高敏字段转成掩码格式只有要真正提交给外部服务时才在受控环节解封LLM 的输出也会再过滤一遍防止模型“学走了”不该输出的隐私内容。合规审计查的就是这个别在这一步省事。4. 实战部署数据链路、评分卡与可观测性4.1 从华为云获取数据的完整链路信贷智能体跑起来后比较核心的问题是怎么把数据稳定地喂给它。我们最终的链路是业务系统的进件请求通过 API 网关进入数据落一份到 GaussDB 作为主存储同时在 OBS 里存原始材料文件AgentArts 工作流启动后通过查询工具直连 GaussDB 拉取结构化客户数据通过 OBS 的预签名 URL 让 OCR 服务读取原始文件。这条链路里OBS 的预签名 URL 模式比让每个服务直接传文件字节流要稳得多既减少了大文件传输对内存的冲击也让文件访问具备了时效性控制。获取数据的方式我建议优先选“事件驱动”。AgentArts 支持配置事件源监听比如 GaussDB 里某张进件表有新记录写入、OBS 里有新对象上传都会自动触发对应工作流。比起轮询数据库事件驱动几乎没有延迟也不会因为轮询频率产生无谓的费用。但事件驱动的数据一致性要自己负责我们遇到过一次上游事务回滚后事件已经发出、导致工作流跑了一个“幽灵进件”的情况后来在上游业务代码里加了事件发送前的状态校验并且在工作流入口加了一道人会判断“该进件是否在有效状态”的检查双保险才堵住。数据格式层面最好以“标准字段列表”的方式定义输入。比如进件事件必须包含 client_id客户号、product_code产品码、apply_amount申请金额、material_list材料文件列表这几个字段缺失任何一个直接拒绝执行。这样做的好处是工作流里所有下游节点都默认这些字段一定存在不用做一堆空值判断上游系统想接入的时候照着字段列表改自己的消息体就行对接成本极低。4.2 信贷评分卡输出与额度测算的落地逻辑评分卡模型在 AgentArts 里是作为一个“模型服务工具”被调用的。我们在模型服务节点里定义了请求体和响应体的完整 Schema工作流运行到这里时会把前面节点抽取到的结构化特征拼成一条请求发给评分卡服务拿到 0 到 100 的分数再走后续流程。这个环节的实际难点不是调通接口而是分数阈值和策略的联动。AgentArts 工作流里可以配置条件分支每个分支挂不同的策略包。我们当时测了好几轮发现只按分数一刀切会导致很多“边际客户”处理失当。比如一个客户评分 62 分但他有稳定的公积金缴存记录实际资质比很多 70 分的客户还好只拿一分就拒掉太可惜。所以我们把分支设计成了“评分 增信标签”的组合判断评分低于 40 直接拒评分在 40 到 60 之间看有没有“公积金连续缴存满两年”“本行代发工资满一年”这类增信标签有则转人工复核而非直接拒没有则拒评分高于 60 直接进下一环节。额度测算的逻辑相对简单我们用的是“基准额度 * 评分系数 * 场景调整系数”的公式。基准额度按产品规定来评分系数是一张映射表场景调整系数由工作流里的规则节点根据进件场景动态计算。测算完成后智能体会生成一段解释文本把测算逻辑用客户听得懂的语言展开这个解释也进了给业务员看的审批工作台。实际跑下来业务员反馈最有价值的其实是这段解释他们说“以前看数字还要自己翻规则现在文字直接摆在那里复核快了不少”。4.3 监控告警、日志审计与灰度上线AgentArts 平台自带一定的基础监控比如工作流执行成功率、平均耗时、节点失败率但这些不够支撑信贷场景的审计要求。我们在工作流里主动埋了业务层面的监控点阶段耗时监控每个大步骤记录开始和结束时间戳汇总进 Prometheus。如果“OCR 解析”阶段平均耗时突然从 3 秒涨到 10 秒大概率是服务限流或文件质量出问题能在客户投诉前就发现。业务结果分布监控按小时统计自动通过率、人工复核率、直拒率。这个指标很有用一旦自动通过率飙升很可能某条规则被误改或模型行为漂移了要立刻查。异常进件明细日志所有走到降级、兜底、人工节点的进件都会写一份详细的 JSON 日志包含触发原因、节点日志、相关材料路径方便事后复盘和监管审计。日志审计这块AgentArts 会自动记录工作流里每个节点的输入输出这让我们在做“为什么这个客户被拒绝了”这类追溯时非常省力。但要注意自动日志包含敏感字段的原文我们在平台层开了日志脱敏配置确保查到的是掩码后的数据原始数据则加密存到独立审计库只有特定权限的人可访问。上线策略上我强烈建议用“影子模式过渡”。AgentArts 支持把工作流配置成双跑模式真实业务还是走老系统新智能体并行跑一份结果不写回业务库只落日志。我们影子跑了三周拿新链路的结果和人工审批结果对比统计一致率从 68% 慢慢调到 91%确认稳定了才切真实流量。一开始直接全量切换的话光审批口径的差异就能把业务团队吓回原始社会。5. 常见问题与排查技巧实录5.1 典型故障速查表三个月实测下来我们踩了不少坑挑几个代表性的记录成速查表方便大家之后遇到类似问题直接对照问题现象根因分析排查与解决方案工作流偶发卡住不往下走某段工具调用在等待第三方 API 响应但超时设置过长把所有外部调用统一设 10 秒超时重试改为指数退避超时后转人工兜底LLM 抽取的身份证号偶尔缺位图片清晰度差导致 OCR 漏识别OCR 环节增加清晰度检查低于阈值直接提示“材料模糊请重新上传”不再硬跑反欺诈工具的调用顺序不受控单智能体自主规划模式不适合有严格顺序要求的场景改为工作流编排模式显式定义每个工具节点只让 LLM 在“是否需要继续查关联图谱”这个点上做决策模型输出 JSON 偶尔多一个字段显式 Schema 未设定给所有 LLM 节点配置严格输出 Schema并加自校验工具做运行时断言审批意见里出现“建议批准”但评分模型实际为“拒绝”提示词里业务规则和模型输出矛盾时模型倾向迎合用户把决策类结果改为结构化字段输出禁止模型生成结论性文字只允许生成人工复核参考意见影子模式日志量太大存储成本翻倍每个节点全量日志被长期保留日志分级存储常规日志保留 30 天审计日志加密保留 3 年降低存储成本5.2 项目沉淀的几点避坑心得先说提示词设计。信贷智能体的系统提示词我建议写成“角色 任务边界 行为红线 输出格式”四段式不要写长篇大论的“你是一个优秀的信贷专家”这类空话对模型行为没有约束力。我们最终的提示词大致长这样你是一个信贷资料初审助理只负责从客户材料中提取信息并做一致性判断不得输出任何审批结论不得依据材料之外的信息做推测当信息缺失时输出空字段并标记 missing 原因输出严格遵循给定 json schema。写完之后我找了几条边界 case 去试探模型比如材料里夹杂一段“客户希望尽快批贷”的催促语看模型会不会因此放松一致性判断标准结果是约束在提示词里的红线基本都能守住。然后是数据脱敏的细节。很多人在 AgentArts 项目里只做“展示层脱敏”认为系统界面里不显示完整手机号就够了。实际上问题在日志和模型输入输出链路里完整数据会出现在工作流日志、调试信息、模型服务的请求体里每一个环节都可能泄露。我们在平台配了三层脱敏存储层字段级加密、链路传输层 JSON 字段过滤、日志输出层掩码替换。别嫌麻烦真出了合规问题前面省的所有事都会翻倍还回来。最后想聊一下成本和效率的平衡。AgentArts 按运行量和模型调用计费信贷进件高峰时段比如月初的工作流吞吐是平时的三到五倍费用也跟着涨。我们的做法是把区分“高价值复杂进件”和“普通小额进件”后者走轻量版工作流减少不必要的工具调用和模型推理次数费用直接降了四成。同时把评分卡这类确定性计算尽量挪到规则服务里能不用模型就不用模型省钱还更稳。我在实际做这个项目的过程中感受最深的一点是AgentArts 最终考验的不是模型有多聪明而是你有多懂自己的业务边界和故障模式。智能体把原来需要人工串起来的动作自动化了但设计、约束和兜底的责任全转移到了工程侧。每一次模型幻觉、每一次流程卡顿、每一次口径漂移都能通过工作流编排和容错设计在平台层拦截掉这才是 AgentArts 这类 AI 智能体平台真正的价值所在。如果你们团队也准备在信贷或类似强合规场景里引入智能体我建议第一步先别急着买资源、配模型而是把你现在的业务流程一条条列出来标出哪些节点必须“确定性”、哪些节点可以“智能化”。把这条线划清楚后面的路会好走得多。