긴 작업에서 에이전트가 맥락을 스스로 정리하게 합니다 | DAKER 커뮤니티

2026년 8월 28일 Zhuoshi Pan 연구팀이 긴 구간 에이전트 작업에서 맥락을 스스로 정리하는 ContextPilot을 arXiv에 공개했습니다. EMNLP 2026 Main Track에 채택되었습니다. 긴 작업은 여러 턴에 걸쳐 흩어진 정보를 반복해 가져오고 합치고 유지해야 하는데, 모든 상호작용 기록을 남기면 작업 맥락이 계속 커집니다. 최근 방법들은 전용 도구로 작업 맥락을 편집하게 하지만, 도구 범위·탐색·신용 할당에 한계가 있습니다. ContextPilot은 계획·장기 기억·소프트 오프로딩을 도구에 더하고, 맥락·엔트로피 변화로 중요한 편집을 고르는 세분 RL을 제안합니다.

긴 작업에서 에이전트가 맥락을 스스로 정리하게 합니다

논문은 2026년 8월 28일 arXiv에 올라왔습니다. 초록은 arXiv:2608.28476에서 확인할 수 있습니다. 저자는 Zhuoshi Pan, Qizhi Pei, Junru Lu, Honglin Lin, H. Vicky Zhao, Di Yin, Xing Sun입니다. 코멘트에는 10 pages, 6 figures, 5 tables, accepted to EMNLP 2026 (Main Track)라고 적혀 있습니다. PDF는 같은 번호의 pdf입니다. 코드는 GitHub Tencent/ContextPilot에 공개되어 있습니다. 오늘 본문은 초록이 적은 범위만 옮깁니다. 초록에 없는 벤치 점수와 퍼센트는 쓰지 않습니다.

긴 작업에서 에이전트가 맥락을 스스로 정리하게 합니다 장면

긴 작업의 맥락 팽창을 다룹니다

긴 구간 에이전트 과제는 모델이 여러 턴에 걸쳐 흩어진 정보를 가져오고, 합치고, 유지해야 합니다. 모든 상호작용 기록을 그대로 두면 작업 맥락이 계속 커집니다. 최근 능동 맥락 관리 방법은 전용 도구로 작업 맥락을 편집하게 합니다. 그래도 세 가지 한계가 남습니다.

첫째, 도구셋이 검색·삭제·요약에 묶여 전역 계획, 장기 기억, 적응 압축을 지원하지 않습니다. 둘째, 맥락 관리 행동이 최종 결과에 미치는 영향이 다른데도 탐색이 행동을 균일하게 취급합니다. 셋째, RL에서 궤적 단위 최종 보상을 중간 맥락 편집 전체에 粗하게 할당합니다. ContextPilot은 이 간격을 메우려 합니다.

DACON과 DAKER처럼 팀이 긴 조사·검색·코딩 루프를 돌리는 자리에서는, “컨텍스트 창만 키우기”와 “작업 맥락을 편집하는 도구·학습”을 같은 칸에 두지 말아야 합니다. 오늘 팀이 가져갈 한 줄은 이것입니다. 기록이 늘어날수록 계획·기억·오프로딩 도구를 같이 설계하십시오.

도구를 늘리고 세분 RL을 붙입니다

ContextPilot은 계획, 장기 기억, 소프트 맥락 오프로딩 도구로 도구셋을 체계적으로 확장합니다. 여기에 맥락 관리에 맞춘 RL을 더합니다. 맥락과 엔트로피 변화를 이용해 중요한 편집 결정을 고르고 분기 샘플링을 하며, 해당 맥락 편집 행동을 지나는 모든 분기 궤적에서 행동 단위 어드밴티지를 추정합니다.

실험은 긴 맥락 QA와 deep search 과제에서 ContextPilot이 더 작은 작업 맥락으로도 더 강한 성능을 낸다고 보고합니다. 여러 베이스 모델과 벤치에서 기존 기준선을 일관되게 앞선다고 적습니다. 없는 벤치 이름과 퍼센트를 짓지 않습니다. 초록이 준 “더 압축된 작업 맥락”과 “더 강한 성능”만 옮깁니다.

