계획 내 각 작업에 전달되는 것과 그렇지 않은 것

A plan은 여러 개의 coding-agent 세션을 순차적으로 또는 동시에 실행합니다. 이들 중 어느 것도 서로 메모리를 공유하지 않습니다. 각각의 세션은 빈 context window로 시작하므로, 지식을 전진시키는 유일한 것은 orchestrator가 전달하기로 결정하는 것입니다. 그 결정은 읽어볼 가치가 있습니다. 왜냐하면 그것이 작업을 지속시키는 작업과 작업을 재발견하게 만드는 작업 사이의 차이이기 때문입니다.

공개: 저는 Ordewell을 구축했기 때문에, 다음 내용은 설문조사라기보다는 실제로 어떻게 작동하는지에 대한 설명입니다. 이것은 무료이며 Apache 2.0 라이선스를 따릅니다. 여러 세션을 실행하는 모든 도구에서 문제의 형태는 동일하므로, 설치하지 않더라도 그 추론 과정은 유용합니다.

문제: 에이전트는 이전 세션에 대해 아무것도 모른다

계획을 대화처럼 상상하기 쉽습니다. 하지만 그렇지 않습니다. Task 2는 새로운 프롬프트와 함께 완전히 새로운 프로세스입니다. Task 1이 코드베이스에 대해 무엇을 배웠든, 어떤 접근 방식을 포기했든, 함수에 이름을 붙였든, 이 모든 것은 작업 디렉터리(working tree)에 작성되거나 명시적으로 반환되지 않는 한 사라집니다.

게으른 해결책은 모든 것을 붙여넣는 것입니다. 이전 모든 작업의 전체 트랜스크립트나 계획을 생성한 대화 내용을 통째로 넣는 방식입니다. 하지만 이것은 당신이 피해를 입기 전까지 알아차리지 못할 방식으로 실패합니다. 상호작용하는 러너(interactive runner)의 트랜스크립트는 주어진 프롬프트를 포함하며, 그 프롬프트에는 감시자(watcher)가 작업을 완료로 표시하기 위해 찾는 토큰이 포함되어 있습니다. 선행 작업의 출력을 종속 작업에 원시 텍스트(raw text) 형태로 전달하면, 세션이 시작되는 순간부터 종속 작업은 선행 작업의 증거를 기반으로 설정될 수 있습니다.

실제로 작업에 전달되는 것

세 가지 블록입니다. 고정된 순서로 배열되어 작업 자체의 프롬프트 위에 배치됩니다. 첫째는 계획 맵(plan map), 다음은 해당 작업이 직접적으로 의존하는 작업들의 출력, 마지막으로 그 작업 자체입니다. 이 세 가지 모두 모델 스스로가 작성한 것이 아니라 계획 상태(plan state)에서 구성됩니다.

계획 맵은 계획에 포함된 작업들을 번호 목록으로 보여주며, 각 작업의 현재 상태, 실행 담당자(runner)가 지정되었다면 그 정보, 그리고 세션이 현재 작업하고 있는 라인에 하나의 마커를 표시합니다:

## Plan map
 1. [done   ] Add the settings model
 2. [NOW    ] Wire the flag into the CLI   ← you are here
...

상태는 저장된 작업 상태에서 읽어오기 때문에, 이 맵은 모델이 재해석할 수 있는 계획이라기보다는 이미 발생한 일에 대한 보고서입니다. 헤더에는 중요한 규칙 하나가 명시되어 있습니다: 이 목록은 문맥(context)을 위한 것이며, 현재로 표시된 작업만 수행하고 뒤따라오는 작업들은 선행하지 않아야 합니다.

직접적인 의존성 및 다른 누구의 결과물들

맵 아래에는 계획 순서대로 해당 작업이 선언한 각 의존성에 대한 블록이 나옵니다. 이 블록들은 구조상 짧습니다: 해당 작업에 대해 기록된 검토 노트와 그 포착된 출력물의 꼬리 부분입니다.

두 가지 세부 사항이 중요합니다. 첫째는 이 '꼬리'가 실제로 꼬리라는 점입니다. 이는 최대 500자로 제한되며, 끝부분에서 가져온 내용으로, 실행 담당자의 최종 요약과 완료 마커가 위치하는 곳입니다. 둘째는 직접적인 의존성만 기여한다는 것입니다. A에 의존하고, 그 A가 B에 의존하는 작업은 B의 출력물이 아니라 A의 출력을 받습니다. 플래너(planner)가 방출한 의존성 그래프 역시 문맥 경계이므로, 작업이 읽어야 하는 양은 실행 길이보다는 그래프의 형태에 따라 증가합니다.

같은 웨이브에서 나란히 실행되는 두 작업은 서로 아무것도 보지 못합니다. 이는 고의적인 것입니다: 설계상 다른 파일을 건드렸기 때문에, 각 작업에게 상대방의 진행 중인 출력을 제공하면 그 작업이 상대방의 작업을 수정하도록 유도할 수 있기 때문입니다.

