Holo4: 범용 컴퓨터 사용 에이전트를 구동하지만, 벤치마크 격차는 여전히 중요하다

Holo4는 9월 28일 두 개의 모델과 네 가지 상호작용 모드를 내놓으며, 특화된 컴퓨터 사용 시스템에 직접 도전장을 던졌다. H Company는 Holo4: 범용 컴퓨터 사용 에이전트를 구동하는 모델을 화면을 탐색하고, 코드를 실행하며, 소프트웨어 도구를 호출할 수 있는 하나의 모델 패밀리로 설명한다.

이 출시는 컴퓨터 자동화가 하나의 인터페이스 안에만 머무르는 경우가 드물기 때문에 중요하다. 하나의 비즈니스 프로세스는 브라우저에서 시작해 API를 거친 뒤, 현대적 통합 기능이 없는 데스크톱 소프트웨어에서 끝날 수 있다. 대부분의 에이전트 시스템은 서로 다른 모델, 도구, 제어 루프를 결합해 이 전환을 처리한다.

Holo4는 더 단순한 경로를 제안한다. 같은 모델이 그래픽 인터페이스, 코드, Model Context Protocol 도구, API 가운데 선택할 수 있다. MCP는 AI 시스템이 구조화된 연결을 통해 외부 도구와 데이터에 접근할 수 있게 하는 표준이다.

이 약속은 Holo4를 단순히 또 하나의 모델 공급업체가 아니라, 특화 에이전트 아키텍처와 경쟁하게 만든다. 특화 방식은 시각적 탐색, 코딩, 도구 호출에 각각 다른 모델이나 정책을 배정한다. H Company는 훈련된 하나의 범용 모델이 이러한 표면을 더 효율적으로 조율할 수 있다고 주장한다.

회사는 수천 개의 벤치마크 트래젝터리도 검토할 수 있도록 공개했다. 이러한 투명성은 개발자에게 리더보드 점수만으로는 얻기 어려운 근거를 제공한다. 다만 실제 조직 내 신뢰성, 안전성, 성능에 관한 의문까지 해소하는 것은 아니다.

네 가지 인터페이스 전반에서 범용 컴퓨터 사용 에이전트를 구동하는 Holo4

핵심 변화는 아키텍처에 있다. Holo4는 인터페이스를 에이전트 주변의 고정된 경계가 아니라 작업 안에서 선택할 수 있는 수단으로 다룬다.

Holo4 출시 발표에 따르면, 이 패밀리에는 270억 파라미터의 밀집형 모델과 350억 파라미터의 mixture-of-experts 모델이 포함된다. 후자는 각 추론 단계에서 약 30억 개의 파라미터를 활성화한다.

mixture-of-experts 모델은 모든 파라미터를 활성화하는 대신, 입력을 선택된 내부 구성 요소로 라우팅한다. 이 설계는 연산량을 줄일 수 있지만, 실제 속도는 하드웨어, 소프트웨어, 배포 방식에 따라 달라진다.

두 Holo4 모델은 모두 그래픽 사용자 인터페이스와 상호작용하고, 코드를 작성·실행하며, MCP 또는 API 도구를 호출할 수 있다. H Company는 동일한 모델이 데스크톱, 웹사이트, Android 기기, 코딩 샌드박스, 비즈니스 시스템에서 작동할 수 있다고 말한다.

이는 스크린샷을 기반으로 마우스 클릭만 예측하는 에이전트와 다르다. 애플리케이션에 API가 없을 때 무력해지는 도구 호출 모델과도 다르다. Holo4는 워크플로가 바뀌는 과정에서 방법을 전환하도록 설계됐다.

일상적인 재무 업무를 생각해 보자. 에이전트는 문서에서 필드를 추출하고, 코드로 이를 정규화한 다음, API를 통해 제출하고, 화면에서 결과를 검증할 수 있다. 오래된 엔터프라이즈 소프트웨어는 다시 마우스와 키보드 제어로 전환하게 만들 수 있다.

