Hermes Agent Bot Mode Guide: Bot Screen & Multi-Bot Groups

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Hermes Agent의 봇 모드는 Bot Screen으로 원격 에이전트의 작업을 보고 직접 조작하며, 멀티봇 그룹으로 역할이 다른 에이전트에게 공통 맥락을 전달하는 데 활용할 수 있다.

📌 핵심 요점

1. 여러 백엔드 연결: 로컬 PC, Linux 노트북, DGX Spark, VPS의 봇 프로필을 한 화면에서 관리한다. 원격 연결은 설정의 Gateways와 Saved Connections에서 구성하며, 발표자의 SSH 환경에는 키가 필요하다.
2. 화면과 글자 크기 분리: Appearance → Typography에서 UI 배율과 채팅 글자 크기를 따로 조절한다. 시연에서는 각각 110%, 150%로 설정해 화면 밀도와 읽기 편의성을 함께 확보한다.
3. Bot Screen으로 시각적 협업: 영상 설명상 원격 장치에서만 동작한다. 에이전트 화면을 관찰하다가 Take Over로 직접 조작하고, Hand Back으로 제어권을 돌려줄 수 있다.
4. 멀티봇 그룹의 용도는 공통 맥락 공유: 마케팅 담당과 운영 담당처럼 역할이 분명한 에이전트에게 변경 사항을 함께 알리고 협업 절차를 조율한다. 발표자는 현재 두세 에이전트 정도를 권하며, 주요 작업은 개별 세션에서 진행한다.
5. 전환 속도에는 메모리 비용이 따른다: Advanced의 Warm Bot Backends를 늘리면 더 많은 백엔드를 실행 상태로 유지한다. 발표자는 값을 10으로 높였지만, 전환 지연이 완전히 사라지는 것은 아니며 메모리 사용량도 늘어난다고 설명한다.

🧩 배경과 문제 정의

발표자는 약 한 달 전 Hermes AI Desktop의 봇 모드를 소개한 뒤 계속 사용하면서 기능과 UI가 달라졌다고 설명한다. 이번 영상은 여러 장치의 봇을 관리하는 설정, 원격 화면을 다루는 Bot Screen, 역할별 에이전트의 그룹 채팅을 실제 사용 사례로 소개한다.

핵심 문제는 원격 에이전트가 만드는 시각적 결과물을 어떻게 확인하고 수정할지, 여러 에이전트에게 같은 정보를 어떻게 전달할지다. 전환 지연과 버그에 대한 불만도 함께 다루며, 발표자의 장치 구성과 설정을 바탕으로 개선 팁을 제시한다.

🕒 시간순 섹션별 상세정리

1. 업데이트 소개와 영상의 범위

• 이전 가이드 이후의 개선 사항, 개별 봇 사용, 그룹 채팅, 성능 팁과 Bot Screen을 소개하겠다고 예고한다. [00:49]
• 자신의 Agent Wikis 프로젝트를 홍보한다. 일반 위키는 무료이며, 월 19.99달러 Pro에는 전용 영상·스킬·뉴스레터·전문 에이전트 프로필 등이 포함된다고 설명한 뒤 본론으로 돌아온다. [01:30]

2. 여러 장치의 백엔드와 SSH 연결

• 로컬 PC와 Linux 노트북 외에 SSH로 연결한 DGX Spark, 별도의 VPS 에이전트를 사용한다. 봇은 프로필이며 장치별 프로필이 화면의 레일에 표시된다. [02:21]
• Settings → Gateways → Saved Connections에서 연결을 구성한다. 발표자의 SSH 방식에서는 해당 장치의 SSH 키가 필요하며, 연결을 구성하면 봇 모드 레일에서 접근할 수 있다. [02:56]

3. UI 배율과 채팅 글자 크기 분리

• Appearance → Typography에서 UI Scale과 Chat Text Size를 따로 조절한다. 시연 설정은 UI 110%, 채팅 글자 150%다. [03:32]
• UI는 비교적 작게 유지해 더 많은 요소를 표시하고, 매일 읽는 채팅 글자는 크게 만드는 방식으로 사용한다. [03:48]

4. Bot Screen 실행과 제어권 교대

