코드와 실패 로그를 찾아 읽으며, LLM의 실행 절차를 고치는 에이전트

근거: arXiv v1, PDF, LaTeX 본문, 부록 A–E. 본문·부록·표의 명시값을 기준으로 정리했다. 아래 AI 해석·후속 질문은 정리자(Codex)의 해석과 연구 질문이다. 저자는 Lee·Nair·Zhang·Finn은 Stanford, Kangwook Lee는 KRAFTON, Omar Khattab은 MIT로 표기한다. 순위는 논문에 수록된 비교 시점의 결과다.

주요 원자료: 분류 test, 정보 접근 ablation, optimizer search 비교, OOD 분류, 수학, TerminalBench-2, 분류 variant별 characters.

이 논문에 대한 추가 질문과 답변 기록. 답변은 원문(sources/2026-03_meta-harness/)에 근거하며, 근거 위치(섹션/그림/표)를 함께 적는다. 논문에 없는 내용(정리자의 추론·의견)은 💭 해석으로 따로 표시한다.

Q. Base model이 episode의 trajectory·reward를 보고 reflection을 남기는가, 아니면 로그를 proposer가 읽는가? (2026-10-18)

A. Meta-Harness의 공통 outer loop는 후자다. Base model이 episode를 마칠 때마다 평가 결과를 다시 받아 별도의 reflection을 작성하고, 이를 다음 episode의 memory로 축적하는 단계를 필수 절차로 두지 않는다. 평가 코드는 후보 harness의 코드·점수·execution trace(prompt, tool call, model output, state update)를 저장하고, proposer가 다음 harness를 설계할 때 이를 조사한다(§3, Algorithm 1, App. D).

흐름은 base model + H 실행 → 외부 평가·기록 → proposer의 기록 조사·실패 진단 → H′ 작성 → 재평가다. 로그에는 실행 중 model reasoning이나 state update가 포함될 수 있으므로 숫자만 저장하는 것은 아니다. 다만 reasoning trace가 기록되었다는 사실과, 최종 reward를 받은 base model이 사후 reflection을 별도 생성했다는 것은 다르다.

Proposer의 진단은 실제로 있다. App. A.2에서는 여러 실패 후보를 비교하고, prompt 변경이 구조 수정과 함께 적용되어 회귀 원인을 혼동했을 가능성을 지적하고, 이후 환경 snapshot을 추가하는 방식으로 설계를 바꾼다. 여기서 반성·가설 형성의 주체는 proposer다. 이때 적힌 진단은 proposer의 recorded reasoning이며 base model의 episode 종료 후 회고가 아니다.

“검색하든 안 하든”은 조금 보정해야 한다. 특정 파일·parent·검토 순서를 강제하지는 않지만, §3은 매 iteration 과거 코드·점수·trace를 조사한 뒤 후보를 제안하는 절차로 설명한다. App. A.1의 TerminalBench 10-iteration run에서는 iteration당 median 82개 파일을 실제로 읽었다.

범위 주의: 후보 harness 내부의 memory·verification·reflection까지 금지하는 방법은 아니다. 초기 baseline ACE는 reflective memory curation을 사용하며(§4.1), 발견된 분류 variant에는 draft verification이 있고(App. B.1), TerminalBench harness에는 completion checklist가 있다(App. B.3). 하지만 이런 내부 절차를 Meta-Harness 공통의 “최종 reward 기반 post-episode reflection” 단계로 동일시할 근거는 없다. 논문과 부록만으로 모든 후보 코드에 그런 동작이 전혀 없다고 단정할 수도 없다.

• 근거: §3와 Algorithm 1, App. A.1–A.2, B.1, B.3, D.
• 💭 해석: 경험을 사전에 reflection으로 압축해 두는 체계보다, 원본 경험을 보존하고 개선 시점에 proposer가 목적에 맞게 해석하는 체계로 이해할 수 있다. 축적되는 개선 결과는 공통 loop에서는 새 harness 코드이며, base model의 reflection memory라고 볼 수는 없다.

