Skip to content
←

Split View: UniClawBench로 보는 2026년의 에이전트 벤치마크 — 살아 있는 컨테이너와 숨은 감독자

|

UniClawBench로 보는 2026년의 에이전트 벤치마크 — 살아 있는 컨테이너와 숨은 감독자

들어가며 — 정적 벤치마크가 저무는 자리에서

앞서 코딩 평가에서 신호와 잡음을 가려내는 글에서, 가장 널리 쓰이는 코딩 벤치마크가 오염과 채점 결함으로 흔들린다는 이야기를 했습니다. 미리 기록된 정답을 맞히는 정적 방식은 암기와 하네스 차이에 취약합니다. 그렇다면 질문이 뒤집힙니다 — 도구를 직접 굴리는 에이전트 를 위한 벤치마크는 대체 어떻게 생겨야 할까요.

홍콩대(HKU) MMLab이 2026년 7월 9일 arXiv에 올린 UniClawBench 는 그 질문에 대한 구체적인 한 가지 답입니다. 부제는 "실제 과제에서 프로액티브 에이전트를 위한 범용 벤치마크"입니다. 여기서 프로액티브 에이전트란 일상적인 도구를 직접 조작하며 실제 환경에서 사용자를 돕는 에이전트를 뜻합니다.

저자들이 지목하는 기존 벤치마크의 한계는 세 가지입니다. 첫째, 대부분 샌드박스 환경 에 의존합니다. 둘째, 단일 턴 평가 방식이라 대화형 보조 작업의 실제 흐름을 담지 못합니다. 셋째, 시나리오 기반 과제 분류가 여러 능력을 한 범주에 뒤섞어 놓아, 에이전트가 실패했을 때 그 원인이 무엇인지 짚기 어렵습니다. UniClawBench는 스스로를 "동적인 실제 환경에서 프로액티브 에이전트를 평가하는 최초의 능력 중심 벤치마크"라고 소개합니다.

무엇이 새로운가 — 살아 있는 컨테이너와 단계별 체크포인트

가장 눈에 띄는 설계는 채점 방식입니다. 정적으로 미리 기록해 둔 정답과 문자열을 대조하는 대신, UniClawBench는 에이전트를 살아 있는 Docker 컨테이너 안에서 돌리고 세밀한 단계별 완료 체크포인트 로 채점합니다.

이 차이가 왜 중요한지는 실제 과제를 떠올리면 분명해집니다. "식당을 예약하고 그 일정을 캘린더에 넣어라" 같은 요청에는 중간 상태가 있습니다. 최종 답만 대조하는 방식은 그 문자열 하나만 봅니다. 반면 체크포인트는 "예약이 실제로 잡혔는가", "캘린더에 항목이 생겼는가"를 환경 안에서 단계마다 확인합니다. 사람 비서를 평가하는 방식에 훨씬 가깝습니다 — 결과물뿐 아니라 과정이 실제로 일어났는지를 봅니다.

물론 공짜는 아닙니다. 살아 있는 컨테이너는 정적 JSON 정답 파일보다 돌리는 비용이 크고, 결정적(deterministic)으로 유지하기도 더 까다롭습니다. 다만 이 비용은 에이전트가 실제로 무언가를 해냈는지 를 보기 위해 치르는 값이고, 정적 벤치마크가 놓치는 지점이 바로 거기입니다.

닫힌 고리 — 실행자, 숨은 감독자, 사용자 에이전트

두 번째 핵심 설계는 평가 루프 자체를 세 개의 에이전트로 짠 닫힌 고리(closed-loop) 입니다.

  • 실행자(executor) 에이전트 — 실제로 과제를 수행합니다. 우리가 점수를 매기려는 대상입니다.
  • 숨은 감독자(supervisor) 에이전트 — 단계별 체크포인트로 진행을 채점하되, 채점 기준을 노출하지 않습니다.
  • 사용자(user) 에이전트 — 사람 사용자를 대신해 다중 턴 피드백을 줍니다.
User-Agent   →  다중 턴으로 요청·후속 질문·피드백을 전달
Executor     →  컨테이너 안에서 도구를 조작하며 과제를 수행
Supervisor   →  단계별 체크포인트로 진행을 채점 (기준은 숨긴 채)

