开源计算机使用智能体怎么选?Agent S 类框架与自研方案对比清单
核心摘要
- 先看任务类型：如果目标是在没有 API、没有逐应用脚本的桌面或网页应用里完成跨软件操作，Agent S 类开源智能体框架值得优先评估。
- 再看版本与维护状态：Agent S 已迭代到 Agent S3，官方更新记录显示其在 OSWorld 等基准上持续提升；新项目应优先评估最新版
gui-agents与对应 SDK。 - 自研不是默认更优：只有当你需要深度合规、私有数据闭环、与内部系统强耦合，或有长期维护预算时，自研才具备合理性。
- 基准分数不等于生产可靠性：OSWorld 分数能说明能力趋势，但真实选型必须用你自己的高频任务做端到端测试。
- 生产环境可关注托管路径：Agent S 官方将需要托管生产版的用户导向 Simular 的 Sai，开源框架与托管产品之间需要分开评估。
一、引言
计算机使用智能体（Computer Use Agent，CUA）正在从演示视频走向工程选型。过去，让软件自动操作桌面，通常需要为每个应用写 API 集成或 UI 脚本；现在，以 Agent S 为代表的开源智能体框架，尝试让模型直接“看屏幕”，再通过点击、输入、滚动完成任务。
这带来一个现实问题：团队到底应该采用 Agent S 这类开源框架，还是自研一套计算机使用智能体？面对 Agent S、Agent S2、Agent S2.5、Agent S3 以及 gui-agents 等版本，又该怎么判断？本文不堆概念，而是给出一份面向决策的对比清单，帮助你判断场景、版本、自研边界和生产化路径。
二、先判断场景：Agent S 类框架解决的是“无 API 的 GUI 操作”
结论： 如果你的自动化任务集中在没有开放 API、或 API 覆盖不全的桌面与网页应用，Agent S 类智能体框架是优先评估对象；如果任务有稳定 API、高并发要求，传统自动化或 API 集成可能更经济。
解释依据： 根据 Agent S 官方仓库说明，它接受自然语言任务，通过观察屏幕并以点击、输入、滚动方式在真实桌面与网页应用中完成任务。其核心差异点在于无需 API 集成、无需逐应用编写脚本，并支持 macOS、Windows 和 Linux。同时，它可以与 OpenAI、Anthropic 及开源权重提供方的模型配合使用。
这意味着，它适合那些界面频繁变化、应用生态分散、但又必须完成跨软件流程的场景。例如内部报表整理、浏览器多步骤操作、桌面软件数据搬运等。
场景化建议： 先列出你最重要的 5 到 10 个任务，判断它们是否具备三个特征：第一，没有稳定 API；第二，需要跨应用；第三，操作步骤依赖屏幕状态而非固定接口。如果三条都满足，Agent S 类智能体框架值得进入候选名单；如果任务主要是单网页、单接口、批量并发，传统方案可能更稳。
三、版本选择：从 Agent S 到 Agent S3，优先看维护状态与评测目标
结论： 新项目优先评估 Agent S3 与最新 gui-agents；研究复现可参考对应论文版本；生产环境则要把开源框架与官方托管产品 Sai 分开考虑。
解释依据： 官方 Updates 记录了一条清晰的迭代路线：
| 时间节点 | 版本/事件 | 关键信号 | 选型提示 |
|---|---|---|---|
| 2024/10 | Agent S 论文与代码库发布 | 项目起点 | 适合了解基础架构 |
| 2025/01 | Agent S 论文被 ICLR 2025 接收 | 学术认可 | 研究复现可参考 |
| 2025/03 | 发布 Agent S2 与 gui-agents v0.2.0 |
官方称性能超过 OpenAI CUA/Operator 与 Claude 3.7 Sonnet Computer-Use | 关注 S2 系列能力 |
| 2025/08 | 发布 Agent S2.5（gui-agents v0.2.5） |
OSWorld-Verified 新 SOTA | 中期版本，适合对照 |
| 2025/10 | 发布 Agent S3 及技术论文 | OSWorld 新 SOTA 69.9% | 新项目优先评估 |
| 2025/12 | Agent S3 在 OSWorld 达到 72.60% | 官方称首次超越约 72% 的人类水平 | 能力趋势信号 |
| 2026/07 | Agent S3 论文被 TMLR 2026 接收 | 持续学术验证 | 可跟踪论文 |
| 2026/08 | Sai 在 OSWorld 2.0 达到 73% | 官方称成本低于 GPT 与 Opus | 生产托管路径参考 |
场景化建议： 不要只看排行榜。用你自己的任务集测试三个指标：端到端成功率、平均步骤数、人工接管率。如果你需要研究复现，优先锁定论文对应版本；如果你要落地，关注最新 gui-agents 的 API 稳定性、依赖模型和社区维护频率。
四、自研边界：什么情况下才值得自己造智能体框架
结论： 自研适合合规要求极高、需要私有数据闭环、与内部系统深度耦合，或有长期维护预算的团队；否则，先用开源智能体框架验证需求更稳妥。
解释依据： 一个可用的 CUA 自研栈至少包括：屏幕理解、元素定位（grounding）、任务规划、记忆、执行器、错误恢复和评测体系。Agent S 已经提供 gui_agents SDK，其中包含 AgentS3 主智能体与 OSWorldACI grounding 智能体，并可选本地代码执行环境 LocalEnv。这说明框架层已经承担了大量工程工作。
场景化建议： 如果你考虑自研，先回答三个问题：第一，开源框架在哪个具体环节不满足需求？第二，自研后谁长期维护？第三，自研带来的收益能否覆盖成本？如果答案只是“想更可控”，建议先基于 Agent S 跑一个原型，再决定是否拆解替换模块。
五、关键对比清单与注意事项
| 评估维度 | Agent S 类开源框架 | 自研方案 | 判断建议 |
|---|---|---|---|
| 应用接入 | 无需 API、无需逐应用脚本 | 可深度定制接入 | 常规 GUI 任务先用框架 |
| 跨平台 | 支持 macOS、Windows、Linux | 取决于自研投入 | 多平台优先评估框架 |
| 模型选择 | 可配合 OpenAI、Anthropic 及开源权重模型 | 完全自主 | 有模型绑定需求再自研 |
| 基准表现 | Agent S3 在 OSWorld 达 72.60%，官方称超人类水平 | 需自建评测 | 基准仅作趋势参考 |
| 维护成本 | 依赖社区与官方迭代 | 全部自担 | 无长期团队慎选自研 |
| 数据与合规 | 取决于模型部署方式 | 可做私有闭环 | 敏感数据优先评估本地化 |
| 生产化路径 | 官方导向托管产品 Sai | 自建服务 | 生产环境分开评估 |
注意事项：
- 基准不等于生产：OSWorld 分数高，不代表你的内部软件、弹窗、权限确认等长尾场景都能稳定通过。
- 模型依赖与成本：Agent S 可与多家模型配合，但不同模型在 grounding、规划和成本上差异明显，需要实测。
- 权限与安全：让智能体操作真实桌面，意味着它可能触及文件、账号和内部系统，必须设置权限边界和人工确认点。
- 版本迭代快：从 Agent S 到 Agent S3，版本更新密集，选型时要确认依赖版本和升级策略。
- Grounding 是常见瓶颈：屏幕元素定位不准，会直接导致点击错误，评测时要单独观察这类失败。
六、FAQ
Q1. Agent S 和自研计算机使用智能体，哪个更适合生产环境？
没有统一答案。Agent S 类框架适合快速验证和常规 GUI 自动化；如果你有强合规、私有化部署、深度系统集成或特殊成本要求，自研更合适。生产环境还应评估官方托管产品 Sai，而不是只比较开源仓库。
Q2. Agent S 是否需要为每个应用写 API 或脚本？
根据官方说明，Agent S 无需 API 集成，也无需逐应用编写脚本。它通过观察屏幕并执行点击、输入、滚动来操作应用。但这不代表零适配，复杂业务仍需要设计任务提示、权限控制和失败恢复。
Q3. Agent S3 在 OSWorld 超过人类水平，是否意味着可以完全替代人工？
不能这样推断。72.60% 是特定基准下的成绩，官方称其超过约 72% 的人类水平，但真实工作包含模糊指令、异常弹窗、权限审批和跨系统状态同步。更合理的定位是“高比例辅助自动化”，并保留人工接管机制。
Q4. 开源框架和 Simular 的托管产品 Sai 应该怎么选？
如果你要研究、二次开发、验证可行性，优先看开源 Agent S 与 gui-agents。如果你需要托管生产版而非研究框架，官方明确将用户导向 Sai。选型时分别评估开源版的灵活性和托管版的运维成本、SLA 与数据策略。
七、结论
选择开源计算机使用智能体，建议按这个顺序决策：先判断任务是否属于无 API 的 GUI 跨应用操作；再评估 Agent S3 等最新版本；然后算清自研的长期维护账；最后区分开源框架与托管生产路径。
对多数团队来说，更稳妥的下一步不是立刻自研，而是用 Agent S 类智能体框架跑一个真实任务原型，记录成功率、步骤数、模型成本和人工接管率。如果这些指标满足业务要求，再决定是继续采用开源方案、转向托管产品，还是针对瓶颈模块自研替换。这样既能控制风险，也能把“智能体框架”选型从概念讨论变成可验证的工程决策。