세션 발견: 대화가 접근 불가능해지고, 유령 및 중복 프로젝트 항목이 생김

주요 에이전트 CLI의 공개 이슈 트래커는 '내 에이전트가 무엇을 잊었는지'를 실제 환경에서 읽어보기 가장 좋은 곳입니다. 가장 상세한 보고서 중 하나는 다음과 같은 제목으로 작성되었습니다:

cover

세션 발견: 대화가 접근 불가능해지고, 유령 및 중복 프로젝트 항목이 생김

보고자는 약 10개의 활성 대화를 사용합니다. 문제는 모델의 성능이 약해졌다는 것이 아닙니다. 대화 자체가 주소 지정(addressable)할 수 없게 되었다는 것입니다. 일부 대화는 아예 열 수 없고, 프로젝트 목록에는 유령 항목과 동일한 프로젝트의 중복 항목이 생겨서 돌아가야 할 명확한 장소가 없습니다.

두 개의 관련 보고서는 서로 다른 각도에서 같은 종류의 실패를 설명합니다:

• 특정 기능 요청은 대규모 또는 오래된 세션을 재개할 때 새 대화를 시작하도록 CLI에 제안해 달라고 요구합니다. 왜냐하면 이를 재개하는 과정이 더 이상 작업을 설명하지 않는 컨텍스트를 끌어오기 때문입니다.
• 두 번째 버그 보고서는 에이전트가 하나의 채널을 처리할 때, 자신이 제공하는 다른 채널을 들여다보지 않고도 해당 채널의 형제 스레드를 회상할 수 있는 대화 범위별 가시성을 요청합니다.

이들 중 어느 것도 좁은 의미에서의 회상 품질 문제가 아닙니다. 이것들은 저장 및 주소 지정 문제입니다(storage and addressing problems). 그리고 이 문제들은 모든 것의 근간에 놓여 있습니다.

두 가지 반사 작용 배제하기

프롬프트 재작성으로는 해결되지 않습니다. 프롬프트는 입력일 뿐, 저장소가 아닙니다. 그것은 인덱스도 없고, 소스 포인터도 없으며, 세션이 지난 후 주소 지정할 수 있는 곳도 없습니다. 만약 필요한 것이 어딘가에 기록되어 주소 지정 가능하게 작성된 적이 없다면, 아무리 시스템 프롬프트 엔지니어링을 해도 그것을 되돌릴 수 없습니다.

더 큰 컨텍스트 창(context window)도 이 문제를 해결하지 못합니다. 단지 벽을 옮길 뿐입니다. 압축(Compaction)은 여전히 자체 스케줄에 따라 실행되며, 그 순간 영구적으로 저장되지 않은 모든 것은 사라집니다. 이것은 가설이 아닙니다. 같은 트래커의 또 다른 보고서에는 프롬프트 캐시가 만료되기 전에 유휴 세션이 압축되었고, 거부 옵션 없이 이루어졌으며, 마치 수동 작업이었던 것처럼 기록되었다고 설명되어 있습니다.

공통 분모는 전사본(transcript)과 모델 사이에 누락된 계층입니다. 즉, 사실을 기록하고, 각각에 주소를 부여하며, 다른 세션에서 다시 찾을 수 있는 무언가입니다.

네 가지 쓰기 시간 규칙 (Four write-time rules)

이것들은 제가 Windows용 에이전트의 로컬 우선 메모리 계층인 HyperMarrow에 적용하게 된 규칙들입니다. 이 규칙들은 실패 사례들이 쿼리 시점(query time)이 아닌 쓰기 시점(write time)에 결정되기 때문에, 작동하는 순서대로 배열했습니다.

1. 압축하기 전에 기록하라 (Write before you compact). 선호도, 결정 또는 결론은 요약하거나 작업 컨텍스트를 삭제하도록 허용되기 전에 출처와 타임스탬프가 있는 영구적인 로컬 저장소에 도달해야 합니다. 유휴 압축 보고서는 반례를 통해 이 규칙을 주장합니다. 일단 영구 복사본이 존재하면, 요약기는 단일 실패 지점에서 편리함으로 바뀝니다.

2. 메모리가 어떤 종류인지 쓰기 시점에 결정하라 (Decide at write time what kind of memory it is). 명시된 선호도는 문언 그대로 살아남아야 하며; 결론은 영구적이지만 다시 쓸 수 있고; 일상적인 잡담은 노이즈입니다. 나중에 분류하는 것은 너무 늦습니다. 왜냐하면 원래의 표현 방식은 이미 폐기되었기 때문입니다. 실제로는 하나의 구별되지 않은 벡터 풀(undifferentiated pool of vectors)이 아니라, 세 가지 보관 정책을 가진 세 개의 버킷으로 구성되어야 합니다.