범용 모델은 이런 단계 전반에서 하나의 의사결정 과정을 유지할 수 있다. 특화 스택은 일반적으로 각 단계를 별도 모델, 정책 또는 서비스로 라우팅한다. 이러한 라우팅은 제어력을 높일 수 있지만, 더 많은 인계와 실패 지점도 만든다.

H Company는 생성된 인터랙티브 환경 전반에서 지도 학습과 강화 학습을 통해 Holo4를 훈련했다고 말한다. 회사의 내부 태스크 팩토리는 웹 애플리케이션, 데스크톱, MCP 서버, 하이브리드 환경을 포괄하는 약 10,000개의 작업을 만들었다고 전해진다.

이러한 생성 작업은 정적 예제가 에이전트 행동의 결과를 재현할 수 없기 때문에 중요하다. 인터랙티브 환경은 클릭이 상태를 변경했는지, 코드가 실행됐는지, API 호출이 의도한 레코드를 만들었는지를 시험할 수 있다.

이 방식은 H Company가 문서와 스크린샷에서 작업을 생성할 수 있게도 한다. 이는 모든 워크플로를 수작업으로 설계하지 않고도 훈련 범위를 넓힐 수 있다. 다만 생성된 환경은 권한, 지연, 예상치 못한 상태가 존재하는 복잡한 프로덕션 시스템과 여전히 다를 수 있다.

이번 출시에는 두 주요 Holo4 변형과 함께 업데이트된 Holotron4 Nano 모델도 포함됐다. 또한 BF16, FP8, NVFP4, 4비트 GGUF를 포함한 여러 형식의 모델 가중치를 제공한다.

이러한 형식 지원은 개발자에게 여러 배포 선택지를 제공한다. 그러나 더 중요한 주장은 외부 모델 선택 계층 없이 하나의 모델이 여러 인터페이스를 조율할 수 있다는 것이다.

따라서 Holo4: 범용 컴퓨터 사용 에이전트를 구동하는 모델은 특화 에이전트가 제공하는 정밀도를 희생하지 않으면서 인터페이스 범용성이 시스템 복잡도를 줄일 수 있는지에 대한 시험대가 된다.

긴 워크플로는 특화 에이전트 스택에 압박을 가한다

Holo4는 긴 워크플로에서 모든 라우팅 결정, 컨텍스트 인계, 복구 단계의 비용이 누적되기 때문에 특화 스택에 압박을 가한다.

짧은 브라우저 작업은 아키텍처의 약점을 가릴 수 있다. 에이전트는 한 페이지를 열고, 값을 입력한 뒤, 양식을 제출할 수 있다. 취약한 시스템도 때로는 이 순서를 완료한다.

전문 업무는 다르다. 여러 애플리케이션, 지속되는 상태, 모호한 지시, 실행 중에 등장하는 정보를 포함한다. 에이전트는 이후 상황에 적응하면서 앞서의 제약을 기억해야 한다.

OSWorld 2.0은 이러한 더 어려운 환경을 중심으로 설계됐다. 연구진은 일상 및 전문 업무에 걸친 108개의 장기 워크플로를 구성했다. 숙련된 인간은 각 작업을 완료하는 데 중앙값 약 1.6시간이 필요하다.

이 벤치마크는 선도적인 에이전트가 워크플로 하나당 평균 300단계 이상을 수행할 수 있다고 보고한다. OSWorld 1.0 작업은 약 30단계가 필요했으므로, 새 벤치마크는 컨텍스트 관리에 훨씬 더 엄격한 시험이다.

실패는 부정확한 클릭에만 그치지 않는다. 연구진은 에이전트가 제약을 잊고, 들어오는 정보를 놓치며, 명확화가 필요한 상황에서 추측하고, 검증을 건너뛰는 모습을 관찰했다. 이런 약점은 긴 프로세스 전반에서 누적될 수 있다.

