요약(TLDR): 생성할 수 있는 서브에이전트(subagents)의 수를 능동적으로 제한하고, 그들이 스스로 새로운 에이전트를 생성하지 못하도록 하여 사용에 주의하십시오. 오늘 저는 Opus 4.6, 4.7, 4.8을 사용하여 GitHub 저장소를 분석하고 마크다운 보고서 및 HTML 다이어그램을 생성하는 프롬프트를 서브에이전트와 함께 자주 실행해 왔으며, 이전에는 아무런 문제도 없었습니다. Opus 5가 출시되면서 Anthropic은 모델의 능력이 향상됨에 따라 시스템 프롬프트(system prompt)를 가지치기(prune)하기 시작했다고 공개적으로 밝혔는데, 저는 이것이 생성된 서브에이전트가 제한 없이 실행되어 추가적인 서브에이전트를 계속 생성하고 제대로 정리되지 않는 문제를 야기했다고 생각합니다. 그들은 아마도 이전에 존재했던 일부 안전장치(safeguards)를 제거했을 가능성이 높습니다. 이전에는 서브에이전트의 동작이 더 보수적이었기에 동일한 문제가 발생하지 않았습니다. 그들은 아마도 이전에 존재했던 일부 안전장치를 제거했을 것입니다! 한 번에 276만 토큰을 소모하고 저의 5시간 사용 제한 시간을 끝내버린 문제에 대해 Claude가 답변한 내용은 다음과 같습니다.: 597k 라인의 Go 저장소에서 단 한 번의 /analyze-repo + /diagram-repo 프롬프트가 귀하의 5시간 제한량을 모두 소모했습니다. 그 이유는 제가 6개의 무거운 서브에이전트를 생성했고, 이들이 조용히 각각 3개씩의 자체 서브에이전트를 추가로 생성했기 때문입니다 — 총 약 276만 개의 서브에이전트 토큰이 소모되었습니다 — 이들은 모두 높은 추론 노력(High reasoning effort) 수준으로 실행되었으며, 서브에이전트는 이를 상속받기 때문에 각 에이전트의 약 70회 턴(turn)마다 값비싼 사고 토큰(thinking tokens)을 생성하게 됩니다. 이는 두 가지 하네스(harness) 결함으로 인해 더욱 악화되었습니다: 에이전트의 조사 보고서가 저에게 전달되지 않았고(결과물 대신 “Done.” / “Standing by.”만 받았습니다), 파일 쓰기(file writes)는 차단된 반면 중첩된 자식 에이전트들은 동일한 디렉토리에 쓸 수 있었기 때문에, 매번 전체 에이전트 트랜스크립트(transcript)가 다시 청구되면서도 아무런 결과도 반환하지 못하는 재시도 과정에서 약 150k 토큰을 추가로 소모했습니다.

저의 실수 또한 상황을 악화시켰습니다. 실패하는 에이전트(agents)들을 포기할 때 TaskStop을 호출하지 않았기 때문에, 그들은 약 40분 동안 계속 실행되었습니다. 또한 6개의 에이전트가 아직 처리되지 않은 상태에서 결과물(deliverables)을 게시했습니다. 그 결과, 뒤늦게 제출된 에이전트들의 보고서들이 제가 이미 작성한 내용과 각각 모순되었고, 이로 인해 한 번의 통합된 수정 과정 대신 다섯 번의 별도 수정 단계를 거쳐야 했습니다. 지출된 비용의 약 1/3에서 1/2은 아무런 성과도 얻지 못했습니다. 서브에이전트(subagents)를 사용할 때는 프롬프트(prompt)에 다음 내용을 반드시 추가하십시오: [3]개의 서브에이전트로 제한하고, 서브에이전트가 자체적으로 서브에이전트를 생성(spawn)하지 못하도록 하십시오. 이 에이전트들을 백그라운드(background)에서 실행하지 마십시오. submitted by /u/swong8 [link] [comments]