Holo4：驱动通用型计算机使用智能体，但基准差距仍不容忽视

Holo4 于 9 月 28 日发布，包含两款模型、四种交互模式，并直接向专用计算机使用系统发起挑战。H Company 将 Holo4：驱动通用型计算机使用智能体 描述为一个模型家族：它既能浏览屏幕、执行代码，也能调用软件工具。

此次发布之所以重要，是因为计算机自动化很少局限于单一界面。一项业务流程可能从浏览器开始，经由 API 继续，最终在缺乏现代集成能力的桌面软件中完成。多数智能体系统会通过组合不同模型、工具和控制循环来处理这种切换。

Holo4 提出了一条更简单的路径。同一个模型可以在图形界面、代码、Model Context Protocol 工具和 API 之间作出选择。MCP 是一种标准，可让 AI 系统通过结构化连接访问外部工具和数据。

这一承诺使 Holo4 面对的是专用型架构，而不仅仅是另一家模型供应商。专用型方案会将视觉导航、编程和工具调用分别交给不同模型或策略。H Company 则认为，经过训练的单一通用模型能够更高效地协调这些交互表面。

该公司还开放了数千条基准测试轨迹供外界查阅。这种透明度为开发者提供了比分数榜单更丰富的证据，但并不能解答现实组织环境中的可靠性、安全性或性能问题。

Holo4：跨越四类界面驱动通用型计算机使用智能体

核心变化在于架构：Holo4 将界面视为任务中的一项选择，而非围绕智能体划定的固定边界。

根据 Holo4 release，该模型家族包括一款稠密型 270 亿参数模型，以及一款 350 亿参数的混合专家模型。后者在每一步推理中约激活 30 亿参数。

混合专家模型会将输入路由至选定的内部组件，而非激活全部参数。这种设计可以减少计算量，但实际速度仍取决于硬件、软件和部署选择。

两款 Holo4 模型都可以与图形用户界面交互、编写并执行代码，以及调用 MCP 或 API 工具。H Company 表示，同一模型可在桌面端、网站、Android 设备、编程沙盒和业务系统中运行。

这不同于只能根据截图预测鼠标点击的智能体，也不同于在应用缺少 API 时便失效的工具调用模型。Holo4 的设计目标是在工作流发生变化时切换方法。

以一项常规财务操作为例。智能体可能需要从文档中提取字段，用代码将其标准化，通过 API 提交，再在屏幕上核验结果。较旧的企业软件则可能迫使其再次切换至鼠标和键盘控制。

通用模型可以在这些阶段中维持同一个决策过程。专用型技术栈通常会将每个阶段路由至独立模型、策略或服务。这种路由有助于提升控制力，但也会带来更多交接和故障点。

H Company 表示，其通过监督学习和强化学习，在生成式交互环境中训练 Holo4。据称，其内部任务工厂已创建约 10,000 项任务，涵盖 Web 应用、桌面端、MCP 服务器及混合环境。

这些生成任务十分重要，因为静态示例无法复现智能体操作所带来的后果。交互环境能够测试一次点击是否改变状态、代码是否执行，或 API 调用是否产生预期记录。

该方法还让 H Company 能够根据文档和截图生成任务。这可能在无需人工设计每一个工作流的情况下扩大训练覆盖范围。不过，生成环境仍可能与充满权限限制、延迟和意外状态的复杂生产系统存在差异。

此次发布还包括升级后的 Holotron4 Nano 模型，以及两款主要 Holo4 变体。模型权重提供多种格式，包括 BF16、FP8、NVFP4 和四位 GGUF。

这些格式为开发者提供了多样化部署选择。但更关键的主张仍是：单一模型可以协调多个界面，无需外部模型选择层。

这使得 Holo4：驱动通用型计算机使用智能体 成为一项检验：界面通用性能否在不牺牲专用智能体精确度的前提下，降低系统复杂度。

为何长工作流会让专用智能体技术栈承压

