DeepSeek Harness 개발자 프리뷰
전 세계 에이전트 하네스 개발자를 대상으로 소스 코드가 포함된 개발자 프리뷰를 공개함
GitHub에서 소스 코드 보기와 개발자 문서를 통해 바로 확인 가능
GitHub의 프로젝트 페이지와 빠른 시작 문서도 제공됨
$ npx @deepseek-ai/dsh web$ git clone https://github.com/deepseek-ai/deepseek-harness에이전트의 모든 기능을 교체·재조합할 수 있는 플러그인으로 구성함
모델이 에이전트의 핵심이라면 하네스는 환경을 이해하고 도구를 사용하며 실제 환경에서 계속 작업하도록 지원함
Cordis 플러그인 시스템을 기반으로 모델, 도구, 스킬, 세션, 샌드박스, 스토리지, 루프, 스케줄링, UI를 플러그인으로 제공
Cordis 커널이 플러그인의 마운트·언마운트와 의존성을 관리하고, 서비스와 이벤트를 통해 플러그인끼리 연동함
DeepSeek Harness 소스 코드를 수정하지 않고 설정만으로 원하는 기능을 선택·교체·확장 가능
목적에 따라 Standard·Code·Minimal·Creator의 네 가지 런타임 모드를 제공함
Standard mode는 파일 편집, 셸, 파일·웹 검색, 스킬, 계획, 목표, 서브에이전트, 워크플로를 포함한 전체 도구 세트를 제공
Code mode는 Standard mode의 모든 기능을 Code Mode SDK로 노출해 모델이 여러 단계와 여러 차례의 도구 호출을 하나의 TypeScript 프로그램으로 조율 가능


Minimal mode는 모델을 최소 환경에서 벤치마킹할 수 있도록 persistent bash와
str_replace_editor만 유지Creator mode는 Standard mode 기능에 현재 런타임 검사, 메모리 내 Cordis 플러그인 실험, 사용자 지정 에이전트 프리셋 제작 안내를 추가하며 플러그인을 결합해 새 모드를 만들 수 있음
Cordis 기반 구성을 통해 런타임 기능을 소스 변경 없이 조합함
dsh-demo Creator mode에서 만들고 싶은 구성을 설명하고 플러그인을 실험해 사용자 지정 프리셋으로 결합 가능

모델이 접한 모든 정보를 append-only 세션 로그에 기록해 실행 과정을 추적 가능
시스템 프롬프트, 추론, 도구 호출과 결과, 서브에이전트 스케줄링, 모든 컨텍스트 주입이 기록됨
Trajectory 화면에서 출처별 기록을 살펴볼 수 있으며 재개, 포크, 검색, 재생이 모두 같은 이벤트 스트림을 사용

Node.js가 있으면 Web UI를 즉시 실행하거나 전체 소스를 설치할 수 있음
빠른 시작 명령은
npx @deepseek-ai/dsh web전체 소스는
git clone https://github.com/deepseek-ai/deepseek-harness로 복제한 뒤 저장소의 설정 안내를 따르면 됨
현재도 개발자 프리뷰 단계라 핵심 플러그인과 API가 계속 바뀔 예정임
에이전트 하네스를 만드는 개발자들이 테스트 중이며, 재사용·조합 가능한 오픈소스 인프라를 중심으로 DSH 플러그인 생태계를 확장할 계획
GitHub 저장소와 개발자 문서에서 참여 및 개발 정보를 확인 가능
source https://deepseek.com/harness/en/
HN에서는 실행 과정을 빠짐없이 추적하는 기능과 ‘모든 기능을 플러그인으로 구성한다’는 설계를 가장 중요한 특징으로 봤다. 시스템 프롬프트와 도구 호출, 컨텍스트 주입, 하위 에이전트 작업을 하나의 세션 기록에서 살펴보고 재개·분기·재생할 수 있다는 점은 높은 평가를 받았다. 모델이 무엇을 보고 어떤 작업을 수행했는지 확인해야 도구와 프롬프트를 개선할 수 있다는 실무 경험이 이런 반응의 바탕에 있다.
플러그인 구조를 보는 시선은 활용 방식에 따라 갈렸다. 실행 중 기능을 불러오거나 제거하고, 초기화 과정에서 생긴 연결과 등록 항목을 정리하며, 의존 관계까지 처리하는 Cordis의 생명주기 관리는 흥미로운 시도로 받아들여졌다. 최소 구성에서 출발해 로컬 모델이나 여러 제공자를 연결하고 필요한 기능만 확장하려는 개발자에게는 매력적이다. 실제로 소규모 파이썬 프로젝트와 로컬 모델을 연결하기 쉬웠다는 사용 경험도 나왔다.
반면 플러그인 생태계가 커지면 버전 충돌과 방치된 확장 기능, 일관성 없는 품질, 공급망 보안이 운영 부담으로 돌아온다는 우려도 컸다. 의존성이 거의 없는 플러그인까지 복잡한 주입과 정리 체계를 적용할 실익이 크지 않다는 지적도 있었다. 설치 후 커진 용량과 많은 의존성, Node.js·TypeScript 기반 선택을 두고는 경량성과 보안을 의심하는 반응이 이어졌다.
중요한 것은 실제 작업 품질과 운영 비용이다. 같은 모델을 서로 다른 하네스에 연결했을 때 결과, 토큰 사용량, 세션 관리, 장애 분석 편의가 어떻게 달라지는지 보여주는 비교 자료가 아직 부족하다는 요구가 반복됐다. 개발사도 호환성이 깨질 수 있는 초기 프리뷰라고 밝힌 만큼, 지금은 추적 기록이 디버깅에 충분히 유용한지, 플러그인 확장이 복잡성과 의존성 비용을 상쇄하는지부터 작은 프로젝트에서 확인할 단계다.