H Company는 이러한 문제에 대응해 Holo4 에이전트 하니스를 재구축했다고 말한다. 하니스는 관측을 제공하고, 컨텍스트를 관리하며, 행동을 실행하고, 결과를 모델에 반환하는 실행 루프다.

가장 주목할 만한 두 가지 추가 사항은 수백 단계에 걸친 지속 메모리와 데스크톱 머신에서 실행되는 셸이었다. 셸은 직접적인 GUI 상호작용이 비효율적일 때 에이전트에 코드 기반 경로를 제공한다.

여기서 범용 설계는 단순한 기능 목록 이상의 의미를 갖는다. 모델은 로컬 파일을 코드로 파싱하는 편이 시각적으로 읽는 것보다 낫다고 판단할 수 있다. 이후 시각적 확인이 필요한 작업을 위해 다시 인터페이스로 돌아갈 수 있다.

특화 스택도 같은 순서를 수행할 수 있다. 그러나 언제 제어를 넘길지, 각 전환에 어느 정도의 컨텍스트를 함께 보낼지를 결정해야 한다. 잘못된 라우팅 선택은 단계를 낭비하거나 정보를 버릴 수 있다.

Holo4는 이 결정을 훈련된 모델 내부에 배치하려 한다. 이 접근이 일관되게 작동한다면, 개발자는 브라우저 제어, 데스크톱 제어, 코드 실행, 구조화된 도구를 조율하는 데 필요한 로직을 줄일 수 있다.

그렇다고 오케스트레이션이 사라지는 것은 아니다. 프로덕션 시스템에는 여전히 자격 증명 관리, 샌드박싱, 재시도, 로깅, 승인 게이트가 필요하다. 불확실한 행동이 피해를 일으키기 전에 에이전트를 멈출 신뢰할 수 있는 방법도 필요하다.

이 변화는 더 제한적이지만 여전히 의미가 있다. 개발자는 어떤 모델이 각 인터페이스를 처리해야 하는지 결정하는 데 드는 노력을 줄일 수 있다. 대신 권한 정의, 출력 검증, 전체 워크플로 측정에 더 집중할 수 있다.

이 구분은 검색 가능한 지식 베이스를 구축하는 팀에 중요하다. 이들의 워크플로는 흔히 로컬 문서, 내부 검색, 브라우저 도구, 구조화된 회사 시스템을 넘나든다.

Holo4가 범용 모델이 모든 특화 모델을 대체할 것이라는 점을 증명하는 것은 아니다. 대신 특화 라우팅을 피할 수 없는 기반이 아니라 개발자가 정당화해야 하는 설계 선택으로 만든다.

하나의 에이전트 모델은 더 단순하지만, 특화 모델은 여전히 신뢰성의 기준을 세운다

주된 경쟁은 하나의 범용 모델과 조율된 특화 모델 스택 사이에서 벌어지며, 어느 아키텍처가 이길지는 신뢰성이 결정한다.

특화 모델은 직관적인 장점을 제공한다. 시각적 그라운딩에 좁게 훈련된 모델은 컨트롤을 찾는 데 집중할 수 있다. 코딩 모델은 모든 스크린샷을 해석하지 않고도 문법, 실행, 디버깅에 집중할 수 있다.

도구 호출 모델도 구조화된 스키마의 이점을 얻는다. API는 허용된 행동과 예측 가능한 필드를 노출한다. 그래픽 인터페이스는 더 많은 유연성을 제공하지만, 버튼, 레이아웃, 일시적 상태는 모호성을 만든다.

특화 방식은 엔지니어가 각 표면에 가장 적합한 모델을 선택하게 한다. 위험한 기능을 분리할 수도 있다. 시각 에이전트는 임의의 셸 실행 권한 없이 화면 접근 권한만 받을 수 있다.

