从系统集成到屏幕操作：Agent如何破解无接口系统的自动化难题

之前跟一位做企业数字化的朋友聊天，他掰着手指头跟我算：上了七八套系统，流程该断的还是断，数据该散的还是散。问到最后，原因高度统一——系统之间没有接口，或者有接口但不开放，开放了的又因为版本、权限、字段映射这些事连不上。他说了句特别实在的话：“我们不是不想数字化，是被系统集成卡死的。”

真正动手做过企业项目的人，大概率都经历过这种憋屈。所以我今天想把一个非常反常规的思路展开聊聊：与其执着地打通接口，不如让Agent直接“看屏幕”。这种具备“看屏幕”能力的Agent，不依赖系统是否提供API，而是把软件界面当成操作入口，像人一样用眼睛看、用大脑理解、动鼠标键盘完成业务操作。行业内这类方案越来越常见，我在这里统一用一个代号来称呼它：实在Agent。它不特指某家厂商的产品，而是代表“能看、能想、能操作”的一类屏幕操作型智能体。

这篇文章会讲清楚三件事：这类Agent凭什么能破解传统接口集成难题；企业到底应该怎么评估、怎么落地；以及上线之后有哪些避不开的坑、怎么治理。适合数字化负责人、IT经理、流程管理者和自动化实施工程师参考。

1. 为什么说传统接口集成是一道很难跨过去的墙

1.1 没有接口的系统，才是很多企业的真实家底

先泼一盆冷水：很多企业的核心系统，压根没有对外接口。早年部署的ERP、生产管理、订单管理、库存系统，大多是定制化开发或者很老的CS架构产品，厂商早就停止更新了，更别提什么标准API。你想让这些系统和外部应用对话，唯一的路径就是人肉操作——登录系统、敲代码、点按钮、填表单、再核对一遍结果。

我曾经接手过一个典型流程：销售助理每天上午要登录网站后台导出前一天的订单，再把订单逐条录入公司的老业务系统，最后回到报表工具里做核对。两个系统各自都很稳定，问题在于它们“老死不相往来”。数据要流动，只能靠人当搬运工。这种流程说大不大，但每天都在消耗真实的人力。

有人可能会问，可以找厂商做个二次开发吗？可以，但前提是厂商还在维护，而且报价往往高得离谱。更麻烦的是，开发排期动不动几个月起步，等新系统上线，业务需求可能又变了。业务人员比较务实，他们要的就是今天能把单子录进去、把数据对平，谁等得了半年。

1.2 有接口也不代表幸福，版本和业务规则才是大的变数

没有接口的痛大家都懂，但有接口的项目其实也容易踩坑。接口文档和实际部署版本不一致、字段长度对不上、权限令牌需要频繁刷新、不同环境下的单据状态码完全不同，这些已经是“基操”了。

尤其是集成范围比较大的时候，往往要同时对接三四个系统。表面上是写接口，实际是编一张复杂的映射表。比如A系统订单状态是“已审核”，但B系统里对应的是“已确认”，中间还要经过人工核对金额是否一致。线上商城、ERP、财务系统一起对接时，字段、状态、同步时点、失败重试机制，每一个环节都可能出现意外的业务规则差异。

而这类问题最尴尬的地方在于：开发接口的过程很累，接口跑起来之后依然脆弱。业务部门改一个字段名称，接口对接方就要跟着改代码；系统升级，接口签名可能直接变掉。你今天调试好了，明天可能就因为一个配置项被改而静默失效。

1.3 业务要的是把事办掉，不是把“协议”弄通

我见过不少项目，技术层面其实都挺懂的，但推动试行了几个月仍然没有实际产出。核心原因很一致：技术团队关注的是协议、字段、参数，业务团队关注的是订单能不能按时录入、报表能不能跑得出来。两边语言的鸿沟，让集成项目变成一个漫长的拉锯战。

从这个角度看，具备“看屏幕”能力的Agent提供了一个完全不同的维度：它不关心系统内部的数据结构，只关心屏幕上呈现的业务界面。业务员看得见、操作得了的界面，Agent同样能看得见、操作得了。这等于把集成的重点从“技术协议”平移到了“业务流程”。

