一个人指挥一群 AI 干活:Hermes Kanban 从零到跑通

从零开始：先认识 Hermes 这个 Agent 平台，理解它已有的多 Agent 协作方式 delegate_task，以及它为什么不够用。
然后引入 Kanban：一张持久化看板，让 Agent 之间自动传递上下文。
最后实操搭一支 4 人 AI 软件团队，飞书远程指挥。

你有没有遇到过这种场景：跟 Agent 说「帮我加个密码重置功能」。

它吭哧吭哧写完后端 API。写完问你「前端要我做吗？」

你说「要」，它又开始写前端。写到一半忘了刚才的 API 长什么样。

换个 Agent 专门写前端？那你得手动告诉它「后端已经做了这些接口，参数是这几个」。

每换一个角色，就重来一遍上下文交接。

这不是 Agent 不够聪明。是缺少一套让 Agent 之间自动传递上下文的机制。

要理解这套机制怎么来的，得先认识承载它的平台。

认识 Hermes：不只是聊天

Hermes 是Nous Research开源的 AI Agent 运行平台。

说人话：它让你能在本地跑一个 AI 助手。不止能聊天，还能调工具、写代码、操控浏览器。

和 ChatGPT 的区别在哪？ChatGPT 是一个产品，你能在它的界面里用它的功能。

Hermes 是一个平台，你给它接什么模型、装什么技能、连什么消息通道——全由你定。

打个比方：ChatGPT 是租公寓，拎包入住但改不了墙纸。

Hermes 是自己盖房子，什么都得自己来，但想怎么折腾都行。

先把它装起来。

装起来：一条命令的事

打开终端，跑这一行：

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

装完验证：

hermes --version

配一个模型。Hermes 支持 20+ 模型提供商。新手推荐 DeepSeek，便宜好用，国内直连。

Hermes 接入 OpenRouter，3 分钟白嫖 23 个免费大模型

Hermes Agent 本地部署指南：零成本跑之前先看完这篇

新加坡Agnes AI 免费接入 Hermes：零成本白嫖指南

编辑 ~/.hermes/.env：

echo 'DEEPSEEK_API_KEY=你的key' >> ~/.hermes/.env

编辑 ~/.hermes/config.yaml，在 providers 下加：

providers:  deepseek:    model: deepseek-v4-pro

测试：

hermes chat -q "你好，用一句话介绍你自己"

有回复就通了。你现在有了一个能聊天、能调工具的 Hermes Agent。

但它是单兵作战。想让它带团队，得先理解 Hermes 怎么区分「不同的人」。

一个 Agent，一个 Profile

Multi-Agent 正确姿势：别开会话，要隔离身份

Hermes 里每个 Agent 是一个独立的 Profile（配置身份）。

每个 Profile 有自己的 SOUL.md（人设）、独立的记忆、独立的技能包。

这意味着你可以创建四个 Agent。

一个只管拆任务，一个专门写后端，一个负责前端，一个跑测试。它们互不污染上下文。

创建 Profile 很简单，从默认配置克隆：

hermes profile create project-manager --clone defaulthermes profile create backend-developer --clone defaulthermes profile create frontend-developer --clone defaulthermes profile create tester --clone default

现在你有四个「身份」了。但它们还不知道各自该干什么——那是后面 SOUL.md 的工作。

先看 Hermes 怎么让 Agent 之间协作。

delegate_task：Hermes 内置的多 Agent 协作

Hermes 自带一个多 Agent 协作能力：delegate_task。

它的模式是父 Agent 派一个子 Agent 去干活，自己等着。子 Agent 干完把结果传回来。

比如你对主 Agent 说「帮我搜一下 OpenAI 最新公告」。

它调 delegate_task 派一个子 Agent 去搜索。子 Agent 搜完，把结果摘要传回父 Agent。父 Agent 再回答你。

适合什么场景？

一问一答式的任务。

「帮我查这个」「帮我校验这段代码」「帮我翻译这篇文章」。

子 Agent 跑一趟，把结果带回来，就结束了。

工作原理上，它就是一个 fork→join 模型：fork 一个新 Agent 进程 → 干活 → join 回主流程。简单直接。

为什么 delegate_task 不够用

现在把场景升级一下。

你想搭一支团队写一个完整功能：后端写 API，前端写页面，测试验证。

你用 delegate_task 分别派三个子 Agent 去干活。问题来了：

后端 Agent 写完 API 就结束了。 它把结果传回给你，不是传给前端 Agent。

前端 Agent 开工时，不知道后端做了什么接口、参数叫什么。

