KO
GEODE의 공식 픽셀 캐릭터 Geodi
전시실로

GEODE

Autonomous Agent Harness

관측에서 다음 행동으로.

연구, 파일 작업, 예약 작업을 맡길 수 있는 로컬 자율 에이전트 하네스입니다.

2026.02.21 — present

설계·판단·검증 Author · 구현 Claude · 리뷰 Codex

  • CLI공개 배포 · PyPI
  • MCP 서버구현

실행을 검증 가능한 기록으로

성공률만 남기면 왜 성공하거나 실패했는지 확인하기 어렵습니다. 실행 순서, 도구 호출과 결과, 재시도 계보, 독립 검증 결과를 따로 보존하고 공개 범위에 맞춰 연결했습니다. 아래는 실험마다 이 기록과 판단 절차를 어떻게 다듬었는지 보여 줍니다.

실험별 기록 · 날짜순

여섯 실험은 날짜순으로 놓았을 뿐 하나로 이어진 최적화 과정이 아닙니다. SIL이 Crucible이나 Jev로 자동으로 이어지지 않고, 제품 GEODE가 계속 좋아졌다는 주장도 아닙니다. 날짜는 실험과 공개 스냅숏의 날짜이며, 화살표는 한 실험 안의 단계에만 씁니다.

  1. June 3, 2026 to June 4, 2026SIL · 외부 정책 탐색

    감사 한 번으로 얻은 KEEP을 반복 측정으로 다시 확인했습니다

    질문정책 변경이 감사 잡음을 넘어 도구 사용 행동을 개선했는가?

    외부 실험 · GEODE 런타임 밖

    1. 기준선 · K=5
    2. 정책 변경 1개
    3. Petri 감사
    4. 반복 측정
      • 유지
      • 되돌림
    바뀐 점
    이 실험에서는 변경과 감사 한 번의 결과에 반복 측정을 더해 유지 또는 되돌림을 정했습니다. 난이도를 맞춘 seed와 K=5 기준선을 더하고, never · random · gate 세 arm으로 변경 없이 생기는 흔들림과 채택된 변경을 구분했습니다.
    보여 주는 것
    감사 한 번에서 KEEP된 후보를 다시 측정하자 기준선보다 나빠(낮을수록 좋은 지표) 채택을 되돌렸습니다. 이 실험의 결론은 뚜렷한 개선 없음입니다. 과제 완료 보상이 아니라 Petri broken_tool_use 행동 감사입니다.

  2. July 11, 2026 to July 13, 2026Crucible · 외부 실험 커널

    탐색에 남기는 판정과 제품에 반영하는 판정을 나눴습니다

    질문후보를 탐색에 남기는 근거와 제품 반영 · 배포를 허락하는 근거는 같은가?

    외부 Crucible 커널 · 별도 측정 체크아웃

    1. 후보 · 부모 계보
    2. 고정 계약 검사
    3. 쌍 측정
      • KEEP별도 sealed 판정으로만
      • REJECT
      • INVALIDnull · 0%가 아님
    바뀐 점
    거절되거나 무효가 된 후보까지 부모 계보와 함께 남기고, train 선택 · sealed 적격 · 제품 반영 · 배포 권한을 서로 다른 기록으로 나눴습니다.
    보여 주는 것
    r14는 train에서 KEEP(6개 과제 묶음, 각 1회, 승격 권한 없음)였지만 별도 sealed 판정은 REJECT(제품 반영 · 배포 권한 없음)였습니다. r35는 커버리지 부족과 인프라 오염으로 INVALID이고, 쌍 행이 없어 평균은 null로 둡니다. 런타임 자기 수정이나 SIL → Crucible 배포 연결이 아닙니다.

  3. July 21, 2026 · July 31, 2026정제 · 공개

    남은 기록을 분류하고, 공개할 수 있는 부분만 불변 release로 묶었습니다

    질문무엇을 실제로 재구성할 수 있고, 무엇을 안전하게 공개할 수 있는가?

    1. 비공개 원천세션 기록 · 원천 증거native 결과 · verifier 포함
      • 정규화 이벤트순서 · 식별자 보존
    2. 정규화 이벤트식별자 · 순서 · 호출-결과 쌍
      • 공개 후보allowlist · 가림 · 해시
    3. 공개 후보검토 대상
      • 무결성 · 개인정보 검사검사
    4. 무결성 · 개인정보 검사쌍 · 계보 · 범위
      • 불변 release검토된 바이트만
    5. 공개 저장소불변 releasemanifest · native 결과는 digest로 참조
      • 원격 재확인해시 확인
    6. 원격 재확인고정 SHA-256
    바뀐 점
    7월 21일 inventory에서 대화 · 도구 · 탐색 · 판정 기록을 출처별로 분류했고, 같은 원천의 중복은 독립 예시로 세지 않았습니다. 7월 31일부터는 geode.trajectory@1 · geode.trajectory-release@1로 식별자, 이벤트 순서, 호출-결과 쌍, 범위 · 재생 무결성, 내용에 묶인 manifest를 명시합니다. 변환한 공개본과 원본은 digest를 따로 둡니다.
    보여 주는 것
    여기서 정제는 정규화, 상관관계 연결, 명시적 가림, 계보, 공개 승인을 뜻합니다. 숨은 추론을 복원하거나 학습용 데이터셋을 선언하는 일이 아닙니다. 범위가 완전해도 비공개 본문을 digest로 바꾸면 바이트 재생은 불완전합니다.

  4. August 25, 2026Learning view

    한 번의 rollout과 그 증거를 식별자로 묶었습니다

    질문어떤 입력, 시도, 이벤트 순서, 보상이 서로 짝인가?

    geode.eval-learning-view@2 · ID와 검증된 digest로 묶음, 인과 순서 아님

    1. example
    2. rollout
    3. trajectory
    4. reward

    reward는 native verifier receipt가 소유합니다. 인프라 재시도는 한 rollout 안의 attempt입니다.

    바뀐 점
    불변 trajectory를 범위가 정해진 join으로 다시 쓰고, 보상은 평가기가 소유한 파생 라벨로 둡니다. 인프라 재시도는 rollout 수를 늘리지 않습니다. 관측된 0은 그대로 남기고, 보상이 없으면 null입니다. 무효하거나 중단된 attempt는 보상 선택에서 빠집니다. 유효성은 rollout의 속성이며, 무효라고 해서 보상이 저절로 null이 되는 것은 아닙니다.
    보여 주는 것
    Harbor 0.8.0으로 돌린 Terminal-Bench fast-3(세 과제, 3/3)과 Tau2 세 도메인 진단(1/3, 유효한 0 두 개)을 같은 구조로 묶었습니다. 학습 후보일 뿐 학습에 쓴 데이터셋이나 가중치 개선의 증거가 아니며, 세 과제 결과는 전체 정확도가 아닙니다.

  5. August 27, 2026 to September 5, 2026Harbor · Terminal-Bench 2.1

    한 trial에서 결과와 재생 기록을 따로 만들었습니다

    질문실제 과제 실행이 어떻게 결과와 확인 가능한 재생이 되는가?

    1. 고정 과제 · spec사전 고정 · 다섯 반복
      • 격리된 trial지시 · 환경 · 한도
    2. Harbor 0.22.0 trial · 실제 실행격리된 trialGEODE 실행자
      • 실행과 최종 상태실행
    3. 실행과 최종 상태관측된 행동
      • 과제 소유 verifier과제 상태 확인
      • ATIF · 공개 이벤트 투영기록 이벤트 투영
    4. 과제 소유 verifier
      • native 보상 · receipt보상
    5. native 보상 · receipt
      • 선택된 attempt 분석고정 선택
    6. ATIF · 공개 이벤트 투영후처리 · 새 실행 아님
    7. 선택된 attempt 분석고정 선택 규칙
    바뀐 점
    사전 고정한 spec, 모든 attempt, 선택된 결과, 과제 소유 verifier, 충실하지만 범위가 제한된 replay를 서로 다른 링크된 기록으로 남겼습니다. Harbor 0.22.0에서 GPT-5.6 Sol/max로 다섯 번 반복해 GEODE(당시 단일 터미널 도구 어댑터)와 Codex를 비교했습니다.
    보여 주는 것
    과제는 지시 · 환경 · 테스트를, trial은 한 번의 시도를, job은 trial 묶음을 뜻합니다. 보상은 과제 소유 verifier가 정하고 GEODE 내부의 완료 판정은 실행 중 피드백입니다. 공개 replay는 기록된 도구 이벤트의 사후 투영이라 원 PTY나 새 실행이 아니며, 빈 칸에 명령을 만들어 넣지 않았습니다. 사전 등록 primary는 측정할 수 없었습니다.

  6. September 24, 2026 to September 28, 2026Jev · 판단 위임

    후보가 맞아도, 전달은 따로 확인해야 했습니다

    질문위임한 판단이 실제 과제 품질과 최종 전달을 지키는가?

    1. U8n · Noul 실행 · Harbor 0.22 · 실행과 수리는 Astra, 판단 경로만 바뀜결정 상태과제 계약 · 후보 · 도구 관측
      • 판정 · Noul판정 입력
    2. 판정 · NoulAstra 또는 Jev
      • GEODE 소비조건별 확률
    3. GEODE 소비충족이면 전달, 근거 부족이면 보류
      • 최종 전달충족
      • Astra 수리근거 부족 · 보류
    4. 최종 전달
      • 독립 결과 검증전달된 결과
    5. Astra 수리피드백을 받은 다음 후보
      • 판정 · Noul다시 판정
      • 마지막 후보 · 보존마지막 후보 보존
    6. 독립 결과 검증규칙 oracle · 전달된 결과
    7. U3 고정 패널판단만 비교 · 실행자 · 도구 · Harbor 없음
    8. 사후 진단 · 실행이 끝난 뒤마지막 후보 · 보존
      • 사후 oracle 진단사후 검사
    9. 사후 oracle 진단후보 정답 여부 · 전달과 무관
    바뀐 점
    판단 수용, 후보 정답, 최종 전달을 서로 다른 결과로 기록하고, 준비 · 실패 · 수리 계보를 공개본에 보존했습니다. 원본과 변환된 공개본의 해시는 따로 둡니다.
    보여 주는 것
    중단된 U8n의 사후 11쌍에서 마지막 후보는 두 구성 모두 정답이었지만, 전달은 Astra 11/11 · Jev Noul 0/11이었습니다. Jev Noul의 근거 부족 판정이 전달을 보류시켰습니다. 사후 분석이며 일반화하지 않습니다. 공개 수치 재계산, replay 확인, 새 실행은 서로 다른 작업입니다.