最近在跑一批RPA数据处理任务时遇到一个典型困境30条数据摆在那里任务类型五花八门有简单的文本分类、有需要多步推理的复杂问题、还有几条要求稳定输出JSON格式的结构化抽取。搁在以前我肯定是一条条看内容、手动指定模型或者干脆全部丢给最强模型一把梭。但这次我用蓝耘的智能路由做了个尝试把模型选择这件事从脚本里彻底抽了出去让同一个RPA脚本自动切换模型跑完全程效果出乎意料地稳。先说结论这30条数据我原来的做法大概要分三类手动跑三轮耗时接近40分钟换成智能路由后一个脚本一次跑完耗时不到9分钟整体成本降了差不多一半。更重要的是脚本逻辑没有任何判断该用哪个模型的分支代码路由选择全部发生在云端。这篇文章就围绕这个实战过程把我怎么接入、怎么设计脚本、过程中踩了哪些坑全部拆开讲清楚。1. 为什么RPA工程师需要脚本不变、模型自选的能力1.1 RPALLM的常见痛点模型固定、成本失控RPA脚本接大模型最蠢也最常见的做法是在脚本里写死一个model字段。比如我用影刀RPA的HTTP请求组件去调某个模型的接口prompt拼好之后model参数固定填一个最强的模型名称。这样做的问题在数据一多就暴露成本浪费30条数据里可能有20条是这段文本属于哪个类别这种简单任务强模型处理这类任务和弱模型差距不大但价格可能是后者的十几倍。我算过一次同样一批快递单信息抽取任务用满血版模型跑下来的账单比用轻量版模型贵了将近17倍但准确率只提升了2个百分点。速度瓶颈强模型的生成速度通常更慢尤其在高并发时。RPA脚本跑数据讲究的是把流程顺下来一条数据等30秒和等3秒整个自动化流程的体感完全不同。维护成本高模型版本更新、旧模型下线、新模型上线脚本里的model字段就得跟着改。如果脚本分布在多台机器上改起来更是灾难。最尴尬的是第三种情况。我之前维护一个给客服部门用的RPA流程里面有30多个脚本文件都写死了同一个模型名。模型方突然宣布旧版本要下线我花了一个下午把所有脚本逐个改过来还要跑回归测试。那时候我就在想为什么不能让脚本只关心要处理什么而把谁来处理这个决策交给更聪明的一层1.2 智能路由的定位把选模型从脚本里抽出来蓝耘智能路由解决的核心问题就是把这个选模型的决策从脚本里剥离出来。官方说法是它可以根据请求内容、任务复杂度、上下文长度、甚至用户的成本预算偏好自动选择最合适的底层模型。实际用下来它的工作方式更像一个模型网关你的脚本只面向一个统一API端点只需要传prompt、传参数路由层拿到请求后会分析任务特征比如是不是代码生成、是不是数学推理、是不是简单问答再结合每个模型的实时状态和你的路由策略决定把这个请求转发给哪个模型返回结果时它会告诉你实际用了哪个模型以及消耗了多少token。对我们RPA工程师来说这意味着脚本和模型彻底解耦。我把智能路由看作一个模型调度中心它懂每个模型的擅长领域和价格而我只需要懂业务数据和流程编排。各管一摊互不干扰。更关键的是这种路由决策发生在云端不在本地脚本里。本地脚本不需要维护一份什么任务用什么模型的映射表也不需要安装额外的SDK。RPA工具只要能发起HTTP请求、解析JSON返回就能接入。门槛比我最初预想的低很多。提示如果你手头的RPA工具不支持Python扩展也不用担心。影刀、星辰这类主流RPA都自带HTTP请求组件纯靠组件也能完成整个接入只是对返回结果的容错处理需要多用几个条件判断组件来补。2. 蓝耘智能路由接入RPA的完整前置准备2.1 平台侧要配好的三样东西API Key、路由策略、模型白名单在写任何RPA脚本之前我建议先把平台侧的三样东西配置好。这个过程大概十分钟但对后续脚本的稳定运行影响很大。第一API Key。在蓝耘控制台的API密钥管理页面创建一个Key它会以sk-开头。创建之后记得立刻保存完整值因为页面关闭后就只能重置、不能查看原文了。这个Key就是脚本的身份凭证所有HTTP请求都要带上它。第二路由策略。这是智能路由的核心配置。我当时创建了一个叫混合批量任务的策略规则大致是优先级最高的规则如果检测到任务类型为结构化抽取并且要求输出JSON则路由到准确率最高的那个模型优先级第二的规则如果任务涉及多步推理或代码生成路由到推理能力更强的模型默认兜底其他任务路由到性价比均衡的轻量模型。这里有个容易忽略的点策略是有优先级顺序的。平台从上到下逐条匹配命中了就停止。所以一定要把最需要强模型的任务类型放在最前面否则容易被后面的兜底规则截胡。第三模型白名单。这个很多人会漏掉。如果你不配置白名单智能路由可能会在你不知情的情况下把请求路由到你预算之外的模型上。我个人的习惯是在路由策略里明确规定只有白名单内的模型可以被选中其他模型一律不参与调度。比如我这次只开放了三个模型一个轻量通用模型、一个强推理模型、一个支持JSON模式的结构化模型。既省心又可控。2.2 RPA侧要用到的两个组件HTTP请求组件与JSON解析RPA侧的准备比很多人想得简单。如果你用的是影刀RPA核心就两个组件HTTP请求组件用来发送POST请求到蓝耘的智能路由API端点。需要注意三点请求头必须带上Authorization: Bearer 你的API KeyContent-Type要设置为application/json请求体里只需要放业务参数不需要指定model。JSON解析组件用来从返回结果中提取实际响应文本。蓝耘智能路由的返回结构里最终的内容在choices[0].message.content这个路径下同时顶层会有model字段标明实际使用的模型名称。我第一次接入时最不习惯的就是不需要指定model这一变化。以前写脚本总要在请求体里写死model: xxx现在删掉了这个字段还要手动确认一遍是不是漏写了。实际上蓝耘智能路由的API设计里model字段是可选的你传了它也不优先使用除非你显式开启强制指定模型模式这个后面踩坑部分会详细讲。2.3 一个关键设计让路由策略跑在云端而不是本地这可能是整篇文章里我最想强调的一点。很多人一听到自动切换模型第一反应是那我在RPA脚本里写个判断逻辑先判断数据类型再决定调用哪个模型接口。这种思路恰恰是错的。如果你在脚本里做分支判断那你就把路由逻辑绑定到了本地代码上。一旦策略调整——比如你想让某类任务改用另一个模型——你得改脚本、发新版本、重新部署。这和我们解决脚本里写死model的初衷完全背道而驰。正确的设计应该是脚本只发请求路由决策完全交给云端。我在这次实践中脚本逻辑只有三步读取数据 - 拼接prompt - 调用智能路由API。至于这条数据该由哪个模型处理脚本一概不管。路由策略要调整直接在控制台改配置就好RPA脚本一行代码都不用动。这个设计还带来一个额外好处不同RPA机器人比如影刀和星辰各跑一个流程可以共享同一套路由策略只要大家都调同一个API端点即可。策略统一、口径统一、成本也统一维护成本直接下降一个量级。3. 同一个脚本自动切换模型的代码实现3.1 从固定模型到智能路由最小改动方案为了让大家看得更直观我把改动前后的代码逻辑写出来对比一下。改动前的固定模型调用方式假设用Python脚本影刀里通过执行Python代码组件调用import requests def call_llm(prompt: str) - str: resp requests.post( urlhttps://api.example.com/v1/chat/completions, headers{ Authorization: Bearer sk-your-api-key, Content-Type: application/json }, json{ model: super-strong-model-001, # 写死最强模型 messages: [ {role: user, content: prompt} ], temperature: 0.3 }, timeout60 ) data resp.json() return data[choices][0][message][content]改动后接入蓝耘智能路由import requests def call_llm(prompt: str) - dict: resp requests.post( urlhttps://api.lanyun.cloud/v1/router/chat/completions, # 智能路由统一端点 headers{ Authorization: Bearer sk-your-api-key, Content-Type: application/json }, json{ messages: [ {role: user, content: prompt} ], temperature: 0.3 # 注意这里没有 model 字段真正由智能路由调度的模型无需也无需在脚本中指定 }, timeout60 ) resp.raise_for_status() data resp.json() return { content: data[choices][0][message][content], actual_model: data.get(model, unknown), usage: data.get(usage, {}) }可以看到核心改动只有两点请求URL换成了智能路由端点删掉了model字段。其余prompt组织逻辑、返回解析逻辑基本不变。这也是我这次实践的初衷——用最小改动换来最大的灵活性。3.2 30条数据的任务类型分割与路由权重设定脚本改完后我把30条测试数据大致归了几类目的不是去脚本里写分支而是验证路由策略是否覆盖到了我所有的任务类型。分类如下简单分类任务12条商品评论情感正负判断、新闻标题领域分类等多步推理任务8条数学应用题、逻辑推理题需要模型给出分步解答结构化抽取任务10条从简历、发票、合同中抽取指定字段要求输出JSON。在路由策略里我为这三类分别设定了优先级和期望模型。这里有一个路由权重的概念平台支持为不同模型设置权重或优先级用于解决多个模型都满足条件时选谁的问题。我的个人经验是把准确率敏感型任务的权重集中在一个强模型上宁慢勿错把延迟敏感型任务的权重集中在轻量模型上宁快勿贵如果某个模型状态异常比如过载、限流路由平台会自动把流量分配到其他可用模型这个在权重设计时不用额外考虑平台负责处理。我当时的设置大致是结构化抽取任务的流量全部导向支持JSON模式的模型多步推理任务的流量70%导向强推理模型、30%导向通用模型简单分类任务全部导向轻量模型。3.3 路由结果的JSON结构解析与容错这是实战中花时间最多的地方。蓝耘智能路由返回的JSON结构和普通OpenAI兼容接口很接近但有几个字段需要注意{ choices: [ { message: { role: assistant, content: 实际回答内容 }, finish_reason: stop } ], model: light-model-003, usage: { prompt_tokens: 120, completion_tokens: 45, total_tokens: 165 }, router_info: { matched_rule: simple_classification, fallback: false } }我强烈建议在RPA脚本里把router_info这个字段解析出来打日志。因为智能路由的黑盒特性你必须在事后知道每条数据到底走了哪条规则、用了哪个模型。否则出了问题时你连是路由选错了模型还是prompt写得不对都分不清。容错方面我给脚本加了三层兜底HTTP层面请求失败时重试2次每次间隔3秒并使用指数退避策略业务层面如果返回内容为空或finish_reason不是stop重新调用一次路由接口prompt末尾追加请务必完整输出逃生舱如果同一数据重试3次仍然失败把原始数据写入一个failed_queue文件同时标记状态为待人工处理不阻塞后续数据。注意RPA跑批量数据处理时最忌讳的就是一条数据卡死整个流程。永远要设计失败队列让单条失败不影响整体进度。这个习惯帮我省了无数次半夜从床上爬起来处理流程中断的时间。4. 30条数据实测从逐条手挑模型到一把梭4.1 实测数据池设计混合难度样本为了公平对比我没有直接拿生产数据跑而是精心构造了一个30条的混合测试集。每条数据都提前标注了期望模型等级轻量/通用/强这样跑完之后可以对照路由的实际选择来评估准确性。数据池的构成是12条简单任务、8条中等难度任务、10条复杂任务。复杂任务里我又特意塞了5条要求JSON输出的结构化抽取目的是测试路由能不能识别需要JSON模式这个隐含需求。这里分享一个设计技巧测试集里一定要包含边界情况。比如我故意放了一条既是分类任务又要求输出JSON格式的数据用来测试路由策略里两条规则发生冲突时优先级设置是否生效。实测结果它走了优先级更高的JSON规则模型选择正确输出格式也规范。边界测试能帮你提前发现策略配置的漏洞别等上线了再被用户投诉。4.2 跑完后如何验证路由选型是否合理跑批结束后我把返回的model字段全部汇总和每条数据的期望模型等级做了比对。验证方法其实很简单三个维度第一看准确率。把模型输出和标准答案比对。如果某条简单分类数据被路由到了轻量模型但分类错误那我就需要判断是模型能力不够还是prompt需要优化。实测下来12条简单任务全部正确说明轻量模型足够胜任。第二看格式合规率。尤其针对结构化抽取任务我必须检查JSON是否能被直接解析。10条复杂任务里有9条输出为合法JSON1条输出中混入了多余的说明文字需要做一次后处理清洗。这个不是路由的问题而是目标模型偶尔会话多在prompt里强制加一句只输出JSON不要任何解释后问题基本消失。第三看延迟分布。我记录了每条数据的响应时长。轻量模型平均耗时约2秒强推理模型平均耗时约11秒结构化模型平均耗时约5秒。如果强模型被频繁塞给简单任务总耗时绝不会是9分钟这个量级。4.3 成本与耗时的对比数据直接上对比数据。同30条数据、同样的prompt设计三种处理方式的结果如下处理方式总耗时乐观估算Token消耗相对成本全部用最强模型约38分钟约12.6万基准1x手动分三类分别跑约40分钟含人工筛选耗时约8.4万约0.62x智能路由自动切换约9分钟约8.1万约0.53x手动分三类其实成本也不高问题在于需要人工判断每条数据的类型30条数据不算什么但如果是300条、3000条呢人工筛选的耗时和出错率都会指数级上升。智能路由的价值在数据量越大时体现得越明显——脚本完全不关心任务类型路由自动完成分类和模型选择我只需要在跑完后看一眼路由日志确认决策质量。我特别把手动分三类的耗时算了进去。不要只算机器运行时间人工介入时间才是RPA流程里最隐蔽的成本。去掉人工筛选的40分钟才是真正体现智能路由价值的9分钟。5. 踩坑记录RPA智能路由最容易翻车的四个细节5.1 API返回超时与重试机制RPA流程卡死的根源第一次跑通脚本后我直接在30条数据上全量运行结果在第14条数据卡住了。影刀那边显示的日志是HTTP请求超时整个流程停在那里等响应后面的数据全部排队阻塞。排查之后原因出在强推理模型在最坏情况下单次响应可能超过60秒而我设置的timeout60在边缘场景下不够用。更麻烦的是超时之后RPA流程没有进入错误分支而是停留在等待状态。我的解决方式分两步第一步把timeout调整到120秒从源头避免正常请求超时第二步在RPA流程里把HTTP请求组件放到一个错误捕获容器中一旦抛出超时异常就自动进入重试逻辑重试次数设为2次。这个坑的核心教训是RPA调用大模型API重试机制不是可选项而是必选项。大模型的响应时间天然波动训练负载高的时候一次正常的请求也可能慢得离谱。没有重试机制RPA流程就变成了定时炸弹。5.2 并发限制与排队策略别让30条数据变成30分钟跑完第一轮全量流程后我发现总耗时虽然比手动快但还是偏长。仔细看日志发现我的脚本是逐条同步调用的——前一条返回了才发起下一条请求。这是RPA脚本最容易犯的线性思维毛病。其实智能路由API支持并发请求只要控制好QPS上限就行。我把30条数据拆成5个并发批次每批6条。实测下来总耗时从25分钟压缩到了9分钟而且路由平台的吞吐完全扛得住。但这里有个前提必须确认你的API Key的并发配额。蓝耘的免费试用Key并发限制比较低我一开始用默认Key跑5并发直接触发了部分请求的429状态码。后来在控制台升级了并发配额才稳定跑满5路并发。5.3 返回结果的编码与截断问题第三条数据的返回结果在写入Excel时出现了乱码。排查半天问题出在两个环节一是RPA的HTTP请求组件在解析响应时没有显式指定UTF-8编码导致部分中文字符被错误解码二是没有对返回内容做长度截断检查某条生成结果超过了我在Excel表里预设的单元格长度上限。编码问题的解法很简单HTTP请求组件的响应类型选择文本并在后续代码中强制response.encoding utf-8。如果是纯组件式实现就在JSON解析组件之前先过一层文本编码转换操作。截断问题的解法在写入Excel之前先判断返回内容长度。如果超过2000字符截断并追加省略号同时在日志里标记内容可能不完整。原因是结构化的发票信息抽取偶尔会返回超长文本其中往往混入了模型自己生成的解释性内容——这也是我在前面提到的在prompt里强调只输出JSON不能完全杜绝必须靠脚本层面兜底。5.4 路由策略的越权风险什么时候必须强制指定模型最后这个坑最有意思。我在测试中发现有一条复杂推理任务被路由到了轻量模型输出结果质量明显下滑。查路由日志发现那条数据同时命中了默认兜底规则和多步推理规则——但因为我在策略配置里把兜底规则的优先级设得比推理规则高所以它走了兜底。这个问题本质上是策略优先级配置不当。但更值得记住的是智能路由适合兜底但强制指定模型是必要逃生舱。蓝耘平台的API支持在请求体中显式传model字段开启强制模式后路由会忽略策略规则、直接使用指定模型。我的实战建议是在RPA脚本里增加一个紧急参数入口。平时批量处理不传model完全依赖路由但当某条数据处理结果不理想时先在本地临时把这条数据标记为重试-强制使用强推理模型单独调用一次API并传入指定model。这相当于给自动化流程加了一个人工干预窗口不用改大流程却能精准兜住最大业绩风险。6. 关于路由策略运营的两个进阶经验6.1 定期看路由日志而不是只看账单很多RPA工程师接入智能路由后关注点全在省了多少钱上每个月拉一次账单看看消耗就完事了。但我建议你至少每周导出一次路由日志重点看matched_rule和actual_model的分布。为什么要看因为业务数据构成会变。比如我这个月跑的分类数据变多了那轻量模型的调用占比应该上升如果某周突然有大量复杂推理请求被路由到轻量模型说明策略兜底规则吃掉了太多流量你就该检查数据分布是否变化、策略优先级是否要调整。路由日志是观测业务数据变化的一个很独特的窗口。6.2 把路由策略拆成环境级和任务级两层我后来把路由策略做成了两个层环境级策略负责全局兜底比如所有测试环境的请求都走轻量模型任务级策略负责具体业务逻辑比如RPA脚本通过请求头里的一个自定义字段标识任务类型路由层据此匹配规则。这样做的好处是不同业务线的RPA机器人即使共用同一个API Key池也能各走各的策略。RPA脚本里只需要在请求头增加一个X-Task-Type字段即可路由平台按这个字段匹配任务级策略匹配不到再走环境级兜底。这个设计让我不用为每个业务线单独建一套API Key体系运维成本低了不少。7. 回头看智能路由到底解决了什么问题回到最初的30条数据。其实这30条数据本身不算什么大数据量但它非常典型地暴露了RPA大模型最常见的三个矛盾成本、速度、维护性。智能路由没有让模型本身变强也没有改变我的脚本流程它只是把一个原本需要人工在每个节点做决策的事情变成了云端的自动决策。对我个人而言最大的体感变化是以前调模型接口就像带着一张固定的通讯录出门碰见什么人只能找名单上那个联系人现在通讯录升级成了一个总机你只需要报需求总机会帮你转接最合适的人。脚本里的model字段消失了但任务的处理质量不但没有下降还因为专业模型干专业事而更稳了。如果你也在跑RPA大模型的批量处理流程且正在被一个模型打天下的成本或效果问题困扰我建议你先把手头数据的任务类型统计出来看看是不是真的适合智能路由。如果数据里确实混合了多种难度和多种类型的任务那接入智能路由的收益会非常直接——毕竟脚本不用大改路由策略先跑两周对比一下账单和耗时数据会告诉你答案。