你得手动当中介，把后端 Agent 的输出抄给前端 Agent。

更麻烦的是，子 Agent 一结束，它的上下文就没了。

崩了、重启了、过了两小时再继续。之前干了什么全忘。

这就是 delegate_task 的天花板：它只管任务执行，不管上下文传递。

适合一问一答，不适合跨角色的接力协作。

那跨角色协作需要什么？

Kanban：一张看板，Agent 在列后面排队

Hermes Kanban 是一张持久化的任务看板（基于 SQLite 的任务队列 + 状态机）。

跟你看过的 Trello、Linear 一样，有列、有任务卡片。区别在于，列后面等着的是 Agent，不是人。

看板上有 6 列：

Triage（待筛选）：你脑子里有个粗糙想法，比如「加个限流」，扔进去。

系统帮你把三字标题细化为完整任务描述。

Todo（待办）：任务已创建，但前置依赖还没完成。

比如「写前端登录页」依赖「后端认证 API」。API 没做完之前它不会动。

Ready（就绪）：依赖全部满足，等 Agent 来领。

In Progress（进行中）：Agent 正在跑。

Blocked（阻塞）：Agent 撞墙了。权限不够、依赖缺失、逻辑矛盾，会停下来等你处理。

Done（完成）：搞定，附带完整运行历史和总结。

Agent 不会自己决定做什么。它有一套固定的工作流。

先调 kanban_show() 看任务详情和之前的 Agent 写下的总结，然后干活。

干完了调 kanban_complete() 写上自己的总结。

这个「总结」就是整个系统的核心。

上一个 Agent 写完：

我改了 auth.ts，新增了 /api/reset-password 端点。POST 请求，参数是 email。

下一个 Agent 开工前读到这句话。它不需要重新翻代码，不需要猜接口。

这就是 Briefing（任务简报），Agent 之间的上下文传递协议。

和 delegate_task 的区别：delegate_task 是函数调用，Kanban 是消息队列。

函数调用 fork→join，子任务跑完结果回传就没了。

消息队列持久化，上一个 Agent 写总结，下一个 Agent 读取。不需要父 Agent 当中介。

前置准备：飞书 Bot + 模型

好，理论差不多。开始搭。

先确认你的 Hermes 已经装了、模型配好了（上面「装起来」那节）。

然后接飞书，让 Agent 在飞书里听你指挥。

打开飞书开发者后台（open.feishu.cn），创建一个企业自建应用。

在「应用功能 - 机器人」页面，打开机器人能力。记下 App ID 和 App Secret。

在「权限管理」页面，搜索并添加这几个权限：

• im:message — 收发消息
• im:message.p2p_msg:readonly — 读取私聊
• im:message.group_at_msg:readonly — 读取群聊 @消息

发布一个新版本，管理员审批通过后生效。

终端里跑：

hermes gateway setup# 选择 Feishu / Lark# 填入 App ID 和 App Secret# 连接模式选 WebSocket（推荐，无需公网 IP）# 扫码授权

看到 Feishu connected 就成功了。到飞书里找到你的 Bot，发一条「你好」，确认能回复。

飞书用的是 WebSocket 模式。Hermes 通过飞书 SDK 建立一个持久的出站连接，不需要你暴露公网端口。

断开自动重连。

搭 Kanban：三步组一支 AI 软件团队

目标：搭一支 4 人团队。一个 PM（拆任务）、一个后端（写 API）、一个前端（写页面）、一个测试（验证）。

通过飞书远程指挥。

Step 1：给每个 Agent 写人设

Profile 在「认识 Hermes」那节已经建好了。现在给它们写 SOUL.md，告诉每个 Agent 它是谁、管什么、不管什么。

不要写太长，聚焦职责边界。

PM 的 SOUL.md（~/.hermes/profiles/project-manager/SOUL.md）：

你是项目协调者。你的唯一职责是：- 读取用户的高层目标- 用 kanban_list 检查已有的 Agent 资源- 把目标拆成任务，用 kanban_create 创建并链接依赖- 在所有任务完成后，读 kanban_show 的总结，判断是否完成你永远不写代码，不跑测试。你只协调。

后端开发的 SOUL.md：

你是后端工程师。你只负责：- 读 kanban_show 拿任务和前置 Agent 的总结- 写后端代码（API、数据库、认证）- 完成后调 kanban_complete，总结改了什么文件、API 接口是什么你不碰前端代码。

前端和测试的 SOUL.md 同理。各管各的，互不越界。

