一个人怎么管理 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 同时自信地胡说八道，你根本不知道该信谁。
【配图 1：Telegram 群里多个 topic 的截图】
多 Agent 的上限，不是 Agent 数量决定的。是交接质量决定的。
所以我现在越来越喜欢把每个 Agent 的任务写成合同。不是一句「帮我优化一下」，而是写清楚输入、输出、禁止事项、验收标准、阻塞条件。
前者是聊天，后者是工单。
AI 做站要想稳定，必须从聊天变成工单。
这句话有点冷，但是真的。
说到这儿，我觉得这套东西真正想解决的问题，其实不是自动建站。自动建站只是表层，更深层的问题是，未来一个人怎么管理一群 AI 员工。
以前我们说一个人公司，更多是在说一个人加很多 SaaS 工具。现在不一样了。你面对的不再是工具按钮，而是一堆能主动行动、会写东西、会改代码、会提建议、也会犯错的 Agent。
这时候你最需要的能力，不是会不会写 prompt。
是会不会设计组织。
谁负责什么，谁不能越界，谁验收谁，哪里必须人工确认，错误怎么回滚。这些听起来不像 AI 技巧，更像管理，也更像工程。
从写 prompt，变成搭流程。从调模型，变成管团队。
【配图 2：kanban 状态机截图】
从跟一个 AI 聊天，变成带一群 AI 干活。
这就是我这段时间最真实的感受。不是炫技，也不是教程，就是一个很朴素的发现。
当 AI 员工越来越多，最稀缺的不是员工，是秩序。
而 *Kanban，就是我现在给这群 AI 员工上的第一套秩序 *。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
链接我进千人 AI 交流群。
谢谢你看我的文章，我们，下次再见。
