Hermes on Zampo Blog

Hermes Kanban 实战：别再用聊天记录管理多 Agent 团队

Wed, 13 May 2026 15:36:00 +0800

你把任务卡创建好了，researcher、writer、coder 也都分配了。

然后什么都没发生。

这不是 bug。恰恰相反，这是 Hermes Kanban 最容易被误解、也最值得讲清楚的地方：创建 card，不等于启动 worker。

很多人把多 Agent 系统想得太像“开几个聊天窗口”。一个负责调研，一个负责写稿，一个负责代码，大家各干各的。听起来很美，真跑起来就会发现：谁先干？谁等谁？谁审核？交付物放哪？失败了谁接？

靠聊天记录和几个 Markdown 文件也能凑合跑。但只要任务链稍微长一点，协作就开始变脆。

Hermes Kanban 解决的不是“让 Agent 更聪明”。它解决的是另一个更工程的问题：

把 Agent 的工作，放进一条可追踪、可审核、可恢复的流水线里。

这篇不讲概念安利，只讲怎么用。

先记住一句话：Kanban 是任务系统，不是魔法按钮

Hermes Kanban 是一块持久化的任务板。你可以用它创建任务、分配 assignee、声明 parent/child 依赖、绑定 workspace、记录 comment、阻塞等待审核、完成后给下游传 handoff。

它适合管这种任务：

一个任务需要多个 profile 接力，比如 researcher → writer → default；
下游必须等上游交付后才能开始；
交付物必须有路径、有验证、有审核记录；
任务失败后不能靠人翻聊天记录猜状态；
你希望 worker 不只是“答一句”，而是按岗位技能执行。

它不适合管这种任务：

你只是问一句命令怎么写；
任务几分钟就能完成，没有上下游；
没有明确交付物，也不需要审核；
你还没把需求想清楚，只是随手丢一个念头。

这也是为什么 Hermes Kanban 的六列看板很重要。它不是装饰，它是任务生命周期。

六列可以这样理解：

列	含义	你该做什么
Triage	原始想法，还不是可执行任务	点 Specify，或用 `hermes kanban specify` 补成任务简报
Todo	任务已创建，但依赖未满足或还没分配	等 parent 完成，或补 assignee
Ready	已经可执行，等 dispatcher 或人工 claim	检查 gateway/dispatcher 是否在跑
In Progress	worker 已 claim，正在执行	看 heartbeat、runs、log
Blocked	等审核、等补料、或断路器触发	看 block reason，决定 unblock 还是打回
Done	任务完成	看 summary 和 metadata，给下游消费

不要小看这六列。多 Agent 协作最大的问题，不是 Agent 不会做事，而是状态没人管。

Agent 越会写代码，你越需要一块看板

Wed, 13 May 2026 12:25:00 +0800

你创建了 5 张 Agent 任务卡，以为系统会自动开干。

结果过了十分钟，什么也没发生。

不是模型不行，也不是任务拆得不够细。问题更尴尬：卡片创建，不等于任务执行。

这就是我这两天把文案线从 TASK_BOARD.md + inbox/active/done 文件流迁到 Hermes Kanban 时，最直接的体感。

以前我们用 Markdown 看板管 researcher、writer、coder。任务从 inbox 移到 active，再从 active 移到 done。听起来很朴素，也确实能跑。但一旦任务变多，问题马上冒出来：状态同步靠人记，交付物路径靠人写，谁能开始、谁在等审核、谁依赖谁，经常要翻半天聊天记录。

换成 Kanban 以后，事情并没有神奇地全自动。恰恰相反，我更清楚地看到一个事实：

Agent 越会干活，越需要一套严肃的任务面板。

多 Agent 的难点，已经不只是“让它写代码”。而是它写完之后，谁来审？失败之后，谁来接？上游没交齐素材，下游凭什么开工？任务卡完成了，交付物有没有真的落盘？

这才是 2026 年 Agent 工具真正开始分化的地方。

瓶颈换地方了

Vibe Kanban 的 README 里有一句话很准：Your Engineering Bottleneck Has Shifted。

过去，工程瓶颈在编码速度。

你有一个需求，开发者理解、写代码、调试、提 PR。AI 编码工具出现后，很多环节被加速了。Claude Code、Codex、Cursor Agent、Gemini CLI 这类工具，已经能承担相当一部分实现工作。

但加速之后，新的瓶颈露出来了。

不是没人写代码，而是没人稳定地规划、分发、审查、合并、回滚。

