企业官网建设流程全解析

最近在跑一批RPA数据处理任务时遇到一个典型困境：30条数据摆在那里，任务类型五花八门，有简单的文本分类、有需要多步推理的复杂问题、还有几条要求稳定输出JSON格式的结构化抽取。搁在以前，我肯定是一条条看内容、手动指定模型，或者干脆全部丢给最强模型一把梭。但这次我用蓝耘的智能路由做了个尝试，把模型选择这件事从脚本里彻底抽了出去，让同一个RPA脚本自动切换模型跑完全程，效果出乎意料地稳。

先说结论：这30条数据，我原来的做法大概要分三类手动跑三轮，耗时接近40分钟；换成智能路由后，一个脚本一次跑完，耗时不到9分钟，整体成本降了差不多一半。更重要的是，脚本逻辑没有任何"判断该用哪个模型"的分支代码，路由选择全部发生在云端。这篇文章就围绕这个实战过程，把我怎么接入、怎么设计脚本、过程中踩了哪些坑，全部拆开讲清楚。

1. 为什么RPA工程师需要"脚本不变、模型自选"的能力？

1.1 RPA+LLM的常见痛点：模型固定、成本失控

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 Key>；Content-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( url="https://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 }, timeout=60 ) data = resp.json() return data["choices"][0]["message"]["content"]

改动后，接入蓝耘智能路由：

import requests def call_llm(prompt: str) -> dict: resp = requests.post( url="https://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 字段，真正由智能路由调度的模型，无需也无需在脚本中指定 }, timeout=60 ) 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写得不对"都分不清。

容错方面，我给脚本加了三层兜底：

1. HTTP层面：请求失败时重试2次，每次间隔3秒，并使用指数退避策略；
2. 业务层面：如果返回内容为空或finish_reason不是stop，重新调用一次路由接口，prompt末尾追加"请务必完整输出"；
3. 逃生舱：如果同一数据重试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条输出为合法JSON，1条输出中混入了多余的说明文字，需要做一次后处理清洗。这个不是路由的问题，而是目标模型偶尔会"话多"，在prompt里强制加一句"只输出JSON不要任何解释"后，问题基本消失。

第三，看延迟分布。我记录了每条数据的响应时长。轻量模型平均耗时约2秒，强推理模型平均耗时约11秒，结构化模型平均耗时约5秒。如果强模型被频繁塞给简单任务，总耗时绝不会是9分钟这个量级。

4.3 成本与耗时的对比数据

直接上对比数据。同30条数据、同样的prompt设计，三种处理方式的结果如下：

手动分三类其实成本也不高，问题在于需要人工判断每条数据的类型，30条数据不算什么，但如果是300条、3000条呢？人工筛选的耗时和出错率都会指数级上升。智能路由的价值在数据量越大时体现得越明显——脚本完全不关心任务类型，路由自动完成分类和模型选择，我只需要在跑完后看一眼路由日志确认决策质量。

我特别把"手动分三类"的耗时算了进去。不要只算机器运行时间，人工介入时间才是RPA流程里最隐蔽的成本。去掉人工筛选的40分钟才是真正体现智能路由价值的9分钟。

5. 踩坑记录：RPA+智能路由最容易翻车的四个细节

5.1 API返回超时与重试机制：RPA流程卡死的根源

第一次跑通脚本后，我直接在30条数据上全量运行，结果在第14条数据卡住了。影刀那边显示的日志是"HTTP请求超时"，整个流程停在那里等响应，后面的数据全部排队阻塞。

排查之后，原因出在强推理模型在最坏情况下单次响应可能超过60秒，而我设置的timeout=60在边缘场景下不够用。更麻烦的是，超时之后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+大模型的批量处理流程，且正在被"一个模型打天下"的成本或效果问题困扰，我建议你先把手头数据的任务类型统计出来，看看是不是真的适合智能路由。如果数据里确实混合了多种难度和多种类型的任务，那接入智能路由的收益会非常直接——毕竟脚本不用大改，路由策略先跑两周，对比一下账单和耗时，数据会告诉你答案。