방금, DeepSeek가 차세대 에이전트 하네스 개념을 발표했습니다

원문 제목: Super-agent 디자인 탐색: 더 자율적인 Agent 시스템으로 나아가기

원문 저자: DeepSeek 제품부

1. Super-agent

지난 1년 동안, Coding Agent를 대표로 하는 단일 작업 Agent는 모델이 도구를 사용하여 복잡한 문제를 해결할 수 있으며, 인간의 지속적인 모니터링과 점진적인 개입이 점점 덜 필요하다는 것을 증명했습니다. 동시에, 모델의 다중 Agent 협업 능력도 향상되어, 세션 간의 조직 및 조정이 가능해졌습니다. 인간의 하위 실행 참여가 줄어들면서, 인간의 역할은 점차 더 높은 수준의 결정 및 수용으로 이동하고 있습니다.

모델 능력의 이러한 향상은 새로운 응용 형태를 촉발했습니다. 최근 개인 비서(Personal Agent)가 집중적으로 등장하기 시작했으며, 이들은 일상적인 메시지, 일정, 이메일 및 작업 플랫폼에 직접 연결되어 정보 흐름을 지속적으로 관찰하고 업무를 처리하는 데 도움을 줍니다. 이러한 지속적인 온라인, 사건 주도 작업 방식은 개인적인 상황에 국한되지 않으며, 개인 비서는 그 중 하나의 응용일 뿐입니다; 소프트웨어 개발 등 상업적 상황에서도 동일하게 가치가 있습니다.

그러나 현재의 주류 Agent 디자인은 다중 작업 및 팀 협업의 규모에서 이러한 방식을 지원하기 어렵습니다. Agent의 작업 방식은 여전히 단일 세션을 기본 단위로 하며, 서로 다른 세션 간에는 독립적입니다. 사용자가 여러 작업을 병행할 때, 각 세션의 맥락을 기억하고 수동으로 전환해야 하며, 관찰에 따르면 한 사람이 동시에 3개에서 5개의 활성 세션만을 따라갈 수 있습니다. 이러한 디자인 하에서는 단일 작업의 한계는 모델 능력에 의존하고, 다중 작업의 한계는 인간의 주의력에 의존합니다.

기존의 로컬 단일 세션 Agent에서 CLI, MCP 또는 외부 커넥터를 통해 간단한 확장을 시도하더라도, Agent는 외부 메시지에 접근할 수 있지만 여전히 단일 세션 동기화 차단, 다중 작업 맥락 혼란, 로컬 장치 오프라인 시 중단 등의 문제에 제약을 받으며, 많은 인력 유지 관리가 필요합니다.

이러한 제한을 극복하기 위해서는 Agent와 단일 수동 세션의 결합을 끊고, 세션 간에 맥락을 유지하며 동시에 여러 복잡한 작업을 진행할 수 있는 연속적인 실체로 만들어야 합니다. 우리는 이러한 Agent 형태 및 시스템 아키텍처를 Super-agent라고 부릅니다.

예를 들어, 우리가 내부적으로 DeepSeek Harness를 기반으로 운영하는 Super-agent 인스턴스에서는 동일한 개발 작업이 IM과 GitHub 간에 연속적으로 진행될 수 있습니다; 이 인스턴스는 또한 공용 채팅에서 피드백을 지속적으로 관찰하며, 아무도 @하지 않는 경우에도 원인을 능동적으로 파악하고 수정 Pull Request를 제출합니다:

동일한 작업이 IM 그룹 채팅과 GitHub Pull Request 검토 간에 연속적으로 진행됨

공용 채팅을 지속적으로 주시하며, 아무도 @하지 않는 경우에도 결함을 능동적으로 식별하고 수정 Pull Request를 제출함

구체적으로, 우리는 Super-agent가 다음 네 가지 기본 특성을 갖추고 있다고 생각합니다:

• 연속성: 사용자는 IM 채팅, GitHub 댓글 등 익숙한 작업 인터페이스에서 직접 상호작용할 수 있으며, 항상 하나의 Agent만 존재하는 것처럼 느끼고 "세션 X의 맥락에 Y 정보가 있는지"에 대해 고민할 필요가 없습니다. 예를 들어, 사용자가 IM에서 A 방안을 제안한 후 GitHub Pull Request 댓글에서 B 방안으로 변경하면, 그것을 이해하고 실행 방향을 조정할 수 있습니다.

• 효율성: 상호작용 응답이 빠르며, 동시에 여러 복잡한 작업을 병행하고 고품질로 완료할 수 있습니다. 이전 명령이나 작업이 완료되기를 기다리지 않고 다음 지시를 받을 수 있습니다.

• 능동성: 사용자가 지시를 하나씩 내리기를 기다릴 필요 없이, 환경 사건을 지속적으로 관찰하고 처리할 가치가 있는 사항을 능동적으로 추진하며, 개입이 필요하지 않을 때는 조용히 유지됩니다.

• 지속성: 항상 온라인 상태이며, 사용자의 실제 작업 환경에 직접 연결되어 있으며, 장기 운영 중에 이상이 발생하면 자동으로 복구됩니다.

단일 ReAct 루프는 위의 네 가지 특성을 동시에 지원할 수 없으며, 하위에는 이에 상응하는 아키텍처가 필요합니다. 유사한 설계 제약은 유사한 아키텍처 선택을 도출합니다. 우리는 개인 비서든 소프트웨어 개발 등 상업적 상황을 위한 Agent든, 지속적으로 온라인 상태에서 환경 사건에 동시 응답하는 시스템을 구축하는 것이 목표라면, 하위에서 유사한 아키텍처를 채택할 가능성이 높다고 생각합니다. 동시에 이 과정에서 직면하는 많은 문제는 전통적인 컴퓨터 시스템에서 오랫동안 논의된 문제와 매우 유사하므로, 컴퓨터 시스템의 많은 고전적인 설계 사상이 여기에서도 적용될 수 있습니다.

구체적인 구현에서 이 아키텍처는 다양한 변형을 가질 수 있지만, 우리는 다음 다섯 개 모듈이 위의 네 가지 기본 특성을 지지하는 기본 프레임워크를 구성한다고 생각합니다: 이중 레이어 아키텍처(제 2절)를 통해 연속 상호작용과 효율적인 병행을 고려하고, 사건 주도(제 3절)를 통해 능동적 응답을 실현하며, 인간 중심의 상호작용(제 4절)을 통해 상호작용 과정에서 연속성과 효율성을 동시에 달성하고, 계산, 상태 및 환경의 분리를 통해(제 5절) 장치 간의 지속적인 온라인 상태 및 이상 자가 복구를 실현합니다.

아래 그림은 Super-agent의 전체 시스템 아키텍처를 보여주며, 그림의 각 모듈 번호 [2]에서 [6]은 각각 아래의 제 2절에서 제 6절에 해당합니다:

Super-agent 전체 시스템 아키텍처, 번호 [2]에서 [6]은 아래의 제 2절에서 제 6절에 해당

2. 이중 레이어 아키텍처

신호 채널 간의 연속 상호작용과 다중 작업의 효율적인 병행을 동시에 실현하기 위해, 시스템은 하위 세션 조직에서 연속성과 처리량 간의 근본적인 균형(Trade-off)에 직면합니다.