Q. Proposer는 구체적으로 어떻게 이전 기록을 조사하는가? 실제 source code로 보면? (2026-10-18)

A. 공식 공개 코드의 8123ccabe2b19fa1123090b2e5f1bacc20963ce8 commit을 보관하고 코드 해설을 작성했다. Outer loop는 파일 경로와 task prompt, domain skill을 전달하고 claude_wrapper.run()으로 Claude Code session을 연다. Skill이 frontier·history·실패/성공 trajectory·candidate code를 읽도록 지시하며, 실제 파일·검색식·조회 범위는 model이 Read/Grep/Bash 등의 tool call로 선택한다. 별도 vector retriever가 문맥을 자동 구성하는 방식은 검토한 TerminalBench 경로에 없다.

공개 TerminalBench skill에는 분석용·구현용 subagent를 순차적으로 사용하는 workflow가 있고, 분류 skill은 main session만 쓰도록 지시한다. 공개 배포본은 논문 코드의 cleaned-up release이므로 논문 당시의 정확한 prompt와 동일하다고 가정하지 않는다.

이전 답변 보완: Base model의 reward 기반 post-episode reflection은 공통 단계가 아니다. 그러나 저장되는 것이 dry log뿐인 것은 아니다. Proposer의 hypothesis·changes·session output도 남고, 공개 분류 skill Step 0은 누락된 과거 iteration에 30줄 이하 post-eval report(변경·개선/회귀 이유·교훈)를 쓰도록 한다. 주체가 proposer라는 점과 원본 trace를 계속 조사할 수 있다는 점이 핵심이다.

• 근거: 공식 코드 reference_examples/terminal_bench_2/meta_harness.py의 render_task_prompt/propose_claude/update_evolution_summary, claude_wrapper.py의 run/build_command/log_session, TerminalBench·분류 SKILL.md. 보관 commit.

Q. 하나의 benchmark에서 최종 LLM + Harness가 만들어지는 과정을 전개도로 보면? (2026-10-18)

A. Base model M은 처음에 정해 고정하고, 그 M과 benchmark에 맞는 harness H를 탐색한다. 최종 산출물은 M의 새 가중치가 아니라, 고정 M을 호출하는 개선된 Python harness H*다. Proposer P는 이 프로그램을 만드는 역할이다(§3, Algorithm 1).

TerminalBench-2의 Opus 4.6 설정을 예로 들면:

flowchart TD
    A["① 설정: benchmark = TerminalBench-2<br/>Base M = Opus 4.6, 가중치 고정"]
    B["초기 H: Terminus 2 / Terminus-KIRA"]
    E["② M + H로 benchmark 실행·채점"]
    D[("후보 코드 · 점수 · trajectory 저장")]
    P["③ Proposer P<br/>Claude Code + Opus 4.6<br/>과거 기록 조사 → 수정 가설"]
    H["새 후보 H 작성·interface 검증"]
    S["④ 탐색 종료 후 H* 선택"]
    F["최종 실행 시스템<br/>고정 M + 선택된 H*"]
    A --> B --> E --> D --> P --> H --> E
    D -->|탐색 종료| S --> F

1. 준비: Benchmark·평가 함수·base model을 고정하고 초기 harness들을 준비한다. 이 예에서는 P와 M 모두 Opus 4.6이지만, 코드를 고치는 역할과 task를 푸는 역할은 다르다.
2. 실행·기록: M + H로 여러 task를 수행하고 점수·코드·trace를 남긴다.
3. 반복 개선: P가 여러 과거 후보와 trace를 읽고 새 H를 작성한다. 같은 M으로 평가하며 반복한다. 매번 직전 후보만 수정해야 하는 것은 아니고, 모든 수정이 개선되는 것도 아니다.
4. 산출물 선택: 점수와 필요시 비용을 보고 후보를 고른다. 일반 알고리즘은 Pareto frontier를 반환하므로 항상 단 하나의 H만 반환하는 것은 아니다. 여기서는 그중 실행에 쓸 H* 하나를 선택하는 경우를 그렸다.

