端侧大模型与超自动化融合：Agent与RPA协同架构实战

1. 端侧大模型与超自动化融合的底层逻辑

1.1 为什么要把大模型塞进端侧设备

过去两年我接触过不少RPA项目，从最早的影刀RPA教程里那种纯规则驱动的流程自动化，到后来加入OCR和NLP的传统AI组件，再到如今大模型Agent开始接管决策环节，整个技术栈的演进速度远超预期。但有一个问题始终卡在喉咙口：云端大模型API的延迟和成本。一个典型的超自动化流程，比如自动处理客服工单，如果每一步决策都要调用云端大模型，单次任务耗时轻松突破十几秒，并发一上来费用更是线性飙升。

端侧部署大模型解决的就是这个核心矛盾。把模型直接跑在本地设备上，无论是工控机、边缘服务器还是个人电脑，推理延迟从网络往返的几百毫秒压缩到本地计算的几十毫秒，而且没有按Token计费的压力。我实测过一个7B参数量的量化模型，在配备16GB显存的消费级显卡上，生成速度能稳定在每秒30个Token以上，对于RPA流程中的意图识别、字段抽取、简单决策这类任务完全够用。

但端侧落地不是简单地把模型文件下载下来就完事。你需要考虑硬件选型、模型量化、推理框架、内存管理、以及与现有RPA工具的集成方式。这些细节决定了方案能不能真正跑起来，而不是停留在Demo阶段。

1.2 超自动化的边界到底在哪里

超自动化这个概念被Gartner提出来的时候，核心是RPA加AI加流程挖掘的组合拳。但实际落地中，传统RPA的边界非常清晰：它只能处理结构化数据，只能执行预设规则，遇到异常就卡死。我见过太多RPA工程师花80%的时间在维护那些脆弱的流程脚本，业务规则一变，整个流程就得推倒重来。

大模型Agent的介入，把这个边界往外推了一大截。Agent具备自主规划、工具调用、上下文理解的能力，它可以在RPA流程中充当“大脑”的角色。比如一个采购订单处理流程，传统RPA只能按照固定模板提取字段，但Agent可以理解不同供应商发来的五花八门的PDF格式，甚至能从邮件正文的模糊描述中推断出订单意图。

这里的关键在于分工：RPA负责确定性的、高频的、需要精确操作UI的动作，比如点击按钮、填写表单、复制粘贴；Agent负责非确定性的、需要语义理解的、异常处理的环节，比如判断一封投诉邮件的紧急程度、从合同文本中提取关键条款。两者结合，才能把超自动化的覆盖范围从“规则明确的长尾流程”扩展到“规则模糊的复杂流程”。

1.3 端侧Agent与RPA的协同架构

我在多个项目中验证过一种分层架构，效果比较稳定。最底层是端侧大模型推理服务，用vLLM或者llama.cpp这类框架加载量化后的模型，对外暴露OpenAI兼容的API接口。中间层是Agent编排框架，可以用LangChain、LangGraph或者Spring AI Agent，负责管理对话历史、工具调用、任务分解。最上层是RPA执行器，影刀RPA、UiPath或者开源的TagUI都可以，通过API接收Agent下发的结构化指令。

这种架构的好处是解耦。模型可以独立升级，Agent逻辑可以独立调整，RPA流程可以独立维护。而且端侧部署意味着数据不出本地，对于金融、医疗这类对数据隐私敏感的行业，这是硬性合规要求。

注意：端侧模型的上下文窗口通常比云端小很多，7B模型一般只有4K到8K Token。在设计Agent的提示词时，必须精打细算，把最关键的指令和上下文放在前面，避免被截断。

2. 端侧大模型部署的实操细节

2.1 硬件选型与模型量化策略

端侧部署的第一步是搞清楚你的硬件底线。我整理了一个简单的对照表，基于实际测试数据：

量化是端侧部署的必修课。FP16的7B模型需要14GB显存，但Q4_K_M量化后只需要4GB左右，精度损失在可接受范围内。我试过用llama.cpp的Q4_K_M量化跑Qwen2.5-7B，在字段抽取任务上和FP16版本的准确率差距不到2个百分点，但显存占用降了70%。

量化工具链方面，llama.cpp的quantize工具最成熟，支持从Q2到Q8的各种精度。如果你用GPU推理，AutoGPTQ和AWQ也是不错的选择，但配置复杂度更高。对于大多数RPA场景，我建议从Q4_K_M起步，如果效果不达标再考虑Q5或Q8。

2.2 推理框架的选型对比

