APX Session Compact: 긴 스레드를 지속 가능한 아티팩트(Artifact)로 변환

APC는 휴대 가능한 컨텍스트(Context) 계층입니다. APX는 해당 컨텍스트를 일상적으로 유용하게 만드는 런타임(Runtime) 및 툴링(Tooling) 계층입니다. apx session compact는 바로 그 경계에 위치합니다. 이는 긴 대화를 가져와 나중에 계속 사용할 수 있는 무언가로 변환합니다.

이것이 중요한 부분입니다. 가공되지 않은 전사(Transcript)는 좋은 장기적 아티팩트(Artifact)가 아닙니다. 너무 노이즈가 많고, 너무 세부적이며, 정신적으로 다시 열어보기에는 비용이 너무 많이 듭니다. 압축된 세션(Compacted session)은 다릅니다. 이는 턴(Turn)별 잡동사니를 제거하면서 작업의 유용한 형태를 유지합니다.

Compact의 용도

APX는 세션(Session)을 에이전트 호출(Agent invocation) 또는 작업 스레드(Work thread)의 지속 가능한 기록으로 취급합니다. 대화(Conversations)는 가공되지 않은 로그(Log)입니다. 세션(Sessions)은 당신이 다시 돌아오게 되는 대상입니다. apx session compact <slug>는 대화 측면을 디스크 상의 더 짧고 읽기 쉬운 요약본으로 축소하기 위해 존재합니다.

이로 인해 compact는 일기 도구가 아닌 복구 도구(Recovery tool)가 됩니다.

빠른 파악(Orientation)만 필요하다면 apx session summary <id>로 충분합니다. 만약 긴 세션의 결과를 보존하여 전체 전사(Transcript)를 다시 읽지 않고도 나중에 다시 열 수 있기를 원한다면, compact가 올바른 선택입니다.

분리가 중요한 이유

모든 에이전트 출력이 하나의 거대한 로그에 담겨야 한다고 생각한다면 이 분리를 놓치기 쉽습니다. 그것은 단순해 보이지만 금방 무너집니다.

• 로그(Logs)는 추적성(Traceability)에 좋습니다.
• 요약(Summaries)은 파악(Orientation)에 좋습니다.
• 압축된 요약(Compact summaries)은 지속 가능한 인수인계(Durable handoff)에 좋습니다.
• APC 메모리는 안정적인 프로젝트 사실(Project facts)에 좋습니다.

APX는 모든 대화를 프로젝트의 진실(Project truth)로 바꾸려고 시도해서는 안 됩니다. 그 역할은 APC의 몫입니다. APX는 라이브 런타임(Live runtime)을 제한된 범위 내로 유지하고, 완료된 작업이 저장하기 쉽도록 만들어야 합니다.

따라서 규칙은 지루하지만 유용합니다:

1. 작업이 활성화되어 있는 동안에는 가공되지 않은 턴 기록(Raw turn history)을 유지합니다.
2. 스레드가 보존할 수 있을 만큼 충분히 완료되면 압축(Compact)합니다.
3. 안정적인 사실(Stable facts)만을 APC 메모리나 문서로 이동합니다.

이렇게 하면 에이전트 워크플로우(Agent workflows)에서 흔히 발생하는 실수 중 하나인, 일시적인 채팅 노이즈를 영구적인 프로젝트 컨텍스트(Project context)로 격상시키는 문제를 방지할 수 있습니다.

실용적인 워크플로우 (A practical workflow)

에이전트(Agent)가 버그를 검토하고, 로그를 확인하고, 두 가지 수정 사항을 시도한 뒤, 마침내 깔끔한 답변을 도출해낸 세션을 상상해 보십시오. 해당 트랜스크립트(Transcript)는 감사(Audit) 용도로는 유용할 수 있지만, 일상적인 읽기 용도로는 적합하지 않습니다.

워크플로우는 간단해집니다:

apx session summary <id>
apx session compact reviewer --conversation <id>

첫 번째로 읽고, 두 번째로 압축(Compact)하십시오.

첫 번째 명령은 요점을 제공합니다. 두 번째 명령은 유용한 결과물이 더 작은 아티팩트(Artifact)로서 살아남도록 보장합니다. 그 이후에는 세션을 다시 살펴보기가 더 쉬워지며, 다음 작업자는 모든 잘못된 시작(False start) 과정을 다시 재생할 필요가 없습니다.

압축하지 말아야 할 때 (When not to compact)

너무 일찍 압축하지 마십시오.

스레드(Thread)가 여전히 변하고 있다면, 압축하는 것은 유용한 컨텍스트(Context)를 숨기는 것에 불과합니다. 이는 특히 코드를 편집 중이거나, 도구(Tool)의 결과를 기다리거나, 두 가지 접근 방식 사이에서 결정 중일 때 더욱 그러합니다. 그러한 경우에는 가공되지 않은 대화(Raw conversation)가 여전히 올바른 소스입니다.

대화가 탐색(Exploration) 단계에서 기록 보관(Record-keeping) 단계로 넘어갔을 때 압축하십시오. 좋은 신호는 다음과 같습니다:

• 결정이 충분히 확정적이다.
• 다음 단계가 현재 스레드 외부의 일이다.
• 또 다른 주고받기(Back-and-forth)가 아닌 핸드오프(Handoff)를 원한다.
• 트랜스크립트가 너무 길어서 다시 여는 것이 시간을 낭비하게 만든다.

APC는 휴대성을 유지하고, APX는 로컬 상태를 유지합니다 (APC stays portable, APX stays local)

이것이 이 명령어가 중요한 더 깊은 이유입니다.

APC는 프로젝트 컨텍스트(Project context)를 저장소(Repo) 내에서 휴대 가능하게 유지합니다. APX는 런타임 상태(Runtime state)를 머신(Machine)에 로컬로 유지합니다. apx session compact는 APX가 자신의 역할을 잘 수행하도록 돕습니다. 즉, 전체 트랜스크립트가 프로젝트 계약(Project contract)에 속하는 것처럼 가장하지 않으면서도 유용한 결과물을 보존하는 것입니다.

이러한 경계는 건강합니다. APC는 작고 검토 가능한 상태를 유지합니다. APX는 그래야 할 곳에서 유연하고 폐기 가능한(Disposable) 상태를 유지합니다. 압축된 세션은 그 중간에 위치합니다. 중요할 만큼 내구성이 있으면서도, 정직함을 유지할 만큼 로컬에 머뭅니다.

결론 (Bottom line)

apx session compact는 모든 것을 아카이빙(Archiving)하는 것에 관한 것이 아닙니다.

그것은 하나의 완료된 스레드(thread)를 재사용 가능한 아티팩트(artifact)로 변환하는 것에 관한 것입니다. 방향을 잡기 위해서는 session summary를 사용하세요. 결과를 보존하려면 session compact를 사용하세요. 프로젝트와 함께 이동해야 하는 사실(facts)에는 APC 메모리를 사용하세요.

이것이 시스템의 가독성을 유지하는 분리 방식입니다: 휴대 가능한 컨텍스트(context)를 위한 APC, 일상적인 런타임(runtime)을 위한 APX, 그리고 그 사이의 핸드오프(handoff)를 위한 compact입니다.