Holo4 对专用技术栈构成压力，是因为长工作流会放大每一次路由决策、上下文交接和恢复步骤的成本。

简短的浏览器任务可能掩盖架构弱点。智能体或许只需打开一个页面、输入一个值并提交表单。即使脆弱的系统，有时也能完成这套流程。

专业工作则不同。它涉及多个应用、持续状态、模糊指令，以及执行过程中才出现的信息。智能体必须记住早先的约束，同时适应后续事件。

OSWorld 2.0 正是围绕这种更困难的场景设计。其研究人员汇集了 108 项覆盖日常与专业工作的长程工作流。熟练人类完成每项任务的时间中位数约为 1.6 小时。

该基准报告称，领先智能体在每个工作流中平均可执行超过 300 步。OSWorld 1.0 的任务约需 30 步，因此新基准对上下文管理提出了严格得多的考验。

失败并不止于点击不准确。研究人员观察到，智能体会遗失约束、遗漏新出现的信息、在需要澄清时猜测，以及跳过验证。这些缺陷会在漫长流程中不断累积。

H Company 表示，它针对这些问题重构了 Holo4 的智能体执行框架。执行框架是为模型提供观察、管理上下文、运行操作并返回结果的执行循环。

其中最值得关注的两项新增能力，是支持数百步操作的持久记忆，以及运行在桌面设备上的 shell。后者让智能体能够在直接 GUI 交互变得低效时，转而采用基于代码的路径。

此时，通用型设计的意义已不只是功能清单。模型可以判断，用代码解析本地文件比通过视觉读取更合适；随后再回到界面中，执行需要视觉确认的操作。

专用技术栈也能完成同样的序列。不过，它必须决定何时移交控制权，以及每次移交需要携带多少上下文。错误的路由选择可能浪费步骤或丢失信息。

Holo4 试图将这项决策置于训练后的模型内部。若这种方法能稳定发挥作用，开发者或可减少协调浏览器控制、桌面控制、代码执行和结构化工具所需的逻辑。

这并不意味着编排会被消除。生产系统仍需要凭据管理、沙盒、重试、日志和审批关卡，也需要可靠机制，以便在不确定操作造成损害前停止智能体。

这种转变的范围较窄，但依然具有意义。开发者可以减少判断何种模型应处理各类界面的精力，转而更专注于定义权限、验证输出和衡量完整工作流。

这一区别对构建 searchable knowledge base 的团队尤为重要。他们的工作流经常跨越本地文档、内部搜索、浏览器工具和结构化企业系统。

Holo4 并未证明通用模型会取代每一种专用模型。它只是让专用路由成为开发者需要论证的设计选择，而不再是不可避免的基础。

单一智能体模型更简洁，但专用模型仍设定可靠性门槛

核心竞争在于单一通用模型与协同专用模型技术栈之间，可靠性将决定哪种架构胜出。

专用模型拥有直观优势。为视觉定位进行狭义训练的模型可以专注于定位控件；编程模型则可以专注于语法、执行和调试，无需解读每一张截图。

工具调用模型也受益于结构化模式。API 会公开允许执行的操作和可预测字段。图形界面提供了更大灵活性，但按钮、布局和瞬态状态会带来模糊性。

专用方案允许工程师为每种交互表面选择最合适的模型，也可以隔离高风险能力。例如，视觉智能体可以获得屏幕访问权限，而不拥有任意 shell 执行能力。

然而，专业化将复杂性转移至外围系统。路由器必须对每个阶段分类、选择组件，并在交接中保留用户意图。技术栈还必须协调不同的上下文格式和故障信号。

Holo4 的通用路径则将部分协调工作转移到模型内部。智能体可以查看屏幕、识别出直接操作效率不高，并改用代码或结构化工具。

H Company 以专业软件任务说明这一方法。在一个案例中，据称 Holo4 27B 使用 68 次调用和 240 万 token，在 Godot 中构建了一款自主游戏。在相同提示词和执行框架下，其 Qwen 基础模型使用了 197 次调用和 1,140 万 token。

