작업마다 스스로 진화하는 에이전트 하네스

왜 중요한가

LLM 에이전트의 성능을 모델 규모만으로 설명하기 어렵다는 문제를 하네스 생성 자체의 학습 문제로 전환했습니다. JIT-Agent는 작업마다 메모리·계획·행동·역량 조정 구조를 새로 구성하고, 실패 복구와 실행 피드백 기반 진화를 함께 학습해 서로 다른 모델과 작업에 전달되는 운영 능력을 만들었습니다. GLM-5.2와 DeepSeek-V4-Flash에 적용했을 때 9개 벤치마크 평균이 각각 74.1에서 81.8, 66.7에서 75.5로 상승했고, 성능 향상이 더 긴 실행 비용에만 의존하지 않았다는 점이 중요합니다.

핵심 기여

작업 조건부 하네스 지능 정식화

JIT-Agent는 모델이 고정된 실행 골격 안에서 행동하는 데 그치지 않고, 작업에 맞는 하네스를 구성하고 수정하는 Model-as-a-Harness 패러다임을 정의했습니다. 하네스 지능을 적응성, 실행 신뢰성, 진화 가능성의 세 능력으로 분해해 학습 목표로 만들었습니다. 이 관점은 에이전트 능력을 모델 가중치와 하네스의 결합 결과로 평가하게 합니다.

네 모듈 실행 프로토콜과 HarnessFactory

하네스를 memory, planning, action, capability-orchestration의 네 모듈로 고정하고 공통 인터페이스와 실행 커널을 마련했습니다. HarnessFactory는 ReAct, Plan-and-Execute, ReSum, ROMA, AOrchestra 등 13개 하네스를 같은 프로토콜로 재구현해 생성 모델이 참조할 수 있는 설계 공간을 구성했습니다. 그 결과 자유 형식 프로그램 생성보다 검증·조합·비교가 가능한 실행 아티팩트 생성으로 문제를 좁혔습니다.

생성·복구·진화를 잇는 3단계 학습

Stage I은 교사 하네스를 모방하고 성능·지연·비용 선호를 학습해 작업 조건부 생성을 익힙니다. Stage II는 컴파일 오류, 인터페이스 불일치, 도구 호출 실패, 런타임 예외를 버리지 않고 최대 두 번의 수정 궤적으로 바꿔 복구 능력을 학습합니다. Stage III의 Evo-GDPO는 기존 하네스 저장소의 기준점보다 보상·지연·비용 면에서 Pareto frontier를 개선하는 후보를 선택해 온라인 진화를 학습합니다.

모델·하네스 분리 실험과 효율성 검증

JIT-Agent는 같은 backbone에 기본 하네스 대신 생성 하네스를 씌우는 방식으로 하네스 기여를 분리해 평가했습니다. GLM-5.2에서는 9개 벤치마크 평균이 74.1에서 81.8로, DeepSeek-V4-Flash에서는 66.7에서 75.5로 올랐고, 18개 직접 대응 비교 모두에서 성능이 개선됐습니다. 고정 하네스와 비교한 6개 설정에서는 토큰 사용량과 API 비용이 모두 가장 낮았으며 평균 비용 절감은 36.0%였습니다.

핵심 아이디어 이해하기

LLM 에이전트는 모델이 다음 토큰을 생성하는 능력만으로 작업을 끝내지 못합니다. 실행 중인 이력에서 필요한 정보만 골라 현재 상태를 만들고, 다음 하위 목표를 정하고, 사용할 도구를 선택한 뒤, 도구 결과를 다시 상태에 반영해야 합니다. 기존 ReAct 같은 고정 하네스는 이 순서를 모든 작업에 비슷하게 적용하므로 장기 연구, 파일 산출물 생성, 제약 조건 계획처럼 상태 구조가 다른 문제에서 병목이 생깁니다.

JIT-Agent는 하네스를 메모리 M, 계획 P, 행동 A, 역량 조정 F의 네 부분으로 표현하는 $h=(M,P,A,F)$ 구조를 사용합니다. M은 누적 이력과 현재 상태에서 모델이 읽을 view를 만들고, P는 작업·상태·view를 다음 local directive로 바꾸며, F는 그 지시에 맞는 도구와 skill만 활성화합니다. 마지막으로 A는 조합된 입력을 사용해 컨트롤러 상태를 갱신하고 도구 호출 또는 최종 출력을 내보냅니다.

