Google Harness2, 에이전트 자기 개선을 오픈소스로 공개했지만 검증은 여전히 과제

Google은 에이전트의 모델 자체가 아니라 이를 둘러싼 소프트웨어를 변경해 최대 11.5점의 성능 향상을 달성했다고 밝힌 뒤 Google Harness2를 오픈소스로 공개했다. 이 구분이 핵심적인 긴장을 만든다. 이 프레임워크는 에이전트가 프롬프트, 도구, 메모리 및 기타 운영 지침을 수정하도록 하지만, 정답을 알 수 없는 상황에서 그 수정안을 판단해야 한다.

저자들이 Harness²라고 부르는 이 프로젝트는 Google Cloud AI Research 및 Northwestern University와 연계된 연구진이 개발했다. 코드는 2026년 10월 9일 연구 논문과 함께 공개됐으며 Apache 2.0 라이선스를 사용한다. 이번 공개로 연구 방법론은 개발자가 검사하고 실행하며 수정할 수 있는 소프트웨어가 됐다.

이 프로젝트는 AI 에이전트에 대한 익숙한 가정에도 도전한다. 더 나은 결과가 항상 더 새롭거나 더 큰 모델을 필요로 하는 것은 아니다. 언어 모델을 행동하는 시스템으로 만드는 소프트웨어와 지침, 즉 하니스를 바꾸는 데서도 성과가 나올 수 있다.

이 주장은 고정된 에이전트 프레임워크에 압박을 가한다. OpenCode, Codex, Claude Code 및 유사 시스템은 모델을 프롬프트, 도구, 메모리, 오케스트레이션과 결합한다. Google Harness2는 이러한 주변 구성 요소가 배포 후에도 고정된 상태로 남아야 하는지 묻는다.

그 답은 벤치마크 순위를 넘어 중요하다. 자기 편집형 하니스는 낯선 법률, 사무, 웹 및 코딩 업무에 적응할 수 있다. 반면 잘못된 가정을 보존하거나 더 약한 수정안을 선택하거나, 답에 도달하는 데 훨씬 많은 컴퓨팅 자원을 쓸 수도 있다.

Google Harness2는 고정된 모델 주변의 소프트웨어를 바꾼다

이번 공개는 재귀적 개선을 모델 학습에서 에이전트 런타임의 수정 가능한 여덟 가지 구성 요소로 옮긴다.

AI 에이전트는 프롬프트에 답하는 언어 모델 그 이상이다. 에이전트는 지침, 사용할 수 있는 도구, 저장된 맥락, 위임 규칙 및 각 행동을 제어하는 소프트웨어에도 의존한다. 이들 구성 요소를 통틀어 에이전트 하니스라고 한다.

Google Harness2는 시스템 프롬프트, 가드레일, 메모리, 도구 가이드, 서브에이전트, 스킬, 스크립트 및 미들웨어 플러그인 등 여덟 가지 구성 요소를 수정 대상으로 노출한다. 각 구성 요소는 런타임에 마운트되는 파일로 표현된다. 기반 모델의 가중치는 고정된 상태로 유지된다.

이 분리는 중요하다. 모델을 학습하거나 파인튜닝하려면 전문 인프라, 준비된 데이터 및 별도의 배포 절차가 필요하다. 프롬프트, 스킬 또는 도구 지침의 편집은 에이전트가 작업을 수행하는 동안에도 이뤄질 수 있다.

오픈소스 리포지터리는 이 방법을 Linux용 Python 프로젝트로 패키징한다. Python 3.12, 병렬 및 순차 정제, OpenCode 및 Codex 실행기와의 통합을 지원한다. 포함된 데모는 결정론적 편집기와 로컬 Python 실행을 사용하므로 개발자는 모델 자격 증명 없이도 워크플로를 살펴볼 수 있다.

모델 기반 평가는 더 많은 인프라를 필요로 한다. 리포지터리는 Node.js, Google Cloud 인증, Vertex AI를 통한 모델 접근 및 벤치마크별 의존성을 명시한다. WorkBuddy-Bench에는 Docker가 필요하고, 법률 벤치마크에는 문서 처리 유틸리티가 필요하다.