빌더 팀에 옮기면 세 줄입니다. 첫째, 검색·삭제·요약 외에 계획·장기 기억·오프로딩 칸을 도구 표에 둡니다. 둘째, 맥락 편집 로그에 엔트로피·길이 변화를 같이 남깁니다. 셋째, 최종 보상만 전체에 뿌리지 말고, 중요 편집 지점을 표시합니다. 해커톤 README에 이 세 칸이 없으면 재현이 어렵습니다.

균일 탐색과 粗한 신용 할당을 피합니다

초록은 맥락 관리 행동의 영향이 이질적이라고 적습니다. 모든 편집을 같은 탐색 가중치로 두면 중요한 압축·오프로딩이 묻힙니다. 팀이 오늘 돌리는 에이전트 로그에도 “삭제 한 번”과 “계획 갱신 한 번”을 같은 점수로 두지 마십시오.

DAKER 제출에서는 작업 맥락 길이 곡선과 최종 과제 성공을 같은 페이지에 둡니다. 길이만 줄이고 답이 틀리면 실패입니다. 성공만 보고 맥락이 비대해도 실패에 가깝습니다. ContextPilot이 강조한 방향은 압축과 성능을 같이 보는 것입니다.

粗한 신용 할당은 중간 편집 전부를 최종 보상으로 덮는 방식입니다. 팀이 RL을 쓰지 않더라도, 사람이 리뷰할 때 마지막 턴만 보고 중간 요약 실패를 넘기지 마십시오. 편집 시점 태그를 로그에 남깁니다.

공개 코드로 재현을 시작합니다

코드가 GitHub에 있으므로, 팀은 오늘 저장소와 초록을 같은 탭에 두고 자체 맥락 도구 표를 쓸 수 있습니다. 표에는 계획 도구, 장기 기억, 소프트 오프로딩, 검색·삭제·요약이 들어가야 합니다. 채팅에만 남긴 도구 목록은 다음 주 팀원이 실행하지 못합니다.

다른 팀의 능동 맥락 관리 데모를 받을 때도 같은 규칙을 씁니다. 도구가 검색·요약뿐이면 ContextPilot이 지적한 첫 한계가 그대로입니다. DAKER와 DACON 제출은 다른 사람이 열 수 있는 주소를 요구합니다. 맥락 길이 로그와 편집 태그를 저장소에 두십시오.

오늘 팀이 창 크기만 키우고 편집 도구를 비우면, 내일 긴 검색에서 작업 맥락이 다시 부풀어 오릅니다. 그 순환을 끊는 일이 이 글을 읽는 이유입니다. 압축과 성능을 같이 재십시오.

해커톤 긴 조사 루프에 옮깁니다

해커톤의 deep search 성격 과제에서는 매 턴 전체 기록을 붙이지 말고, 오프로딩·기억·계획 갱신 시점을 미리 적습니다. 초록이 말한 소프트 오프로딩은 “지우기만”이 아니라 작업 맥락 밖으로 내리는 옮기는 쪽입니다. 팀 문서에 보관 위치와 다시 불러오는 규칙을 적습니다.

팀이 오늘 할 일은 제출 페이지에 “작업 맥락 편집 도구”와 “최종 답 생성”을 표로 나누는 것입니다. 편집 도구 칸에는 계획·기억·오프로딩 호출 예를 적습니다. 최종 답 칸에는 압축된 맥락만 쓰는지 적습니다. 초록이 말한 프레임은 이 표가 공개 주소에 있을 때 성립합니다.

베이스 모델을 바꿀 때도 같은 표를 유지합니다. 초록은 여러 베이스 모델에서 기준선을 앞선다고 적습니다. 우리 실험에서도 모델 이름과 맥락 도구 설정을 한 줄에 같이 적습니다. 모델만 바꾸고 도구를 비우면 비교가 성립하지 않습니다.

엔트로피·맥락 길이 변화를 중요 편집 신호로 쓰는 아이디어는, RL을 돌리지 않는 팀에도 리뷰 체크리스트가 됩니다. 길이가 급증한 턴과 급감한 턴을 표시하고, 그 턴의 도구 호출만 따로 읽습니다.

계획 도구는 다음 여러 턴의 정보 요구를 먼저 적게 합니다. 장기 기억은 작업 맥락 밖에 두는 사실·중간 결론을 담습니다. 소프트 오프로딩은 지금 창에서 빼되 다시 불러올 주소를 남깁니다. 세 도구의 입출력을 JSON 스키마로 고정하면 팀원이 바뀌어도 같은 로그를 읽습니다.