端侧推理框架的选择直接决定了部署的难易程度和运行效率。我实际用过的几个方案：

llama.cpp：纯C++实现，跨平台支持最好，Windows、Linux、macOS都能跑。CPU推理速度尚可，GPU加速需要编译CUDA版本。优点是依赖少，一个可执行文件加模型文件就能跑。缺点是并发能力弱，不适合多路同时请求。

vLLM：GPU推理的首选，PagedAttention机制让显存利用率极高，支持连续批处理，并发吞吐量是llama.cpp的十几倍。但vLLM对显存要求较高，7B模型至少需要8GB显存才能跑起来。部署也复杂一些，需要Python环境和CUDA工具链。

Ollama：封装得最好的方案，一条命令就能拉取和运行模型，自带API服务。适合快速验证和轻量级场景。但底层还是llama.cpp，并发能力有限，而且模型格式受限于GGUF。

AirLLM：这个方案比较特殊，它通过分层加载的方式，让大模型可以在显存不足的情况下运行。我试过用AirLLM在8GB显存的机器上跑70B模型，虽然速度慢到每秒不到1个Token，但确实能跑起来。适合对速度不敏感、但对模型能力要求极高的场景。

对于RPA场景，我的建议是：如果并发量在5路以下，用Ollama或llama.cpp就够了；如果并发量上到几十路，必须上vLLM，否则请求排队会拖垮整个流程。

2.3 模型选择：通用还是垂直

端侧部署的模型选择，核心权衡是能力和资源占用。我列几个实际用过的模型：

Qwen2.5系列是目前中文端侧部署的最优解。7B版本在中文理解、指令遵循、JSON输出格式方面表现均衡，量化后资源占用可控。14B版本能力更强，但需要至少12GB显存。

Llama3.1系列英文能力突出，但中文支持一般，需要额外微调。8B版本适合英文为主的RPA场景。

Hermes系列在函数调用和结构化输出方面有专门优化，如果你的Agent需要频繁调用工具，Hermes是不错的选择。

Agnes大模型和Space Bunny大模型我关注过官网，但实际端侧部署的案例还不多，生态成熟度有待观察。

实操心得：不要盲目追求大参数。我见过太多项目在7B模型上微调后效果很好，却非要上13B，结果推理速度掉一半，流程整体耗时反而增加。先用小模型跑通闭环，再根据瓶颈决定是否升级。

2.4 微调还是提示词工程

这个问题我被问过无数次。我的答案是：先榨干提示词工程的上限，再考虑微调。

提示词工程在端侧场景下的优势很明显：零训练成本、即时生效、可解释性强。对于字段抽取、意图分类这类任务，精心设计的Few-shot提示词加上JSON Schema约束，7B模型能达到90%以上的准确率。

但提示词工程有天花板。当任务涉及复杂的领域知识、特殊的输出格式、或者需要模型理解行业黑话时，微调就变得必要了。端侧微调我推荐LoRA，用LLaMA-Factory或者Unsloth框架，在单张消费级显卡上就能完成7B模型的微调。训练数据不需要太多，500到1000条高质量样本就能看到明显效果。

微调后的模型需要合并权重再量化，这一步会损失一些精度，但整体效果通常比纯提示词工程好。我的一般流程是：提示词工程验证可行性，收集bad case，标注500条数据做LoRA微调，合并量化后部署，再根据线上表现迭代。

3. Agent与RPA的集成实战

3.1 从零搭建一个端侧Agent

搭建Agent的第一步是定义它的能力边界。我以“自动处理客服工单”为例，拆解一下具体步骤。

第一步：定义工具集。Agent需要调用的工具包括：查询订单数据库、发送邮件、更新工单状态、调用RPA流程执行UI操作。每个工具用JSON Schema描述清楚输入输出。

第二步：设计系统提示词。系统提示词要包含角色定义、可用工具列表、输出格式要求、以及关键约束。比如“你是一个客服工单处理助手，你的任务是判断工单类型并调用相应工具。输出必须是JSON格式，包含action和parameters两个字段。”

第三步：实现Agent循环。用LangGraph或者Spring AI Agent搭建一个ReAct循环：接收用户输入，模型推理决定调用哪个工具，执行工具，把结果返回给模型，继续推理直到任务完成。

第四步：接入RPA执行器。当Agent决定需要执行UI操作时，它输出一个特定的action，比如{"action": "run_rpa", "parameters": {"flow_name": "create_ticket", "data": {...}}}。RPA执行器监听这个指令，调用影刀RPA的API触发对应流程。