이 구성은 프로젝트의 현재 대상 사용자를 보여준다. 이는 모든 에이전트를 조용히 업그레이드하는 소비자 기능이 아니라, 통제된 평가를 실행할 준비가 된 팀을 위한 연구 소프트웨어다. 이번 공개는 실험을 위한 장치를 제공하지만, 도입자는 여전히 과제, 실행 환경, 평가자 및 운영 한도를 마련해야 한다.

프레임워크는 들어오는 각 작업을 공통의 기본 하니스에서 시작한다. 최신 작업별 구성을 단순히 다음 할당으로 넘기지 않는다. 대신 현재 하니스를 임시로 정제하고, 재사용 가능한 교훈은 별도의 개선 라이브러리에 기록한다.

이 결정은 적응형 시스템에서 흔한 실패를 다룬다. 계약 분석에 도움이 되는 지침은 스프레드시트 작업에는 해로울 수 있다. 성공한 모든 편집을 직접 누적하면 하니스는 점점 더 전문화되고 이해하기 어려워진다.

대신 Harness²는 편집이 왜 도움이 됐는지에 대한 근거를 보존하려 한다. 이후 작업은 이전 실행 구성 전체를 물려받지 않고도 그 경험을 활용할 수 있다.

따라서 이 프로젝트는 두 형태의 소프트웨어를 나타낸다. 하나의 하니스는 작업을 수행하고, 다른 하니스는 그 작업을 수행하는 시스템을 개선한다. 이 두 번째 계층 때문에 저자들은 이 방법을 일반적인 프롬프트 최적화가 아니라 재귀적 에이전트 하니싱이라고 설명한다.

이미 에이전트 지침을 수동으로 관리하는 개발자에게 이번 공개는 익숙한 워크플로를 공식화한다. 팀은 실패를 살피고, 지침을 수정하고, 작업을 다시 실행하며, 유용한 기법을 보존한다. Google Harness2는 이 과정의 상당 부분을 에이전트에 맡기고, 그 결과의 변경 사항을 구조화된 산출물로 기록한다.

Google Harness2가 정답 없이 에이전트를 정제하는 방식

핵심 메커니즘은 완벽한 검증자에게 정답 출력을 식별하게 하는 대신, 일치하는 조건에서의 행동을 비교한다.

프레임워크는 주요 작업 수준 프로세스를 Propose-Probe-Compose라고 부른다. 먼저 제안자가 원래 실행을 분석하고 목표가 명확한 하니스 편집안을 제시한다. 프로브는 해당 후보들로 같은 작업을 다시 실행한다. 이후 컴포저는 결과 궤적 간 차이로 뒷받침되는 변경 사항을 결합한다.

궤적은 모델 응답, 도구 호출, 관찰 결과 및 생성된 파일의 기록된 순서다. 이는 최종 답변만 보는 것보다 시스템에 더 많은 근거를 제공한다. 편집기는 한 수정안이 누락된 입력을 찾았는지, 적절한 도구를 호출했는지, 제출 전 문서를 검증했는지를 확인할 수 있다.

시스템은 제안을 두 범위로 나눈다. 불변 편집기는 파일 작성 후 출력을 확인하는 것과 같은 일반적 실행 행동에 집중한다. 도메인 편집기는 작업별 지식, 형식 또는 절차에 집중한다.

이 분리는 모든 문제에 동일한 일반적 수정을 적용할 가능성을 낮춘다. 또한 두 변경안이 모두 유용한 행동 변화를 만들 때, 컴포저가 널리 유용한 프로세스 규칙과 전문화된 지침을 결합할 수 있게 한다.

중요하게도 온라인 프로세스는 벤치마크의 정답 키를 받지 않는다. 연구 논문은 하니스 설계 이후 작업이 도착하는 오픈월드 환경을 설명한다. 실행 중에는 신뢰할 수 있는 정답 검증자가 없을 수 있다.