• 워크플로 캔버스를 만드는 봇에서 우클릭 → Open Screen으로 화면을 열고 실행한다. Bot Screen은 원격 장치에서만 작동한다고 설명하며, 헤드리스 DGX Spark의 실제 화면을 보여준다. [04:59]
• Take Over를 누르면 사용자가 커서를 제어한다. Ubuntu의 파일 관리자를 열어 파일을 살펴보고 Chromium 브라우저도 실행한다. [06:08]
• Hand Back으로 제어권을 돌려주면 사용자의 클릭은 작동하지 않고, 봇이 다시 페이지와 장치를 조작한다. [06:33]

5. 워크플로 캔버스를 보며 개발하기

• 모델에 따라 Bot Screen 실행 요청을 바로 이해하지 못할 수 있다고 드러낸다. 시연에서는 에이전트가 로컬 서버를 열어 개발 중인 무한 캔버스를 표시한다. [06:59]
• 노드별 할 일과 API·키 설정을 시각화하려는 프로젝트다. 발표자는 주문형 인쇄 사업의 워크플로를 정리하는 용도를 설명하고, 직접 제어권을 가져와 노드를 옮겨본다. [08:29]
• 프로젝트는 아직 많은 작업이 필요한 초기 상태다. 캔버스는 React Flow가 그리며, 에이전트 연동 부분은 별도로 구축하고 있다고 보여준다. [09:45]

6. 미설정 상태와 체크리스트 추가

• proposed·configured 상태에 더해, 승인됐지만 설정이 끝나지 않은 노드의 not configured 상태와 간단한 할 일 목록을 요청한다. 이후 제어권을 돌려줘 에이전트의 작업을 지켜본다. [10:20]
• 완료 후 일부 노드가 겹친 모습을 확인한다. 리뷰 모델 선택이나 GitHub Pages 게시처럼 남은 설정을 목록과 링크로 확인하는 예시를 보여준다. [11:30]
• 채팅과 원격 화면을 한 앱에서 오가며 결과를 직접 조작하는 방식이 자신의 워크플로를 편하게 만든다고 평가한다. [11:59]

7. 마케팅·운영 에이전트의 그룹 구성

• Keepsake Threads용 KT 그룹을 연다. 활성 봇 사이를 전환하는 데도 시간이 걸리며, 이때 약 20초가 걸렸다고 추정한다. [12:31]
• 두 에이전트는 상시 실행 중이다. KT Marketer는 광고 제작과 캠페인 관리를, PM은 cron 작업을 통한 사이트 상태·트래픽·문제 모니터링을 담당한다. [13:07]
• 서로 소개하게 하며 공통 맥락을 이해하는 모습을 보여준다. 현재 효과에는 한계가 있다고 보고, 그룹에는 두세 에이전트 정도만 넣겠다고 드러낸다. [13:35]

8. Warm Bot Backends와 메모리 절충

• 그룹의 봇은 활성 상태여야 한다고 보여준다. Settings → Advanced의 Warm Bot Backends는 전환을 위해 실행 상태로 유지하는 백엔드 수를 설정한다. [13:53]
• 기본값은 아마 4라고 추정하며 자신의 설정은 10이다. 값을 높이면 전환이 빨라지지만 메모리를 더 사용하므로 함께 고려해야 한다. [14:08]

9. 그룹에서 공유할 정보와 개별 작업의 구분

• 새 PR, 사이트 기능이나 스타일 변경, 에이전트 사이의 워크플로를 그룹에서 설명하면 같은 내용을 각 세션에 반복 전달할 필요가 줄어든다. [14:41]
• 주요 마케팅 작업 같은 집중 업무는 개별 세션에서 진행하고, 팀 전체에 맥락이 필요할 때 그룹을 사용하겠다고 보여준다. [14:56]

10. 주간 보고를 공유 파일과 cron으로 연결

• 마케팅 봇이 PM에게 주간 보고서를 작성하도록 요청한다. 같은 장치에 있으므로 로컬 Markdown 파일로 전달할 수 있으며, 아직 마케팅을 시작하지 않아 실제 보고할 데이터는 없다. [15:21]
• PM이 더 짧은 보고 형식을 요구하고 마케팅 봇이 수정한다. 이어 매주 화요일 보고서를 쓰는 cron과 다른 봇이 매주 파일을 읽는 cron을 구성하는 방식을 보여준다. [16:16]
• 사용자는 Telegram에서 PM 한 봇의 보고를 받는 구조를 원한다. 역할이 분명한 에이전트가 공통 정보를 이해하도록 그룹을 활용하되, 일상 업무 전체를 그룹에서 진행하지는 않겠다고 정리한다. [17:10]