第五步：错误处理和重试。Agent调用工具失败时，需要把错误信息返回给模型，让模型决定是重试、换工具还是放弃。这个循环最多执行5轮，避免无限循环。

3.2 RPA流程的改造要点

传统RPA流程是为人类操作设计的，直接让Agent调用会踩很多坑。我总结了几个必须改造的点：

输入输出标准化。RPA流程的输入参数和输出结果必须结构化，最好用JSON格式。影刀RPA支持通过API传入JSON参数，但需要在流程内部做解析。输出结果也要统一格式，方便Agent理解。

异常处理前置。传统RPA流程遇到异常就弹窗报错，但Agent调用时没有人来点确认。所有可能阻塞的环节都要改成自动处理或超时跳过。

幂等性设计。Agent可能会重复调用同一个流程，RPA流程必须保证幂等。比如“创建工单”操作，如果工单已存在就返回已有工单ID，而不是重复创建。

日志和追踪。每个RPA流程的执行日志要关联到Agent的会话ID，方便排查问题。我一般会在流程开始和结束时各写一条日志，记录输入参数、输出结果、执行耗时。

注意：影刀RPA的社区版和企业版在API调用上有差异，社区版对并发调用有限制。如果Agent的并发量较高，需要提前确认RPA执行器的授权和并发能力。

3.3 并发场景下的性能调优

AI Agent怎么扛并发，这是端侧落地必须回答的问题。我的经验是，瓶颈通常不在模型推理，而在RPA执行器的并发能力和Agent的请求队列管理。

模型推理层面，vLLM的连续批处理可以把多个请求合并成一个批次，吞吐量提升非常明显。我实测过，单张RTX 4090跑Qwen2.5-7B，vLLM在并发16路时，总吞吐量能达到每秒200个Token以上，平均每路延迟在2秒以内。

Agent层面，需要引入请求队列和限流机制。我用Redis做队列，每个请求入队后由Worker池消费。Worker数量根据RPA执行器的并发能力设定，一般不超过RPA授权数的80%。

RPA执行器层面，影刀RPA企业版支持多机器人并行，但需要合理分配任务。我的做法是按流程类型分组，不同类型的流程分配给不同的机器人池，避免相互阻塞。

还有一个容易被忽略的点：端侧模型的上下文长度限制。并发高的时候，每个请求的上下文会占用显存，如果上下文太长，显存很快就不够用了。解决方案是限制单次请求的上下文长度，把历史对话做摘要压缩，只保留最近几轮的关键信息。

3.4 一个完整的集成案例

去年我帮一个电商团队搭建了一套端侧Agent加RPA的售后处理系统。场景是这样的：客服邮箱收到用户邮件，系统需要自动判断邮件类型（退货、换货、咨询、投诉），提取订单号和诉求，然后在后台系统中执行相应操作。

端侧部署的是Qwen2.5-7B的Q4_K_M量化版本，用Ollama加载，跑在一台配备RTX 4060 Ti 16GB的工控机上。Agent用LangChain搭建，工具集包括：查询订单API、发送回复邮件API、调用影刀RPA流程更新工单状态。

整个流程的耗时分布：邮件解析和意图判断约1.5秒，订单查询约0.3秒，RPA执行约3秒，邮件发送约0.5秒。总耗时在5到6秒之间，比之前纯云端方案快了将近一倍，而且没有API费用。

踩过的坑：最初Agent经常把“退货”和“换货”搞混，后来在提示词里加了几个Few-shot示例，准确率从75%提升到95%以上。还有一个问题是RPA流程执行失败时Agent不知道怎么办，后来在工具描述里加了错误码说明，让Agent根据错误码决定重试还是转人工。

4. 常见问题与排查技巧实录

4.1 模型加载失败与显存不足

这是端侧部署最高频的问题。症状通常是模型加载到一半报OOM，或者推理时突然崩溃。

排查思路：先用nvidia-smi确认显存占用情况，看看是不是有其他进程占着显存。然后检查模型量化版本和推理框架是否匹配，比如GGUF格式的模型只能用llama.cpp或Ollama加载，不能用vLLM。

如果显存确实不够，有几个降级方案：换更小的模型、用更激进的量化（Q3或Q2）、减少上下文长度、降低并发数。我一般会先试Q4_K_M，不行再降到Q3_K_M，精度损失在可接受范围内。

还有一个隐蔽的坑：Windows系统下，WDDM模式会让显存管理变得不可预测。如果条件允许，切换到TCC模式能获得更稳定的显存表现。但TCC模式需要专业显卡支持，消费级显卡不一定能切换。

