OpenClaw와 Hermes Agent 비교
OpenClaw는 채널·Gateway·세션·플러그인을 묶는 운영 플랫폼으로, Hermes Agent는 장기 목표·증거 검증·학습을 밀어붙이는 자율 에이전트 하네스로 더 성숙했다.
OpenClaw와 Hermes Agent 비교
한 줄 요약
여러 채널과 디바이스에서 안정적으로 에이전트를 운영하려면 OpenClaw가 낫고, 장기 목표를 끝까지 수행하며 완료 증거까지 요구하려면 Hermes Agent가 더 알맞다.
먼저 읽을 결론
두 프로젝트는 같은 문제를 푸는 듯 보이지만 중심축이 다르다. OpenClaw는 에이전트가 올라가는 운영 플랫폼에 가깝다. Hermes는 에이전트가 스스로 목표를 유지하고 검증하며 학습하도록 만든 실행 루프에 가깝다.
| 평가 축 | 우세 | 판단 |
|---|---|---|
| 멀티채널·Gateway·앱·디바이스 운영 | OpenClaw | 세션, 채널, 전달 복구, 외부 하네스 연결이 제품의 중심이다 |
| 범용 장기 워크플로 | Hermes | 최근 Harness-Bench와 WildClawBench에서 완료율과 일관성이 높다 |
| 격리된 SWE 코딩 | OpenClaw | 두 비교 모델에서 성공률이 높고 입력 토큰과 비용은 낮았다 |
| 종료 전 증거 검증 | Hermes | evidence ledger, verify-on-stop, completion contract가 기본 루프에 들어 있다 |
| 빈 응답·부작용 재시도 방어 | OpenClaw | 실행 상태와 이미 발생한 side effect를 구분해 복구한다 |
| 장기 세션의 의미 안전성 | Hermes 근소 우세 | stale task 재개 방지, 세션 잠금, soft archive가 강점이다 |
| 컴팩션 엔진 교체와 플랫폼 통합 | OpenClaw | ContextEngine과 compaction provider 계약이 더 명확하다 |
| 학습·MoA·지속 목표 | Hermes | self-improving agent라는 프로젝트 방향과 직접 연결된다 |
| 보수적인 production 운용 | OpenClaw stable | stable과 beta가 분리돼 있다 |
짧게 말하면 OpenClaw는 AI 운영 플랫폼과 런타임으로 더 완성돼 있고, Hermes는 스스로 끝까지 수행하고 검증하는 인지 하네스로 더 완성돼 있다.
다만 직접 비교 벤치마크 세 편은 2026년 5~6월에 공개됐다. OpenClaw 2026.7.1-beta.2와 Hermes 0.18.2의 현재 성능을 직접 재측정한 결과가 아니다. 숫자는 최신 절대 순위보다 두 하네스의 성향을 보여주는 자료로 읽는 편이 안전하다.
왜 저장했나
에이전트 성능은 모델만으로 결정되지 않는다. 시스템 프롬프트, 도구 스키마, 상태 관리, 실행 루프, 재시도, 종료 판정, 세션 저장, 컴팩션을 묶은 하네스가 같은 모델의 결과를 크게 바꾼다.
OpenClaw와 Hermes는 이 실행 계층을 서로 다른 방향으로 발전시키는 대표 사례다. 하나는 운영과 확장에, 다른 하나는 목표 유지와 검증에 무게를 둔다. 제품 도입이나 자체 하네스 설계에서 무엇을 우선해야 하는지 판단하기 좋은 비교다.
정리한 질문
최근 릴리즈, 공개 벤치마크, 토큰 사용, 컴팩션, 실행 복구, 완료 검증, 프로젝트 방향을 함께 보면 OpenClaw와 Hermes Agent는 각각 어떤 작업에 더 적합한가?
비교 기준과 범위
이 노트에서 OpenClaw는 openclaw/openclaw, Hermes는 NousResearch/hermes-agent를 뜻한다. 첨부된 연구 결과는 2026-07-10의 기본 브랜치 코드와 공개 릴리즈·논문을 분석했다. 2026-07-11에 공식 릴리즈 페이지, OpenClaw VISION, Hermes README, 세 벤치마크 논문의 핵심 수치를 다시 확인했다.
하네스는 모델 호출 래퍼만 가리키지 않는다. 프롬프트, 도구, 권한, 상태, 재시도, 검증, 세션, 컴팩션을 포함한 전체 실행 계층을 뜻한다.
최근 릴리즈
| 프로젝트 | 채널·버전 | 날짜 | 성격 |
|---|---|---|---|
| OpenClaw | stable 2026.6.11 | 2026-06-30 | 메시지 전달, reconnect, stuck send, 설정 실패를 다듬은 안정화 릴리즈 |
| OpenClaw | beta 2026.7.1-beta.2 | 2026-07-05 | GPT-5.6, 외부 하네스 attach, Codex 세션 연동, 채널·UI·비용·자동화 확장 |
| Hermes | 0.18.0 / v2026.7.1 | 2026-07-01 | Judgment Release. MoA, 증거 검증, completion contract, 학습·회고, background subagent 추가 |
| Hermes | 0.18.2 / v2026.7.7.2 | 2026-07-07 | WhatsApp Baileys 의존성과 Docker 빌드를 고친 후속 패치 |
OpenClaw beta의 중요한 변화는 모델 추가보다 플랫폼과 하네스의 분리다. openclaw attach로 외부 하네스가 기존 Gateway 세션에 붙을 수 있고, Telegram에서 Codex pairing·steering·복구를 지원한다. on-exit cron, 대화별 capability profile, session-first UI, context meter, reasoning slider, quota·budget reporting도 들어갔다.
Hermes 0.18.0은 판단과 완료 검증을 크게 확장했다. Mixture-of-Agents를 일반 모델처럼 선택할 수 있고, 코드 변경 후 verification evidence를 기록하며, /goal에 completion contract를 연결한다. /learn과 /journey는 학습·회고를 제품 기능으로 끌어올렸다.
변경 규모도 크다. 공식 릴리즈 노트는 0.18.0에 약 1,720개 커밋, 998개 병합 PR, 2,215개 파일 변경이 포함됐다고 적는다. 6일 뒤 나온 0.18.1도 약 660개 병합 PR과 667개 커밋, 약 990개 파일 변경을 묶었다. 개발 속도와 기능 흡수력은 높지만 자동 업데이트에는 부담스러운 규모다.
릴리즈 운영의 차이는 분명하다. OpenClaw는 안정 채널을 지키면서 Gateway와 외부 하네스를 넓힌다. Hermes는 판단·검증·학습·다중 에이전트 기능을 빠르게 하나의 하네스에 흡수한다.
아키텍처의 중심
OpenClaw
OpenClaw의 공식 VISION은 사용자의 디바이스와 채널에서 사용자의 규칙에 따라 실제 일을 하는 개인 AI를 목표로 한다. 현재 우선순위는 보안과 안전한 기본값, 버그와 안정성, 설치 경험이다. 그다음에 모델 제공자, 메시징 채널, 성능·테스트, computer use와 agent harness, 각 OS의 companion app이 놓인다.
core는 가볍게 유지하고 plugin API를 넓히려 한다. manager-of-managers나 중첩 planner tree, 무거운 orchestration layer를 기본 아키텍처로 삼지 않겠다는 guardrail도 명시했다. 다중 에이전트를 지원하더라도 플랫폼 전체를 계층형 자율 조직으로 만들지는 않겠다는 뜻이다.
Hermes
Hermes README는 프로젝트를 self-improving agent로 규정한다. 경험에서 skill을 만들고, 사용 중 개선하고, 기억을 저장하며, 과거 대화를 검색하고, 사용자 모델을 누적하는 학습 루프가 중심이다. 여기에 여러 채널, subagent, RPC 도구 실행, terminal backend, trajectory 생성이 붙는다.
구조를 한 줄씩 줄이면 이렇다.
- OpenClaw: 모델·하네스·ContextEngine·채널·Gateway를 잇는 host/runtime
- Hermes: 기억·검증·목표·학습·위임을 계속 수행하는 opinionated agent loop
최근 직접 비교 벤치마크
Harness-Bench
Harness-Bench는 106개 sandboxed offline task, 8개 워크플로 범주, 6개 하네스와 8개 API 모델 백엔드를 사용했다. Codex를 포함해 5,194개 trajectory를 분석했다.
| 하네스 | 종합 | 완료율 | Tool | 일관성 | 복원력 | Security | 평균 토큰 | 평균 턴 |
|---|---|---|---|---|---|---|---|---|
| OpenClaw | 52.4 | 60.0 | 79.5 | 74.0 | 70.9 | 100 | 82.1K | 5.0 |
| Hermes | 71.2 | 80.4 | 88.5 | 88.4 | 85.5 | 100 | 139.7K | 22.6 |
Hermes는 종합 +18.8%p, 완료율 +20.4%p, Tool +9.0%p, 일관성 +14.4%p, 복원력 +14.6%p 앞섰다. OpenClaw는 평균 토큰을 약 41.2%, 턴 수를 약 77.9% 적게 썼다.
이 토큰 차이를 순수 효율 차이로 단정하면 안 된다. OpenClaw는 더 일찍 멈췄고 완료율도 낮았다. 일부 절감은 탐색과 검증을 덜 하고 종료한 결과일 수 있다. 두 시스템의 Security 100도 해당 sandbox와 permission 조건 안에서만 유효하다.
WildClawBench
WildClawBench는 장기·이중언어·멀티모달 과제를 다룬다.
| 모델 | 하네스 | 시간(분) | 비용 | 점수 |
|---|---|---|---|---|
| GPT-5.4 | OpenClaw | 5.83 | $0.33 | 50.3 |
| Hermes | 8.97 | $0.44 | 50.7 | |
| GLM-5 | OpenClaw | 6.22 | $0.19 | 42.6 |
| Hermes | 6.62 | $0.44 | 46.4 | |
| MiMo-V2-Pro | OpenClaw | 7.63 | $0.44 | 40.2 |
| Hermes | 8.30 | $0.26 | 48.1 | |
| MiniMax-M2.7 | OpenClaw | 9.18 | $0.12 | 33.8 |
| Hermes | 10.30 | $0.11 | 37.1 |
Hermes는 네 모델 모두 점수가 높았고 실행 시간은 모두 길었다. GPT-5.4에서는 0.4점 차이에 그쳤지만 MiMo-V2-Pro에서는 7.9점 차이가 났다. 강한 모델은 OpenClaw의 얇은 scaffold로도 충분할 수 있고, 장기 진행과 자기검증이 약한 모델은 Hermes의 두꺼운 scaffold에서 더 큰 도움을 받을 수 있다.
Claw-SWE-Bench
Claw-SWE-Bench는 43개 저장소, 8개 언어, 350개 실제 GitHub 이슈 해결 과제를 사용한다.
| 하네스 | GLM-5.1 해결률 | 비용 | 입력/출력 토큰 | 평균 시간 | Cache |
|---|---|---|---|---|---|
| OpenClaw | 257/350, 73.4% | $277.0 | 27.6M / 9.3M | 586.8초 | 96.5% |
| Hermes | 249/350, 71.1% | $330.6 | 93.1M / 5.5M | 675.1초 | 91.3% |
| 하네스 | Qwen3.6-Flash 해결률 | 비용 | 입력/출력 토큰 | 평균 시간 | Cache |
|---|---|---|---|---|---|
| OpenClaw | 231/350, 66.0% | $71.5 | 38.9M / 7.5M | 636.0초 | 97.6% |
| Hermes | 219/350, 62.6% | $103.3 | 44.3M / 7.2M | 638.6초 | 97.4% |
OpenClaw는 GLM-5.1에서 입력 토큰을 70.4%, 전체 입력+출력을 62.6%, 비용을 16.2% 줄이면서 성공률은 2.3%p 높였다. Qwen3.6-Flash에서는 입력 12.2%, 전체 토큰 9.9%, 비용 30.8%를 줄였고 성공률은 3.4%p 높았다.
이 결과는 두 제품 전체를 비교한 것이 아니다. Hermes는 --yolo, --max-turns와 terminal/file toolset 중심의 stateless 코딩 실행으로 들어갔다. OpenClaw도 memory, web, session, subagent, cron, image를 끈 격리형 구성이었다. Hermes의 goal judge, learning, memory, MoA, background subagent는 사실상 평가되지 않았다.
논문 자체도 adapter 설계가 결과에 큰 영향을 준다고 보여준다. 같은 GLM-5.1에서 OpenClaw의 bare adapter는 19.1%였고 full adapter는 73.4%였다. 하네스 비교에서 adapter와 patch extraction 방식을 빼고 숫자만 읽으면 안 되는 이유다.
벤치마크를 함께 읽는 법
범용 장기 과제는 미완료 상태를 인식하고, 증거를 확인하고, 여러 턴에 걸쳐 목표를 유지하고, 오류 뒤에 재계획하는 능력을 보상한다. Hermes가 강화한 축과 맞는다.
격리된 코드 수정은 context replay를 줄이고, 파일 탐색과 patch 적용 경로를 짧게 유지하고, 테스트 뒤 적절한 시점에 멈추는 능력이 중요하다. 이 조건에서는 OpenClaw의 얇은 실행 경로가 유리했다.
따라서 “어느 하네스가 더 좋은가”보다 “내가 쓸 모델과 작업은 얼마나 두꺼운 scaffold와 검증을 필요로 하는가”가 더 정확한 질문이다.
토큰 관리
OpenClaw
OpenClaw는 매 실행 때 도구 목록, skill metadata, workspace bootstrap, runtime·채널 정보를 조합해 시스템 프롬프트를 만든다. skill 본문은 필요할 때만 읽는다.
- bootstrap 파일은 개별 20,000자, 총합 60,000자로 제한
- 실시간 tool result는 context에 따라 기본 16K·32K·64K자 제한
- 명시적으로 늘려도 context window의 30%를 넘지 못함
- 이미지는 기본 최대 1,200px로 축소
- billing 누적 usage와 현재 context snapshot을 분리
- cache read/write와 가격표를 이용해 비용 표시
- 작은 로컬 모델용
localModelLean은 experimental
실제 벤치마크에서 입력 토큰과 비용이 대체로 낮았고, provider별 usage·cache 관측도 풍부하다.
Hermes
Hermes는 과거 tool result를 먼저 줄인 뒤 대화 head와 최근 tail을 보호하고, 중간 구간을 구조화된 summary로 바꾼다. 반복 컴팩션에서는 기존 summary를 갱신한다.
토큰 계산에 content 길이뿐 아니라 tool-call envelope, call id, function name, JSON, reasoning field, Codex replay item, 이미지당 1,600 token 상당, role·key overhead를 넣는다. 코드 주석에는 214-turn 세션에서 codex_reasoning_items가 약 115K token, 전체 payload의 27%를 차지한 사례가 있다. arguments만 세면 병렬 tool call을 2~15배 적게 잡을 수 있었다는 설명도 남아 있다.
provider가 보고한 실제 prompt_tokens도 저장한다. 이전 실제 요청이 threshold 아래에서 성공했다면 rough estimator가 높아도 max(4096, threshold의 5%) 범위에서는 연속 컴팩션을 미룬다.
Hermes는 숨은 wire payload까지 꼼꼼히 세지만 실제 토큰을 적게 쓰지는 않는다. 검증, goal judge, 긴 tail, continuation이 호출 수와 replay context를 늘린다.
| 토큰 관점 | 우세 |
|---|---|
| 실제 비용·사용량 효율 | OpenClaw |
| hidden replay와 tool envelope accounting | Hermes |
| 사용량·비용 관측 UI | OpenClaw |
| 장기 목표를 위한 추가 토큰 투자 | Hermes |
컴팩션
OpenClaw의 방식
OpenClaw는 sessions.json과 append-only tree JSONL transcript를 쓴다. compaction entry를 transcript에 저장하고 이후에는 summary와 firstKeptEntryId 뒤의 최근 메시지를 넣는다.
assistant tool call과 tool result 사이를 자르지 않는다. 기본 planner는 chunk ratio 0.40, 최소 0.15, safety factor 1.2, overhead 4,096 token을 사용한다. 자동 컴팩션은 provider overflow 뒤의 retry, 또는 성공한 turn 뒤 contextTokens > contextWindow - reserveTokens 조건에서 실행된다.
주요 기본값은 reserveTokens 16,384, keepRecentTokens 20,000, embedded run의 reserveTokensFloor 20,000이다. mid-turn precheck는 있지만 기본값은 false다. compaction provider가 실패하거나 빈 응답을 내면 built-in summarizer로 돌아가며, safeguard mode는 malformed summary를 다시 검사한다. 자동 컴팩션 약 4,000 token 전에는 durable memory flush도 실행할 수 있다.
Hermes의 방식
Hermes summary는 과거 대화의 참고자료일 뿐 현재 지시가 아니라고 명시한다. 최신 사용자 메시지만 현재 작업이며, summary의 pending task를 자동 재개하지 말라고 적는다. stop, undo, never mind, 새 주제가 오면 과거 작업을 끝낸다. summary가 오래된 지시를 되살리는 문제를 직접 막는다.
기본 configured threshold는 50%다. 처음 3개 메시지와 최근 20개 메시지를 보호하고, summary target ratio는 20%, summary 범위는 2,000~10,000 token이다. 512K 미만 모델은 threshold를 최소 75%로 올리며 조건이 충돌하면 effective input window의 85%에서 시작한다.
LLM 요약 전에는 tool result 중복 제거, 오래된 tool output 축약, screenshot 제거, 큰 argument 축약, reasoning block 제거, secret redaction을 한다. 두 번 연속 10% 미만만 줄면 추가 컴팩션을 멈춘다.
SQLite state.db 기반 세션 잠금과 TTL lease로 동시 컴팩션 race를 막는다. 새로운 in-place 모드는 session id를 유지하고 과거 메시지를 active=0으로 soft archive하며 검색과 복구를 남긴다. 다만 compression.in_place는 아직 rollout 중이고 기본값은 false다.
| 세부 축 | 우세 |
|---|---|
| chunk planning과 tool pairing | OpenClaw |
| stale task·instruction 오염 방지 | Hermes |
| hidden replay token accounting | Hermes |
| provider·ContextEngine 확장 계약 | OpenClaw |
| 실패 후 session consistency | Hermes 근소 우세 |
| 컴팩션 전 durable memory | OpenClaw |
| 동시 컴팩션 잠금과 atomic archive | Hermes |
| 작은 context 모델 유연성 | OpenClaw |
| 기본 경로의 단순성 | OpenClaw |
| 장기 세션 의미 안전성 | Hermes |
컴팩션 품질을 직접 비교한 공개 벤치마크는 아직 없다. 이 판정은 코드 구조를 읽은 결과이지 실증 점수가 아니다.
하네스 완성도
OpenClaw는 실행을 살리는 데 강하다
OpenClaw embedded runner는 final answer 없는 turn, token length로 끊긴 turn, reasoning만 있는 turn, 빈 응답, tool side effect가 있는 turn을 따로 판정한다. reasoning-only retry는 기본 2회, empty response retry는 1회다.
재시도 전에 tool replay safety, async activity, 메시지 전송, cron write, session spawn을 확인한다. 이미 결제, 메시지, 파일 변경 같은 부작용이 생겼을 수 있으면 무작정 반복하지 않는다. before_agent_finalize hook과 run별 retry budget도 있다.
한계도 있다. built-in strict-agentic contract는 현재 OpenAI GPT-5 계열에서만 자동 활성화되고, 구조화된 update_plan 도구는 experimental이다. runtime guard는 성숙했지만 모든 모델에 공통으로 적용되는 강한 완료 검증은 아직 plugin이나 특정 contract에 가깝다.
Hermes는 완료를 증명하게 한다
Hermes verify-on-stop은 코드 변경 뒤 새 verification evidence가 없는데 모델이 종료하려 하면 synthetic follow-up을 넣는다. CLI, TUI, Desktop, API 같은 coding surface에서는 기본 활성화되고 메시징 surface에서는 기본 비활성화된다.
변경된 code path와 canonical test·lint·build command를 찾아 증거를 확인한다. 증거가 없으면 명령을 실행하거나 검증할 수 없는 blocker를 구체적으로 설명해야 한다. 연속 nudge는 기본 최대 3회다.
/goal은 한 turn의 지시가 아니라 DB에 남는 지속 상태다. lightweight judge가 매 turn을 평가하고, 미완료면 같은 session에 continuation을 넣는다. completion contract는 outcome, verification, constraints, boundaries, stop_when을 가진다. judge는 명령 결과, 파일 excerpt, 테스트 output 같은 증거가 있어야 done을 허용한다.
background process를 기다려야 하면 wait로 park할 수 있다. judge 오류는 done이 아니라 continue로 처리하고, 기본 20-turn budget이 마지막 안전장치가 된다.
| 영역 | 우세 |
|---|---|
| 빈 응답·불완전 turn 복구 | OpenClaw |
| side-effect-aware retry | OpenClaw |
| 종료 전 evidence 검증 | Hermes |
| 장기 목표 유지 | Hermes |
| 완료 기준 구조화 | Hermes |
| context engine 교체 | OpenClaw |
| MoA·적극적 위임 | Hermes |
| 전체 Gateway 운영 | OpenClaw |
| 학습·skill 개선 | Hermes |
앞으로의 방향
OpenClaw가 밝힌 우선순위는 안전한 기본값, 안정성, 설치 경험, 주요 모델과 채널, 성능·테스트, computer use와 agent harness, companion app, lean core와 plugin 생태계 순이다. 최근 beta와 합치면 Gateway를 AI session operating system처럼 강화하고, Codex 같은 외부 하네스를 session·channel plane에 붙이며, ContextEngine과 compaction provider를 외부화하는 방향으로 읽힌다.
Hermes는 단일 roadmap보다 README, Judgment Release, 현재 코드가 방향을 보여준다. evidence ledger와 goal judge, /learn과 /journey, MoA와 background subagent, 장기 기억, trajectory, scale-to-zero를 한 실행 루프에 묶고 있다.
원문이 코드와 릴리즈 흐름에서 추론한 단기 과제는 in-place compaction의 기본 전환, goal judge와 verification evidence 연결 강화, MoA·subagent 비용 통제, auxiliary model routing 안정화, 학습 skill의 품질 평가, memory·summary·active goal의 authority 충돌 해결이다. 공식 roadmap에 명시된 약속은 아니다.
선택 기준
| 사용 시나리오 | 권장 | 이유 |
|---|---|---|
| 여러 메시징 채널과 앱을 묶은 상시 개인 비서 | OpenClaw stable | Gateway, routing, delivery recovery가 핵심이다 |
| 여러 디바이스에서 같은 세션을 이어서 사용 | OpenClaw | session과 channel plane이 제품의 중심이다 |
| GitHub 이슈를 비용 효율적으로 해결 | OpenClaw | 최근 SWE 자료에서 성공률·비용·입력 토큰이 모두 앞섰다 |
| 장기 조사·운영·리팩터링을 끝까지 수행 | Hermes | goal loop와 completion contract가 맞는다 |
| 테스트 증거 없이 완료하는 문제를 방지 | Hermes | verify-on-stop과 evidence ledger가 기본 기능이다 |
| 경험에서 skill을 만들고 개선 | Hermes | self-improvement가 프로젝트 정체성이다 |
| MoA와 background subagent 활용 | Hermes | 현재 제품 방향과 직접 맞는다 |
| 자체 ContextEngine·compaction provider 개발 | OpenClaw | plugin lifecycle과 failure isolation이 명확하다 |
| 16K~32K 작은 로컬 모델 | OpenClaw 쪽이 유리 | reserve 상한과 localModelLean이 있고 Hermes auxiliary compaction은 64K를 전제한다 |
| 업데이트 회귀를 줄인 production | OpenClaw stable | stable과 beta가 분리돼 있다 |
| 빠른 기능 흡수와 실험 | Hermes | 릴리즈 속도와 기능 밀도가 높다 |
프로덕션 도입 권고
OpenClaw 운영 환경은 2026.6.11 stable을 기준으로 삼는 편이 안전하다. GPT-5.6, openclaw attach, 최신 Codex 연동이 꼭 필요할 때만 2026.7.1-beta.2를 canary에서 검증한다.
Hermes는 0.18.2를 정확히 pin하고 자동 업데이트를 피하는 편이 낫다. 0.18.0과 0.18.1의 변경량, 뒤이은 dependency patch를 고려하면 Gateway, WhatsApp, provider, compaction, resume, goal loop를 자체 환경에서 다시 확인해야 한다.
실제 선택 전에는 두 profile을 따로 비교한다.
| Profile | 목적 |
|---|---|
| Minimal coding | memory·subagent·web을 끄고 terminal/file만 비교 |
| Full autonomous | memory·goal·verification·subagent·browser를 실제 운영 설정으로 비교 |
모델, provider endpoint, reasoning level, context window, max output, tool schema, network, workspace, timeout, 승인 정책을 고정한다. 측정값은 verified success, model call 수, input/output/cache token, 비용, wall time, compaction 횟수, compaction 후 사실 손실, restart/resume 성공률, 중복 side effect, 최종 artifact validity까지 포함해야 한다.
한계와 주의점
- 세 직접 비교 논문은 모두 최신 7월 릴리즈보다 앞선 preprint다.
- 모든 실행의 정확한 repository tag와 dependency lock을 공개 자료만으로 완전히 재구성하기 어렵다.
- Harness-Bench와 WildClawBench는 범용성을, Claw-SWE-Bench는 격리된 코딩 루프를 측정한다. 점수를 합쳐 하나의 순위를 만들면 안 된다.
- 컴팩션 후 사실 보존율, 사용자 의도 보존율, stale-task 재개율을 직접 비교한 공개 실험은 확인되지 않았다.
- 이번 공개 노트는 첨부된 코드 분석을 압축하고 주요 공개 근거를 재확인한 결과다. 두 최신 태그를 같은 환경에서 직접 실행한 비교는 아니다.
검증이 필요한 주장
- 원문의 “같은 모델에서 하네스 선택만으로 최대 27.4%p 차이”는 이번에 확인한 Harness-Bench 공개 HTML에서 같은 수치를 찾지 못했다. 공개 표에서 확인되는 하네스 종합 최대 격차는 23.8%p이며, 27.4%p의 정확한 산출 위치는 별도 확인이 필요하다.
- OpenClaw와 Hermes의 컴팩션 기본값과 experimental flag는 빠르게 바뀔 수 있으므로 도입할 tag에서 다시 확인해야 한다.
strict-agentic contract의 모델 제한,compression.in_place기본값,localModelLean상태는 최신 코드와 설정 마이그레이션을 직접 재검증해야 한다.- Hermes의 검증 기능이 실제 업무에서 추가 토큰을 상쇄할 만큼 실패율을 줄이는지는 자체 workload A/B 테스트가 필요하다.
Source Fidelity Notes
- 핵심 벤치마크 수치를 보존했다: Harness-Bench의 종합·완료·Tool·일관성·복원력·토큰·턴, WildClawBench의 네 모델별 시간·비용·점수, Claw-SWE-Bench의 성공률·비용·시간·입출력 토큰·cache를 남겼다.
- 주요 구현 기준을 보존했다: OpenClaw bootstrap·tool result 제한, compaction planner·reserve 기본값, Hermes token accounting·threshold·summary budget·session lock·in-place archive를 유지했다.
- 하네스 프레임을 보존했다: OpenClaw의 side-effect-aware recovery와 Hermes의 evidence verification·completion contract·persistent goal을 별도 비교했다.
- 선택표, production pin 권고, Minimal coding과 Full autonomous 비교 profile을 남겼다.
- 원문의 세부 코드 설명과 반복되는 결론은 압축했다. 숫자와 공식 문서에서 확인한 방향성은 유지했다.
- 27.4%p 주장은 공개 근거에서 같은 값을 찾지 못해 검증 항목으로 옮겼다. 그 밖의 세 논문 핵심 표와 최신 릴리즈 태그는 2026-07-11에 다시 확인했다.