Step 2：装技能

Skills 是 Agent 的「上岗培训」。教它怎么用特定工具。

# 添加技能源hermes skills tap https://github.com/nousresearch/hermes-skills# 给后端装 InsForge 全家桶hermes --profile backend-developer skills install insforge-backend insforge-cli insforge-debug insforge-integrations# 给前端装设计技能hermes --profile frontend-developer skills install frontend-design# 给测试装测试技能hermes --profile tester skills install webapp-testing

Step 3：初始化看板 + 启动

# 创建看板（生成 ~/.hermes/kanban.db）hermes kanban init# 启动 Gateway（内嵌 dispatcher，每 60 秒扫描一次任务）hermes gateway start

启动后随时检查状态：

hermes gateway status# 应该看到 Feishu: connected ✓

跑起来：飞书发任务，看板看进度

打开飞书，找到你的 Hermes 机器人，发一条消息：

帮我做一个 Google Docs 克隆，需要完整的后端 API、前端编辑界面、和端到端测试。

PM Agent 收到消息后会做这几件事：

调 kanban_list 看有哪些 Agent 可用
把「Google Docs 克隆」拆成几个任务：后端 API、前端界面、端到端测试
用 kanban_create 逐个创建任务，设置依赖关系：前端依赖后端、测试依赖前端
回复你：「已创建 3 个任务，开始排队执行」

接下来不用管了。Dispatcher（调度器）每 60 秒扫描一次看板，发现 Ready 列有任务就分配对应 Agent。

想看实时进度：

# 命令行hermes kanban watch# 或者打开 Dashboard# http://127.0.0.1:9119

Dashboard 有几个实用操作：

• 按 Agent 分组看谁在干什么
• 点卡片看完整运行历史
• 手动调整任务优先级和依赖关系

三种协作模式，覆盖真实场景

光会排队还不够。真实项目里有三种高频场景：

Pipeline（依赖链）。 最常见的模式。

后端→前端→测试，只有前一个 Done，后一个才进入 Ready。Dispatcher 自动处理流转。

Human-in-the-loop（人工介入）。 Agent 跑到一半发现权限不够。

它在飞书里回你「需要访问文档服务的管理员权限」。任务自动进入 Blocked 列。

你开完权限，在飞书里回一句「已开」，Dashboard 上点「Unblock」。Agent 下一轮调度自动继续。

而且它知道上次为什么 Blocked，不用从头来过。

Triage（草稿细化）。 有时候你只有一句「加上限流」，不想写完整的任务描述。

扔进 Triage 列，系统自动把三个字扩充成完整的任务说明：

目标：防止 API 被滥用。方案：令牌桶算法，每分钟 100 次。验收标准：超过限制返回 429。

Agent 拿到的是一个完整的任务，不是一句模糊的话。

简单说：一问一答用 delegate_task，跨角色接力用 Kanban。记住这句话就够了。

踩坑清单

搭起来不难，跑的时候有几个坑提前知道能省不少时间：

数据库过载。 SQLite 是单写者。2-4 个 Agent 并行没问题，10+ Agent 同时高频写入会卡。用 hermes kanban dispatch --max 4 限制并发数。

Scratch 工作区会丢代码。 默认情况 Agent 在临时目录（scratch）里跑，任务完成就删了。

如果你要它写代码，两个选择：

• 用 worktree（Git 工作树，代码自动保留）
• 在任务描述里写明项目文件夹路径

千万别用默认 scratch 跑代码任务。

本地模型饱和。 如果你用 Ollama 本地模型，同时跑 4 个 Agent 可能把 GPU 撑爆。

推理速度骤降，耗时超标触发自动停止。

本地模型建议 --max 2。用 API 模型（DeepSeek、Claude 等）不存在这个问题。

Dispatcher 间隔。 默认 60 秒扫一次。刚建完任务想立刻看到 Agent 动起来，Dashboard 上点「Nudge dispatcher」强制立即扫描。

下次你有一个跨域的任务——比如「加个功能」这种需要后端+前端+测试协作的活。

试试别让一个 Agent 硬撑。给它配一支团队。

在飞书里丢一句需求，然后去 Dashboard 看它们排队干活。

你跑通了吗？把截图发评论区。

参考来源

• Hermes 官方文档：hermes-agent.nousresearch.com/docs/user-guide/features/kanban
• 飞书集成文档：hermes-agent.nousresearch.com/docs/zh-Hans/user-guide/messaging/feishu
• X Article 源文：x.com/akshay_pachaar/status/2062526843564233040