)
)
AI代理开始以与人类用户相似的方式与桌面应用程序互动。对于IT团队来说，这提出了一个重要问题：现有的Windows软件，包括没有现代API的应用程序，是否可以在不先被替换或重建的情况下，变得可被AI驱动的工作流程访问？
这个答案的影响超出了人工智能自动化。它影响桌面架构、应用交付、身份、权限和网络安全，特别是当代理可以采取行动而不仅仅是检索信息时。
为什么AI代理需要访问桌面应用程序？
API的位置？
大多数企业自动化在软件通过应用程序编程接口（API）进行通信时效果最佳。API提供结构化的操作和可预测的输入输出，而无需软件解释图形界面。
困难在于企业环境中包含的应用程序从未围绕现代API设计。定制的Windows应用程序、较旧的ERP客户端和专有的业务软件在其原始架构过时后仍然可能是必不可少的。
输入AI代理
计算机使用提供了另一种途径。AI代理可以潜在地与提供给人类用户的相同接口进行交互，而不需要每个应用程序都暴露API。
这不再仅仅是实验性的。亚马逊网络服务（AWS）现在将亚马逊工作区定位为一个托管环境，AI代理可以在其中操作桌面应用程序，包括没有现代API的应用程序。微软同样将Windows 365 for Agents描述为一个执行环境，用于需要与缺乏可靠API的桌面和Web应用程序进行交互的任务。
由于这些是供应商的提议，请假设并非每个遗留应用程序或工作流程都已准备好进行自主操作。在规划生产基础设施时请注意这一点。
AI代理如何实际使用Windows应用程序？
桌面AI代理并不是以相同的方式与软件互动。计算机使用系统可以分析屏幕截图并生成鼠标点击和键盘输入，有效地再现一些与图形用户界面的人工互动。
其他方法使用操作系统控制、可访问性信息或更接近机器人流程自动化（RPA）的确定性自动化技术。混合架构可以将这些方法与API或模型上下文协议（MCP）工具结合起来。
AWS，例如，将可视桌面交互与MCP工具转发相结合，允许适当的任务使用直接工具而不是像素级交互。微软还在其Windows 365 for Agents架构中区分了计算机使用代理和RPA。
对于IT团队来说，这一区别是重要的。当结构化接口可靠且安全地提供所需功能时，通常应优先选择它。图形用户界面交互在没有合适的编程途径时变得特别有趣。
每个 AI 代理都需要自己的桌面吗？
一旦代理需要图形应用程序，IT团队必须决定该交互应该发生在哪里。
本地桌面访问
代理可以在物理工作站上操作安装的软件。这提供了对现有应用程序、文件和用户上下文的直接访问，但也有可能在同一环境中混合人类和自主活动的风险。
本地执行也需要仔细定义。代理可以在本地运行，同时将提示、屏幕截图或应用程序数据发送到远程托管的AI模型。桌面运行的位置和数据处理的位置是两个不同的架构问题。
专用虚拟桌面和DaaS
专用虚拟桌面创建了更强的隔离。AWS WorkSpaces 为 AI 代理和 Microsoft Windows 365 为代理展示了这一模型，为代理工作负载提供了受管理的桌面会话，而不是允许他们直接在员工工作站上操作。Microsoft 描述了具有受管理身份、设备状态和受管会话生命周期的池化云 PC。
桌面即服务（DaaS）因此成为人工智能代理和人类用户的一个可能执行层。
远程应用交付
然而，整个虚拟桌面并不总是必要的。如果代理只需要一两个Windows应用程序，IT团队还可以考虑这些应用程序是否应该集中托管并作为受控的远程会话交付。
这将把架构问题从“代理的桌面应该在哪里？”转变为“这个代理实际上需要访问哪些资源？”
人工智能能给传统Windows应用程序带来新生吗？
传统上，遗留软件在自动化项目中提供了一个困难的选择。如果一个重要的应用程序缺乏API，组织可能需要定制集成、RPA或应用程序现代化，然后才能将其连接到更新的工作流程。
AI代理增加了另一种可能性。如果软件能够解释和操作现有的用户界面，GUI本身可以成为一个集成界面。
AWS明确提出避免应用程序现代化和自定义集成作为其代理WorkSpaces的用例。微软正在开发从代理Cloud PC访问本地业务应用程序的功能，类似地将该能力框定为在不首先现代化遗留应用程序的情况下自动化工作流程。
这并不意味着每个旧应用程序都适合 AI 桌面自动化。接口会变化，视觉解释可能会失败，会话可能会达到意想不到的状态，许可可能会限制应用程序的使用。虽然从技术上讲，代理可以访问的工作流程仍然需要测试其可靠性、可支持性和商业风险。
AI代理访问会产生哪些新的安全和合规问题？
给予AI代理访问商业软件的权限将其角色从信息助手转变为主动系统参与者。因此，安全模型需要假设代理可能会犯错误、误解上下文或采取从未打算的技术上允许的行动。
AI代理需要身份和定义的权限
代理访问应以最小权限开始。IT团队需要确定代理使用哪个帐户、可以访问哪些应用程序和文件、可以到达哪些网络资源，以及是否可以执行特权或破坏性操作。
PocketOS事件特别生动地说明了为什么架构控制很重要。在2026年4月，一名在进行阶段任务的AI编码代理获得了一个铁路API令牌，并在一次API操作中删除了公司的生产数据库及相关备份。报告的删除过程耗时九秒。
这节课的内容比编码代理更广泛。指示代理不要执行危险操作并不等同于基础设施阻止该操作。
本地人工智能和第三方人工智能创建不同的数据路径
组织还需要映射信息的流动路径。桌面可能在本地托管，而解释其内容的模型则在第三方基础设施上运行。
截图可能会暴露客户记录、凭据或机密应用数据。提示、日志和上下文信息可能会产生额外的数据流，受保留、居住和监管要求的限制。
在部署之前，IT团队应识别代理执行的位置、AI模型执行的位置以及应用程序数据处理或保留的位置。
人类批准需要一个有意义的界限
在采取重要行动之前，人机协作控制最为重要，而不是之后。删除数据、改变权限、提交财务交易或修改生产系统可能需要明确的确认，或者简单地超出代理的允许范围。
更广泛的风险不再是假设。人工智能事件数据库在2026年5月至7月的处理期间新增了148个事件ID，同时警告这些新增事件跨越不同日期，不应被解读为事件频率的测量。然而，它的汇总仍然突显了涉及自主系统、隐私和人工智能辅助网络安全活动的反复出现的问题。
2026年7月的Hugging Face入侵提供了不同的警告：Hugging Face报告称，其生产基础设施的一部分遭到了一种自主AI代理系统的端到端入侵。这是一种攻击，而不是授权的企业代理超越其权限，但它展示了自主软件如何迅速探索和在可访问的基础设施上采取行动。
日志在用户使用软件时显得尤为重要
代理会话应留下足够的证据，以重建发生的事件。身份验证记录、会话活动、应用程序日志和代理操作都可以为该审计轨迹提供贡献。
管理员还需要一种快速终止活动的方法。AWS 为 AI 代理在 WorkSpaces 中添加了实时会话可见性和访问撤销，而微软则将监控、会话控制和人工干预描述为其代理 Cloud PC 架构的一部分。这些控制表明 IT 团队应该提出的操作性问题，无论平台如何。
在给予AI代理桌面访问权限之前，IT应该决定什么？
一个有用的起点是将AI代理视为一种新的特权用户类别，而不是一种异常强大的自动化脚本。
在允许桌面访问之前，确定GUI交互是否确实必要，并将代理与其不需要的资源隔离。为其提供一个具有最小权限的专用身份，并定义哪些操作需要人工批准或无法自主执行。
IT团队还应确保活动可以被记录、停止和调查。最后，故障条件的测试应与成功工作流程一样故意：当应用程序冻结、凭据失败或出现意外信息时，代理的行为可能比在理想序列中的行为更为重要。
远程应用交付适合在哪里？
AI代理的到来并不意味着组织需要更多的云PC。对于已经集中托管Windows应用程序的环境，远程应用程序交付提供了另一种架构可能性。
TSplus Remote Access 提供集中式 Windows 应用程序发布和远程访问，无需每个用户操作完整的云桌面。当组织开始评估对现有应用程序的代理访问时，同样的原则提出了一个有趣的可能性：围绕应用程序和任务提供访问，而不是自动围绕整个桌面。
这并不是说 TSplus Remote Access 本身就是一个 AI 代理平台。相反，AI 代理使得关于应用程序发布、会话隔离、访问控制和基础设施所有权的现有问题与新类型的应用程序消费者相关。
AI代理将改变对遗留应用程序的处理方式
传统的Windows应用程序是围绕人们坐在键盘前设计的。使用计算机的代理通过使图形界面可能对软件可访问来挑战这一假设。
对于IT团队来说，重要的问题不仅仅是一个AI代理是否能够点击旧的Windows应用程序。关键在于如何仅提供代理所需的访问权限，同时保持对身份、数据、会话和基础设施的控制。随着AI代理成为应用程序用户，合理的远程访问架构可能会变得越来越重要，而不是减少。
)
)
)
