一个人怎么管理 13 个 AI 员工？我用 Hermes Kanban 试了一次

事情是这样的。

前段时间我干了件挺神经的事。

不是测哪个新模型,也不是上手哪个新框架。我想搞一个AI做站工厂。

不是输入一句话生成静态页面那种demo。也不是让一个Agent从头到尾硬憋,写到一半上下文爆掉,给你一个理论上能跑的项目。

我想要一条真正像公司生产线一样的流程。

找词、PRD、定价、合规、文案、设计、前端、后端、QA、SEO、增长,最后还有一个复盘的人,负责判断这项目该继续做,还是该杀掉。

13个角色。

听起来像过家家。但我真的开始搭了。

越搭越觉得,这玩意儿真正难的地方,根本不是让AI干活。

让AI干活太简单了。你打开任何一个聊天窗口,让它写PRD、写首页、改bug,它都能动。

真正难的是,当这件事不是一个任务,而是一条链路的时候,谁来保证上一个人做完的东西,能被下一个人稳定接住。

这才是多Agent的命门。

我一开始也没想这么复杂。最朴素的想法,搞个Telegram群把几个Bot拉进来,一个叫总管,一个叫找词,一个叫PRD,一个叫QA。

我在群里喊,总管,开始做一个网站。总管说收到,找词说开始找词,PRD说等找词结果。

挺像一个团队。

但只要跑长一点,问题立刻出来。

群聊是热闹的。但群聊不是事实源。

今天找词Bot发了一段候选关键词,明天PRD Bot到底读哪一版?设计Bot改了一版视觉,前端Bot没看到那条消息是不是又要重来?QA发现了问题,修复任务发给谁?

更麻烦的是,人也会插话。我可能中途说一句,这个方向先别做。这些东西全靠聊天记录保存,过两天回头看,基本就变成考古。

你要在一堆「收到」「完成」「我继续」里面,找那句真正影响流程的话。

非常痛苦。

所以我后来意识到一件事。

多Agent不是多几个Bot在群里聊天。多Agent必须有一个状态机。

这个状态机要知道,任务现在在哪儿,归谁,依赖谁,产物在哪儿,哪里卡住,下一步是什么。

这就是我把Kanban搬进做站流水线的原因。

Kanban这词以前我也觉得有点管理味。但当你真的把它塞进Agent工作流,它就不再只是项目管理工具。

它变成了多Agent的共享记忆。

更准确点,它变成了这群AI员工之间的交接班记录。

我后来越来越确定一件事,Telegram只能当观察窗,不能当数据库。

Telegram Topic适合给人看,Kanban卡片适合给机器交接。这两个东西不能混。

所以我现在给整条链路定了一个原则。

Bot可以汇报,但事实必须回写Kanban。

Bot可以说话。Kanban才算数。

这句话我觉得可以贴在所有多Agent项目门口。

搭下来还有一个反直觉的发现。AI团队不是人越多越好。

很多人一聊多Agent,就想上来搞二三十个,每个起一个很酷的名字,看起来像复仇者联盟。

但如果你没有任务系统,没有交接规范,没有验收边界,Agent越多,混乱越快。

一个Agent胡说八道你还能盯住。十个Agent同时自信地胡说八道,你根本不知道该信谁。

群聊里面多个topic 如下图

多Agent的上限,不是Agent数量决定的。是交接质量决定的。

所以我现在越来越喜欢把每个Agent的任务写成合同。不是一句帮我优化一下。而是写清楚输入、输出、禁止事项、验收标准、阻塞条件。

前者是聊天,后者是工单。

AI做站要想稳定,必须从聊天变成工单。

这句话有点冷,但是真的。

说到这儿,我觉得这套东西真正想解决的问题,其实不是自动建站。

自动建站只是表层。更深层的问题是,未来一个人怎么管理一群AI员工。

以前我们说一个人公司,更多是在说一个人加很多SaaS工具。

现在不一样了。

你面对的不再是工具按钮,而是一堆能主动行动、会写东西、会改代码、会提建议、也会犯错的Agent。

这时候你最需要的能力,不是会不会写prompt。

是会不会设计组织。

谁负责什么,谁不能越界,谁验收谁,哪里必须人工确认,错误怎么回滚。

这些听起来不像AI技巧。更像管理,也更像工程。

从写prompt,变成搭流程。

从调模型,变成管团队。

kanban 状态机

从跟一个AI聊天,变成带一群AI干活。

这就是我这段时间最真实的感受。

不是炫技,也不是教程。就是一个很朴素的发现。

当AI员工越来越多,最稀缺的不是员工，是秩序。

而Kanban,就是我现在给这群AI员工上的第一套秩序。

以上,既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧,如果想第一时间收到推送,也可以给我个星标⭐~