처리는 이력과 상태를 입력으로 받아 view를 만들고, view와 작업을 directive로 변환한 다음, directive에 맞는 capability subset을 선택하고, 선택된 capability와 상태를 행동 루프에 넣어 observation을 얻는 순서로 진행됩니다. 실행은 도구 호출이면 공통 커널이 결과를 반환하고, 최종 출력이면 종료하며, 각 이벤트는 다음 단계의 이력에 추가됩니다. 따라서 동일한 네 모듈 인터페이스 안에서도 Palimpsest는 의존성 DAG와 artifact store를 사용해 연락처 파일을 순서대로 만들고, Trapdoor는 bounded sub-agent와 FactGraphMemory를 사용해 여러 증거 갈래를 조사합니다.

학습은 한 번에 완벽한 하네스를 요구하지 않습니다. Stage I은 유효한 교사 하네스를 모방하고, Stage II는 실패한 하네스와 진단 결과에서 최대 두 번의 국소 수정 방법을 익히며, Stage III는 실행 보상과 지연·비용을 기준으로 기존 저장소를 넘어서는 후보를 남깁니다. 이 구조는 모델이 작업을 수행하는 능력과 작업에 맞는 실행 환경을 설계하는 능력을 분리해 함께 최적화합니다.

관련 Figure

Diagram
중앙의 JIT-Agent는 Memory, Planning, Action, Capability 네 모듈을 task-conditioned module synthesis로 결합합니다. 왼쪽의 Deep Research, Product Generation, Auto Research 작업은 서로 다른 요구를 입력하고, 오른쪽에서는 evidence workflow, artifact store, progress board처럼 각 작업에 맞는 실행 절차와 상태 저장 구조가 생성됩니다. 이 그림은 공통 인터페이스는 유지하면서 실제 planning·action topology와 capability 구성을 작업별로 바꾸는 방법을 나타냅니다.
JIT-Agent가 네 모듈을 조합해 작업별 실행 하네스를 만드는 구조도입니다.

방법론

JIT-Agent는 Qwen3.6-27B를 기반으로 학습한 하네스 지능 모델이며, 추론 시 작업 설명, 고정된 네 모듈 프로토콜, 해당 작업의 capability registry, 기존 하네스 일부를 입력으로 받습니다. 생성기는 이 문맥에서 실행 가능한 하네스를 만들고, 고정된 agentic LLM backbone이 그 하네스 아래에서 실제 rollout을 수행합니다. 검증기는 문법·인터페이스·실행 가능성을 확인하고 task reward, 평균 latency, monetary cost를 기록합니다.

Stage I에서는 task type에 맞는 seed bank 하네스 3개를 참조로 샘플링하고, 더 강한 teacher가 네 모듈 프로토콜을 따르는 task-adapted harness를 생성합니다. 검증과 실행을 통과한 결과는 supervised fine-tuning의 목표가 되며, 같은 backbone과 평가 seed에서 더 높은 reward를 내면서 latency와 cost를 늘리지 않은 후보는 preference pair로 사용됩니다. 이 과정은 단순히 프로토콜을 지키는 생성보다 높은 성능과 낮은 실행 부담을 함께 선호하도록 만듭니다.

Stage II는 Stage I에서 실패한 출력도 학습 자료로 전환합니다. compiler error, interface mismatch, tool-call failure, runtime exception을 구조화한 diagnostic report를 현재 하네스와 함께 teacher에게 주고, 작은 patch를 적용한 뒤 다시 검증합니다. 최대 두 번의 repair round 안에 실행 가능해진 궤적만 보존하므로, 전체 재설계보다 실제 배포에서 회복 가능한 국소 수정에 초점을 맞춥니다.

Stage III의 Evo-GDPO는 현재 harness bank에서 reward가 가장 높은 incumbent를 고르고, 같은 작업·backbone·예산·평가 seed에서 여러 후보를 실행합니다. 후보 reward는 incumbent보다 높을 때 진화 보너스를 받고, reward가 incumbent 이상일 때만 latency와 cost 절감 신호가 켜지며, 세 신호를 각각 정규화한 뒤 reward 가중치를 더 크게 둔 aggregate advantage로 PPO-style 정책을 갱신합니다. 후보가 기존 frontier의 reward를 유지하거나 넘으면서 reward·latency·cost 중 하나를 엄격하게 개선할 때만 bank에 추가합니다.