논문이 설명한 대표 TerminalBench harness H*는 Terminus-KIRA + environment bootstrapping이다. Working directory·파일·설치 도구·언어 버전 등을 첫 model call 전에 수집해 초기 prompt에 넣는다. 최종 Opus 4.6 조합의 pass rate는 76.4%다(§4.3, Table 7, App. B.3).

flowchart LR
    T["Task"] --> B["H*: 환경 정보 수집·초기 prompt 구성"]
    B --> M["Base M: Opus 4.6"]
    M --> U["H*: 도구 실행·관찰 처리·완료 확인"]
    U -->|계속 수행| M
    U -->|완료| O["결과"]

이 고정 시스템을 실행할 때 outer-loop proposer를 매번 호출할 필요는 없다. 모델을 선택하는 search나 모델 weights 학습도 이 절차의 기본 구성은 아니다. TerminalBench-2는 탐색·평가에 같은 89 tasks를 사용하므로, 최종 76.4%를 unseen task 일반화의 증거로 읽지는 않는다.

• 근거: §3, Algorithm 1, §4.3, App. B.3, Table 7.

Q. 새 Harness 후보의 인터페이스 검증은 보통 어떻게 하는가? (2026-10-18)

A. 비싼 benchmark 전에 후보를 evaluator에 연결해 실행할 수 있는지 확인하는 단계다. 논문 App. D는 module import → class instantiation → 아주 적은 example에 필요한 method 호출을 권한다. 성능 개선 판정은 이후 평가의 역할이다.

공개 TerminalBench 코드(보관 commit 8123cca)의 경로는 후보 → import/class 검증 → 1-task smoke test → 전체 benchmark다.

1. validate_agent_class(import_path): MODULE:CLASS 형식인지 확인하고, importlib.import_module()로 module을 불러온다. getattr()로 지정 class를 찾고 inspect.isclass()와 issubclass(..., Terminus2)를 검사한다. 외부 loop는 class 이름을 AgentHarness로 정규화한다. validate_candidate()는 이 검사를 30초 제한의 별도 process에서 실행한다. 이 단계만으로 instance 생성이나 method signature·반환값·동작의 완전한 호환성이 확인되는 것은 아니다.
2. smoke_test(): extract-elf 한 task를 한 trial 실행한다. Process가 정상 종료하고, result.json이 존재하고, 보고된 stats.n_errors가 0이면 통과한다. 이 함수는 reward가 1인지 검사하지 않으므로 문제를 틀려도 runtime error 없이 실행되면 통과할 수 있다. --skip-smoke로 생략할 수 있다.
3. 통과한 후보만 정식 benchmark에 넣어 pass rate 등 성능을 측정한다. 모든 후보가 invalid하면 이 iteration은 평가를 건너뛰고 실패를 기록한다.

공개 분류 코드의 validate_candidates()는 30초 내 candidate module을 import하고 OK를 출력하는 더 얕은 검사다. MemorySystem은 predict·learn_from_batch·get_state·set_state의 interface를 정의하지만, 해당 import check가 이 method들을 실제 호출하는 것은 아니다. 따라서 논문의 구현 권장사항과 각 공개 domain의 자동 validation을 구분해야 한다.

• 근거: App. D, TerminalBench class 검사, import 검증·smoke test, 평가로 이어지는 분기, 분류 import check.

Q. Proposer는 한 iteration에 하나의 harness 후보만 만드는가? (2026-10-18)

A. 반드시 하나는 아니다. Algorithm 1은 proposer가 한 iteration에 k개의 새 harness {H1, …, Hk}를 제안하고, 각 후보를 interface validation한 뒤 통과한 후보를 각각 평가·기록한다. Single coding-agent proposer라는 것은 proposer 구성에 대한 말이며 후보 수가 1이라는 뜻이 아니다.