모든 사건을 동일한 세션에서 처리한다면, 맥락은 가장 연속적이지만, 단일 ReAct 루프의 직렬 실행 속도 한계에 의해 작업 완료 시간이 길고 처리량이 낮으며, 다중 작업의 중간 세부 사항이 혼합되어 완료 효과에 영향을 미칠 수 있습니다.

반대로, 모든 사건을 독립적인 세션에서 처리한다면, 병행 처리량은 최고지만, 작업 간 완전한 독립성이 없을 경우, 전역 맥락이 부족하여 각 세션의 결과가 서로 단절되고, 여러 세션이 각기 사용자에게 응답하는 것도 상호작용 혼란을 초래할 수 있습니다.

연속성과 처리량을 모두 고려하기 위해, 우리는 "전역 연속성 유지"와 "고병행 실행"을 두 개의 다른 레벨로 분리할 수 있습니다: 상주하는 라우터 레이어(2.1절)가 인간 상호작용과 전역 조정을 통합하고, 맥락이 분리된 워커 레이어(2.2절)가 구체적인 작업을 병행 실행합니다, 아래 그림과 같이:

이중 레이어 아키텍처: 라우터 레이어가 라우팅 및 대외 상호작용을 통합하고, 여러 워커 세션이 격리되어 병행 실행 작업을 수행함

이 이중 레이어 아키텍처를 통해, 시스템은 하위에서 맥락 관리 및 병행 실행을 인수하여, 사용자 측에서는 세션의 존재를 희석시켜 사용자가 항상 동일한 Super-agent를 대면하게 됩니다. 이러한 관점에서, 사용자가 수동으로 세션을 관리하도록 하는 것은 상당 부분 하위 LLM API에서 이어진 설계 관성입니다; 세션은 시스템의 구현 세부 사항이어야 하며, 사용자의 인지 부담이 되어서는 안 됩니다.

현재 디자인에서 세션은 기술적인 맥락 관리와 사용자 중심의 프로젝트 관리를 동시에 수행하고 있습니다. 제품 형태와 하위 세션을 분리한 후, 사용자 중심의 프로젝트 관리는 더 이상 세션의 제약을 받지 않으며, 사용자에게 어떤 상호작용 및 작업 관리 방식을 노출할지는 독립적인 제품 문제로 남게 됩니다. 우리는 후속 문서에서 이 문제를 논의할 것입니다.

여기서 "이중"은 논리적인 책임 분담을 의미하며, 각 레이어는 구현상 단일 세션에 국한되지 않고 각자의 내부 구조를 가질 수 있습니다. 아래에서는 라우터 레이어와 워커 레이어의 디자인을 각각 소개합니다.

2.1 라우터 레이어

라우터 레이어는 상주하는 전역 라우팅 레이어로, 모든 진입점의 인간 상호작용을 수용하는 역할을 합니다. 모든 작업 간의 정보와 결정은 라우터 레이어에서 집계되며, 이를 통해 전역의 시퀀스 포인트(Sequence Point), 조정 포인트 및 기억 역할을 합니다. 이 전역 노드가 시스템의 성능 병목이 되지 않도록 하기 위해, 라우터 레이어는 설계상 구체적인 작업을 직접 실행하지 않고, 인간 상호작용 및 작업 배분만 담당하며, 심지어 Bash 도구를 갖추지 않을 수도 있습니다.

하나의 중심 노드가 여러 실행 노드를 배분하는 구조는 표면적으로는 일반적인 Agent 팀과 유사해 보이지만, 두 가지의 초점은 다릅니다. 일반적인 Agent 팀은 단일 복잡 작업 내부의 단계 분해 및 역할 협업에 주로 사용되며, 하위 단계가 일반적으로 긴밀하게 결합되어 있기 때문에 팀 리드는 종종 작업 세부 사항을 깊이 이해하고 하위 작업을 계획하며 각 구성원을 고빈도로 조정해야 하며, 스스로도 상당한 추론 부담을 지게 됩니다. 반면 Super-agent에서는 라우터 레이어가 작업 간의 고수준 연관성과 배분만 처리하며, 단일 작업 내부의 분해에 개입할 필요가 없습니다; 반대로, 만약 프롬프트를 통해 Agent 팀의 주 세션이 구체적인 작업을 직접 실행하지 않고 대외 상호작용만 담당하며 서로 다른 작업을 각 구성원에게 독립적으로 추진하도록 배분한다면, 그것도 이러한 이중 레이어 아키텍처로 볼 수 있습니다. 우리의 실천에 따르면, 라우터 레이어의 작업은 종종 예상보다 복잡하지 않으며, 비교적 가벼운 모델을 사용해도 속도와 효과를 모두 고려할 수 있습니다.

내부 구현에서 라우터 레이어는 또한 단일 세션에 국한될 필요가 없으며, 심지어 일부 논리는 LLM을 호출할 필요가 없을 수도 있습니다. 우리는 가장 직접적인 단일 상주 LLM 세션을 라우터 레이어의 핵심 구현으로 선택했으며, 그것이 표면적으로 보이는 것만큼 쉽게 처리량 병목이 되지 않는다는 것을 발견했습니다. 왜냐하면 이전 라운드 추론 기간 동안 도달한 환경 사건(즉, 제 3절의 Trigger)이 누적되어 다음 라운드에서 함께 처리되며, 배치 처리(Batching)가 이루어지기 때문입니다. 그리고 병합 처리의 추가 비용은 매우 적습니다:

• 외부 사건 흐름이 원활할 때, Trigger가 하나씩 라우터 세션으로 들어오며, 이때 단일 응답 지연이 낮습니다;

• 사건이 밀집하여 Router Session에서 대기 혼잡이 발생할 때, 이전 추론 기간 동안 쌓인 여러 Trigger가 자동으로 병합되어 다음 LLM 호출 시 함께 주입됩니다. Router Session은 가벼운 상호작용 및 분배만 수행하며, 각 단계는 일반적으로 긴 입력과 짧은 출력을 포함합니다. 쌓인 여러 Trigger를 하나의 LLM API 호출로 병합하면 Prefill 단계에서 병렬 계산이 이루어지며, 단일 요청 소요 시간의 증가는 배치 크기보다 훨씬 느립니다. 따라서 일정 범위 내에서 쌓인 것이 많을수록 개별 결정이 분담하는 추론 시간은 낮아집니다; 상한선은 문맥 길이와 모델이 한 번에 정확히 처리할 수 있는 Trigger의 수에 따라 달라집니다.

우리는 7.2절에서 실험을 통해 이 배치 처리 메커니즘의 효과를 정량적으로 보여줄 것입니다. 이후에 소개될 구독 및 직통 메커니즘과 체인 호출(3.2, 3.3절 참조)을 더하여, 단일 상주 Router Session은 문맥의 연속성을 유지하면서 현재 팀 규모에서 충분히 활용될 수 있습니다.

규모가 더욱 확대되고 단일 세션이 실제로 수용하기에 부족할 경우, Router 계층 내부는 다층 필터 구조로 설계되거나 여러 세션으로 수평 분할(Sharding)될 수 있습니다. 이때 Router 계층의 내부 설계는 본질적으로 연속성과 처리량 간의 균형을 이루게 됩니다. 분할의 세분화가 더 미세할수록 Router 계층의 동시 처리량은 높아지지만, 조각 간의 기억 및 문맥 연속성은 낮아집니다. 전역 기억 문제를 해결하기 전까지 이 균형은 항상 존재합니다.