"숨은"이 핵심입니다. 채점 기준이 대화에 새어 나오면 실행자는 과제를 해내는 대신 채점 기준에 맞는 말을 하도록 최적화될 수 있습니다. 감독자의 루브릭을 감춰 두면 그 지름길이 막힙니다 — 이는 앞 글에서 다룬 오염·게이밍 문제를 정면으로 겨냥한 설계입니다. 다중 턴 구성도 같은 맥락입니다. 실제 보조 작업은 한 번의 프롬프트가 아니라 대화이고, 사용자 에이전트가 그 후속 요청과 명료화를 공급합니다.

모델과 스캐폴드를 분리한다 — 다섯 가지 능력

UniClawBench는 400개의 이중 언어 과제를 다섯 가지 기초 모델 능력 으로 나눕니다 — 기술 사용(skill usage), 탐색(exploration), 긴 맥락 추론(long-context reasoning), 멀티모달 이해(multimodal understanding), 크로스 플랫폼 조율(cross-platform coordination). 과제마다 겨냥하는 능력이 정해져 있으니, 실패가 안개가 아니라 원인을 가리킵니다 — "탐색에서 무너졌다"와 "긴 맥락을 놓쳤다"를 구분할 수 있습니다. (참고로 어느 두 언어인지는 초록에 명시되어 있지 않습니다.)

가장 developer 관점에서 반가운 부분은 마지막입니다. 저자들은 베이스 모델의 능력과 프레임워크 수준의 설계 선택을 분리 하려고, 최신 모델들을 여러 에이전트 프레임워크 위에서 평가합니다. 이는 앞 글에서 확인한 사실 — 스캐폴드(하네스)만 바꿔도 점수가 몇 %p씩 움직인다 — 에 대한 정공법입니다. 스캐폴드를 고정하거나 의도적으로 바꿔 보지 않으면, 모델 A가 모델 B를 이긴 건지 A의 하네스가 더 좋았던 건지 알 수 없습니다.

한 가지는 분명히 해 둡니다. 초록은 모델과 프레임워크가 "성능을 함께 빚어낸다"는 결론을 제시하지만, 구체적인 순위나 점수를 초록에 담고 있지는 않습니다. 본문에 어떤 표가 있든 그것은 저자 보고값이며, 아직 독립적으로 재현·감사되지 않았습니다. 벤치마크와 코드는 공개한다고 밝히고 있으니, 검증은 커뮤니티의 몫으로 남습니다.

마치며

UniClawBench 한 편으로 2026년 에이전트 벤치마크 설계의 방향이 꽤 또렷하게 읽힙니다 — 정적보다 살아 있는 환경, 최종 답보다 단계별 체크포인트, 새어 나가는 루브릭보다 숨은 감독자, 그리고 모델과 스캐폴드의 분리. 이 네 가지는 점점 기본기가 되어 가고 있습니다.

물론 유보할 지점도 많습니다. 나온 지 며칠 된 논문이고, 수치는 저자 보고값이며, 이중 언어의 정체도 초록엔 없습니다. 살아 있는 컨테이너 방식은 비싸고 재현이 까다로우며, 어떤 벤치마크든 결국은 포화하고 게이밍됩니다 — 앞 글이 남긴 교훈 그대로입니다. 그래도 설계의 방향만큼은 옳습니다.

그러니 쓸모 있는 질문은 "누가 UniClawBench 1위인가"가 아닙니다. "환경이 살아 있고, 턴이 여러 번이고, 채점자가 기준을 알려 주지 않을 때, 내 에이전트가 버티는가"입니다. 리더보드 숫자 하나가 아니라 그 조건이 진짜 신호입니다.

참고 자료

What a Good Agent Benchmark Looks Like in 2026 — UniClawBench, Live Containers, and a Hidden Supervisor

Introduction — Where Static Benchmarks Leave Off

In an earlier post on separating signal from noise in coding evals, I covered how the most widely used coding benchmark got shaky under contamination and scoring flaws. Matching against pre-recorded answers is brittle: it rewards memorization and it drifts with harness differences. Which flips the question — what should a benchmark for a tool-driving agent actually look like?

