企业官网建设流程全解析

做RPA批量处理数据，最怕碰到的情况就是同一批数据里“笨的笨、精的精”。我前阵子刚跑完一个小需求：从30条商品评论里提取情感倾向和退换货原因。表面上看是标准批量活儿，实际上每条评论长短、语病、信息密度完全不一样。有的就一句话：“质量差”，有的是几百字长篇反馈。麻烦就麻烦在：如果脚本写死一个模型，简单任务用大模型是浪费，复杂任务用小模型又会漏关键信息。后来我把“选模型”这件事交给了蓝耘智能路由，RPA这边只负责读数据、发请求、写回结果。同一个脚本，30条数据跑完，日志里看到至少5种不同模型被自动切换使用。整个过程很有代表性，我把细节整理出来分享给你。

这套思路的核心只有一句话：RPA负责流程，路由负责决策。脚本里面不写死任何具体模型名，把选择权交给智能路由层。后面我会从问题拆解、方案设计、关键配置、实战记录、报错排查几个方面把整个过程讲透。

1. 为什么“30条数据”也会遭遇模型选择难题

1.1 固定模型批处理的两个极端

很多人觉得才30条数据，随便用一个模型跑完不就行了？但我实际遇到的情况是，这30条评论的难度分布极不均匀。拆开看大概是这样：有3条超过300字的售后纠纷，逻辑绕，还有错别字；有7条中等长度，同时提到商品优点和问题；剩下20条一两句话就能说清。这种分布下，固定用一个模型必然要选一个平衡点。

如果选轻量模型，速度快、成本低，但面对那3条长纠纷时，经常漏掉“充电口接触不良”“售后不回复”这些关键原因，甚至会把负面情感判断成正面。如果选能力强的模型，20条简单评论也会按高价计费，耗时还多。关键是，这种“二选一”不是拍脑袋就能解决的，因为你不知道下一条数据到底有多复杂。

固定模型的另一个问题在于维护。你可能会想：那我在脚本里加个if-else，根据文本长度自己选模型不就行了？做过的人都懂，这种逻辑一开始能用，但随着数据变化就要不停调阈值。“多长算长？多少字算复杂？”这些规则很难写稳。而且一旦换了新模型，脚本要改，规则要调，整个流程就变得特别脆。

1.2 智能路由的本质：把“选模型”变成API能力

蓝耘智能路由解决的就是“该调哪个模型”这个决策问题。它本质上是一个调度层，把多个模型统一封装成一个API。调用方不需要知道具体是哪个模型在处理，只需要把文本和任务说明发给它，它会根据内置策略决定把请求转发给最合适的模型。

你可以把它想象成快递分拣中心。你在包裹上写地址，分拣中心自己决定走哪条运输线路，你不需要自己开车去送。智能路由也一样，你提交请求，它根据文本长度、复杂度、关键词甚至语义特征，把任务分给轻量模型、标准模型或者更强的模型。

这条路子对RPA特别友好。因为RPA最擅长的是重复流程，最怕的是做复杂决策。以前“选模型”这种逻辑必须写在RPA脚本里，现在它变成了一次API调用的内部行为。脚本里没有模型名，只有“路由别名”，下次换算法、换模型，RPA脚本完全不用动。

2. 整体方案设计：RPA搬数据，路由选模型

2.1 职责边界：让脚本回归“搬运工”

我在设计这个方案时，第一件事就是划清RPA和智能路由的职责边界。RPA这边的任务非常纯粹：打开Excel、读取文本、循环、发起HTTP请求、把返回结果写回Excel。所有判断模型、解析语义的事情，都交给路由层和处理模型去完成。

为什么这么划？因为RPA脚本一旦承担了“智能判断”的职责，每多一个分支，维护成本就翻一倍。如果脚本里出现“如果文本长度大于200就用模型A，否则用模型B”这种逻辑，本质上是在用流程工具做算法决策，太勉强。而且RPA调试起来比后端代码麻烦，每次改逻辑都要重新跑一遍流程，很费时间。

