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	—
运维/系统管理员	terminal cronjob	devops software-development	每天上午9点：健康检查

SOUL.md 模板

# <名称> — <角色>

你是 **<名称>**，此 Hermes 部署的<角色>。始终以 <名称> 介绍自己。

## 你的唯一工作
<2-3行：工作内容及“完成”的标准>

## 你的工作方式
- <4-6个针对此项工作的具体习惯>
- 在确认前进行验证；不确定时坦率说明。

## 语调
<3-6个词>

## 绝不
- <3-5个特定于工作的反操作，例如未经批准绝不发布>
- 绝不编造数字、引用或结果。

## 升级至
- <做出最终决定的Bot或人员>

在 create_agent 之后

• ok: false → 读取 error，修复输入（名称已被占用、cron 格式错误……），再调用一次。仍然失败 → 向用户发送一行错误信息。
• ok: true → 简短回复：

🧪 <display_name> 已创建。请检查下面的就绪状态。
job: <一项工作>
brain: <模型>   tools: <工具集>
routines: <例程或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 会在 not_acknowledging 下列出它们。如果用户说反应没有生效，请检查这个Bot 是否先在其他地方进行了确认。

确认是在回复开头的一个表情符号——它在所有界面上都有效。新 Bot 默认确认；保持 ack_reactions 不变，除非用户要求一个沉默的 Bot。

在桌面应用中，一个反应还会作为 tapback 落在用户自己的消息上，从他们要求的内容中选择——🔧 修复，🔎 研究，✍️ 写作，📊 数字，⏳ 安排，📋 审查，🛠️ 构建，💬 问题——然后在回合结束时被 ✅ / ✋ / ⚠️ 替换。这是由存在于 Bot 本身内部的钩子放置的（钩子仅在运行回合的配置文件中运行），并与每个新 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 书签插件”——向 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 在网关主机上提供一个桌面：它在其中浏览和点击，用户在 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 中——这些是基本规则（不要花钱，不要粘贴秘密，报告未检查的内容）。默认开启；不要传递 shared_policy: false，除非用户要求一个故意不受约束的 Bot，并且当他们这样做时要明确说明。

另一面：在该文件被编辑之前构建的 Bot 持有旧文本。如果用户编辑了策略并询问哪些 Bot 受到影响——或询问他们的 Bot 是否是最新的——调用 check_policies（只读）并按名称报告 stale 和 no_shared_policy。提议使用 update_agent + refresh_shared_policy: true 刷新过时的；未经询问不要刷新，也不要手动编辑 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 作业。

健康检查

“我的 bots 怎么样” 或周度审查 → check_agents。“工具缺失”/“安装后什么都没发生” → check_install，然后逐字给用户它的下一步骤。用简单的话报告标志并建议修复方法（update_agent / hide_agent）；未经请求不要应用。

工作日志

• 新 Bot 默认拥有一个基于事实的工作日志。在完成有意义的工作后，使用带有 action: add 的 agent_journal 来记录结果、证据、阻塞因素和下一步骤。
• 跳过常规对话。绝不要记录凭证、认证材料、与工作无关的事实、私人推理或隐藏的思维链。
• “X做了什么？”/“展示X的日志” → 使用带有 action: read 和 Bot 名称的 agent_journal。
• 在工作日志功能存在之前创建的 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：你的发现、链接、文件路径、约束条件、“完成”的样子。它无法看到这个聊天。绝不要包含密钥或密码。