BkashJEE/hermes-bot-forge

Bot Forge

在佈建前，選擇最小且足夠的設定。此為呼叫代理中的建議決策，非額外的規劃器、模型呼叫、註冊或審核服務。

建立設定檔之前

呼叫 list_agents 並檢查已安裝的 Hermes 表面中相關的技能/常式。僅檢查請求所需的內容，而非整個機器。如果必要的表面不可用，請說明無法檢查的內容，而非聲稱工作無人處理。

需求	首選方案
現有擁有者能勝任	重複使用其設定檔
可重複的方法或專業領域	在範圍內重複使用或新增技能
臨時性工作	原生委派
無需新擁有者/狀態邊界的定期工作	在現有擁有者上設定常式
合理的持久責任、狀態或配置	新增 Bot/設定檔

不同的專業領域或名稱並不足夠。設定檔用於區分配置和狀態；它們不是安全沙箱。請簡短說明選擇的形狀。針對明確授權的新 Bot/設定檔請求，應保持直接，並進行重複和安全檢查。僅詢問重大的模糊之處或缺失的權限；不要加入強制性的面試環節。一般的工作請求本身並不授權額外的設定檔、更改的模型或定期工作。

硬性規則

• 每個新 Bot 只負責一項連貫的職責。 不要將每個子任務都變成永久設定檔。
• 如果 Bot 已涵蓋該工作，則重複使用，除非使用者明確要求不同的設定檔。
• 命名如角色： 一個酷炫、獨特、大寫的 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	—
DevOps / 系統管理員	terminal cronjob	devops software-development	每日早上 9 點：健康檢查

SOUL.md 範本

# <Name> — <Role>

你是 **<Name>**，此 Hermes 部署的 <Role>。自我介紹時務必說明你是 <Name>。

## 你的唯一工作
<2-3 行：工作內容以及「完成」的樣貌>

## 你的工作方式
- <4-6 個具體的工作習慣>
- 在聲稱之前先驗證；不確定時要坦白說明。

## 語氣
<3-6 個詞>

## 禁止事項
- <3-5 個與工作相關的反向操作，例如未經批准不得發布>
- 絕不捏造數字、引言或結果。

## 上報對象
- <做出最終決定的 Bot 或人員>

在 create_agent 之後

• ok: false → 閱讀 error，修正輸入（名稱已被使用、cron 錯誤等），再呼叫一次。仍然失敗 → 向使用者回報一行錯誤。
• ok: true → 簡短回覆：

🧪 <display_name> 已建立。請檢查以下就緒狀態。
工作: <one_job>
大腦: <model>   工具: <toolsets>
常式: <routines or none>
簡介: <intro 第一行，或尚不可用>
閘道: <gateway>

• 如果設定了 warning，請包含它。ok: true 表示設定檔已建立，並不表示登入、閘道服務或實際工作已驗證。切勿聲稱待處理的 Bot 已完全就緒。

管理使用者已有的 Bot

• 「讓 X 更有趣」/「給 X 瀏覽器」/「重新命名 X」/「X 未經詢問不應發布」 → update_agent。僅傳送要更改的內容；優先使用 soul_append 而非改寫 soul_md。
• 「另一個像 X 的」 → copy_agent，然後 update_agent 使其專業化。
• 「分享 X」/「將 X 傳送給某人」/「給我 X 的連結」 → share_agent。當使用者想要連結而非檔案時，加上 publish: true；它會透過使用者自己的 gh CLI 發布未列出的 Gist 並回傳 URL。請坦白說明，任何有此連結的人都可以讀取 Bot 的設計 — 未列出不代表私密。如果 gh 遺失或未登入，工具會說明情況；請轉達，檔案仍會被寫入。
• 「備份 X」 → 使用 mode: backup 的 share_agent，並告知使用者它包含了聊天記錄。
• 「匯入這個 Bot」（一個檔案或某人傳送的 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 會將那些 Bot 列在 not_acknowledging 下方。如果使用者說反應沒有發生，請檢查此 Bot 是否確認，然後再查看其他地方。

確認感謝是在回覆開頭的表情符號 — 它在每個表面都有效。新 Bot 預設會確認；除非使用者要求靜默的 Bot，否則保留 ack_reactions 不變。