2.2 Worker 계층

Worker 계층은 구체적인 실행을 담당하는 세션으로 구성되며, 각 Worker는 서로 문맥이 격리되어 완전한 실행 도구를 장착하고 독립적인 문맥에서 단일 작업을 집중적으로 수행합니다. Worker Session은 작업 결과 및 코드 품질을 직접 결정하므로, 일반적으로 가장 강력한 모델을 구성해야 합니다.

Worker는 인간과 직접 상호작용하지 않으며, 그 추론 과정과 도구 호출은 외부 채널에 직접 출력되지 않고 Router 계층에 상태를 보고하여 Router 계층이 사용자에게 통합적으로 응답합니다. 이를 통해 동시성을 보장하고 전달 품질을 유지하면서 여러 세션이 각각 응답하여 발생하는 혼란을 피할 수 있습니다.

다중 작업을 동시 실행할 때, 각 Worker는 독립적으로 작업을 진행하며, 동일 계층의 Worker 간에는 일반적으로 직접 통신이 필요하지 않습니다. 여러 Worker가 구체적인 실행 중 충돌하는 경우는 동일한 Pull Request와 같은 공유 작업 환경에서 발생합니다; 그들이 모두 해당 Thread를 구독하고 있다면 동일한 사건 알림을 받게 되어(3.2절 참조) 스스로 충돌을 발견하고 해결할 기회를 갖게 됩니다. 소수의 교차 작업 협업은 Router 계층을 통해 중계됩니다.

Router 계층과 유사하게, 각 Worker Session 내부도 단일 세션에 국한될 필요는 없습니다: 복잡한 단일 작업을 수행할 때 Worker 내부에서 Subagent를 추가로 생성할 수 있으며, 본인 자체가 Agent Team일 수도 있습니다. 이러한 구조는 상위 Router 계층에 투명하게 유지됩니다. 이 구조는 코드 협업 시나리오(여러 독립적인 문제 재현, Pull Request 검토 및 기능 개발을 동시에 진행하면서 서로 방해하지 않음)에도 적합하며, 개인 비서 시나리오에도 적합합니다: 개인 비서는 인터페이스에서 일반적으로 단일 세션의 채팅 페이지만 제공하지만, 사용자가 동일한 대화 상자에서 여러 다른 주제를 동시에 논의할 때, 프론트엔드의 단일 채팅 페이지가 상호작용의 연속성을 유지하고, 하위에서는 각 주제에 대해 Worker를 배정하여 작업을 병렬로 진행하고 응답 초안을 작성할 수 있습니다.

3. 사건 주도

Super-agent가 능동성을 갖추려면 먼저 시스템의 구동 방식을 변경해야 합니다. Agent를 구동하는 주요 입력은 더 이상 인간이 Session에서 하나씩 입력하는 프롬프트가 아니라 환경의 반구조화된 사건입니다. Super-agent에서 그룹 채팅 메시지, 이메일 및 일정 알림, 코드 검토 댓글, CI 실행 결과와 같은 환경 사건은 Trigger라고 불립니다. Trigger를 모니터링하고 응답함으로써, Agent는 더 이상 단일 Session 모드에서처럼 인간이 지시를 내릴 때까지 수동적으로 실행되지 않습니다.

환경 사건이 들어오고 처리되는 생애 주기를 중심으로, 아래에서는 네 가지 점진적인 문제를 순차적으로 논의합니다: 프로그램과 모델 결합의 두 단계 전략을 통해 대량의 노이즈를 필터링하는 방법(3.1절), 구독 및 직통 메커니즘을 통해 사건을 Worker에게 라우팅하는 방법(3.2절), Inline & Spill 및 체인 호출을 활용하여 모델에 고밀도로 문맥을 주입하고 필요에 따라 호출하는 방법(3.3절), 그리고 환경 신호에 따라 배경에서 미리 행동하기 위해 투기적 실행을 활용하는 방법(3.4절).

3.1 사건 필터링

실제 그룹 채팅 및 코드 플랫폼에 접속한 후, 환경 사건 흐름은 "높은 노이즈, 낮은 트리거율"의 특징을 보입니다. 대부분의 일상 메시지는 Agent의 개입이 필요하지 않습니다. 각 사건에 대해 대형 모델을 호출하여 처음부터 판단한다면 지연과 계산 비용을 감당하기 어려울 것입니다. 컴퓨터 시스템의 Fast Path / Slow Path 개념을 차용하여, 대형 모델 추론은 유연하지만 비용이 높은 Slow Path로 간주할 수 있으며, 이미 명확하고 안정적인 고빈도 판단을 결정론적 코드로 고정하면 저지연, 저비용의 Fast Path를 구성합니다.

따라서 사건이 시스템에 들어온 후 첫 번째 단계는 필터링이며, 목표는 대형 모델을 호출하기 전에 결정론적 전략을 사용하여 노이즈를 걸러내고 의미 이해가 필요한 후보 사건만 모델 판단에 넘기는 것입니다. 우리는 프로그램 전략과 대형 모델을 결합한 두 단계 필터링 메커니즘을 채택합니다:

• 프로그램 계층 전략(빠른 경로): 사건 출처, 그룹 범위, 사용자 또는 로봇 화이트리스트와 같은 결정론적 조건에 따라 코드로 빠른 접근 검사를 수행합니다. 예를 들어, 서로 다른 출처에 대해 "명확한 요청에만 응답", "후보 사건으로" 또는 "직접 무시"와 같은 설정을 하여 모델 호출 전에 대부분의 무관한 메시지를 필터링합니다.

• 의미 계층 전략(느린 경로): 프로그램 계층에서 승인된 후보 사건을 LLM에 전달하여, LLM이 프롬프트로 작성된 전략과 문맥에 따라 행동이 필요한지 판단합니다. 의미 계층은 동시에 인간을 위한 자연어 확장 지점으로 작용하여, 언제든지 프롬프트 스위치나 새로운 전략을 추가할 수 있도록 합니다. 아래 그림과 같이:

두 단계 필터링: 먼저 프로그램 계층 전략이 대부분의 무관한 메시지를 걸러내고, 그 다음 의미 계층 전략이 판단합니다.

3.2 사건 라우팅

2절에서 소개된 전역 Router 계층은 채널 간의 연속성을 유지하는 역할을 하지만, 이미 할당된 작업의 각 후속 사건이 여전히 Router 계층을 통해 전달되어야 한다면, 이 전역 노드는 여전히 많은 부하를 감당해야 하며 시스템의 응답 지연을 증가시킵니다. 따라서 Fast / Slow Path는 필터링된 사건 라우팅에도 동일하게 적용됩니다. 전역 Router 계층은 새로운 작업의 콜드 스타트 및 작업 간 조정만 담당하며, 이미 소속 관계가 결정된 후속 사건은 프로그램이 직접 해당 Worker 세션으로 전송하여 Router 계층을 통해 전달할 필요가 없습니다.

실제 작업 흐름에서 동일한 GitHub Pull Request, 동일한 IM 주제 또는 동일한 이메일 스레드의 연속 사건은 사건 흐름, 즉 Thread를 구성합니다:

Thread 예시: 동일한 IM 주제 또는 동일한 GitHub Pull Request 아래의 연속 Trigger가 하나의 Thread를 구성합니다.

