AI不必等遗留系统改完：给智能体一张受管桌面

很多企业的智能体项目，并不是卡在模型能力，而是卡在一扇很普通的“桌面窗口”前：订单、理赔、财务、客户资料仍跑在多年定制的 ERP、CRM、主机程序或专有客户端里。它们承载着真实业务，却没有现成 API；要把每个环节重新集成，往往意味着长周期改造、预算争夺和新的合规评估。于是，业务说“先把系统改完”，AI 项目说“那就下个年度再见”。

AWS 在 6 月底宣布其面向 AI 智能体的 WorkSpaces 已全面可用：智能体可在受管云桌面中查看屏幕、操作桌面应用，而不必先改造应用或另建定制集成。它还支持沿用既有身份、网络隔离、合规边界与审计归因，并允许运营人员实时查看会话、在会话中撤销访问。这个产品信号值得企业认真看待：遗留系统不再只是“等改造完才能自动化”的障碍，它正在变成智能体必须被纳入治理的执行现场。

真正被打通的，不是一个界面，而是一条责任链

让智能体像人一样点击、输入、滚动，确实绕过了“没有 API”的门槛；但这不是让它获得一个无边界的鼠标。AWS 的公开说明里，智能体使用独立身份与权限进入受管环境，屏幕截图可被保存用于审计和排障，运营者可以实时控制会话并中途收回权限。换句话说，企业交给智能体的不应是一台无人问津的虚拟机，而是一份可回放、可追责、可中止的岗位授权。

当智能体开始操作老系统，最小管理单元不该是“给它开了什么权限”，而应是“它在什么场景、以什么身份、完成哪一步、留下什么证据、谁能随时叫停”。

这也解释了为什么“能看屏幕”并不等于“可以直接上线”。界面会变化，弹窗会出现，数据会在操作中改变；同一套权限在不同业务场景里的风险也不同。以页面自动化替代接口集成，解决的是连接成本，并没有自动解决动作边界、异常处理和责任归属。

上线前，先写一张“桌面执行卡”

我建议企业不要从“让它接管整个系统”开始，而是为一个高频、边界清楚的动作建立桌面执行卡。它至少应包含五项：第一，任务触发条件和允许读取的数据；第二，可点击、可填写、可提交的动作清单；第三，遇到金额、敏感字段、陌生页面或结果不确定时的升级出口；第四，必须保存的证据，如会话记录、关键截图、系统回执；第五，业务负责人、技术负责人和停止权限的归属。

然后把它放进模拟环境和小范围真实流程中验证。要看的不只是完成率，还包括：它是否在正确的身份下操作、是否遇到异常就停、人工接管是否足够及时、每次提交能否反查。这样，企业就不会把“一个能点鼠标的演示”误当成“可运营的生产能力”。

STARBOX视角：把执行环境也纳入组织资产

在 STARBOX 看来，企业智能体不是脱离组织独自“会干活”的工具。组织层先定义业务目标、品牌和数据边界、审批规则及责任人；BOX 层沉淀流程说明、系统操作知识、桌面执行卡、异常样本与验收标准；智能体层才在这些边界内完成具体动作。这样，换模型、换界面、换执行方式时，真正重要的业务规则和复盘证据仍留在企业手里。

这给我们的新提醒是：企业 AI 的“最后一公里”不只是把智能体接进系统，更是把它放进一套可管理的执行环境。DDABC 闭环可以把人工叫停、异常页面、被退回的结果和成功步骤持续沉淀下来，帮助团队判断该改知识、改权限、改流程，还是停止这个动作。最终可复制的，不是一段自动点击脚本，而是一套带有边界和证据的执行能力。

下一次有人说“系统太老，AI 还不能做”时，或许该把问题换成：我们能否先为一个具体任务准备受管环境、清晰授权和随时可撤销的出口？遗留系统未必需要先被推倒重来；但任何进入它的智能体，都必须先学会在组织的规则里工作。

信息来源：AWS《Announcing general availability of Amazon WorkSpaces for AI agents》（2026-06-30）；AWS News Blog《Modernize your workflows: Amazon WorkSpaces now gives AI agents their own desktop》（2026-05-05，2026-07-01 更新）。