플래너가 이상한 계획을 짜는데 재현이 안 됨. 다들 뭘 저장하고 있음?

데이터 고정과 정확한 렌더링 요청 저장에 동의함. 이런 종류의 디버깅에서 두 가지를 더 추가하겠음:

1. '플래너가 이걸 다시 선택할까?'와 '실행이 똑같이 진행될까?'를 분리하셈. 첫 번째를 위해, 저장된 요청과 기록된 도구 출력을 고정한 채 플래너 호출만 리플레이하고 10번 실행해보셈. 10번 중 2번 나쁜 계획을 선택한다면, 당신은 재현 문제가 아니라 변동성 문제를 겪고 있는 거임. 어떤 상태를 저장해도 결정론적으로 만들 수 없음.

2. 실행과 함께 서브 에이전트 레지스트리를 해시로 로깅하셈. 내가 본 가장 흔한 '재현 불가' 원인은 나쁜 실행과 리플레이 사이에 누군가 서브 에이전트 설명을 수정하는 거였음. 플래너는 텍스트를 보고 선택하니까, 한 줄짜리 설명 변경도 다른 프롬프트가 되는 거임.

꿀팁: 계획이 잘못된 것 같으면, 픽스처로 저장해서 평가 세트에 추가하셈. 몇 주 지나면 당신을 괴롭혔던 바로 그 계획들의 회귀 테스트 세트가 생길 거임.

데이터 버전과 정확한 플래너 입력(렌더링된 메시지, 후보 서브 에이전트 목록/설명, 도구 스키마)을 저장하셈. 그게 없으면 그래프 상태는 그냥 기념품일 뿐임.

내가 실행 하나와 별개로 유지하는 건 다음 세션이 읽어야 할 짧은 기록임: 목표, 결정 + 이유, 거절한 것들. 도구를 바꿀 때 나는 이전 로컬 세션을 Portable Resume으로 불러와서 새 에이전트가 새로운 채팅이 아니라 같은 커밋에서 시작하게 함: https://gitlab.com/aa22396584/resume-skills pipx install portable-resume

데이터 버전도 일부겠지만, 솔직히 나한테 이걸 해결해 준 건 플래너가 받은 정확한 렌더링 프롬프트를 로깅하는 거였음. 템플릿 더하기 상태가 아니라, 서브 에이전트 설명을 포함한 실제 최종 문자열 말이야. 내 멀티 에이전트 설정(Claude와 몇몇 브라우저 사용 워커)에서 나는 서브 에이전트 설명을 계속 수정했는데 플래너도 그걸 읽는다는 걸 깜빡했음. 그래서 예전의 나쁜 계획은 현재 코드로는 재현이 거의 불가능했음. 또한 별칭이 아니라 모델 스냅샷을 고정하고, 검색된 컨텍스트는 그 순간 그대로 저장하셈. 그래도 바이트 단위로 똑같은 리플레이는 안 될 거임. temp 0도 약간의 드리프트가 있으니까. 그래서 나는 계획을 재생성하려고 애쓰는 걸 관두고, 그냥 전체 요청/응답을 저장한 뒤 플래너 이후의 모든 것을 그 기록된 계획에서 리플레이함. 솔직히 디버깅이 훨씬 쉬워졌음.

렌더링된 프롬프트 부분은 생각도 못 했네. 플래너가 잘못된 접근 방식을 골라서 네가 직접 개입해야 했던 실행 건들에 대해서는 뭘 따로 저장해? 아니면 그냥 입력값만 저장함? 나도 입력값은 똑같은데 플랜이 다르게 나오는 경우를 계속 겪고 있거든. 내가 진짜로 다시 보고 싶은 건 데이터가 아니라 추론 과정임. 그리고 궁금한 게 있는데, 플래너를 어디에 돌리는 거야? 너희 자체 서비스야 아니면 클라이언트 작업이야?

리스트에 없는 거 하나 추가하자면: 계획 시점의 서브 에이전트 레지스트리임. 누군가 서브 에이전트를 추가, 이름 변경, 또는 설명을 수정했다면 플래너는 다른 메뉴를 본 거고 '이상한 순서'는 종종 그냥 그 때문임. 렌더링된 플래너 프롬프트를 (도구/서브 에이전트 설명 포함) 그대로 스냅샷 찍고 모델 ID + 파라미터를 저장하셈. 그거랑 데이터 버전이면 보통 리플레이가 될 거임.

맞음, 데이터 버전이 핵심임. 모델 설정이랑 프롬프트 템플릿은 매 실행마다 똑같으니까 나쁜 계획이랑 재현 시도 사이에서 차이가 날 수가 없음. 차이가 나는 건 툴이 뭘 반환했느냐인데, 그건 그 시점에 데이터가 어땠느냐에 따라 결정되는 거임. 모델이 본 그대로의 렌더링된 프롬프트랑 툴의 원본 출력값을 저장해두면, 실제 데이터 건드리지 않고도 나쁜 계획을 그대로 재현할 수 있음.

데이터 버전 말이 맞는 듯. 계획은 입력값의 함수니까, 잘못된 실행이랑 재현 시도 사이에 데이터가 바뀌었으면 그래프를 완벽하게 저장해도 그 잘못된 계획을 다시 만들어낼 수가 없음. 매번 계획이랑 같이 입력값 해시를 저장하는 걸 추천함. 툴 결과는 저장하기 제일 싸고 제일 쓸모없음. 어차피 다시 실행하면 되니까.

더 저장하기 전에 '재현'이 뭘 의미하는지부터 확실히 하는 게 좋을 듯. temperature가 0보다 크거나, 실행할 때마다 배치를 다르게 처리하는 모델 제공자를 쓰면 모든 걸 고정해도 똑같은 계획이 안 나옴. 대신 같은 입력값을 다시 돌려서 계획이 허용 범위 안에 들어오는지 확인하는 게 나음. 그럼 재현 문제에서 평가 문제로 바뀌는 거고, 내부 구조를 모르는 호스팅 모델에서도 계속 쓸 수 있음.

네 리스트에는 없지만 저장해야 할 게 하나 더 있음: 잘못된 플랜 그 자체를 고정해서 저장해두는 거임. 다시 실행할 때, 뭐든 돌리기 전에 새 플랜이랑 옛날 플랜을 비교(diff)해봐. 플랜이 똑같으면, 그 뒤 단계에서 문제가 생기는 건 플래너 탓이 아님. 만약 다르면, 수정해야 할 지점이 실행 과정 내부가 아니라 그 이전 단계(upstream)라는 걸 알 수 있지.