코딩 에이전트 하네스 176개 설정 실험, 컨텍스트 관리 이득은 대부분 오버플로 방지에서 나와

PDF 다 안 봤는데 지금까지 읽은 걸로는, 차 A가 차 B보다 빠르다고 그게 꼭 엔진 때문은 아니잖아. 타이어일 수도 기어박스일 수도 있고. 같은 모델로도 ReAct 루프로 짜든 plan-and-execute로 짜든 결과가 달라진다는 얘기지.

결론 보면 계획은 약한 모델엔 성공률 올려주고 강한 모델엔 비용 줄여준다는데, 솔직히 다 뻔한 소리 같음. bash 잘하는 모델한테 bash 전용 도구가 좋다는 것도 그렇고.

뻔해 보여도 모델별로 뭘 잘하는지 목록을 만들고 거기에 맞춰 하네스를 고르자는 거잖아. llm 레시피북 같은 거. 로컬 모델은 실행 방식이 더 중요하고.

뻔한 걸 실험으로 확인하는 게 과학임. 가정을 줄여주는 것만으로도 가치가 있음.

하네스랑 모델을 같은 랩에서 만든 걸 쓰면 훨씬 좋다는 말엔 동의 못 함. 최근 벤치마크에서 pi agent가 claude, codex 네이티브 하네스랑 성능 차이 없었고 작업당 비용은 더 쌌음.

bash 전용 결론을 잘못 읽은 것 같은데. bash 잘하는 모델 + bash 전용 도구가 bash 잘하는 모델 + 사전 정의 도구보다 낫다는 거임. MCP는 모델이 bash를 잘하게 되면서 사실상 쓸모없어진 거고.

Anthropic도 같은 결론인 듯. Opus 4.8, Sonnet 5, Fable 5, Mythos 5부터 TodoWrite 같은 도구가 빠졌고 CLAUDE_CODE_ENABLE_TODO_TOOLS=1로 되살리는 걸로 바뀌었음.

근데 이 연구 Nemotron + Mistral로만 했잖아. 지금 프론티어인 qwen, deepseek이나 Claude, GPT는 안 넣었으니 별로 상관없는 얘기 아님?

모델 선택은 상관없음. 하네스 접근법이 모델 크기별로 어떻게 작동하는지가 초점이니까. 최신 모델이면 다르다는 주장에는 근거가 있어야 함.

논문에 'bash capable'이 뭔지 정의가 없음. Luna도 bash 잘할 텐데, 그럼 Bash 말고 도구를 더 붙이려면 값어치가 있는지 제대로 검증해야 함.

그건 그냥 토큰 스트림에서 셸 명령 문자열 뽑아 프로세스 띄우는 파서가 있냐는 뜻 아닌가. 모델이 bash를 잘 쓰면 굳이 전용 도구 안 붙여도 된다는 거고, RAG랑 비슷한 결론임.

mini-swe-agent 만든 사람인데, 하네스에 대한 원칙적인 연구는 더 필요함. 복잡한 하네스가 아주 단순한 에이전트를 일관되게 이기는 벤치마크가 별로 없음. 내 건 100줄로 시작했고 TB3 랭킹 상위에 있음.