• 논문 §4.1의 분류 실험: iteration당 2개, 20 iterations로 40개 후보.
• 논문 §4.2의 수학 실험: 40 iterations에서 총 109개 후보. 고정된 iteration당 후보 수는 이 숫자만으로 확정할 수 없다.
• 공개 TerminalBench skill(보관 commit 8123cca): iteration당 정확히 1개 variant를 요구한다.
• 공개 분류 skill(같은 commit): iteration당 정확히 3개 memory system을 요구한다. 논문 분류의 2개와 다르므로 설정을 구분한다.

후보가 여러 개면 각각 검증·평가하고 결과를 모두 기록한다. 다음 iteration에서는 이 결과들과 더 오래된 기록을 함께 볼 수 있으며, 매번 승자 하나만 남겨 직선으로 수정해야 하는 규칙은 아니다(§3). 앞 전개도의 “새 Harness 후보” 노드는 일반적으로 후보 묶음을 의미하도록 읽을 수 있고, 공개 TerminalBench 예에 한정하면 1개가 맞다.

• 근거: Algorithm 1, 분류 설정, 수학 설정, 공개 TerminalBench skill, 공개 분류 skill.

Q. 다음 iteration의 parent harness는 최고 점수 후보로 자동 선택되는가, 아니면 proposer가 정하는가? (2026-10-18)

A. 논문의 방법 정의에서는 proposer가 정한다. §3은 population·Pareto frontier를 유지하지만 parent-selection rule은 강제하지 않는다고 명시한다. Proposer는 어느 과거 후보의 코드·trace든 조사할 수 있고, local edit·여러 설계 결합·큰 rewrite를 선택할 수 있다. 강한 기존 harness에서 시작하는 경향은 있지만 hard-coded rule이 아니라 관찰된 전략이라고 설명한다. 따라서 frontier의 최고 점수 기록과 다음 proposal의 parent 선택은 별개다.

공개 release의 domain별 지시는 더 구체적이다. 보관 commit 8123cca의 TerminalBench render_task_prompt()는 매 iteration “Start from agents/baseline_kira.py as the parent”라고 전달한다. 동시에 해당 skill은 agents/의 기존 agent 하나를 복사해 시작하고 필요한 코드를 재사용하도록 지시한다. 분류 skill은 “Copy a top-performing base system”이라고 지시한다. 따라서 공개 구현까지 포함해 완전히 아무 제약 없이 parent를 고른다고 설명하면 부정확하다. 공개 TerminalBench update_frontier()는 최고 후보를 기록하지만, render_task_prompt()가 그 최고 후보를 자동으로 parent에 대입하는 코드는 아니다.

• 근거: 논문 §3, 강한 prior에서 시작하는 경향, 공개 TB prompt, TB skill의 시작점 지시, 분류 skill, frontier 기록.

Q. Proposer가 고칠 수 있는 harness 구성요소는 사람이 미리 정의해야 하는가? (2026-10-18)

A. 수정 가능한 구성요소·선택지를 모두 사전 열거할 필요는 없다. 다만 evaluator에 연결되는 interface와 수정 가능한 코드의 경계는 사람이 정한다. §3은 retrieval·memory·prompt construction 수정에서 full program rewrite까지 허용하는 code-space search로 설명한다. App. D는 skill에 금지 사항·산출물·목표를 쓰되 diagnosis procedure는 자유롭게 두도록 권한다.

사람이 준비하는 것은 task·평가 함수·고정 base model·baseline, candidate 파일 위치, evaluator가 호출할 class/method와 입출력 계약, 수정 금지 파일 등이다. Proposer는 그 경계 안에서 retrieval algorithm, memory structure, prompt, tool, retry, observation processing, agent loop 같은 내부 구현을 바꾸거나 새로운 기능·보조 method를 추가할 수 있다. 후보가 evaluator에 연결되어 실행되고 채점될 수 있어야 한다.

