200회 이상의 툴 호출이 필요한 에이전트를 어떻게 처리하시나요? 저희가 시도한 방식에 대한 피드백을 구합니다
How do you handle agents that need 200+ tool calls per task? We tried one approach, looking for critique
핵심 요약
대규모 툴 호출이 필요한 에이전트 체인의 안정적인 운영을 위해 체크포인트 기반 설계 방식을 공유하고 커뮤니티의 의견을 묻는 글입니다.
- 긴 연구 체인 — 100회 이상의 툴 호출 시 발생하는 컨텍스트 드리프트와 연결 끊김 문제 해결 시도함.
- 상태 유지 방식 — 전체 세션을 유지하는 대신 최근 툴 결과만 유지하고 재연결 가능한 체크포인트 시스템 도입함.
- 설계 피드백 — 300회 툴 호출 제한이 적절한지, 아니면 서브 에이전트 구조가 더 나은지에 대한 커뮤니티 의견 수렴함.
- 운영 경험 공유 — 대규모 에이전트 체인을 프로덕션 환경에서 운영하는 개발자들의 실무 사례 및 노하우 요청함.
에이전트 체인을 작업 중이라 이 서브레딧에 가장 먼저 가져오고 싶었습니다. 공개하자면, 저는 MiroMind에서 일하고 있고 이건 저희의 체크포인트지만, 브랜드가 아니라 설계 트레이드오프가 흥미로워서 올리는 겁니다.
딥 리서치 체인에서 계속 부딪혔던 문제들:
- 긴 호흡. 실제 연구 작업은 일상적으로 100회 이상의 툴 호출을 넘깁니다. 대부분의 에이전트 프레임워크는 컨텍스트 드리프트와 툴 결과 노이즈 때문에 50회만 넘어가도 성능이 급격히 떨어집니다.
- 연결 끊김. 20분짜리 작업이 소켓 리셋으로 죽어버리면, 재시도 로직이 망가졌다는 걸 배우는 데 너무 비싼 대가를 치르게 됩니다.
- 추적 기억상실. 작업을 끝냈는데 답이 틀렸을 때, 체인이 어느 툴 호출에서 꼬였는지 확인할 방법이 없습니다.
저희가 MiroThinker 1.7 딥 리서치로 시도한 것: - 단일 실행으로 256K 컨텍스트 윈도우 내에서 최대 300회의 툴 상호작용을 수행하며, 최근성 기반 유지(가장 최신 K개의 툴 결과만 컨텍스트에 유지)를 사용합니다. "모든 게 깨지기 쉬운 HTTP 세션 하나에 살아야 한다"는 방식이 아닙니다.
제출 / 재개 / 취소 기능이 1급 시민으로 취급되며, 에이전트는 저희 쪽에서 계속 실행되고 사용자는 나중에 다시 연결할 수 있습니다. - 모든 단계가 로깅됩니다. 240단계 중 187단계에서 체인이 실패했을 때 왜 그랬는지 알아야 할 때 유용합니다. 아키텍처 선택에 유용한 숫자들입니다.
아직 확신이 안 서는 부분: - 300회 툴 호출 제한이 실제로 적절한 형태인지, 아니면 여러분 대부분은 그보다 훨씬 전에 체인을 끊고 서브 에이전트를 사용하는지 궁금합니다.
- 현재 재개 가능한 실행을 어떻게 처리하시나요? 직접 작업 큐를 만드시나요, 아니면 제가 놓치고 있는 패턴이 있나요?
긴 체인을 프로덕션에서 돌리고 계신 분들의 경험담을 듣고 싶습니다.
BTW API 출시 가격은 25% 할인 중이고, 프리즈 전 요금제라 플랫폼이 실패하면 비용을 지불하지 않으셔도 됩니다.