你可以把RPA理解成一个搬运工，它只需要确认“请求发出去了，响应拿回来了，结果写进表格了”。至于这个结果是怎么算出来的，不归它管。这种模式的好处是，脚本变得非常通用。今天处理评论，明天处理工单，后天处理问卷，流程结构一模一样，只改Excel路径和提示词就好。

2.2 调用链设计与数据流

整个调用链设计得比较直观，数据流是单向走通的：Excel数据 → RPA循环 → 组装请求体 → 调用蓝耘智能路由API → 返回JSON → 解析结果 → 写回Excel → 下一条。

每个环节的数据格式要提前定好。Excel里我用两列：A列是编号，B列是评论文本。后面预留三列：C列写情感倾向，D列写退换货原因，E列写实际使用的模型名称。这样跑完30条，一眼就能看出哪条数据被哪个模型处理过，也方便后续核算成本。

在请求体组装时，我要求每条请求只包含必要字段：路由别名、输入文本、少量生成参数。不需要把Excel里的编号传进去，也没必要传时间戳。响应端返回时，我特别关注三个字段：实际使用模型、生成内容、token用量。前两个用于结果审计，第三个用于成本核算。

2.3 设计时提前避开的三个坑

第一点，不要手工拼JSON字符串。一开始我图省事，想着就几十条数据，直接用字符串拼接请求体。结果遇到评论里有双引号和换行符，拼出来的JSON直接解析失败。后面改成用json.dumps构建，一次搞定。RPA里如果自带JSON对象组件，优先用组件；没有就用Python代码块。

第二点，不要在循环里固定等待太长时间。有些教程会教“每次循环sleep 3秒”防止限流，这对30条数据来说太慢了。建议设计成“判断错误码，非200才重试等待”，而不是无脑等。如果API返回429限流，再等1到2秒重试即可。

第三点，API Key绝对不能硬编码在共享脚本里。我做测试时把Key写在了命令行参数里，但最终交付的RPA脚本中，Key都是放在用户环境变量或者RPA的加密配置中。否则脚本一旦发出去，相当于把账户密钥给了别人，别人可以拿你的Key去调接口，成本全算你头上。

3. 同一个脚本自动切换模型的三个配置细节

3.1 请求体设计：只写路由别名，不写具体模型

这是“同一个脚本自动切换模型”的第一关键。在我对接蓝耘智能路由时，请求体里的model字段填的不是模型名，而是一个路由别名。我用的别名是route_auto，控制台里配置它为“根据输入长度和关键词自动选择模型”。

一个典型的请求体长这样：

{ "model": "route_auto", "input": "请从这段评论中提取情感倾向和退换货原因，只返回JSON，不要解释。评论内容：耳机用了三天充电口就松了，客服一直不回复。", "temperature": 0.1 }

注意，route_auto不是一个模型，它是一套路由策略的名字。我在控制台里配置了规则：文本少于200字且不包含“退款”“售后”“质量问题”等敏感词时，走轻量模型；超过200字或包含敏感词时，走能力更强的模型；如果任务特别复杂，再升级到最强模型。这样配置之后，RPA脚本里永远不会出现类似gpt-4o这样的具体模型名。

有些路由服务还支持完全不传model字段，默认走自动路由。但我个人建议还是显式传一个路由别名。因为后续你可能会有多套策略，比如“常规路由”“安全路由”“代码专用路由”，显式传别名让脚本意图更清楚。另外，响应里通常会带实际使用的模型名，我们需要把它记下来，用于事后核对。

3.2 统一响应结构：让RPA不因模型不同而分支

第二个关键，是无论底层换成哪个模型，返回结构始终一致。我在这个项目里拿到的响应大概长这样：

{ "id": "8c37f2a1", "model": "fast-v2", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "{\"sentiment\":\"negative\",\"reason\":\"充电口接触不良\"}" }, "finish_reason": "stop" } ], "usage": { "total_tokens": 320 } }