공개 TerminalBench skill은 search space를 arbitrary Python code로 설명하고 어떤 method도 override할 수 있다고 명시한다. 주요 method 목록은 읽기·수정의 안내이며 닫힌 허용 목록이 아니다. 단, single-file agents/<name>.py, class 이름 AgentHarness, Terminus2 상속이라는 계약이 있다. 새 prompt template은 만들 수 있지만 기존 agent 파일·meta_harness.py·claude_wrapper.py는 수정하지 말라고 한다.

공개 분류 skill은 MemorySystem의 predict, learn_from_batch, get_state, set_state를 규정하고, 지정 LLM wrapper·answer extraction·cold start 조건까지 둔다. 따라서 완전 무제약 프로그램 생성은 아니며 domain별 scaffold와 계약이 search space를 제약한다. 하지만 사람이 완성된 retrieval·reflection 모듈들을 미리 만들어 두고 proposer가 그 조합만 고르는 방식으로 한정되는 것도 아니다.

• 근거: §3, App. D, TB search space·파일 경계, 분류 interface·제약.

Q. Meta-Harness에는 train/validation 구분이 없는가? 무엇을 validation하는가? (2026-10-18)

A. 앞서 예로 든 TerminalBench-2에서는 task 수준의 탐색/최종 평가 split이 없다. 그러나 논문 전체에 데이터 분리가 없는 것은 아니다. 분류·수학은 search set으로 harness를 수정·선택하고 별도의 held-out test로 최종 평가한다. 여기서 statistical validation은 앞서 설명한 import/interface validation과 다른 의미다.

분류에서는 두 수준을 구분해야 한다. Inner loop에서 train examples는 가중치가 아니라 memory/state를 갱신한다. 공개 분류 코드의 offline 경로는 learn_from_batch()에 labeled examples를 넣고, evaluate_memory()는 val/test에 대해 predict를 호출하며 learn_from_batch를 호출하지 않는다. Outer loop에서는 이 val/search 결과를 proposer에게 다시 보여 주어 harness 코드 자체를 수정한다. 따라서 val은 memory를 직접 학습시키지 않지만 harness search에는 적극 사용되는 development data다. 공개 finalize_run()은 탐색을 동결한 뒤 선택된 후보의 test를 평가한다.

💭 해석: Search/val은 outer-loop 관점에서는 최적화 데이터와 후보 선택 데이터를 겸한다. 독립적인 outer-loop train → validation → test의 3분할을 일관되게 운영하는 방법으로 읽으면 안 된다. 가중치가 고정되어 있어도 코드를 반복 수정하면 search 문제에 맞춰질 수 있으므로, held-out 평가의 대상은 harness의 일반화다. TerminalBench-2 결과는 benchmark-specific discovery로 해석해야 하며, 같은 task에서 trial을 늘려 재평가하는 것은 unseen task 평가를 대신하지 않는다.

• 근거: §3 search/test, §4.1, §4.2, §4.3의 같은 89 tasks, 공개 분류 config, train state update, val/test 평가, test finalization.

근거는 공식 repository의 8123ccabe2b19fa1123090b2e5f1bacc20963ce8 commit(2026-10-01)이다. 보관 snapshot 정보. 저장소는 MIT License이며 원본 LICENSE를 함께 보관했다. README는 논문에 쓴 코드의 cleaned-up release이며 실행 여부 외에는 충분히 테스트하지 않았다고 밝힌다. 아래는 공개 배포 코드의 동작을 설명하며, 논문 실험 당시 모든 지시문과 세부 구현이 같았다고 가정하지 않는다. 분석을 위해 코드를 읽었으며 benchmark는 실행하지 않았다.

결론: 자연어 workflow를 받은 coding agent가 실제 tool call을 선택한다

“Proposer가 thinking해서 검색한다”는 말은 무엇을 더 읽을지 LLM이 결정한다는 뜻에서는 맞다. 다만 실행 구조는 task prompt + domain skill + 파일 읽기/검색 도구 + Claude Code의 agent loop다. Model이 Read, Grep, Bash 등을 호출하면 Claude Code가 실행하고 결과를 model context로 돌려준다. 그 결과를 보고 다음 조회나 코드 수정을 선택한다.

