에이전트 마이그레이션 완료. 모든 게이트가 연결된 것처럼 보였지만, 아무것도 작동하지 않았다.

저는 에이전트의 게이트 하네스를 새로운 프레임워크로 마이그레이션하는 작업을 끝냈습니다. 파일들은 디스크에 있었고, 바이트 카운트는 정상이었으며, 마크다운도 렌더링되었습니다. 모든 게이트가 '등록'되었습니다.

그러고 나서 실제로 실행해 보았습니다. 아무것도 작동하지 않았고, 애초에 작동했던 적도 없었습니다.

앞서 한 가지 주의사항을 말씀드리자면, 아래 내용 전체에 걸쳐 중요합니다. 원래 시스템은 사설 데이터로 구동되기 때문에 공유할 수 없습니다. 마지막 문장에서 언급한 주장은 제가 곧 보여드릴 레포지토리의 것이 아니라 _저_의 시스템에 대한 것입니다. 아래 내용은 동일한 실패 체인을 재현하기 위해 제가 구축한 최소한의 재구성에서 나온 것이며, 이는 공개적이고 종속성이 없으며 Python 3.8 이상을 사용합니다.

저는 이미 작동하는 것처럼 보이지만 그렇지 않은 게이트(38개의 게이트, 87% 노이즈)와 모델을 전환하는 순간 작동을 멈추는 게이트(게이트가 모델을 전환할 때까지 완벽하게 작동하다)에 대해 글을 쓴 적이 있습니다. 이것은 두 경우 모두 마이그레이션된 형태이며, 제가 측정하지 않았던 것은 전혀 실행되지 않은 게이트입니다.

간략한 배경 설명

제 에이전트는 다음 두 가지를 관리하는 메모리 인덱스를 유지합니다: 라우트 테이블(어떤 종류의 작업에 대해 어떤 메모리 파일을 읽을지)과 상주 블록(resident blocks)(매 턴 컨텍스트에 주입되는 내용). **게이트(gate)**는 연결 상태가 온전한지 확인하는 작은 스크립트입니다. 예를 들어, 모든 라우트가 존재하는 파일들을 가리키는지 등을 확인합니다.

마이그레이션 후에는 게이트를 실행할 것이라고 예상했습니다. 저는 그들이 등록되었다고 생각했고, 그것이 작동한다는 의미라고 가정했습니다.

재현 과정

python harness/route_gate.before.py   # rc=3  아예 실행되지 않음
python harness/route_gate.py          # rc=2  실행되며 RED를 보고함
python harness/route_gate.fixed.py    # rc=0  실행되며 GREEN을 보고함
...

이 세 파일은 세 개의 게이트가 아닙니다. 이것들은 세 가지 상태의 하나의 게이트입니다: 마이그레이션된 상태, 코드가 절반 수정된 상태, 그리고 완전히 수정된 상태. 마지막 명령어의 출력 결과는 이렇습니다 — 실제로는 게이트당 3줄이지만, 저는 한 줄로 압축했습니다:

등록된 항목은 모두 정상입니다. 컴파일도 성공했습니다. 두 숫자 모두 3이라는 것은 깨끗한 상태를 나타내는 것처럼 보입니다. 하지만 종료 코드(exit codes)는 세 가지 다른 숫자가 나왔습니다. 만약 여러분의 점검이 '등록되고 컴파일되는지'에서 멈춘다면, 이것이 보고서 내용입니다.

겹겹이 쌓인 세 개의 레이어

저는 버그가 하나만 나올 거라고 예상했습니다. 하지만 실제로는 세 개였고, 각각은 이전의 버그를 고친 후에야 비로소 눈에 보였습니다.

레이어 1: 실행되지 않는데 compile()은 정상이라고 말한다

route_gate.before.py는 compile(src, path, "exec")을 깨끗하게 통과합니다. 이름이 누락된 경우(dangling name)는 런타임 오류이며, 어떤 파서도 이를 감지할 수 없습니다. 만약 여러분의 '이 게이트가 실행될 수 있는가?' 검사가 compile()이나 ast.parse라면, 이 파일은 괜찮다고 알려줄 것입니다.