추론에는 static과 streaming 두 방식이 있습니다. Static inference는 하네스 N개를 병렬 생성하되 하나만 실행해 후보 다양성을 늘리고 rollout 수는 유지하며, streaming inference는 이전 작업에서 얻은 하네스와 실행 지표를 bank에 보존해 다음 작업의 참조로 사용합니다. Streaming에서는 현재 rollout 중간에 환경 피드백을 주입하거나 모델 파라미터를 갱신하지 않고, 작업 종료 뒤 reward·latency·cost를 이용해 저장소 갱신 여부만 결정합니다.

관련 Figure

Diagram
Stage I은 teacher와 accepted harness corpus를 이용해 task-adapted harness를 만들고, Stage II는 failed harness와 diagnostics를 local repair trace로 바꿉니다. Stage III는 harness bank의 incumbent와 candidate group을 비교하고 shared execution으로 검증한 뒤 reward·latency·cost frontier를 개선하는 후보를 보존합니다. 세 단계가 각각 생성 구조, 실행 가능성, 누적 개선을 담당해 JIT-Agent의 학습 목표와 일치합니다.
하네스 생성 모델을 적응·복구·진화의 세 단계로 학습하는 파이프라인입니다.

주요 결과

JIT-Agent가 GLM-5.2와 결합된 경우 9개 벤치마크 평균이 74.1에서 81.8로 7.7포인트 상승했고, DeepSeek-V4-Flash와 결합된 경우 66.7에서 75.5로 8.8포인트 상승했습니다. 같은 backbone을 직접 비교한 18개 benchmark pair 모두에서 JIT 하네스가 기본 scaffold보다 높은 점수를 냈습니다. JIT-Agent + GLM-5.2는 DeepSearchQA 93.9, AgentIF 69.9, PinchBench 93.3을 기록했고, JIT-Agent + DeepSeek-V4-Flash는 DeepPlanning-Shopping에서 83.9를 기록했습니다.

장기 상태 관리와 제약 조건 추적이 필요한 작업에서 상승폭이 컸습니다. DeepSeek-V4-Flash의 DeepPlanning-Shopping 점수는 59.1에서 83.9로 24.8포인트 올랐고, GLM-5.2의 DeepPlanning-Travel 점수는 62.8에서 83.0으로 20.2포인트 올랐습니다. DeepSeek-V4-Flash에서는 xBench-DS가 70.1에서 82.0으로 11.9포인트, DeepSearchQA가 76.2에서 85.1로 8.9포인트 상승했습니다.

고정 backbone에서 하네스만 바꾼 비교에서도 효율성 우위가 확인됐습니다. DeepSeek-V4-Flash에서 JIT-Agent는 DeepSearchQA 85.1, xBench-DS 82.0을 기록해 각 최고 고정 하네스보다 4.7포인트와 4.0포인트 높았고, Qwen3.6-Flash에서는 xBench-DS 70.0과 AgentIF 58.3으로 각각 7.0포인트와 2.9포인트 높았습니다. 6개 통제 설정 모두에서 토큰 사용량과 API cost가 가장 낮았으며, 고정 하네스 대비 case당 비용을 14.9%에서 54.1%까지 줄여 평균 36.0% 절감했습니다.

구체적으로 DeepSeek-V4-Flash의 xBench-DS에서는 토큰 사용량이 527K에서 212K로, 비용이 $0.075에서 $0.039로 줄면서 점수는 78.0에서 82.0으로 올랐습니다. Qwen3.6-Flash의 AgentIF에서는 JIT-Agent가 394K 토큰과 $0.078을 사용해 고정 하네스의 최소 839K 토큰과 $0.170보다 적은 자원으로 55.4에서 58.3으로 개선했습니다. 따라서 점수 상승이 단순히 더 긴 trajectory나 더 많은 도구 호출을 구매한 결과로만 설명되지 않습니다.

ReAct와 비교한 24개 backbone·benchmark 대응에서도 모든 결과가 상승했고 평균 개선폭은 7.6포인트였습니다. 모델 계열별 평균 상승폭은 DeepSeek V4 10.2포인트, Qwen 3.6 4.0포인트, Mimo 2.5 8.6포인트였으며, DeepSearchQA 평균 상승폭은 15.2포인트로 Mimo-V2.5-Pro에서 22.2포인트, DeepSeek-V4-Flash에서 19.0포인트에 달했습니다. Streaming JIT는 DeepPlanning-Shopping, DeepPlanning-Travel, OfficeBench 세 task stream 모두에서 Static JIT보다 높은 누적 정확도로 끝났고, 비용과 tool-call 규모는 작업별로 달랐지만 일관된 증가를 보이지 않았습니다.

