最近 DeepSeek API 价格调整的消息让不少开发者开始重新审视自己的调用账单。尤其是那些把大模型接入到日常流程中的团队稍微跑几个批量任务Token 消耗就像流水一样。价格上涨之后同样的流程成本可能直接翻了好几倍。但这里有一个被很多人忽略的切入点并不是所有重复性流程都非要调用大模型不可。很多高频操作本质上只是规则的、确定性的、模板化的完全可以用 RPA机器人流程自动化替代。本文就围绕这个思路讲清楚 Token 成本是怎么烧起来的RPA 能接管哪一类流程以及如何用一套“RPA DeepSeek API”的组合方案把成本降下来。本文适合三类读者接入了 DeepSeek API但发现 Token 消耗速度远超预期的开发者。在做 RPA 自动化项目想结合 AI 能力但不想无脑烧 Token 的工程师。负责业务提效、正在评估“到底哪些流程该用 AI”的团队技术负责人。读完本文你会掌握Token 的计费逻辑、判断流程是否适合 RPA 的方法、一个完整的 Python RPA 示例、一套缓存与批量优化方案以及常见报错的排查思路。1. 背景API 价格调整后重复流程成了“烧钱重灾区”1.1 为什么“重复调用大模型”最容易超支先看一个很常见的业务场景运营团队每天要把几十条客户留言复制到后台逐条做“情感分类”和“关键词提取”然后再填进表格。在没有大模型之前这个工作靠人工完成。有了 DeepSeek API 之后很多人第一反应是写个脚本循环调用 API把每条留言都丢给模型自动输出分类结果。听起来很合理但仔细算一下假设每条留言平均 300 个汉字对应约 400 到 500 个 Token。每次 API 调用除了输入 Token还会返回输出 Token。每天 100 条留言消耗大概 5 万到 10 万 Token。如果任务变成全天候轮询、每 5 分钟跑一次Token 消耗就是指数级增长。价格调整后同样的调用量成本可能从“几乎可以忽略”变成“每月一笔不可忽视的账单”。更关键的是这类流程有大量重复计算同一条数据被反复解析、同一个模板被反复填充、同一类页面被反复点击。每一次重复都在消耗 Token但每次得到的结果几乎一模一样。1.2 RPA 的本质用确定性逻辑替代确定性操作RPA 的全称是 Robotic Process Automation翻译过来是机器人流程自动化。它的核心思想是把人在电脑上的重复操作录制成脚本或编写成流程由软件机器人自动执行。比如打开某个网页登录点击按钮下载文件。读取 Excel 中的内容填入另一个系统的表单。定时检查某个目录下有没有新文件有就处理。在多个系统之间搬运数据、做格式转换。这些操作的特点是规则明确、步骤固定、不需要聪明判断。换句话说它们不需要大模型只需要一个能稳定执行指令的机器人。所以当 API 价格上涨、Token 成本变高时正确的思路不是减少所有 AI 功能而是把流程拆开看哪些步骤真正需要 AI哪些步骤只是“看起来需要 AI”。2. 概念拆解Token、上下文长度与 RPA 的边界2.1 Token 到底是怎么消耗的Token 是大模型处理文本的最小单位。对于中文场景一个 Token 大约对应 0.5 到 1 个汉字具体取决于分词方式。调用一次 DeepSeek API 的成本可以拆解为总消耗 Token 输入 Token 输出 Token输入 Token 包括你在 prompt 里写的指令。你要让模型处理的数据内容。多轮对话中之前所有的历史消息如果开启上下文记忆。附加的系统提示词、示例、few-shot 样本。输出 Token 就是模型生成回复的长度。这里有一个非常隐蔽的坑系统提示词和示例不会因为“每次都一样”就不计费。哪怕你的 prompt 固定不变只要每次调用都发送一次它就每次都收费。举个例子system_prompt 你是一个专业的文本分类助手请对用户输入做情感分类只输出正面、负面、中性。这段 prompt 大约 60 到 80 个 Token。如果一个自动化任务每小时调用 60 次一天 1440 次仅 prompt 本身就要消耗约 10 万 Token——而且这还是在你还没发送任何“待处理数据”的情况下。这就是为什么很多人觉得明明只是小功能账单却高得离谱。2.2 RPA 适合处理哪些流程要判断一个流程是否适合用 RPA可以套用三个标准第一流程是否稳定如果步骤经常变化、页面结构频繁调整、业务规则三天两头改RPA 的维护成本会很高。第二是否有明确规则比如“如果状态为已发货就发送物流通知”这是明确规则。而“根据客户语气决定回复策略”这不是明确规则需要 AI。第三是否需要访问多个系统RPA 的价值在跨系统整合。如果只在一个系统内操作可能原生的 API 就足够了。我整理了一个简单的判断表流程特征适合 RPA适合 DeepSeek API规则明确步骤固定是否需要理解语义、做判断否是每天执行成百上千次是成本低需谨慎Token 成本高跨系统搬运数据是否非结构化文本处理否是页面点击、表单填写是否2.3 结合方式RPA 负责“动”API 负责“想”在实际项目中RPA 和大模型不是二选一而是分工合作。RPA 负责那些不需要智力的体力活登录系统、读取文件、拼接数据、填写表单、发送请求。DeepSeek API 负责那些需要理解能力的判断情感分析、文本摘要、分类、信息抽取。正确的调用姿势是先用 RPA 把数据预处理成干净的、结构化的输入再调用一次 API 获取结构化结果然后再用 RPA 把结果回填到目标系统。整个过程只调用一次模型而不是每一步都调用。3. 成本分析一次 API 调用 vs 一次 RPA 执行3.1 成本的量级差异为了更直观地理解我们来对比一下一次 DeepSeek API 调用的成本取决于输入和输出 Token 数量。假设一次普通任务消耗 1000 Token价格调整前和调整后的差异可能达到数倍。一次 RPA 脚本执行的成本主要是脚本运行所在机器的资源消耗。如果你用的是本机定时任务成本约等于电费和机器损耗如果你用的是 RPA 工具自带的调度器通常按机器人数量或执行次数收费但总体远低于按 Token 计费的模式。更重要的一点是RPA 的边际成本非常低。脚本写好后执行 100 次和执行 1000 次脚本本身的成本是固定的增加的只是运行时间。而 API 调用是每一次都要付费。3.2 一个实际的成本对比案例假设你有一个“日报自动整理”任务方案 A直接用 DeepSeek API每天调用 50 次每次输入 1500 Token输出 500 Token。每天消耗 10 万 Token。按当前价格计算一个月下来是一笔固定支出。方案 BRPA 抓取数据 API 一次性汇总RPA 先把 50 条日报数据从各个系统抓取下来合并成一个 Markdown 文件。调用一次 DeepSeek API输入 5000 Token输出 1000 Token让模型生成汇总摘要。每天只消耗 6000 Token。两种方案得到的日报质量可能差不多但 Token 成本相差十几倍。方案 B 的关键在于数据搬运和格式化由 RPA 完成模型只处理“最后一道汇总”。4. 实战案例用 Python RPA 实现“留言自动分类”省钱版下面来做一个完整的实战案例。场景是运营每天需要处理一批客服留言做情感分类和紧急度标记。我们把它改造成“RPA 预处理 单次 API 调用 RPA 回填”的流程。4.1 传统写法循环调用 API先看一个典型的反例。很多开发者会写成这样import requests import pandas as pd API_URL https://api.deepseek.com/chat/completions API_KEY your-api-key def classify_comment(text: str) - str: payload { model: deepseek-chat, messages: [ {role: system, content: 你是客服留言分类助手。}, {role: user, content: f请对以下留言进行情感分类只输出正面/负面/中性。\n留言内容{text}} ], temperature: 0 } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } resp requests.post(API_URL, jsonpayload, headersheaders) result resp.json() return result[choices][0][message][content].strip() df pd.read_excel(messages.xlsx) df[情感分类] df[留言内容].apply(classify_comment) df.to_excel(messages_classified.xlsx, indexFalse)这段代码功能上没问题但它会为每一行数据单独调用一次 API。如果表里有 100 条留言就是 100 次调用。每个请求都要重复发送相同的 system prompt重复做一次 HTTP 往返重复计费。这是最昂贵的写法。4.2 优化思路RPA 预处理 批量请求优化后的流程分成三个阶段。第一阶段用 Python 读取 Excel做基础清洗去空行、去重复、去除无意义字符。这一步不需要调用任何模型。第二阶段把清洗后的 100 条留言拼接成一个结构化的文本分两次或三次调用 API每次让模型处理 30 到 50 条。这样做的好处是相同的 system prompt 只需要发送几次而不是 100 次同时模型在一次推理中可以对多条数据做批量分类输出更稳定。第三阶段用 Python 解析模型返回的 JSON回填 Excel。这一步也不需要调用模型。import requests import pandas as pd import json API_URL https://api.deepseek.com/chat/completions API_KEY your-api-key def load_and_clean_messages(file_path: str) - list[str]: 读取并清洗留言数据不需要调用大模型。 df pd.read_excel(file_path) messages df[留言内容].dropna().drop_duplicates().tolist() cleaned [str(msg).strip() for msg in messages if str(msg).strip()] return cleaned def batch_classify(messages: list[str], batch_size: int 40) - list[dict]: 批量分类把多条留言拼接成一次请求。 results [] system_prompt ( 你是客服留言分类助手。 你会收到一组用编号标记的留言例如\n 1. 留言内容...\n2. 留言内容...\n 请为每条留言输出 JSON 数组格式如下\n [{id: 1, sentiment: 负面, urgent: true}, ...]\n 只输出 JSON不要输出其他解释。 ) for i in range(0, len(messages), batch_size): batch messages[i:i batch_size] user_content \n.join(f{idx 1}. {msg} for idx, msg in enumerate(batch)) payload { model: deepseek-chat, messages: [ {role: system, content: system_prompt}, {role: user, content: user_content} ], temperature: 0, response_format: {type: json_object} } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } resp requests.post(API_URL, jsonpayload, headersheaders) if resp.status_code ! 200: print(f请求失败状态码{resp.status_code}响应{resp.text}) continue data resp.json() content data[choices][0][message][content] # 解析模型返回的 JSON parsed json.loads(content) results.extend(parsed) return results def fill_back(messages: list[str], classifications: list[dict], output_path: str): 把分类结果按 id 回填到 DataFrame 并保存。 df pd.read_excel(messages.xlsx) for item in classifications: idx item[id] - 1 # 需要把 id 映射回原数据行 if 0 idx len(df): df.loc[idx, 情感分类] item[sentiment] df.loc[idx, 是否紧急] item[urgent] df.to_excel(output_path, indexFalse) if __name__ __main__: comments load_and_clean_messages(messages.xlsx) print(f清洗后共 {len(comments)} 条留言) result batch_classify(comments) fill_back(comments, result, messages_classified.xlsx) print(分类完成结果已写入 messages_classified.xlsx)这里有几个关键点batch_size控制每次请求处理多少条留言可以按实际 prompt 长度调整。如果留言很长需要减小这个值避免超出上下文长度。response_format要求模型返回 JSON方便解析。解析时用 id 做映射保证结果不会错位。这种写法把 100 次 API 调用压缩到了 3 次左右Token 消耗直接少了一个数量级。4.3 加入 RPA自动检查新文件并触发任务上面的脚本已经比逐条调用节省很多了但它还缺一个“自动化触发”能力。真实业务中运营不可能每天手动运行一次脚本。这时 RPA 的价值就体现出来了。我们可以写一个简单的文件监听脚本放在服务器或办公电脑上定时运行。当检测到新文件messages_new.xlsx出现时自动执行分类并把结果放到指定目录。import time import os import shutil import subprocess WATCH_DIR input DONE_DIR done OUTPUT_DIR output def process_new_file(filepath: str): 检测到新文件后调用之前的分类脚本。 print(f检测到新文件{filepath}) # 这里调用上一个小节中的分类流程 subprocess.run([python, classify.py, filepath], checkTrue) shutil.move(filepath, os.path.join(DONE_DIR, os.path.basename(filepath))) print(f已完成处理文件移动到 {DONE_DIR}) def watch_directory(): os.makedirs(WATCH_DIR, exist_okTrue) os.makedirs(DONE_DIR, exist_okTrue) os.makedirs(OUTPUT_DIR, exist_okTrue) print(f正在监听目录{os.path.abspath(WATCH_DIR)}) while True: for filename in os.listdir(WATCH_DIR): if filename.endswith(.xlsx): filepath os.path.join(WATCH_DIR, filename) process_new_file(filepath) time.sleep(10) if __name__ __main__: watch_directory()这个监听脚本本质上就是一个轻量 RPA 流程定时检查、触发执行、移动文件。它不调用任何大模型却能把整个流程串起来。4.4 运行与验证把前面的代码保存为classify.py和watcher.py然后准备好messages.xlsx其中有一列名为“留言内容”。在项目目录下执行python classify.py观察输出。也可以执行python watcher.py进入监听模式把新文件放进input目录看它是否自动处理。运行成功后messages_classified.xlsx中会新增两列“情感分类”和“是否紧急”。整个过程只有真正的文本分类调用了 DeepSeek API清洗、拼接、回填全部是本地逻辑。5. 进阶方案缓存、上下文压缩与 Token 监控5.1 结果缓存避免重复计算很多重复流程其实是“对同一批数据反复处理”。比如每天生成的日报内容 80% 和昨天相同。如果每次都重新调用 API省不了钱。一个有效的做法是引入缓存层。用内容的哈希值做 key把 API 返回结果存到本地数据库或 JSON 文件中import hashlib import json import os CACHE_FILE cache.json def load_cache() - dict: if os.path.exists(CACHE_FILE): with open(CACHE_FILE, r, encodingutf-8) as f: return json.load(f) return {} def save_cache(cache: dict): with open(CACHE_FILE, w, encodingutf-8) as f: json.dump(cache, f, ensure_asciiFalse, indent2) def get_cache_key(text: str) - str: return hashlib.md5(text.encode(utf-8)).hexdigest() def call_with_cache(text: str, call_func) - str: cache load_cache() key get_cache_key(text) if key in cache: print(命中缓存跳过 API 调用) return cache[key] result call_func(text) cache[key] result save_cache(cache) return result这样即使任务重复执行也不会每次都被计费。需要注意的是缓存只适用于结果稳定、不要求实时性的场景。如果模型版本升级或 prompt 策略调整记得清理缓存。5.2 控制上下文长度的技巧Token 成本中输入 Token 往往是大头。减少输入 Token 的常用方法有去掉 prompt 中不必要的修饰性文字指令尽量精简。不要在每轮对话中都附加一堆 few-shot 示例。示例只在第一次调用时需要。如果不需要多轮对话就不要用messages数组传历史记录只传当前轮次。将大段文本先做摘要再交给模型做最终判断。这个过程叫“分治”。先让模型概括每一段再把多个概括拼接做最终分析。5.3 在代码里做 Token 用量监控DeepSeek API 的响应中会返回 Token 使用情况。我们可以在代码中把每次调用的 Token 数记录下来汇总到日志或数据库。def log_token_usage(response_data: dict): usage response_data.get(usage, {}) print(json.dumps(usage, ensure_asciiFalse, indent2)) with open(token_log.jsonl, a, encodingutf-8) as f: f.write(json.dumps(usage) \n)把token_log.jsonl按天汇总就能统计出每个流程每天的 Token 消耗。一旦发现某个流程消耗异常增长就可以及时排查。6. 常见问题与排查思路在实际部署这套方案时会遇到各种报错。下面整理几个高频问题都来自常见开发场景。问题现象常见原因解决思路请求返回 401 UnauthorizedAPI Key 失效或填错检查环境变量或配置文件中的 Key确认 Key 是否过期注意别把 Key 提交到 Git 仓库请求返回 429 Too Many Requests调用频率超限改用批量拼接方式减少请求次数增加重试逻辑合理设置batch_size响应报错“token exchange failed”登录认证流程中 Token 交换失败常见于第三方工具接入时检查 OAuth 配置确认授权回调地址是否正确查看服务端日志定位是哪一步失败返回内容超长被截断输出 Token 上限不足在请求参数中设置更大的max_tokens或缩小一次处理的批量大小JSON 解析失败模型返回了非标准 JSON在 prompt 中明确要求“只输出 JSON”开启response_format参数解析失败时打印原始内容人工检查本地脚本突然不运行RPA 依赖的窗口或文件路径改变检查监听目录是否存在检查文件是否被占用了写权限添加日志输出定位断点每次都重复计费没有缓存重复调用引入 5.1 小节的缓存机制按内容哈希做去重如果遇到登录类错误比如“sign-in could not be completed”“token exchange failed: error sending request”等先不要急着改代码。检查重点应该是你的认证配置是否指向了正确的服务地址。Token 是否在有效期内过期需要重新申请。网络环境是否稳定频繁超时会触发 Token 交换失败。服务端的时区与本地是否一致可能导致 Token 有效期判断偏差。7. 最佳实践与工程建议7.1 流程分流设计不要因为文章标题说“RPA 省钱”就一上来把已有的 AI 流程全部替换掉。正确做法是先梳理现有流程标记出哪些步骤是确定性的哪些是非确定性的。以客服留言处理为例读取文件、清洗数据、拼接内容、回填表格确定性步骤用 RPA。情感分类、紧急度判断、回复草稿生成非确定性步骤用大模型。定时调度、异常重试、结果通知确定性步骤用 RPA。7.2 API 调用的工程规范所有 API Key 一律通过环境变量或密钥管理服务加载禁止明文写在代码里。每次调用必须有超时设置和重试机制。建议超时时间 30 到 60 秒重试最多 3 次并采用指数退避。在生产环境中所有 API 调用都要记录日志至少包括时间、请求 ID、Token 用量、响应状态码。对模型返回的内容做校验。比如要求 JSON 输出时要先json.loads并判断字段是否存在再做后续处理。涉及自动登录、自动点击、模拟操作时必须在有授权的系统上使用。不要在未经允许的站点上采集数据或执行自动化操作这会违反平台规则。7.3 RPA 脚本的维护建议脚本要模块化。把“读取数据”“调用 API”“写回结果”拆成独立函数方便单独测试。文件路径不要写死。使用argparse或配置文件传入。增加日志输出。建议使用 Python 的logging模块输出到文件方便排查。对边缘情况做处理空文件、格式错误、网络中断。不要假设输入永远干净。在测试环境完整跑通后再上生产。如果操作的是生产系统一定要确认流程不会误删数据。7.4 成本告警即使做了缓存和批量优化也应该给 Token 消耗设置告警线。常见做法是每天统计 Token 消耗量。当单日消耗超过预设阈值时发送告警通知。每周做一次成本复盘找出消耗最高的前三个流程评估是否可以进一步优化。8. 下一步可以怎么优化本文的方案把重点放在了“减少调用次数”和“用 RPA 做确定性工作”这两件事上。在实际项目中还可以继续往下优化。一个是引入本地小模型做前置过滤。对于不需要复杂推理的任务可以用一个本地的小模型先过一遍命中不了再调用 DeepSeek API。这样能进一步减少远程调用量。不过这类方案对部署环境有一定要求适合有 GPU 资源或需要离线处理的场景。另一个是使用模型蒸馏或微调。如果你发现某个固定任务比如“订单状态分类”反复在消耗 Token可以把历史调用记录整理成训练集微调一个专用小模型。但这个方向的成本比较重建议在 API 调用量已经很大的情况下再考虑。你还可以把 RPA 工具本身也升级一下。除了用 Python 写监听脚本也可以使用商业 RPA 工具比如影刀、UiPath、来也等。它们提供了可视化编排能力适合业务人员直接维护流程减少对开发者的依赖。这类工具通常有免费的社区版可以在小范围内试用后再推广。9. 总结回到题目本身当 API 价格波动、Token 成本压力变大时最该做的不是减少 AI 功能而是调整流程结构。把大量重复、确定、模板化的操作交给 RPA 执行把真正需要语义理解和判断的部分交给大模型再配合批量拼接、结果缓存、Token 监控这些手段完全可以把成本控制在合理范围内。本文用一个“留言自动分类”的案例演示了完整的改造思路传统逐条调用 API 是最贵的做法。先做数据清洗再批量拼接请求可以把调用次数压缩一个数量级。配合文件监听脚本形成完整的 RPA 自动化闭环。缓存、上下文压缩、Token 用量记录是后续优化的关键手段。如果你现在正在跑一个高频调用 DeepSeek API 的脚本我建议你按这个顺序排查一遍先看每次请求是不是重复发送了太多历史上下文再看是不是每条数据都要独立调用一次最后看有没有可能用本地脚本或 RPA 把清洗、搬运、回填这些“不烧 Token”的活先干完。这一步做完往往就能省下一大笔费用。