검토한 TerminalBench outer loop에는 trajectory embedding을 만드는 별도 retriever나, 실패 원인을 특정 검색식으로 바꾸는 고정 알고리즘이 없다. 상위 수준의 분석 순서와 산출물은 skill이 정하고, 구체적 파일·패턴·조회 범위는 coding agent에게 맡긴다.

Outer loop가 전달하는 것은 전체 로그가 아니라 위치와 과제다

meta_harness.py의 render_task_prompt()는 iteration·model·baseline과 함께 evolution_summary.jsonl, frontier_val.json, reports/, pending_eval.json의 경로를 prompt에 적는다. 이 함수가 모든 trajectory를 읽어 prompt에 합치는 것은 아니다.

실제 관련 코드 발췌:

        f"## Run directories\n"
        f"All logs and results for this run are under `{LOGS_DIR}/`.\n"
        f"- `{LOGS_DIR / 'evolution_summary.jsonl'}` — past results\n"
        f"- `{LOGS_DIR / 'frontier_val.json'}` — frontier\n"
        f"- `{LOGS_DIR / 'reports'}/` — post-eval reports\n"
        f"- Write pending_eval.json to: `{PENDING_EVAL}`"

evolution_summary.jsonl은 단순 reward 배열이 아니다. update_evolution_summary()는 proposer가 제안한 hypothesis, changes와 평가 수치를 함께 보관한다. 이 가설 문장은 base model이 사후 reward를 보고 쓴 reflection을 뜻하지 않는다.

Prompt는 reports 경로도 알려 주지만, 이 경로를 문자열로 전달한다는 사실만으로 TerminalBench outer loop가 자연어 report를 자동 생성한다고 볼 수는 없다.

실제 proposer 호출: LLM 한 번 호출이 아니라 Claude Code session

meta_harness.py의 allowed tools와 propose_claude(). 아래는 실제 코드의 일부를 묶어 보여 준 것으로 실행용 전체 함수가 아니다.

PROPOSER_ALLOWED_TOOLS = [
    "Read", "Glob", "Grep", "Agent", "Write", "Edit", "Bash",
]

result = claude_wrapper.run(
    prompt=task_prompt,
    model="opus",
    allowed_tools=PROPOSER_ALLOWED_TOOLS,
    skills=[str(EVOLVE_DIR / ".claude/skills/meta-harness-terminal-bench-2")],
    cwd=str(EVOLVE_DIR),
    log_dir=str(LOGS_DIR / "claude_sessions"),
    name=f"iter{iteration}",
    timeout_seconds=timeout,
    effort="max",
)

Wrapper는 skill 파일을 읽어 system prompt에 넣고, Claude CLI 명령을 구성한 뒤 subprocess로 실행한다. 따라서 claude_wrapper.run() 한 번 안에서 여러 번의 model 판단과 tool interaction이 가능하다. Tool 실행 engine은 Claude Code이며, Python wrapper의 parse_stream_events()는 실행 내역을 수집·파싱하는 쪽이다.

Skill은 “알아서 해”보다 구체적인 조사 지시를 준다

TerminalBench skill의 Step 1은 다음을 요구한다.