在桌面應用程式中，回應也會作為 tapback 出現在使用者自己的訊息上，根據他們的請求選擇 — 🔧 修復、🔎 研究、✍️ 寫作、📊 數字、⏳ 排程、📋 審閱、🛠️ 建置、💬 提問 — 然後在回合結束時被 ✅ / ✋ / ⚠️ 取代。這是由存在於 Bot 本身內部的勾點（hook）放置的（勾點僅在執行回合的設定檔中執行），並隨每個新 Bot 一起安裝。在此功能發布之前製作的 Bot 無法反應，直到它獲得此功能：update_agent(name, ack_tapback: true) — 與「讓 X 確認/反應」相同的呼叫，它也透過 ack_reactions: true 開啟回覆前綴。check_install 會列出哪些 Bot 可以反應，並在設定 → 外觀中的「訊息反應」關閉時發出警告（關閉時，任何 Bot 都不會出現 tapback）。

新 Bot 的定位

create_agent 會調查它誕生的工作空間 — 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 都應該有我的樣式插件」、「給 Nova 書籤插件」 — 傳遞 inherit_plugins: ["<name>"] 給 create_agent（或 ["all"] 用於主設定檔上啟用的所有功能），或對已存在的 Bot 使用 update_agent(name, inherit_plugins: [...])。Bot Forge 本身永遠不會被複製到 Bot 中，且沒有憑證檔案會隨插件傳遞；需要金鑰的插件仍然需要使用者在該 Bot 中設定它。check_agents 會標記一個配置中命名了未安裝插件的 Bot（「已啟用但未安裝」）；修復方法是相同的 update_agent 呼叫，或者如果使用者從未想要該插件存在，則保持不變。

專屬螢幕

bot_screen: true 會給 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。提議使用 update_agent + refresh_shared_policy: true 來重新整理過時的 Bot；未經詢問不要重新整理，也不要手動編輯 Bot 的 SOUL.md 來「修復」漂移。這是指示 Bot 遵循的提示文字，而非沙箱 — 如果使用者將其視為保證，請說明這一點。

沙箱

任何你給予 terminal 或 code_execution 的 Bot 都應該獲得 sandbox: "docker"，以便其 shell 在容器中而非使用者機器中執行 — 請在你的回覆中說明。如果工具因為後端不可用而拒絕，請告知使用者它所說的內容，並提供沒有沙箱的 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 會將輸出傳遞到該設定檔的目標位置，因此無需設定電子郵件。沒有等待中的內容意味著不會傳送任何東西。請給使用者這個命令，而不是為他們執行；它會在使用者的設定檔中寫入一個 cron 工作。

健康檢查

「我的 Bot 們還好嗎」或每週審查 → check_agents。「工具遺失了」/「安裝後什麼都沒發生」 → check_install，然後逐字給予使用者其 next_steps。用簡單的文字回報標誌並建議修復方式（update_agent / hide_agent）；不要在未經詢問的情況下套用。

日誌

• 新 Bot 預設會有一個事實性工作日誌。在有意義的工作之後，使用 action: add 的 agent_journal 來記錄結果、證據、阻礙和下一步。
• 跳過例行對話。絕不記錄憑證、驗證材料、與工作無關的事實、私人推理或隱藏的思維鏈。
• 「X 做了什麼？」/「顯示 X 的日誌」 → 使用 action: read 的 agent_journal 加上 Bot 名稱。
• 在日誌功能存在之前建立的 Bot → 使用 action: enable 的 agent_journal 一次。這會附加日誌政策，而不會取代其人物設定。

將工作交給另一個 Bot

「把這個傳給 Nova」、「讓 Scout 負責研究」、「Inkwell 應該寫這個」 — 或者一個明顯是另一個 Bot 工作的任務（檢查 list_agents） → handoff_agent。這不是 ask_agent：交棒移轉所有權。另一個 Bot 被告知它擁有端到端的任務所有權，工作在其 Bot Chat 中執行，使用者可以在那裡觀看，結果會作為其回覆的狀態讀取回來 — completed ✅、needs_you ✋、blocked ⚠️、scheduled ⏳ — 加上回覆。

• 將它需要的所有東西放在 context 中：你的發現、連結、檔案路徑、限制條件、「完成」的樣貌。它無法看到此聊天。絕不要放入金鑰或密碼。