这也是为什么 Vibe Kanban 这种工具会火。它不是又一个聊天框，而是把编码 Agent 放进任务面板里：一个 issue 可以启动一个 agent workspace，配 git worktree、终端、预览和 diff review。人不再守着一个对话框等回答，而是像管理一组实习生一样管理 Agent。

说点大实话：真正厉害的 Agent 用户，早就不靠囤 Skill 找掌控感

Mon, 13 Apr 2026 16:58:00 +0800

说点大实话，很多人不是在用 Agent 变强，而是在靠囤 Skill 给自己找掌控感。

最典型的翻车场景就是：你装了一堆 Skill，写作有一套规则，发布有一套规则，校验又有一套规则。真正开工前，不是直接做任务，而是先花半小时猜今天到底该按哪套来。看起来系统越来越完整，实际体感却是越用越乱。

很多人刚开始玩 openclaw、Hermes 或其他 Agent，第一反应不是先把自己的工作流跑顺，而是到处找 Skill、装 Skill、囤 Skill。看起来像在升级系统，实际上很多时候只是把收藏癖换了个壳。Skill 列表是变长了，能力却不一定真的长在你自己身上。

我为什么从 OpenClaw 切到了 Hermes：Agent 世界里，苹果正在赢安卓

Mon, 06 Apr 2026 11:01:15 +0800

最近不少朋友问我，为什么我把主力 Agent 从 OpenClaw 切到了 Hermes。

先说结论：不是 OpenClaw 不好。恰恰相反，OpenClaw 当初最打动我的地方，就是它够猛，够自由，够像一台你可以随便改、随便接、随便折腾的 Agent 引擎。它像安卓，开放、灵活、想象空间大。

但也正因为这样，它很容易一路从“强大”滑向“失控”。

而 Hermes 给我的感觉，是另一条路。它没那么野，但它更完整、更稳、更像一个真正可以长期用、敢交给它跑起来的产品。你可以把它理解成 Agent 世界里的苹果：边界更清晰，系统更收敛，很多能力不是没有，而是已经被整理好了，装进一个更可控的框架里。

这篇文章不是参数对比，也不是功能表。我想从一个真正在两边都用过的人视角，聊聊我为什么最后决定切到 Hermes。

Hermes 的启动页给我的第一感觉就是：系统边界很清楚，信息密度也很高。工具、技能、模型、工作目录，开场就摆在台面上。

OpenClaw 为什么一开始那么让人上头

如果你用过 OpenClaw，大概率能理解那种感觉。

它最吸引人的，不是“能聊天”，而是“能长成任何样子”。

你可以给它做多 agent 架构，可以自己拼工作流，可以接各种插件，可以把不同能力揉成一个有点疯狂、但也很有创造力的个人系统。那种感觉很像第一次认真玩安卓自动化：你会觉得，原来系统还能这么改。

OpenClaw 最强的一面，其实是它给了你一种“这个系统没有天花板”的感觉。

但问题也恰恰出在这里。

当一个系统足够自由，真正的成本不是“不会”，而是“会了之后越来越乱”。

你会开始遇到这些问题：

配置越来越多，但不确定哪些还在生效
插件越来越多，但不知道哪些是稳定资产，哪些是历史包袱
记忆、技能、工作目录、渠道配置互相牵扯
同一个 Agent 今天还像 A，明天又像 B
你以为自己在增强它，结果往往是在制造更多不可预测性

这不是 OpenClaw 独有的问题。所有高度开放的系统，走到后面都会遇到这个坎。

自由，本身就是一种管理负担。

我切换的真正原因，不是功能，而是“系统感”

很多人选 Agent 工具，第一反应是看功能表：谁支持更多模型，谁的浏览器能力更强，谁的插件更多，谁更容易魔改。

但我现在越来越觉得，决定一个 Agent 能不能长期用下去的，不是功能点，而是系统感。

什么叫系统感？

就是它有没有把这些核心问题想明白：

配置边界在哪里
记忆边界在哪里
会话边界在哪里
工作目录边界在哪里
技能是怎么积累、怎么维护、怎么避免腐烂的
网关、消息渠道、CLI、工作区之间到底怎么隔离

OpenClaw 更像一套你可以自己搭的 Agent 操作系统。它很强，但很多系统级规则要你自己补。

Hermes 则明显更像一套已经定义好秩序的产品。它不是不让你扩展，而是先把最重要的边界给你立起来。