Router 계층이 특정 Thread의 초기 사건에 따라 Worker Session을 생성한 후, 해당 Worker는 직접 해당 Thread를 구독하여 사건 라우팅을 아래 그림과 같이 두 경로로 나눕니다:

• 구독됨(빠른 경로): 동일한 Thread의 후속 사건은 프로그램이 구독된 Worker로 직접 전달되며, Router 계층이 다시 도구를 호출하여 전달할 필요가 없습니다. 새로운 사건이 현재 작업의 범위를 초과하면 Worker는 구독을 취소하거나 Router 계층에 다시 배정할 수 있습니다.

• 구독되지 않음(느린 경로): Router 계층은 여전히 모든 사건을 관찰하여 전역 상태를 파악할 수 있지만, 구독되지 않은 새로운 사건의 판단 및 배정만 담당합니다.

구독 및 직통: 초기 사건이 Router 계층을 통해 Worker를 생성하고 구독을 설정하며, 동일한 Thread의 후속 사건이 해당 Worker로 직접 전송됩니다.

또한, Thread와 Worker 간의 구독은 다대다 관계입니다. 하나의 Worker는 동시에 여러 관련 Thread를 구독할 수 있으며, 동일한 Thread는 여러 Worker에 의해 구독될 수 있습니다. 여러 Worker가 동일한 작업 환경이나 논의에서 교차할 경우, 해당 Thread의 새로운 사건은 구독한 모든 Worker에게 동시에 전달되어 점대점 통신이 필요 없으며 서로의 작업을 알게 되고 스스로 충돌을 해결할 기회를 갖게 됩니다. 출력 측면에서 Worker는 여전히 중요한 결론을 Router 계층에 보고하며, Router 계층이 사용자에게 통합적으로 응답하고 전역 기억을 동기화합니다.

3.3 문맥 조직

사건이 필터링 및 라우팅을 거쳐 목표 Session에 들어간 후, 다음 문제는 모델의 문맥 창에 얼마나 많은 정보를 주입해야 하는가입니다. 시스템 입력이 제한된 인간 프롬프트에서 환경이 지속적으로 생성하는 반구조화된 사건으로 전환됨에 따라, 도구 호출 및 사건 주입의 구조 설계가 더욱 중요해졌습니다. 너무 많은 정보를 주입하면 창을 차지하고 모델의 주의력을 희석시키며, 너무 적은 정보를 주입하면 모델이 도구를 반복적으로 호출하여 읽어야 하므로 실행 단계를 증가시킵니다. 문맥 창을 낭비하는 것은 모델의 지능을 낭비하는 것입니다.

이를 위해 우리는 제한된 문맥 창을 Cache로 관리할 수 있습니다. 컴파일 최적화 및 컴퓨터 시스템의 개념을 차용하여, 문맥 주입 설계는 두 가지 기본 작업으로 요약될 수 있습니다. Inline은 최근에 사용될 가능성이 높은 정보를 현재 문맥 창에 직접 인라인으로 삽입하여 추가 도구 호출 왕복을 줄이는 것을 의미합니다. Spill은 창 예산을 초과하거나 저빈도로 사용되는 전체 정보를 문맥 창 밖에 남겨두고, 창 내에서는 참조나 요약만 보유하여 모델이 필요에 따라 읽을 수 있도록 하는 것을 의미합니다.

컴퓨터 시스템 설계에서 고전적인 지역성(Locality) 개념을 결합하여, 우리는 Inline & Spill을 통해 사건 주입 및 도구 호출을 점진적으로 최적화할 수 있습니다:

1. 최소한의 정보로 시작: 처음에는 현재 객체의 ID와 내용 요약만 제공합니다.

2. 지역성을 활용하여 관련 정보를 점진적으로 Inline: 최근에 사용될 가능성이 높은 정보를 문맥에 Inline하여, 먼저 밀접하게 관련된 객체의 ID를 첨부하고, 그 다음 시공간적으로 인접한 내용을 추가합니다. 예를 들어 내용의 앞 50자, IM 메시지의 앞뒤 인접 메시지 및 응답한 메시지, 또는 코드 댓글이 있는 리뷰 논의의 인접 댓글을 포함합니다.

3. 상한을 초과하면 Spill: 모든 내용을 Inline으로 처리할 수 없는 긴 콘텐츠에 대해 더 작은 길이 상한을 설정하고, 초과 부분은 창 밖으로 Spill합니다. 간단하고 직접적인 방법은 초과 부분을 잘라내고 계속 읽을 수 있는 진입점을 남기는 것입니다. 모델이 전체 콘텐츠가 필요할 때 도구를 호출하여 읽습니다.

또한, 많은 후속 사건이 Worker를 통해 직접 연결되고 시스템이 장기간 운영되면서 많은 역사적 작업을 축적한 경우, Router 계층은 모든 작업의 전체 역사 기록을 자신의 컨텍스트 창에 넣을 수 없으며, 사용자가 채널을 넘어 특정 오래된 작업을 언급할 때 컨텍스트를 찾아야 합니다. Inline 및 Spill을 시스템의 다양한 객체에 일관되게 적용하면 필요에 따라 확장할 수 있는 다중 점검 검색 메커니즘인 체인 리콜(Chain of Recall)을 얻을 수 있습니다. 이 체인 리콜 과정은 Router 계층이 긴 과정에서 이전 정보를 잃어버리는 문제를 완화합니다. 아래 그림과 같이:

체인 리콜: 매번 리콜되는 객체는 다음 점프 관련 객체의 ID를 Inline으로 포함하여 참조 관계를 따라 점진적으로 컨텍스트를 확장할 수 있도록 지원합니다.

구체적으로, 시스템은 Trigger, Thread 및 Worker Session과 같은 객체에 고유 ID를 부여하고, 주입 시 밀접하게 관련된 객체의 ID를 Inline으로 포함시켜 이러한 객체가 하위에서 참조 그래프를 구성하도록 합니다. 매번 도구를 호출하여 리콜되는 객체 자체도 Inline 및 Spill을 따르기 때문에, 반환 결과에는 다음 점프 관련 객체의 요약 및 ID가 Inline으로 포함되어 모델은 현재 사건에서 출발하여 참조 관계를 따라 점진적으로 필요에 따라 컨텍스트를 리콜할 수 있습니다.

예를 들어 현재 메시지에서 위치 Thread를 읽고, Thread에 Inline된 ID를 통해 관련 Worker Session을 추적한 다음, 해당 Worker와 관련된 또 다른 코드 리뷰 Thread를 찾습니다.

3.4 사전 조치

컴퓨터 시스템의 투기적 실행(Speculative Execution) 아이디어를 차용하여, Agent는 결과가 채택될지 불확실할 때 환경 신호에 따라 백그라운드에서 미리 시도할 수 있습니다. 추가적인 백그라운드 계산력을 소모하여 인간의 대기 및 개입 비용을 줄입니다. 결과가 가치가 있으면 전달하고, 가치가 없으면 버립니다.

개인 비서 시나리오에서 회의 초대 이메일이나 할 일 메시지를 받으면, Agent는 먼저 백그라운드에서 일정 충돌을 확인하고 관련 배경 자료를 수집하며 답변 초안을 준비할 수 있습니다. 사용자가 검토한 후 바로 확인하여 발송할 수 있습니다. 연구 협업 시나리오에서도 마찬가지입니다. 예를 들어, 우리는 회사의 DeepSeek Harness 내부 사용자 그룹에 "조용한 재현 및 수정" 전략을 구성했습니다: 그룹에서 누군가 문제를 피드백하거나 변경 방안을 논의할 때, Agent는 먼저 백그라운드에서 재현을 시도하고 수정 방안을 찾습니다. 문제를 확인하고 간단한 수정 방안을 찾은 후에만 결과를 사용자에게 전달하고, 그렇지 않으면 전 과정에서 조용히 유지합니다.