$ python harness/route_gate.before.py
PROBE_FAULT rc=3 -- NameError: name 'AGENT_MEM' is not defined

레이어 2: 해결책이라고 생각한 수정이 절반에 불과하다

AGENT_MEM은 단지 먼저 나오기 때문에 처음 실패합니다. 이것을 정의하면 다음 이름에서 오류가 발생합니다:

PROBE_FAULT rc=3 -- NameError: name 'MEMORY_ROOT' is not defined

오류 메시지는 하나의 문제만 지적합니다. 하지만 파일에는 두 개의 문제가 있었습니다. 첫 번째 실패를 유일한 실패로 간주하는 어떤 프로세스는 여러분을 루프 안에서 두 번이나 돌게 만듭니다. (저는 고치는 과정에서 직접 이 오류에 도달했습니다. 재현하려면 route_gate.py에서 MEMORY_ROOT = ROOT를 삭제하세요.)

레이어 3: 이제 실행되고, 예상치 못한 것을 보고한다

두 이름 모두 정의하면 마침내 실행됩니다:

route_gate — is the route layer actually wired?
target  : <repo>/memory/MEMORY.md
routes  : 3 declared
...

여기서 두 가지가 중요합니다.

cases.md 파일이 누락되었다고 보고됩니다. 하지만 그렇지 않습니다. 이 파일은 memory/cases/cases.md에 존재하지만, 라우트 테이블에서는 순수한 파일 이름으로 이를 지칭하고 있습니다. 파일 자체는 실제이지만, 테이블 정보가 잘못된 것입니다.

그리고 거주 파서(resident parser)는 명백히 두 개의 블록이 있는 파일에서 0개의 블록을 발견했습니다. 따라서 게이트는 스스로 닫힙니다: NONVACUOUS_SECTION은 빈 집합에 대해 평가된 검사에서는 녹색(green)을 주장하기를 거부합니다.

제가 붙잡고 갈 문장입니다. 조용히 판별 기능을 멈춘 게이트는 게이트가 없는 것보다 더 나쁩니다. 왜냐하면 여전히 판결을 출력하기 때문입니다.

녹색(green)으로 가기까지 다섯 가지 변경 사항: 코드 세 가지, 데이터 두 가지

rc=3에서 rc=0까지는 다섯 가지 변화가 있습니다. 먼저 코드를 수정했습니다:

1. 참조되었지만 정의되지 않은 상수 두 개 — AGENT_MEM, MEMORY_ROOT.
2. 거주 파서는 ### N ·을 예상했지만, 대상(target)은 ## <section>에 1. item을 추가합니다.
3. 출처 표시(provenance marks)는 ASCII 전용(=>)였지만, 대상은 ⇒를 사용합니다.

2번과 3번 수정 사항은 다른 옷을 입은 같은 실패입니다: 게이트와 그 대상이 멀어져 갔고, 아무것도 이 변화를 감지하지 못했습니다. 게이트는 충실하게

• n = 1이며, 재구축된 것입니다. 원본은 비공개 데이터로 실행되었기 때문에 공개되지 않습니다. 위에 제시된 모든 숫자는 원래 시스템이 아닌 재생산(reproduction) 레포지토리에서 가져온 것입니다.
• 게이트는 의도적으로 좁습니다: 경로 존재 여부, 출처 표시(provenance marks), 그리고 실패 시 폐쇄되는 자체 점검 기능입니다. 이것은 프레임워크가 아니라 시연(demonstration)입니다.
• 이 레포지토리는 전체 아크(rc=3 → rc=2 → rc=0)를 실행합니다. 제가 원래 시스템에 대한 전/후 숫자를 드릴 수 없는 이유는, 그곳을 수정하는 작업이 아직 진행 중이며, 저는 제가 얻지 못한 숫자를 보고하게 될 것이기 때문입니다.

직접 시도해 보세요

git clone https://github.com/YuhaoLin2005/agent-migrate-demo
cd agent-migrate-demo
python harness/gate_inventory.py

이것을 실행하신다면, 어떤 레이어에서 가장 먼저 걸리는지 알려주시면 좋겠습니다. 제 추측으로는 Layer 1일 것 같습니다. 왜냐하면 제가 본 거의 모든