11. 기능 평가와 남은 성능 문제

• UI 개선, Bot Screen, 그룹 채팅 활용을 되짚어 본다. 봇 사이 이동이 때때로 느리다는 불만에 일부 동의하며, 장치에 따라 체감 속도가 다르다고 드러낸다. [17:52]
• Warm Backends 10개로 전환을 조금 빠르게 사용하고 있으며, 개발팀이 봇 모드 성능 개선을 진행 중이라고 전해진다. 사용 경험과 개선 의견을 댓글로 요청하며 영상을 마친다. [18:18]

🧾 결론

• Bot Screen의 구체적인 활용 사례는 시각적 결과물을 만드는 과정이다. React Flow 기반 워크플로 캔버스를 보면서 노드를 옮기고, 수정 결과를 확인하고, 후속 요청을 전달한다.
• 그룹 채팅은 역할이 다른 에이전트에게 같은 정보를 반복 설명하는 부담을 줄이는 공간으로 제시된다. 모든 작업을 그룹에서 처리하는 방식은 권하지 않는다.
• 주간 보고 협업은 같은 장치의 Markdown 파일과 cron 작업으로 구성하는 예시다. 마케팅 봇이 보고서를 작성하고 운영 봇이 읽어 사용자에게 전달하는 흐름을 보여준다.
• 영상은 실제 사용 경험과 개발 중인 프로젝트의 시연이다. 기능의 활용 가능성은 보여주지만 안정성이나 생산성 향상을 정량적으로 입증하지는 않는다.

📈 투자·시사 포인트

• 에이전트 도구의 도입 판단에서는 자동 실행 기능과 함께 사람이 결과를 확인하고 개입하는 과정의 편의성도 살펴볼 필요가 있다. Bot Screen 시연은 이 검토 과정을 한 앱 안에서 진행하는 사례다.
• 상시 실행 장치와 Warm Bot Backends는 응답 편의성을 높이는 선택지지만, 메모리와 장치 운영 부담을 함께 고려해야 한다. 발표자의 DGX Spark 경험을 다른 장치의 성능으로 일반화하기는 어렵다.
• 역할별 에이전트가 늘어날수록 공통 변경 사항을 전달하고 보고를 통합하는 절차가 중요해진다. 영상에서는 그룹 채팅, 공유 파일, 운영 봇의 Telegram 보고를 연결한다.
• 영상에는 관련 기업의 실적이나 가치평가 자료가 없다. 투자 판단보다는 에이전트 운영 방식과 도입 조건을 검토하는 자료로 활용하는 편이 적절하다.

⚠️ 불확실하거나 확인이 필요한 부분

• Bot Screen은 원격 장치에서만 작동한다고 설명하지만, 지원 운영체제·버전·연결 방식의 전체 범위는 제시하지 않는다. 직접 보여준 환경은 Ubuntu 기반 DGX Spark다.
• Warm Bot Backends의 기본값은 발표자가 '아마 4'라고 말한 추정이다. 값을 10으로 높였을 때의 메모리 증가량이나 전환 시간 개선 폭도 측정 자료가 없다.
• 그룹 참여를 두세 에이전트로 제한하라는 조언은 발표자의 사용 판단이다. 공식적인 참여 수 제한이나 규모별 성능 검증으로 제시되지는 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Gateways → Saved Connections에서 사용할 장치를 등록하고, SSH 연결이라면 키와 연결 상태를 확인한다.
• Appearance → Typography에서 UI 배율과 채팅 글자 크기를 각각 조정해 읽기 편한 조합을 찾는다.
• 원격 봇의 Open Screen을 실행한 뒤 Take Over와 Hand Back을 시험해 제어권 전환을 확인한다.
• 역할이 분명한 두 에이전트로 그룹을 구성하고, 공통 변경 사항 하나를 전달해 양쪽의 이해를 확인한다.

❓ 열린 질문

• 그룹 채팅의 맥락은 개별 세션과 장기 기억에 어느 범위까지 이어지는가?
• 장치 성능과 Warm Bot Backends 설정이 각각 전환 지연에 얼마나 영향을 주는가?
• 서로 다른 장치의 에이전트가 보고서를 교환할 때는 어떤 전달 방식이 필요한가?