인용된 완료 마커는 잘못된 작업에 대한 증거가 될 수 있음

대화형 실행 담당자(Interactive runners)는 프롬프트를 터미널로 에코하고, 워처(watcher)는 이 터미널 출력을 읽어 작업을 완료했는지 결정합니다. 따라서 이전 작업으로부터 전달되는 모든 텍스트는 삽입되기 전에 마커가 분리됩니다. 해당 토큰은 스캐너가 받아들이지 않는 하이픈(-) 형태의 형식으로 재작성되며, 그 안에 있던 식별자는 완전히 제거됩니다.

하이픈(-)을 공백(space) 대신 사용하는 것은 단순히 시각적인 문제가 아닙니다. watcher는 또한 터미널의 공백이 제거된 뷰를 읽는데, 이때 공백으로 분리된 토큰은 하나의 살아있는 토큰으로 다시 합쳐집니다. 그리고 누락된 식별자(identifier) 역시 두 번째 이유로 중요합니다. 전사 기록(transcripts)은 이 식별자에 의해 특정 작업에 바인딩되기 때문에, 만약 종속적인 작업이 선행 작업의 전체 토큰을 인용했다면, 종속적인 작업 자체의 전사 기록이 나중에 선행 작업에 대한 질문에 답할 수 있게 됩니다.

동일한 추론은 완성 마커(completion marker) 지침 자체에도 적용됩니다. 이 지침은 모델에게 두 부분으로 주어지며, 조립된 토큰은 프롬프트 내에서 절대 나타나지 않도록 합니다. 따라서 프롬프트를 단순히 반복한다고 해서 실행 초기에 작업을 완료할 수 없습니다.

재개된 세션의 파일 및 경고

작업을 계속하는 것은 다른 경우입니다. 세션은 여전히 원래의 프롬프트를 유지하므로, 프롬프트가 다시 전송되지 않습니다. 바뀐 것은 작업 디렉터리(working directory)입니다. 이 디렉터리는 통합 브랜치(integration branch)로부터 재구성되었기 때문에, 이전 시도의 수정 사항이 존재하려면 그 작업이 실제로 반영되어야 합니다. 계속 진행 알림은 정확히 이 점을 명시하며, 모델에게 파일에 의존하기 전에 확인하도록 지시합니다.

이것이 전체 프로토콜입니다. 전사 기록을 단순히 붙여넣거나, 모델에 의해 요약본을 생성하거나, 조용히 최신 상태에서 벗어나는 메모리 파일을 사용하는 것은 없습니다. 작업 상태(Task state)와 캡처된 출력(captured output)이 인터페이스이며, 작업이 선행 작업에 대해 아는 모든 것은 이를 통해 전달됩니다.

정직한 한계

• 꼬리 부분이 유용한 부분을 놓칠 수 있습니다. 긴 실행 과정의 상단 근처에 출력된 테스트 실패는 마지막 500자 안에 포함되지 않습니다. 리뷰 노트가 이 역할을 하도록 되어 있으며, 그 가치는 작성한 시도 자체에 달려 있습니다.
• 간접적인 종속성은 보이지 않습니다. B의 결과가 A에만 의존하는 작업에 중요하다 하더라도, A가 이를 언급해야만 해당 작업에 도달합니다. 종속성을 선언하는 것이 해결책입니다.
• 맵은 창문과 같습니다. 목록은 현재 작업 주변으로 지난 30개 항목을 잘라내고, 푸터는 제외된 내용을 계산하여 보여줍니다. 설계상 작업이 전체 계획을 볼 수는 없습니다.
• 이는 강제가 아닌 텍스트입니다. 모델은 범위를 유지하라는 지침을 무시할 수 있습니다. 경계는 정보를 제공할 뿐, 복종시키지는 않습니다.
• 무력화(Defusing)는 관례입니다. 이는 마커가 전달되는 컨텍스트에서 벗어나 읽히는 것을 방지합니다. 런너가 자체적으로 유효해 보이는 토큰을 출력할 수 있기 때문에 보안 경계는 아닙니다.
• 캡처된 출력은 이유가 있어서 제한됩니다. 이 상한선(cap)은 선행 작업의 노이즈가 작업 자체의 프롬프트를 압도하는 것을 막아줍니다. 이를 높이면 디테일을 얻는 대신 주의력(attention)을 잃게 됩니다.

소스 및 설계 노트

위에 언급된 모든 내용은 리포지토리 내에 있습니다: promptAugment.ts (구성 순서, 500자 꼬리 부분, 30개 항목 창문 및 그 되돌아보기(look back), 마커 무력화), Task 모델, 그리고 github.com/ordewell/ordewell.