RPA脚本只需要固定解析choices[0].message.content。这个字段里的值，是我在提示词里要求模型返回的JSON字符串，再解析一次就能得到情感倾向和原因。脚本完全不关心model字段是fast-v2还是strong-v3，只要统一取内容字段就行。

这是保证“同一个脚本”能跑通的重要前提。如果你的路由服务返回结构不统一，比如简单模型返回一句话，复杂模型返回JSON，那RPA就需要写分支逻辑，脚本就会回到“根据模型走不同分支”的老路。所以对接时一定要确认，无论路由到哪个模型，响应结构一致。如果不一致，建议在上层路由服务里做一层结果规范化，再返回给RPA。

3.3 影刀RPA的HTTP请求配置实操

我用的是影刀RPA，这类支持发送HTTP请求的工具都适用。流程很简单：读数据、循环、发请求、解析、写回。

打开Excel后，我用“读取区域”组件把30条评论文本一次性读进列表变量dataList。然后开始循环。循环内第一步，组装请求体。影刀里有“创建对象”组件可以用来构建JSON，也可以用Python代码块。我为了控制转义细节，直接插入了Python代码块：

import json text = dataList[loop_index] # 当前循环的文本 body = { "model": "route_auto", "input": "请从这段评论中提取情感倾向和退换货原因，只返回JSON。评论内容：" + text, "temperature": 0.1 } payload = json.dumps(body, ensure_ascii=False)

这里有一点要提醒：ensure_ascii=False很关键。如果不设置，中文会被转成\uXXXX形式，虽然接口一般也能识别，但后期看日志时排查问题特别痛苦。设置之后，请求体里保留中文，一目了然。

接着调用“发送HTTP请求”组件。请求方式是POST，URL填对接文档里的接口地址，请求头加上Authorization: Bearer {你的Key}和Content-Type: application/json，请求体直接绑定payload变量，超时时间我设置为60秒。

拿到响应之后，先把响应字符串JSON解析一次，取出choices[0].message.content，再对这个内容做第二次JSON解析，分别取出sentiment和reason。写入Excel对应列。如果你是第一次写RPA，不用被“两次解析”吓到，本质上就是解析外层响应，再解析内层结果，两步而已。

4. 实战记录：30条数据从测试到全流程跑通

4.1 环境准备：申请Key与连通性测试

开工之前需要准备三个东西：接口地址、API Key、路由策略。登录蓝耘控制台后，开通智能路由服务，创建应用，拿到API Key。路由策略我建议第一步先配置“自动模式”，让路由用自己的默认判断能力来调度。等跑完测试数据，再根据结果细化规则。

然后是连通性测试。先用一条复杂的样例数据测通，确认返回结构符合预期。我用命令行做的测试，命令供你参考：

curl -X POST "https://your-endpoint.example.com/v1/router" \ -H "Authorization: Bearer sk-xxxx" \ -H "Content-Type: application/json" \ -d '{ "model": "route_auto", "input": "耳机用了三天充电口就松了，想退，客服一直不回复，体验很差。", "temperature": 0.1 }'

注意，在Windows的PowerShell里，命令里的反斜杠换行可能会报错。如果你用PowerShell，可以把命令写在一行，或者改用Git Bash。测试时重点看三件事：接口通不通、返回的model字段是哪个模型、content里是不是合法的JSON字符串。

4.2 完整RPA流程搭建实录

测试通过后，我开始搭完整流程。Excel表结构是A列编号，B列评论，C列情感，D列原因，E列实际模型。C到E列是等待填充的。

流程第一步，用“启动Excel”打开文件，读取B2到B31的区域，存入列表。第二步，清空C2到E31的旧内容，防止上一次运行残留数据影响判断。

第三步是核心循环。我用“For”循环遍历dataList。循环内做了几件事：用Python代码块组装请求体，发HTTP请求，判断状态码。如果非200，记录错误并最多重试3次。如果成功，解析出model和content。再解析content里的JSON，得到情感和原因，写入当前行对应的C、D、E列。

