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 失败的根因，结论有三条：
- 系统间无统一 API：6 套系统中仅 ERP 和 WMS 提供 REST API，TMS 和对账平台只有老旧 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.48（Chromium 130）
- 桌面终端控制：pyautogui 0.9.54 + Windows UI Automation（UIA）
- 向量记忆：pgvector 0.7（PostgreSQL 16），存储历史操作轨迹与 FAQ 语义
- 任务队列：Redis 7.2（Celery 5.4）
4. 实操步骤：从 PoC 到生产
4.1 环境准备
# 内网 GPU 服务器（NVIDIA A10 24GB）conda create-nagentpython=3.11-yconda activate agent pipinstall"langgraph==0.2.60""playwright==1.48.0""pyautogui==0.9.54"\"qwen-vl-utils==0.1.0""pgvector==0.7.0""celery==5.4.0""redis==5.2.0"playwrightinstallchromium4.2 核心编排：LangGraph 状态机
fromlanggraph.graphimportStateGraph,ENDfromtypingimportTypedDict,LiteralclassAgentState(TypedDict):task:strscreenshot:straction_history:listextracted_data:dictstatus:Literal["pending","running","done","failed"]defbuild_graph():g=StateGraph(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 生成"屏幕坐标 + 动作"JSONprompt=f"""你是桌面操作员。根据截图和任务，输出动作JSON。 任务：{state['task']}历史动作：{state['action_history'][-3:]}输出格式：{{"action": "click|type|scroll", "x": int, "y": int, "text": str}}"""resp=qwen_vl_chat(state["screenshot"],prompt)action=json.loads(resp)ifaction["action"]=="click":pyautogui.click(action["x"],action["y"])elifaction["action"]=="type":pyautogui.typewrite(action["text"],interval=0.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 Agent） | 1,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 升级版"——适合解决"语义理解 + 跨系统桥接"的难题，但必须配好熔断、校验、人工兜底三件套，才能在生产环境稳定跑起来。如果你的业务是高频低延迟、强合规审计、或页面每周大改版，请谨慎评估，不要照搬这套方案。
 最高 100W Source 快充方案)
