DeepSeek Harness 팀, Agent를 '운영체제'로 설계한 아키텍처 공개

DeepSeek Harness 팀이 아키텍처 장문을 발표해, 이들이 어떻게 "항상 온라인"인 Agent를 만들었는지 설명했다. 글에는 아주 예리한 문장이 하나 있다.

단일 작업의 상한은 모델 능력에 달려 있고, 다중 작업의 상한은 사람의 주의력에 달려 있다.

그들은 사람이 보통 동시에 3~5개의 활성 Session만 따라갈 수 있다고 관찰했다. 기존 Agent는 모두 단일 Session을 단위로 하고 Session 간에 서로 독립적이기 때문에, 여러 작업을 병행해서 진행할 때 수동으로 전환해야 하고 각 Session에서 어디까지 이야기했는지도 기억해야 한다.

그들의 해법은 Super-agent라 불리며, 네 가지 특징이 있다. 연속성 (IM, GitHub 코멘트 같은 익숙한 인터페이스에서 대화하며, 항상 하나의 Agent와 이야기하는 느낌), 효율성 (이전 명령이 끝나기를 기다리지 않고 다음 명령을 내릴 수 있음), 능동성 (지시를 기다리지 않고 스스로 환경 이벤트를 관찰), 지속성 (항상 온라인, 이상 발생 시 자동 복구).

아키텍처에서 가장 핵심은 이중 레이어 설계 다. 하나의 상주 Router 레이어가 모든 인간 상호작용과 전역 조정을 담당하고, 여러 컨텍스트 격리된 Worker 레이어가 구체적 작업을 동시에 실행한다.

이 분리는 하나의 근본적 트레이드오프를 해결한다. 모든 이벤트를 같은 Session에 몰아넣으면 컨텍스트는 가장 연속적이지만, 단일 ReAct Loop의 직렬 실행에 제약되어 처리량이 올라가지 않고, 여러 작업의 중간 세부 사항이 서로 오염된다. 반대로 이벤트마다 새 Session을 열면 동시성은 최고지만 전역 컨텍스트가 부족해 각자의 결과가 파편화된다.

핵심 통찰은 이것이다. "전역 연속성 유지"와 "고동시성 실행"은 두 가지 일이며, 같은 레이어가 담당해서는 안 된다.

Router 레이어는 의도적으로 구체적 작업을 실행하지 않는다. "Bash 도구를 아예 갖추지 않을 수도 있으며", 오직 상호작용과 분배만 한다. Worker는 사람과 직접 대화하지 않고 Router에만 상태를 보고한다. 그들이 언급한 한 가지는 특히 주목할 만하다. Router 레이어의 작업은 흔히 생각만큼 복잡하지 않아서, 비교적 경량의 모델로도 흔히 속도와 효과를 함께 챙길 수 있다 .

글은 또 날카로운 관점을 던진다. 사용자가 Session을 수동으로 관리하게 하는 것은 상당 부분 하위 LLM API에서 이어진 설계 관성이다. " Session은 시스템의 구현 세부 사항이어야 하며, 사용자의 인지 부담이어서는 안 된다. "

그다음은 운영체제에서 차용한 몇 가지 설계인데, 이 부분이 가장 흥미롭다.

이벤트 필터링은 Fast Path / Slow Path 를 사용한다. 실제 그룹 채팅과 코드 플랫폼에 접속한 뒤 이벤트 스트림은 "고노이즈, 저트리거율"이다. 대다수 일상 메시지는 Agent의 개입이 필요 없다. 그래서 먼저 결정론적 코드로 첫 번째 필터(출처, 그룹 범위, 화이트리스트)를 수행하고, 의미 이해가 필요한 후보만 모델에 넘긴다. 대규모 모델 추론은 유연하지만 고비용인 Slow Path이고, 결정론적 코드는 저지연 저비용의 Fast Path다.

이벤트 라우팅 역시 빠른 경로와 느린 경로로 나뉜다. 같은 GitHub PR, 같은 IM 토픽 아래의 연속 이벤트가 하나의 Thread를 구성한다. Router는 최초 이벤트에서만 Worker를 생성하고 구독을 설정하며, 이후 같은 Thread의 이벤트는 프로그램이 이미 구독한 Worker에 직통 으로 전달하고 더는 Router를 거치지 않는다. 실제 측정 결과: 직통 메커니즘을 제거하면 작업 완료 시간은 기본적으로 변화가 없지만, Router가 해야 할 결정이 약 30% 늘어나고, 캐시 읽기 토큰이 2323만에서 3177만으로 늘어난다(+37%).