투기적 실행 예시: 그룹 내에서 해결 방안을 논의하는 동안 Super-agent는 이미 백그라운드에서 수정 Pull Request를 제출했습니다.

4. 사람을 위한 상호작용

제2절의 이중 구조는 컨텍스트 측면에서 채널 간의 연속성을 보장하지만, 실제 인간-기계 상호작용 경험에서 연속성과 효율성을 동시에 달성하기 위해서는 상호작용 방식과 상호작용 채널에서 두 가지 문제를 해결해야 합니다: 첫째, 비동기 ReAct Loop를 통해 백그라운드에서 소요되는 작업이 전면 대화에 대한 차단을 제거하여 세션이 이전 명령이나 작업이 완료될 때까지 기다리지 않고 언제든지 새로운 지시를 받을 수 있도록 하는 방법(4.1절); 둘째, 상호작용이 사용자가 익숙한 다양한 작업 채널에서 발생할 때 시스템의 출력 방식이 해당 채널의 대역폭 및 인간의 사용 습관에 맞추어지는 방법(4.2절).

4.1 전이중 상호작용

고전적인 ReAct Loop에서 모델이 동기화된 run() 도구 호출을 시작하면, 루프는 도구 실행이 완료되고 최종 결과가 반환될 때까지 차단됩니다. 이 기간 동안 세션은 새로운 사용자 입력에 응답할 수 없습니다. 이러한 차단을 제거하기 위해 대화를 일문일답의 반이중 모드에서 전이중 모드로 전환해야 합니다. 아래 그림과 같이:

고전적인 ReAct Loop와 비동기 ReAct Loop 비교: 비동기 호출은 즉시 시작(Started) 알림을 반환하고, 백그라운드 도구 실행 기간 동안에도 새로운 메시지에 응답할 수 있습니다.

이를 위해, 우리는 시간이 소요되는 명령 및 하위 작업 도구 호출을 비동기 start() 및 stop()으로 변경하여 비동기 ReAct Loop를 구성합니다. 모델이 start()를 호출하면 즉시 "시작됨(Started)"이라는 반환을 받고, 루프는 더 이상 해당 도구를 기다리지 않습니다. 백그라운드 도구 실행이 완료된 후, 시스템은 최종 결과를 새로운 사건 메시지로 세션에 전달합니다. 동시에, 모델은 컨텍스트에 따라 stop()을 호출하여 실행 시간이 너무 긴 백그라운드 명령을 적극적으로 종료할 수 있습니다.

이로 인해 전면 대화 응답과 백그라운드 작업 실행이 분리되어 Agent는 백그라운드에서 시간이 소요되는 작업을 실행하는 동시에 인간 입력에 응답할 수 있습니다. 새로운 입력은 현재 추론 단계가 끝난 후 즉시 처리되며, 백그라운드 도구가 완료될 때까지 기다릴 필요가 없습니다.

이 비동기 작업 메커니즘은 DeepSeek Harness에서 구현되었지만 기본적으로 활성화되어 있지 않습니다.

4.2 다중 채널 상호작용

다양한 작업 채널은 서로 다른 정보 밀도와 상호작용 습관을 가지고 있으며, 시스템의 출력은 이에 맞춰야 합니다. 단일 사용자 단말을 위한 상호작용 방식을 그룹 채팅으로 직접 가져오고, 긴 추론 과정과 밀집된 도구 호출을 그대로 출력하면 다인 협업에서 정보 과부하를 초래하기 쉽습니다.

Super-agent에서는 이중 구조가 일부 문제를 해결했습니다: 특정 작업에서 긴 추론 과정과 밀집된 도구 호출은 Worker Session 내부에 격리되어 외부 채널에 직접 출력되지 않으며, Router 계층이 외부 상호작용을 통합적으로 담당합니다. 이 기반 위에 시스템은 사용자가 일상적으로 사용하는 다양한 작업 환경에 접속하고, 프롬프트를 통해 서로 다른 채널에 맞춘 상호작용 규범을 맞춤화해야 합니다:

• IM 등 즉시 통신 채널: 낮은 방해의 경량 커뮤니케이션에 중점을 두며, 인간 동료처럼 결정이나 수락이 필요할 때만 알림을 보내고, 직접적인 질문을 하고 간단한 결론을 제공합니다. 우리가 검증한 간단하고 효과적인 강제 규칙은 단일 응답이 100단어를 초과하지 않도록 하는 것입니다.

• GitHub, 이메일 및 문서 등 비동기 채널: 구조화되고 높은 정보 밀도의 비동기 전달에 중점을 두며, 예를 들어 Pull Request를 생성하거나 업데이트할 때 프로젝트 규범에 따라 완전한 문제 배경, 변경 설명 및 검증 결과를 작성하거나 개인 비서 시나리오에서 구조화된 이메일 및 문서 요약을 직접 초안합니다.

5. 계산, 상태 및 환경의 분리

현재의 로컬 Agent는 기본적으로 Agent Loop를 추진하는 계산, 지속적으로 저장해야 하는 세션 상태, 코드 저장소 및 로컬 도구 체인과 같은 실행 환경을 동일한 장치에 결합합니다. 장치가 절전 모드에 들어가거나 오프라인이 되면 Agent는 실행을 중지하고 다른 장치의 환경에 접근할 수 없습니다. Super-agent가 항상 온라인 상태를 유지하고 다양한 실제 작업 환경에 유연하게 접속할 수 있도록 하려면, 컴퓨터 시스템의 저장-계산 분리(Compute-Storage Separation) 아이디어를 차용하여 이 세 가지의 결합을 두 단계로 분리할 수 있습니다: 첫 번째 단계는 Agent Loop를 추진하는 계산과 지속 가능한 세션 상태를 분리하여 Agent가 단일 장치의 생애 주기 제한에서 벗어나 클라우드에서 항상 온라인 상태를 유지하도록 합니다(5.1절); 두 번째 단계는 클라우드의 Agent Loop와 상태가 많은 실행 환경을 분리하여 실제 작업 환경을 원래 위치에 두고 장치 간 접근을 지원합니다(5.2절).

5.1 계산과 상태 분리

Agent Loop를 추진하는 계산은 무상태로 만들 수 있으며, 지속적으로 저장해야 하는 것은 세션 상태입니다. 따라서 첫 번째 분리는 Agent Loop를 추진하는 계산을 클라우드의 무상태 탄력적 계산 컨테이너에 넣고, 세션 등 지속 가능한 상태는 데이터베이스에 저장하는 것입니다. 무상태 계산 컨테이너는 수평 확장, 재시작 또는 교체가 가능하며, 세션과 작업의 연속성은 지속 가능한 저장소에 의해 보장되어 Agent가 단일 로컬 장치의 생애 주기 제한에서 벗어나 클라우드에서 항상 온라인 상태를 유지할 수 있습니다.

5.2 계산과 실행 환경 분리

