도구 컨텍스트 관리

도구 정의와 누적된 tool_result 블록은 "context window"(컨텍스트 윈도우)를 소비합니다. 많은 도구를 사용하거나 여러 턴을 거치는 장기 실행 에이전트는 작업이 완료되기 전에 사용 가능한 컨텍스트를 소진할 수 있습니다. 네 가지 접근 방식이 파이프라인의 서로 다른 지점에서 이 문제를 해결합니다.



네 가지 접근 방식

각 접근 방식은 서로 다른 컨텍스트 압박 원인을 대상으로 합니다. 토큰이 어디에 소비되고 있는지에 맞는 방식을 선택하세요.



도구 검색

도구 검색은 Claude가 요청할 때까지 도구 정의를 컨텍스트 윈도우 밖에 유지합니다. 50개의 도구 스키마를 사전에 보내는 대신, 단일 tool_search 도구를 보내고 Claude가 필요에 따라 나머지를 찾도록 합니다. 이는 약간의 "latency"(지연 시간, 도구를 조회하기 위한 추가 턴 한 번)를 감수하는 대신 기본 컨텍스트 사용량을 크게 줄입니다.



프로그래밍 방식 도구 호출

프로그래밍 방식 도구 호출은 일련의 도구 호출을 Claude가 작성하고 Anthropic의 코드 실행 샌드박스가 실행하는 단일 코드 블록으로 축소합니다. tool_use와 tool_result의 다섯 번의 왕복 대신, Claude는 샌드박스 내에서 다섯 개의 함수를 모두 호출하는 하나의 스크립트를 생성합니다. 중간 결과는 대화 히스토리에 전혀 들어가지 않습니다.



프롬프트 캐싱

"Prompt caching"(프롬프트 캐싱)은 컨텍스트의 토큰 수를 줄이지는 않지만, 후속 요청에서 해당 토큰에 대해 지불하는 비용을 줄입니다. 도구 정의가 안정적이라면 한 번 캐시하고 수천 개의 요청에서 캐시된 접두사를 재사용하세요. 도구 세트가 크지만 고정되어 있을 때 적합한 선택입니다.



컨텍스트 편집

컨텍스트 편집은 오래된 tool_result 블록이 그 역할을 다한 후 대화 히스토리에서 제거합니다. 긴 에이전트 루프는 당시에는 유용했지만 이제는 불필요한 부담이 된 수백 개의 중간 결과를 생성할 수 있습니다. 컨텍스트 편집을 사용하면 대화를 다시 시작하지 않고도 이를 정리할 수 있습니다.



접근 방식 조합하기

이러한 접근 방식은 함께 조합할 수 있습니다. 장기 실행 에이전트는 도구 검색을 사용하여 도구 세트를 간결하게 유지하고, 프롬프트 캐싱을 사용하여 나머지 정의의 비용을 분산하며, 컨텍스트 편집을 사용하여 대화가 길어짐에 따라 오래된 결과를 정리할 수 있습니다. 각각이 문제의 서로 다른 부분을 해결하므로 함께 사용해도 충돌이 없습니다.

대용량 에이전트를 위한 합리적인 시작점은 다음과 같습니다.

1. 첫날부터 도구 정의에 프롬프트 캐싱을 활성화하세요. 캐시 쓰기는 기본 입력 가격 대비 25%의 추가 비용이 발생하지만, 캐시에 적중하는 두 번째 요청부터 비용이 회수됩니다.
2. 도구 세트가 대략 20개 이상으로 늘어나거나 기본 컨텍스트 사용량이 눈에 띄게 되면 도구 검색을 추가하세요.
3. 개별 대화가 충분히 길어져서 초기 결과가 무의미해지기 시작하면 컨텍스트 편집을 추가하세요.
4. 단일 배치로 실행할 수 있는 작은 도구 호출의 반복적인 체인이 발견되면 프로그래밍 방식 도구 호출을 고려하세요.



다음 단계