엔트로피 변화를 직접 계산하지 않는 팀도, 요약 전후 토큰 길이와 중복 비율을 남겨 두면 중요 편집 후보를 고르는 데 도움이 됩니다. 길이가 거의 안 줄었는데 요약했다고 적힌 턴은 실패 후보입니다. 리뷰 때 그 턴만 모아 읽습니다.

deep search 과제에서는 출처 URL과 인용 문장을 장기 기억에 넣고, 최종 답 생성 직전에는 압축된 작업 맥락만 쓰는지 검사합니다. 최종 답에 출처가 없는데 기억에는 출처가 있으면 오프로딩 경로가 끊긴 것입니다. DAKER 제출 체크리스트에 그 검사를 한 줄로 둡니다.

베이스 모델을 바꿀 때 맥락 도구 프롬프트도 같이 버전을 올립니다. 모델만 바꾸고 도구 설명을 옛버전으로 두면 비교가 성립하지 않습니다. 초록이 여러 베이스에서 앞선다고 적은 만큼, 우리 표에도 모델×도구 버전 행렬을 남깁니다.

작업 맥락 편집 실패를 등급으로 나눕니다. 필수 사실을 지운 편집, 계획만 갱신한 편집, 오프로딩 주소를 남긴 편집을 다르게 태깅합니다. 최종 보상이 같아도 실패 유형이 다르면 다음 주 도구 수정 방향이 달라집니다. DAKER 회고 문서에 유형별 횟수만 적어도 충분합니다.

이 글이 아닌 것입니다

특정 벤치 점수표가 아닙니다. 초록은 긴 맥락 QA와 deep search에서 더 강한 성능과 더 작은 작업 맥락을 보고하지만, 벤치 이름과 퍼센트를 적지 않습니다. 없는 점수를 지어내지 않습니다.

컨텍스트 창만 키우면 된다는 처방이 아닙니다. 능동 편집 도구와 세분 RL을 말합니다. “max tokens만 올리기”로 바꾸어 쓰지 않습니다.

검색·삭제·요약만 있으면 충분하다는 주장도 아닙니다. 그 제한을 한계로 두고 계획·장기 기억·오프로딩을 더합니다.

특정 회사 제품 출시 공지가 아닙니다. 연구 논문과 공개 코드 안내입니다.

모든 베이스 모델에서 동일 수치가 나온다는 보장도 아닙니다. 여러 베이스와 벤치에서 기준선을 일관되게 앞선다는 보고입니다. 우리 스택과 같다고 쓰지 않습니다.

오늘 할 일

첫째, 초록과 PDF를 직접 여십시오. arXiv:2608.28476pdf를 같은 탭에 둡니다. EMNLP 2026 Main 채택 문구와 제출일 2026-08-28을 메모 첫 줄에 적습니다.

둘째, 공개 코드를 북마크하십시오. Tencent/ContextPilot README와 라이선스를 저장합니다. 클론만 하고 출처 URL을 비우지 않습니다.

셋째, 우리 팀의 맥락 도구 표를 한 페이지로 쓰십시오. 검색·삭제·요약·계획·장기 기억·소프트 오프로딩을 칸으로 나눕니다. DAKER 월간 해커톤이나 긴 조사 과제에 맞춰 적습니다.

넷째, 작업 맥락 길이 로그를 켜십시오. 턴마다 길이와 편집 유형을 남깁니다. 없는 퍼센트를 채우지 말고 길이 곡선과 성공·실패만 적습니다.

다섯째, 중요 편집 후보 규칙을 정하십시오. 길이·엔트로피 급변 턴을 리뷰 목록에 올립니다. 최종 턴만 보지 않습니다.

여섯째, 창 크기만 키운 베이스라인과 편집 도구 후보를 나란히 비교하십시오. 초록이 구분한 한계와 혼동하지 않습니다.

일곱째, 도구 표와 길이 로그를 공개 링크로 올리십시오. DAKER와 DACON에는 빌더와 대회 기록이 쌓여 있습니다. 배포가 제출입니다. 올린 링크가 제출입니다.

출처: arXiv:2608.28476 — ContextPilot (2026-08-28) · PDF · Code · EMNLP 2026 Main