검토된 핵심 진화 기반 자기개발 코딩 에이전트

Ouroboros는 코딩 에이전트의 성능을 고정된 모델 능력만으로 보지 않고, 컨텍스트 조립과 도구 호출, 검증, 복구를 포함한 하네스 자체의 진화 문제로 확장한다. 검토된 커밋만 다음 실행 버전에 반영하는 구조로 자기 수정 능력과 운영자 통제를 함께 다루며, Terminal-Bench 2.1에서 86.97% raw와 86.74% 감사 조정 점수를 기록했다. 장기 실행 에이전트를 배포할 때 성능 향상 루프와 권한 경계를 같은 시스템 안에서 설계해야 한다는 점이 핵심 의미다.

기존 코딩 에이전트의 결과는 기반 모델의 추론 능력만으로 정해지지 않는다. 같은 모델이라도 어떤 컨텍스트를 조립하고, 어떤 도구를 어떤 순서로 호출하며, 결과를 어떻게 검증하고 실패를 어떻게 복구하는지에 따라 장기 작업의 성공률이 달라진다. Ouroboros는 이 실행 하네스를 고정된 외부 프로그램이 아니라 이후 작업을 직접 바꾸는 버전 관리 대상로 취급한다.

일반적인 agent loop는 task를 읽고 컨텍스트를 만든 뒤 도구를 호출하고 결과를 확인하는 순서를 반복한다. Ouroboros에서는 이 loop를 실행하는 repository의 prompt, tool, memory projection, review logic, core code도 task의 결과에 따라 수정 대상이 된다. 다만 자식 에이전트가 만든 patch는 live system repository에 직접 commit할 수 없고, 부모가 lineage와 hash, protected path를 확인한 뒤 3방향 병합을 수행한다.

진화는 두 경로로 시작된다. Free evolution에서는 현재 시스템을 점검하고 개선 사항을 구현하는 일이 그 자체로 task가 되며, 완료가 다음 evolution task를 예약할 수 있다. Experience-driven core evolution에서는 일반 작업 중 중복 메시지 전송이나 review-pack context overflow 같은 문제가 드러나고, 에이전트가 원인을 durable error class로 기록한 뒤 구조적 수정 여부를 판단한다.

자기 수정이 가능하면 성능을 높이는 변경뿐 아니라 더 강한 도구나 다른 model API를 선택하는 변경도 발생할 수 있다. 그래서 Ouroboros는 변경 전후 staged diff fingerprint, reviewer quorum, constitution 보호, 외부 예산 한도, supervisor의 /panic을 둔다. 핵심은 에이전트가 개선할 수 있는 대상과 운영자가 중단·롤백할 수 있는 권한을 같은 진화 루프에 넣되, 후자의 권한은 에이전트 코드 변경 범위 밖에 두는 데 있다.

Ouroboros는 launcher와 supervisor를 mutable agent repository에서 분리한다. Launcher는 startup, process supervision, release bootstrap, panic-stop을 소유하고 repository는 task loop, tools, prompts, memory projection, review logic, benchmark adapters, user interfaces를 소유한다. 외부 workspace task는 별도 repository root에서 실행되고 patch artifact 또는 직접 산출물만 부모 쪽으로 반환된다.

자기 저장소 변경은 owner가 선택한 light, advanced, pro runtime mode와 reviewed commit pipeline을 통과한다. Light는 repository edit을 막고 advanced는 일반 edit을 허용하면서 governance surface를 보호하며 pro는 보호된 edit까지 review 대상으로 허용한다. 각 write는 staged snapshot을 바꾸므로 이전 review evidence를 무효화하고, deterministic preflight, staged diff fingerprint, reviewer evidence 수집, commit 직전 fingerprint 재확인을 순서대로 수행한다.

Review 범위는 context mode에 따라 달라진다. Max mode에서는 whole-repository scope reviewer가 목표, coupling, prompts, functional code를 함께 평가하고 low mode에서는 scope review를 건너뛰되 typed skip row와 diff quorum을 남긴다. 어떤 mode에서도 diff-review panel은 blocking이며, rollback은 이전 reviewed state를 복원하는 별도 recovery path를 따른다.

Task 결과는 execution, objective, review, artifact라는 독립 축으로 기록되고 host-run verification command는 revision-bound receipt를 만든다. Project task에는 journal, workpad, knowledge scope, one-writer lease가 추가된다. 완료 처리에서는 최신 typed answer를 보존하면서 capability failure, infrastructure error, timeout, budget exhaustion, incomplete evidence를 구분한다.

Subagent 구조는 readonly planning scout와 mutative acting child를 task tree 아래에 배치한다. 기본 depth는 2이고 configured maximum은 500이며, acting child는 isolated worktree 또는 admitted external workspace에 쓰고 live system repository에는 commit하지 않는다. 부모는 lineage, patch hash, protected path를 검증한 뒤 three-way indexed integration을 수행하고, pass@1을 보존해야 하는 benchmark profile에서는 delegation을 끄고 planning scout의 context만 별도로 공개한다.

Benchmark launcher는 Harbor task container마다 fresh runtime을 설치하고 official verifier를 사용한다. 각 run은 admission 전 manifest에 seed와 runtime을 기록하며, instance별 ledger에 성공, skip, timeout, infrastructure failure를 append-only 방식으로 남기고 공개 submission copy에는 value-level secret scrubbing과 zero-leftover check를 적용한다. Hope의 live lineage는 frozen benchmark seed와 분리되어 지속 진화하므로 재현 가능한 평가와 운영 중 변화를 구분한다.

