事情是这样的。

最近出现了一个堪称疯狂的尝试——不是测新模型，也不是上手新框架，而是试图搭建一个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同时自信地胡说八道，根本不知道该信谁。

多Agent的上限不是Agent数量决定的，是交接质量决定的。所以越来越倾向把每个Agent的任务写成合同——不是一句“帮我优化一下”，而是写清楚输入、输出、禁止事项、验收标准、阻塞条件。前者是聊天，后者是工单。AI做站要想稳定，必须从聊天变成工单。这句话有点冷，但是真的。

说到这儿，这套东西真正想解决的问题其实不是自动建站。自动建站只是表层。更深层的问题是：未来一个人怎么管理一群AI员工。

以前说“一个人公司”，更多是在说一个人加很多SaaS工具。现在不一样了——面对的不再是工具按钮，而是一堆能主动行动、会写东西、会改代码、会提建议、也会犯错的Agent。这时候最需要的能力，不是会不会写prompt，而是会不会设计组织：谁负责什么，谁不能越界，谁验收谁，哪里必须人工确认，错误怎么回滚。这些听起来不像AI技巧，更像管理，也更像工程。

从写prompt变成搭流程，从调模型变成管团队。

Kanban状态机

从跟一个AI聊天，变成带一群AI干活。这就是这段时间最真实的感受。不是炫技，也不是教程，就是一个很朴素的发现：当AI员工越来越多，最稀缺的不是员工，是秩序。而Kanban，就是现在给这群AI员工上的第一套秩序。