这些数据来自 H Company 自身评估，而非独立实验室。它们描述的是单一任务，而不是平均生产性能。尽管如此，它们展示了该公司希望 Holo4 实现的效率类型。

其他案例涉及在 FreeCAD 中构建细节丰富的对象。这类工作流结合空间理解、软件控制和代码生成，比填写单个网页表单要求更高。

这些案例也揭示了一项限制。据称，Holo4 的埃菲尔铁塔任务需要 84 次调用和 130 万 token。即使最终结果成功，长时间的计算机使用会话仍可能带来沉重计算负担。

当工作流可预测时，专用模型仍保有另一项优势。确定性脚本或狭义 API 集成可能比在多种可能操作中选择的智能体更快，也更容易审计。

当工作流多变、界面变化，或遗留系统缺乏集成能力时，通用方案更具优势。当组织需要可重复性并能精确定义流程时，专用方案仍更具优势。

这意味着 Holo4 不太可能消除传统自动化。相反，它竞争的是一个不确定的中间地带：固定脚本会失效，而不受约束的前沿智能体仍过于昂贵或难以治理。

因此，开发者应评估完整任务，而非孤立的点击操作。真正相关的问题是，Holo4 能否在真实工作流中减少失败和工程开销。

若一个模型通过更少交接达到正确的最终状态，即便其在某项狭义技能上的原始精度较低，也可能是合理的选择。若通用模型以不可预测的方式切换方法，则可能造成更大的调试负担。

最终结果将取决于轨迹质量、可复现性和恢复行为。这些因素比某种架构在图表上是否显得更简洁更重要。

Holo4 基准结果需要结合其执行框架与脚注解读

Holo4 的成绩值得关注，但发布内容本身也说明，若干醒目的对比并不能直接等同。

H Company 表示，Holo4 27B 在 OSWorld 2.0 上取得了 61.7% 的成绩，其 35B-A3B 模型达到 30.9%。该公司将这些结果与 Opus 5.5 的 81.8% 进行比较。

Holo4 27B 与 Opus 5.5 之间 20.1 个百分点的差距相当明显。在这项公布的指标上，Holo4 并未领先最强的闭源模型。其论点主要围绕模型规模、部署灵活性和预估任务成本展开。

H Company 还引用了 Opus 5 的 70.2% 和 GPT-5.6 Sol 的 66.2%。这些参考成绩采用的是截至 2026 年 8 月 8 日的离线 OSWorld 2.0 数据集，在最高推理强度下按部分奖励计算。

发布内容提醒，不同模型版本、测试框架和任务子集之间存在差异。每一项对比都应附带这一警示。智能体性能远不只取决于模型检查点。

测试框架决定了记忆管理、工具访问、观察结果格式、重试行为和最大步数。即使底层模型不变，调整其中任何一个变量都可能改变结果。

成本图表同样需要谨慎解读。H Company 根据每次运行所使用的输入和输出 token 估算费用。它按照自身 API 费率为 Holo4 定价，并采用其他模型的外部公开标价。

此类估算可用于内部规划，但并非受控的经济测量。缓存假设、推理基础设施、重试次数和批量折扣都会改变实际部署成本。

AutomationBench 带来了另一项可比性问题。H Company 在其内部测试框架中使用 1.0.6 版本评估 Holo4 及其 Qwen 基线模型。其他模型的成绩则来自该基准的公开数据集。

其他模型引用的成本数据来自一个使用私有数据集的排行榜。H Company 表示，将在完成测试后报告 Holo4 在该私有评估中的表现。

在此之前，读者不应将所有 AutomationBench 数据点视作同一项受控实验的结果。它们是在不同条件下得出的相关测量结果。

即使是基准定义也会影响叙事。OSWorld 2.0 支持二元完成判定和部分得分。一款模型即使未能完成整个工作流，也可能获得有意义的部分分数。

