AI 에이전트에게는 Ctrl+Z 기능이 없습니다.

스탠퍼드(Stanford) 연구진이 방금 이 기능을 구현했습니다.

모든 에이전트 개발자가 아는 문제입니다:

에이전트가 긴 작업의 10단계 지점에 있습니다. 트레이스백(traceback)을 잘못 읽고, 원래 문제가 없던 파일을 '수정'하며 실행 흐름이 망가집니다.

8단계까지 모든 것이 완벽했습니다.

하지만 이제 당신에게는 정확히 3가지 선택지가 있으며, 모두 좋지 않습니다:

1. 계속 진행하게 둔다 → 에이전트가 스스로 만든 문제에 대한 수정 작업으로 토큰을 소모하며 나선형으로 빠집니다.
2. 수동으로 개입한다 → 이제 '자율적인' 에이전트를 돌보는 역할을 하게 됩니다.
3. 1단계부터 재시작한다 → 모든 모델 호출 비용을 다시 지불해야 하며, 에이전트는 비결정적(non-deterministic)이므로 처음 8단계를 똑같이 되돌릴 수 없습니다.

왜 단순히 8단계로 되감아 갈 수 없을까요?

그 이유는 트래젝토리(trajectory)가 단지 메시지 로그이기 때문입니다. 이는 에이전트가 무슨 말을 했고 어떤 도구를 호출했는지만 기록할 뿐, 그 아래의 실시간 상태(live state)는 기록하지 않습니다.

메모리(Memory). 자식 프로세스(Child processes). 설치된 패키지(Installed packages). 열린 파일 핸들(Open file handles). /tmp. KV 캐시(KV cache).

이 중 어느 것도 로그에는 없습니다.

Git조차도 당신을 구해주지 못합니다. 8단계로 체크아웃하는 것은 파일을 복원하지만, 프로세스는 여전히 콜드 캐시(cold cache)를 가진 채 10단계 메모리에 머물러 있습니다.

Shepherd가 이 문제를 런타임 레이어(runtime layer)에서 해결했습니다.

이는 실행 과정을 타이핑된 이벤트의 트레이스(trace)로 기록합니다. 모든 에이전트-환경 상호작용은 커밋(commit)이 됩니다. Git처럼 작동하지만, 이 커밋은 에이전트 프로세스와 파일 시스템을 함께 캡처하며 Copy-on-write 방식을 사용합니다.

브랜치(branch)는 단순히 파일을 담는 것이 아니라 실제 실시간 상태를 지니고 있습니다.

8단계로 되감기는 것은 단 한 번의 호출입니다. 해당 커밋에서 포크(fork)하여 정확한 상태부터 재개하는 것입니다.

수치는 놀랍습니다:

→ Copy-on-write 포크는 docker commit보다 약 5배 빠릅니다.
→ 8단계까지의 프롬프트 접두사(prompt prefix)가 변경되지 않아, 리플레이 시 KV 캐시의 95% 이상이 재사용됩니다.
→ 초기 단계는 다시 처리되지 않습니다.

그리고 한 번 실행 과정이 포크 가능해지면, 그 위에 메타-에이전트(meta-agent)를 올릴 수 있습니다.

슈퍼바이저(supervisor)가 트레이스를 감시하고 무언가 잘못된 것처럼 보이면 나쁜 쓰기가 일어나기 전에 되돌립니다. 별도의 제어 평면(control plane) 없이, 단순히 Python이 fork, replay, revert를 호출하는 방식입니다.

결과: 두 에이전트가 하나의 코드베이스를 공유하는 CooperBench에서 라이브 슈퍼바이저(live supervisor)를 추가하자 페어 코딩 통과율(pair-coding pass rate)이 28.8%에서 54.7%로 증가했습니다.

거의 두 배에 가깝습니다.

솔직히 할 수 있는 한 가지 주의사항은, 모든 것이 되돌릴 수 있는 것은 아니라는 점입니다.

파일 및 샌드박스(sandbox) 변경 사항은 스스로 취소됩니다. 데이터베이스 쓰기 작업에는 사전에 정의된 일치하는 undo 단계가 필요합니다. 전송된 이메일이나 실제 청구 금액은 되돌릴 수 없으므로, 그 경우 슈퍼바이저는 그것이 발동되기 전에 포착하는 역할을 해야 합니다.

아직 초기 알파(alpha) 버전이며, 가장 큰 성과는 실행 과정이 무거운 샌드박스 상태를 많이 분기할 때 나타납니다. — 바로 여기서 재시작하면 토큰을 가장 많이 낭비하게 됩니다.

Git은 파일 변경 사항을 되돌릴 수 있게 만들었습니다.

Shepherd는 라이브 에이전트 실행에 대해 같은 일을 합니다.

Shepherd Repo: https://t.co/sxUBBWnVBW

(별표 표시하는 것을 잊지 마세요 ⭐)

Shepherd는 실행 내부의 잘못된 단계를 되돌립니다. 하지만 그 주변을 둘러싼 하네스(harness) — 프롬프트, 도구, 검사 항목 — 는 모델과 종속성(dependencies)이 변경됨에 따라 실행마다 계속해서 표류합니다.

Akshay는 이 하네스가 스스로를 복구하도록 만드는 것에 대해 글을 썼습니다. 실패한 추적(trace)은 진단되고, 수정 사항은 정확히 실패했던 입력값과 비교하여 검증되며, 그 실패는 회귀 테스트(regression test)로 고정되어 다시 발생하지 않도록 합니다.

아래에서 읽어보세요 👇