그러나 특화는 복잡성을 주변 시스템으로 옮긴다. 라우터는 각 단계를 분류하고, 구성 요소를 선택하며, 인계 전반에서 사용자의 의도를 보존해야 한다. 스택은 서로 다른 컨텍스트 형식과 실패 신호를 조정해야 한다.

Holo4의 범용 경로는 이러한 조율 일부를 모델 내부로 옮긴다. 에이전트는 화면을 보고 직접 조작이 비효율적임을 인식한 뒤, 대신 코드나 구조화된 도구를 사용할 수 있다.

H Company는 전문 소프트웨어 작업으로 이 접근을 설명한다. 한 사례에서 Holo4 27B는 Godot에서 자율형 게임을 만드는 데 68회의 호출과 240만 토큰을 사용한 것으로 전해진다. 같은 프롬프트와 하니스에서 Qwen 기반 모델은 197회의 호출과 1,140만 토큰을 사용했다.

이 수치는 독립 연구소가 아니라 H Company 자체 평가에서 나온 것이다. 평균적인 프로덕션 성능이 아니라 하나의 작업을 설명한다. 그럼에도 회사가 Holo4로 달성하려는 효율성의 유형을 보여 준다.

다른 사례에는 FreeCAD에서 세부적인 객체를 구성하는 작업이 포함된다. 이러한 워크플로는 공간 해석, 소프트웨어 제어, 코드 생성을 결합한다. 하나의 웹 양식을 작성하는 것보다 더 까다롭다.

사례는 한계도 드러낸다. Holo4의 Eiffel Tower 작업에는 84회의 호출과 130만 토큰이 필요했던 것으로 전해진다. 최종 결과가 성공하더라도 긴 컴퓨터 사용 세션은 여전히 연산 비용이 클 수 있다.

워크플로가 예측 가능할 때 특화 모델은 또 다른 장점을 유지한다. 결정론적 스크립트나 범위가 좁은 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는 각 실행에서 사용된 입력 및 출력 토큰을 기반으로 비용을 추정했다. Holo4에는 자체 API 요금을 적용했고, 다른 모델에는 외부 공개 가격을 사용했다.

이러한 추정치는 내부 계획 수립에는 도움이 될 수 있지만, 통제된 경제 측정값은 아니다. 캐싱 가정, 추론 인프라, 재시도, 물량 할인은 실제 배포 비용을 바꿀 수 있다.

AutomationBench는 또 다른 비교 가능성 문제를 제기한다. H Company는 내부 하니스에서 버전 1.0.6을 사용해 Holo4와 Qwen 기준 모델을 평가했다. 다른 모델의 점수는 벤치마크의 공개 세트에서 가져왔다.

다른 모델의 참조 비용 수치는 비공개 세트로 운영되는 리더보드에서 가져왔다. H Company는 테스트가 완료된 뒤 해당 비공개 평가에서 Holo4 결과를 보고할 계획이라고 밝혔다.

그때까지 독자는 모든 AutomationBench 점수를 하나의 통제된 실험에서 나온 결과로 받아들여서는 안 된다. 이들은 서로 다른 조건에서 산출된 관련 측정값이다.

벤치마크 정의조차 서사를 형성할 수 있다. OSWorld 2.0은 이진 완료와 부분 점수 방식을 지원한다. 모델은 완성된 워크플로를 제공하지 못하면서도 의미 있는 부분 점수를 받을 수 있다.

그렇다고 부분 점수가 쓸모없다는 뜻은 아니다. 이진 성공 기준이 개선을 가릴 수 있는 장기 작업에서 진전을 식별할 수 있다. 다만 구매자는 최종 레코드, 파일 또는 거래가 올바른지에 관심을 둔다.

효율성 역시 토큰 수만으로는 충분히 평가할 수 없다. 에이전트 효율성에 관한 연구는 선도적인 컴퓨터 사용 에이전트가 평가에서 필요한 것보다 1.4배에서 2.7배 많은 단계를 수행했다는 사실을 발견했다.

