特工们现在能用电脑了吗？我们有相关数据

这听起来似乎很显然，但如果你离开硅谷，到世界其他地方去告诉人们：“有一种叫做智能代理的东西，它们非常聪明，能够与你一起完成任务，并自动处理工作中一些重复性的工作”，那么你很可能会首先听到这样的问题：“它们会用电脑吗？”

这是个很好的问题！它们真的能做到吗？在现实经济中，我们将在未来数十年里逐步释放出的巨大生产力潜力，其实就存在于各种日常工作中：一个智能代理能否（打个比方）全天 24 小时坐在办公桌前，被信任地使用网络浏览器、填写表格、点击正确的按钮且不犯错？这正是业务流程外包（BPO）所涉及的领域。过去，BPO 的含义仅仅是“这项工作能否外包”，但现在它已经迎来了由智能代理带来的新发展机遇。我们在去年就写过相关内容，那时电脑辅助应用的场景还大多只是各种演示而已。从那以后，情况已经发生了很大变化。

这些模型的进步速度超出了大多数人的预期。在那些流程较为固定且可重复的任务中，运用电脑的智能代理已经开始能够在大规模生产环境中稳定运行，比如更新记录系统、通过门户传输数据、处理工单、核查记录，以及处理那些没有标准 API 的复杂软件任务。借助合适的基础设施，如今可以利用这类电脑智能能力来处理端到端的复杂任务，而以往这类任务要么需要人工监督，要么必须由人工直接完成。

如今，那些借助电脑实现的流程还远未达到完美状态：当工作内容偏离既定流程时，这些智能代理就会表现不稳定；而在那些无法进行缓存处理的场景中（下文会详细说明），其成本又过高，导致在某些情况下并不具备经济可行性。不过，我们已经看到标准化后台工作的实际应用案例出现，尤其是那些原本需要人工通过传统系统操作的任务；考虑到这类基于电脑的流程具有全天候可用以及——最为重要的是——能够根据需求扩展规模等结构化优势，其成本效益正逐渐变得颇具吸引力。

第一波电脑相关基础设施的发展旨在让智能代理具备观看、点击、输入以及从错误中恢复的能力。而下一波发展则着眼于让它们在真实企业环境中发挥作用。随着基础的界面操作功能逐渐成为模型层层面的标准化功能，模型本身已不再是主要瓶颈，真正的持久竞争优势则转移到了更上层的环节：上下文环境、权限设置、流程知识、验证机制、问题升级处理、错误处理、缓存技术，以及通过对特定客户企业内部工作流程的深入理解来实现端到端的流程管理。换言之，发展的焦点正在从“智能代理能否使用电脑？”转变为“它能否可靠地完成这项任务？”。

从人工全程监控到真正的自主工作流程

一年前，性能最佳的电脑使用模型在 OSWorld-Verified 测试中的得分仅为 42%，而如今的最佳模型得分已达到 85%，这一数值超过了人类在完成相同任务时的~72%水平（即意味着它们能成功完成 100 项任务中的 85 项）。在实际应用环境中，这些最先进的模型表现与在测试环境中的情况类似：相关实验室会将电脑操作功能以 API 的形式提供——模型会获取屏幕截图，并反馈点击和按键操作信息，OpenAI 的 CUA 还会在条件允许时补充提供可访问性树或 DOM 数据——而后，开发者们会用自己的框架将这些功能整合起来：包括隔离式的虚拟机或浏览器，以及围绕其运行的调度、验证和重试机制。值得注意的是，几乎没有人会使用消费级产品（如 Claude、ChatGPT 的代理模式）来实现这一目标——创业者和企业通常直接利用原始 API，或从那些已将相关功能打包好的供应商处购买服务。正是性能上的显著提升使得这类方案具备了可行性，正如一位该领域的创业者所说：“在 2026 年 2 月 Opus 4.6 版本出现之前，这些模型本身还不足以直接用于实际生产环境。”在过去的 18 个月里，电脑端的智能应用能力已经从演示阶段发展到了可以实际部署使用的阶段。

当然，基准测试并不总是衡量实际应用可行性的最佳指标。OSWorld 仅统计已完成的任务数，因此 85%的完成率仍意味着 100 项任务中有 15 项失败了，而一个业务流程只有在所有步骤都顺利完成时才能算结束。后台工作并非按完成度来评估：如果还是由人工逐一检查输出结果，那就并没有节省任何劳动力。（这其实与当前编程领域的状况类似：如今稀缺的资源已不再是编写代码，而是对代码质量的担保。）