1. Frontier와 evolution summary를 읽는다.
2. jobs/·logs/의 실패한 trajectory와 성공한 trajectory 둘 다 깊게 읽는다.
3. agents/*.py의 implementation을 읽는다.
4. STATE, 검증 가능한 HYPOTHESIS, 구체적 CANDIDATE와 성능·효율 영향 예측을 반환한다.

공개 TerminalBench skill은 분석용 subagent 하나와 구현용 subagent 하나를 순차적으로 사용하도록 지시한다. 분석 subagent는 필요한 기록을 읽고 가설을 반환하며, 구현 subagent에는 그 가설과 변경 지시를 넘긴다. 반면 분류용 skill은 모든 작업을 main session에서 하고 subagent에 위임하지 말라고 지시한다. 즉 delegation 구조도 domain skill에 따라 다르다. 논문의 “single coding-agent proposer”를 공개 구현의 모든 내부 작업이 단일 model call이라는 뜻으로 읽으면 안 된다.

조회 순서의 개념 예시는 다음과 같다. 아래는 이해를 위한 Bash 예시이며, 저자들의 실제 run에서 이 명령을 그대로 실행했다는 기록은 아니다.

# 어떤 후보가 어떤 가설로 어떤 결과를 냈는가?
cat logs/evolution_summary.jsonl
cat logs/frontier_val.json

# 의심한 completion 처리의 코드 위치는 어디인가?
grep -n -E '_pending_completion|task_complete' agents/baseline_kira.py

# 실행 파일의 위치를 찾은 뒤 특정 trial의 trajectory를 읽는다.
# 실제 파일 이름과 읽을 범위는 jobs/를 조사한 결과에 따라 선택한다.

중요한 반복은 조회 → 결과 확인 → 추가로 조사할 가설/위치 결정 → 다시 조회다. grep이라는 명령 이름이 핵심은 아니며, 공개 코드는 native Read·Glob·Grep도 허용한다. 어떤 검색어를 택했는지까지 확인하려면 실제 run의 tool log가 필요하다.

“무슨 정보를 읽었는가”도 다시 기록한다

claude_wrapper.py의 log_session()은 proposer session을 다음 형태로 저장한다.

logs/claude_sessions/<timestamp>_iterN/
├── meta.json          # prompt, model, tokens, files_read, tool_summary 등
├── response.md        # proposer의 text output
├── events.jsonl       # raw stream events
└── tools/
    ├── 001_Read.txt   # tool input과 output
    └── ...

Tool call의 input과 output을 함께 보관하므로 어느 파일을 읽거나 어떤 명령을 실행했는지 나중에 조사할 수 있다. 여기서는 실제 search를 실행하지 않았고 보관한 배포본에 과거 실험 session이 함께 제공된 것도 아니므로, 위 명령 예시를 실제 논문 run의 tool trace로 제시하지 않는다.

앞선 reflection 답변을 공개 코드 기준으로 보완

“Base model의 사후 reflection이 공통 절차인가?”에는 여전히 아니다가 맞다. 하지만 “외부 저장소에는 해석 없는 dry log만 존재하는가?”에는 그렇게 제한하면 부정확하다.

• TerminalBench summary에는 proposer의 hypothesis와 changes가 남는다.
• Proposer session의 text와 tool interaction도 저장된다.
• 특히 분류 skill Step 0은 과거 결과에 report가 없으면 30줄 이하 post-eval report를 쓰라고 요구한다. 무엇을 바꿨는지, 어느 dataset이 왜 개선·회귀했는지, 다음 iteration의 교훈을 적는다.

따라서 공개 구현은 원본 기록을 보존하면서 proposer가 작성한 가설·진단·report도 함께 축적할 수 있다. Summary-only 방법과의 차이는 해석/요약이 전혀 없다는 것이 아니라, 그것만으로 정보를 제한하지 않고 원본을 다시 조사할 수 있다는 점이다. 분류용 learn_from_batch()는 정답·정오·metadata를 memory system에 전달하는 domain별 내부 경로도 제공한다(inner_loop.py); 이것 자체가 base model의 별도 LLM reflection 호출을 강제하지는 않는다.

논문 설명과 공개 release의 경계

공개 TerminalBench prompt는 baseline_kira.py에서 시작하라고 쓰고, skill은 하나의 hypothesis를 담은 1개 후보와 분석/구현 subagent를 요구한다. 분류 skill은 3개 후보와 명시적 prototype·self-critique·report를 요구한다. 논문 본문의 최소 outer-loop 설명이나 분류 2개 후보/iteration과 세부가 다르다. 그러므로 위 파일은 현재 공개 reference 구현의 구체적인 작동 근거로 사용하며, 공개 skill을 논문 당시의 동일한 prompt라고 주장하지 않는다.

코드 발췌 출처: Meta-Harness 공개 저장소, MIT License.