1. 背景客服团队被跨系统查询拖垮了2025 年 Q3我所在的供应链 SaaS 公司主营 WMS/TMS 云平台服务 300 中型制造企业遇到一个很现实的业务问题客服与运营团队每天要跨 6 个内部系统ERP、WMS、TMS、对账平台、工单系统、企业微信反复查询、录入、核对数据。以订单异常处理为例一名资深客服处理一单平均耗时 4 分 30 秒其中约 70% 时间消耗在打开系统→登录→找到订单→复制字段→粘贴到另一个系统这类机械操作上。量化指标很直观日均异常订单约 2,400 单客服团队 12 人日均处理量上限约 1,900 单积压率长期在 20% 以上客户投诉响应慢占比 31%。业务侧天天催客服天天加班问题却不见好转。我最初的想法和大多数人一样上 RPA。于是我们先用 UiPath 做了流程自动化结果踩了不少坑——维护成本高、页面改版即失效而且完全无法处理需要语义理解的模糊场景如这个订单为什么被拦截。RPA 这条路走不通我才开始关注AI 智能体浏览器与桌面终端即具备视觉理解与 GUI 操作能力的多模态 Agent可操控浏览器与桌面应用目标是让智能体替代人工完成跨系统查询与录入把单均处理耗时压到 90 秒以内。2. 现状RPA 为什么解决不了根因拆解在决定引入智能体之前我先冷静拆解了 RPA 失败的根因结论有三条系统间无统一 API6 套系统中仅 ERP 和 WMS 提供 REST APITMS 和对账平台只有老旧 Web 界面工单系统是企业微信内嵌 H5。RPA 依赖 DOM 选择器页面改版我们平均每月收到 3 次前端变更就崩。操作路径非线性客服处理一单并非固定流程而是查询→判断→分支处理判断依赖语义理解如客户等级为 A 且金额 5 万需走特批。传统 RPA 的 if-else 写死规则规则膨胀到 200 条后难以维护。上下文割裂数据散落在不同系统人工需要复制-粘贴来桥接。智能体浏览器/桌面终端天然具备看屏幕→理解→操作→回填的闭环能力能模拟人的完整操作路径。这三条根因决定了这不是流程编排问题而是视觉理解 语义判断问题传统自动化工具在架构上就解决不了。3. 方案两套候选方案对比与选型明确了根因后我调研并 PoC 了两类方案方案技术路线优点缺点A. 开源框架自建如基于 Playwright GPT-4o UI-TARS 类模型自建 Agent 编排层模型负责视觉理解与动作生成可控性强、可深度定制、无单点供应商锁定工程量大需自研状态机、重试、安全沙箱初期准确率不稳定B. 商用智能体终端如某云厂商的 Agent 桌面终端 企业版 API开箱即用内置浏览器/桌面操作能力上线快2 周 PoC、自带安全审计与录屏回放单席位成本高约 800 元/月/席位定制能力受限选型依据我最终选择方案 A自建核心原因是业务规则高度定制特批流程、多级审批且需要与内部 SSO、审计系统深度集成商用方案的黑盒策略难以满足合规要求。技术栈定为Agent 编排层Python 3.11 LangGraph 0.2.x状态图编排视觉-操作模型Qwen2.5-VL-7B本地部署数据不出内网 备用 GPT-4o仅用于难例浏览器控制Playwright 1.48Chromium 130桌面终端控制pyautogui 0.9.54 Windows UI AutomationUIA向量记忆pgvector 0.7PostgreSQL 16存储历史操作轨迹与 FAQ 语义任务队列Redis 7.2Celery 5.44. 实操步骤从 PoC 到生产4.1 环境准备# 内网 GPU 服务器NVIDIA A10 24GBconda create-nagentpython3.11-yconda activate agent pipinstalllanggraph0.2.60playwright1.48.0pyautogui0.9.54\qwen-vl-utils0.1.0pgvector0.7.0celery5.4.0redis5.2.0playwrightinstallchromium4.2 核心编排LangGraph 状态机fromlanggraph.graphimportStateGraph,ENDfromtypingimportTypedDict,LiteralclassAgentState(TypedDict):task:strscreenshot:straction_history:listextracted_data:dictstatus:Literal[pending,running,done,failed]defbuild_graph():gStateGraph(AgentState)g.add_node(parse_task,parse_task)# 语义解析任务g.add_node(observe,observe_screen)# 截图 视觉理解g.add_node(act,act_on_screen)# 执行动作点击/输入g.add_node(verify,verify_result)# 校验结果g.add_node(extract,extract_data)# 抽取字段回填g.set_entry_point(parse_task)g.add_edge(parse_task,observe)g.add_conditional_edges(observe,decide_next,{act:act,done:extract,failed:END})g.add_edge(act,verify)g.add_conditional_edges(verify,check_retry,{retry:observe,done:extract,failed:END})g.add_edge(extract,END)returng.compile()4.3 视觉-操作闭环关键片段defact_on_screen(state:AgentState)-AgentState:# 调用 Qwen2.5-VL 生成屏幕坐标 动作JSONpromptf你是桌面操作员。根据截图和任务输出动作JSON。 任务{state[task]}历史动作{state[action_history][-3:]}输出格式{{action: click|type|scroll, x: int, y: int, text: str}}respqwen_vl_chat(state[screenshot],prompt)actionjson.loads(resp)ifaction[action]click:pyautogui.click(action[x],action[y])elifaction[action]type:pyautogui.typewrite(action[text],interval0.05)# 截图更新state[screenshot]capture_screen()state[action_history].append(action)returnstate预期运行结果在 PoC 环境1 台 A10 2 台 Windows 10 虚拟机跑通跨系统查询订单状态并回填工单全流程单任务平均耗时 75 秒动作成功率 82%。5. 踩坑与排错三个真实报错自建方案最大的代价就是所有坑都得自己趟一遍。以下是上线过程中最典型的三个问题。6. 验证数据与效果上线 4 周后2025.11.10-12.08我们对比了人工与智能体处理订单异常查询回填任务指标人工基线智能体生产提升单均处理耗时4 分 30 秒82 秒-70%日均处理量12 人→8 人2 Agent1,900 单2,350 单24%字段录入准确率98.2%96.5%-1.7%可接受积压率21%4.2%-16.8pp关键结论智能体不是替代人而是放大人的产能——我们把 4 名客服转岗为异常复核员只处理智能体标记为低置信度约 12%的任务形成人机协同闭环。7. 权衡与总结什么场景别照搬适用场景跨系统、无 API 的查询-判断-录入型重复工作如客服、财务对账、运营报表规则复杂但可语义化描述、需要视觉理解的场景数据敏感、要求本地化部署的行业制造、金融、政务。不适用/慎用场景高频、低延迟操作如每秒多次点击视觉模型推理延迟 1.5-3s不适合实时性要求 1s 的场景强合规审计虽然我们做了录屏回放但AI 自主操作的合规边界仍需法务确认页面频繁大改版虽然比 RPA 抗改版强但若每周改版仍需持续维护视觉 prompt。代价与边界自建方案并非免费的午餐。单 Agent 并发建议 ≤ 3 个受 GPU 显存限制A10 24GB 跑 Qwen2.5-VL-7B 约占用 18GB若并发需求大需上多卡或量化INT8。整体 ROI硬件 开发成本约 35 万按节省 4 人人力年薪 25 万/人计算约 5 个月回本——但前提是业务规则相对稳定否则视觉 prompt 的维护成本会吃掉这部分收益。一句话复盘AI 智能体浏览器/桌面终端不是万能自动化它是能看懂屏幕的 RPA 升级版——适合解决语义理解 跨系统桥接的难题但必须配好熔断、校验、人工兜底三件套才能在生产环境稳定跑起来。如果你的业务是高频低延迟、强合规审计、或页面每周大改版请谨慎评估不要照搬这套方案。