관련 Figure

Chart
OfficeBench, AgentIF, DeepSearchQA, DeepPlanning-Shopping에서 JIT-Agent가 결합된 GLM-5.2와 DeepSeek-V4 계열의 점수가 높은 위치를 차지합니다. 예를 들어 GLM-5.2 조합은 DeepSearchQA에서 93.9%, AgentIF에서 69.9%, OfficeBench에서 68.4%를 기록하고, DeepSeek-V4-Flash 조합은 DeepPlanning-Shopping에서 83.9%를 기록합니다. 그래프는 동일한 모델이라도 JIT 하네스가 적용되면 업무·연구·계획·작업공간 전반의 점수가 달라진다는 본문 결과와 연결됩니다.
네 개의 agent benchmark에서 여러 LLM과 JIT-Agent 조합의 점수를 비교한 막대그래프입니다.

Chart
가로축은 case당 API cost, 세로축은 performance이며, DeepSeek-V4-Flash와 Qwen3.6-Flash는 채운 원과 빈 원으로 구분됩니다. DeepSearchQA에서 DeepSeek-V4-Flash + JIT-Agent는 $0.066에 85.1을 기록해 높은 성능과 낮은 비용의 지점에 놓이고, AgentIF에서는 Qwen3.6-Flash + JIT-Agent가 $0.078에 58.3으로 고정 하네스의 최고 점수와 최소 비용을 함께 넘어섭니다. 계단형 선은 어떤 조합도 성능과 비용 양쪽에서 더 좋지 않은 Pareto frontier를 표시합니다.
DeepSearchQA와 AgentIF에서 하네스별 API 비용과 성능의 Pareto frontier를 나타낸 산점도입니다.

Chart
각 행은 하나의 모델 계열과 두 variant를, 각 열은 DeepSearchQA·AgentIF-Oneday·ShoppingPlanning·OfficeBench를 나타냅니다. 실선 JIT 점수는 모든 24개 직접 비교에서 점선 ReAct보다 높고, DeepSearchQA에서는 DeepSeek-V4-Flash가 66.1에서 85.1로, Mimo-V2.5-Pro가 49.4에서 71.6으로 상승합니다. 모델 규모나 계열이 달라도 하네스 생성 효과가 반복된다는 점을 시각적으로 확인할 수 있습니다.
DeepSeek V4, Qwen 3.6, Mimo 2.5의 모델 쌍에서 ReAct와 JIT 하네스 점수를 비교한 패널 그래프입니다.

기술 상세

JIT-Agent의 핵심 표현은 하네스를 네 모듈의 튜플로 두는 $h=(M,P,A,F)$ 입니다. M은 immutable event history와 mutable controller state에서 현재 view를 만들고, P는 task·state·view를 local directive로 변환하며, F는 directive에 맞는 capability subset을 선택하고, A는 state·task·view·directive·capability를 입력으로 받아 다음 state와 action을 출력합니다. action이 executable call이면 공통 Exec 커널이 observation을 반환하고, terminal output이면 null observation과 함께 실행을 끝냅니다.

생성 공간은 자유 형식 출력 G, 문법적으로 유효한 하네스, 프로토콜 준수 하네스, 실행 가능한 프로토콜 준수 하네스의 순서로 좁혀집니다. 고정 protocol은 module schema, interface, lifecycle, validation rule, shared execution semantics를 지정해 언어와 런타임의 우연한 차이를 제거하지만 각 모듈의 내부 전략은 열어 둡니다. 예를 들어 canonical ReAct는 full history, 명시적 planner 없음, ReAct action, 전체 registry 조합으로 표현되고, Codex·OpenCode 계열은 compact memory와 todo planner를 추가한 같은 네 모듈 계약 안에 들어갑니다.

