프롬프트에서 활용까지: 처음부터 만드는 코더릿

From Prompt to Harness: Coderlet from Scratch

모델 자체만으로는 프로그래밍 에이전트의 작동 방식을 결정할 수 없습니다. 모델이 무엇을 보고, 어떤 방식으로 액션이 환경에 입력되며, 어떻게 피드백이 반환되고, 그리고 한 실행이 다음 실행에 어떤 영향을 미치는지 등 모든 것은 하니스(harness)가 어떻게 구성되어 있는지에 따라 달라집니다. 일반적으로 최소한의 예제는 모델과 도구 간의 기본적인 상호작용만을 보여주는 반면, 실제 시스템은 이러한 관계를 복잡한 구성 요소와 의존성으로 확장합니다. 본 논문에서는 단일 요청을 컨텍스트 형성, 모델 결정, 환경 액션, 관측값 반환 및 상태 지속이라는 과정을 거치면서, 간결한 하니스 설계를 연구합니다. 모델, 실행 및 상태라는 세 가지 경계는 모델 서비스, 도구 환경 및 영속적인 상태를 연결하며, 요청 수명 주기는 이러한 전환이 발생하는 순서를 결정합니다. 이들은 함께 하니스의 핵심 역할을 보여줍니다: 모델 생성 결과를 환경 액션으로 변환하고, 런타임 피드백을 후속 결정에 반영하며, 상태가 여러 요청을 통해 지속되도록 하는 것입니다. 또한, 이 런타임 구조 위에 하니스(harness)는 지속적인 부트스트래핑을 통해 실행 과정에서 점진적으로 개선될 수 있습니다. 이러한 설계는 https://github.com/lilinxi/Coderlet 에서 실행 가능한 형태로 구현되었습니다.

A model alone does not determine how a programming agent acts. What the model sees, how actions enter the environment, how feedback returns, and how one run affects the next all depend on how the harness is organized. Minimal examples usually show only the basic interaction between a model and tools, while production systems spread these relationships across complex components and dependencies. This paper studies a compact harness design by following a single request through context formation, model decision, environmental action, observation return, and state continuation. Three boundaries---model, execution, and state---connect the model service, tool environment, and persistent state, while the request lifecycle determines the order in which these transitions occur. Together, they show the harness's core role: turning model generations into environmental actions, carrying runtime feedback into later decisions, and allowing state to continue across requests. On top of this runtime structure, a harness can also be gradually refined across runs through continued bootstrapping. The design is realized in the executable artifact https://github.com/lilinxi/Coderlet.