DeepSeek Super-Agent: 정의, 작동 방식, 아직 누락된 사항3 min read

코딩 에이전트 3개를 동시에 열어보면 문제점을 느낄 수 있습니다. 하나는 결정을 기다리고 있고 하나는 20분 전에 완료되었으며 어느 것이 인증 수정을 가지고 있는지 이미 잊어버렸습니다. DeepSeek의 Harness 팀은 이에 대해 숫자를 기록했습니다. 경험상 한 사람은 한 번에 3~5개의 활성 에이전트 세션만 따라갈 수 있습니다. 그 지점을 지나면 모델은 더 이상 병목 현상이 발생하지 않습니다. 당신은.

2026년 10월 31일에 팀은 슈퍼 에이전트라고 부르는 디자인 기사를 게시하고 dsh-superagent라는 프로토타입을 오픈 소스로 공개했습니다. 하나의 GitHub 저장소에 대한 사전 코딩 에이전트입니다. 하나의 오래 지속되는 라우터 세션은 사람들과 대화하고 작업을 전달하며, 승인된 모든 요청은 끌어오기 요청이나 질문으로 끝나는 자체 작업자 세션을 갖습니다. 저장소는 약 이틀 만에 별 12,000개를 돌파했습니다. README에는 이것이 연구 코드이지 공식 DeepSeek 제품이 아니라는 것이 무뚝뚝하게 나와 있습니다.

이 가이드는 프로토타입의 기능, 라우터 및 작업자 설계의 작동 방식, 벤치마크 수치가 증명하는 것과 증명하지 않는 것, 실제 저장소에 적용하기 전에 확인해야 할 사항을 알고 싶어하는 엔지니어와 팀 리더를 위한 것입니다.

세부 사항을 설명하기 전에 한 가지 참고하세요. “이 버그 수정”에 대한 작업자의 대답은 끌어오기 요청이며 GitHub는 이에 대한 좋은 곳입니다. 코드와 관련하여 에이전트가 생성하는 나머지 항목(근본 원인 기록, 테스트 요약, 리뷰어가 요청한 비교 테이블)은 배치하기가 더 어렵습니다.AgentGrid.io사람과 AI 에이전트가 하나의 라이브 버전, 속성 및 기록을 통해 문서, 앱 및 파일을 생성, 편집 및 공유하는 공유 작업 공간입니다. 우리는 거의 끝 부분에 맞는 곳으로 돌아옵니다.

DeepSeek Super-Agent는 무엇입니까?

두 가지가 함께 나타났습니다. 첫 번째는 긴 디자인 기사인 “슈퍼 에이전트 디자인 탐색: 보다 자율적인 에이전트 시스템을 향하여”입니다. 하네스 팀은 이를 중국어로 작성해 11월 1일 X에 기계 번역된 영어 버전을 게시했습니다. 조회수는 220만 회 이상입니다. 두 번째는 코드입니다.deepseek-ai/dsh-superagent-프로토타입, MIT 라이선스로 출시되었습니다.

슈퍼 에이전트 설계 탐색: 보다 자율적인 에이전트 시스템을 향하여

https://t.co/gwwIHtyCRQ

– DeepSeek 하네스(@DeepSeekHarness)2026년 11월 1일

새로운 모델이 아닙니다. dsh-superagent는 다음을 위한 번들입니다.DeepSeek 하네스, DeepSeek의 오픈 소스 에이전트 하네스로 회사는 전 세계 공개 미리보기로 설명합니다. 번들은 하나의 GitHub 저장소를 감시하고, 스위치를 켜면 Feishu 채팅을 합니다. 허용 목록에 있는 누군가가 에이전트에게 작업을 요청하면 에이전트는 작업 항목을 열고 해당 세션과 디렉터리에서 이를 실행하며 원래 대화로 응답합니다. 웹 패널에는 사람이 필요한 것만 표시됩니다.

이름은 생각보다 쉽습니다. DeepSeek의 제품 부서 소속이자 기사의 최종 리뷰어 중 한 명인 Cui Tianyi는 Zhihu 게시물에서 “슈퍼”는 위 첨자와 아래 첨자를 의미한다고 설명했습니다. 슈퍼 에이전트는 작업을 수행하는 에이전트 위에 레이어를 추가하는 반면, 하위 에이전트는 아래에 레이어를 추가합니다. 그것은 뛰어난 지능을 주장하는 것이 아닙니다.

