당신의 AI 에이전트는 처음 10단계까지는 완벽하게 작동합니다.
그러다 15단계쯤 가면, 점점 엉망이 되기 시작합니다.
잘못된 도구 호출. 원래 지시사항을 잊어버림. 낮은 품질의 출력 결과.
대부분의 사람들은 모델을 탓합니다.
하지만 거의 항상 모델 탓은 아닙니다.
문제는 모델이 보고 있는 것입니다.
모델이 보는 것을 정리하는 것을 컨텍스트 엔지니어링이라고 합니다.
이는 AI 에이전트를 구축하는 모든 사람에게 가장 중요한 기술로 빠르게 자리 잡고 있습니다.
다음은 완벽한 플레이북입니다.
프롬프트 엔지니어링은 죽었습니다. 이제 중요한 것은 컨텍스트 엔지니어링입니다.
프롬프트 엔지니어링에 대해 들어보셨을 겁니다.
명확한 지침 작성. 좋은 예시 제시. 모델에게 수행할 역할을 알려주기.
챗봇에게는 완벽하게 작동합니다.
하지만 에이전트를 구축하는 순간 더 이상 작동하지 않습니다.
그 이유는 다음과 같습니다.
챗봇은 하나의 질문에 답하고 멈춥니다.
에이전트는 행동을 수행합니다 — 웹 검색, API 호출, 코드 작성, 명령 실행 — 단계별로, 때로는 수십 단계를 거칩니다.
모든 단계는 출력을 생성하고, 이 출력은 모델의 컨텍스트에 추가됩니다.
그리고 그 컨텍스트는 유한합니다.
Anthropic의 엔지니어링 팀은 이를 다음과 같이 정의합니다:
"컨텍스트는 LLM에서 샘플링할 때 포함되는 토큰 집합입니다. 컨텍스트 엔지니어링은 원하는 결과를 일관되게 달성하기 위해 해당 토큰의 유용성을 최적화하는 것입니다."
간단히 말해: 에이전트가 올바른 정보를, 올바른 형식으로, 올바른 시점에 볼 수 있도록 하는 것입니다.
프롬프트 엔지니어링은 컨텍스트 엔지니어링의 하위 집합입니다.
컨텍스트 엔지니어링이 전부입니다.
에이전트의 컨텍스트 윈도우는 RAM입니다. 그리고 점점 가득 차고 있습니다.
LangChain이 이에 대한 적절한 비유를 제시합니다.
LLM을 새로운 종류의 운영 체제라고 생각해보세요.
모델은 CPU입니다 — 사고를 담당합니다.
컨텍스트 윈도우는 RAM입니다 — 모델이 현재 보고 추론할 수 있는 모든 것이 존재하는 작업 메모리입니다.
컴퓨터가 RAM으로 가득 차면 느려지듯이, 에이전트의 추론 능력은 컨텍스트 윈도우가 복잡해지면 저하됩니다.
이를 컨텍스트 부패라고 합니다.
Chroma는 18개의 최첨단 모델(GPT-4.1, Claude 4, Gemini 2.5, Qwen3 등)을 평가하는 연구를 수행했습니다.
모든 모델의 성능은 입력 길이가 증가함에 따라 저하되었습니다.
하드 한계에서가 아닙니다. 그 이전부터였습니다.
200K 토큰 윈도우를 가진 모델은 50K 토큰에서 상당한 성능 저하를 보일 수 있습니다.
성능 저하는 연속적입니다. 절벽처럼 떨어지는 것이 아닙니다.
왜일까요? 트랜스포머는 모든 토큰이 다른 모든 토큰에 주의를 기울이는 방식으로 작동하기 때문입니다 — 이는 n-제곱 관계를 만듭니다. 컨텍스트가 커질수록 모델이 이러한 모든 관계를 유지하는 능력이 약해집니다.
그리고 "중간에서 길을 잃음" 문제가 있습니다.
LLM은 U자형 주의 곡선을 보여줍니다.
→ 컨텍스트의 시작: 잘 기억함
→ 컨텍스트의 끝: 잘 기억함
→ 중간: largely ignored
연구자들은 관련 정보가 컨텍스트의 시작 부분에서 중간으로 이동할 때 정확도가 30% 포인트 이상 떨어지는 것을 측정했습니다.
원래 지시사항은 50,000 토큰의 도구 출력 아래에 묻혀 사실상 사라집니다.
Claude Code 사용자들은 출력 품질이 컨텍스트 용량의 40–60% 에서 저하된다는 것을 발견했습니다. 어떤 하드 한계보다 훨씬 이전입니다.
에이전트의 컨텍스트 공간을 두고 실제로 경쟁하는 것은 무엇일까요?
7가지 범주입니다. 모두 동일한 유한한 윈도우 공간을 두고 경쟁합니다.
1. 시스템 프롬프트
에이전트의 정체성. 행동 규칙. 제어 흐름 로직. 다양한 작업 유형에 대한 지침. 에이전트에서 이는 단순히 "도움이 되는 것"이 아닙니다. 전체 아키텍처를 정의할 수 있습니다.
2. 도구 정의
에이전트가 호출할 수 있는 모든 도구는 수행하는 작업, 사용하는 매개변수 및 사용 시기에 대한 스키마가 필요합니다.
3. 도구 호출 결과
모든 도구 호출은 출력을 컨텍스트에 추가합니다. 웹 페이지 검색: 5,000–10,000 토큰. 파일 읽기: 비슷합니다. 이러한 정보는 빠르게 누적됩니다.
4. 검색된 지식 (RAG)
벡터 데이터베이스에서 가져온 문서, 검색 결과, API 응답 등 에이전트의 결정을 알리기 위해 검색된 모든 것입니다.
5. 대화 기록
지금까지 일어난 모든 것에 대한 전체 기록입니다. 사용자 메시지, 에이전트 응답, 추론, 이전 결정. 각 턴마다 선형적으로 증가합니다.
6. 메모리
현재 세션의 단기 메모리입니다. 이전 세션의 장기 메모리 — 사용자 선호도, 이전 결과, 학습된 패턴.
7. 에이전트 상태
현재 계획, 할 일 목록, 진행 표시기, 스크래치패드 노트. 다단계 작업에서 에이전트의 위치를 추적하는 메타 정보입니다.
7가지 모두 동일한 윈도우를 두고 경쟁합니다.
컨텍스트 엔지니어링은 무엇이 승리할지 결정하는 것입니다.
4가지 핵심 전략
LangChain은 모든 컨텍스트 엔지니어링 기법을 4개의 버킷으로 구성하는 프레임워크를 발표했습니다.
앞으로 배우게 될 모든 기술은 이 중 하나에 속합니다.
쓰기. 선택하기. 압축하기. 격리하기.
전략 1 — 쓰기 (에이전트는 잊어버립니다. 기억할 방법을 주세요.)
에이전트의 컨텍스트가 가득 차서 압축되면 정보가 손실됩니다.
에이전트가 그 전에 아무것도 기록하지 않았다면 — 그 정보는 영원히 사라집니다.
쓰기는 에이전트가 컨텍스트 윈도우 외부에 정보를 유지할 수 있는 방법을 제공하는 것을 의미합니다.
세 가지 형태가 있습니다:
스크래치패드
에이전트에게 작업 중 메모를 작성할 수 있는 도구를 제공합니다. 중간 결과. 내린 결정. 나중에 필요할 것이라고 아는 정보.
Anthropic은 "think" 도구를 만들었습니다 — Claude가 문제를 해결할 수 있는 전용 공간입니다.
tau-bench 벤치마크에서 이는 특정 작업에서 최대 54%의 성능 향상을 가져왔습니다.
규칙 파일
영구적인 절차적 메모리입니다.
Claude Code를 사용해 본 적이 있다면 CLAUDE.md를 보았을 것입니다.
매 세션 시작 시 로드되는 지침입니다 — 프로젝트 아키텍처, 규칙, 테스트 실행 방법, 주의해야 할 사항.
에이전트는 시작할 때마다 이를 읽습니다.
기본 사항을 절대 잊지 않습니다.
메모리 추출
에이전트는 사실, 사용자 선호도 및 학습된 패턴을 저장하여 여러 세션에 걸쳐 검색할 수 있습니다.
컨텍스트 윈도우 외부에 완전히 존재합니다.
내일 에이전트가 필요로 하는 정보는 내일이 왔을 때 거기에서 기다리고 있습니다.
전략 2 — 선택하기 (에이전트에게 모든 것을 주지 마세요. 지금 필요한 것만 주세요.)
40개의 도구, 대규모 지식 기반 및 여러 세션의 기록을 가진 에이전트는 이 모든 것을 한 번에 로드할 수 없습니다.
무언가가 이 단계에 무엇이 관련 있는지 결정해야 합니다.
전통적인 RAG: 시스템이 결정합니다.
사용자가 질문 → 문서 검색 → 프롬프트에 삽입 → 완료.
정적입니다. 일회성입니다. 모델은 발언권이 없습니다.
에이전트 RAG: 에이전트가 결정합니다. 필요한 것을 검색하고, 쿼리를 개선하며, 도구를 선택하고, 충분한 정보를 가지고 있을 때를 결정합니다.
검색을 일회성 파이프라인이 아닌 반복적인 프로세스로 만듭니다.
이는 모든 단계에서 관련성이 변경되기 때문에 중요합니다 — 그리고 다음에 무엇이 필요한지 아는 것은 오직 에이전트뿐입니다.
도구 선택 문제는 사람들을 가장 많이 당황하게 만드는 문제입니다.
에이전트가 40개 이상의 도구를 가지고 있다면, 작업을 시작하기도 전에 컨텍스트에 잠재적으로 10,000 토큰의 도구 정의가 존재한다는 의미입니다.
해결책: 도구 설명에 대한 RAG입니다.
모든 도구 정의를 모든 호출에 덤프하는 대신, 의미론적 검색을 사용하여 현재 단계와 관련된 도구만 표시합니다.
RAG-MCP라는 논문에서 이를 테스트했습니다.
도구 선택 정확도: 14% → 43% (3배 향상). 토큰 사용량: 약 절반으로 감소.
Anthropic은 이를 하이브리드 전략이라고 부릅니다: 필수 컨텍스트는 사전에 로드하고(예: CLAUDE.md), 나머지는 에이전트가 적시에 검색하도록 합니다.
기본 사항을 먼저 로드하고, 필요에 따라 나머지를 검색합니다.
전략 3 — 압축하기 (컨텍스트는 축적됩니다. 의미는 유지하고, 토큰은 줄이세요.)
좋은 선택을 하더라도 컨텍스트는 축적됩니다.
모든 도구 호출, 검색된 문서 및 결정은 윈도우에 남아 있습니다.
에이전트가 20번의 도구 호출을 했다고 상상해보세요.
컨텍스트: 누적된 도구 출력, 대화 기록, 추론 흔적으로 80,000 토큰.
대부분은 더 이상 관련이 없습니다. 에이전트는 이미 이에 따라 행동했습니다.
하지만 여전히 거기에 있으며, 공간을 차지하고, 주의를 분산시키며, 비용과 지연 시간을 증가시킵니다.
3가지 지점에서 압축할 수 있습니다.
정보가 컨텍스트에 들어가기 전에:
→ 검색 전에 큰 문서를 일관된 조각으로 분할
→ 가장 유용한 조각만 들어가도록 재순위화
→ 주요 컨텍스트에 들어가기 전에 도구 출력을 즉시 요약
에이전트가 작업하는 동안:
→ 대화 기록의 롤링 요약 — 지속적으로 업데이트
→ 인기 있는 하이브리드: 마지막 10개 메시지는 그대로 유지 + 이전 메시지는 모두 요약
→ 하드 트리밍: 컨텍스트가 크기 임계값에 도달하면 이전 메시지 제거
→ Claude Code 자동 압축: 95% 용량에서 트리거되어 전체 궤적을 자동으로 요약
에이전트가 무언가에 대해 행동한 후:
→ 도구 결과 지우기: 도구 결과가 15단계 전에 사용된 경우, 삭제
→ 한 줄 요약으로 대체하거나 완전히 제거
→ 에이전트는 20단계 전에 가져온 웹 페이지의 전체 텍스트가 필요하지 않음
목표: 토큰 수를 줄입니다. 실제로 중요한 것을 보존합니다.
전략 4 — 격리하기 (가장 강력한 전략입니다. 다중 에이전트 시스템을 가능하게 합니다.)
긴 에이전트 실행의 더 깊은 문제가 여기에 있습니다.
단순히 공간의 문제가 아닙니다. 오염의 문제입니다.
연구 단계의 상세한 파일 검색 결과는 에이전트가 코드를 작성하는 단계로 넘어갈 때 여전히 컨텍스트에 남아 있습니다.
그 오래된 연구 컨텍스트는 이제 노이즈입니다. 모델이 깔끔한 구현에 집중해야 하는 단계에서 주의를 분산시키고 있습니다.
격리는 작업의 다른 부분에 별도의 컨텍스트 윈도우를 제공하는 것을 의미합니다.
하위 에이전트
상위 에이전트는 집중된 하위 작업("코드베이스에서 인증 관련 파일을 모두 검색")을 하위 에이전트에 위임합니다.
하위 에이전트는 자체 깨끗한 컨텍스트 윈도우에서 작업합니다.
보고할 때는 압축된 요약만 반환합니다.
모든 지저분한 검색 작업은 하위 에이전트의 컨텍스트에 격리되어 유지되며 상위 에이전트를 절대 오염시키지 않습니다.
상태 스키마 격리 (LangGraph의 접근 방식)
에이전트의 상태를 설계하여 다른 필드가 다른 유형의 컨텍스트를 저장하도록 합니다.
LLM은 현재 단계와 관련된 필드만 봅니다.
도구 결과는 "백스테이지" 필드에 위치하여 — 명시적으로 표시될 때까지 모델에 보이지 않습니다.
별도의 하위 에이전트를 시작하지 않고도 각 단계에서 에이전트가 보는 것을 세밀하게 제어할 수 있습니다.
격리는 복잡한 다단계 워크플로우를 실제로 안정적으로 만드는 것입니다.
다른 작업. 다른 컨텍스트 윈도우. 오염 없음.
에이전트가 실패하는 4가지 방식 (실패를 식별하세요. 수정하세요.)
Drew Breunig는 에이전트 컨텍스트가 성장함에 따라 네 가지 뚜렷한 실패 모드를 식별했습니다.
당신이 본 모든 고장난 에이전트는 이 중 하나에 속합니다.
실패 1: 컨텍스트 중독
환각이나 오류가 컨텍스트에 진입합니다.
에이전트는 이후 단계에서 이를 계속해서 참조합니다.
5단계의 잘못된 데이터가 이후의 모든 단계로 증폭됩니다.
해결책: 도구 출력이 컨텍스트에 진입하기 전에 검증하세요. 오류에서 복구한 후에는 실패한 시도의 기록을 압축하세요. 해결 방법만 중요할 때 10단계의 막다른 디버깅 결과를 보이지 않도록 하세요.
━━━
실패 2: 컨텍스트 산만
컨텍스트가 너무 길어져 모델이 최근 기록에 지나치게 의존하기 시작합니다.
새로운 계획을 종합하는 대신, 최근에 한 일을 되풀이하기만 합니다.
생각을 멈춥니다. 반복하기 시작합니다.
해결책: 적극적으로 요약하고 정리하세요. 사용 가능한 큰 컨텍스트 윈도우가 있더라도 말입니다. 큰 윈도우가 그것을 채워야 한다는 것을 의미하지는 않습니다.
━━━
실패 3: 컨텍스트 혼란
불필요한 콘텐츠가 모델을 저품질 결정으로 이끕니다.
전형적인 예: 46개의 도구가 주어졌을 때 벤치마크에서 실패한 모델 — 컨텍스트가 한계 내에 있었음에도 불구하고 — 19개의 도구만으로는 잘 작동했습니다.
도구가 컨텍스트가 수용하기에 너무 많았던 것이 아닙니다.
모델이 명확하게 추론하기에 너무 많았던 것입니다.
해결책: 동적 도구 관리입니다. RAG-MCP를 사용하여 현재 단계와 관련된 도구만 표시하세요. 도구 세트를 현재 단계와 일치시키세요.
━━━
실패 4: 컨텍스트 충돌
새로운 정보가 이미 컨텍스트에 있는 내용과 모순됩니다.
시스템 프롬프트는 한 가지를 말합니다. 검색된 문서는 다른 것을 말합니다.
에이전트는 모순을 해결할 수 없습니다. 일관되지 않은 동작을 생성합니다.
해결책: 명확한 권한 순서를 설정하세요. 시스템 프롬프트 > 검색된 사실 > 대화 기록. 새로운 정보를 주입하기 전에 기존 컨텍스트와 비교하여 검증하세요. XML 태그와 명확한 헤더를 사용하여 모델이 어떤 소스를 신뢰해야 하는지 알 수 있도록 하세요.
에이전트를 위한 시스템 프롬프트 작성 방법 (챗봇이 아닙니다. 에이전트입니다.)
챗봇 시스템 프롬프트는 어조를 설정합니다.
"당신은 유용한 어시스턴트입니다. 간결하고 친절하게 행동하세요."
에이전트 시스템 프롬프트는 아키텍처를 정의합니다.
제어 흐름 — 작업 유형에 접근하는 방법, 언제 어떤 도구를 사용할지, 오류 시 수행할 작업, 따라야 할 가드레일을 지정합니다.
이는 성격 프롬프트라기보다 자율적인 직원을 위한 직무 설명을 작성하는 것에 가깝습니다.
Anthropic은 이를 "적절한 고도"에서 작성하는 것이라고 부릅니다.
너무 규정적: "사용자가 청구를 언급하고 환불을 언급하며 금액이 $100를 초과하면 도구 X를 호출하세요." 깨지기 쉽습니다. 예상치 못한 모든 예외 상황에서 실패합니다.
너무 모호: "도움이 되고 적절한 도구를 사용하세요." 에이전트에게 아무것도 제공하지 않습니다. 구체적인 신호 없이는 좋은 자율적 결정을 내릴 수 없습니다.
최적점: 자율적 행동을 안내할 만큼 구체적이어야 합니다. 모델이 새로운 상황에서 판단을 적용할 수 있을 만큼 유연해야 합니다. 강력한 휴리스틱. 경직된 규칙이 아닙니다.
실용적인 팁:
→ XML 태그 또는 마크다운 헤더로 구성 — 배경, 지침, 도구 가이드
→ 최소한으로 시작하고 실패에 대해 반복 — 처음부터 모든 예외 상황을 예측하려고 하지 마세요
→ 최소가 짧다는 것을 의미하지는 않습니다 — 복잡한 에이전트 시스템 프롬프트는 수천 토큰이 될 수 있으며 모든 토큰이 그 자리를 차지할 가치가 있는 한 괜찮습니다
→ 퓨샷 예제 사용 — 모든 규칙을 단어로 설명하려고 하기보다 모델에게 좋은 행동이 무엇인지 보여주세요
KV-캐시: 컨텍스트 순서에 신경 써야 하는 $$$ 이유
대부분의 에이전트 빌더는 이것이 존재한다는 것을 모릅니다.
토큰을 LLM에 보내면, 모델은 각 토큰에 대한 키-값 표현을 계산합니다.
계산 비용이 많이 듭니다.
따라서 추론 제공자는 이러한 표현을 캐시합니다.
컨텍스트의 시작 부분(접두사)이 API 호출 간에 동일하게 유지되면, 제공자는 캐시된 계산을 재사용하고 끝 부분의 새 토큰만 처리합니다.
빠릅니다. 저렴합니다.
그러나 호출 간에 컨텍스트의 초기 부분을 재배열하거나 변경하면 캐시가 무효화됩니다. 제공자는 처음부터 모든 것을 다시 계산합니다.
Claude Sonnet의 비용 차이:
→ 캐시된 입력 토큰: 백만 개당 $0.30
→ 캐시되지 않은 입력 토큰: 백만 개당 $3.00
10배 차이입니다.
작업당 30–40번의 API 호출을 하는 에이전트의 경우, 이 차이는 빠르게 누적됩니다.
KV-캐시 효율성을 위한 실용적인 규칙:
→ 안정적인 콘텐츠는 컨텍스트의 맨 위에 배치 — 시스템 프롬프트, 도구 정의, 턴 사이에 변경되지 않는 모든 것
→ 동적 콘텐츠는 맨 아래에 배치 — 대화 기록, 현재 단계, 에이전트 상태
→ 대화 중간에 도구를 동적으로 추가하거나 제거하지 마세요 — 캐시를 무효화합니다
→ 도구 제거 대신 도구 마스킹 사용 — 접두사(캐시됨)에 모든 도구 정의를 안정적으로 유지하고, 현재 단계에 사용할 수 없는 도구를 표시만 하세요
7시간 만에 35,000줄의 코드를 출시하는 워크플로우
Dex Horthy(HumanLayer CEO)는 AI Engineer Code Summit에서 이 내용을 발표했습니다.
그의 팀은 이 방법을 사용하여 대규모 Rust 코드베이스에 단 7시간 만에 약 35,000줄의 코드를 출시했다고 합니다.
방법: 빈번한 의도적 압축입니다.
에이전트 작업을 단계로 구조화합니다. 각 단계는 압축된 산출물을 생성합니다. 각 새 단계는 해당 산출물만 포함하는 새로운 컨텍스트 윈도우로 시작합니다.
항상 컨텍스트 윈도우의 40–60% 미만을 의도적으로 유지합니다.
1단계 — 연구
하위 에이전트가 코드베이스를 탐색합니다. 파일을 읽습니다. 데이터 흐름을 추적합니다. 아키텍처를 매핑합니다.
모든 지저분한 grep 결과와 파일 내용은 하위 에이전트 컨텍스트에 유지됩니다. 상위 에이전트는 절대 건드리지 않습니다. (격리)
출력: 압축된 research.md — 파일 경로, 함수 시그니처, 패턴, 주의사항. (쓰기)
컨텍스트 재설정: 원시 연구는 윈도우의 60–80%를 사용했습니다. 연구 산출물은 이를 15–20%로 압축합니다. (압축)
2단계 — 계획
새로운 컨텍스트 윈도우입니다. 포함 내용: 연구 문서 + 문제 정의만 포함합니다.
에이전트가 상세한 구현 계획을 생성합니다.
이것이 가장 중요한 인간 검토 체크포인트입니다.
여기서 논리 오류를 잡으면 수정하기 쉽고 무료입니다. 나중에는 몇 시간이 걸립니다.
3단계 — 구현
또 다른 새로운 컨텍스트 윈도우입니다. 포함 내용: 계획만 포함합니다.
에이전트가 이를 단계별로 따릅니다.
복잡한 작업의 경우: progress.md가 완료된 작업과 남은 작업을 추적합니다. (쓰기)
결과: 각 단계마다 깨끗하고 집중된 에이전트입니다. 오염 없음. 컨텍스트 부패 없음. "엉성한 20단계" 없음.
최고의 플랫폼이 이 문제를 다르게 처리하는 방법
Claude Code
하이브리드 검색. CLAUDE.md가 먼저 로드됩니다. glob 및 grep과 같은 도구는 적시에 코드베이스 탐색을 처리합니다.
95%에서 자동 압축 — 아키텍처 결정과 가장 최근에 액세스한 5개의 파일을 보존합니다.
복잡한 하위 작업을 위해 각각 자체 깨끗한 컨텍스트를 가진 하위 에이전트를 생성할 수 있습니다.
철학: "작동하는 가장 간단한 것을 하라." 모델이 필요한 것이 무엇인지 똑똑하게 판단하도록 하고, 그것을 찾을 수 있는 도구를 제공하세요.
Manus
KV-캐시 인식 컨텍스트 순서: 안정적인 접두사, 동적 접미사. 도구 제거가 아닌 도구 마스킹.
관찰 압축 파이프라인 — 모든 도구 출력은 에이전트의 컨텍스트에 진입하기 전에 처리됩니다.
상태 추적을 위한 영구 할 일 목록.
제거된 컨텍스트를 위한 오버플로 메모리로서의 파일 시스템.
확장성을 위해 구축되었습니다. 효율성이 비즈니스 비용 문제인 수십만 명의 사용자에게 서비스를 제공합니다.
ChatGPT Agent
시각 우선 접근 방식. 에이전트는 GUI 브라우저와 상호 작용합니다.
스크린샷이 시각적 스냅샷으로 컨텍스트에 추가됩니다. 모델은 보이는 것을 기반으로 추론합니다.
시각적 토큰은 비용이 많이 들기 때문에 에이전트는 스크린샷 수를 선택적으로 결정합니다.
RL을 사용하여 명시적으로 프로그래밍하는 대신 수천 대의 가상 머신에서 최적의 도구 사용 전략을 학습합니다.
Google ADK
가장 원칙적인 아키텍처 접근 방식입니다.
세 가지 설계 원칙:
- 저장소와 프레젠테이션 분리 — 지속적인 상태는 각 API 호출에 표시되는 것과 동일하지 않습니다.
- 명시적 변환 — 테스트 가능하고 구성 가능한 단계로 컨텍스트를 변환하는 명명되고 정렬된 프로세서
- 기본적으로 컨텍스트 범위 지정 — 모든 모델 호출은 필요한 최소 정보만 봅니다.
프롬프트 제작보다 엔지니어링 규율.
보편적인 에이전트 턴 파이프라인
모든 주요 플랫폼은 에이전트 턴당 동일한 5단계 루프로 수렴합니다:
→ 수집 — 사용자 입력, 대화 기록, 도구 결과, 검색된 문서, 에이전트 상태
→ 선택 — 남은 토큰 예산 내에서 이 단계에 관련된 것
→ 압축 — 컨텍스트에 맞게 요약, 자르기 또는 재구성
→ 배열 — 안정적인 콘텐츠 먼저(캐시), 동적 콘텐츠 마지막
→ 조립 및 호출 — 최종 컨텍스트 → API 호출 → 출력 획득 → 반복
이것이 당신이 사용해 본 모든 프로덕션 에이전트 내부에서 실행되는 루프입니다.
이것을 이해하는 것이 안정적인 에이전트를 출시하는 빌더와 에이전트가 15단계에서 왜 엉망이 되는지 궁금해하는 빌더를 구분짓습니다.
요약
컨텍스트 부패는 현실이며 컨텍스트 제한보다 훨씬 이전에 시작됩니다.
이를 해결하는 4가지 전략:
→ 쓰기 — 에이전트가 잊지 않도록 컨텍스트 외부에 정보 유지
→ 선택하기 — 이 단계에 필요한 것만 가져오기
→ 압축하기 — 토큰을 줄이고, 의미를 유지하며, 사전 예방적으로(반응적으로가 아닌)
→ 격리하기 — 별도의 작업을 위한 별도의 컨텍스트, 오염 없음
주시해야 할 4가지 실패 모드:
→ 중독 — 잘못된 데이터가 모든 단계를 통해 증폭됨
→ 산만 — 긴 기록으로 에이전트가 생각 대신 재탕함
→ 혼란 — 너무 많은 도구가 결정 품질을 저하시킴
→ 충돌 — 모순이 일관되지 않은 동작을 생성함
KV-캐시는 10배의 비용 절감 효과가 있습니다. 안정적인 콘텐츠를 먼저 배치하세요.
최고의 워크플로우: 연구 → 압축 → 계획 → 압축 → 구현. 모든 단계에서 새로운 컨텍스트.
컨텍스트 엔지니어링은 진지한 에이전트 작업을 위한 선택 사항이 아닙니다.
그것이 작업 자체입니다.
이 글이 유용했다면:
→ 아는 모든 에이전트 빌더와 공유하려면 리포스트하세요
→ 더 많은 시스템이 당신이 자는 동안 작동하는 것을 보려면 @sairahul1을 팔로우하세요
→ 이 글을 북마크하세요 — 4가지 전략 프레임워크로 돌아오게 될 것입니다
저는 AI, 제품 구축 및 실제로 작동하는 시스템에 대해 글을 씁니다.