Terminal-Bench 2.1에서 Opus 5는 89개 task에 각각 5회씩 총 445회 실행해 387/445, 86.97% raw를 기록했다. trajectory audit에서 약한 verifier를 이용한 의도하지 않은 shortcut 1회를 찾아 제외한 결과는 386/445, 86.74%였고, Claude Code + Fable 5의 83.8%와 비교됐다. 이 범위의 binomial standard error는 약 ±1.7 percentage points이며, audited 점수는 strongest baseline보다 대략 두 standard errors 높았다.

OSWorld-Verified에서는 표준 non-Google-Drive set 361개 중 327.39개에 해당하는 90.69%를 기록해 Intelligence-Indeed의 90.19%, Claude Mythos Preview의 85.4%, Pointer Agent with Opus 4.7의 83.64%보다 높았다. 실행에는 screenshot, 100-turn budget, read-only feasibility pass, task 설정에 따른 per-task proxy session, official evaluator가 사용됐다. CL-Bench에서는 Sonnet 4.6으로 5개의 ordered stateful rollout과 하나의 stateless baseline을 모든 6개 domain에서 수행해 normalized reward 0.2301을 얻었으며, ICL의 0.1960과 Claude Code의 0.1855를 앞섰다.

SWE-bench Pro에서는 양쪽 arm 중 하나라도 reference solution에 도달한 instance를 대칭적으로 제거한 655개 paired task에서 Ouroboros 58.2%, Codex 59.4%를 기록했다. 1.2 percentage-point 차이는 McNemar test에서 p = 0.40으로 통계적으로 구별되지 않아 model-matched parity에 해당했다. GAIA에서는 Sonnet 5를 사용해 Ouroboros 78.2%, Claude Code 78.8%를 기록해 유사한 수준이었다.

Hope는 2026년 8월 6일 cutoff 기준 161 elapsed days 동안 7개 interaction surface에서 실행됐으며, model spend $110.6K, processed tokens 79.7B, code 175,755 lines, memory artifacts 227 MB를 기록했다. 실제 운영 중 public feedback으로 duplicate-send path를 수정했고, 자체 관찰로 review-pack context overflow를 bounded connectivity-aware context atlas로 교체했다. 전자의 수정은 같은 메시지 반복 전송을 막고 후자의 수정은 import-graph centrality와 provider-calibrated size estimate를 사용해 연결성이 높은 core file을 review context에 보존했다.

Ouroboros의 실행 경계는 launcher-supervisor와 mutable repository의 분리로 시작된다. Supervisor는 process tree, startup, panic-stop을 통제하고 repository는 task loop와 tool, prompt, memory, review, benchmark adapter를 실행한다. 이 분리는 에이전트가 수정할 수 있는 substrate와 운영자가 중단하거나 교체할 수 있는 authority를 다른 경로에 둔다.

Self-repository mutation은 staged snapshot에 묶인다. Write가 발생하면 기존 review evidence가 무효화되고 deterministic preflight 뒤 staged diff의 fingerprint를 계산하며, reviewer panel이 evidence를 만든 다음 commit 직전에 fingerprint를 다시 계산해 검토된 변경과 실제 commit 대상이 같은지 확인한다. Constitution은 untruncated path로 resident context에 들어오고 governance file은 deterministic guard로 일반 write path에서 보호된다.

Subagent patch integration에서는 parent task가 commit authority를 유지한다. Planning scout은 readonly evidence만 만들고 acting child는 isolated worktree 또는 admitted external workspace에서 작업하며, parent는 child lineage와 patch hash, protected path를 입력으로 받아 3방향 indexed integration의 결과를 결정한다. 이 과정에서 child가 live system repository에 직접 commit하지 못하므로 실행 중인 부모의 version history와 승인 경계가 분리된다.

Hope의 multi-channel state는 모든 입력을 하나의 ordered message log로 합친 뒤 rolling, per-person, per-call digest로 투영한다. Private correspondence는 public log에서 제외하고 bounded private context만 non-public reasoning projection에 들어가므로 채널마다 독립 agent를 만들지 않는다. Public message는 commit, restart, shell, identity-edit tool을 직접 호출하지 못하며, budget과 model routing은 authenticated operator channel에서만 처리되고 /panic은 정상 agent handling보다 먼저 supervisor가 해석해 process tree를 종료한다.

평가에서는 모델과 harness를 함께 기록해 실행 조건을 통제한다. Terminal-Bench 2.1은 89 task에 5 trials씩 총 445 trials를 사용하고 공식 verifier와 anti-lookup paragraph를 적용하며, CL-Bench는 5 ordered stateful rollout에서 native memory를 유지하되 conversation state는 질문 사이에 reset한다. SWE-bench Pro는 reference-solution 도달 instance를 양쪽 arm에서 대칭 제거한 뒤 paired comparison을 수행해 공개 자료 누출이 raw aggregate 해석에 미치는 영향을 줄인다.

안전 통제는 진화 압력 아래에서도 남아야 하는 독립 경계를 여러 개 둔다. Model API와 provider route 변경은 capability, refusal behavior, prompt-injection surface, cost를 바꿀 수 있으므로 audited configuration change로 취급하고, external spend cap은 agent tool로 올릴 수 없게 외부에 둔다. Staging health check, crash rollback, protected governance paths, review quorum, isolated operator channel, /panic이 함께 작동해 agent-level recovery mechanism과 supervisor-level shutdown authority를 구분한다.

논문은 단일 장기 실행 lineage를 추적했으며, 독립적으로 진화하는 여러 agent population을 비교한 controlled study는 아니다. SWE-bench Pro는 공개 reference leakage와 task defect의 영향을 받는다. LLM reviewer가 agent와 같은 blind spot을 공유할 수 있고 low context mode에서는 whole-repository scope review가 생략된다.