에이전트가 같은 실수를 반복하는 이유는 모델이 멍청해서가 아니라, 배운 교훈이 다음 에피소드를 인도하는 하네스에 도달하지 못하기 때문이다. Living-Harness는 완료된 상호작용 궤적과 평가 신호를 “사후 증거(posterior evidence)“로 변환하여, 에피소드 기억과 상태 그래프라는 두 개의 보완적 지식 구조에 영구 저장한다. GPT-5.2 medium을 백본으로 쓰면서도 Gemini 3 Pro를 τ²-Bench에서 앞지르고, MultiWOZ-2.4에서는 최강 기준선 대비 평균 10%p 상승을 기록했다.

핵심 문제: 에피소드 내 교정 vs 크로스-에피소드 수리
LLM 에이전트 연구에서 반복해서 등장하는 패턴이 있다. 에이전트가 한 에피소드에서 실패하고, Reflexion 같은 자기 성찰 메커니즘이 “사용자를 휴먼 에이전트에게 연결해야 한다”는 교훈을 도출한다. 그런데 다음 에피소드에서 똑같은 상황이 오면, 에이전트는 또 같은 실수를 한다. 교훈이 해당 에피소드 안에서만 유효하고, 하네스(에이전트를 둘러싼 외부 프로그램)에는 아무런 흔적도 남지 않기 때문이다.
이것이 단순한 메모리 부족이 아닌 이유는, “휴먼 에이전트에게 연결하라”는 텍스트 교훈이 실제로 필요한 트리거 조건, 도구 액션, 워크플로 전환을 명시하지 않기 때문이다. Living-Harness가 주목하는 갭은 바로 이 지점이다: “다음 응답을 개선하는 것”이 아니라 “미래 에피소드를 절차적으로 수리(persistent procedural repair)하는 것”.
Living-Harness의 구조: 롤아웃–평가–갱신 루프

Living-Harness는 하네스를 세 개의 컴포넌트로 분해한다:
- 고정 실행 자원(C_d^act): 도구, 기본 컨텍스트, 도메인 규칙. 배포 후 동결.
- Evolution-SOP(ψ_d): 도메인 수준의 고정된 업데이트 프로토콜. 에피소드 종료 후에만 작동.
- 진화하는 하네스 상태(S_d^(n)): 에피소드 기억(R)과 상태 그래프(G)로 구성.
핵심 설계 원칙은 도구와 기본 컨텍스트를 얼리고, 절차적 지식만 진화시킨다는 것이다. 이는 누적된 경험이 에이전트의 작동 경계를 자의적으로 다시 쓰는 것을 방지한다.
롤아웃–평가–갱신 순환
각 에피소드는 세 단계로 진행된다:
- 롤아웃: 현재 하네스 상태에서 관련 항목을 검색하여 procedural context로 렌더링하고, 에이전트가 환경과 상호작용.
- 평가: 평가자(Evaluator)가 완료된 궤적에 대해 실행 결과 신호(y_n)를 생성.
- 갱신: Evolution-SOP가 궤적과 평가 신호를 “에피소드 추상(e_n)“으로 압축하고, 여기서 절차적 수리 증거(u_n)를 추출하여 기억과 그래프에 커밋.

