코딩 에이전트는 도구(Tools) 사용에 서툴다

Hermes, Copilot, Pi, Opencode 등 어떤 에이전트 프레임워크(framework)나 하네스(harness)의 소스 코드를 열어보십시오.
어디에서나 도구(tools)를 발견하게 될 것입니다.

예시:
https://github.com/NousResearch/hermes-agent/tree/main/tools
https://github.com/anomalyco/opencode/tree/dev/packages/opencode/src/tool

이것들은 bash 훅(hooks), 파일 뷰어(file viewers), 파일 에디터(file editors), grep, 질문, 작업, 웹 검색 등입니다.

여러분의 하네스(harness)는 루프(loop)이며, 각 루프마다 이 모든 도구들과 각각의 개별 지침(instructions)들이 컨텍스트(context)에 주입됩니다. 이것이 opencode를 사용한 초기 요청이 아무 이유 없이 10k 토큰(tokens)이나 되는 이유입니다.

우리는 도구(tools)와 관련하여 문제를 겪고 있는가? 네, 아주 많이 겪고 있습니다.

Some(어떤) 도구들은 제대로 작동하지 않으며, 이러한 도구들에는 버그(bugs)가 존재합니다. 어떤 것들은 줄 수를 제대로 세지 못하고, 어떤 것들은 토큰(tokens)을 아끼기 위해 파일을 잘라버립니다(truncate). 어떤 것들은 캐시(cache)를 무효화하여 토큰 대비 비용($) 비율을 악화시킵니다.

Tool(도구) 시그니처(signatures)는 하네스(harness)마다 다릅니다. 그리고 모델(models)은 이 부분에 정말 서툽니다. 세션(session)이 길어질수록 모델은 더 많이 "망각"하며, 이러한 노이즈가 섞인 도구 설명으로부터 주의(attention)를 돌립니다. 하네스(harness)는 파일을 찾는 것과 같은 기본적인 작업에서 실패하기 시작합니다. 성능이 낮은 모델은 끝없는 루프(loops)에 빠져 아무런 출력 없이 여러분의 예산만 축냅니다.

When(모델이) 깨끗한 JavaScript를 작성하는 것과 파일을 보기 위해 일탈적이고 경직된 JSON 페이로드(payload)를 포맷팅하는 것 사이에서 문맥 전환(context-switch)을 강요받게 되면, 모든 것이 무너지거나, 그렇지 않더라도 효율적이지 못합니다.

Models(모델)는 사용 가능한 모든 하네스(harness)에 대해 학습된 것이 아니라, bash와 코딩(coding)에 대해 학습되었습니다. 그것이 모델이 해야 할 일이며, 이것이 Pi가 매우 뛰어난 이유입니다. 하지만 더 나아질 수 있습니다!

실패의 정점은 항상 파일 편집(file editing)에서 나타납니다. 파일을 처음부터 새로 작성하는 것은 순방향으로 흐르는 토큰 스트림(token stream)이기에, 저희가 추측하기로 꽤 쉬운 작업입니다. 하지만 기존 파일을 편집하는 것은 모델이 코드의 추상 구문 트리 (AST, Abstract Syntax Tree)에 대한 정확한 정신적 지도(mental map)를 유지해야 하고, 공백 들여쓰기(white-space indentation, 탭 vs 공백)를 완벽하게 맞춰야 하며, 정확한 라인 차이(line diffs)를 계산해야 합니다.

성능이 낮은 모델이 검색 및 교체(search-and-replace) 편집을 시도할 때, 거의 항상 줄바꿈(newline)이나 마지막 중괄호(trailing brace)를 놓칩니다. 그러면 하네스(harness)가 해당 편집을 거부합니다. 모델은 가공되지 않은 bash 오류나 파서(parser) 오류로 인해 혼란에 빠지고, 파일 내에서 자신의 위치를 놓치며, 완전히 잘못된 라인을 수정하기 시작합니다. 결국 컨텍스트 윈도우(context window)가 쓰레기(garbage)로 가득 찰 때까지 코드베이스를 손상시킵니다. 도구(tools)는 쓰레기를 생성하고 여러분의 컨텍스트를 오염시킵니다. 하네스가 더 많은 도구를 가질수록, 컨텍스트에는 더 많은 무관한 쓰레기가 쌓이게 됩니다.

저희는 이 문제를 해결했다고 생각합니다. 만약 하네스가 다른 코드를 편집하기 위해 코드를 생성한다면 어떨까요? 모델은 이미 그런 작업을 수행하도록 어느 정도 학습되어 있습니다. 그래서 저희는 단 하나의 "도구"인 Elixir Eval만을 가진 하네스를 구축하기로 결정했습니다. 저희는 이를 eeva라고 부릅니다.

Elixir는 모델에게 완벽한 언어입니다. bash와 유사해 보이면서도 bash와 동일한 "파이핑(piping)" 동작을 가지고 있으며, File.ls나 File.read와 같이 매우 유사한 기본 함수들을 제공합니다. 또한 깨끗한 함수형 언어(functional language)이기도 한데, 모델들은 이 분야에 매우 능숙합니다. 모델들은 bash와 Elixir 모두 잘 다룹니다. 이들은 지식과 주의력(attention)을 결합하여 작업을 해결합니다. 모델이 작업을 수행하는 데 실패할 때마다, 하네스는 항상 유사한 형태의 Elixir 에러 트레이스(error traces)를 모델에게 제공합니다.

이것은 작은 변화처럼 보이지만, 게임의 판도를 완전히 바꿉니다. 에이전트가 더 오래 작업할수록, 컨텍스트가 길어질수록, 편집과 작업은 더 정밀해집니다. 무작위 도구들의 잡다한 오류로 컨텍스트를 채우는 대신, Elixir 컴파일 에러를 제공함으로써 모델을 Elixir 환경으로 몰아넣고, 기본적으로 고품질의 출력과 결과물을 통해 실시간으로 "미세 조정(fine-tuning)"하는 효과를 냅니다.

컨텍스트가 커지면 모든 코딩 에이전트는 결국 실패하게 되며, 저희의 에이전트조차 마찬가지입니다. 하지만 이번에는 그 한계치(ceiling)가 훨씬 더 높습니다.

따라서 만약 이 접근 방식을 시도해보고 싶다면, 직접 도전해 보세요: https://github.com/beamcore/agent