같은 연구는 후반 단계가 초기 단계보다 훨씬 오래 걸릴 수 있다는 점도 확인했다. 계획 및 성찰 호출이 지연 시간의 상당 부분을 차지했다. 따라서 긴 에이전트 추적은 보이는 행동 수를 넘어 지연을 증폭시킬 수 있다.

이러한 발견은 메모리와 셸 접근에 대한 H Company의 초점을 뒷받침한다. 동시에 성공적인 벤치마크 점수가 자동으로 수용 가능한 사용자 경험을 만들어내지는 않는 이유도 보여준다.

공정한 해석은 기각도 무비판적 수용도 아니다. Holo4는 비교적 소형 모델로서 경쟁력 있는 회사 보고 결과를 제시했지만, 선도적인 폐쇄형 시스템에는 뒤처진다.

실질적인 검증은 이 결과가 독립 하니스, 비공개 평가, 조직별 권한과 데이터를 포함한 워크플로에서도 유지되는지에 달려 있다.

공개 추적 기록은 검증을 개선하지만 안전성을 보장하지는 않는다

H Company의 가장 강력한 신뢰성 제고 조치는 점수의 근거가 된 추적 기록을 공개한 것이지만, 검토 가능한 행동이 자동으로 안전한 행동을 뜻하지는 않는다.

trajectory dataset에는 Holo4 27B와 Holo4 35B-A3B의 실행 기록 7,366건이 담겨 있다. 각 추적 기록에는 작업, 추론, 행동, 도구 결과, 스크린샷, 실행 시간, 단계, 최종 점수가 포함될 수 있다.

이 컬렉션에는 두 모델을 합쳐 2,100건이 넘는 OSWorld 실행 기록이 포함돼 있다. 또한 OSWorld 2.0 실행 212건과 AutomationBench 실행 약 3,200건도 담고 있다.

추가 추적 기록은 AndroidWorld, PinchBench, Agents’ Last Exam을 다룬다. H Company는 사용자가 데이터세트를 다운로드하거나 전용 뷰어를 통해 추적 기록을 재생할 수 있도록 한다.

이 공개는 연구자들에게 회사의 결론에 도전할 여러 방법을 제공한다. 연구자들은 성공한 실행이 합리적인 경로를 사용했는지, 불필요한 행동을 반복했는지, 작업별 지름길의 혜택을 받았는지 살펴볼 수 있다.

실패 패턴도 분석할 수 있다. 집계 점수만으로는 에이전트가 지시를 오해했는지, 잘못된 대상을 클릭했는지, 맥락을 잃었는지, 검증 전에 멈췄는지를 알 수 없다.

공개 추적 기록은 성능 향상이 더 나은 추론에서 비롯됐는지, 더 관대한 하니스에서 비롯됐는지도 드러낼 수 있다. 또한 팀이 사람의 개입이 얼마나 자주 필요할지 추정하는 데 도움을 줄 수 있다.

하지만 실행 이후의 투명성은 실행 이전의 통제와 다르다. 추적 기록은 조사자가 무엇이 일어났는지 이해하는 데 도움을 준다. 에이전트가 데이터를 전송하거나, 파일을 삭제하거나, 악의적인 지시를 따르는 일을 막지는 못한다.

컴퓨터 사용 에이전트는 기존 채팅 시스템이 피하는 위험에 직면한다. 이들은 신뢰할 수 없는 콘텐츠와 가치 있는 자격 증명이 있는 환경에서 작동한다. 웹페이지는 적대적인 텍스트를 모델의 관찰 정보 안에 직접 배치할 수 있다.

OS-Harm benchmark는 150개 작업 전반에서 의도적인 오용, 프롬프트 인젝션, 의도치 않은 모델 동작을 테스트한다. 연구진은 여러 프런티어 시스템에서 의미 있는 수준의 안전하지 않은 행동을 발견했다.

