에이전트 하네스(harness)는 대규모 언어모델을 실제 작업에 연결하는 뼈대다. 도구 호출 규약, 서브에이전트, 프롬프트, 메모리 같은 요소가 여기에 속한다. 프라임 인텔렉트(Prime Intellect)가 공개한 오픈소스 코딩 하네스 '프라임 에이전트(Prime Agent)'는 이 뼈대를 다시 설계하겠다는 문제의식에서 출발한다. 회사 측 주장에 따르면 오늘날 널리 쓰이는 하네스는 이전 세대 모델의 능력에 맞춰 만들어졌고, 고정된 도구 호출 스키마나 컨텍스트 압축 방식 탓에 모델이 자기 발판을 활용하기보다 오히려 그것을 우회하며 일하게 된다는 것이다. 손으로 짜 넣은 서브에이전트·프롬프트·스킬·메모리는 설계 시점에 한 번 정해진 뒤 실행 중 학습한 내용을 반영하지 못한다는 지적도 함께 제시된다.
REPL을 유일한 도구로 삼는 구조
프라임 에이전트의 가장 큰 특징은 모델이 지속되는 IPython 커널을 사실상 유일한 도구로 사용한다는 점이다. 서브에이전트 호출을 포함한 다른 하네스 기능들이 별도의 도구 스키마가 아니라 커널 안의 함수로 노출된다. 초기화 시 각 스킬과 도구가 모듈로 미리 임포트되고, 재귀적 서브에이전트 호출을 담당하는 rlm도 이때 함께 준비된다. rlm은 비동기 함수이기 때문에 모델이 코드 안에서 자유롭게 서브에이전트를 병렬로 띄울 수 있다. await rlm("하위 작업")을 실행하면 자체 모델과 커널, 세션 트리, 대화 이력을 가진 완전한 세션이 생성되며, 호출은 즉시 반환되고 이후 소통은 agent_message.send 방식으로 이뤄진다.
이 구조를 떠받치는 것이 백그라운드 데몬이다. 데몬은 로컬 소켓을 통해 모든 라이브 세션을 소유하며, 사용자는 에이전트 루프에 영향을 주지 않고 세션에 붙거나 떨어질 수 있다. 워커 프로세스가 죽어도 세션 JSONL과 커널 상태 스냅샷으로 복구된다. 세션 이력은 추가 전용 JSONL 파일로 디스크에 남고, 분기·포크·클론은 같은 파일에서 리프 포인터를 옮기는 방식으로 처리된다. 서브에이전트 역시 루트 에이전트와 같은 실행-대기-비활성 상태 기계를 공유해, 30분간 활동이 없으면 메모리에서 내려갔다가 누군가 말을 걸면 디스크에서 다시 로드된다. 중첩이 깊은 대화에서 메모리를 아끼기 위한 설계다.
실행 중에 자기 하네스를 고친다
두 번째 축인 '컨티뉴얼 하네스(Continual Harness)'는 하네스 상태를 프롬프트·서브에이전트·스킬·메모리 네 요소로 형식화한다. 이 상태는 커널 안의 rlm.harness에 살아 있어 작업 도중 곧바로 읽고 호출할 수 있으며, 변경분은 디스크에도 기록돼 턴과 세션을 넘어 유지된다. 네 요소는 모두 동일한 생성·조회·수정·삭제(CRUD) 인터페이스를 갖는다. 스킬을 만드는 일도 SKILL.md 형식의 참조를 담은 create_skill 호출이어서, 메모리나 프롬프트 노트를 추가하는 것과 같은 조작으로 취급된다.
자기 개선은 /refine 파이프라인이 담당한다. 에이전트 자신의 트래젝터리, 즉 무엇을 시도했고 어떤 결과가 나왔는지를 읽어, 하네스 전체를 다시 쓰는 대신 가장 작은 관련 CRUD 편집만 적용한다. 각 개선은 그 계기와 결과를 함께 기록하므로 근거 기반으로 남는다. 편집을 제안하는 계획 단계는 백그라운드에서 돌아 대화를 막지 않고, 디스크에 쓰고 시스템 프롬프트를 재구성하는 적용 단계만 다음 턴 경계에서 잠깐 블로킹된다. 기본 시스템 프롬프트 자체는 불변으로 두고 그 주변 하네스 층만 손대며, 잘못된 갱신은 ID로 되돌릴 수 있다.
벤치마크 수치와 실무적 해석
성능 근거로는 ARC-AGI 3가 제시된다. Opus 5를 프라임 에이전트의 자율 모드로 돌렸을 때 RHAE Best@1 기준 95.5%를 기록했는데, 이는 보고된 인간 전문가 기준선 95.4%를 근소하게 넘어선 수치다. 세 번의 실행에서 95.0, 95.2, 95.5로 일관된 결과가 나왔고 Best@3은 183개 레벨을 모두 통과해 99.97%였다고 회사는 밝혔다. 주목할 점은 각 모델의 네이티브 하네스보다 최고 점수가 높으면서도 전체 토큰 사용량은 더 적었다는 주장이다. 도구로 데이터를 읽어 토큰을 쓰는 대신 데이터 위에서 함수를 프로그래밍적으로 실행하기 때문이라는 설명이다. 다만 자율 실행을 위한 골(goal)·하트비트·자율 모드 조합에는 토큰 예산과 턴 제한이 함께 붙는다.
실무자 입장에서 이 발표는 두 가지 유보를 함께 읽어야 한다. 첫째, 하네스 성능은 설계뿐 아니라 그 하네스에 맞춰 훈련된 모델 능력에 함께 묶여 있는데, 회사 스스로 현재 어떤 모델도 프라임 에이전트나 그 핵심 기능에 맞춰 훈련되지 않았다고 명시한다. 즉 지금 수치는 하네스에 최적화되지 않은 모델로 얻은 결과다. 둘째, 비교의 공정성 문제도 있다. Opus 5와 GPT-5.6 Sol을 각각 클로드 코드와 코덱스로 직접 돌린 실험에서는 공식 보고치보다 낮게 나와 공식 수치를 대신 인용했다고 밝힌 대목은, 하네스 간 비교 실험의 재현 조건이 결과에 크게 좌우된다는 점을 시사한다. 프로그래밍적 도구 호출, 지속 커널, 실행 중 자기 편집이라는 방향성 자체는 검토할 가치가 있지만, 인간 기준선을 넘었다는 한 줄보다 이런 조건들을 함께 저울질하는 편이 안전하다.