Context Management for Deep Agents
Blog

Context Management for Deep Agents

LangChain Accounts
2026.01.29
·Web·by 이호민
#LLM#Agent#Context Management#LangChain#AI

핵심 포인트

  • 1Deep Agents SDK는 LangChain의 오픈소스 에이전트 Harness로, LLM 에이전트가 긴 Task를 수행할 때 발생하는 context rot와 메모리 제약을 해결하기 위해 고안되었습니다.
  • 2이 SDK는 대규모 tool 결과 및 입력 Offloading과 Summarization을 포함한 세 가지 주요 context compression 기술을 활용하여 LLM의 context window를 효율적으로 관리합니다.
  • 3효과적인 context management를 검증하기 위해, 개발자들은 압축 이벤트를 인위적으로 늘리고 목표 유지 및 정보 복구(예: needle-in-the-haystack)를 확인하는 targeted evals를 수행하여 시스템을 평가합니다.

본 논문은 AI 에이전트의 addressable task length가 증가함에 따라 context rot을 방지하고 LLM의 유한한 메모리 제약 조건을 관리하기 위한 효과적인 context management의 중요성을 강조합니다. LangChain의 오픈 소스 에이전트 harness인 Deep Agents SDK는 계획 수립, subagent 생성, 그리고 filesystem과의 상호작용을 통해 복잡하고 장기 실행되는 작업을 수행하는 에이전트를 구축하는 쉬운 경로를 제공합니다. 이러한 종류의 작업은 일반적으로 모델의 context window를 초과할 수 있기 때문에, SDK는 context compression을 용이하게 하는 다양한 기능을 구현합니다.

Context compression은 에이전트의 working memory에 있는 정보의 양을 줄이면서도 작업을 완료하는 데 관련된 세부 정보를 보존하는 기술을 의미합니다. 이는 이전 상호작용 요약, 오래된 정보 필터링, 또는 무엇을 유지하고 무엇을 버릴지 전략적으로 결정하는 것을 포함할 수 있습니다. Deep Agents는 listing, reading, writing file뿐만 아니라 search, pattern matching, file execution과 같은 작업을 수행할 수 있는 filesystem abstraction을 구현합니다. 에이전트는 필요에 따라 offloaded된 콘텐츠를 검색하고 검색하기 위해 filesystem을 사용합니다.

Deep Agents는 다음과 같은 세 가지 주요 압축 기법을 구현하며, 이는 다른 빈도로 트리거됩니다:

  1. Offloading large tool results: tool 호출의 응답(예: 큰 파일 읽기 결과 또는 API 호출)은 모델의 context window를 초과할 수 있습니다. Deep Agents는 tool response가 20,000 tokens를 초과하는 것을 감지하면, 해당 응답을 filesystem으로 offload하고 이를 파일 경로 참조 및 처음 10줄의 preview로 대체합니다. 에이전트는 필요에 따라 콘텐츠를 다시 읽거나 검색할 수 있습니다.
  1. Offloading large tool inputs: file write 및 edit 작업은 에이전트의 conversation history에 전체 파일 콘텐츠를 포함하는 tool call을 남깁니다. 이 콘텐츠는 이미 filesystem에 지속(persisted)되어 있으므로 종종 중복됩니다. session context가 모델의 사용 가능한 window의 85%를 초과할 때, Deep Agents는 이전 tool call을 truncate하여 디스크의 파일에 대한 pointer로 대체하고 active context의 크기를 줄입니다.
  1. Summarization: offloading으로 충분한 공간이 확보되지 않을 때, Deep Agents는 summarization으로 전환합니다. 이 과정은 두 가지 구성 요소를 가집니다:
    • In-context summary: LLM이 conversation의 구조화된 요약(session intent, 생성된 artifact, 다음 단계 포함)을 생성하여 에이전트의 working memory에 있는 전체 conversation history를 대체합니다.
    • Filesystem preservation: 완전한 원본 conversation message는 canonical record로서 filesystem에 기록됩니다.