컨텍스트는 Cache 단위로 관리하며, 두 가지 작업이 있다. Inline(가까운 시일 내 사용될 가능성이 높은 정보를 직접 인라인해 도구 호출 왕복을 없앰)과 Spill(예산을 초과한 내용은 윈도우 밖에 두고 참조나 요약만 유지). 지역성 원리와 함께 층층이 펼쳐져 마지막에는 "체인형 회수"를 형성한다. 각 객체가 다음 홉의 연관 객체 ID를 인라인하고, 모델은 참조 관계를 따라 한 홉씩 컨텍스트를 되찾을 수 있다.

또 두 단어를 꽤 정확하게 썼다.

투기적 실행(Speculative Execution) — 결과가 채택될지 아직 확실하지 않을 때 먼저 백그라운드에서 시도한다. "결과에 가치가 있으면 전달하고, 가치가 없으면 버린다." 이들 내부에는 "조용히 재현하고 수정" 전략이 있다. 그룹에서 누군가 문제를 피드백하면 Agent가 먼저 백그라운드에서 재현과 수정을 시도하고, 문제를 확인하고 간단한 수정법을 찾았을 때만 전달하며, 그렇지 않으면 전 과정에서 조용히 있는다.

전이중 상호작용 — 고전적 ReAct Loop의 동기 블로킹 run()을 비동기 start() / stop() 으로 바꾼다. start() 는 즉시 "시작됨"을 반환하고, 백그라운드에서 실행이 끝나면 결과를 새 이벤트로 세션에 다시 전달한다. 전면 대화와 백그라운드 작업이 이로써 분리된다.

배포 측면에서는 스토리지·컴퓨트 분리 를 차용했다. 먼저 Agent Loop의 컴퓨팅과 영속화 상태를 분리하고(컴퓨팅은 무상태 컨테이너로, 상태는 데이터베이스로), 이어서 실행 환경을 제자리에 둔다. 단말 측에는 세션 상태를 저장하지 않는 경량 daemon 하나만 두고, 명령 실행과 결과 반환만 담당한다. 이렇게 하면 BYOM(Bring Your Own Machine)을 지원하고, 클라우드 호스팅 머신도 연결할 수 있다. 그들은 이것이 Anthropic의 "뇌와 손 분리" 사고와 일치하며, 차이는 시나리오에 있다고 언급한다. 그쪽은 호스팅 서비스이고, 이쪽은 우선 사용자가 일상적으로 쓰며 간헐적으로 온라인일 수 있는 개인 머신에 연결하는 것이다.

외부에는 또 Watchdog Session 이 있어 정기 메시지로 구동되어 독립적인 제어 루프를 구성한다. 이는 프로세스 생존만 감시하지 않는다. "많은 이상은 프로세스 크래시가 아니라 모델이 실행 중 비효율적 루프에 빠지거나 목표에서 벗어나는 것"이므로, 모델이 Worker에 실질적 진전이 있는지, 방향이 벗어났는지도 판단해야 한다. Watchdog 자체도 완전한 도구를 갖춘 Agent이기 때문에, 유지보수자는 자연어로 장애 원인을 물을 수 있고, 심지어 온라인에서 메인 시스템의 프롬프트와 트리거 규칙을 수정하게 할 수도 있다.

실험 데이터도 제시했다. 엔드투엔드 소거 실험에서 Super-agent의 p50, p95 완료 시간은 각각 12.4분, 15.7분이다. 반면 Subagent 도구를 갖춘 단일 Session 방식은 프롬프트에 심하게 의존한다. 중립적 프롬프트에서 모델은 5회 실행 중 한 번도 Subagent를 호출하지 않았고, 전부 메인 세션에서 새 메시지에 반복적으로 방해받아 p95가 29.5분에 달했다.

글은 또 미해결 문제도 명확히 나열했으며, 미화하지 않았다. 가장 현실적인 항목은 보안이다. 클라우드 Agent Loop가 침해되거나 프롬프트 인젝션에 뚫리면, 그것이 연결된 모든 단말 장치가 제어될 위험에 직면한다 . 게다가 클라우드가 뚫리지 않더라도, 단말 자격 증명이 모델 컨텍스트에 들어가기만 하면 정상 실행 과정에서도 마찬가지로 유출 위험이 있다. "Agent가 자격 증명 자체에 전혀 접촉하지 않은 채 자격 증명을 사용할 수 있도록 하는 메커니즘 설계도 필요하다."

이 설계는 현재 이들 내부에서 돌아가고 있으며, 프로토타입 코드는 dsh-superagent-prototype 에 오픈소스로 공개되어 있다. 공식 측은 "기술 노선을 검증하기 위해 제공된 프로토타입일 뿐, DeepSeek의 정식 제품이 아니다"라고 강조한다.

참고 출처

- DeepSeek Harness 팀: Super-agent 설계 탐구 — 더 자율적인 Agent 시스템을 향하여