\begin{table}[]\centering \caption{三种自动化方式对比} \label{tab:my_table} \begin{tabular}{|l|l|l|l|} \hline 维度 & 传统API集成 & 传统RPA（控件/DOM抓取） & 看屏幕型Agent \ \hline 依赖条件 & 系统必须提供开放接口 & 系统界面元素结构相对稳定 & 界面可见、可操作即可 \ \hline 实施成本 & 高，需要前后端开发配合 & 中，需要适配控件属性 & 中高，需要视觉模型调优 \ \hline 抗界面变化能力 & 高，但接口一变就崩 & 弱，DOM/控件属性一变就崩 & 中等，可以靠视觉语义重新定位 \ \hline 适用场景 & 新系统、标准API、高并发接口 & 结构稳定的桌面/网页应用 & 老系统、跨系统、无接口场景 \ \hline \end{tabular} \end{table}

2. 具备“看屏幕”能力的Agent到底是什么

2.1 核心定义与工作闭环

一句话概括：具备“看屏幕”能力的Agent，是一套能够像人一样观察图形用户界面、理解界面内容、自主决定下一步操作、并执行和校验结果的智能自动化系统。它不是传统意义上单纯“识别文字”的OCR，也不是只会按固定路径点击的RPA脚本，而是一个完整的“感知—认知—决策—执行—校验”闭环。

把这个闭环展开来看：Agent首先捕获屏幕画面，这是“眼睛”；然后通过视觉模型、语义理解模型识别出当前页面的业务状态，比如哪个按钮对应保存、哪些表格数据需要处理，这是“大脑”；接着把识别结果转成具体的操作指令，确定在哪里点击、在哪里输入、按什么顺序操作，这是“决策”；鼠标键盘级别的动作执行器会完成实际点击、输入、回车，这是“手”；最后Agent会再一次读取屏幕反馈，确认操作是否生效，比如保存后有没有出现“提交成功”的提示，这是“校验”。

整个过程跑一遍，其实就是在模仿人类业务人员的日常操作。人和业务系统之间不需要TCP/IP、不需要API鉴权，唯一需要的就是“看得见、点得着”。Agent之所以能绕开接口，恰好是利用了这个最基本的事实。

2.2 从“看”到“干”的四个技术环节

说起来简单，“看屏幕”背后实际上是一整套技术栈的配合。

第一步是屏幕采集。Agent要拿到高质量、稳定、低延迟的屏幕画面。技术上需要考虑分辨率差异、多显示器环境、窗口遮挡、缩放比例等。很多落地项目翻车，不是模型不好，而是采集阶段就没处理好DPI缩放，导致后续坐标全偏。

第二步是页面理解。这是这块方案与传统RPA最大的差别。传统RPA通过读取界面控件的DOM结构或者窗口句柄来定位操作对象，而屏幕型Agent更多依靠视觉识别技术，比如光学字符识别、目标检测、版面分析，再加上最近很多团队引入的多模态大模型进行整体语义理解。简单说，传统RPA读的是“结构”，屏幕型Agent读的是“画面”。

第三步是决策编排。理解了页面之后，Agent要决定先点什么、后输入什么、遇到弹窗怎么处理。落地时通常会把业务流程拆成步骤树，每个节点对应一个视觉状态和一个动作组合。复杂的流程中，决策编排还要结合业务规则，比如当“金额超过阈值”时才执行某一条分支。

第四步是动作执行与结果校验。执行时不只是单纯模拟一次鼠标点击，还要处理输入法、键盘焦点、快捷键组合等细节。执行之后必须回读屏幕上的反馈，用关键文本、截图差异、控件状态来判断节点是否成功。结果校验是整个流程稳定性的关键，也是最容易被低估的技术环节。

2.3 为什么“模拟人眼”比“模拟协议”更接地气

所有软件系统，无论底层架构多么复杂，最终都要通过一个图形界面来服务人类用户。说白了，界面本身就是所有系统之间最大公约数的“通用接口”。人靠眼睛和鼠标就能操作任何系统，这就意味着：只要一个流程能够让人通过屏幕完成，理论上就能让一个同样具备“看屏幕”能力的Agent自动完成。