README는 “공식 DeepSeek 제품이 아닌 참고용으로만 연구 프로토타입을 연구해 보세요.”라는 경고 메시지와 함께 시작됩니다. 엔지니어링의 대부분은 코딩 에이전트에 의해 수행되었으며 코드에 버그가 있을 수 있으며 기사의 일부 디자인은 향후 작업에 대한 지침이며 구현되지 않았다고 덧붙였습니다.

또 다른 DeepSeek 드롭: dsh-superagent

저장소의 GitHub 문제와 많은 에이전트의 PR을 병렬로 처리하는 에이전트 프레임워크로, 최대한 많은 가치를 제공하면서 사람의 관심을 최대한 덜 끌도록 설계되었습니다.

pic.twitter.com/XR73mIvA0V

– 레안드로 폰 웨라(@lvwerra)2026년 10월 31일

DeepSeek가 병목 현상이 인간의 관심이라고 말하는 이유는 무엇입니까?

이 글은 단순한 관찰에서 시작됩니다. 지난 1년 동안 코딩 에이전트는 단일 작업이 모델에 의해 제한될 만큼 충분히 향상되었습니다. 그러나 한 번에 여러 작업을 실행하면 한계가 당신에게로 옮겨집니다. 각 세션은 분리되어 있으므로 직접 세션을 전환하고 각 세션이 알고 있는 내용을 추적할 수 있습니다. CLI, MCP 또는 채팅 커넥터를 하나의 로컬 세션에 연결하면 새로운 이벤트에 대해 들을 수 있지만 여전히 긴 명령을 차단하고 다른 작업의 컨텍스트를 혼합하며 노트북이 절전 모드일 때 중지됩니다.

DeepSeek의 대답은 세션을 관리 단위로 취급하지 않는 것입니다. 슈퍼 에이전트가 갖춰야 할 네 가지 특성은 다음과 같습니다.

• 지속적.채팅이나 GitHub 댓글 등 이미 작업 중인 곳에서 대화하면 하나의 에이전트처럼 작동합니다. 채팅으로 플랜 A를 요청하고, 풀 리퀘스트 댓글에서 플랜 B로 전환하면 따라옵니다.
• 생산적입니다.여러 가지 복잡한 작업을 병렬로 실행하고 마지막 작업이 완료되기 전에 다음 명령을 수행합니다.
• 적극적.이벤트를 감시하고, 처리할 가치가 있는 작업에 대해 조치를 취하고, 그 외에는 조용합니다.
• 지속성.다시 시작하지 않고도 온라인 상태를 유지하며 장애로부터 복구됩니다.

저자는 단일 ReAct 루프가 네 가지를 모두 제공할 수 없으므로 품질은 모델 주변의 아키텍처에서 나와야 한다고 주장합니다. 이것이 기사의 실제 주제이며, Hesam이 공유한 아래의 시각적 설명은 한 페이지에서 전체 디자인을 빠르게 볼 수 있는 방법입니다.

다음은 Super-Agent에 대한 DeepSeek의 기사에 대한 시각적 설명입니다.https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP

– ℏεsam (@Hesamation)2026년 11월 1일

라우터와 작업자 설계는 어떻게 작동하나요?

스탠드업 중에 코드를 절대 작성하지 않는 훌륭한 엔지니어링 관리자를 생각해 보십시오. 는라우터모든 채널에서 모든 메시지를 수신하는 하나의 장기 세션입니다. 작업을 실행하지 않습니다. 메시지가 무엇을 요구하는지 결정하고, 작업자에게 새로운 작업을 전달하며, 관련된 사람들에게 모든 응답을 씁니다. 기사에는 쉘 도구 없이도 실행할 수 있으며 일반적으로 더 가볍고 빠른 모델이면 충분하다고 나와 있습니다.

에이노동자하나의 작업을 전담하는 격리된 컨텍스트와 전체 도구 세트가 포함된 별도의 세션입니다. 직원들은 절대로 사람들과 직접적으로 대화하지 않습니다. 라우터는 한 목소리로 응답을 유지하는 라우터에 상태를 보고합니다. 프로토타입에서 각 티켓은 자체 세션과 자체 디렉터리(일반적으로 git 작업 트리)를 가지며 작업자 수는 제한됩니다. 기본값은 한 번에 3개이며 1에서 16까지 조정 가능하며 한 사람의 메시지가 항상 전달될 수 있도록 추가 슬롯 하나를 비워 둡니다.

두 가지 세부 사항이 이를 작업 대기열 이상의 것으로 만듭니다.

