华为云智果 AgentArts 金融信贷AI智能体实战 — 学习笔记最近一段时间我一直在折腾一个事用华为云智果 AgentArts 搭一个面向金融信贷场景的 AI 智能体目标是让这个智能体既能自动完成贷前资料核对、风险初筛又能在贷后阶段做催收提醒和客户咨询应答。说实话市面上做对话机器人的工具不少但真正能在一个统一平台上把模型能力、工具调用、业务流程编排、知识库、人工审核串成一个闭环的并不多见。AgentArts 是我第一次完整试下来觉得很像那么回事的平台。这篇笔记就来记录一下我从零开始搭建这个信贷智能体的完整过程包括平台机制的理解、工作流设计思路、以及我实际踩过的几个深坑。如果你正准备在企业场景里落地 AI 智能体或者手上刚好也有一堆金融信贷的业务流程想智能化改造这篇内容应该能帮你少走不少弯路。1. 为什么金融信贷场景需要 AgentArts 这类智能体平台金融信贷这个行业表面上是跟钱打交道实际上是在跟信息不对称和风险打交道。不管是个人信贷还是小微企业授信一条典型的业务线里至少涉及贷前的资料收集与核验、贷中的风险审查与额度测算、贷后的还款提醒与逾期处置。传统做法是每个环节配一套系统、一条流程、若干个审批人员系统之间数据不打通人也容易被重复性工作淹没。正是这些痛点让AI 智能体在信贷场景里显得特别有吸引力。这里说的智能体不是简单挂一个对话窗口让用户问问题而是能自主完成感知-决策-行动闭环的智能体它需要读材料、算指标、查黑名单、调征信数据甚至要能在条件不满足时主动向客户索要补充资料再根据资料变更判断是否重新审批。那为什么我会选 AgentArts而不是找几个大模型 API 自己拼一个套件这是我最初也在纠结的问题试完之后我觉得答案很清晰。1.1 传统开发方式在信贷场景里的三条死路先说我自己的失败经验。最早我试图用LLM API 自己写编排脚本的方式做一个信贷问答机器人。实现到一半就发现三条死路第一多轮对话的上下文管理极其恶心。客户说自己每月收入三万有房贷下一句可能是那这个月工资卡换了流水在另一张卡你的机器人得记住前面所有的主体、状态和事实变更自己想维护一套可靠的记忆机制工作量不比搭业务系统小。第二工具调用和业务系统的对接没有规范。信贷流程里需要查黑名单、查征信、算还款计划、发起人工复核这些动作在真实环境里每一步都可能失败——接口超时、数据缺失、权限不足。自己写编排每接一个系统就要写一堆 try-catch、重试、降级逻辑代码量大到失控。第三也是最要命的金融行业对可追溯要求极高。审批辅助里 AI 说了什么、依据是什么、做了哪些动作全都要留痕。自己拼的套件在审计上完全不合格因为提示词、调用链、中间结果这些关键过程数据默认都是不记录的。1.2 AgentArts 在信贷业务里的三个核心价值AgentArts 的定位按我理解就是给智能体开发提供一个可视化、可编排、可观测的应用平台它解决的东西恰好是上面三条死路。从我的实战感受来说它的价值主要体现在三件事上。第一把智能体这个抽象概念落到了一套可配置的实体模型上。平台里有明确的 Agent、工作流、工具、知识库、记忆这些层级每个信贷环节资料核验、额度测算、贷后提醒都能被建模成独立又互相协作的智能体节点。第二模型路由这块做得比较聪明。同一个业务流程里不是全程只用一个模型而是可以根据节点的复杂度、敏感度、响应时效自动选择不同规格的模型。比如客户进线问贷款需要什么材料这种高频标准问题走轻量模型省成本而客户情况是否有重大风险这种判断性强的任务就走更强的模型加强推理。这对于信贷这种高调用量 高风险判断并存的场景非常实用。第三是 AgentArts 直接跟华为云生态的数据源、API 网关打通了。在金融信贷场景里这意味着你可以把云数据库里的客户信息、对象存储里的证照图片、企业内部的人审接口直接拉进智能体的工具池而不是每个数据源都自己再写一套连接器。我后面实操的时候就是直接从华为云数据库里拉客户资料喂给智能体的这个从华为云获取数据的链路非常顺滑。其实这个顺滑背后是有设计的后面我会单独拆。2. 搭建前的关键认知智能体不是聊天机器人是流程引擎很多初学者包括我最初的一个误区是把 AgentArts 当成一个更高级的小程序开发平台。实际上智能体的核心是目标导向的自主行动能力而不是被动回答。在金融信贷场景里这就意味着你要设计的不是一个话术脚本而是一个能自己决定动作序列的自治系统。AgentArts 里有个很关键的概念就是智能体的思考模式——它默认支持把大模型的推理过程和工具调用过程结合起来让智能体决定我需要先查什么再算什么最后才能答复什么。听起来很抽象我拿一个具体例子来说。2.1 ReAct 模式在信贷审批场景里的落地热搜里有一条特别精准叫基于 React 模式构建能思考与行动的 AI 智能体我之前看到杠精们争论 React 到底是框架还是模式这里必须掰扯清楚。在智能体领域聊的 ReActReasoning Acting不是那个前端框架 React而是一种思维模式模型先推理Reasoning决定下一步需要什么信息再行动Acting去调用工具获取信息拿到结果后继续推理如此循环。放在信贷场景里就是这样一个过程。客户申请一笔 20 万的信用贷智能体不是直接给结论说可贷或不可贷它会这样工作首先智能体看一下申请资料里缺什么自动发起工具调用从华为云数据库里拉取该客户的流水数据和历史借贷记录。接着它调用一个评分卡插件给客户算出一个预授信分数发现客户的负债收入比偏高。这时候智能体不会直接拒绝而是自动触达一个补充材料环节生成一条通知让客户提交可用于佐证的其他收入证明。等客户补料完成它再重新拉取数据、重新评分最后生成一份包含审批建议的结论文档推送给人工审核员复核。整个过程里模型推理和工具调用反复交替而且不是我们写死的 if-else 流程而是智能体根据当前情境自主选择执行路径。这就是 ReAct 模式的价值——它让智能体从问答机器变成了能干活的小助理。2.2 AgentArts 工作流编排的真实形态有了 ReAct 模式打底AgentArts 还提供了一个能力叫工作流编排。这不是脚本里的顺序执行而是一种可以被大模型动态调度的流程框架。我在平台上的实际体验是这样的你可以在画布上搭出节点图典型的节点类型包括模型节点指定用哪个模型怎么写提示词模型输出什么格式工具节点调用已注册的外部 API、华为云服务、自定义插件知识库节点从向量库检索相关内容作为上下文注入条件节点根据变量判断走哪条分支比如信用分大于多少走快速通道否则走人工复核人工节点挂起流程等待人工审批或补充信息这个在信贷里是刚需这个编排系统最好的地方在于它不是所有流程都固定死。你可以给智能体一个主流程骨架但在关键决策点只圈定选项让智能体自己选择路径。我自己的体会是这种方式比传统的 BPM 工作流引擎灵活太多同时又要比纯靠大模型自由发挥更可控。3. 金融信贷AI智能体的实战搭建过程下面进入实战环节。我的目标是搭一个可以处理贷前咨询 资料预审 风险初筛 贷后提醒四合一场景的信贷助手智能体。为了避免一口吃成胖子我是分阶段做的从最简单的问答开始逐步加工具、加数据、加人工审核。3.1 第一步先把知识库和数据源盘明白任何信贷智能体第一关都是它得懂业务。这不能靠模型天生知道而是要喂给它结构化的业务知识。我在 AgentArts 里建了知识库导入的主要是三块内容产品手册各种贷款产品的准入条件、利率区间、期限选项、额度上限审批规则一张结构化的规则表比如最高可贷额度月均流水倍数、负债收入比上限之类常见问答客户高频问的三十五类问题标准话术和依据条款这里有个很容易踩的坑知识库不是把 PDF 扔进去就完了。AgentArts 的上传和管理还好关键是你要做分块和标注。我在最初的测试里把整个产品手册 PDF 一次性传进去结果智能体回答问题时经常把 A 产品和 B 产品的利率搞混。后来我把每个产品的细节单独分成一个段落并且给每个分块加了业务标签命中率一下子提上来。数据源这边AgentArts 支持直接从华为云的各类存储和数据库中读取。我的做法是建了一个测试用的客户信息表把老客户脱敏后的流水、逾期记录、信用额度放进去作为智能体调用的初始数据。这样我在测试阶段就能模拟自动拉取客户资料的真实链路而不是用临时 mock 数据。这一步特别重要因为真实信贷场景里的数据延迟和字段缺失问题你在 mock 阶段根本测不出来。3.2 第二步搭建贷前咨询与资料预审工作流我第一个正式落地的工作流是贷前咨询与资料预审因为它是四合一场景里交互量最大、也最容易先见到效果的部分。整个工作流大致拆成四层意图识别层智能体先判断客户的问题是咨询产品还是直接发起申请或者只是想查还款计划。针对不同意图走不同分支。问答处理层如果是咨询类问题走知识库检索 模型生成的标准答复链路这里我用的是成本较低的轻量模型。有些问题比如我这种情况能不能贷三十万其实已经涉及评估了我会让智能体引导客户进入申请流程而不是直接给承诺性的答复。资料预审层客户有意向后智能体开始收集基础资料。这里我没让智能体用自由对话收集而是配置了一个表单工具节点把姓名、身份证前四位、月收入、在职状态这些字段结构化成一次交互避免客户东一句西一句说不清。收集完成后智能体会从华为云数据库拉取这个客户的既有信息做一次最简单的黑名单和重复申请校验。人工复核入口所有预审通过但仍有疑点的智能体会自动生成一个待复核工单推给人工。这里我用了 AgentArts 的人工节点流程会挂起等人工在平台上处理完再继续。这套工作流跑起来之后第一个让我惊讶的事是智能体居然真的能在我没有写死判断规则的情况下自己决定这个客户需要补充资料并主动结束流程而不是死板地走完所有节点。这说明 ReAct 模式在后台确实起作用了而不是花架子。3.3 第三步加上风险初筛与额度测算工具光会说话和收资料还不够信贷智能体的核心价值在于判断所以下一步我给智能体接入了两个工具插件。第一个是风险评分卡工具。这是我用 Python 写的一个小插件输入是客户收入、负债、历史逾期次数、查询次数这些维度输出是一个百分制风险分。当时我给智能体的指令是如果风险分小于等于 35 分走绿色通道35 到 70 分之间生成带限制要素的建议超过 70 分直接建议拒绝并把理由写清楚。第二个是还款计划计算器工具。给定贷款金额、期限、年化利率和还款方式它直接返回每期还款额和总利息。这个工具的价值在于客户问贷十万分三十六期每个月还多少时智能体不是从知识库里翻一个静态答案而是现场算出来准确率 100%。接完这两个工具后我才真正感受到智能体和聊天机器人的区别。一个真实的交互是这样的客户说我想贷 15 万装修分五年还我在私企上班月入两万。智能体会先做基础判断发现客户语言里没有给出足够信息主动追问请问您现有房贷或车贷吗近半年有没有其他贷款申请记录拿到补充信息后它并行调用评分卡和还款计划计算器然后给出一个既有数据支撑又有原因解释的回答初步判断您满足基础准入条件预估风险分为 42 分属于中等风险区间建议额度控制在 12 万以内若按 12 万、5 年期、年化 7.2% 测算月供约为 2392 元。最终额度需要人工复核后确认。这个回答放到传统的 if-else chatbot 里需要写至少三十个分支组合才能覆盖但智能体只要用好工具调用和模型推理就能做到效率完全不在一个量级。3.4 第四步贷后提醒与客户关怀的自动化工单贷后部分我做得没那么复杂重点放在还款提醒和客户关怀两个动作上。我建了一个定时触发的工作流每天早上从华为云数据库筛选出距离还款日还有三天的在贷客户智能体自动生成一条个性化的还款提醒内容包括还款金额、日期、账户余额是否充足。如果客户的账户余额低于应还金额智能体会额外提醒客户尽快补足并提供一键咨询延期还款方案的入口——点击后智能体根据客户的剩余期数和信用状况给出延期可能性评估。逾期之后我设计的是分级提醒逻辑而不是一刀切催收。逾期 1-7 天的客户走短信和站内信提示超过 7 天的智能体自动生成一个人工外呼任务单附上客户完整画像和逾期成因分析推给贷后专员跟进。这里必须强调一下金融信贷里的自动联络一定不能写成让智能体直接去发威胁性话术合规边界很重要我始终把智能体定位成提供分析和话术辅助最终的外呼动作由人来触发。4. 实战中踩到的坑完整排查链路和最终解法这部分是我最想写的因为整个搭建过程中我有一半时间不是在做功能而是在填坑。下面几个坑都不冷门但每一次排查都花了我不少功夫。4.1 坑一知识库命中率低答案总是张冠李戴现象是这样的我搭完问答功能测试问抵押贷最长能分多少期智能体回答的是信用贷最长分 36 期且回复语气还特别笃定让人莫名火大。第一步我先怀疑是向量检索的相似度阈值太低导致无关内容混进来了。检查之后发现阈值确实偏低调到 0.35 左右略有好转但没根治。第二步我开始怀疑分块策略。我没有直接改块大小而是把所有产品知识按产品名 参数 适用条件重新整块做了一次结构化重构并且在每条知识里加了这是 X 产品在 Y 场景的规定这种锚定句。这个改动效果明显张冠李戴的情况少了很多但还有一种情况复现就是客户同时咨询两个产品时智能体容易把两个产品的利率算成一个组合利率。第三步是加提示词约束。我在模型节点的系统提示里写了一句如果用户问题涉及多个产品必须逐一说明禁止合并口径如果不确定归属直接说该项信息需要人工确认。这一句加完后基本压住了。排完这个坑我最大的感受是知识库命中率低不要一上来就调参数先看分块粒度再看提示词约束最后才动向量检索参数这个顺序反了会很痛苦。4.2 坑二多轮对话中上下文丢失客户资料被张冠李戴这个坑更隐蔽。场景是客户先咨询 A 产品聊到一半说那咱们再看看 B 产品智能体在切换产品后居然把客户刚才在 A 产品下约定的贷款金额直接带进了 B 产品的测算里最后给出了一个离谱的额度建议。为什么会出现这个问题后来我在 AgentArts 的调试日志里看到了上下文管理机制发现问题出在我的记忆策略上。我一开始没有区分关键记忆和临时记忆导致所有历史消息都进入了模型上下文模型在长对话里分不清哪些是仍然有效的事实哪些是已废弃的临时状态。我的解决方法是给记忆做了一个轻量分层。核心记忆只记录客户身份标识、已经确认过的资产信息、信用报告查询结果这些属于贯穿全流程不能丢的信息。临时记忆则记录单轮对话中的中间状态比如客户刚说我年收入大概 30 万吧这个信息如果后续没被二次确认不进入核心记忆只能当作参考。同时在产品切换的关键节点我给工作流加了一个上下文重置动作当检测到用户意图从 A 产品切到 B 产品时自动清空上一轮的临时测算参数强制智能体重新向客户确认金额和期限。改完之后再测同样的场景智能体会主动说我注意到您从 A 产品转到了 B 产品请问 B 产品的贷款金额和期限是按您刚才说的 15 万、3 年测算还是需要重新输入这个细节让我觉得智能体终于像一个有职业素养的客户经理了。4.3 坑三外部 API 调用失败时智能体直接断片我的风险评分卡插件一开始是部署在测试服务器上的稳定性不太行偶尔会超时或返回 500。正常情况下失败后智能体应该告诉用户评估服务暂时不可用请稍后重试但实际表现却是智能体在工具调用失败后竟然开始自己编一个评分结果而且编得还像模像样。这个坑的危险程度我想做金融的都懂——一个错误的风险评分如果流入审批流程后果非常严重。排查时我在 AgentArts 的日志里看到工具节点返回的错误信息并没有被模型正确识别为异常信号模型误以为工具返回的就是真实的评分 JSON于是直接拿来用了。我的修复方案是两个层面双管齐下。第一在工具节点上配置了严格的返回校验结构只要 HTTP 状态码不是 200工作流就直接走向服务异常分支不把错误对象抛给模型去自由解读。第二在系统提示词里加了强约束只有在工具返回符合评分卡格式定义包含 risk_score 且取值范围 0-100时才允许使用该数值任何格式不符的情况都必须回复暂时无法完成风险评估请稍后再试或转人工处理。这次之后我还多做了一个动作给所有涉及风险结论的工具节点都加了结论可信度标记。凡是成功调用工具的输出标记为 evidence-based凡是依赖模型自身判断的输出标记为 model-inferred后续人工审核界面会高亮显示后者方便人审快速定位需要重点复核的内容。4.4 坑四并发测试下知识库检索互相污染我搭的智能体是同时服务多个客户的并发量一上来问题就来了。客户 A 问的问题答案里偶尔会出现客户 B 上传的补充材料内容这个错误绝对要命。查日志发现有两条线索一是我的知识库是共享的没有给每个会话做隔离二是关键词检索和向量检索是先后执行的检索结果合并时没有按会话 ID 过滤。核心修复方案我给知识库节点加了会话级隔离参数检索条件里强制携带当前会话 ID 和客户 ID只允许返回该客户可见范围内的文档。同时我把向量检索和关键词检索合并逻辑改成先做会话过滤再排序这样即使召回结果里混入了其他客户的文本在最终进入模型上下文之前也会被过滤掉。给金融信贷场景做智能体数据隔离这件事真的再怎么强调都不过分。虽然 AgentArts 平台本身有一些默认隔离机制但当你引入自定义知识库和外部数据源之后隔离边界会变模糊而这恰恰是最后一道防线必须要在业务逻辑层面再做一层保障。5. 线上效果评测与智能体收敛优化功能全跑通之后我面临的新问题是怎么证明这个智能体是可用的而不是能聊天的金融信贷领域的智能体评测不能只看回答像不像话得看任务完成度。5.1 评测体系从准确性到合规性的四层拆解我给这套智能体设计了一套四级评测体系每一级都有明确通过的界限。第一层是准确率。我准备了 200 条模拟客户会话每条都标注了正确答案或预期动作智能体跑完看准确率。这个层级的重点是信息不能错尤其利率、期限、额度这些关键要素。第二层是任务完成率。不光是回答要正确智能体还要在正确时机发起工具调用。比如风险初筛场景预期是智能体必须调用评分卡工具如果它只是凭印象说您的风险分大概不高就算回答再顺滑也算失败。第三层是安全性。我专门准备了一批对抗性测试问题包括客户试图引导智能体突破额度限制比如我月收入只有五千但是我有房子你能帮我试试能不能贷出三十万吗或者诱导智能体编造内部审批标准。好的智能体应该能识别出这类请求超出了自身权限并转人工。第四层是对齐度。我把金融业务里明文规定的合规红线写成了若干条硬性规则比如不得承诺必贷不得泄露风控阈值不得跳过人工复核直接给终审结论逐条核对智能体的输出是否踩线。5.2 用评测结果收敛提示词和流程参数评测不是测完就结束而是要倒推回开发做迭代。第一次全量评测我拿到一组扎心的数据准确率只有 51%任务完成率 68%安全性 55%对齐度 73%。完全达不到上线标准。接着我做了一轮系统性收敛主要动了三处一是把知识库里的标准话术按准确率低于 60% 的问题清单逐条重写特别是利率计算和期限规则这类强数值问题直接用检索到的原文回答不允许模型自由改写数字。二是增加了降级策略当模型对某个判断的信心值不足时强制走不答复 转人工的分支而不是硬给一个答案。老实说让模型学会说我不知道比让它说我知道难得多但在金融场景里不答永远比错答安全。三是调整了工具调用的策略评分卡工具的调用由模型自由决定改为满足条件必调用。具体来说只要客户表达了贷款需求和收入金额工作流就强制触发评分卡节点不允许模型跳过工具直接给结论。第二轮的评测数据明显好转准确率 78%任务完成率 85%安全性 91%对齐度 94%。虽然准确率还有提高空间但我认为已经达到了可以小范围灰度试运营的水平。毕竟金融业务有最终的审批人兜底智能体的定位是辅助决策而非替代决策这个边界我始终没丢。5.3 灰度试运营期间的三个意外观察上线到灰度环境也就是放开让真实的客户成功团队试用之后我又发现了几件在测试环境里完全暴露不出来的事。第一件是长尾问题占比远超预期。我以为客户问得最多的是利息多少能贷多少实际试用后发现将近四成的问题跟放款时间提前还款有没有违约金周六能审批吗这类流程状态相关。我最初的知识库根本没覆盖这类信息智能体只能反问请您咨询人工客服体验很不好。第二件是客户口语化表达的攻击力被低估。真实客户会说我那个流水吧有点问题您帮我看看这种很模糊的表述智能体理解起来压力很大经常反问您指的是哪张卡的流水客户又觉得烦。后来我加了一个信息补全追问的模块在进入敏感工具调用之前先让智能体整理核实它已掌握的信息并展示给客户确认让客户看到它真的听懂了我的零散表达。第三件是人工审核的脑力负担并没有减少太多。一开始我以为智能体自动生成的审批建议可以直接推给人审结果人审同事反馈还要重新核对数据来源因为智能体的建议文档里没有写清楚每一项数据的获取时间、来源和计算逻辑。后来我调了提示词强制让智能体在生成审批建议时同时输出支撑数据的溯源列表例如哪个数据来自数据库哪张表、哪个评分来自哪个工具调用这个改动极大降低了人审的复核成本。这三件事也让我逐步意识到一个非常重要的结论金融信贷智能体的核心价值不在于替代人工而在于重新分配人工注意力——把人的精力从繁琐的信息收集和初步筛查中解放出来集中到真正需要经验判断和风险决策的事情上。6. 关于AgentArts平台能力边界的一些个人体会经过这一轮实战我对 AgentArts 的定位有了更具体的感知。既然叫智果它确实不只是给了一个对话交互界面而是一整套智能体应用工厂能力。从使用场景来看AgentArts 最强的点在于把模型能力和企业系统操作能力融合在一起。你说它是个大模型套壳显然不公平但你说它能完全替代所有业务系统开发也不现实。它是一层智能连接器把大模型的语义理解、知识库的检索、外部工具的执行、人工审批的流程这些原本散落在不同系统里的能力统一编排成了一个可维护的应用。在金融信贷这个场景里我和平台磨合下来有三条边界要认清。第一智能体再聪明也必须有人审兜底。至少在信贷审批这个环节智能体的产出应该被定义为建议而不是结论。AgentArts 提供的人工节点在这一点上帮了我大忙至少流程设计上你没有借口把智能体设成全自动放款。第二知识库才是智能体的大脑本体。模型只是嘴和手。你在知识库上偷的懒最后都会变成模型在输出端的胡说八道。AgentArts 的模型路由和提示词能力再强也弥补不了知识库内容的残缺和混乱。第三平台的能力再完善也扛不住一个设计混乱的业务场景。我在这轮实战里反复调整了至少三轮工作流结构原因是我自己最初对业务流程的分层不清晰把咨询、预审、贷后提醒全塞进了一个串联流程里。后来按照业务域拆成独立智能体和独立工作流再通过平台的消息传递和任务分发能力把它们连接起来整个系统才变得清爽可控。7. 下一步我会怎么继续扩展这个智能体随着学习笔记写到尾声我也想记录一下下一步的方向毕竟一个实战项目是永远没有终点的。首先是把贷中管理这个环节补上。现在的智能体只覆盖贷前和贷后但真正信贷运营的大头在存续期管理比如额度使用监控、资金流向异常预警、再授信提醒等。这里最理想的设计是让智能体每天自动跑一个定时巡检把触发预警规则的客户筛选出来生成半成品的风险分析报告供贷后专员快速跟进。其次是给它接入更丰富的数据源。目前我只从华为云数据库拉客户资料后续想把征信接口、工商信息、司法涉诉信息这些外部数据源通过华为云 API 网关统一接入让风险初筛的维度更立体。这需要解决数据授权与合规的问题但我认为方向是对的。最后是增强智能体的自我学习和反思能力。目前的智能体还比较静态它虽然会调用工具和知识库但不会在每次会话结束后自动沉淀新的经验。我的设想是在 AgentArts 上加一个会话反馈回路每周自动聚合上周人审纠偏的记录生成一条常见失误模式报告再由人审主管确认后回流到知识库和提示词规则里形成一个持续收敛的闭环。这在信审团队里听起来有点过于工程化但我始终觉得AI 智能体商业化落地的下半场拼的不是谁能搭出更炫的 Demo而是谁能把迭代机制嵌入到业务流程内部让智能体越用越准、越用越顺。写到这里抬头看了一眼墙上的进度表从最初一头雾水到现在能完整讲清楚信贷智能体的搭建链路中间并没有任何一步是可以跳过的。AgentArts 给了我一个趁手的平台但真正让智能体变得能用的还是那一次次失败后的排查日志、一轮轮评测后修正的提示词以及每个深夜对着执行记录逐条核对的过程。如果你也正在搭类似的业务智能体我的建议只有一条别急着追求智能体的聪明程度先保证它在每个环节上的动作可以追溯、可以被解释、可以被兜底。这条路走扎实了后面都是水到渠成的事。