在实际项目里，这样做的好处非常明显。首先是“没有接口也能自动化”，这是最直接的增量场景。其次是抗业务变化的能力更强，界面文字变了，视觉模型可以根据语义重新定位；而传统API方式一旦字段语义变化，往往伴随接口重开发。再加上落地速度更快，不需要对方系统开放任何端口、不需要协调外部团队，一个人就能在测试环境里快速搭出第一个可运行的流程。

2.4 它不是传统RPA，也不是简单OCR

我曾经不止一次被问到：这和RPA有什么区别？和OCR又有什么区别？确实有必要理清概念。

OCR是被动的。它只能从一张静态图片里抽取文字，没有点击、没有输入、没有上下文理解，更没有操作后的自我校验。传统RPA虽然能操作界面，但依赖的是控件ID、DOM树、XPath这类结构性特征。一旦页面改版，这些属性可能全部失效，脚本就得重写。

而看屏幕型Agent把“看见”和“操作”闭环起来了。它不仅是让系统“看到一张图”，而是让系统理解图里的业务含义，并根据这个含义做出行为和验证。多模态大模型的加入，让它可以处理传统RPA很难搞定的模糊状况，比如控件位置变化、复杂的表格布局、需要判断上下文的按钮选择。这也正是“实在Agent”这个名字里“实在”的意味：把自动化落到业务实处，而不只是做一个识别工具。

3. 实在Agent落地方法：从场景甄选到规模化复制

3.1 选流程的“三有一稳”原则

很多团队启动这类项目时，最容易犯的一个错误是先买了工具再找场景。正确的姿势反过来，应该先用严格标准筛出一批流程，再谈技术选型。我总结了“三有一稳”原则，供做项目时直接套用。

第一个“有”是有明确规则。这个流程需要满足“输入明确、操作步骤明确、预期结果明确”。比如财务每天做对账、客服每天录合同、运营每天填报表，这类流程规则相对固定，适合机器替代。相反，那种“根据客户情绪决定话术”“根据领导意见调整优先级”的流程，天然不适合自动化。

第二个“有”是有数据核对点。自动化最怕的就是“做完没有反馈”。如果系统操作完成后，屏幕上能看到单据号、金额合计、成功状态等明确回执，Agent就可以做自我校验，一旦异常就停下来通知人工。这是成功率能不能做上去的关键条件。

第三个“有”是有兜底机制。流程出错后能不能重跑？能不能人工介入？业务影响可不可控？如果流程是实时性的、出错会产生不可逆影响，初期就不要碰。

最后一个“一稳”是界面相对稳定。不是说系统永远不改版，而是在项目实施的前三个月内不要有大的界面重构。界面频繁改动的系统，再好的视觉模型都会疲于应付。

另外还有一条隐性的筛选原则：选择操作步骤多、重复频次高、但单位价值不算太高的流程。这种流程在业务上不显眼，恰恰最值得自动化，因为出错影响可控，而节省的人力非常可观。

3.2 五步落地路线，照排期走就行

第一步是流程盘点与投资回报初筛。把目标部门的日常操作活动画出来，标记出哪些步骤是“纯机械式”，哪些涉及判断。机械步骤占比高、跨系统数量多、人工消耗大的流程，优先列进候选清单。

第二步是技术验证。在测试环境中快速搭一个最小原型，只做一条完整的业务链路，比如从登录系统到查询数据再到提交保存。这一阶段的主要任务不是追求高成功率，而是验证“这条链路在视觉层面能不能走通”。第一次跑通之后，再逐步补充异常分支的处理。“这两步走通后，管理层心里才有底，才好继续投入资源。”

第三步是小批量试运行。把自动化流程放到真实的业务系统里跑，初期约束到小范围业务数据，比如只处理某一类订单，或者只覆盖某两个业务员的单据。连续运行一到两周，记录每次失败和人工介入的原因，这些记录将成为第四步的输入。

第四步是完整交接与规则标准化。试运行稳定后，把流程从开发环境正式移到运行环境。这时候要做几件事：整理异常处理手册，明确哪些情况自动重试、哪些情况派发人工；配置监控告警；把权限、账号、日志理干净；最终交接给运营人员，让实施人员从日常维护中抽身。