Agent Loop와 세션 상태가 클라우드에 상주하게 되면, 다음 문제는 작업에 필요한 실행 환경에 접근하는 방법입니다. 모델 작업에 필요한 컨텍스트의 상당 부분은 도구 호출을 통해 코드 저장소, 로컬 파일, 의존 서비스 등 실행 환경에서 가져와야 하며, 이런 의미에서 광의의 컨텍스트는 실행 환경 자체를 포함합니다.

이 문제를 둘러싼 일반적인 접근 방식은 두 가지입니다: 하나는 클라우드에서 샌드박스를 시작하고 코드를 가져와 환경을 재구성하고 동기화하려고 시도하는 것이지만, 실제 작업 환경은 종종 제출되지 않은 로컬 수정, 개인 자격 증명, 내부 네트워크 서비스 의존성 및 특정 하드웨어 또는 도구 체인을 포함하고 있어 기술적으로 이러한 환경을 동기화하는 것은 비용이 매우 높고 정보 누락이 발생하기 쉽습니다; 다른 하나는 사용자에게 로컬 환경을 포기하고 클라우드에서 작업하도록 요구하는 것이지만, 많은 사용자에게는 이동 비용이 너무 높습니다.

복사하고 동기화하기 어려운 것이 환경 자체라면, 실행 환경이 Agent Loop와 함께 클라우드로 올라갈 필요는 없습니다. 두 번째 분리는 Agent Loop가 클라우드에서 실행되도록 하고, 상태가 많은 실행 환경은 원래 위치에 두며, 세션 상태를 저장하지 않는 경량 데몬을 단말 측에 배포하여 명령 실행 및 결과 반환만 담당하게 합니다. 이는 실행 환경을 클라우드 외부에 두고 Agent가 필요에 따라 그 안의 컨텍스트를 읽도록 하는 것입니다.

이 아이디어는 Anthropic이 제안한 "두뇌와 손의 분리"(Decoupling the brain from the hands)와 일치하며, 하네스를 무상태로 유지하고 세션 로그를 하네스 외부에 저장하며 통합 인터페이스를 통해 필요에 따라 실행 환경에 접속하도록 합니다. 두 가지의 차이는 시나리오에 있습니다. 그 논문은 관리 서비스에 대해 설명하며, 주로 필요에 따라 생성된 샌드박스와 고객 VPC 내의 자원에 대해 논의합니다; 여기서는 먼저 사용자가 일상적으로 사용하는, 간헐적으로 온라인 상태일 수 있는 개인 기계에 접속해야 하며, 그 위에는 제출되지 않은 수정과 로컬 자격 증명이 있습니다. 따라서 이 설계는 BYOM(Bring Your Own Machine)을 지원하여 사용자가 일상적으로 사용하는 개발 기계나 개인 컴퓨터를 클라우드 Agent에 연결할 수 있도록 하며, 클라우드에서 호스팅되는 기계나 필요에 따라 생성된 계산 환경에도 접속할 수 있도록 지원합니다.

이로 인해 하나의 Agent는 단일 기계에 제한되지 않고, 다양한 실행 장치 간에 전환할 수 있으며, 작업 필요에 따라 환경을 선택하여 명령을 실행하고 환경 내의 컨텍스트를 가져올 수 있습니다. 심지어 사용자의 특정 개인 장치가 다시 온라인 상태가 되었을 때 클라우드 Agent가 자동으로 트리거하여 해당 장치에서 실행해야 하는 작업을 완료할 수 있도록 지원합니다. 아래 그림은 계산, 지속 상태 및 다양한 실행 환경이 두 단계로 분리된 구조를 보여줍니다:

저장 및 계산 분리와 실행 환경 분리: 에이전트 루프와 지속 상태가 클라우드에서 분리되며, 단말 측 데몬을 통해 다양한 실행 환경에 필요에 따라 접속합니다.

6. 감시자

지속적인 연결을 구현하기 위해서는 5절의 저장 및 계산 분리 외에도 시스템이 장기간 실행 중에 비정상 상태에서 자동으로 복구될 수 있어야 합니다. 지속적인 연결을 가진 분산 시스템은 주 시스템 내부의 논리만으로는 장기적으로 신뢰할 수 있는 운영을 보장하기 어렵기 때문에, 주 시스템 외부에 독립적인 외부 제어 루프인 Control Loop을 도입해야 합니다.

또한, 에이전트 시스템에서는 전통적인 프로세스 생존 탐지나 모니터링 스크립트만으로는 충분하지 않습니다. 많은 비정상 상태는 프로세스의 충돌이 아니라 모델이 실행 중 무효 루프에 빠지거나 목표에서 벗어나는 경우이기 때문입니다. 따라서 장기간 운영되는 에이전트 시스템은 기본 인프라의 생존을 모니터링하는 것뿐만 아니라 작업 자체의 진행 상황도 모니터링해야 합니다.

우리는 주 시스템 외부에 독립적인 감시자 세션을 구성하고, 정기적인 메시지로 이를 구동하여 외부의 Control Loop을 형성했습니다. 감시자는 인터페이스 오류 처리, 상태 복구 실패 등 기본 인프라 고장 외에도 모델이 각 워커의 실질적인 진행 상황과 방향이 전체 목표에서 벗어나는지를 판단합니다. 비정상 상태를 발견하면 즉시 개입하여 수정하고, 외부의 우발적 고장에 대해서는 정상으로 복구될 때까지 지속적으로 재검토합니다.

감시자 자체도 완전한 도구 능력을 가진 에이전트 세션이기 때문에, 유지보수자는 자연어로 고장 원인을 문의할 수 있으며, 주 시스템의 행동을 온라인으로 수정할 수 있습니다. 예를 들어, 프롬프트를 추가하거나 삭제하거나, 트리거 규칙을 조정하는 등의 작업을 수행할 수 있습니다.

7. 초기 실험

앞서 설명한 핵심 스케줄링 및 라우팅 설계를 평가하기 위해, 우리는 두 가지 측면에서 초기 실험을 진행했습니다: 먼저 엔드 투 엔드 실험을 통해 이중 구조, 구독 직통 및 단일 세션 솔루션(7.1 절)을 비교한 후, 라우터 층의 배치 처리(7.2 절)를 개별적으로 테스트했습니다. 실험은 합성 부하 및 단순화된 환경을 기반으로 하므로 일부 설정은 더 엄격하게 조정할 수 있으며, 아래 결과는 초기 참고용으로만 제공됩니다.

7.1 소거 실험

우리는 그룹 채팅과 GitHub CI 메시지 흐름을 동시에 구동하여 네 가지 엔드 투 엔드 솔루션을 테스트했습니다: 단일 실험에는 약 300개의 메시지가 포함되며, 그 중 약 20개는 작업 요청이고 나머지는 잡담, 후속 조치, 중지 및 CI 메시지입니다. 코딩 작업은 시간만 소모하는 도구로 대체되었으므로, 실험은 시스템의 스케줄링 및 협력 능력을 측정하는 것이지 개별 작업의 실행 능력을 측정하는 것이 아닙니다. 각 솔루션은 5회 반복 실행되었습니다.

비교한 네 가지 솔루션은 슈퍼 에이전트, 직통을 제거한 슈퍼 에이전트, 그리고 두 가지 프롬프트 구성 하의 단일 세션 + 서브 에이전트 도구입니다.

중립 프롬프트는 "적절할 때 작업을 위해 서브 에이전트를 사용하세요…"로 작성되었습니다.