HarnessFactory는 13개 seed harness를 공통 커널 아래 재구현합니다. ReAct와 Plan-and-Execute는 계획 및 행동 흐름의 차이를, ReSum·GAM·MemoBrain·AgentFold·HiAgent·DeepAgent는 메모리 구성을, ROMA와 AOrchestra는 recursive execution과 delegation을 제공해 JIT-Agent가 참조할 설계 다양성을 만듭니다. 초기 bank는 13개 하네스로 시작하고, 이후 각 항목에 task, observed reward, latency, cost를 연결해 새로운 frontier 후보를 저장합니다.

Stage I의 preference는 reward가 더 높고 latency·cost가 각각 기준 이하이며 둘 중 하나 이상이 엄격히 낮은 경우에만 긍정 후보로 취급합니다. 후보의 세 지표는 반복 rollout 평균으로 계산되고, reward 차이와 지연·비용 절감량을 가중합해 선호 강도를 만듭니다. 예를 들어 reward가 상승하면서 cost만 낮아지고 latency가 같다면 조건을 통과하지만, reward가 같은 후보는 이 선호 규칙에서 긍정 후보가 되지 않습니다.

Stage III에서는 후보 그룹의 reward, latency, cost 신호를 따로 표준화하고 aggregate advantage를 계산합니다. reward 가중치는 latency와 cost 가중치의 합보다 커서 작업 성능이 우선되며, latency와 cost 보상은 후보 reward가 incumbent 이상일 때만 활성화됩니다. PPO-style clipped objective는 현재 정책과 rollout 정책의 token probability ratio를 clip하고, Stage-II checkpoint와의 KL penalty를 더해 후보 생성 정책이 한 번의 업데이트로 크게 이탈하지 않게 합니다.

생성된 하네스의 task별 구조 차이는 두 사례에서 드러납니다. Palimpsest는 연락처 발견과 schema 확인을 선행 조건으로 두고, 필터링·정렬·Workbook 생성·Email 전송을 dependency DAG와 bounded width/depth로 실행하며 artifact store에 중간 결과를 저장합니다. Trapdoor는 인용·대학 통합·회고록·논문에 걸친 신원 탐색에서 DynamicDecomposer로 하위 질문을 만들고, 최대 5단계의 private research sub-agent가 반환한 답을 일반 observation으로 부모 루프에 다시 넣으며 FactGraphMemory에 압축된 사실을 축적합니다.

관련 Figure

Diagram
작업 입력은 연락처 카드 탐색, Tom 제외, 이름 정렬, contact.xlsx 생성, contact.eml 전송의 다섯 단계로 분해됩니다. Planning은 이를 dependency-aware DAG로 바꾸고, Action loop는 discover·read schema·filter/normalize·build workbook·aggregate 순서로 실행하며 ThreadPool width ≤ 2와 depth < 3 제약을 둡니다. Persistent memory의 artifact store가 각 목표와 결과를 저장하므로 후속 단계가 전체 transcript를 다시 읽지 않고 이전 산출물을 사용합니다.
Palimpsest가 파일 산출물 작업을 dependency graph와 persistent memory로 실행하는 흐름도입니다.

Diagram
작업 입력은 2010년 논문, 1901년 John Muir 인용문, 1974년 대학 통합, 2023년 회고록을 연결해 공동 저자를 찾는 연구 질문입니다. DynamicDecomposer가 하위 질문을 만들고 OrchestratorLoop가 delegate 호출을 가로채며, bounded sub-agent는 연구 도구로 최대 5단계까지 검색·문서 읽기·간결한 답변을 수행합니다. 반환된 답은 부모 루프의 observation으로 재진입하고 FactGraphMemory가 key-value 사실을 압축해 여러 증거 갈래를 통합합니다.
Trapdoor가 bounded sub-agent를 위임 도구로 실행해 다중 단계 연구 질문을 해결하는 흐름도입니다.

실무 활용

JIT-Agent는 검색, 문서 조사, 파일 생성, 업무 자동화처럼 실행 구조가 서로 다른 작업을 하나의 고정 scaffold로 처리하기 어려운 환경에 적용할 수 있습니다. 작업별로 필요한 상태 저장 방식과 계획 구조, 도구 노출 범위, 검증 절차를 생성하고, 실패 시 최대 두 번의 수정으로 복구하는 운영 흐름을 제공합니다. GitHub 저장소가 공개되어 있어 네 모듈 프로토콜과 하네스 생성 시스템을 실험 대상으로 삼을 수 있습니다.