후속 조치는 라우터를 건너뜁니다.작업자가 풀 요청이나 채팅 스레드를 소유하면 해당 스레드를 구독하게 됩니다. 라우터에서 추가 모델 호출 없이 나중에 댓글이 바로 해당 항목으로 이동합니다. 댓글이 다른 내용에 관한 것으로 판명되면 직원이 댓글을 돌려줍니다.

버스트가 일괄 처리됩니다.한 모델 중에 도착하는 트리거는 대기열에 추가되고 다음 호출에 함께 주입됩니다. 저자들이 그 효과를 측정해 보았는데, 아래 수치를 살펴보겠습니다.

또 하나의 대조점. 기사에서는 이를 에이전트 팀과 구별합니다. 에이전트 팀에서 리드는 하나의 복잡한 작업을 여러 단계로 나누고 해당 작업에 대해 작업하는 역할을 조정하는데, 이는 추론 부하가 큽니다. 슈퍼 에이전트 라우터는 독립적인 작업만 디스패치하고 높은 수준에서 해당 작업이 어떻게 관련되는지 추적합니다. 작품 자체를 분해하지는 않습니다.

아무도 묻지 않으면 어떻게 되나요?

이것이 바로 프로젝트의 철학이 현실화되는 지점입니다. 저장소의 첫 번째 문서에서는 원칙을 한 줄로 설명합니다. 즉, 사람의 관심을 최대한 적게 받고 최대한 많은 가치를 제공합니다. 에이전트가 보내는 모든 메시지는 동료의 주의를 끌기 때문에 사람이 행동해야 하거나 결과를 사용할 수 있을 때만 말하고, 요청을 받거나 팀이 작성한 규칙이 허용하는 경우에만 행동합니다.

이를 시행하는 게이트는 모델이 아닌 일반 코드입니다. 팀의 허용 목록을 기준으로 누가 요청하는지 확인하고 요청의 강도를 기록합니다.

그 관찰 모드는 제가 가장 좋아하는 부분입니다. 에이전트는 수행할 작업을 기록하는 것부터 시작하므로 팀은 평가 탭에서 해당 기록을 읽고 적절하다고 판단되는 경우에만 권한을 확대할 수 있습니다. 메시지, 의견 및 인용 문서는 결정에 대한 입력으로 처리됩니다. 에이전트가 수행할 수 있는 작업은 변경할 수 없습니다.

디자인 기사는 실제로 적극적인 작업이 어떤 모습인지 보여줍니다. 내부 DeepSeek Harness 사용자 그룹에서 팀은 “자동 재현 및 수정” 정책을 구성했습니다. 누군가 문제를 보고하거나 제안된 변경 사항에 대해 논의하면 에이전트는 백그라운드에서 이를 재현하고 수정 사항을 찾으려고 시도하며, 문제를 확인하고 간단한 수정 사항을 찾은 후에만 결과를 전달합니다. 그렇지 않으면 조용하게 유지됩니다. 이 기사는 또한 작성자가 확인했다고 말한 채팅 채널에 대해 각 응답을 100단어로 제한하는 무뚝뚝한 규칙을 제공합니다. 이와 대조적으로 GitHub에서는 풀 요청이 문제 배경, 변경 설명 및 확인 결과를 포함하여 밀도가 높아야 합니다.

기본적으로 에이전트가 게시하는 모든 GitHub 메시지는 “이것은 사람이 아닌 자동화된 에이전트에 의한 것입니다”라는 줄로 시작됩니다. 팀은 나머지 프롬프트와 함께 이를 편집할 수 있습니다.

벤치마크 수치가 유지되나요?

이 기사에는 작은 실험이 포함되어 있으며 저자는 이를 참고용으로만 언급하도록 주의했습니다. 4가지 디자인이 그룹 채팅 및 CI 메시지 스트림에서 나란히 실행되었습니다. 실행당 약 300개의 메시지, 약 20개의 실제 작업 요청, 각각 5개의 실행입니다. 코딩 작업은 단순히 시간만 소비하는 도구로 시뮬레이션되었으므로 테스트는 누구의 코드 품질이 아닌 일정 및 조정을 측정합니다.

표제 내용이 전체 이야기가 아니기 때문에 표를 두 번 읽으십시오. 라우터 설계는 p95 완료 시간을 단일 세션의 약 절반으로 줄였지만 캐시 읽기 토큰을 대략 2~4배 사용했습니다. 가장 흥미로운 행은 두 번째 행입니다. 통과 바로가기를 제거해도 작업이 더 빨라지거나 느려지는 것이 아니라 라우터가 약 30% 더 많은 결정을 내리고 37% 더 많은 토큰을 소모하게 됩니다.