这并不意味着部分评分毫无价值。对于二元成功标准会掩盖改进的长任务，它能够揭示进展。然而，采购方更关心最终记录、文件或交易是否正确完成。

效率同样不能只看 token 数量。关于智能体效率的研究发现，在其评估中，领先的计算机操作智能体执行的步骤数量是必要数量的 1.4 至 2.7 倍。

同一研究还发现，后续步骤所耗时间可能远长于早期步骤。规划和反思调用占据了大部分延迟。因此，冗长的智能体轨迹带来的延迟可能远超其可见操作数量所显示的程度。

这些发现支持了 H Company 对记忆和 shell 访问的关注。它们也说明，成功的基准分数并不会自动带来可接受的用户体验。

更公平的解读既不是否定，也不是全盘接受。对于一款相对紧凑的模型而言，Holo4 展现出有竞争力的公司自报成绩，但仍落后于领先的闭源系统。

真正的检验在于，这些结果能否在独立测试框架、私有评估，以及包含组织特定权限和数据的工作流中持续成立。

开放轨迹提升可验证性，而非安全性

H Company 最能增强可信度的举措，是公开支撑其成绩的轨迹；但可检查的行为并不自动意味着安全的行为。

轨迹数据集包含 Holo4 27B 和 Holo4 35B-A3B 的 7,366 次运行记录。每条轨迹可能包括任务、推理、操作、工具结果、截图、时长、步骤及最终得分。

该集合包含两款模型合计超过 2,100 次 OSWorld 运行，也包含 212 次 OSWorld 2.0 运行及近 3,200 次 AutomationBench 运行。

其他轨迹涵盖 AndroidWorld、PinchBench 和 Agents’ Last Exam。H Company 允许用户下载数据集，或通过专用查看器回放轨迹。

这项披露为研究人员提供了多种检验公司结论的方式。他们可以检查一次成功运行是否采用合理路径、是否重复了不必要的操作，或是否受益于任务特定的捷径。

他们也可以分析失败模式。汇总分数无法展现智能体是误解了指令、点击了错误目标、丢失了上下文，还是在验证前停止。

开放轨迹可以揭示性能提升究竟来自更好的推理，还是更宽松的测试框架。它们也能帮助团队估算人工干预可能需要多频繁。

然而，执行后的透明度不同于执行前的控制。轨迹能帮助调查者理解发生了什么，却无法阻止智能体发送数据、删除文件或遵从恶意指令。

计算机操作智能体面临着传统聊天系统通常不会遇到的风险。它们运行在包含不可信内容和高价值凭据的环境中。网页可以将对抗性文本直接置于模型的观察内容中。

OS-Harm 基准在 150 项任务中测试蓄意滥用、提示注入和非预期模型行为。其研究人员发现，多套前沿系统均存在具有实际意义的不安全行为。

该研究没有评估 Holo4，因此其结果不能证明 Holo4 的安全性。但它表明，具备出色的计算机控制能力与具备安全的计算机控制能力，是两个独立的评估问题。

当单一模型拥有广泛接口访问权限时，风险会更加突出。一个通用模型可以从阅读网页转而运行代码或调用 API。这种灵活性提高了实用性，也扩大了失误可能造成的影响。

无论基准成绩如何，企业都需要分层控制措施。这些措施包括限定范围的凭据、隔离执行环境、受限网络访问、可逆操作，以及对关键步骤的人类审批。

企业还需要能够将每项操作与用户指令及当时观察到的状态关联起来的日志。Holo4 的轨迹格式为这类审计记录提供了一个有益范例。

许可同样值得关注。开放权重并不保证每个检查点或组件都拥有完全相同的商业使用权。团队应在部署前审查每份模型卡和依赖项。

数据治理亦是如此。截图和智能体轨迹可能记录个人信息、客户资料或机密文件。记录一切可以改善调试，但也会形成另一份敏感数据集。