시스템은 하나의 후보를 정답으로 선언하는 대신 대비를 찾는다. 예를 들어 기본 에이전트가 여러 소스 파일을 놓친다고 하자. 한 수정안은 모든 입력을 목록화하고, 다른 수정안은 스프레드시트 대사 지침을 추가한다. 이들의 궤적은 이러한 개입이 에이전트의 프로세스를 바꿨는지 보여준다.

컴포저는 그 근거를 사용해 또 다른 하니스를 구성하고 작업을 다시 실행한다. 이 접근법이 판단 자체를 없애지는 않는다. 출력과 알려진 정답을 비교하는 판단에서, 여러 실행에 걸쳐 관찰 가능한 행동을 비교하는 판단으로 옮길 뿐이다.

개발자는 두 가지 방식으로 추가 테스트 시점 컴퓨팅을 사용할 수 있다. 병렬 재귀는 여러 후보 수정안을 동시에 탐색한 뒤 그 시도들의 근거를 조합한다. 순차 재귀는 이전 수정이 끝날 때마다 또 다른 정제를 적용한다.

변수 k는 이 탐색 예산을 제어한다. 값이 클수록 시스템은 편집안을 찾아 시험할 기회를 더 많이 얻지만, 각 기회에는 모델 호출, 도구 사용 및 실행 시간이 추가된다.

작업이 끝난 뒤에는 두 번째 재귀 수준이 지속적 개선 하니스를 업데이트한다. 리플렉터는 채택된 하니스와 개입, 근거 및 결과를 설명하는 경험 파일을 저장한다. 이후 제안은 이 라이브러리를 참조할 수 있다.

이 설계는 경험을 완성된 프롬프트보다 더 이식 가능하게 만든다. 저장된 교훈은 문서 생성 작업에서 최종 파일을 다시 열고 필수 섹션을 확인하는 것이 도움이 된다고 말할 수 있다. 정확한 문서가 달라도 이 프로세스는 여러 도메인에 적용될 수 있다.

이 구분은 프레임워크를 일상적인 지식 업무와도 연결한다. 에이전트는 의사결정 메모를 만들기 전에 회의록, 스프레드시트, 정책 및 프로젝트 문서를 결합해야 할 수 있다. 어려운 부분은 유창한 문장을 생성하는 것보다 출처 전반에서 주장을 추적하는 일인 경우가 많다.

팀은 이미 검색 가능한 지식 베이스를 구축해 이 부담을 줄일 수 있다. Harness²는 이 아이디어를 실행 정책으로 확장한다. 에이전트는 특정 작업을 위해 이 자료를 수집하고, 확인하고, 사용하는 방식을 수정할 수 있다.

그러나 이 메커니즘은 여전히 실험적이다. 행동상의 대비는 근거이지 진실은 아니다. 두 후보가 같은 잘못된 전제를 공유할 수 있으며, 매끄러운 궤적도 부실한 산출물로 이어질 수 있다.

벤치마크 성과는 고정된 에이전트 하니스에 압박을 가한다

보고된 결과는 특히 출발 시스템이 약할 때 하니스 설계가 모델 교체만큼 성능을 바꿀 수 있음을 시사한다.

연구진은 세 가지 전문 벤치마크에서 Harness²를 평가했다. WorkBuddy-Bench는 코딩, 웹 및 사무 작업을 다룬다. JobBench는 전문 업무를 시험하며, Harvey’s Legal Agent Benchmark는 법률 작업 성능을 측정한다.

시험은 두 모델과 두 시작 하니스의 네 가지 조합을 포함했다. 모델은 Gemini 3.5 Flash와 GLM-5였다. 초기 실행 하니스는 OpenCode와 Codex였으며, Claude Opus 4.8은 주요 실험에서 기본 편집기로 사용됐다.

저자들에 따르면 단일 정제 단계는 세 벤치마크 전체에서 시험된 모든 모델 및 하니스 조합을 개선했다. 보고된 최대 성능 향상은 WorkBuddy-Bench에서 11.5점, JobBench에서 4.5점, 법률 벤치마크의 부분 통과율에서 11.8%포인트에 달했다.

가장 큰 WorkBuddy-Bench 변화는 OpenCode에서 GLM-5를 사용했을 때 나타났다. 평균 점수는 한 단계 후 64.2에서 75.7로 올랐다. OpenCode에서 Gemini 3.5 Flash는 72.4에서 77.5로 상승했다.