두 개의 보완적 지식 구조
Living-Harness가 기존 reflection 메서드와 결정적으로 다른 점은, 실패를 두 가지 형태의 구조화된 지식으로 동시에 저장한다는 것이다.
에피소드 기억(Episodic Memory, R)
왜(why), 언제(when) 실패가 발생하고 어떻게(how) 회복했는지를 기록한다:
- 트리거 조건 (trigger conditions)
- 실패 패턴 (failure patterns)
- 회복 액션 (recovery actions)
이는 Reflexion의 “텍스트 교훈”과 다르다. 예를 들어 “환불 한도 초과 시 휴먼 에이전트에게 전환”이라는 교훈이 단순한 문장이 아니라, 구조화된 레코드로 저장된다.
상태 그래프(State Graph, G)
어디서(where) 절차가 끊어졌고 무엇을(what) 연결해야 하는지를 기록한다:
- 상태 노드 (state nodes)
- 수리 엣지 (repair edges)
- 전환 규칙 (transition rules)
상태 그래프는 워크플로 수준에서 “이 상태에서 이 액션이 빠져 있다”는 정보를 인코딩한다. 기억이 경험적 교훈을 보관한다면, 그래프는 실행 가능한 워크플로 구조를 개정한다.
Evolution-SOP: 사후–추출–커밋 절차
Evolution-SOP는 단순한 프롬프트가 아니라 도메인 수준의 고정 프로토콜이다. 세 단계로 작동한다:
- 사후 추상(Posterior Abstraction): 완료된 궤적에서 과제 목표, 검증된 상호작용 사실, 실행 결과, 핵심 실패/회복 지점을 추출. 전체 궤적을 보존하지 않고 절차적으로 유용한 정보만 분리한다.
- 증거 추출(Extract): 추상을 메모리 증거(u_n^R)와 그래프 증거(u_n^G)로 변환.
- 커밋(Commit): 후보 수리를 증거 지지, 과제 범위, 도메인/도구 제약 조건과 대조하여 검증. 통과한 것만 기억과 그래프에 기록되고, 미지원 또는 충돌 후보는 폐기.
이 검증 단계가 중요하다. 검증받지 않은 자기 비판(self-critique)을 그대로 하네스에 기록하면 환각(hallucination)이 누적될 수 있다.
POMDP 해석: 이중 시간척도 적응
Living-Harness는 program-state POMDP 관점으로 공식화된다:
- 에피소드 내(intra-episode): 환경 상태 s_t는 관측-액션 이력에 따라 벨리프 갱신. 프로그램 상태 z^(n)은 고정.
- 에피소드 간(cross-episode): 평가 후, 기억과 그래프 갱신이 새로운 z^(n+1)을 유도.
정보 정제(Information Refinement) 명제는 핵심이다: 프로그램 상태 z가 실행 관련 잠재 변수 ξ에 대해 0이 아닌 조건부 정보를 포함하면, 하네스 상태가 포함된 결합 신념(joint belief)의 Bayes 오차 한계가 환경만의 신념보다 엄격하게 감소한다. 즉, 진화하는 하네스가 수학적으로 더 나은 예측의 기반을 제공한다.
실험: τ²-Bench와 MultiWOZ-2.4에서 압도적 성능

τ²-Bench: Gemini 3 Pro를 넘어서
Living-Harness는 GPT-5.2 medium을 백본으로 사용하면서도 τ²-Bench 평균 Pass@1 83.09%를 기록했다. 이는 Gemini 3 Pro의 82.92%를 넘어서는 수치다. 같은 GPT-5.2 백본에서 가장 강한 기준선이었던 Reflexion(73.02%) 대비 10.07%p 상승이다.
도메인별로 보면 더 선명하다:
- Retail: 57.02 → 85.96 (+28.94)
- Airline: 70.00 → 86.00 (+16.00)
- Telecom: 57.39 → 78.07 (+20.68)
MultiWOZ-2.4: 3-도메인에서의 도약
MultiWOZ-2.4에서는 평균 65.50%로, 최강 기준선 ReasoningBank(55.59%) 대비 9.91%p 상승이다. 특히 3-도메인 과제에서 기준선 7.50%에서 25.87%로 비약한다. 절차적 수리가 도메인 경계를 가로지러 전이될 때 진가가 발휘되는 것이다.
사이클별 누적 효과
Table 2가 보여주는 패턴이 흥미롭다. 첫 번째 진화 사이클(Cycle 0→1)에서 대부분의 큰 폭 상승이 발생하고, 이후 사이클에서는 미세 조정과 간헐적 감소가 나타난다. 이는 초기 업데이트가 누락된 워크플로 단계를 수리하고, 후속 사이클은 축적된 상태를 다듬는 패턴에 부합한다.
컴포넌트 절제: Evolution-SOP가 핵심

절제 실험 결과:
| 설정 | τ²-Bench 평균 |
|---|---|
| 전체 Living-Harness | 83.09 |
| w/o Evolution-SOP | 73.38 (−9.71) |
| w/o Memory | 77.34 (−5.75) |
| w/o State Graph | 79.50 (−3.59) |
Evolution-SOP 제거가 가장 큰 하락을 가져온다. 이는 단순히 메모리나 그래프를 붙이는 것만으로는 효과가 없으며, 구조화된 사후 해석과 bounded state evolution이 근본적인 동력임을 시사한다. 메모리와 그래프는 상호 보완적으로 기여한다.
크로스-모델 전이: 한 모델이 진화시킨 하네스를 다른 모델이 쓴다

