Herdr 管工位Hermes 管团队

先说结论

如果你的目标是：在 Herdr 里同时开 Codex、Claude Code、Hermes，让一个“总管”能派活、查看进度、处理卡住的问题，最合理的组合是下面这样。

Herdr 怎么管理多窗口

想象一栋办公楼。Herdr 的核心不是“多个聊天机器人”，而是“多个真实终端和进程”。客户端关掉后，办公室里的人仍然在工作。

多窗口为什么不会跟着 UI 一起死？

Herdr 所谓 Agent “状态”是什么？

Hermes 的“多 Agent”有五种

这些名字都像“多 Agent”，但寿命、身份和通信方式完全不同。选错了，就会把临时分工当成长期团队，或把多模型投票误认成多个员工。

Bot Mode：像给公司建立长期通讯录

Delegation：像经理临时找三位外包分析员

子 Agent 从空白对话开始，不知道父 Agent 的聊天记录；父 Agent 必须把目标和上下文讲全。默认最多并行 3 个（可配置），每个有自己的终端 session，最后只有结构化总结进入父上下文。优点是快、隔离；缺点是失败后不具备 Kanban 那种持久恢复和人类中途接管。

Kanban：像有台账的跨班组工单系统

任务、依赖、评论、状态、worker 身份和交接都写入 ~/.hermes/kanban.db。评论是 Agent 间的正式交接协议；worker 每次重启会读到完整评论。它能用 scratch、指定目录或 Git worktree 工作，并通过 heartbeat、claim TTL、失败计数和 review 状态避免任务悄悄丢失。

Hermes 到底怎么管理本地 CLI

答案分三层：Hermes 能运行 shell 命令；能把 Codex 的 app-server 当内部 runtime；也能导入 Claude/Codex 配置。但这三件事都不等于“像 Herdr 一样持久管理多个全屏 CLI 窗口”。

Hermes 和 Herdr 怎么协作

推荐把“谁决定任务”和“谁拥有终端”写死，不要让两个系统互相猜。下面是最清晰、最容易排错的责任链。

现成就能做的连接

推荐的一次派工流程

# 1. Hermes lead 先拿到当前全局状态
herdr agent list

# 2. 在当前 Herdr pane 旁边开一个不抢焦点的工位
split=$(herdr pane split --current --direction right --no-focus)
pane=$(printf '%s\n' "$split" | jq -r '.result.pane.pane_id')

# 3. 在已有空闲 shell pane 启动 Codex 专家
herdr agent start reviewer --kind codex --pane "$pane"

# 4. 给出完整任务并等待明确状态
herdr agent prompt reviewer \
  "只读审查当前 diff。输出：发现、证据、风险、建议；不要修改文件。" \
  --wait --until idle --until done --until blocked --timeout 120000

# 5. 读结果；若 blocked，先读屏再由人决定按什么键
herdr agent read reviewer --source recent-unwrapped --lines 160

建议的四条治理规则

• 单一写作者：同一 checkout 同一时间只允许一个 Agent 改；并行写用独立 Git worktree。
• 单一进程所有者：一个 worker 要么由 Herdr 启动/停止，要么由 Hermes Kanban dispatcher 管，不要双重管理。
• 阻塞必须由人看：Herdr 识别 blocked 后只读屏；不要让总管自动按 Enter 同意未知权限。
• 交接靠证据：输出 changed files、测试命令、退出码、未覆盖风险和产物路径；终端最后一句“done”不算验收。

每天真正用的三招

这两篇社区文章最值得留下的不是“多开几个窗口”，而是一条能每天重复的管理闭环：先把任务交清楚，再把成功方法固化，最后只在真正需要你时汇报。

Captain 和 Worker 的最小合约

Captain 是唯一和你对话的人，负责结果、选择 Worker、监督、验收和最终报告；Herdr 启动的 CLI 是 Worker，只做一个有边界、能独立验收的交付物。

role=worker; outcome=<最终要交付什么>
scope=<允许修改的路径；其他只读>
constraints=<不能做什么、哪些外部动作需批准>
accept=<验收命令或可观察结果>
return=done|blocked; paths=<产物>; checks=<检查>; blocker=<原因>; stop

• 先走最短路径：一个很小、紧密的交付物直接做；长任务、独立交付物、专业 CLI 或真正可并行的工作才值得用 Herdr。
• 默认一个 Worker：只有依赖已满足，而且文件、接口和运行资源互不冲突时才并行。
• 一个交付物一条通道：Worker 不继续派 Worker，也不顺手清理任务外内容。
• 回执不是证明：Captain 仍要检查实际 diff、产物和验收命令。

只读的 Flock Check

巡检的目标是减少你在终端之间切换，而不是偷偷替你操作。先读 Herdr 的实时状态，再用最近终端输出补充任务背景；两者冲突时要明确说“不确定”。

# 1. 检查 server 和协议
herdr status

# 2. 盘点 Agent 与 Workspace；自动化时解析 JSON
herdr agent list
herdr workspace list

# 3. 按 pane id 读取必要的最近输出；先 80 行，最多扩到 200 行
herdr agent read <pane_id> \
  --source recent-unwrapped \
  --lines 80 \
  --format text

到底应该选择哪一层？

文章说法与当前实现：五个校正

Herdr 重要 API 全解读

Herdr CLI 是对本地 socket API 的友好包装。正式自动化优先用 CLI；需要长期事件订阅、或某方法 CLI 没暴露时再直接连 NDJSON socket。下面清单来自本机 Herdr v0.8.2 的 herdr api schema --json。

{"id":"req-1","method":"session.snapshot","params":{}}
{"id":"req-1","result":{...}}

Hermes 的接口地图

Hermes 不是只有一个 API。你要先判断调用者是谁：人、Hermes 内部模型、远端程序，还是另一个 Agent。

最稳妥的实施顺序

先让信息流跑通，再逐步开放写权限。这样某个状态误判最多导致“没自动继续”，而不是误批危险命令。

如果要让两者协作，还要读哪些文档

按这个顺序读，不需要一开始吞完整站点。前 6 篇足够搭出安全的第一版。

第一组：必须读

第二组：要做自动化再读

依据、推断与尚未做的事

主要官方来源

• Herdr Documentation：Concepts、Agents、Automation、Session Restore、Integrations、CLI、Socket API、Agent Skill。
• Hermes User Stories：社区案例索引，用来理解实际用法，不用来替代规格。
• Hermes Bot Mode、Profiles、Delegation、Kanban。
• Hermes API Server、A2A、Codex Runtime。

社区运行手册与当前实现

• The orchestration masterclass (steal this)：提供单一 Captain、Herdr Worker 和统一规则的实践样本；模型排序与效果属于作者经验。
• Herdr + Hermes: 3 Tricks I Use Daily：提供派工、Skill 固化和 fleet digest 的日常工作流。
• herdr-agent-orchestration：当前公开 Captain/Worker 合约、简短 brief 和停止条件；仓库首页同时把该方案标为实验并指向 Firstmate。
• flock-check SKILL.md：只读巡检步骤、状态/终端证据边界、隐私限制和摘要格式。
• Firstmate：更完整的 Captain/Crew 工程工作流；其 README 把 Herdr/Zellij backend 标为 experimental。