端侧大模型与超自动化融合：AI Agent与RPA协同落地实践

1. 端侧大模型与超自动化融合的底层逻辑1.1 为什么要把大模型塞进端侧设备过去两年大模型落地的主流路径是云端API调用。但真正做过企业级自动化项目的人都知道这条路在实操中会遇到几个绕不开的坎网络延迟导致RPA流程卡顿、敏感数据不能出内网、API调用成本随流程数量线性增长、以及最致命的——一旦网络抖动整条自动化流水线直接瘫痪。端侧部署大模型本质上是把推理能力从远端机房搬到离数据和业务最近的设备上。这里的“端侧”不单指手机或边缘盒子也包括企业内网的工控机、办公PC、甚至RPA机器人所在的那台虚拟机。把模型放在这些位置带来的直接好处有三个响应延迟从秒级降到毫秒级、数据不出本地满足合规要求、单次推理的边际成本趋近于零。我实测过一组数据同一个文档信息抽取任务走云端API平均耗时1.8秒端侧部署7B量化模型后降到0.3秒。对于需要连续执行上百步操作的超自动化流程来说这个差距直接决定了流程能不能跑通。1.2 超自动化边界被扩展的三个方向传统RPA擅长的是“规则明确、界面稳定、步骤固定”的任务比如每天定时登录系统导出报表、按固定格式录入数据。但一旦遇到界面改版、弹窗变化、非结构化文档传统RPA就歇菜了。大模型端侧落地后超自动化的边界往三个方向明显外扩第一从结构化数据扩展到非结构化数据。以前RPA处理发票需要固定模板现在端侧模型可以直接理解PDF、扫描件、甚至手写备注把关键字段抽出来再交给RPA执行后续操作。第二从固定流程扩展到动态决策。AI Agent可以根据当前屏幕内容、历史操作记录、业务规则自主决定下一步点哪里、填什么。RPA从“执行器”变成了“手脚”大模型成了“大脑”。第三从单机自动化扩展到多Agent协同。端侧部署让多个Agent可以在同一内网内低延迟通信一个负责理解需求一个负责操作软件一个负责校验结果形成闭环。1.3 端侧部署与云端调用的选型对照对比维度端侧部署云端API调用响应延迟毫秒级稳定秒级受网络波动影响数据合规数据不出本地需评估传输与存储合规长期成本一次性硬件投入按调用量持续计费模型能力受限于端侧算力通常用7B-14B量化模型可调用千亿参数模型运维复杂度需自行处理部署、更新、监控由服务方维护适用场景高频、敏感、低延迟任务低频、非敏感、复杂推理任务选型逻辑很直接高频重复且对延迟敏感的任务走端侧复杂长尾推理任务走云端。很多团队采用混合架构端侧模型负责意图识别和简单抽取遇到难题再转发给云端大模型。2. 端侧大模型部署的实操路径与关键参数2.1 硬件选型与模型规格匹配端侧部署第一步是算清楚硬件账。模型参数量、量化精度、推理框架三者共同决定了需要什么级别的硬件。以常见的7B模型为例不同量化精度下的显存占用大致如下量化精度模型文件大小推理显存需求典型硬件FP16约14GB16GBRTX 4090 / A5000INT8约7GB10GB左右RTX 3080 12GINT4约3.5GB6GB左右RTX 3060 12G / 笔记本4060GGUF Q4_K_M约4.2GB5-6GB消费级显卡或Apple Silicon如果目标设备是普通办公PC没有独立显卡那就只能考虑CPU推理加小参数模型比如Qwen2.5-1.5B或Phi-3-mini配合llama.cpp这类CPU优化框架。实测在i7-13700上跑1.5B的Q4量化模型生成速度大约15-20 token/s做简单的意图分类和字段抽取够用了。注意不要盲目追求大参数模型。端侧场景下一个响应稳定的3B模型比一个动不动OOM的13B模型有价值得多。2.2 推理框架选择与部署步骤目前端侧推理框架主流的有llama.cpp、Ollama、vLLM、TensorRT-LLM。选哪个取决于你的硬件和并发需求llama.cppCPU和Apple Silicon上表现最好GGUF格式模型生态丰富适合个人PC和边缘设备。Ollama封装了llama.cpp提供REST API适合快速搭建原型但并发能力有限。vLLMGPU推理首选支持PagedAttention并发吞吐量高适合企业内网多Agent共享一个模型服务。TensorRT-LLMNVIDIA显卡上性能最优但部署复杂度最高需要模型转换和编译。以Ollama为例部署一个端侧模型的完整步骤# 1. 安装OllamaLinux示例 curl -fsSL https://ollama.com/install.sh | sh # 2. 拉取量化模型 ollama pull qwen2.5:7b-instruct-q4_K_M # 3. 启动服务并指定监听地址 OLLAMA_HOST0.0.0.0:11434 ollama serve # 4. 测试推理 curl http://localhost:11434/api/generate -d { model: qwen2.5:7b-instruct-q4_K_M, prompt: 从以下文本中抽取发票号码和金额发票号INV-2024-001金额3500元, stream: false }如果要用vLLM部署并支持多Agent并发调用# 安装vLLM pip install vllm # 启动OpenAI兼容服务 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --quantization awq \ --max-model-len 4096 \ --gpu-memory-utilization 0.85 \ --port 8000关键参数说明--max-model-len控制上下文长度端侧场景建议不超过4096以节省显存--gpu-memory-utilization控制显存占用比例留出余量给RPA本身和其他进程。2.3 模型微调与提示词工程的端侧适配端侧模型参数量小通用能力不如云端大模型所以微调和提示词工程必须做扎实。微调方面LoRA是端侧最实用的方案训练成本低推理时可以合并权重也可以动态加载。一个典型的LoRA微调配置from peft import LoraConfig lora_config LoraConfig( r16, # 秩端侧建议8-16 lora_alpha32, # 缩放系数通常为r的2倍 target_modules[q_proj, v_proj, k_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM )训练数据不需要多500-2000条高质量样本就能让模型在特定任务上表现明显提升。关键是数据质量输入要覆盖实际业务中各种边界情况输出格式要严格统一。提示词工程在端侧更重要因为小模型对提示词敏感。几个实操原则指令要短且明确避免多层嵌套条件。输出格式用JSON Schema约束方便RPA解析。few-shot示例控制在3个以内太多会挤占上下文。系统提示词里写死角色和边界防止模型跑偏。3. AI Agent与RPA协同的落地实现3.1 Agent架构设计与并发处理一个能在生产环境跑起来的端侧Agent架构上通常分四层感知层负责获取屏幕截图、窗口信息、剪贴板内容决策层由端侧大模型负责理解当前状态并输出下一步动作执行层调用RPA组件完成点击、输入、拖拽等操作记忆层维护短期对话历史和长期任务知识。并发是端侧Agent最容易踩坑的地方。多个Agent同时调用一个端侧模型服务时如果推理框架不支持批处理请求会排队延迟飙升。解决方案有两个一是用vLLM的continuous batching把多个请求合并成一个batch推理二是给每个Agent分配独立的模型实例但这样显存占用会成倍增加。实测数据单张RTX 4090上vLLM部署7B-AWQ模型并发4路请求时平均延迟约400ms并发8路时延迟升到900ms左右。如果业务要求每路延迟低于500ms建议并发数控制在4-6路。3.2 RPA与大模型对接的三种模式模式一大模型作为RPA的“前置处理器”。RPA流程开始前先把非结构化输入交给大模型抽取结构化字段然后RPA按原有逻辑执行。这种模式改动最小适合存量RPA流程的智能化改造。模式二大模型作为RPA的“运行时决策器”。RPA执行到关键节点时把当前屏幕截图和上下文发给大模型由模型决定下一步操作。这种模式适合界面频繁变化、规则难以穷举的场景。模式三Agent完全接管流程编排。大模型不仅决定单步操作还负责整个任务的规划和异常处理。RPA退化为纯粹的执行工具库。这种模式最灵活但对模型的推理能力和稳定性要求最高。以影刀RPA为例对接端侧模型的典型方式是通过Python脚本组件调用本地APIimport requests import json def ask_local_llm(prompt, system_prompt你是一个RPA流程助手): response requests.post( http://localhost:11434/api/chat, json{ model: qwen2.5:7b-instruct-q4_K_M, messages: [ {role: system, content: system_prompt}, {role: user, content: prompt} ], stream: False, options: {temperature: 0.1} } ) return response.json()[message][content] # 在影刀流程中调用 result ask_local_llm(当前页面有一个弹窗标题是系统提示按钮有确定和取消应该点哪个)提示temperature设低一些0.1-0.3保证Agent决策的稳定性。端侧场景下创造性不是首要目标确定性才是。3.3 流程分享与组件复用的工程化实践端侧Agent和RPA流程做好之后团队内部往往需要复用和分享。这里有几个工程化要点第一把模型配置和流程逻辑解耦。模型地址、名称、参数放在配置文件里流程代码只引用配置项。这样换模型或换设备时不用改代码。第二RPA组件封装成标准接口。每个原子操作点击、输入、读取都封装成独立函数Agent只需要输出“操作名参数”的JSON由统一调度器执行。第三流程版本管理。用Git管理流程定义文件和提示词模板每次变更记录diff。端侧模型更新后用回归测试集验证流程是否仍然正常。第四异常兜底机制。Agent决策失败时要有降级方案重试、转人工、或回退到传统RPA规则。端侧模型再稳定也有犯错的时候兜底机制是生产环境的必需品。4. 常见问题排查与性能优化实录4.1 端侧推理典型故障速查现象可能原因排查方法解决方案模型加载OOM显存不足查看nvidia-smi显存占用换更小量化精度或更小参数模型推理速度突然变慢显存碎片或温度墙监控GPU利用率和温度重启服务或限制并发数输出乱码或重复量化损失过大对比FP16和量化版输出换更高精度量化或调整提示词API调用超时请求排队查看服务端日志并发数增加batch size或限制客户端并发Agent决策不稳定temperature过高多次运行同一输入对比输出降低temperature增加few-shot示例RPA操作失败界面元素变化截图对比操作前后界面增加等待时间或改用图像识别定位4.2 性能优化的五个实操技巧技巧一KV Cache量化。vLLM支持KV Cache用FP8存储显存占用降低约一半对长上下文场景效果明显。开启方式是在启动参数中加--kv-cache-dtype fp8。技巧二提示词缓存。如果系统提示词很长且固定可以用vLLM的prefix caching功能避免每次请求都重新计算。启动时加--enable-prefix-caching。技巧三动态批处理调优。--max-num-seqs控制最大并发序列数端侧场景建议设为4-8。设太大反而会因为显存不足导致频繁换入换出。技巧四模型蒸馏替代微调。如果7B模型在端侧跑不动可以用云端大模型生成训练数据蒸馏到1.5B或3B小模型上。实测在特定任务上蒸馏后的3B模型能达到7B模型90%以上的准确率。技巧五CPUGPU混合推理。llama.cpp支持把部分层放在GPU、部分层放在CPU适合显存刚好差一点的场景。用-ngl参数控制GPU层数逐步调整找到最佳平衡点。4.3 生产环境部署的避坑清单不要在生产设备上直接拉取最新模型。先在测试环境验证确认输出格式和稳定性后再上线。不要忽略模型预热。服务启动后先跑几条推理请求让模型加载到显存并完成CUDA kernel编译否则第一批真实请求延迟会很高。不要把所有Agent都指向同一个模型实例。关键业务Agent建议独立部署避免被其他Agent的请求挤占资源。不要忘记监控。至少监控推理延迟、显存占用、请求失败率三个指标用PrometheusGrafana搭个简单看板。不要忽视日志。Agent的每次决策输入输出都要落盘出问题时才能回溯。日志保留至少7天。5. 从0到1搭建端侧Agent的完整参考方案5.1 最小可行系统搭建步骤假设你有一台带RTX 3060 12G的办公PC想搭建一个能自动处理邮件附件的端侧Agent。完整步骤如下第一步部署推理服务。安装Ollama拉取qwen2.5:7b-instruct-q4_K_M模型启动服务并验证API可用。第二步定义Agent工具集。用Python封装几个原子操作读取邮件附件、解析PDF文本、调用模型抽取字段、写入Excel、移动文件到指定目录。第三步编写Agent主循环。用LangChain或直接写Python循环把当前状态和可用工具列表发给模型解析模型输出的工具调用指令执行后把结果反馈给模型直到任务完成。第四步接入RPA执行器。对于需要操作图形界面的步骤比如打开邮件客户端通过影刀或UiPath的Python接口调用。第五步加异常处理和日志。每个工具调用都包try-except失败时记录详细上下文并决定重试还是跳过。第六步压测和调优。用真实邮件样本跑100次统计成功率和平均耗时根据瓶颈调整模型参数或流程逻辑。5.2 关键代码骨架import requests import json class LocalAgent: def __init__(self, model_name, base_urlhttp://localhost:11434): self.model_name model_name self.base_url base_url self.tools { read_attachment: self.read_attachment, extract_fields: self.extract_fields, write_excel: self.write_excel, } def call_llm(self, messages): resp requests.post( f{self.base_url}/api/chat, json{ model: self.model_name, messages: messages, stream: False, options: {temperature: 0.1} } ) return resp.json()[message][content] def run(self, task_description, max_steps10): messages [ {role: system, content: 你是一个邮件处理助手可用工具read_attachment, extract_fields, write_excel。输出JSON格式的工具调用。}, {role: user, content: task_description} ] for step in range(max_steps): output self.call_llm(messages) try: action json.loads(output) except json.JSONDecodeError: messages.append({role: assistant, content: output}) messages.append({role: user, content: 输出格式错误请输出合法JSON}) continue if action.get(type) finish: return action.get(result) tool_name action[tool] tool_args action.get(args, {}) result self.tools[tool_name](**tool_args) messages.append({role: assistant, content: output}) messages.append({role: user, content: f工具执行结果{result}}) return 达到最大步数限制这个骨架可以直接跑实际使用时根据业务替换工具函数和系统提示词即可。5.3 效果评估与迭代方向上线后需要持续跟踪几个指标任务成功率端到端完成比例、平均步数步数越少说明模型决策越高效、人工干预率需要人工兜底的比例、单任务耗时。迭代方向按优先级排序先优化提示词和few-shot示例这是投入产出比最高的然后补充训练数据做LoRA微调最后考虑换更大模型或升级硬件。不要一上来就想着换模型大部分问题出在提示词和流程设计上。我个人在实际操作中的体会是端侧大模型加超自动化这个方向技术选型不是最难的难的是把模型的不确定性和RPA的确定性要求调和好。我的做法是给Agent划一个“安全操作空间”在这个空间内允许模型自由决策超出边界就强制走规则逻辑。这样既保留了智能化的灵活性又保证了生产环境的稳定性。另外一个小技巧是把常用的操作序列缓存下来模型决策过一次之后相似场景直接复用既省算力又提速度。