3. 검색(Recall)은 당신의 요약본이 아닌 단어를 되돌려준다 (Recall returns your words, not a summary of your words). 저장된 것이 이미 손실성이 있었다면, 사용 가능한 최고의 랭커(ranker)도 실제로 필요했던 문장을 복구할 수 없습니다. 이것이 규칙 2가 검색 조정보다 더 중요한 이유입니다. 검색 품질은 쓰기 품질에 의해 제한되기 때문입니다.

4. 망각은 스케줄링되고 제한적이며, 고정된(pinned) 기록은 절대 사라지지 않습니다. 무한한 메모리는 기능이 아닙니다. 관련성이 떨어지는 세션은 영원히 유지되는 대신 스케줄에 따라 만료되어야 하며, 명시적으로 고정한 기록만 예외입니다. 위에서 언급된 오래된 세션 요청은 바로 이 점을 한 단계 높은 수준에서 요구하는 사용자 니즈입니다.

전체 시스템에 걸쳐 두 가지 제약 사항이 작동합니다. 첫째, 메모리는 기본적으로 로컬이며, 둘째, 개인 정보 보호 경계(privacy boundary)는 약속이 아니라 설정입니다. 기록이 어디에 저장되고, 주어진 기록이 기기를 벗어날 수 있는지 여부는 정책 문단이 아닌 구성 결정 문제입니다.

보고된 증상과 규칙 매핑하기

• 대화가 접근 불가능해집니다. 각 세션은 스크롤백이나 CLI 자체의 세션 목록에 의존하지 않는 주소값을 가진 안정적인 로컬 기록을 갖게 됩니다. 검색(Recall)이 저장소에 직접 질의합니다.
• 유령 및 중복 프로젝트 항목. 프로젝트 항목은 별도로 누적되는 것이 아니라 저장된 기록으로부터 파생되므로, 목록이 실제 존재하는 것과 동떨어질 수 없습니다.
• 크거나 오래된 세션 재개. 검색(Retrieval) 범위가 지정되고 순위가 매겨지기 때문에, 재개한다는 것이 모든 것을 다시 주입하는 것을 의미하지 않습니다. 오래된 기록은 스케줄에 따라 만료되며, 고정된 기록은 그렇지 않습니다.
• 대화 범위별 가시성. 범위(Scope)는 기록의 속성이므로, 검색(Recall)을 다른 내용을 노출하지 않으면서 특정 채널의 스레드로 제한할 수 있습니다.

이 모듈들은 record, recall, consolidation 및 file-bridge가 있으며 MCP를 통해 노출되므로, 에이전트가 도구별 맞춤형 통합을 할 필요가 없습니다.

여전히 잘못된 점

위의 보고 내용은 타당한 비판이므로, 한계를 명확히 밝힐 가치가 있습니다:

여전히 잘못된 점

위의 보고 내용은 타당한 비판이므로, 한계를 명확히 밝힐 가치가 있습니다:

• 하이브리드 랭킹(Hybrid ranking)은 정말 어렵습니다. 긴 기록에 대한 짧은 질의가 제가 바라는 것보다 더 자주 실패하며, 인용된 문장이 항상 그것을 패러프레이징한 내용보다 높은 순위를 차지하는 것은 아닙니다.
• 세션 주소 지정(Session addressing)은 호스트가 제공하는 세션 식별자(session identifiers)만큼만 좋을 수 있습니다. 만약 CLI가 이를 이름 변경하거나 재활용한다면, 메모리 계층(memory layer)은 이를 조정해야 하며, 이 조정 과정이 잘못될 수 있습니다.
• 메모리 종류를 분류하기 위해 모델에 의존하는 모든 것은 어느 정도의 비율로 오분류할 것입니다. 이는 데이터를 잃는 것보다 더 조용하게 실패하지만, 여전히 실패합니다.

이제 당신 차례입니다

여러 세션에 걸쳐 에이전트(agents)를 실행한다면: 무엇을 계속해서 재설정해야 합니까? 그리고 만약 이러한 보고서를 작성했다면, 이 모델이 당신이 본 것과 여전히 일치하지 않는 부분이 어디인지 듣고 싶습니다.

HyperMarrow는 Windows 데스크톱 메모리 계층입니다. 로컬 우선(local-first) 빌드는 여기에서 확인할 수 있습니다: HyperMarrow

공개 고지: 제가 HyperMarrow를 제작했으므로, 이 점을 염두에 두고 위 내용을 읽어주세요. 여기에 인용된 문제 보고서는 실제적이고 공개적인 것이며, 본 게시물을 위해 어떤 숫자, 사용자 수 또는 추천사도 꾸며내지 않았습니다.