我们发现，要理解什么才是关键，就应该超越那些基准测试，转而关注核心问题：借助计算机处理能力，能否可靠地实现业务流程的自动化？从这一角度来看，起决定性作用的是与模型相关的所有因素——也就是验证机制、升级方案，以及当零售商的网站布局在夜间突然发生变化时的错误处理能力。

或许最明显的迹象是，我们采访过的一位每月要处理数百万项自动化任务的操作员，竟然说不出是哪种模型在执行这些任务——他其实也没必要知道。他的供应商会像云服务提供商更换硬件那样随时更换底层模型。但他确实信任这些能够使用人工智能的代理来执行任务。归根结底：当那些最频繁使用这些系统的用户不再关注排名榜时，排名榜也就不再重要了。

因此，上图解释了为何在 2026 年出现了实际应用部署，而在 2024 年却没有。从那之后，决定这些部署能否成功的关键因素就变成了其他一切——而这正是本文其余部分要探讨的内容。

这些智能体遵循相应的协议。

我们与那些在实际业务中运用人工智能代理处理工作流的团队进行了多次交流，从他们的经验中得知，遵循固定流程的任务最为适合使用这类人工智能代理。不出所料，在那些流程较为复杂、难以验证准确性的场景中，人工智能代理的表现就会变差。总体而言，这类人工智能代理在那些标准化、可重复且流程清晰明确的任务上表现最佳。而真正具有突破意义的，是那些没有标准 API、需要人工通过界面手动操作的软件任务。在实际应用中，这些任务包括在 CRM 系统中更新记录、进行质量检测、登录政府和保险机构的网站、从数据库及监管机构页面获取数据、处理零售订单、处理合同，以及在 ServiceNow 系统中处理 IT 工单等。

我们认为，用户的实际体验比任何理论都能更清晰地说明问题。以下是一些实例：某消费品数据平台向我们展示了他们如何每月处理高达 1 亿至 2000 万次自动化的门户交互任务，他们利用智能代理作为手动编写的抓取工具的自我修复替代方案——当零售商的门户界面发生变化时，智能代理能够立即检测到问题、修复自动化流程，从而在工程师发现故障之前就保证数据传输的持续进行。该平台表示，实施这一方案后，用于维护抓取工具的工程团队规模减少了一半，相应的人力资源可以被重新分配到其他工作流程中。在另一个案例中，我们从一家全球系统集成商那里了解到，他们使用了 27 个基于人工智能代理的工作流，每天可处理 1,500 至 2,100 份 IT 工单，其最终目标是将 20%到 25%的员工重新分配到利润较低的托管服务项目中。最后，还有一家机构向我们展示了他们如何实现招聘工作流的端到端自动化，以便在候选人面试结束后立即将相关数据录入申请跟踪平台。为此，他们使用了成本较低的非前沿地区训练出的模型，因为“它能完成我们所需的所有任务，而且表现优异”。

最典型的场景是那些理论上可以让计算机智能代理来处理并完成任务的流程，但要么难以界定“合格的结果标准”（即难以进行评估），要么没有可靠的方法来判断任务是否已完成。通常，以下情况会出现问题：(1) 无法对输出结果进行交叉验证——比如让智能代理从合同中提取付款条款并输入到 ERP 系统中：如果它将“净 60 天”误读为“净 30 天”，那么该记录看起来完全合理，也能通过所有视觉检查，直到发票开具出错时才有人发现问题。其次，在某些情况下，任务执行时并没有任何信号可以表明任务是否成功完成——比如某个智能代理在保险门户网站上提交理赔申请：申请已提交，屏幕显示“已收到”，任务似乎已完成。但两天后，理赔员会打电话到相关办公室，因为还需要确认保单号码才能继续处理该理赔。这时，由人类处理的理赔人员只需 30 秒就能解决问题；而智能代理却根本不知道有这个电话打来，结果理赔流程就停滞不前了。归根结底，除非相关系统从一开始就设计有应对这类异常情况的机制，否则再聪明的模型也无法改善那些需要通过电话与人联系才能解决问题的流程。

买家关注基础设施

