어떤 모델이든 Elpis에 넣으면 Elpis가 됩니다

저는 단 하나의 아이디어를 중심으로 구축된 오픈 소스 터미널 에이전트 셸(terminal agent shell)인 Elpis를 방금 출시했습니다:

어떤 모델을 Elpis에 넣든, 그것은 Elpis가 됩니다.

모델이 에이전트 그 자체(be)가 되어서는 안 됩니다.

에이전트를 실제로 정의하는 요소들, 즉 목표(goal), 컨텍스트(context), 메모리(memory), 규칙(rules), 증거(evidence), 그리고 작업 상태(working state)를 유지하면서 모델과 제공자(provider) 사이를 자유롭게 이동할 수 있어야 합니다.

그것이 바로 Elpis가 시도하려는 것입니다.

GitHub: https://github.com/MasihMoafi/Elpis

장시간 실행되는 코딩 에이전트의 문제점

코딩 에이전트(Coding agents)는 세션 초기에는 매우 유용합니다.

하지만 세션이 길어집니다.

에이전트는 파일을 읽고, 명령어를 실행하고, 로그를 조사하며, 실패한 시도를 반복하고, 다시 시도하고, 패치(patch)를 생성하며, 수천 토큰(tokens)에 달하는 중간 작업 내용을 축적합니다.

결국 유용한 상태(state)는 히스토리(history) 속에 파묻히게 됩니다.

모델은 단순히 이전에 무언가가 발생했다는 이유만으로, 그것이 여전히 중요해서가 아니라 점점 더 커지는 트랜스크립트(transcript)를 받게 됩니다.

그러면 압축(compaction) 단계가 오거나,

새로운 세션이 시작되거나,

혹은 다른 모델을 사용하기로 결정하게 됩니다.

갑자기 당신이 무엇을 하고 있었는지 이해하던 에이전트는 더 이상 존재하지 않게 됩니다.

당신은 프로젝트를 다시 설명해야 합니다.

결정 사항들을 다시 설명해야 합니다.

무엇이 작동했고 무엇이 실패했는지 다시 알려주어야 합니다.

저에게 이것은 역행하는 것처럼 느껴졌습니다.

컨텍스트는 축적되는 것이 아니라 관리되어야 합니다

Elpis는 컨텍스트(context)를 계속해서 커지는 대화가 아닌, 관리되는 리소스(managed resource)로 취급합니다.

작업이 완료된 후에는 명령어 덤프(command dumps), 파일 읽기, 실패한 조사(failed probes)와 같은 대규모의 일시적인 출력물들을 향후 모든 모델 요청에 포함하여 유지할 필요가 없습니다.

Elpis는 정확한 근거(evidence)를 사용할 수 있는 상태로 유지하면서, 오래된 일시적 자료들을 압축된 표현(compact representations)으로 대체할 수 있습니다.

중요한 차이점은 다음과 같습니다:

모델의 작업 컨텍스트(working context)에서 무언가를 제거하는 것은 그것을 삭제하는 것과 같지 않습니다.

트랜스크립트와 아티팩트(artifacts)는 여전히 사용할 수 있는 상태로 남아 있습니다.

단지 기본적으로 활성 컨텍스트 윈도우(active context window)를 점유하지 않을 뿐입니다.

모델이 무엇을 보는지 확인할 수 있어야 합니다

현재의 에이전트(agent)들에 대해 제가 신경 쓰이는 점 중 하나는 컨텍스트(context)가 얼마나 불투명해지는가 하는 점입니다.

컨텍스트 윈도우(context window)가 있다는 것은 알고 있습니다.

정보가 추가되거나 제거되고 있다는 것도 알고 있습니다.

하지만 정확히 다음 요청(request)에는 무엇이 포함될까요?

Elpis는 이를 위해 **컨텍스트 장부 (Context Ledger)**를 가지고 있습니다.

목표(goals), 체크포인트(checkpoints), 규칙 파일(rule files), 추가된 파일(added files), 그리고 기타 수용된 소스(admitted sources)들이 개별적으로 시각화됩니다.

이 아이디어의 핵심은 컨텍스트가 에이전트 뒤에 숨겨진 보이지 않는 상태(invisible state)가 아니라, 사용자가 검사하고 추론할 수 있는 대상이 되어야 한다는 것입니다.

