에이전트 벤치마크는 주장하는 대로 작동하는가? 도구 사용 에이전트 환경의 실행 가능한 계약 감사

도구를 사용하는 에이전트는 잘못된 행동이 실제 비용을 초래하는 환경으로 진입하고 있으며, 이를 인증하는 벤치마크는 각 시뮬레이션된 도구 호출이 보고한 내용만을 평가하며, 해당 도구가 인터페이스가 광고하는 대로 작동했다고 가정합니다. 우리가 조사한 감사 분류 체계(audit taxonomies) 중 어느 것도 이러한 가정을 위한 범주를 게시하지 않으며, 점수 아래에 존재하는 결함은 재실행 시마다 나타납니다. 우리는 도구가 광고하는 표면을 실행 가능한 계약(executable contract)으로 간주하고, 구현체를 이에 맞춰 확인하며, 각 점수의 출처를 태스크 파일과 평가자 코드(evaluator code)를 거쳐 상태(state)에서 결함이 있는 도구가 작성했어야 할 판결까지 추적합니다. 네 가지 벤치마크의 34개 감사 대상 변경 가능한 도구(mutating tools) 전반에 걸쳐, 우리는 고정된 커밋(pinned commits) 기준으로 총 7가지 도구 결함과 1가지 평가자 속성(evaluator property)을 확인했습니다. 주입된 결함에 대해 검사기(checker)는 25개의 플래그에서 오탐지(false positive)를 일으키지 않았고, 5개 중 2개의 부정 통제(negative controls)를 플래그 지정했지만, 대부분은 놓쳤습니다. 33개의 점수 기록된 누락 사례 중 29개에서 조항이 결함을 다루었지만 어떤 탐침(probe)도 이를 밝혀내지 못했습니다. 검사기 자체의 정적 분석 부분만 실행해도 17개 확인된 사이트 중 14개를 플래그 지정하므로, 이러한 발견에 대해서는 동적 부분이 발견하기보다는 확인하고 추적합니다. 추가로 AgentDojo 도구 12개(6개의 보류 도구와 앞서 감사한 7개 포함)를 통해 25개 도구의 변경 가능한 표면을 완성했는데, 이 표면에서 최소 5개의 도구가 우리의 계약이 읽는 광고된 표면과 다르게 작동합니다. 이는 AgentDojo 단독으로도 높은 비율입니다. 어떤 골드 트랙토리(gold trajectory)도 tau2-bench 결함을 달성하지 못했으며, 통신 전산망(telecom) 결함을 격리하기 위해 구축된 1,120개의 경로 중에서도 평가자는 정지된 라인의 재충전을 보상하고 수리된 도구를 실패시킵니다. 가장 명확한 사례는 도구가 문서화된 '쓰기 없음(no-write)' 설계 하에서 에이전트에게 각 쓰기가 실행되었다고 알려주지만, 그 인터페이스가 공개하지 않은 경우입니다. 이 평가자는 해당 메시지를 증거로 받아들여, 행동 성공률을 요청이 예상 페이로드(payload)를 가지고 있었는지 여부로 기록할 뿐, 실제로 레코드가 변경되었는지는 기록하지 않습니다.