이 수치는 실용적인 추론을 뒷받침한다. 하니스는 원시 모델 역량만으로 해결되지 않는 실행 행동을 바로잡아 모델 간 격차의 일부를 줄일 수 있다.

결과는 구성에 따라 달랐다. Codex에서 GLM-5는 JobBench에서 23.6에서 24.8로 이동하며 1.2점만 올랐다. 같은 벤치마크에서 OpenCode의 Gemini는 4.5점 개선됐다.

이 변동성은 가장 높은 헤드라인 수치보다 더 중요하다. 이 방법은 모든 모델, 하니스 및 작업에 걸쳐 일률적인 개선을 만들지 않았다. 그 가치는 시작 시스템과 도메인에 따라 달라졌다.

연구진은 재귀 예산도 늘렸다. OpenCode에서 Gemini를 사용할 때 정제 한 단계에서 k=5의 병렬 재귀로 이동하자 WorkBuddy-Bench 성능이 더 높아졌다. 코딩은 80.8, 웹은 81.7, 사무는 83.4에 도달했다.

논문은 선택된 WorkBuddy-Bench 도메인에서 예산이 1에서 5로 늘어날수록 병렬 및 순차 점수가 모두 상승했다고 보고한다. 경쟁 방법은 해당 시험에서 더 작거나 덜 일관된 변화를 보였다.

더 많은 탐색이 전부는 아니었다. 절제 연구에서 개선 라이브러리를 제거하자 평균 WorkBuddy-Bench 성능이 3.1점 낮아졌다. 범위가 구분된 편집기 역할을 제거하면 2.9점의 손실이 있었고, 조합을 건너뛰면 1.6점이 낮아졌다.

JobBench도 비슷한 패턴을 보였다. 라이브러리를 제거하면 점수가 1.8점 낮아졌고, 일반 편집기는 3.7점을 잃었으며, 조합을 생략하면 1.9점이 낮아졌다. 이 결과는 보존된 경험, 전문화된 제안 및 근거 기반 결합이 각각 기여했음을 보여준다.

JobBench 사례 연구는 그 작동 방식을 잘 보여준다. 기본 에이전트는 소스 파일 전반의 정보를 조정하지 못했고, 최종 출력을 다시 열어 검증하지도 않았다. 점수는 43.1점이었다.

한 제안된 개입은 모든 입력의 목록화와 명시적인 출처 추적을 요구했다. 또 다른 개입은 일정, 장소, 인력, 예산 조정에 관한 도메인 지침을 추가했다. 컴포저는 이 개입들이 도입한 네 가지 수정을 모두 유지했고, 재실행 점수는 77.8점이었다.

이 사례는 실패가 절차적 문제였다는 점에서 에이전트 하니스 개선의 필요성을 뒷받침한다. 모델에 기본적인 언어 능력이나 파일 접근 권한이 없었던 것은 아니다. 신뢰할 수 있는 작업 방법이 부족했을 뿐이다.

고정된 하니스도 도메인별로 서로 다른 성과를 보였다. 논문의 비교 결과, 고정 시스템 가운데 Claude Code는 코드 및 오피스 작업에서 앞섰고 Codex는 웹 작업에서 선두를 차지했다. 변경되지 않은 하나의 하니스가 모든 분야에서 선두를 차지한 것은 아니었다.

더 큰 재귀 예산을 적용한 OpenCode를 출발점으로 삼았을 때, Harness²는 가장 강력한 고정형 대안보다 코드에서 4.6점, 웹에서 5.8점, 오피스에서 4.9점 높았다. 저자들은 이 적응형 결과가 추가적인 테스트 시점 연산을 사용했다고 명시적으로 언급한다.

따라서 경쟁 압력은 특정 제품 하나가 아니라 고정 하니스 접근 방식에 향한다. 공급업체가 모델을 개선할 수는 있지만, 주변 지침과 도구가 적응하지 못한다면 사용자는 여전히 일관성 없는 결과를 받을 수 있다.

자기 개선형 에이전트 하니스에는 여전히 독립적인 검증이 필요하다