第五步是规模化复制。把已验证的流程沉淀成标准组件和视觉模板，再推到同类型业务部门。不同部门之间的流程差异通常不大，一套模板稍作调整就能复用。规模化过程中，要每周关注成功率指标，一旦某个节点开始下滑，立刻回看视觉识别版本和界面改动记录。

3.3 实施团队怎么配，谁拍板、谁干活、谁兜底

看屏幕Agent项目，本质上是一个业务流程自动化项目，不是纯技术项目。团队配置上，业务负责人应该占主导权，IT负责人负责环境和安全管控，两者不能互相代替。

一个比较标准的团队配置是，业务侧指定一位流程负责人，负责梳理流程、验收业务结果；IT侧安排一位系统管理员，负责账号权限、网络环境、系统版本变更通知；自动化实施工程师负责配置视觉模型、编排步骤和编写校验规则；运营侧至少要配一名监控人员，盯数据、处理异常任务；如果企业合规要求较高，安全和审计人员必须从项目初期就介入。

我见过不少失败项目，都是业务做“甩手掌柜”、IT闭门造车导致的。业务不提供真实流程，IT做了一个“技术上完美、业务上没用”的Demo；IT不提前介入安全，业务部门自己装了自动化工具，最后变成影子IT，运维完全失控。所以团队配置的意义，是让每一个环节都有人负责，而不是只在技术层面用力。

3.4 试点阶段的量化目标怎么定

没有量化指标的试点都是耍流氓。我不建议一开始就定“全流程自动化率100%”这种高不可攀的目标，那样只会逼着团队修改数据来填平指标。

比较务实的指标是：首次成功率不低于90%，这里的“首次”指不经过任何人工干预、并且不经过重试就直接完成；含重试的最终成功率不低于95%；单个流程的人工处理时长下降50%以上；业务数据差错率要低于人工操作差错率；异常平均响应时间不超过15分钟。

如果连续两周各项指标都达到上述标准，再谈规模化。如果达不到，就不要急于扩量，停下来找原因。大多数情况下，问题不是出在“看屏幕看不准”上，而是出在流程边界没划清、异常分支没覆盖、业务规则没写透。

4. 上线后最容易踩的5个坑与排查实录

4.1 分辨率、DPI缩放导致鼠标“点偏了”

这是上线后遇到最多的一个问题。开发环境的屏幕是1080P分辨率、100%缩放，一切运行正常；一部署到用户电脑或者虚拟桌面，屏幕是4K或者125%缩放，Agent的动作坐标就开始偏。明明识别到了按钮位置，点下去却落到了其他元素上。

排查思路：先搞清楚系统UI框架是按物理像素还是逻辑像素渲染。很多Windows应用在DPI缩放时，会拉伸整个界面，但底层鼠标坐标仍然按逻辑坐标解释。解决办法是把坐标计算从“全局屏幕坐标”改为“目标控件相对坐标”，并在所有运行环境中统一分辨率和缩放比例。项目实施初期，约定运行环境统一为固定分辨率和100%缩放，可以少走很多弯路。

4.2 页面加载和弹窗时机比想象中复杂

业务流程里经常出现这种情况：界面元素已经能看到了，但点击下去没有生效，或者表单还在加载中就执行了下一步。浏览器页面尤其明显，前端看起来全部渲染完成，实际上接口数据还没返回。

这种问题要靠在流程编排里加入“状态等待”。视觉模型识别到元素只是第一步，真正的“可操作状态”需要额外信号来判断，比如某个按钮从灰色变成可用、列表里出现了预期数据、Loading图标消失。在开发过程中，必须为每一个关键节点设置超时和失败分支，超时后进入人工处理队列，不要让流程卡死在那里。

4.3 数据填对了，但数据错了无人发现

最隐蔽的坑是“操作成功，业务失败”。举个例子，自动录入表单时把客户编号填错了，系统本身有校验，但是校验规则比较宽松，单子照样提交成功，Agent在界面上看到“提交成功”也认为一切正常。直到月底业务部门盘点，才发现出一堆脏数据。