프롬프트 우선 위임은 "채팅의 모든 메시지가 당신에게 도달하므로, 당신이 직접 실행하는 작업은 새로운 메시지로 인해 계속 중단됩니다. 각 작업을 자신의 서브 에이전트에게 위임하는 것을 선호하고, 자신은 작은 일만 하세요…"로 작성되었습니다.

작업 요청의 누적 도달 곡선과 네 가지 솔루션의 누적 완료 곡선(5회 실험 실행 평균; 메시지 간격 및 작업 시간은 1/4로 축소, 모델 호출 소요 시간은 실제 값)

각 솔루션은 5회 반복 실행되었습니다; 작업 완료 시간은 작업 요청부터 결과 메시지까지의 소요 시간을 나타냅니다.

작업 완료 시간을 보면, 슈퍼 에이전트의 p50과 p95는 각각 12.4분과 15.7분으로, 서브 에이전트 도구가 포함된 단일 세션보다 현저히 우수합니다. 그 이유는 서브 에이전트가 포함된 단일 세션이 실험 장면에서 프롬프트의 영향을 많이 받아, 주 세션이 종종 직접 작업을 수행하기로 결정하여 총 완료 시간이 길어지고 성능이 불안정해지기 때문입니다. 중립 프롬프트 하에서 모델은 5회 실행 중 한 번도 서브 에이전트를 호출하지 않았고, 모든 작업이 주 세션에서 진행되며 새로운 메시지에 의해 계속 중단되어 p95가 29.5분에 달했습니다; 프롬프트 우선 위임으로 변경한 후 모델은 5회 실행 중 4회 위임을 수행했으며, 완료 시간이 단축되었지만 여전히 슈퍼 에이전트보다 느렸고, 나머지 1회는 작업이 "매우 작다"고 판단하여 스스로 실행하기로 선택하여 그래프에서 보라색 긴 꼬리를 형성했습니다. 단일 세션에서 프롬프트 엔지니어링과 모델의 즉각적인 판단에 의존하는 것과 비교하여, 이중 구조는 라우터가 구체적인 작업을 직접 실행하지 않도록 하고, 워커가 구독한 스레드의 메시지만 수신하도록 하여 시스템 차원에서 이 문제를 완화했습니다.

시스템 오버헤드 측면에서, 여러 독립 세션을 유지하기 때문에 슈퍼 에이전트의 단일 실험에서 읽기 캐시 토큰이 단일 세션보다 높아져, 더 짧고 안정적인 완료 시간을 얻기 위해 더 많은 토큰 소모를 감수한 것입니다. 슈퍼 에이전트 내부에서 직통 메커니즘을 제거한 후, 작업 완료 시간은 전체 버전과 기본적으로 일치하지만, 단일 실험에서 라우터가 내려야 하는 결정이 약 30% 증가하여 총 읽기 캐시 토큰이 2323만에서 3177만으로 증가하여 약 37% 증가했습니다. 이는 실험 부하 하에서 직통 메커니즘이 작업 완료 품질 및 속도를 높이지 않지만, 라우터 세션에 상당한 토큰 및 추론 오버헤드를 절약했음을 나타냅니다.

7.2 라우터 층의 배치 처리

2.1 절에서 단일 상주 라우터 세션의 처리 한계와 배치 처리 메커니즘을 검증하기 위해, 우리는 라우터 층에 대한 스트레스 테스트를 개별적으로 수행했습니다: 라우터가 실제 모델을 호출하고, 워커가 모형 모델을 사용하며, 결정해야 할 트리거 도달 속도를 매분 약 1개에서 약 40개로 점진적으로 증가시켜 평균 배치 크기, 단일 요청 소요 시간 및 단일 결정의 분산 추론 시간을 관찰했습니다.

다양한 트리거 도달 속도에서 라우터 세션의 배치 크기, 단일 요청 소요 시간 및 단일 결정의 분산 추론 시간

8. 개방된 문제

2절에서 6절까지 소개된 다섯 개 모듈은 슈퍼 에이전트 운영을 지원하는 기본 구조를 구성하며, 7절의 실험은 다중 작업 동시 처리에서 핵심 스케줄링 및 라우팅 메커니즘의 효과를 검증했습니다. 이 시스템이 낮은 복잡도로 운영될 수 있는 이유는 현재 단계에서 일련의 공학적 및 장면 단순화를 수행했기 때문입니다. 이러한 단순화의 적용 범위를 초과할 경우, 이중 구조의 확장(8.1 절), 세션을 벗어난 인간-기계 협력(8.2 절), 맥락 경계 및 A2A(8.3 절), 그리고 보안 및 개인 정보 보호(8.4 절)와 관련하여 여전히 해결해야 할 몇 가지 문제가 있습니다.

8.1 이중 구조를 어떻게 확장할 것인가

앞서 설명한 "단일 상주 라우터 세션 + 구독 직통 + 워커 간 비직접 통신"의 단순화 조합을 통해, 우리는 현재 대부분의 일상 작업을 작은 공학적 비용으로 커버했습니다. 그러나 작업 규모가 확대되고 결합도가 높아져 단일 라우터 세션의 수용 범위를 초과할 경우, 구체적인 층 내 구조에 대한 결론은 없습니다. 라우터 층이 수평으로 분할해야 하는 시점, 세분화는 어떻게 이루어져야 하는지, 그리고 동일 층의 워커 간에 언제 직접 통신을 도입해야 하는지, 어떤 협력 토폴로지를 채택해야 하는지는 여전히 더 많은 장면에서 검증이 필요합니다. 동시에 시스템과 모델의 협동 설계(Co-design)도 탐색할 가치가 있는 방향으로, 라우터 층의 이벤트 판별, 배치 배포 및 맥락 회수 등의 작업에 대한 전문 훈련이 라우터 층의 처리량 및 결정 성능을 더욱 향상시킬 수 있습니다.

동시에, 앞서 설명한 상주 라우터 층은 참조 그래프 기반의 체인 회수를 통해 최근 작업 및 세션 기록의 필요에 따른 검색을 주로 해결합니다. 운영 주기가 한 달 이상으로 길어질 경우, 장기 기억이 확장성의 주요 병목이 됩니다.

8.2 세션을 벗어난 후 에이전트와 어떻게 협력할 것인가

앞서 설명한 이중 구조는 하위 다수의 세션 관리를 사용자에게 숨겨 세션이 더 이상 제품 설계의 주요 문제가 되지 않도록 했습니다. 그러나 하위 실행 세션이 더 이상 사용자 인터페이스의 세션과 직접적으로 대응하지 않게 되면, 사용자가 작업을 어떻게 제시하고 자연스러운 상호작용 및 프로젝트 관리 형식을 제공할 것인지가 새로운 문제가 됩니다. 우리는 채팅 창을 중심으로 한 상호작용이 어느 정도 경로 의존의 결과라고 생각합니다. 상호작용은 특정 도메인에 특화된 상호작용 인터페이스에서 더 많이 발생할 수 있습니다. 예를 들어, 본문의 사례처럼 슈퍼 에이전트가 GitHub의 이슈 및 풀 리퀘스트에서 직접 작업하도록 하는 것입니다. 세션은 사용자의 사용 습관에 따라 인터페이스에 남겨둘 수 있지만, 사용자가 보는 하나의 세션이 하위에서 반드시 하나의 세션에만 대응하지는 않을 수 있습니다.