Harness²는 에이전트의 프로세스를 개선할 수 있지만, 자체 증거는 재귀적 수정이 때때로 더 나쁜 행동을 선택하거나 잘못된 가정을 확산시킬 수 있음을 보여준다.

벤치마크 결과는 프로젝트 저자들이 제시한 것이며, 독립적인 배포 환경 전반에서의 프로덕션 신뢰성은 아직 확립되지 않았다. 논문은 세 번의 실행에 대한 평균을 보고하며, 이는 변동성을 측정하는 데 도움이 되지만 외부 재현을 대체하지는 않는다.

이 방법은 최종 출력을 제공하기 전에 추가 연산을 사용한다. 각 제안, 프로브, 구성, 재실행은 토큰과 실행 시간을 소비한다. 용량이 있을 때 병렬 처리는 경과 시간을 줄일 수 있지만, 근본적인 리소스 비용을 없애지는 못한다.

논문은 JobBench와 WorkBuddy-Bench에 대해 평가된 구성을 경험적 연산-성능 프런티어에 배치한다. 이는 측정된 향상이 테스트된 대안과 비교해 유리했다는 뜻이다. 재귀가 모든 프로덕션 워크로드에서 경제적이라는 뜻은 아니다.

가치가 낮은 작업은 여러 차례의 모델 실행을 정당화하지 못할 수 있다. 법률 메모나 운영 의사결정은 더 많은 검증을 정당화할 수 있지만, 그러한 도메인은 벤치마크 실행기가 제공하는 것보다 더 엄격한 통제를 요구한다.

가장 중요한 경고는 저자들 자신의 실패 분석에서 나온다. 이들은 9건의 성능 저하를 검토하고 후보 선택 실패, 공유된 잘못된 전제, 평가 또는 실행 불확실성으로 분류했다.

한 코딩 사례에서 프레임워크는 점수 95인 대안 대신 점수 55인 출력을 선택했다. 법률 작업에서는 범위를 좁힌 수정이 커버리지를 줄여 점수를 54점에서 26점으로 떨어뜨렸다.

다른 실패는 후보 전반에 공유된 잘못된 가정에서 시작됐다. 이 오류들은 2점에서 11점에 이르는 손실을 초래했다. 제안된 모든 수정이 동일한 잘못된 전제를 받아들인다면, 그 행동을 비교해도 원래의 실수를 드러내지 못한다.

논문은 또한 누락된 심사 결정과 일반적인 실행 간 변동성을 원인 귀속 문제로 지목한다. 달라진 점수는 수정, 확률적 실행 또는 평가 잡음을 반영할 수 있다. 더 많은 프로브는 도움이 되지만 비용을 높인다.

저장소 활동에서도 구현 위험이 드러났다. 공개된 캐시 식별 문제는 작업 식별자가 동일하게 유지되는 동안 작업 지침이나 소스 파일이 변경된 뒤에도 재개된 실험이 이전 출력을 재사용할 수 있다고 보고한다.

이 문제의 작성자는 모델 호출 없이 해당 동작을 재현했으며, 저장된 실행 식별자의 일부에 입력 콘텐츠가 포함되지 않는다고 지적했다. 이 보고서는 공개된 벤치마크 점수에 미치는 영향을 수치화하지 않았고, 검토 시점에 유지관리자의 해결 조치도 첨부되지 않았다.

그럼에도 이 문제는 더 광범위한 운영상의 과제를 보여준다. 재귀 시스템에는 작업, 소스 자료, 하니스 수정본, 캐시된 출력, 평가 설정에 대한 신뢰할 수 있는 계보 관리가 필요하다. 그렇지 않으면 겉보기 개선이 오래된 증거를 반영할 수 있다.

보안 역시 또 다른 우려를 낳는다. 수정 가능한 여덟 가지 구성 요소에는 가드레일, 스크립트, 플러그인, 도구 지침이 포함된다. 이 파일들은 에이전트가 무엇에 접근하고 어떤 작업을 수행하는지에 영향을 줄 수 있다.