이 연구는 Holo4를 평가하지 않았으므로, 그 결과로 Holo4의 안전성을 입증할 수는 없다. 다만 유능한 컴퓨터 제어와 안전한 컴퓨터 제어가 별개의 평가 문제임을 보여준다.

하나의 모델이 폭넓은 인터페이스 접근 권한을 가질 때 위험은 더 커진다. 범용 모델은 웹페이지를 읽는 일에서 코드를 실행하거나 API를 호출하는 일로 이동할 수 있다. 이러한 유연성은 유용성과 실수의 잠재적 영향 모두를 키운다.

기업은 벤치마크 점수와 무관하게 다층적 통제가 필요하다. 여기에는 범위가 제한된 자격 증명, 격리된 실행, 제한된 네트워크 접근, 되돌릴 수 있는 작업, 중요한 단계에 대한 사람의 승인이 포함된다.

또한 각 행동을 사용자의 지시 및 당시 관찰된 상태와 연결하는 로그도 필요하다. Holo4의 추적 기록 형식은 이러한 감사 기록에 유용한 모델을 제시한다.

라이선스도 주목할 필요가 있다. 공개 가중치가 모든 체크포인트나 구성 요소에서 동일한 상업적 권리를 보장하지는 않는다. 팀은 배포 전에 각 모델 카드와 종속성을 검토해야 한다.

데이터 거버넌스도 마찬가지다. 스크린샷과 에이전트 추적 기록은 개인정보, 고객 기록 또는 기밀 문서를 포착할 수 있다. 모든 것을 기록하면 디버깅은 개선될 수 있지만, 또 다른 민감한 데이터세트가 생긴다.

H Company는 공개 추적 기록 릴리스에서 자격 증명, 내부 호스트, 개인정보를 마스킹했다고 밝혔다. 프로덕션 운영자는 자체 추적 기록을 위해 동등한 수준의 비식별화 및 보존 통제를 구축해야 한다.

공개 데이터세트는 향후 출시의 기준을 높인다. 우수한 컴퓨터 사용 성능을 주장하는 공급업체는 이제 재현 가능한 증거가 어떤 모습일 수 있는지에 대한 더 명확한 사례를 갖게 됐다.

그럼에도 가장 가치 있는 외부 작업은 적대적 재생, 독립 채점, H Company 하니스 외부에서의 테스트를 포함할 것이다. 투명성은 그 과정을 열어주지만, 완성하지는 않는다.

세 가지 신호가 Holo4의 범용 모델 전략이 성립하는지 보여줄 것이다

다음 단계는 독립 재현, 비공개 벤치마크 결과, 프로덕션 워크플로의 증거를 통해 평가돼야 한다.

첫 번째 신호는 Holo4의 OSWorld 2.0 성능을 독립적으로 재현하는 일이다. 연구자들은 문서화된 인프라, 프롬프트, 단계 제한, 채점 규칙과 함께 공개된 가중치를 실행해야 한다.

보고된 61.7%를 재현한다면 모델 자체가 해당 역량을 갖고 있다는 H Company의 주장이 강화될 것이다. 큰 차이가 난다면 회사의 하니스가 헤드라인이 시사하는 것보다 더 크게 기여했음을 암시할 수 있다.

재현 연구는 이진 완료, 부분 점수, 단계 수, 지연 시간, 개입률도 비교해야 한다. 하나의 점수만으로는 에이전트가 실용적인 한계 안에서 사용할 수 있는 결과에 도달하는지를 포착할 수 없다.

공개된 추적 기록은 이 작업의 실현 가능성을 높인다. 연구자들은 알려진 실행 기록에서 시작해 실패 경계를 살펴보고, 동일한 작업에 대해 대체 하니스를 비교할 수 있다.

두 번째 신호는 Holo4의 비공개 AutomationBench 결과다. 발표문은 현재 점수가 공개 세트에서의 내부 실행에서 나왔으며, 비교 비용은 비공개 세트 리더보드를 참조한다는 점을 인정한다.