在我们交谈过的采购方看来，模型本身很少成为决定性因素，因为“如今的模型已经足够好了”。实际上，他们会评估与模型相关的所有要素并为此付费：能够支持大规模稳定运行、通过安全审查以及展现投资回报率的基础设施。用户并不关心解决方案是否使用了最先进的模型，他们关注的是该方案能否真正实现大规模且可靠的任务处理。仅此而已。

因此，故障处理方式比任何基准标准都更为重要，从一开始就应将故障应对设计作为首要考虑因素——因为无法妥善处理故障的解决方案永远不可能被用于实际生产环境。我们在实践中多次遇到过这样的情形：智能体执行一次工作流后，系统会将其缓存为确定性代码，之后便以低成本、可重复的方式持续执行该任务，而只有当出现故障时才会重新调用模型来进行诊断、修复并再次缓存。采用这种方式，整个工作流生命周期内的运行成本都会下降，更便宜的模型则能进一步降低费用。有趣的是它处理不确定性的方式——以往确定性代码要么直接失效，要么需要人工逐一检查并修复故障，而在这里智能体能够自行承担这些不确定性。这是一种故障应对设计方法，也体现了消费者在实际应用中真正看重并愿意大规模采用的方案。

在与我们交谈过的用户中，我们并未见到更复杂的应用场景，这表明市场目前仍在解决那些较为容易实现的自动化任务。不过，在人们开始需要处理更复杂的任务之前，还有许多工作流程可以通过这种方式实现自动化。

模型并非决定性因素，情境才是。

对创业者而言，更重要的变化在于哪些技术正在变得日益标准化。过去，要构建能够执行任务的计算机智能体，就需要处理 Selenium 或 Playwright 这类工具，或是较新出现的 Stagehand，还要通过整合 DOM 数据或视频录像来记录工作流程。而如今，整个执行层正在被逐步抽象出来，就如同 Claude Code 将围绕编码智能体的各种辅助结构进行抽象处理一样。如果点击正确的按钮都已不再是一件困难的事，那它也就不再能构成任何竞争优势了。

不出所料，工作流程的上下文与相关知识具有很强的稳定性。关键问题不在于智能体能否操作 SAP 界面，而在于它是否理解某家公司的实际工作方式：那些传统的行业知识、内部术语、首选的文件格式、该向谁汇报以及何时汇报、如何处理故障、如何可靠地验证输出结果等。在实践中，这些信息存储在操作手册、访问权限与凭证、测试用例以及针对流程异常情况的应对措施中，越来越多地还体现在某人完成某项工作的录像资料里。这些都不是通用内容，而是特定于某家公司，甚至某个团队的。正因如此，专注于特定领域的初创公司往往比模型提供商更能解决这类具体且并不光鲜的问题，这也解释了为什么我们认为下一代智能协作工具应构建在应用层和上下文层，而非模型层。

我们交谈过的采购方也明确证实了这一点。他们在选择供应商时，会看产品能否在不增加工作量的情况下显示出节省的时间，以及初级工程师是否能够操作该产品。目前，真正的竞争优势并不在于那些前沿功能，而在于企业是否能够且被允许大规模地将某家供应商的产品用于实际业务中。

真正的转折点在于经济层面，而不仅仅是技术层面。

成本数据也同样令人鼓舞。上述数字仅作为大致范围，并非精确数值。目前运行一个智能体每小时的推理成本大约在 6 到 8 美元之间，但实际上这一数值会在 3 美元到 15 美元之间波动，具体取决于其集成方式——比如截图的频率、所能处理的上下文量，以及能交给确定性代码处理的任务比例。这些数据反映的是使用最昂贵的前沿模型、逐屏操作用户界面的情况。而设计良好的集成系统会将这种高成本模式留给真正需要它的场景，让低成本的确定性代码来处理那些可重复的任务——并非所有工作流都能通过这种方式优化，但在适用的情况下，综合成本会迅速下降。因此，可将这种对比视为最糟糕的情况——即便如此，当代理以每小时 1001 美元的满负荷成本运行时，其成本也与海外 BPO 大致相当；而若以每小时 30-45 美元的美国内部劳动力成本计算，其毛利率可达到 70-80%。在实际应用中，框架所带来的成本影响与模型本身差不多。

