당신의 에이전트가 티켓을 생성했다고 말했습니다. 평가(eval)도 통과했습니다. 하지만 티켓은 존재하지 않습니다.

이것은 행동을 수행하는 에이전트(action-taking agents)가 초래하는 실패 모드이자, 출력 등급 평가(output-grading evals)가 그대로 지나쳐 버리는 문제입니다. 에이전트의 업무가 무언가를 말하는 것이라면, 텍스트를 등급 매기는 것이 곧 업무를 평가하는 것입니다. 하지만 에이전트의 업무가 무언가를 하는 것(파일 쓰기, PR 열기, 카드 결제, 이메일 전송 등)이라면, 에이전트가 내뱉는 텍스트는 부수 효과(side effect)에 대한 주장이지, 부수 효과 그 자체가 아닙니다.

부수 효과를 일으키는 에이전트에게 Tier 1은 있으면 좋은 기능이 아닙니다. 그것이 게임의 전부입니다. 대부분의 프로덕션 실패 사례 — API 호출의 500 에러, 쓰기 작업이 읽기 전용 마운트에 발생, 에이전트가 재시도하여 티켓을 두 번 생성함, "전송됨" 상태인 이메일이 반송됨 등 — 는 거의 비용이 들지 않으면서도 결정론적(deterministic)으로, 그리고 실행 경로(hot path) 내에서 실행을 차단할 수 있을 만큼 충분히 빠르게 이곳에서 포착됩니다. Tier 3는 이 중 어떤 것도 할 수 없습니다. Tier 3는 오프라인 전용이며, 사용량에 따라 비용이 발생하고, 비결정론적(non-deterministic)이기 때문입니다. 사용자와 재시도(retry) 사이에 느린 모델의 의견이 끼어드는 상황을 원치 않을 것입니다.

효과를 검증하세요, 주장을 채점하지 마세요

다음은 Tier 1 부수 효과 검증(side-effect check)의 형태입니다. 이것이 무엇을 하지 않는지에 주목하세요. 이 검증은 에이전트가 작성한 발생 상황 요약을 절대 읽지 않습니다.

type EffectCheck<T> = {
  name: string;
  // 독립적으로 세상을 관찰합니다. 에이전트는 이 내용을 작성할 수 없습니다.
...

observe 함수가 핵심입니다. 이 함수는 에이전트가 아니라 GitHub를 호출합니다. 환각(hallucinated)된 이슈 번호는 null을 반환하며, 어떤 판정기(judge)가 호출되기도 전에 Tier 1에서 실패합니다. 이것이 바로 "80%를 출시하는" 방법입니다. 오래된 데이터, 충돌, 잘못된 형태, 그리고 환각된 효과로 인한 실패들이 이곳에서 저렴하게 모두 처리되며, 비용이 발생하는 판정기에게는 오직 진정으로 주관적인 부분 — 이것이 좋은 티켓인가? — 만 남겨집니다. 이는 명백히 라벨링된 '의견'이지 '증거'가 아닙니다.

추적(trace)이 있어야 디버깅이 가능합니다

위의 코드에는 숨겨진 두 번째 문제가 있습니다. verifyEffect가 effect not found를 반환할 때, 왜일까요? 에이전트가 issues.create를 호출했는데 속도 제한(rate-limited)에 걸린 것일까요? 잘못된 엔드포인트를 호출한 것일까요? 올바른 엔드포인트를 호출하여 이슈 #4299와 함께 201 응답을 받았는데, 요약본에는 #4213이라고 환각을 일으킨 것일까요? 합격/불합격(pass/fail) 결과는 세상이 잘못되었다는 것만 알려줄 뿐, 에이전트가 어디서 경로를 이탈했는지는 알려주지 않습니다.

그것이 바로 AgentLens가 필요한 이유입니다. AgentLens는 에이전트가 자신의 주장에 도달하기까지의 **트레이스 (trace)**를 캡처합니다. 즉, 모든 모델 단계(model step)와 도구 호출(tool call), 해결된 입력값(resolved inputs), 그리고 에이전트가 실제로 받은 가공되지 않은 출력값(raw outputs)을 모두 기록합니다. 따라서 Tier 1에서 오류(red)가 발생했을 때, 여러분은 궤적(trajectory)을 다시 재생해 볼 수 있습니다. 예를 들어, issues.create가 number: 4299와 함께 201을 반환했는데 에이전트의 최종 메시지에는 4213이라고 적혀 있다면, 이것이 권한(permissions) 문제가 아니라 요약(summarization) 버그라는 것을 알게 되고 정확한 부분을 수정할 수 있습니다.

하지만 이 결합은 디버깅보다 더 깊은 의미를 갖습니다. Tier 1과 Tier 2는 무언가와 비교하여 점수를 매길 대상이 필요하며, 그 대상은 반드시 에이전트가 작성하지 않은 데이터여야 합니다. 트레이스(trace)가 바로 그것입니다. AgentLens에 담긴 가공되지 않은 201 응답 본문은 위조할 수 없는 지상 실측 데이터(ground truth)입니다. agent-eval은 트레이스에서 실제로 반환된 이슈 번호를 읽어 에이전트가 주장한 값과 비교하며, 이 과정에서 거짓이 즉시 드러납니다. agent-eval은 출력값을 평가하고 게이트(gate) 역할을 수행하며, AgentLens는 그 점수를 디버깅 가능하고 신뢰할 수 있게 만드는 궤적(trajectory)을 캡처합니다. 이 둘은 하나의 루프를 이루는 두 반쪽입니다. 독립적으로 캡처하지 않은 궤적 데이터로는 독립적인 평가(evals)를 수행할 수 없습니다.

규칙

"에이전트가 성공했다고 말했는가?"라고 묻는 것을 멈추십시오. 대신 "세상이 작업 요구 사항에 맞춰 변했는가?"라고 물으십시오. 액션 에이전트(action agents)에게 이 둘은 서로 다른 질문이며, 오직 하나만이 실질적인 지지대 역할을 합니다. Tier 1에서 효과를 검증하고, Tier 2에서 그 형태를 확증하십시오. 그리고 판단(judge)은 취향(taste)이 실제로 중요한 상위 20%의 영역을 위해 남겨두십시오. 이때 하단에 트레이스(trace)가 뒷받침되어야만, 게이트가 붉은색으로 표시되었을 때 어깨를 으쓱하며 넘기는 대신 수정할 지점을 정확히 가리킬 수 있습니다.

에이전트의 요약은 하나의 가설일 뿐입니다. 직접 확인하십시오.