세션은 모든 것을 재현하지 않고도 연속성을 가져야 합니다

Elpis는 작업의 영구적인 상태(durable state)를 트랜스크립트(transcript)와 분리합니다.

현재의 목표는 GOAL.md에 저장됩니다.

가벼운 실행 체크포인트(execution checkpoint)는 ES.md에 저장됩니다.

이는 세션이 다음과 같은 압축된 표현(compact representation)으로부터 계속될 수 있음을 의미합니다:

• 우리가 달성하려는 것,
• 이미 일어난 일,
• 중요한 결정 및 제약 조건(constraints),
• 마지막으로 검증된 결과,
• 그리고 다음의 유용한 행동.

해당 상태를 재구성하기 위해 대화 전체를 다시 재생(replay)할 필요가 없습니다.

필요한 경우 여전히 정확한 네이티브 스레드(native thread)를 재개할 수 있습니다.

하지만 가벼운 연속(lean continuation)을 시작할 수도 있습니다.

메모리는 자격을 갖추어야 합니다

저는 또한

Elpis는 주변의 연속성 (continuity)을 소유합니다.

따라서 오늘은 Codex를 사용하고, 내일은 다른 제공업체를 사용하거나, 궁극적으로는 로컬 모델을 사용할 수도 있습니다.

기저의 지능 (underlying intelligence)은 변합니다.

하지만 에이전트 (agent)가 처음부터 다시 시작할 필요는 없습니다.

그의 목표는 여전히 존재합니다.

그의 메모리 (memory)는 여전히 존재합니다.

그의 컨텍스트 규칙 (context rules)은 여전히 존재합니다.

그의 증거 (evidence)는 여전히 존재합니다.

그의 작업 상태 (working state)는 여전히 존재합니다.

어떤 모델이든 Elpis에 넣으면 Elpis가 됩니다.

왜 Rust이며, 왜 Codex인가?

Elpis는 주로 Rust로 작성되었으며, 그 실행 기반은 OpenAI의 Apache-2.0 Codex CLI를 의도적으로 축소하여 포크 (fork)한 것에서 비롯되었습니다.

이를 통해 터미널 상호작용, 패치 (patches), 권한 (permissions), 샌드박싱 (sandboxing), 세션 (sessions) 및 명령 실행 (command execution)을 위한 이미 견고해진 기반을 프로젝트에 제공할 수 있었습니다.

저는 코딩 에이전트 실행 환경을 처음부터 다시 구축하는 대신, 그 기반을 중심으로 Elpis 제어 계층 (control layer)을 구축해 왔습니다.

목표는 하나의 API를 감싸는 또 다른 스킨 (skin)을 만드는 것이 아닙니다.

목표는 주변의 에이전트를 지속 가능하고, 검사 가능하며, 하단에 어떤 모델이 있든 상관없이 점점 더 독립적으로 만드는 것입니다.

첫 번째 릴리스

아직 초기 단계입니다.

컨텍스트 관리 시스템 (context-management system) 중에는 특히 턴 이후 가지치기 (post-turn pruning)와 각 턴 이후 저장된 컨텍스트 양을 직접 확인할 수 있게 만드는 등, 훨씬 더 발전시키고 싶은 부분들이 있습니다.

하지만 이제 아키텍처 (architecture)가 충분히 존재하므로, 이를 릴리스하여 저 이외의 다른 사람들에게도 이 모델이 의미가 있는지 확인하고 싶었습니다.

Elpis는 오픈 소스이며 MIT 라이선스를 따릅니다.

현재 주요 타겟은 Linux x86_64입니다.

체크아웃 방법:

git clone https://github.com/MasihMoafi/Elpis.git
cd Elpis
scripts/install-elpis.sh

만약 긴 세션 동안 코딩 에이전트 (coding agents)를 사용하고 계신다면, 특히 다음 사항이 궁금합니다:

**에이전트 (agent)**와 **모델 런타임 (model runtime)**을 분리하는 것이 여러분에게 의미가 있습니까?

그리고 에이전트의 컨텍스트 (context)에 들어가는 내용에 대해 실제로 어느 정도의 제어권을 원하십니까?

GitHub: https://github.com/MasihMoafi/Elpis