가장 실용적으로 중요한 결과 중 하나다. GPT-5.2로 3사이클 진화시킨 하네스 상태를 동결(freeze)하여 4개의 다른 모델에 검색 전용으로 전이했다:
- GLM-5: Taxi 도메인 0.00 → 43.08
- Qwen3-max: Taxi 도메인 0.00 → 45.13
- Kimi-k2: Taxi 도메인 0.00 → 45.13
- Gemini 3 Pro: 전 도메인 평균 +6.34 ~ +38.46 향상
이는 진화된 하네스 상태가 모델 특유의 표현이 아니라 이식 가능한 절차적 지식임을 증명한다. 약한 모델에 더 큰 도움을 주지만, 강한 모델에게도 유의미한 향상을 제공한다.
사례 연구: “알면서도 못 하던” 행동이 어떻게 수리되는가

Figure 4가 보여주는 사례는 Living-Harness의 철학을 가장 잘 요약한다. GPT-5.2 기반 Reflexion은 “환불 한도 초과 시 휴먼 에이전트 전환”이라는 교훈을 3회 연속 올바르게 도출하면서도, 정작 transfer_to_human_agents() 함수를 단 한 번도 호출하지 않았다. “알면서도 못 하는” 것이다.
Living-Harness는 이 실패를 두 가지로 분해하여 저장한다:
- 에피소드 기억: “환불 한도 초과 + 휴먼 전환 필요” → 트리거 조건 + 회복 액션
- 상태 그래프 엣지: “종단 정지 감지” → “transfer_to_human_agents()” 수리 엣지
Cycle 1에서 에이전트가 유사 상황에 직면하면, 검색된 수리가 단순한 조언이 아니라 상태 조건부 실행 지시로 작동하여, 에이전트가 즉시 도구를 호출하고 과제를 완수한다.
기존 자가진화 시스템과의 비교

Living-Harness의 독특함은 기존 self-evolving 에이전트들이 주로 하나의 산물물(메모리, 스킬, 워크플로, 아키텍처 중 하나)만 진화시키는 데 비해, 에피소드 기억과 상태 그래프를 동시에 갱신한다는 점이다. Reflection 계열이 텍스트 교훈에 머물고, AHE/HarnessFix 계열이 워크플로 코드만 수정하는 데 비해, Living-Harness는 경험적 지식과 실행 구조를 분리하면서도 조정한다.
또한 도구와 기본 컨텍스트를 동결한다는 제약이 실은 신뢰성의 원천이다. 도구 인터페이스가 임의로 변경되지 않으므로, 진화하는 지식이 일관된 실행 환경에서 평가될 수 있다.
시사점: “다음 응답”이 아니라 “다음 절차”를 진화시키기
Living-Harness가 던지는 더 넓은 시사점은 이것이다: 신뢰할 수 있는 에이전트는 더 강한 단일 응답 생성이나 모델 측 업데이트에만 의존할 필요가 없다. 미래 상호작용을 조직하는 bounded harness state를 진화시킴으로써, 같은 모델로도 더 나은 에이전트가 될 수 있다.
이는 최근 하네스 진화 연구 라인(Slef-Harness, HarnessFix, Meta-Harness, EvoTrainer 등)과 맥락을 같이하면서도, “어떤 것을 진화시킬 것인가”에 대한 답이 다르다. Living-Harness의 답은: 평가자가 검증한 실패 증거를, 실행 가능한 절차적 수리로, 두 가지 보완적 구조에 영구 기록한다.
실제 적용 관점에서, 하네스 상태가 모델 간 전이된다는 결과는 특히 매력적이다. 비용이 많이 드는 모델로 하네스를 진화시키고, 그 상태를 더 가벼운 모델에 전이하여 추론 비용을 줄이는 전략이 가능하다.
📄 논문: Living-Harness Is an Interactive-Agent Evolver (arXiv:2607.26598)
더 실습해보고 싶은 분들께
에이전트 하네스를 스스로 진화시키는 루프를 직접 설계하고 싶다면, 다음 두 자료가 실질적인 출발점이 됩니다:
- 『이게 되네? 오픈클로 미친 활용법 50제』 — 하네스·루프·도구 사용을 넘어 실제 자동화 시나리오까지 실험해볼 수 있는 활용 사례집
- 「모두를 위한 루프 엔지니어링」 — 에이전트 루프 설계와 진화 메커니즘을 체계적으로 배우는 강의