这类问题的排查成本很高，但预防并不复杂。在流程中的每个关键节点，加入独立的业务校验规则，比如校验单号前缀、核对金额合计、检查必填字段是否为空。Agent执行完操作后，不仅要看系统回执，还要重新读取一遍页面数据，与输入值做比对。记住一句话：界面上的“成功”不等于业务上的“正确”。

4.4 登录态过期、权限调整和弹出证书

长期运行的自动化流程，经常会遇到登录态过期、动态口令失效、权限被回收这类问题。还可能碰上SSL证书过期、页面弹出安全提示框，这些弹窗平时人眼一扫就能判断，Agent却容易卡住。

对策是提前把“登录和身份认证”设计成独立环节。可以考虑给Agent配置专用的自动化账号，通过单点登录记住会话状态，尽量减少重复登录次数。涉及动态口令、短信验证码这类安全步骤时，比较稳妥的做法是采用“人值守辅助”：Agent跑到这一步自动暂停，等待值守人员输入验证信息后再继续。这里要避免的是让Agent尝试规避安全验证，这在合规层面风险很大。安全机制设计的初衷就是防止未授权访问，自动化改造不应越过这条边界。

4.5 滚动列表加载导致“漏行”

处理长列表数据时，Agent如果一次性向下滚动太快，虚拟列表的懒加载机制还没来得及返回数据，页面就已经滚过去了，最终导致只处理了前面几行、漏掉了后面的数据。

这种坑非常难发现，因为脚本本身没有报错。解决方法是把滚动改成“逐屏滚动”：每滚动一屏，暂停并校验当前页面行数变化；如果行数没有增加，再继续滚动。流程结束时，要把采集到的记录条数与系统界面显示的“共多少条”对照，做一次总量校验。凡是涉及列表录入的环节，总量校验都是必须的安全带。

4.6 常见问题速查表

5. 安全、治理与“人机协同”不能等到上线再考虑

5.1 给Agent一个“最小权限”的工号

具备“看屏幕”能力的Agent，本质上是一个数字员工。企业里给人类员工怎么定权限，就应该给Agent怎么定权限。我强烈建议让Agent使用独立的自动化账号，而不是挂在某位同事的账号下。原因很简单：独立账号才能做独立审计，出了问题才能快速定位。

权限配置要遵循最小权限原则。Agent只需要“查看某几个菜单”“编辑某一类单据”“导出某几份报表”，那就只把这些权限给它，不要顺手给一个系统管理员账号。很多自动化项目为了省事，在线申请了一个管理员权限，运行没问题，但一旦被外部攻击者控制，就相当于拿到了整个系统的高权限入口，这风险相当大。权限变更要纳入审批流程，而不仅仅由实施工程师自己决定。

5.2 录屏留痕和审计日志，是治理底牌

屏幕操作型Agent最大的优势之一，是它天然留下了完整的操作记录。每一次点击、输入、页面跳转，都可以被录屏、截图、记录日志。这些记录不只是故障排查时的证据，更是审计合规的基本资料。

落地时，日志至少要覆盖：操作时间、操作用户、操作页面、关键输入参数、输出结果、异常信息。最好能回放整个自动过程的视频片段。保留周期要按企业安全策略来定，通常至少保留一个季度。日志平台要防篡改，确保审计人员拿到的是未改动的原始记录。这些措施看上去很“重”，但真到出问题的时候，它们就是唯一能还原现场的东西。

5.3 熔断机制与人工复核，别让错误批量放大

自动化流程最容易出问题的一点，是错误会被批量放大。人工操作每天做100单，最多错几单；Agent一天跑几千单，一旦规则判断逻辑出错，可能一个小时内全错。所以在设计上必须加入熔断机制。

比较常用的做法是设置“滑动窗口成功率”。比如最近20次操作中，失败率达到30%，Agent自动暂停整个流程，并把剩余任务交给人工队列。同时在关键业务节点上保留人工抽检，尤其是涉及金额、合同、关键客户的流程，日终必须做一次对账，确保当天自动化处理的数据与源系统一致。这种机制看似保守，实际是让老板放心的根本保障。