循环每跑完一条，我加了400毫秒的延时。为什么不是3秒？因为RPA场景下连续调用30次，一般不会触发限流，加一点延时只是为了给日志和Excel写入一个缓冲。真遇到429，我是在重试逻辑里等待1到2秒，而不是固定sleep。

运行过程里有个细节值得提一下。跑到第27条时，接口返回了400错误。排查后确认是那条评论里有一个半角双引号，导致手工拼接的请求体被截断。改成json.dumps之后问题消失。这说明即使只有30条数据，构建请求体也一定要走JSON序列化，不要图省事拼字符串。

全部跑完，30条数据都有结果。日志里能看到每条实际使用的模型名，E列数据也证明路由确实在做动态调度：简单评论大多走了轻量模型，长纠纷走了强模型，中间还有一些标准模型。整个过程没有修改过一次脚本，模型切换完全由路由层完成。

4.3 效果与成本对比

跑完以后我做了一个小对比，方案分别是用固定轻量模型、固定强模型、蓝耘智能路由。30条评论总共约4500个汉字，折算成token约6000左右。我用一个模拟表来展示差异，不同模型定价不同，这里更看重比例关系：

从E列数据看，30条里大约21条走了轻量模型，6条走了中间模型，3条走了强模型。也就是说，只有最难的3条付出了较高的模型成本，其余都被分流到更经济的模型上。最后准确率很接近固定强模型，费用却只有零头。

这个数字对30条来说看着不明显，但思路一换成3000条就很舒服。用固定强模型成本和延迟都会线性放大，智能路由的“按需分配”优势会被放大得特别明显。

5. 高频报错与稳定性调优实录

5.1 五个高频报错及处理方法

我整理了一下在对接和运行过程中遇到的五类报错，做成速查表，以后你遇到类似问题可以直接对照：

这里最容易被忽略的就是invalid_json。RPA的请求体组装如果在低代码组件里做，有时候会自动处理转义，但如果像我一样混合使用Python代码块，就要注意输入文本里包含的引号、换行和多字节字符。我踩过这个坑之后，所有请求体统一走json.dumps，再也没有出过JSON解析错误。

另一个值得提醒的是401问题。测试阶段我为了省事把Key暴露在命令行参数里，后来被同事提醒，才发现这样很不安全。正确的做法是存放在RPA的全局配置或环境变量中。尤其是当脚本准备给团队其他人用时，不要把Key写死在共享脚本里，否则密钥泄露了也不知道从哪查。

5.2 调优建议：从跑通到跑稳

第一次跑通之后，别急着交付，先做两件事：第一，把返回的model字段和usage.total_tokens都写进结果表；第二，用更多历史数据回放一遍路由策略。

写model字段是为了让每次结果都可以追责。假如某条数据结果明显不对，一看C列能发现它是被哪个模型处理的，方便判断“这到底是模型能力不行，还是路由分错了”。写total_tokens则是为了成本核算，月底统计时直接Excel加总，比看接口日志方便得多。

路由策略的调优，我建议从小规则开始。先别追求复杂的语义路由，就用长度和关键词两个维度做实验。比如规定“包含退款、售后、投诉、质量问题的评论，必须走强模型”，这个规则简单可控，效果立竿见影。跑一阵子之后再结合结果微调，比一开始就全自动要稳妥。

如果条件允许，建议把“30条测试”升级成“50条样本回放”。把历史数据准备好，让路由跑一遍，和人工标注结果做对比。这一步能发现路由策略的盲区，比如哪些简单评论被错误调度到了强模型，哪些复杂评论被漏给了轻模型。调优之后，脚本不需要动，真正有价值的调整都在路由层。

最后再分享一个我个人的小习惯。我习惯把每次调用的路由别名、实际模型、token总数、状态码统一打到一个日志文件里。这样做的好处是，运行完30条或3000条数据后，不需要打开RPA控制台看乱七八糟的中间日志，直接看这个文件就能了解全局情况。这个习惯看起来不起眼，但在你准备把项目交付给客户或者交接给同事时，价值非常大。