구현했지만 한 번도 보지 못한 패턴

Clew는 세 가지 낭비 패턴에 대한 디텍터를 제공합니다. repeat_node, pingpong, requery_known입니다. 앞의 둘은 구조적인 것이고, 셋째는 첫째의 특수한 경우로서 공유 코드 경로를 통해 탐지됩니다.

pingpong 디텍터는 특정한 구조적 모티프를 찾습니다. 두 에이전트가 어느 쪽도 새로운 상태를 만들지 않은 채 번갈아 도는 것입니다. A → B → A → B이고, 네 span이 모두 LLM span으로 분류되며, 엄밀히 인접한 이벤트로 일어나고, A ≠ B여야 합니다. 멀티에이전트 supervisor/worker 라우터에서 흔한 실패 양상을 겨냥한 것으로, 조정자와 전문가가 새 문맥이 쌓이지 않는 채 제어권을 주고받는 상황입니다.

정의는 정밀하도록 골랐습니다. 인접성, 에이전트 간 동일성, LLM span 타입, 이 셋이 함께 패턴을 충분히 좁혀서 매치가 무언가를 뜻하도록 했습니다.

디텍터를 실제 트레이스 코퍼스 세 곳에 돌렸습니다. Claude Code 세션(tool span 6,780개), Toolathlon 트래젝토리(tool span 176,270개), RedundancyBench(tool span 1,628개)입니다. pingpong은 셋 모두에서 0회 발동했습니다.

이 패턴은 합성 평가에는 기여합니다. 보고된 F1 0.857은 디텍터 셋 전부를 포함하고 pingpong도 그중 하나입니다. 다만 그 pingpong 성분은 오직 합성 트레이스 생성기(pingpong_aba.py)를 통해서만 발동하는데, 그 생성기는 트레이스를 직접 구성하면서 span_kind="llm"을 명시적으로 부여합니다. 실제 트레이스에서 관측된 발동은 0건입니다.

구현했다는 것과 관측했다는 것은 같지 않습니다. 그렇게 적어야 합니다.

현재 입력에서 pingpong을 막는 구조적 요인이 둘 있습니다.

첫째는 어댑터 계층입니다. 우리 실제 어댑터 셋 중 어느 것도 LLM span을 내보내지 않습니다. 그들이 만드는 모든 span은 span_kind="tool"로 태그됩니다. Claude Code 어댑터는 그 값을 하드코딩하고 thinking이나 text블록을 span으로 만들지 않습니다. Toolathlon 어댑터는 “합성 CHAIN 루트 + tool span만”으로 정의되어 있습니다. RedundancyBench 어댑터는 매치된 쌍을 전부 span_kind="tool"로 내보내고 assistant 텍스트를 span으로 만들지 않습니다. LLM span 위에 정의된 패턴은 그것이 하나도 없는 입력에서는 발동할 수 없습니다.

둘째는 전처리 계층입니다. OTel과 LangGraph 트레이스는 LLM span을 실제로 담고 있고, 어댑터의 _KIND_MAP도 그것을 인식합니다. 그러나 공식 진입점은 전처리 단계 collapse_llm_spans를 실행하는데, 이 단계가 span_kind == "llm"인 span을 모두 제거하고 그 토큰 수를 상위 chain span으로 올려 붙입니다. LLM span을 가진 채 파이프라인에 들어온 트레이스조차 디텍터에는 그것 없이 도착합니다.

두 차단 요인 너머로, 워크로드 자체도 중요합니다. 지금 우리가 관측할 수 있는 트레이스는 코딩과 단일 에이전트 도구 호출 세션이 지배적입니다. A → B → A → B 형태의 에이전트 간 교대는 서로 다른 두 에이전트 정체성이 번갈아 도는 것을 요구합니다. 그것은 우리가 아직 접근하지 못한 종류의 작업입니다.

사이트가 그 패턴을 서술하는 방식을 바꿨습니다. Clew 페이지에서 pingpong 카드는 이제 “구현됨, 실제 트레이스에서는 아직 관측되지 않음”이라는 상태 줄을 달고 있고, pingpong이 진정한 멀티에이전트 트레이스를 필요로 한다는 것, 단일 에이전트 코딩 세션과 Toolathlon에서는 그것이 나오리라 기대되지 않는다는 것을 함께 적었습니다.

패턴은 여전히 구현되어 있습니다. 코드는 바뀌지 않았습니다. 사이트가 바뀌었습니다. 이 리포트가 그 이유입니다.