UniClawBench, posted to arXiv on July 9, 2026 by HKU MMLab, is one concrete answer. Its subtitle is "A Universal Benchmark for Proactive Agents on Real-World Tasks," where a proactive agent is one that operates everyday tools and assists users in real-world environments.

The authors name three limits of existing benchmarks. First, most rely on sandboxed environments. Second, they use single-turn evaluation, which misses the flow of conversational assistance. Third, their scenario-based taxonomies mix several capabilities into one task category, so when an agent fails you cannot say why. UniClawBench bills itself as "the first capability-driven benchmark" for evaluating proactive agents in dynamic, real-world settings.

What Is Actually New — Live Containers and Step Checkpoints

The most striking design is the scoring. Rather than comparing an output string against a static, pre-recorded answer, UniClawBench runs the agent inside a live Docker container and grades it with fine-grained, step-by-step completion checkpoints.

Why that matters becomes clear with a real task. A request like "book a table, then add it to my calendar" has intermediate state. Answer-matching only sees the final string; checkpoints verify, step by step and inside the environment, whether the booking actually happened and whether the calendar entry was created. That is much closer to how you would judge a human assistant — you check that the process occurred, not just the final artifact.

It is not free. Live containers cost more to run than a static JSON of answers, and they are harder to keep deterministic. But that cost buys a look at whether the agent actually did something — which is precisely what static benchmarks miss.

The Closed Loop — Executor, Hidden Supervisor, User Agent

The second core idea is to build the evaluation loop itself from three agents — a closed-loop design.

  • Executor agent — actually performs the task. This is what you are scoring.
  • Hidden supervisor agent — grades progress via the step checkpoints, but does not reveal the grading criteria.
  • User agent — stands in for the human, supplying multi-turn feedback.
User-Agent   ->  sends the request, follow-ups, and feedback across turns
Executor     ->  operates tools inside the container to complete the task
Supervisor   ->  scores progress via step checkpoints (criteria kept hidden)

The word "hidden" is doing the work. If the grading criteria leak into the conversation, the executor can optimize for saying the right things instead of doing the task. Keeping the supervisor's rubric out of sight closes that shortcut — a design aimed squarely at the contamination and gaming problems from the previous post. The multi-turn setup follows the same logic: real assistance is a conversation, not a one-shot prompt, and the user agent supplies the follow-ups and clarifications.

Separating Model from Scaffold — The Five Capabilities

UniClawBench splits its 400 bilingual tasks across five foundational model capabilities: skill usage, exploration, long-context reasoning, multimodal understanding, and cross-platform coordination. Because each task targets a capability, a failure points at a cause instead of a fog — you can tell "it broke during exploration" apart from "it lost the long context." (The abstract does not name which two languages the tasks span.)

The most welcome part from a developer's seat is the last one. To disentangle base-model ability from framework-level design choices, the authors evaluate state-of-the-art models under multiple agent frameworks. That is the direct answer to a finding from the earlier post: swapping only the scaffold (the harness) can move scores by several points. Unless you hold the scaffold fixed, or vary it on purpose, you cannot tell whether model A beat model B or whether A simply had a better harness.

One caveat, stated plainly. The abstract concludes that model and framework "jointly shape performance," but it does not report specific rankings or scores. Whatever tables the paper contains are author-reported and not yet independently reproduced or audited. The benchmark and code are said to be public, so verification is left to the community.

Closing

From this one paper, the direction of agent-benchmark design in 2026 reads clearly — live over static, step checkpoints over final-answer matching, a hidden supervisor over a leaked rubric, and separating the model from the scaffold. These four are becoming table stakes.

There is plenty to hold in reserve. The paper is days old, the numbers are author-reported, and the identity of the two languages is not in the abstract. Live-container evaluation is expensive and hard to reproduce, and every benchmark eventually saturates and gets gamed — exactly the lesson the earlier post left behind. Even so, the design direction is right.

So the useful question is not "who tops UniClawBench." It is "does your agent hold up when the environment is live, the turns are many, and the grader will not tell you the rubric." That condition, not a single leaderboard number, is the real signal.

References