문서와 인용 증거를 모으는 Deep Research 작업에서 evidence matrix, fact memory, bounded delegation을 조합하는 연구 에이전트 구성
파일 탐색·필터링·정렬·Workbook 생성·Email 전송처럼 산출물 의존성이 있는 업무 자동화 파이프라인 구성
제약 조건이 많은 Shopping 및 Travel 계획에서 DAG planning과 상태 저장을 결합한 장기 작업 실행
기존 하네스 실행 실패의 compiler error, interface mismatch, runtime exception을 이용한 국소 repair 학습
여러 작업 스트림에서 성능·지연·비용을 측정하고 frontier를 개선한 하네스를 다음 작업의 참조로 축적

코드 공개 여부: 공개

코드 저장소 보기

키워드

JIT-Agent(적시 하네스 생성 모델)Agent Harness(에이전트 실행 골격)Harness Intelligence(하네스 지능)Memory·Planning·Action·Capability(네 모듈 프로토콜)Evo-GDPO(진화형 정책 최적화)Test-Time Evolution(추론 시점 진화)Cost–Performance Pareto Frontier(비용·성능 파레토 전선)

용어 해설

에이전트 하네스(Agent Harness): — LLM이 도구를 호출하고 작업을 수행하는 실행 환경의 운영 계층입니다. 대화 이력에서 무엇을 보존할지, 목표를 어떻게 나눌지, 어떤 도구를 열어 둘지, 실패 뒤 언제 복구할지를 결정하며, 같은 모델이라도 하네스 구성에 따라 성능·지연·비용이 달라집니다.
적시 하네스(Just-in-Time Harness): — 미리 하나의 실행 구조를 고정하지 않고 현재 작업의 요구에 맞춰 추론 시점에 하네스를 생성하는 방식입니다. 작업 설명과 도구 목록, 기존 하네스 사례를 입력으로 받아 실행 가능한 메모리·계획·행동·역량 조합을 만들므로, 검색·터미널·연구·파일 처리처럼 서로 다른 작업에 맞춰 운영 구조를 바꿀 수 있습니다.
하네스 지능(Harness Intelligence): — 모델이 작업에 맞는 실행 골격을 만들고, 실패를 고치며, 실행 피드백으로 다음 골격을 개선하는 학습 능력입니다. JIT-Agent는 이를 적응성·신뢰성·진화 가능성으로 나누고, 고정된 모델 가중치 대신 모델과 하네스의 결합을 에이전트 성능의 중요한 단위로 취급합니다.
프로토콜 준수 하네스(Protocol-Compliant Harness): — 메모리·계획·행동·역량 조정 모듈의 스키마와 인터페이스, 수명 주기, 검증 규칙을 공유하는 실행 구조입니다. 생성 결과가 문법적으로만 맞는 데서 그치지 않고 공통 커널에서 실제 실행되도록 제한하며, 서로 다른 하네스를 동일한 설계 공간에서 비교하고 조합할 수 있게 합니다.
진화형 그룹 분리 정책 최적화(Evolutionary Group-Decoupled Policy Optimization): — 새 하네스를 기존 아카이브의 기준점과 비교해 보상·지연·비용을 별도 정규화한 뒤 정책을 갱신하는 학습 방식입니다. 작업 보상을 우선하고, 같은 보상을 유지할 때만 더 짧은 지연이나 낮은 비용을 보상하며, 기존 Pareto frontier를 넘는 후보만 하네스 저장소에 남깁니다.

작업마다 스스로 진화하는 에이전트 하네스

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

실무 활용

키워드

용어 해설

관련 토론

댓글

관련 기사

EvoHarness-RL: 장기 LLM 에이전트의 자기진화 하네스

재귀 언어 모델(RLM)을 활용한 에이전트 하니스 설계와 최적화

EnvHarness로 정적 환경을 정책에 맞춰 재구성

실전 에이전트를 위한 아홉 가지 설계 원칙

Prime Agent로 장기 작업을 확장하는 재귀 실행 하네스

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

실무 활용

키워드

관련 토론

댓글

관련 기사

EvoHarness-RL: 장기 LLM 에이전트의 자기진화 하네스

재귀 언어 모델(RLM)을 활용한 에이전트 하니스 설계와 최적화

EnvHarness로 정적 환경을 정책에 맞춰 재구성

실전 에이전트를 위한 아홉 가지 설계 원칙

Prime Agent로 장기 작업을 확장하는 재귀 실행 하네스