내가 읽은 내용은 실제 결과가 단일 세션 행에 있다는 것입니다. 중립 프롬프트를 사용하면 모델은 5번의 실행 중 어느 경우에도 하위 에이전트를 호출하지 않았습니다. 자체적으로 작업을 수행했고, 새로운 메시지가 계속해서 방해를 받았으며, 가장 느린 작업에는 29.5분이 걸렸습니다. 위임하라는 메시지와 함께 5번 중 4번의 실행을 위임했고, 나머지 실행에서는 모델이 작업이 “작다”고 판단하여 자체적으로 수행했습니다. 단일 세션은 모델의 기분에 따라 다릅니다. 코드 실행이 허용되지 않은 라우터는 그런 실수를 할 수 없습니다.

라우터에 대한 별도의 스트레스 테스트를 통해 의사 결정이 필요한 이벤트의 도착률이 분당 약 1회에서 약 40회로 증가했습니다. 평균 배치는 1.0에서 2.8 이벤트로 증가했고, 요청당 시간은 2.5초에서 3.9초로 늘어났으며, 결정당 분할 상환 시간은 6.4에서 1.6초로 줄었습니다. 더 많은 이벤트가 쌓일수록 각각의 비용은 더 저렴해집니다. 저자가 말하는 한도는 컨텍스트 길이와 모델이 한 번에 얼마나 많은 이벤트를 정확하게 처리할 수 있는지에 따라 달라집니다.

DeepSeek는 방금 슈퍼 에이전트 프로토타입을 오픈 소스로 공개했습니다. 하나의 라우터 세션은 사람들과 대화하고 작업을 전달하며, 격리된 작업자는 GitHub 이벤트와 동시에 작업을 실행합니다. 자체 테스트에서 p95 완료 시간은 하위 에이전트를 사용한 단일 세션에 비해 29.5분에서 15.7분으로 단축되었습니다.

고래가 다시 오픈소스로 공개되었습니다.pic.twitter.com/mS4sRbHmyx

– 통통한 (@kimmonismus)2026년 11월 1일

이는 합성 작업에 대한 자체 보고 결과입니다. 그들은 일정 계획 아이디어가 타당하다는 것을 보여줍니다. 프로토타입이 버그를 더 빨리 수정한다는 것을 보여주지는 않습니다.

프로젝트에 가까운 사람들은 한계에 대해 뭐라고 말합니까?

출시 직후 DeepSeek 제품 부서의이자 디자인 기사의 최종 리뷰어 중 한 명인 Cui Tianyi가 디자인을 어떻게 보는지 썼습니다. 그의 프레임은 겸손하기 때문에 유용합니다. 그는 중앙 균형을 작업 전반의 연속성과 작업 처리량으로 명명합니다.

제한적으로 검토는 직접적입니다. 프로토타입은 제안된 디자인의 일부만 구현합니다. 그의 검토에 따르면 DeepSeek Harness에는 세션 전반에 걸쳐 장기 메모리가 내장되어 있지 않았습니다. 그리고 시스템은 회사 내부의 소규모의 신뢰할 수 있는 환경에서만 검증되었습니다. 기사 자체의 공개 문제 섹션에는 라우터 확장, 수개월에 걸친 메모리, 세션 없이 작업, 에이전트 간의 컨텍스트 경계 및 격리된 에이전트가 서로 통신하는 방법 및 보안이 나열되어 있습니다.

실행하기 전에 무엇을 확인해야 합니까?

문서는 대부분의 출시 게시물보다 더 솔직하며 경고를 요구 사항으로 처리할 가치가 있습니다.

