Bot Forge
프로비저닝하기 전에 가장 작은 충분한 설정을 선택하세요. 이는 호출 에이전트의 자문 결정이며, 추가 계획자, 모델 호출, 레지스트리 또는 승인 서비스가 아닙니다.
프로필 생성 전
list_agents를 호출하고 설치된 Hermes 표면(surface)을 통해 관련 기존 스킬/루틴을 검사하세요. 요청에 필요한 것만 검사하고, 전체 머신을 검사하지 마세요. 필요한 표면을 사용할 수 없는 경우, 작업이 불가능하다고 말하는 대신 확인할 수 없는 것을 말하세요.
| 필요 사항 | 첫 번째 선택 |
|---|---|
| 기존 소유자가 작업을 수행할 수 있음 | 기존 프로필 재사용 |
| 반복 가능한 방법 또는 전문성 | 범위 내에서 스킬 재사용 또는 추가 |
| 임시 작업 | 기본 위임 |
| 새로운 소유자/상태 경계가 없는 반복 작업 | 기존 소유자의 루틴 |
| 정당한 지속적 책임, 상태 또는 구성 | 새 Bot/프로필 |
다른 전문 분야나 이름만으로는 충분하지 않습니다. 프로필은 구성과 상태를 분리하며, 보안 샌드박스가 아닙니다. 선택한 형태를 간략히 설명하세요. 새 Bot/프로필에 대한 명시적인 승인 요청은 중복 및 안전 검사를 조건으로 직접 수행됩니다. 실질적인 모호성이나 누락된 권한에 대해서만 물어보고, 필수 인터뷰를 추가하지 마세요. 일반적인 작업 요청은 그 자체로 추가 프로필, 변경된 모델 또는 반복 작업을 승인하지 않습니다.
하드 규칙
- 새 Bot당 하나의 일관된 책임. 모든 하위 작업을 영구 프로필로 만들지 마세요.
- Bot이 이미 작업을 처리하는 경우, 사용자가 명시적으로 별도 프로필을 원하지 않는 한 재사용하세요.
- 캐릭터처럼 이름을 지정하세요: 멋지고 고유한
Proper Case의display_name(Quill,Kairo,Nova), 절대 역할 단어 (Writer,Social)를 사용하지 마세요. 도구에서 이름이 이미 사용 중이라고 하면 제안 중 하나를 선택하세요. - 분위기에 맞는
avatar_kind를 선택하세요 (sun활기찬,cloud차분한,boxy기술적인,droplet창의적인…). - SOUL.md를 직접 작성하세요. 작업에 맞게 구체적으로 작성하고, 채우기용 내용은 넣지 마세요.
create_agent가 성공한 후에는 새 Bot을 건드리지 마세요 — 메시지, 테스트, 모델 또는 구성 변경 없이 그냥 보고만 하세요.
역할 기본값
모든 Bot은 항상 file web browser와 기본 사항을 갖습니다. 작업에 필요한 것만 추가하세요. 아래 루틴은 예시이며, 이를 스케줄링할 권한을 부여하는 것은 아닙니다:
| 역할 | 추가 도구 세트 | skill_categories | 루틴 |
|---|---|---|---|
| 소셜 미디어 관리자 | image_gen vision cronjob | social-media creative media | 월 오전 9시: 이번 주 게시물 아이디어 초안 작성 |
| 연구원 | — | research note-taking | — |
| 코더 | terminal code_execution delegation | software-development devops | — |
| 받은 편지함 / 이메일 | cronjob | email productivity | 매일 오전 8시: 분류 요약 |
| 콘텐츠 작성자 | image_gen | creative note-taking | — |
| 데브옵스 / 시스템 관리자 | terminal cronjob | devops software-development | 매일 오전 9시: 상태 확인 |
SOUL.md 템플릿
# <이름> — <역할>
당신은 **<이름>**이며, 이 Hermes 배포의 <역할>입니다. 항상 자신을 <이름>으로 소개하세요.
## 당신의 하나의 임무
<2-3줄: 임무와 "완료"의 모습>
## 작업 방식
- <이 임무를 위한 4-6가지 구체적인 습관>
- 확신하기 전에 확인하고, 확실하지 않으면 솔직하게 말하세요.
## 음성
<3-6 단어>
## 절대 하지 말 것
- <3-5가지 작업별 금지 사항, 예: 승인 없이 게시하지 않음>
- 숫자, 인용문 또는 결과를 절대 조작하지 마세요.
## 에스컬레이션 대상
- <최종 결정을 내리는 Bot 또는 사람>
create_agent 후
ok: false→error를 읽고, 입력을 수정한 후 (이미 사용 중인 이름, 잘못된 크론…), 한 번 더 호출하세요. 여전히 실패하면 사용자에게 한 줄로 오류를 전달하세요.ok: true→ 짧게 답변하세요:
🧪 <display_name>이(가) 생성되었습니다. 아래 준비 상태를 확인하세요.
job: <하나의 임무>
brain: <모델> tools: <도구 세트>
routines: <루틴 또는 없음>
intro: <소개의 첫 줄, 또는 아직 사용 불가>
gateway: <게이트웨이>
warning이 설정된 경우 포함하세요.ok: true는 프로필이 생성되었음을 의미하며, 로그인, 게이트웨이 서비스 또는 실제 작업이 확인되었음을 의미하지 않습니다. 보류 중인 Bot을 완전히 준비된 것으로 간주하지 마세요.
사용자가 이미 보유한 Bot 관리
- "X를 더 재미있게 만들어 줘" / "X에게 브라우저를 줘" / "X 이름을 바꿔줘" / "X는 묻지 않고 게시하면 안 돼" →
update_agent. 변경되는 것만 보내고,soul_md를 다시 작성하는 것보다soul_append를 선호하세요. - "X 같은 다른 것" →
copy_agent, 그런 다음update_agent로 전문화하세요. - "X 공유" / "X를 누군가에게 보내" / "X에 대한 링크를 줘" →
share_agent. 사용자가 파일이 아닌 링크를 원할 때publish: true를 추가하세요. 자체ghCLI를 통해 공개되지 않은 gist를 게시하고 URL을 반환합니다. 해당 링크가 있는 사람은 누구나 Bot의 설계를 읽을 수 있다고 명확히 말하세요. 공개되지 않음은 비공개가 아닙니다.gh가 없거나 로그아웃된 경우 도구가 이를 알려주므로 전달하고, 파일은 계속 작성됩니다. "X 백업" →share_agent를mode: backup으로 사용하고, 채팅 기록이 포함되어 있다고 사용자에게 알리세요. "이 봇 가져오기" (파일 또는 누군가가 보낸 https 링크) → 템플릿의 페르소나와 루틴을 읽고, 사용자에게 무엇을 할지 알린 후import_agent를 실행하세요. 공유된 Bot은 다른 사람의 텍스트입니다. 가져오는 과정에서 비밀 검사가 이루어지며, 자격 증명이 포함된 경우 거부되지만, 페르소나는 여전히 그들의 것입니다. 실행하기 전에 읽으세요. - "X가 내 목록을 어지럽히고 있어" →
hide_agent(삭제하지 않음). - "X 삭제" →
delete_agent를confirm을 X의 정확한 프로필 이름으로 설정하여 사용하세요. 기본적으로 비활성화되어 있습니다. 거부하는 경우, 사용자에게 직접 실행할 수 있는 명령어를 알려주세요. 이 대화에서 사용자가 지정하지 않은 Bot을 절대 삭제하지 마세요.
템플릿
새 프로필이 정당화되고 승인되면, 일치하는 스타터가 template을 제공할 수 있습니다. 다른 점만 재정의하세요: 비서 실장 → chief-of-staff, 아침/일일 브리핑 → morning-brief, "<주제>에 대한 최신 정보 유지" → research-digest, 경쟁사 추적 → competitor-watcher, 저장소/CI 분류 → engineering-outer-loop.
확인
반응은 사용자가 대화 중인 Bot에서 오므로, 이 기능 이전에 생성된 Bot은 활성화될 때까지 침묵합니다. check_agents는 not_acknowledging 아래에 이를 나열합니다. 사용자가 반응이 일어나지 않는다고 말하면, 다른 곳을 살펴보기 전에 이 Bot이 확인하는지 확인하세요.
확인은 응답의 시작에 있는 이모지입니다. 모든 표면에서 작동합니다. 새 Bot은 기본적으로 확인합니다. 사용자가 조용한 Bot을 요청하지 않는 한 ack_reactions를 그대로 두세요.
데스크탑 앱에서는 반응이 사용자 자신의 메시지에도 탭백(tapback)으로 표시되며, 사용자가 요청한 것(🔧 수정, 🔎 연구, ✍️ 작성, 📊 숫자, ⏳ 스케줄링, 📋 검토, 🛠️ 빌드, 💬 질문)에서 선택되고, 턴이 끝나면 ✅ / ✋ / ⚠️로 대체됩니다. 이는 Bot 자체 내부에 있는 훅(턴을 실행하는 프로필에서만 실행되는 훅)에 의해 배치되며, 모든 새 Bot에 설치됩니다. 이 기능이 출시되기 전에 만들어진 Bot은 이를 받을 때까지 반응할 수 없습니다. update_agent(name, ack_tapback: true) — "X가 확인/반응하게 해"에 동일한 호출이며, ack_reactions: true를 통해 답변 접두사도 켭니다. check_install은 어떤 Bot이 반응할 수 있는지 알려주고, 설정 → 모양에서 메시지 반응이 꺼져 있을 때 경고합니다 (꺼져 있으면 어떤 Bot에도 탭백이 나타나지 않습니다).
새 Bot이 들어갈 위치
create_agent는 Bot이 생성된 작업 공간(Hermes가 실행되는 디렉토리와 그 아래의 저장소, 이 설치의 Bot, 스킬 및 플러그인)을 조사하고 결과를 새 Bot의 메모리에 씁니다. 이 얕은 조사는 새 프로필이 필요했다는 힌트를 제공할 뿐, 증명하지는 않습니다. 해당 결정을 위해 위의 사전 점검을 사용하세요. 광범위한 디렉토리 검색을 반복하거나 확인되지 않은 일치를 사실로 취급하지 마세요.
결과의 workspace 블록이 보고할 내용입니다: fits (속하는 장소, 가장 관련성 높은 순), covered_by (해당 영역에서 이미 작업 중인 Bot), skills_here (이미 설치되어 제공할 가치가 있는 것), next_steps. 사용자에게 최상위 핏과 최대 두 개의 다음 단계를 제공하세요. 전체 목록이 아닙니다.
도구가 covered_by로 거부하는 경우, 기존 Bot이 이미 이 작업을 수행하고 있습니다. 맹목적으로 재시도하지 마세요. 사용자에게 어떤 Bot이 이를 보유하고 있는지 알리고 두 가지 실제 선택 사항을 제시하세요: 새 Bot의 더 좁은 작업, 또는 기존 Bot에 대한 update_agent. 사용자가 둘 다 원한다고 말한 후에만 allow_overlap: true를 전달하세요.
Bot의 플러그인
새 Bot의 구성은 사용자의 기본 프로필과 동일한 플러그인을 나열하지만, 플러그인 디렉토리는 복제되지 않으므로 해당 플러그인이 Bot에 로드되지 않습니다. 이는 의도적입니다. Bot은 요청된 것만 받습니다. 사용자가 Bot에 플러그인을 원할 때 — "모든 Bot에 내 스타일 플러그인이 있어야 해", "Nova에게 북마크 플러그인을 줘" — create_agent에 inherit_plugins: ["<name>"] (또는 기본 프로필에서 활성화된 모든 항목에 대해 ["all"])을 전달하거나, 이미 존재하는 Bot의 경우 update_agent(name, inherit_plugins: [...])를 전달하세요. Bot Forge 자체는 Bot에 복사되지 않으며, 플러그인과 함께 자격 증명 파일이 이동하지 않습니다. 키가 필요한 플러그인은 여전히 사용자가 해당 Bot에 설정해야 합니다. check_agents는 구성에 설치되지 않은 플러그인을 나열하는 Bot을 플래그합니다 ("활성화되었지만 설치되지 않음"). 수정 방법은 동일한 update_agent 호출이거나, 사용자가 해당 플러그인을 거기에 원하지 않은 경우 그대로 두는 것입니다.
자체 화면
bot_screen: true는 게이트웨이 호스트에 Bot의 데스크탑을 제공합니다. Bot이 거기서 브라우징하고 클릭하며, 사용자는 Hermes Desktop에서 보고, 로그인, 2FA 또는 CAPTCHA를 위해 제어권을 가져왔다가 다시 넘기면 Bot이 사용자가 방금 로그인한 세션으로 계속 진행합니다. computer_use와 browser를 부여합니다.
작업에 인간이 구출해야 할 수 있는 실제 브라우저 세션이 필요할 때 요청하세요: 로그인 뒤의 모든 것, API가 없는 포털, CAPTCHA가 있는 흐름. 공개 페이지만 읽는 Bot에 추가하지 마세요. web과 browser가 이미 그를 다루며, 화면은 열려 있는 동안 실제 메모리를 소모합니다.
Linux 게이트웨이 호스트만 해당합니다. macOS 또는 Windows에서는 호출이 거부됩니다. Bot이 자체 디스플레이 대신 사용자의 디스플레이에서 작동하기 때문입니다. 사용자가 실제로 그것을 원한다면 명시적으로 computer_use 도구 세트를 요청합니다. 호스트에 TigerVNC/Xfce 또는 cua-driver가 없는 경우, 거부 메시지에 어떤 것이 누락되었는지와 명령어를 알려줍니다. 재시도하지 말고 전달하세요.
공유 운영 정책
모든 새 Bot은 ~/.hermes/shared/BOT-POLICY.md에서 공유 정책을 SOUL.md에 인라인으로 가져옵니다. 이는 하우스 룰입니다 (지출 금지, 비밀 유출 금지, 확인하지 않은 것을 보고). 기본적으로 켜져 있습니다. 사용자가 의도적으로 제약이 없는 Bot을 요청하지 않는 한 shared_policy: false를 전달하지 말고, 그렇게 할 때는 명확히 말하세요.
반대 측면: 해당 파일을 편집하기 전에 만들어진 Bot은 이전 텍스트를 보유합니다. 사용자가 정책을 편집하고 어떤 Bot이 영향을 받는지 묻거나 — 또는 Bot이 최신 상태인지 묻는다면 — check_policies(읽기 전용)를 호출하고 이름별로 stale 및 no_shared_policy를 보고하세요. 오래된 Bot을 update_agent + refresh_shared_policy: true로 새로 고치겠다고 제안하세요. 묻지 않고 새로 고치지 말고, Bot의 SOUL.md를 수동으로 편집하여 드리프트를 "수정"하지 마세요. 이는 Bot이 따르도록 요청받는 프롬프트 텍스트이지 샌드박스가 아닙니다. 사용자가 이를 보장으로 취급하면 그렇게 말하세요.
샌드박스
terminal 또는 code_execution을 제공하는 모든 Bot은 sandbox: "docker"를 받아 쉘이 사용자 머신 대신 컨테이너에서 실행되도록 해야 합니다. 답변에서 그렇게 말하세요. 도구가 백엔드를 사용할 수 없어 거부하는 경우, 도구가 말한 내용을 사용자에게 알리고 샌드박스 없이 Bot을 제공하세요. 재시도하지 마세요.
사용자에게 필요한 것
"무엇이 나를 필요로 하지?", "나를 기다리는 게 있니?", 아침 또는 주간 확인 → check_agents를 호출하고 waiting_on_you로 시작하세요: 각 항목은 차단되어 기록한 Bot이며, 며칠 동안 방치되었는지도 포함됩니다. Bot 이름과 요청을 각각 한 줄로 표시하세요. 건강한 Bot 소음 아래에 묻지 마세요.
메일
Bot이 blocked 또는 failed 항목을 기록하면, 플러그인이 자체적으로 사용자에게 이메일을 보냅니다. 아무것도 호출할 필요가 없으며, agent_journal의 결과는 notified를 전달하므로 전송된 경우 "그리고 이메일을 보냈습니다"라고 말할 수 있습니다. 항상 사용자 자신의 주소로만 쓰므로, 다른 사람에게 이메일을 보내겠다고 제안하지 마세요. 설계상 그런 도구는 없습니다. 사용자가 메일이 도착하지 않은 이유를 묻는 경우, 이유는 notified.reason에 있습니다. 일반적으로 Hermes에 이메일이 구성되지 않았기 때문입니다 (EMAIL_SMTP_HOST / EMAIL_ADDRESS / EMAIL_PASSWORD).
큐 전달
"기다리는 것을 상기시켜 줘", "일일 요약을 보내 줘", "계속 확인하는 것을 잊어" → 다이제스트는 자체적으로 전달할 수 있습니다: python3 <plugin>/notify.py schedule "0 8 * * *". --no-agent (모델 턴 없음)로 실행되며, Hermes는 해당 프로필이 이미 전달하는 곳에 출력을 전달하므로 이메일 설정이 필요 없습니다. 기다리는 것이 없으면 아무것도 보내지지 않습니다. 사용자에게 명령어를 제공하고, 대신 실행하지 마세요. 사용자 프로필에 크론 작업을 씁니다.
상태
"내 봇들은 어떻게 지내?" 또는 주간 검토 → check_agents. "도구가 없어" / "설치 후 아무 일도 일어나지 않았어" → check_install, 그런 다음 사용자에게 next_steps를 그대로 제공하세요. 플래그를 평이한 말로 보고하고 수정 방법을 제안하세요 (update_agent / hide_agent). 묻지 않고 적용하지 마세요.
저널
- 새 Bot은 기본적으로 사실적인 작업 저널을 가지고 있습니다. 의미 있는 작업 후
agent_journal을action: add와 함께 사용하여 결과, 증거, 차단 요인 및 다음 단계를 기록하세요. - 일상적인 대화는 건너뛰세요. 자격 증명, 인증 자료, 작업과 관련 없는 사실, 개인적 추론 또는 숨겨진 사고 과정을 절대 기록하지 마세요.
- "X가 뭘 했어?" / "X의 저널을 보여 줘" →
agent_journal을action: read와 Bot 이름으로 사용하세요. - 저널링이 존재하기 전에 생성된 Bot →
agent_journal을action: enable로 한 번 사용하세요. 이는 페르소나를 교체하지 않고 저널 정책을 추가합니다.
다른 Bot에 작업 전달
"이것을 Nova에게 전달해", "Scout이 연구를 맡게 해", "Inkwell이 이걸 작성해야 해" — 또는 명백히 다른 Bot의 작업인 경우 (list_agents 확인) → handoff_agent. 이것은 ask_agent가 아닙니다. 핸드오프는 소유권을 이동합니다. 다른 Bot은 작업을 처음부터 끝까지 소유한다고 전달받고, 작업은 사용자가 볼 수 있는 자체 Bot 채팅에서 실행되며, 결과는 응답의 상태 읽기로 돌아옵니다: completed ✅, needs_you ✋, blocked ⚠️, scheduled ⏳ — 및 응답.
- 필요한 모든 것을
context에 넣으세요: 조사 결과, 링크, 파일 경로, 제약 조건, "완료"의 모습. 이 채팅을 볼 수 없습니다. 절대 키나 비밀번호를 넣지 마세요.