4.2 Agent输出格式不稳定

Agent输出的JSON格式经常出错，比如多了一个逗号、少了一个引号、或者干脆输出了一段自然语言。这个问题在端侧小模型上尤其明显。

解决方案分三层：第一层是在提示词里强调输出格式，给出明确的JSON Schema示例。第二层是在Agent框架层面加输出解析器，用正则表达式提取JSON部分，容错处理。第三层是在模型层面做约束解码，比如用Outlines或Guidance库强制模型输出符合JSON Schema的内容。

我实测下来，约束解码是最可靠的方案，但会稍微增加推理延迟。如果延迟敏感，可以用提示词加解析器的组合，把解析失败的情况记录下来，作为微调的bad case。

4.3 RPA流程执行超时

Agent调用RPA流程时，如果流程执行时间过长，Agent可能会超时放弃，但RPA流程还在后台跑，造成状态不一致。

我的做法是在RPA流程里加心跳机制，每隔几秒向Agent返回一个进度信号。Agent收到进度信号就重置超时计时器。如果超过最大等待时间还没有完成，Agent发送取消指令，RPA流程收到后优雅退出。

另外，RPA流程的每一步操作都要有超时设置，比如点击按钮后等待元素出现，最多等10秒，超时就抛异常。避免流程卡死在某个环节。

4.4 常见问题速查表

4.5 几个容易被忽略的细节

模型文件的存储路径不要有中文和空格。我遇到过好几次因为路径问题导致模型加载失败，排查了半天才发现是路径里的中文字符惹的祸。

Ollama的默认端口是11434，如果被占用会静默失败。启动前先用netstat确认端口可用。

影刀RPA的API调用需要先登录获取Token，Token有有效期，Agent需要处理Token过期的情况。我的做法是在Agent的工具层加一个Token管理模块，自动刷新。

端侧设备的散热。长时间高负载推理会让GPU温度飙升，如果散热不好会触发降频，推理速度断崖式下跌。工控机一定要做好散热设计，必要时加装风扇。

日志要分级。Agent的推理日志、RPA的执行日志、模型的性能日志分开存储，排查问题时才能快速定位。我一般用ELK或者Loki做日志聚合，方便检索。

5. 端侧Agent的扩展方向与个人体会

5.1 多模态能力的引入

纯文本的Agent已经能覆盖大部分RPA场景，但有些任务需要理解图片或PDF。比如从扫描件中提取发票信息，或者从截图中判断UI状态。

端侧多模态模型的选择还比较有限，Qwen-VL系列有量化版本可以在端侧跑，但显存占用比纯文本模型高不少。我的建议是，如果多模态需求不是核心，先用OCR加文本模型的方式过渡，等端侧多模态模型更成熟再切换。

5.2 Agent中台化的思考

当端侧Agent的数量多起来之后，管理就成了问题。每个Agent的提示词、工具配置、模型版本都需要统一管理。我目前的做法是用一个轻量的配置中心，把Agent的定义存成YAML文件，启动时加载。版本控制用Git，每次修改都有记录。

Agent中台的核心价值是复用。把通用的工具（邮件发送、数据库查询、RPA调用）封装成标准组件，不同的Agent按需组合。这样新Agent的搭建成本从几天降到几小时。

5.3 我踩过的最大的坑

最大的坑不是技术问题，而是期望管理。业务方看到大模型的能力后，往往期望Agent能处理所有异常情况。但实际上，端侧7B模型的能力边界很清晰，它擅长的是模式识别和简单推理，不擅长复杂逻辑和长链条规划。

我的经验是，在项目初期就明确Agent的能力边界，把不能处理的情况设计成转人工的流程。宁可让Agent说“我不确定，需要人工介入”，也不要让它胡编乱造。信任是一点一点建立的，一次严重的错误输出可能让整个项目被叫停。

5.4 给后来者的几个建议

如果你正准备入坑端侧大模型加超自动化，我的建议是：先从一个小场景跑通闭环，不要一上来就搞大而全的平台。一个简单的邮件分类加自动回复流程，就能让你把模型部署、Agent搭建、RPA集成、异常处理这些环节全部走一遍。

模型选择上，Qwen2.5-7B是目前中文端侧的最优解，社区资源丰富，踩坑成本低。推理框架用Ollama快速验证，生产环境换vLLM提升并发。

最后，保持耐心。端侧部署的细节非常多，从驱动版本到CUDA兼容性，从量化参数到提示词调优，每一个环节都可能卡住你。但一旦跑通，你会发现这套方案的稳定性和成本优势是云端方案无法比拟的。