• 근로자의 접근성이 넓습니다.라우터와 작업자에 대한 두 가지 권한 사전 설정은 다음과 같이 실행됩니다.danger-full-access운영자의 OS 사용자로. 계정 래퍼는 에이전트가 사용하는 GitHub 자격 증명을 선택하지만 문서에서는 작업자가 여전히 절대 경로로 프로그램을 실행하거나 홈 디렉터리를 읽을 수 있기 때문에 이것이 보안 경계가 아니라 기본값이라고 말합니다. 권장 사항은 에이전트의 자격 증명만 보유하는 전용 OS 계정입니다.
• 신뢰할 수 없는 입력은 공개 보안 질문입니다.기사에서는 즉각적인 주입이나 서버 침입으로 인해 클라우드 에이전트 루프가 손상되면 연결된 모든 장치에 접근할 수 있으며 모델의 컨텍스트에 들어가는 자격 증명이 유출될 수 있다고 경고합니다.
• 인간은 기본적으로 병합됩니다.에이전트는 자신의 계정으로 자동 병합을 활성화하지 않습니다. 자동 병합에는 전달 요구 사항 프롬프트에 이름이 지정된 두 번째 계정의 CLI가 필요하며 기본 지침에서는 변경된 줄이 200개 미만인 소규모 승인 풀 요청에 대해서만 허용합니다.
• 하나의 저장소를 중심으로 구축되었습니다.각 설정은 단일 GitHub 저장소를 감시하며, 중국에서 흔히 사용되는 직장 채팅 도구인 Feishu는 또 다른 일류 소스입니다.
• DeepSeek 하네스와 모델 제공자가 필요합니다.설정에는 Node.js 22.19 이상, pnpm, git 2.32 이상, tmux, Python 3.8 이상 및 GitHub CLI 2.48 이상이 나열됩니다. 모델 제공자를 구성하는 것은 운영자 단계입니다.
• 소음은 비용입니다.철학 문서에는 볼륨을 생성하기 위해 에이전트를 사용하지 말라고 나와 있습니다. 대량 풀 요청 및 브로드캐스트 메시지는 팀이 제공하는 것보다 더 많은 비용을 발생시킵니다.

메인 저장소를 위험에 빠뜨리지 않고 어떻게 시도하시겠습니까?

설정에는 여러 단계가 있으므로 프로젝트에서는 코딩 에이전트가 함께 수행하도록 요청합니다. README에 따르면 에이전트는 한 번에 하나의 짧은 질문을 하고 전체 계획을 한 번 표시한 다음 모든 것을 설치하고 구성합니다. 신중한 첫 번째 실행은 다음과 같습니다.

1. 일회용 저장소를 선택하세요전용 컴퓨터 사용자 또는 OS 계정. 자신의 로그인을 사용하지 마십시오.
2. 에이전트에 대해 별도의 GitHub 계정을 만듭니다.그것이 쓰는 모든 것은 그 이름 아래에 나타납니다.
3. 코딩 에이전트에서 저장소를 열고 아래 프롬프트를 붙여넣습니다.한 번에 하나씩 질문에 답하십시오.
4. 허용 목록을 본인에게만 보관하세요.그리고 관찰 시 수락 모드를 그대로 둡니다.
5. 작은 것을 요청하십시오.허용된 계정에서 댓글을 달아주세요@<agent login> <request>문제에. 약 1분 내에 패널의 개요에 티켓이 표시됩니다.
6. 일주일 동안 평가 탭을 읽어보세요.목록을 넓히거나 “수락할 것” 레코드가 올바르게 보이는 경우에만 자동으로 전환하십시오.

Read SETUP.md in this repository and set up dsh-superagent with me.

프로젝트의 철학 문서는 운영자에게 반복할 가치가 있는 네 가지 규칙을 제공합니다. 즉, 작게 시작하고, 소음을 줄이도록 조정하고, 볼륨을 생성하기 위해 에이전트를 사용하지 말고, 이름에 적힌 대로 소유하십시오.

에이전트의 나머지 작업은 어디로 가야 하나요?

작업자가 불안정한 통합 테스트에 한 시간을 소비한다고 가정해 보겠습니다. 풀 요청이 수정되었습니다. 그러나 그 뒤에 있는 조사, 어떤 테스트가 실패했는지, 어떤 가설을 배제했는지, 타이밍 테이블이 보여준 것은 PR 설명에 속하지 않으며, 리뷰어가 이의를 제기하고 싶은 것이 바로 그것입니다. 채팅 응답에만 있는 경우 다음 상담원이나 팀원이 처음부터 시작합니다.

AgentGrid.io핸드오프를 위해 만들어졌습니다. 인간과 AI 에이전트는 하나의 안정적인 주소, 제어된 액세스 및 버전 기록을 통해 동일한 실시간 문서, 앱 및 파일에 대해 작업합니다. AgentGrid.io의 문서에서는 다음을 실행하여 명령 가능 에이전트를 연결하는 방법을 설명합니다.npx @animaapp/cli@latest login. 사람은 에이전트의 이름, 팀 및 수행할 수 있는 작업(읽기, 쓰기, 공유 또는 게시)을 승인합니다. 그 후에는 에이전트의 변경 사항이 해당 이름으로 기록에 표시됩니다. 프로토타입에는 AgentGrid.io 통합이 내장되어 있지 않으므로 이를 문서화된 기능이 아닌 작업자와 함께 시도해 볼 패턴으로 취급하십시오.