비공개 평가는 더 깔끔한 비교를 만들고, 공개된 작업에 맞춘 튜닝에 대한 우려를 줄일 수 있다. 또한 Holo4가 익숙하지 않은 API 워크플로 전반에서 일반화되는지도 시험할 것이다.

결과에는 성공률 이상이 포함돼야 한다. 개발자에게는 하나의 문서화된 평가 설정 아래 비용, 토큰 사용량, 재시도, 지연 시간, 실패 범주가 필요하다.

세 번째 신호는 혼합 인터페이스 워크플로에서의 신뢰할 수 있는 프로덕션 증거다. 가장 좋은 사례는 하나의 세션 안에서 GUI, 코드, 구조화된 도구를 실제로 모두 필요로 하는 작업일 것이다.

유용한 보고는 사람의 수정 없이 완료된 결과, 인터페이스 변경으로부터의 복구, 제한된 권한 아래의 성능을 보여줄 것이다. 성공한 실행만이 아니라 되돌릴 수 없는 오류도 집계해야 한다.

비용 처리 워크플로는 대표적인 테스트를 제공한다. 에이전트는 문서를 읽고, 필드를 검증하고, 비즈니스 소프트웨어와 상호작용하며, 기록이 의도한 상태에 도달했는지 확인해야 한다.

또 다른 강력한 테스트는 로컬 파일, 이슈 트래커, 브라우저 콘솔, 명령줄 도구를 아우르는 엔지니어링 운영일 것이다. 이러한 워크플로는 공유 맥락이 장점인지 통제되지 않은 행동의 원천인지를 드러낸다.

모델 업데이트도 관련 신호를 제공할 것이다. H Company는 추론을 가속하기 위해 최적화된 drafter 체크포인트를 계획하고 있다고 밝혔다. 측정된 지연 시간 감소는 범용 아키텍처의 경제적 근거를 강화할 것이다.

경쟁사의 대응도 중요하지만, 보조 증거에 머문다. 폐쇄형 모델 제공업체는 컴퓨터 사용 기능을 개선할 수 있으며, 공개 모델 개발업체는 자체 릴리스에 더 광범위한 도구 학습을 추가할 수 있다.

핵심 질문은 Holo4가 모든 대안보다 계속 앞서는지 여부가 아니다. 하나의 범용 모델이 전문 모델 스택보다 더 나은 신뢰성 대비 복잡성 비율을 제공하는지 여부다.

개발자에게 당장의 기회는 통제된 평가다. 대표적인 작업, 제한된 자격 증명, 되돌릴 수 있는 환경을 사용하라. 개별 모델 행동이 아니라 완료된 결과를 측정하라.

기업 구매자에게는 조달 질문에 하니스도 포함돼야 한다. 어떤 구성 요소가 메모리, 승인, 재시도, 비밀 정보, 감사 로그, 부분 실행 후 복구를 관리하는지 물어야 한다.

지식 근로자에게 이 발표는 에이전트가 더 많은 애플리케이션 경계를 넘나들게 될 것임을 시사한다. 그 편의성은 권한 설계와 눈에 보이는 확인 절차를 더욱 중요하게 만든다.

Holo4: 범용 컴퓨터 사용 에이전트를 구동하다는 승리 선언이라기보다 구체적인 아키텍처적 도전 과제다. H Company는 모델, 주장, 그리고 이례적으로 상세한 추적 기록을 제공했다.

다음 수는 독립 평가자와 배포 팀의 몫이다. Holo4는 보고된 결과를 재현하고, 익숙하지 않은 작업을 견디며, 운영 위험을 확대하지 않고 실제 업무를 완료할 수 있을까?

이 세 가지 테스트는 범용 컴퓨터 사용 에이전트가 자동화를 단순화할지, 아니면 가장 어려운 문제를 다른 곳으로 옮길지 결정할 것이다.