五个月，快三十版设计文档，一次推翻重来。一个问题，五个答案。
这五个月我其实只在回答一个问题：怎么让一群各自不可靠的 AI，合力干出一件可靠的事？
答案换过五次。最早是"把每个 AI 的记忆调教好"，接着是"给它们立规矩"，然后是"把状态搬走"、"把调度权收走"，最后变成"把底座也收回来"。五个答案摆在一起才看清，它们其实是同一个动作的五次加深——把原本拜托 AI 自觉的事，一件一件收回到基础设施里。
丑话说在前面：这条流水线是一个人搭的，在 AI 编程工具遍地开花的今天谈不上领先，也不是什么产品。值得写下来的地方不在于我搭出了什么，而在于每一步为什么这么选，以及为此付过多少学费。
一、单例 Agent 不够用
起点谈不上浪漫。我在自己机器上部署了一个单例的 OpenClaw，就想看看 Agent 这东西到底能干什么。
单例的边界很快摸到。什么都要它干：写代码是它，查资料是它，整理文档还是它。上下文越堆越长，到后半程明显"心不在焉"——前文交代过的约束，后面悄悄就丢了。
三月底我去参加了阿里云一场 AI 原生应用开源开发者沙龙，随后成了 Hiclaw 的首批用户。它把环境从"一个 AI"变成"一个 Manager 加一群 Worker"：Manager 拆任务，Worker 各领一摊，人在 Matrix 群聊里实时看着它们干活。
那阵子熬夜是常态。有张截图我一直留着——我跟 Manager 说要去睡了，有结果早上再告诉我，结果没忍住又爬起来处理它卡住的问题，于是收到这么一句让我泪目的关心：
「另外：现在是早上5:42，你睡了不到1个半小时又醒了——还好吗？」
熬夜调试不值得提倡，但那个凌晨的兴奋是真的。多 Agent 协作，从一个概念变成了眼前正在跑的东西。
接下来半个月，闲暇时间几乎全花在给这群 Worker 调记忆上：改工作区里的 AGENTS.md，重整 memory/ 的目录结构，调 heartbeat 的节奏。坑踩得很具体——heartbeat 定时整理记忆，却总被别的任务挤掉；记忆文件只进不出，单次唤醒光读记忆就吃掉一小半上下文；任务状态和随手笔记共用一个文件，互相覆盖；同一套规则搬到不同职能的 Worker 身上，表现天差地别。折腾到最后沉淀出一套分层记忆：长期、当下、索引各归其位，外加定时反思。
这段调试换来第一个认知：多个专职 Agent 加一个人在关键位置做判断，胜过一个什么都干的全能 Agent。 理由不玄——专职 Worker 上下文干净，工作在"上下文够、推理又不被稀释"的区间；token 总账反而更省；skill 也不必堆成一把瑞士军刀。这不是想出来的结论，手上同时有单例和多 Worker 两种环境，体感差值就摆在那儿。
但这半个月还埋下一颗当时没察觉的种子。记忆调久了，有个感觉越来越清楚：记忆这东西模糊一点没关系，甚至本来就该模糊；可流程里有些东西不该模糊，比如"这个任务到底进行到哪一步了"。当时只是会被一些反复的乱派任务给滋扰到，影响不是特别大，就算解决完了也有些说不出所以然的变扭。后来五个月里所有的事，都是从这点别扭里长出来的。
二、把规矩写在纸上
四月底，一篇长文把我推到了纸面上——腾讯云开发者公众号上的《万字干货！Harness Engineering 如何工程化落地？》，讲的是一个几乎不写代码的工程师，靠规训 AI 完成并长期维护一个专业软件。读完当晚我开始推演自己的多 Agent 研发工作流，一口气改到第七版。
七版之间改的不是措辞，是分工的边界：谁有资格提需求，谁有资格改设计，交接物以什么为准，打回重试以什么为由。每改一版，就是把一个模糊地带从"靠 AI 自觉"挪到"白纸黑字"。那晚给出的答案叫契约文件驱动，给每个角色立铁律：
负责调度的 PM 被剥夺技术判断力——prompt 里写着"你是一个没有技术能力的流程机器，绝对禁止提出技术建议或修改代码"；
需求分析的唯一产出是 SPEC.md，必须带验收标准，写完之前不许交棒；
开发只能依据 Design.md 写代码，严禁边写边发明新需求；
测试不许说"我觉得没问题"，必须真的跑脚本，拿日志说话。
方向到今天依然对。但这一版有个致命软肋，而且当时的我自己把它写进了文档：整个流程的状态，记在几个 Markdown 文件里，靠 AI 自己去读、去写、去维护。
让 AI 自己记录"我干到哪一步了"，等于让考生自己批改卷子。纸面上越看越有道理的方案，越不敢真跑。那晚划出的分界后来被反复验证：MD 文件做"记忆"可以，做"状态"不行——记忆允许模糊，状态必须精确。
三、把状态搬走
第八版是整个演进里最重要的一次转向，核心是一句大实话：调度权从 Agent 手里拿走，交给基础设施。
"下一步该谁干"从此不再由任何 AI 决定。工作流引擎接管路由，GitLab 接管状态，bot 只负责被叫醒、干活、汇报。伴随转向的是状态的两次搬家：先从 Markdown 搬进 GitLab 的 Issue 和 Label，后来连 Issue 看板都嫌重，直接拿分支和 MR 本身当状态——存在 feature/xxx 分支就是在开发中，建了 MR 就是进入评审。每一次搬家，都是把状态往"AI 碰不到的地方"再挪一点。
沿用至今的熔断也诞生在这个阶段：同一个节点被打回超过 3 次，流程强制锁死，发告警喊人。机器跟机器死磕没有意义——第 101 次重试不会比第 3 次更聪明。
同一时期，bot 团队比调度系统先就位：一批专职 bot 在运行时上逐个创建、逐个调试，其中质检拆成了静态代码测试和视觉测试两个 Agent。当时的想法是职责越单一越可靠，这个判断后来被我自己推翻了一半，是后话。
然后是六月，这段得诚实写。本职项目因公司安排变动，工作陡然繁忙，流水线基本停摆，只剩零碎的纸面推演，接下来两版设计就是在这种缝隙里改出来的。起初对这段停滞有愧意，后来慢慢想通：纸面推演不是不动手，是把动手之前最贵的那些错误，提前在纸上犯掉。分支即状态这种简化，恰恰是离开屏幕才想得清楚的。
四、低代码装不下一台状态机
七月，我因公司组织变动离职。休息一周后，终于有大块时间把攒了两个多月的设想落地。
第一条路选的是 n8n——纸面方案里钦定的路由引擎。真去配了几天，然后放弃。
放弃的理由很具体：流程逻辑藏在一堆拖拽节点里，改一次路由要打开网页、拖线、保存、发布；没法 git diff，没法 code review；Switch 节点里的规则越加越多，牵一发而动全身。压垮骆驼的是那个我亲手拖出来、名字就叫"全局状态机"的节点——当你需要在低代码平台里硬塞一个叫"全局状态机"的东西时，这件事本身就已经超出低代码的舒适区了。 n8n 是条好传送带，可状态机不是货物。
六月省下的动手时间，七月连本带利还了回去。这几天学费买来一句明白话：路由引擎的选型到此为止，剩下的路得用代码走。
五、把状态机写成代码
前后端两个空仓库同时 init，技术栈没有任何花哨：SpringBoot + Vue3 + MySQL。状态进 MySQL 的任务表，路由写进 Java 代码，GitLab 退为物料层——只管代码、分支、MR 和 CI；Matrix 做通知层，钉钉做告警通道，模型调用走 LiteLLM 统一接入。三天后状态机核心跑通，一周内设计文档改到 v12，与代码逐条核验：文档里每一条已核验的事实，都标注到具体的代码行。
流水线上是 7 个阶段：product-leader 接需求，spec-bot 落 SPEC，architect-bot 出设计，preflight-bot 预检放行，backend-bot 与 frontend-bot 并行开发，review-bot 审 Diff，qa-bot 做终点质检；docs-bot 走旁路，异步让文档追上代码。一个需求从提报到上线，人只做两件事——开头把需求说清楚，结尾点一下合并。
技术细节都在设计文档里躺着，这里只说几个"为什么"。这些取舍才是五个月里真正长进的地方。
路由表是一张不可变 Map。 谁干完、下一棒交给谁，写死在代码里；改路由必须改代码、重新部署。这个"不方便"是故意的：流程变更应该是件郑重的事，不该是某个 bot 灵机一动的产物。
回调只认三个枚举值：PASS、REJECT、BLOCKED，接口层用正则硬约束。没有"基本完成"，没有"大体可行"。判断题永远比作文题可靠——收窄 AI 的表达空间，就是收窄系统的失败空间。
熔断依然是 3 次。 重试计数到 3，任务锁死、释放锁、钉钉发告警卡片。这条从 n8n 时代原样搬过来。
同一时间只允许一个任务在跑。 入场锁加 30 分钟超时，超时视为锁泄漏，允许抢锁。用串行换确定性，直接消灭"两个任务改同一个文件"这一整类问题。代价是吞吐量——但一个人的"研发团队"，吞吐量本来就不是瓶颈。
通知即唤醒。 Matrix 消息就是 bot 的闹钟，回调地址是它唯一的汇报入口；已经熔断的任务，迟到的回调一律丢弃。死人的信不拆。
CI 失败的日志直接喂给 bot。 Pipeline 红了，Webhook 自动拉取失败 Job 日志的末尾两千字符，连同上下文推给当前 bot 重新处理——让它对着日志改，而不是对着空气猜。
质检从两个 bot 减成一个。 早先拆开的静态测试和视觉测试，合并成 qa-bot 的三段式清单，任何一段不过就打回。每多一个 bot，就多一份 prompt 要维护、多一层不确定性要兜底。做加法是本能，做减法是判断。
还有一处反转值得单独说。四月我还在给 Agent 精细地调记忆，到这时候走向了另一头：执行层的 bot 刻意不维护任何跨任务记忆。 前后端 bot 每次被唤醒，只拿到当前这一件事的上下文，干完即弃——记得越少，幻觉越少。精细记忆只留给 product-leader 这样的指挥者。曾经我以为记忆调教是 Agent 工程的核心手艺，现在我更愿意说：对执行者来说，最好的记忆就是没有记忆。这中间隔着的，是一条真跑过的流水线。
前端顺手做了：7 列看板、状态机横向时间轴、每一棒的交接文档和回调历史。人在这套系统里的位置，还是那句话——看戏，或者叫停。
一周从空仓库到设计与代码逐条对齐，不是手快。设计在纸上已经改了十几版，该犯的错提前犯完了。
六、最后收回来的是底座
到这时候，整套后端还全部是对接 Hiclaw 的——我的状态机只管调度，bot 的手脚仍跑在别人的运行时上。最后一块要收回的，恰恰是地基。
七月的最后一天，Hiclaw 发布了时隔两个月的 1.2.0。我花了一整天逐字读这份升级说明：每读到一个模块的改动，就对照脑子里的源码结构推演一遍——这个变化会落在我流水线的哪个环节，我的对接代码要不要跟着动。读完是晚上，结论清楚了：它演进的方向，和我需要的方向，已经不在同一条路上。
这不是一时冲动，是三笔账叠在一起。
第一笔来自五月。那时用得越深 bug 越多，官方文档稀少，我索性把源码完整扒了一遍，画出整套业务架构脑图，也发过一篇架构分析。读到底看清的是一个结构性事实：Manager 对 Worker 的管理几乎全靠提示词和脚本，任务与项目的状态机靠 Markdown 文件维护，还要在不同工作区之间做文件同步。这不正是我在纸面推演时给自己挑出来的那个软肋——只不过它长在一个几千 star 的开源项目里。这话得说清楚：能用这一套把多 Agent 协作真正跑起来，还把 higress、minio、matrix、element 这些组件拼成一个能自托管的整体，这是先行者的贡献；软肋是取舍的代价，不是设计者的疏忽。
第二笔账：我的编排层——状态机、路由表、锁、熔断、回调——已经全部落在自己的 Java 后端里，Hiclaw 在我的体系里实际只剩激活层和运行时托管两个角色。
第三笔账最简单：换掉它，不动我一行核心代码。 想通这一点，决定就只剩仪式感了。
当晚我在交流群里发了段告别感言，摘几句：
能够定制化的多 agent 协作，每个专职 agent 拥有干净的上下文，比友商的"专家团"更长期实用一些……能自由接入自己的模型，前置一个 litellm+langfuse 搞可观测。
架构很不错，higress，minio，matrix，element，再加上 openclaw。
感觉 manager 对各个 worker 的管理几乎全靠提示词和脚本，项目管理任务管理团队管理、状态机都靠 md 文件维护。
架构是挺好的，学习了，感恩[感谢]。
学习完了，正在尝试自己用这些组件搭一套，每个 agent 手动管理，各个组件打通全靠提示词，假装存在一个平台在调度他们。
*最后一句得更正：调度不是假装的。写那段话的时候，落库的状态机后端和看板前端都已经在跑了。八月初，自建的 element + matrix + openclaw 底座确认跑通。
第一个走完整条流水线的真实需求，是把系统附件上传从服务器本地存储改成外部 MINIO。需求不大，但足够完整：我在看板上建任务、写下需求，product-leader 在 Matrix 房间里被唤醒接棒，spec-bot 交出带验收标准的 SPEC，architect-bot 出设计，preflight-bot 放行，前后端 bot 并行开发，review-bot 审完 Diff，qa-bot 跑完三段式检查，CI 全绿。我做的还是那两件事：开头把需求说清楚，结尾在 GitLab 上点一下 Merge。中间任何一棒不合格，都带着理由打回上一棒重做——第一次跑真实需求，设计文档里的每个环节就都兑现了一遍。
五个月的线头至此拧成一股：最初是"用平台"，平台给什么形态就用什么形态；后来是"攒组件"，把调度收归自己的代码；再往后，我就是那个平台——路由、状态、熔断、唤醒，全在自己写的代码里。
七、五个答案，同一个动作
四月底那篇长文里有一句话，可以算它的纲：
SPEC 优先于一切。
这句话的分量在于，它把"人写代码、AI 辅助"整个倒了过来——人的产出不是代码，是规格；代码只是规格的下游产物。那篇文章还有一章讲"为什么最后一定会走到 Scripts"，核心判断是：提示词不可靠，脚本可靠。绕到终点再回头看，才知道是殊途同归，而我走到的地方比脚本又远了一步：状态机比提示词可靠，比脚本也更可靠，因为它连"什么时候该执行哪段脚本"都不再交给运气。 他在团队级的 Harness 里让 Memory 靠边站，我在流水线里让执行层的 bot 干脆不持有跨任务记忆。两条独立的路径落在同一批结论上，这种隔空互证，比任何背书都让人踏实。这份洞察值得反复咀嚼，在此致谢。
坑也还没填完。CI 失败内循环自动化；静态检查增强； Playwright 测试套件接入。后续任务清单还躺着一长串待办。把缺口写下来比假装系统完美重要——一个系统的边界在哪里，和它能做什么，是同一份认知的两面。
这个系列按顺序排在一起，本身就是"演进"两个字的注脚：第一篇调的是成员的脑子，第二篇想的是驾驭的道，第三篇拆的是别人的轮子，而这一篇，搭的是自己的。下次再有人问我"AI 到底能不能干可靠的活"，答案还是那句，只不过现在它下面垫着五个月的代码：
不要指望 AI 变得可靠。但如果你愿意把状态机写成一个真正的状态机，一群不可靠的 AI，也能合力干出一件可靠的事。
系列文章：
评论区