Pi가 에이전트 세션에 트랜잭션 로그를 박아 넣었습니다

에이전트를 3시간째 돌리고 있었습니다. 컨텍스트가 차서 요약을 걸었는데, 그 사이 프로세스가 죽었습니다. 다시 띄웠더니 에이전트는 자기가 뭘 했는지 모릅니다.

10분짜리 작업에서는 안 터지는 문제가, 시간 단위로 넘어가면 전부 터집니다. Pi가 GitHub에 올린 하네스 v2 설계서 233KB가 정확히 이 문제를 겨눕니다.

에이전트 실행을 트랜잭션처럼 기록합니다

Pi 설계 문서가 쓴 핵심 규칙은 한 줄이에요.

도구를 실행하기 전에 먼저 의도 기록(intent record)을 쓰고, 실행이 끝나면 결과를 덧붙인다.

데이터베이스가 쓰기 전에 로그를 먼저 남기는 것과 같은 구조입니다. 프로세스가 도구 실행 도중에 죽어도, 다음 프로세스가 로그를 읽고 이어받아요. Pi 문서 원문은 "every state that a crash can produce is recoverable"라고 적었습니다.

지금 대부분의 에이전트 프레임워크는 이렇게 안 돼요. while 루프 안에 모델과 도구를 넣고, 컨텍스트가 차면 요약하고, 안 죽기를 바라는 구조죠. 10분이면 괜찮지만, 몇 시간이 되면 문제가 전부 터집니다.

병렬 작업을 레인으로 나눕니다

Pi는 한 세션 안에서 여러 작업을 동시에 돌리는 단위를 "레인(lane)"이라고 불러요. 각 레인은 대화 트리 위의 한 위치를 가리키고, 독립적으로 작업을 실행합니다. Pi 문서가 든 예시는 Slack이에요. 채널 하나가 세션이고, 스레드 하나가 레인입니다.

규칙이 명확해요. 레인 하나에는 작업이 최대 하나만 열립니다. 하나의 레인에 작업 두 개가 동시에 열리면 "corruption"이라고 원문에 적혀 있어요. 레인이 각자 독립적으로 멈추고 다시 시작할 수 있어서, 한 레인이 죽어도 다른 레인은 영향을 안 받습니다.

컨텍스트 압축은 하되, 원본은 버리지 않습니다

에이전트가 오래 돌면 컨텍스트 창이 넘쳐요. Pi의 접근은 compaction입니다. 오래된 컨텍스트를 요약 항목으로 교체하되, 원본 대화 트리는 그대로 보존하죠.

원문 규칙을 보면 "It only grows; entries are never changed or deleted."예요. 컨텍스트를 줄여서 모델에 보내는 건 맞지만, 기록 자체를 지우는 게 아닙니다. 필요하면 원본으로 돌아갈 수 있어요.

중국어 해설 트윗(@MaxForAI, 조회 9.9만)에서는 이 구조를 다른 하네스의 컨텍스트 관리와 비교하며 수치를 들었습니다. 컨텍스트 2635% 절감, uncached prefill 7288% 절감이라고 적었는데, 이 수치는 Pi 원문이 아니라 해설자가 옮긴 값이에요. Pi 설계 문서 자체에는 이 벤치마크가 없습니다.

모델과 하네스가 한 몸이 되어 갑니다

해설 트윗이 짚은 관찰 중 흥미로운 게 하나 있어요. 클로드 코드, 딥시크 하네스, 코덱스. 모델마다 자기 하네스가 있고, 모델이 강해질수록 자기 하네스의 도구 형식에 더 깊이 적응한다는 겁니다.

이건 Pi 설계 문서에는 나오지 않는 해설자의 해석이에요. 하지만 방향은 Pi 원문의 설계와 맞닿아 있죠. Pi가 하네스를 데이터베이스 트랜잭션 수준으로 설계하기 시작한 건, 에이전트가 길게 돌수록 모델과 하네스 사이의 계약이 더 단단해야 하기 때문이에요.

에이전트를 10분 돌리는 건 while 루프면 돼요. 50시간을 돌리려면 운영체제가 필요합니다. Pi 하네스 v2는 그 운영체제를 설계하겠다는 문서예요.

뼈대를 고르는 눈을 키우는 순서, 여기 적었습니다.

https://latpeed.com/products/JWpYg?utm_source=threads&utm_medium=post&utm_campaign=PI2

참고

• Pi harness-v2 설계 문서 → https://github.com/earendil-works/pi/blob/harness-v2/j4/packages/agent/docs/harness-v2.md
• @MaxForAI 해설 트윗 → https://x.com/MaxForAI/status/2091056022551187579