H Company 表示，其公开轨迹发布中已对凭据、内部主机和个人数据进行了脱敏。生产环境运营方必须为自身轨迹建立同等的脱敏和保留控制措施。

这一开放数据集提高了未来发布的标准。声称在计算机操作能力上更优的供应商，如今拥有了一个更清晰的可复现证据范例。

不过，最有价值的外部工作仍将包括对抗性回放、独立评分，以及在 H Company 测试框架之外进行的测试。透明度开启了这一过程，但并未完成它。

三项信号将揭示 Holo4 的通用模型押注是否成立

下一阶段应通过独立复现、私有基准结果和生产工作流证据来判断。

第一个信号是对 Holo4 OSWorld 2.0 性能的独立复现。研究人员需要使用已发布的权重，并遵循已记录的基础设施、提示词、步数限制和评分规则进行测试。

若能复现公布的 61.7%，将增强 H Company 关于能力主要由模型本身带来的主张。若出现较大差异，则表明公司测试框架的贡献可能高于标题所暗示的程度。

复现工作还应比较二元完成率、部分得分、步骤数、延迟和干预率。单一分数无法反映智能体能否在实际限制内达成可用结果。

已发布的轨迹使这项工作更易开展。研究人员可以从已知运行记录出发，研究失败边界，并将替代测试框架与相同任务进行比较。

第二个信号是 Holo4 在私有 AutomationBench 中的成绩。发布内容承认，其当前分数来自内部对公开数据集的测试，而对比成本则引用了私有数据集排行榜。

私有评估将形成更干净的对比，并减少针对可见任务调优的担忧。它还将检验 Holo4 是否能在陌生的 API 工作流中实现泛化。

结果不应只包括成功率。开发者需要在同一套有文档记录的评估设置下，获得成本、token 使用量、重试次数、延迟和失败类别等数据。

第三个信号是来自混合接口工作流的可信生产证据。最佳案例应涉及确实需要在同一会话中结合 GUI、代码和结构化工具的任务。

有价值的报告应展示无需人工修正的完成情况、从界面变化中恢复的能力，以及在受限权限下的表现。它还应统计不可逆错误，而不仅仅是成功运行次数。

费用处理工作流提供了一个具有代表性的测试。智能体必须读取文档、验证字段、与业务软件交互，并确认记录已达到预期状态。

另一项有力测试是跨越本地文件、问题跟踪器、浏览器控制台和命令行工具的工程运维。此类工作流可以揭示共享上下文究竟是优势，还是失控行为的来源。

模型更新将提供相关信号。H Company 表示，计划推出经优化的 drafter 检查点以加速推理。可测量的延迟降低将强化通用架构的经济性论据。

竞争对手的回应同样重要，但仍只是辅助证据。闭源模型供应商可以提升计算机操作能力，开放模型开发者也可以在其发布中加入更广泛的工具训练。

核心问题并不是 Holo4 是否始终领先于每一种替代方案，而是单一通用模型能否比专家模型堆栈提供更优的可靠性与复杂度比率。

对于开发者而言，眼下的机会是进行受控评估。使用具有代表性的任务、受限凭据和可逆环境。衡量已完成的结果，而不是孤立的模型操作。

对于企业采购方而言，采购问题还应涵盖测试框架。应询问哪个组件负责管理记忆、审批、重试、密钥、审计日志，以及部分执行后的恢复。

对于知识工作者而言，此次发布表明智能体将跨越更多应用边界。这种便利也使权限设计和可见确认变得更重要。

Holo4：为通用计算机操作智能体提供动力，因此与其说是胜利宣言，不如说是一项具体的架构挑战。H Company 已提供模型、主张和异常详细的轨迹。

下一步属于独立评估者和部署团队。Holo4 能否复现其公布结果、应对陌生任务，并在不扩大运营风险的前提下完成真实工作？

这三项测试将决定，通用计算机操作智能体究竟是简化自动化，还是仅仅将其最棘手的问题转移到别处。