이 이중 접근 방식은 에이전트가 목표와 진행 상황을 인지하도록 보장하는 동시에 (요약을 통해) 필요할 때 특정 세부 정보를 복구할 수 있는 능력을 보존합니다 (filesystem search를 통해).

Context limit을 관리하기 위해 Deep Agents SDK는 모델의 context window 크기의 특정 비율에서 이러한 compression 단계를 트리거합니다. (내부적으로는 LangChain의 model profiles을 사용하여 주어진 모델의 token threshold에 접근합니다.)

이러한 기술의 작동 여부를 확인하기 위해, 실제 작업 벤치마크(예: terminal-bench)는 context compression을 산발적으로 트리거하여 그 영향을 분리하기 어렵게 만듭니다. 이를 해결하기 위해, Deep Agents는 벤치마크 데이터셋에서 개별 기능의 신호를 더 공격적으로 높이는 방법을 제안합니다. 예를 들어, summarization을 사용 가능한 context window의 10-20%에서 트리거하면 최적의 전체 성능을 내지 못할 수 있지만, 훨씬 더 많은 summarization 이벤트를 생성하여 다양한 구성(예: 구현 변형)을 비교할 수 있게 합니다.

Deep Agents SDK는 개별 context management 메커니즘을 격리하고 검증하기 위해 고안된 일련의 targeted evaluations를 유지합니다. 이는 특정 실패 모드를 명확하고 디버깅 가능하게 만드는 의도적으로 작은 테스트입니다. 예를 들어:

  • 요약이 에이전트의 목표를 보존했는지: 일부 evals는 작업 중간에 의도적으로 summarization을 트리거한 다음 에이전트가 계속 진행하는지 확인합니다. 이는 summarization이 에이전트 상태뿐만 아니라 궤적도 보존하는지 확인합니다.
  • 에이전트가 요약된 정보를 복구할 수 있는지: conversation 초기에 "needle-in-the-haystack" 사실을 삽입하고, summarization 이벤트를 강제한 다음, 에이전트가 나중에 해당 사실을 회상하여 작업을 완료하도록 요구합니다. 이 사실은 summarization 후 active context에 없으며 filesystem search를 통해 복구되어야 합니다.
이러한 targeted evals는 context management를 위한 integration test 역할을 하며, 전체 벤치마크 실행을 대체하지는 않지만 반복 시간을 크게 줄이고 실패를 전체 에이전트 동작이 아닌 특정 압축 메커니즘에 귀속시킬 수 있도록 합니다.

Context compression 전략을 평가할 때, 논문은 다음을 강조합니다:

  • 실제 벤치마크로 시작하고 개별 기능을 stress-test: 대표적인 작업을 통해 기준 성능을 설정한 다음, 압축을 더 공격적으로 트리거하여(예: 85% 대신 10-20%에서) 실행당 더 많은 압축 이벤트를 생성합니다. 이는 개별 기능의 신호를 증폭시켜 다른 접근 방식(예: summarization prompt 변형)을 비교하기 쉽게 합니다.
  • 복구 가능성(recoverability) 테스트: Context compression은 중요한 정보에 계속 접근할 수 있을 때만 유용합니다. 에이전트가 압축 후 원래 목표를 향해 계속 나아갈 수 있고 필요할 때 특정 세부 정보를 복구할 수 있는지 확인하는 targeted test를 포함해야 합니다.
  • 목표 이탈(goal drift) 모니터링: 가장 위험한 실패 모드는 summarization 후 사용자의 의도를 놓치는 에이전트입니다. 이는 에이전트가 summarization 후 clarification을 요청하거나 작업을 잘못 완료했다고 선언하는 것으로 나타날 수 있습니다. 미묘한 작업 이탈은 summarization에 귀속시키기 어려울 수 있으므로, 샘플 데이터셋에서 빈번한 summarization을 강제하는 것이 이러한 실패를 드러내는 데 도움이 될 수 있습니다.