자율 편집기에 접근 통제를 약화하거나, 검토되지 않은 스크립트를 실행하거나, 민감한 작업 세부 정보를 영구 저장할 무제한 권한을 부여해서는 안 된다. 프로덕션 사용에는 구성 요소 수준의 권한, 변경 불가능한 보안 경계, 감사 로그, 롤백이 필요하다.

지속적인 경험도 비슷한 주의가 필요하다. 한 고객, 부서 또는 법률 사안에서 얻은 유용한 교훈은 다른 경우에 검색될 때 기밀 정보를 노출할 수 있다. 따라서 개선 라이브러리에는 의미적 관련성뿐 아니라 데이터 분리와 보존 정책이 필요하다.

팀은 성능 최적화와 안전성 검증도 구분해야 한다. 벤치마크 점수는 평가기 기준으로 작업을 완료했는지 보상한다. 하지만 프라이버시, 권한 부여, 사실 정확성, 악의적 입력에 대한 저항성을 자동으로 측정하지는 않는다.

Google Harness2 자체가 이 구분이 중요한 이유를 보여준다. 컴포저는 행동 면에서 설득력 있어 보이지만 객관적으로는 더 약한 후보를 선호할 수 있다. 정답이 없다는 사실은 이 프레임워크가 다루는 문제이지만, 프레임워크가 제거할 수 없는 한계이기도 하다.

합리적인 프로덕션 설계라면 시스템이 위험이 낮은 지침은 수정하도록 허용하되 핵심 정책은 보호할 것이다. 프롬프트 문구와 워크플로 체크리스트는 수정 가능할 수 있다. 자격 증명 규칙, 네트워크 경계, 승인 게이트, 파괴적 작업 제한은 에이전트의 권한 밖에 남아야 한다.

작업 전반에 지속되는 제안 변경 사항에는 사람의 검토도 여전히 가치가 있다. 프레임워크는 수정이 채택된 이유를 설명하는 증거를 만들 수 있다. 운영자는 해당 기록을 활용해 변경 사항이 공유 라이브러리에 들어가기 전에 승인, 거부 또는 제한할 수 있다.

재귀적 에이전트 하니싱이 에이전트 엔지니어링 로드맵을 바꾼다

다음 시험대는 조직이 연산 비용, 성능 저하, 지속 메모리를 통제하면서 성과를 재현할 수 있는지 여부다.

가장 먼저 살펴볼 신호는 독립적인 벤치마크 재현이다. 저장소는 코드, 구성, 프롬프트, 평가 명령을 공개해 외부 팀에 실질적인 출발점을 제공한다. 재현 연구는 최종 점수와 총 모델 사용량을 모두 보고해야 한다.

서로 다른 공급업체에서의 성공적인 재현은 핵심 주장을 강화할 것이다. 이는 적응형 하니싱이 테스트된 모델, 편집기 또는 Google Cloud 환경에 지나치게 결합되어 있지 않음을 보여줄 수 있다.

성과를 재현하지 못한다면 일반성에 대한 근거는 약화된다. 연구자들은 차이가 모델 행동, 벤치마크 버전, 실행 환경, 평가 설정 중 어디에서 비롯됐는지 파악해야 한다.

두 번째 신호는 고립된 벤치마크 실행이 아니라 실제 작업 흐름에서의 성과다. 하니싱 수준의 재귀는 이전 작업에서 얻은 교훈이 이후 제안을 이끌기 때문에 누적 가치를 약속한다.

논문은 그러한 전이에 대한 초기 증거를 제시한다. JobBench를 기반으로 구축한 경험 라이브러리는 WorkBuddy-Bench에서 한 단계 개선 성과를 코드 0.6점, 웹 0.5점, 오피스 2.9점 높였다.

이러한 향상은 가장 강력한 작업 수준 결과보다 작으며, 한 분석은 이후 작업의 경험을 소급적으로 사용했다. 실제 배포는 미래 정보를 가져오지 않으면서 유용한 교훈이 시간 순서대로 축적됨을 보여야 한다.

운영자는 평균 성과와 함께 성능 저하율도 측정해야 한다. 또한 개입 빈도, 지연 시간, 모델 소비량, 사람의 검토를 통과하는 지속적 수정의 비율을 추적해야 한다.