5.4 视觉Agent、API与RPA的共存策略

要明确一件事：看屏幕型Agent不是要替代API，也不是要替代传统RPA。它是一个补充方案，用来处理那些API做不了、RPA又搞不定的场景。

合理的决策顺序应该是：能走API优先走API，接口成本低、性能好、稳定性高；有标准界面元素的流程，优先考虑传统RPA组件抓取，训练和运行成本都比较低；只有那些没有接口、界面复杂、跨系统切换频繁的流程，才应该动用视觉Agent。实际项目里，我倾向于把三者混用：API负责核心数据交换，RPA负责简单表单操作，视觉Agent负责最后一步跨系统协同。用视觉Agent解决“最后一公里”的问题，比单独依赖某一种技术要稳得多。

6. 一个可复用的评估框架：先算账，再立项

6.1 流程打分卡：别让“感觉”替你做决策

没有量化的流程评估，只会让项目停留在“感觉挺好”的阶段。我习惯给每个候选流程做一张“自动化可行性评分表”，根据分数决定优先级。

每项内容由业务负责人和IT工程师共同打分，1到5分，加权求和后排序。得分高且业务价值大的流程，进入试点清单。这里要说一句：频次低但出错影响大的流程，比如月度结账，往往也适合自动化，因为人工操作太容易出错。这类流程即使频率不高，也值得优先处理。

6.2 一个简单的ROI计算模板

算账其实并不复杂，核心口径就两个：节省多少人工时间，以及减少多少差错的隐性成本。

年节省工时等于“单次流程平均耗时乘以日均单量乘以全年工作天数”。举个例子，某流程每次耗时10分钟、每天跑50次、全年工作250天，那么全年节省工时约是10分钟乘以50乘以250，大概2083小时。按一个人每月有效工作时间160小时算，相当于节省了约13人月的人力。再把人力成本乘以人月单价，就是最直观的节省金额。

投入成本方面，需要考虑视觉模型或Agent平台的使用授权、实施工程师的配置工时、服务器或云资源、运维监控工时、以及上线初期的并行成本。把这些列出后，用节省收益除以投入成本，就能得到回收周期。我见过的项目，回收周期通常在六个月到一年之间。如果算下来超过一年半，说明这个流程选得不合适，需要再斟酌。

6.3 验收时盯住这四件事

项目上线前的验收，不是看技术演示有多漂亮，而是看真实业务里能不能连续跑。我会重点盯四件事。

第一，真实业务连续性。没有真实业务验证过的自动化，只能算原型。验收必须要求系统在实际的生产数据流里连续运行至少两个完整业务周期。第二，异常处理闭环。把试运行阶段遇到的所有异常类型逐条过一遍，确认每条都有对应的处理方式，不许遗留“待观察”。第三，审计和权限闭环。登录审计平台查一遍操作日志，确认全流程可追溯、可回放，自动化账号权限范围符合申请。第四，人机分工明确。谁是第一责任人、异常派发给谁、夜间问题谁处理，这些定义必须写进运维手册。

这四件事都做好了，项目才算真正可以交接。只要有一条不过关，就不要进入下一个阶段。

7. 一些实操体会

做了几个这类项目之后，我最大的感受是：看屏幕型Agent的难点从来不在“看”这一下，而在于看清之后的判断、校验、回归和治理。技术再强，没有一套完整的运营机制兜底，很容易从“解放人力”变成“制造事故”。

如果让我给准备启动这类项目的团队一条建议，那就是把预期降到能落地的程度：先选一个高频、流程清晰、界面稳定的小场景，用两到三周时间把成功率打磨到90%以上，让业务部门真实感受到“不用再人工操作了”，再逐步推广。不要一上来就画一个包含所有系统的宏大蓝图，那样很容易被现实打回原形。

企业数字化转型的路上，接口集成只是表象问题，本质上是流程、数据、组织协作方式的内部协调。具备“看屏幕”能力的Agent，恰好给“旧系统无法改造”这个长期难题提供了一条务实路径。它不完美，但胜在能落地。真到了需要一个过渡方案的时候，试着拿一条流程先跑跑看，你会发现有些事确实能用更轻的方式解决。