关于速度的问题同样存在限制。在智能体模式下，它们的处理速度仍慢于人类，差距相当明显——一个人两三分钟就能完成的任务，智能体可能需要八到十分钟，而学术测试得出的差距更大。如果是确定性执行，情况则有所不同：代码的运行速度会超过任何人类，但对于智能体处理的任务而言，关键并非速度，而在于智能体可以全天候运转、成本仅为美国劳动力的一小部分，且无需增加招聘人数即可实现规模扩展。

这一对比对 BPO 采购方和运营团队而言具有参考价值，但如果你是那些出售代理服务时长的一方，其成本结构则有所不同，因为实际场景中的成本更难预测。成本包括推理费用以及重试成本（即失败次的尝试仍会消耗代币），而当工作流程的复杂度增加或截图频率上升时，利润空间就会缩小。供应商通常通过按任务、按小时或按成果来定价来应对这一问题，不同定价方式对应着因工作流程差异而产生的不同风险水平。此外，监控、维护以及人工介入等实际问题也需要纳入成本考量，其处理方式与使用人工团队时类似。目前还不存在一种适用于所有行业的通用商业模式，具体方案需根据不同行业特点而定。

而且相关技术还在不断进步——推理成本持续降低，开源模型的性能也日益提升，足以应用于越来越多的工作流程中。对于任何智能体能够可靠解决的任务而言，使用计算机处理显然比依赖人工更为便捷。因此，现在的问题不再是其经济可行性如何，而是那些能够被可靠解决的任务范围还能扩展到多远，这正是未来发展的方向。

接下来我们该何去何从？

过去一年中，众多实验室以及一批初创企业投入了数亿美元用于构建计算机驱动的强化学习环境——这些环境就是模型用来练习实际任务并因完成任务而获得奖励的“沙箱”；Mechanize、Habitat、Fleet、Chakra、Deeptune、Matrices 和 Originator 等公司则负责为这些前沿模型打造训练与评估所需的基础设施。正是这些投入使得模型具备了更强的推理能力、更好的状态跟踪能力，以及对行为异常的应用程序更高的容忍度。虽然这些模型仍需通过精心设计的方式来确保在生产环境中的稳定运行——运行缓存便是最典型的例子——但它们所拥有的核心能力是通过这类训练基础设施刻意培养出来的，并且会随着时间不断得到提升。

不过，架构则是另一回事。目前投入实际应用的大多数计算机系统都属于单智能体架构：一个模型、一项任务、一个会话。随着工作流日益复杂且延迟成为制约因素，多智能体架构开始变得重要起来。例如，规划器负责分解工作流，执行智能体并行处理子任务，而那些需要长时间运行的智能体则带来了诸多问题：内存占用、信任度以及会随时间不断累积的故障率。目前从事相关研究的团队都在开发定制化的编排工具，因为尚未存在标准的框架。以 Claude Code 为例可以很好地说明这一点：当编程智能体技术成熟后，便出现了用于抽象化编排过程的支撑层。利用计算机智能体功能的工作流很可能会经历同样的发展过程，而这种抽象化层正是该领域中最为有趣且尚未解决的基础设施问题之一。

未来，相关技术的发展将围绕三个方向展开：准确性、延迟以及成本。其中准确性最为重要，正如前文所述，它决定了一个出色的演示与真正解决问题之间的差距——能够识别异常、自我检查工作成果，并且只在确实有必要时才采取进一步行动。延迟则是最可能让人感到意外的一点：目前已有团队通过使用操作流程结构而非截图的方式来降低延迟。Standard Intelligence 的通用计算机动作模型是基于 1100 万小时的视频数据集训练而成的，运行帧率为 30 FPS，这一事实表明，目前制约智能体效率的逐步截图机制是一个可以解决的问题，而非永久性的限制。随着推理成本的下降，以及更小的非前沿模型能够承担起常规操作任务，成本也会持续降低。除了安全与治理因素（如凭证管理、审计日志、数据保留策略、提示词注入问题以及责任归属与权限控制）之外，上述三个方向也将推动该领域的发展。

对于那些具有大量重复性操作、业务规则稳定但依赖旧有接口或缺少 API 的简单工作流程，企业已经能够并且正在从计算机智能代理中获益。目前，这类代理最适用于那些能够立即通过机器检测到完成情况、失败后果可承受且具备明确升级途径的任务。但随着上述技术的发展，相关性能正在快速提升，使得计算机智能代理能够应用于更多类型的工作中。

可以说——人工智能应用能力的未来十分光明！