세 번째 신호는 더 강력한 검증 및 거버넌스 계층이다. 저자들은 공유된 가정에 도전하는 프로브, 수정과 변동성을 구분하기 위한 반복 실행, 커버리지와 정밀도 간 균형을 맞추는 더 나은 선택 방법을 권고한다.

저장소 수정도 또 다른 지표가 될 수 있다. 콘텐츠 인식형 캐시 식별자, 고정된 벤치마크 수정본, 신뢰할 수 있는 무효화는 실험의 재현을 쉽게 만들 것이다. 수정 가능한 구성 요소에 대한 명확한 보안 경계는 배포를 더 안전하게 만들 것이다.

더 넓은 연구 분야는 하니스 적응의 대안적 형태도 시험할 것이다. Meta-Harness는 배포 전에 구성을 탐색한다. ReasoningBank는 하니스를 고정한 채 유용한 추론 경험을 검색한다. Harness Scaling은 개별 작업을 위해 하니스를 수정한다.

Harness²는 온라인 작업 적응과 지속적인 개선 메커니즘을 결합한다. 이 결합이 핵심적인 차별점이지만, 위험도 집중시킨다. 잘못된 작업 수준 수정은 하나의 결과에 영향을 주지만, 잘못 보존된 교훈은 이후 작업에 영향을 미칠 수 있다.

개발자에게 실질적인 메시지는 모든 에이전트가 즉시 자신을 다시 작성해야 한다는 것이 아니다. 프롬프트, 메모리, 도구, 오케스트레이션은 연결된 시스템으로 평가할 가치가 있다는 뜻이다.

팀은 제한된 실험으로 시작할 수 있다. 대표적인 작업을 선택하고, 변경 불가능한 기본 하니스를 보존하며, 샌드박스에서만 수정을 허용하고, 총 연산량 대비 출력 품질을 비교할 수 있다. 모든 지속적 변경은 원인을 추적할 수 있고 되돌릴 수 있어야 한다.

지식 근로자도 하니스 품질이 눈에 보이는 에이전트 행동을 좌우하기 때문에 관심을 가져야 한다. 도구 지침이 약하거나, 메모리에 잡음이 있거나, 워크플로에 검증이 빠져 있으면 모델은 신뢰할 수 없어 보일 수 있다. 반대로 더 나은 절차는 모델을 바꾸지 않고도 결과를 개선할 수 있다.

공개 릴리스는 이러한 가설을 검증 가능하게 만든다. 연구자들에게 에이전트가 실패를 진단하고, 운영 지침을 수정하며, 경험을 보존하는 방식을 연구할 공통 구현을 제공한다.

Google Harness2는 궁극적으로 자기 개선 논의를 추상적인 모델 지능에서 검토 가능한 소프트웨어 아티팩트로 옮긴다. 팀이 파일을 검토하고, 수정 이력을 추적하며, 실행을 측정할 수 있기 때문에 이는 유용한 변화다.

하지만 가장 어려운 질문을 해결하지는 못한다. 정답 키가 없을 때 개선자를 누가 검증하는가? 이 프레임워크는 무분별한 편집을 구조화된 행동 증거로 대체하지만, 증거는 여전히 오해를 불러일으킬 수 있다.

앞으로 몇 달 동안 독립적인 재현, 실제 환경의 작업 간 결과, 수정 가능한 구성 요소에 대한 더 엄격한 통제를 지켜볼 필요가 있다. 이러한 신호는 재귀적 에이전트 하니싱이 신뢰할 수 있는 엔지니어링 계층이 될지, 아니면 유망한 연구 워크플로로 남을지를 결정할 것이다.

현재 AI 에이전트를 평가하는 팀이 취할 즉각적인 조치는 간단하다. 모델과 하니스를 분리해 테스트하고, 모든 변경을 기록하며, 자동화된 수정을 유지하기 전에 명확한 증거를 요구하라. Google Harness2는 그 실험을 위한 구체적인 프레임워크를 제공하며, 보고된 실패 사례는 감독이 여전히 중요한 이유를 보여준다.