실제로 작업자는 조사 내용을 Markdown 파일로 작성하고, 검토자는 테이블 행에 주석을 달고, 다른 보조자는 요약을 강화하고, 끌어오기 요청은 붙여넣은 복사본 3개가 아닌 하나의 현재 버전에 연결됩니다.

여러 사람이 하나의 에이전트를 공유하는 또 다른 방법에 대해서는 다음 가이드를 참조하세요.Grok Bot 팀 봇. 호스팅된 에이전트 아래에서 무엇이 실행되는지 궁금하다면 다음 가이드를 참조하세요.Claude Managed AgentsDeepSeek의 기사에서 인용한 동일한 두뇌와 손 분할의 Anthropic 버전을 살펴봅니다.

언제 dsh-superagent를 사용해야 하며, 언제 다른 것을 사용해야 합니까?

• dsh-superagent 사용심각하고 문서화된 설계로부터 배우고, 위험도가 낮은 저장소에서 포함된 실험을 실행하거나 아이디어를 차용합니다. 코드를 실행하지 않는 라우터, 명시된 범위의 티켓, 자동 모드 이전의 관찰 모드.
• 단일 대화형 코딩 에이전트 사용한 번에 하나의 작업을 수행하고 단계별로 진행하고 싶을 때. 슈퍼 에이전트는 반대 상황을 위해 만들어졌습니다.
• AgentGrid.io 사용출력이 여러 사람과 에이전트가 검토, 편집 및 게시해야 하는 문서, 보고서 또는 앱인 경우 에이전트가 생성한 것입니다.

자주 묻는 질문

DeepSeek Super-Agent는 무엇입니까?

이는 MIT 라이센스에 따라 2026년 10월 31일 DeepSeek의 Harness 팀이 출시한 dsh-superagent라는 연구 프로토타입입니다. 하나의 GitHub 저장소에 대한 사전 코딩 에이전트입니다. 수명이 긴 라우터 세션은 요청을 받아 수락된 각 요청을 자체 작업자 세션에 할당합니다. 작업자 세션은 일반적으로 끌어오기 요청을 통해 원래 대화에서 응답합니다.

DeepSeek Super-Agent는 DeepSeek 공식 제품인가요?

아니요. README에서는 공식 DeepSeek 제품이 아닌 참조용 연구 프로토타입이라고 하며, 자신의 환경에서 사용하기 전에 검토하고 적용하라고 나와 있습니다. 또한 내부 버전이나 설계 기사에서 설명하는 구현과도 동일하지 않습니다.

슈퍼 에이전트는 하위 에이전트와 어떻게 다릅니까?

하위 에이전트는 작업 에이전트 아래에 레이어를 추가합니다. 슈퍼 에이전트는 그 위에 레이어를 추가합니다. 이 설계에서 라우터는 많은 작업자 위에 위치하여 사람들과 대화하고 작업을 전달하는 반면 각 작업자는 하나의 작업을 개별적으로 처리합니다. 그 이름은 지위에 관한 것이지 더 큰 지능을 주장하는 것이 아닙니다.

Feishu가 필요합니까, 아니면 GitHub만 필요합니까?

GitHub만으로도 충분합니다. Feishu는 선택적 두 번째 소스이며 문서에는 Feishu 설정 실패로 인해 Feishu 소스만 비활성화된다고 나와 있습니다.

회사 저장소에서 실행해도 안전합니까?

그렇지 않습니다. 문서에는 작업자가 운영자의 OS 사용자로서 전체 액세스 권한으로 실행되며 래퍼 계정이 격리 경계가 아니라고 나와 있습니다. 에이전트의 작동 방식을 배우는 동안 전용 OS 계정, GitHub의 전용 에이전트 계정, 짧은 허용 목록 및 관찰 모드를 권장합니다.

단일 코딩 에이전트 세션보다 빠르나요?

저자의 자체 시뮬레이션 테스트에서 라우터 설계는 더 많은 토큰을 사용하여 하위 에이전트 도구를 사용한 단일 세션에서 29.5분에 비해 15.7분 만에 가장 느린 작업을 완료했습니다. 테스트에서는 시뮬레이션된 코딩 작업과 디자인당 5번의 실행을 사용했기 때문에 코드 품질이 아닌 일정 수립 이점을 보여줍니다.