동시에, 앞서 설명한 내용은 주로 인간이 작업 시작 및 결과 수용 단계에서의 상호작용에 대해 논의했습니다. 그러나 모델 능력이 빠르게 발전하는 과도기 동안 많은 작업은 여전히 인간이 중간에 참여해야 하며, 제품 설계에서 사용자가 중요한 세부 사항에 점진적으로 개입할 수 있는 것과 백그라운드에서 자율적으로 진행되는 효율성을 어떻게 조화시킬 것인지, 예를 들어 사용자가 백그라운드 실행 과정에서 언제든지 개입하거나 인수하거나 에이전트와 실시간으로 협력할 수 있도록 하는 것도 탐색할 가치가 있습니다.

전반적으로, 사용자가 필요한 프로젝트 관리 및 상호작용 형식은 특정 작업 분야와 개인 스타일과 밀접하게 관련되어 있으며, 최종 형태는 매우 맞춤화된 것이 될 가능성이 높습니다. DeepSeek Harness는 개방형 구조 설계를 채택하고 있어 이러한 맞춤화를 더 쉽게 지원할 수 있습니다.

8.3 맥락 경계를 어떻게 구분하고 A2A 협력을 진행할 것인가

앞서 논의된 내용은 항상 단일 슈퍼 에이전트 인스턴스 내부의 설계를 다루었으며, 기본적으로 그 서비스 범위 내의 정보가 동일한 전역 맥락에 집계된다고 가정했습니다. 그러나 사용 범위가 개인 또는 소규모 팀에서 더 큰 조직으로 확장될 경우, 조직이 슈퍼 에이전트를 어떻게 배치할지를 결정하는 것은 실제로 맥락 공유 및 격리의 경계를 구분하는 것입니다. 공유해야 할 맥락의 범위는 동일한 인스턴스를 공유해야 하며, 격리해야 할 범위는 각각 독립적으로 배치해야 합니다.

더 나아가, 조직 내 또는 조직 간에 서로 격리된 여러 인스턴스가 존재하는 경우, 예를 들어 각 구성원의 개인 비서와 팀이 공유하는 슈퍼 에이전트 간의 경우, 이때 경계를 넘는 협업은 에이전트 간 통신(A2A, 특정 프로토콜을 지칭하지 않음)으로 정의된다. 서로 기본적인 맥락을 공유하지 않고 각기 다른 권한 경계를 대표하는 전제 하에, 안전하고 신뢰할 수 있는 A2A 통신 및 협업을 어떻게 실현할 것인지는 여전히 추가적인 탐색이 필요하다.

8.4 안전성과 개인 정보 보호 보장 방법

제 3 절의 이벤트 기반 설계는 에이전트가 더 넓은 환경에 의해 구동될 수 있게 하지만, 신뢰할 수 없는 입력에 접촉할 위험도 증가시킨다. 안전성과 개인 정보 보호 문제를 잘 해결할 방법이 없다면, 슈퍼 에이전트는 매우 작고 신뢰할 수 있는 범위 내에서만 작동할 수 있다.

예를 들어, 제 5 절에서는 에이전트 루프를 클라우드에 배포하고 다양한 실행 장치에 경량 데몬을 설치하는 설계를 제안하는데, 이 설계는 기본적으로 클라우드와 단말 환경이 서로 신뢰할 수 있다는 전제 하에 이루어진다. 그러나 클라우드의 에이전트 루프가 외부 환경 이벤트에 지속적으로 접속하고, 단말 장치에 개인 코드, 민감한 데이터 및 로컬 자격 증명이 존재할 경우, 이러한 장치 간 연결은 상당한 안전 및 개인 정보 보호 위험을 초래한다. 클라우드의 에이전트 루프가 서버 침입이나 프롬프트 주입으로 인해 해킹당할 경우, 연결된 모든 단말 장치는 제어될 위험에 처하게 된다.

또한, 클라우드가 해킹되지 않더라도, 단말 환경의 자격 증명이 모델의 맥락에 들어갈 수 있는 한, 정상 실행 과정에서도 자격 증명 유출의 위험이 존재한다. 따라서 에이전트가 자격 증명 자체에 전혀 접촉하지 않고도 자격 증명을 사용할 수 있도록 하는 적절한 메커니즘을 설계해야 한다. 이 아키텍처가 더 넓은 응용으로 나아가려면, 다양한 환경에서 맥락을 호출할 수 있는 동시에 위의 안전 및 개인 정보 보호 문제를 해결해야 한다.

9. 결론

전체 설계를 되돌아보면, 우리는 전혀 새로운 이론을 제시한 것이 아니라, 컴퓨터 시스템의 고전적인 공학 사상을 에이전트 시스템 구축에 적용한 것이다. 구체적인 구현 방식은 기술 발전에 따라 진화하겠지만, 우리는 그 배후의 시스템 설계 사고가 더 장기적인 참고 가치를 지닌다고 생각한다. 현재 우리는 이 사고를 바탕으로 DeepSeek Harness를 기반으로 한 내부 슈퍼 에이전트 인스턴스를 지속적으로 운영하고 있으며, 일상적으로 문제 재현 및 수정, 코드 검토 응답 및 DeepSeek Harness 자체의 반복 작업에 참여하고 있다.

서두에서 언급했듯이, 대형 모델이 단일 작업을 수행하는 데 있어 인적 개입이 점점 줄어들면서, 생산성을 더욱 향상시키는 데 있어 병목 현상이 사람의 주의력으로 전환되고 있다. 이중 구조, 이벤트 기반, 비동기 다채널 상호작용, 저장 및 계산 분리, 외부 감시자를 통해 시스템은 기본적으로 복잡한 세션 관리 및 맥락 동기화를 인수하여 인간이 구체적인 실행 세부 사항에서 더 높은 수준의 결정 및 수용으로 나아갈 수 있도록 한다.

이러한 형태에서 에이전트는 더 이상 지시를 수동적으로 기다리는 대화 창구가 아니라, 디지털 환경에서 지속적으로 온라인 상태인 자율 협력자로 진화한다: 개인을 위해, 그것은 장치 간 협력을 통해 일상 업무를 처리하는 개인 비서가 될 수 있다; 팀을 위해, 그것은 연구 개발 작업 흐름에 통합되어 구체적인 작업을 수탁하고 추진한다. 우리는 모델의 능력과 기본 시스템 아키텍처의 공동 진화에 따라, 이러한 더 자율적인 작업 방식이 인간-기계 협력의 일반적인 형태가 될 것으로 믿는다.

본문의 일부 설계는 dsh-superagent-prototype에서 구현되었다. 이 플러그인은 기술 경로를 검증하기 위해 제공된 프로토타입일 뿐, DeepSeek의 공식 제품이 아니다.

저자 및 감사의 말씀

본 문서는 DeepSeek Harness 팀의 공동 실천에서 비롯되었다. 유자 차오가 시스템 구현과 본문 작성을 완료하였고, 환치 차오, 쭈이 천, 시에팅 추, 티안이 추이, 시위안 펑, 유동 한, 커신 리우, 시춘 리우, 게시 로우, 이판 시, 통루이 시옹, C.C. 유, 지야 장, F. 저우 등이 검토 및 논의에 참여하고 피드백을 제공하였다. 시스템의 구현과 글의 형성은 팀의 일상적인 소통과 축적 없이는 불가능하였다.