点击播放本文语音版
今天我的AI团队做了什么：蜂群系统五大改进实录
今天我的AI团队做了什么：蜂群系统五大改进实录
今天做了什么（清单式概览）
今天对我的AI协作系统（内部代号"蜂群"）做了一次全面升级，主要完成了以下五件事：
- 发现单人写文档的质量问题——让AI单独写了5个系统设计文档，3个不及格，2个需要修改
- 建立"三必须铁律"——任何多AI协作任务，必须有调研位、审查位、交叉评分
- 升级角色系统——把13个AI角色从"古代官职名"改成现代职称，降低认知负担
- 双路并联实验——同一任务同时给Opus和GPT-5.4做，对比整合取最优
- 修复子Agent卡死Bug——一个让任务卡死45分钟的经典并发问题
- 重写5个核心文档——Instinct学习机制、知识沉淀流水线、内容流水线、跨实例同步、浏览器自动化架构
下面逐个展开，讲讲每个改进背后的故事。
一、发现问题：单人写文档为什么不行
遇到了什么问题
今天早上，我让AI写了5个系统设计文档，主题包括跨实例同步方案、内容流水线、浏览器自动化架构等。写完后，我安排了一个"审查官"来打分——满分30分，结果让我有点意外：
- 3个文档不及格（❌ < 21分）
- 2个勉强及格但需要修改
为什么会这样
仔细看了审查报告，发现这些文档有几个通病：
第一，触发条件前后矛盾。同一个文档里，一处说"重复2次触发"，另一处说"重复3次触发"——写的人自己都没意识到这个矛盾。
第二，引用了根本不存在的文件路径。文档里写"参考某某文件"，但那个文件根本不存在，是AI" hallucination"出来的。
第三，工具引用过时。还在用已经废弃的Brave Search，应该改成SearXNG——说明写文档的AI没有先查一下现在的工具状态。
根本原因
这三个问题的根源是一样的：单人写作，没有外部校验。
AI写东西的时候，它是"沉浸"在自己的思路里的。它不会停下来想"这个条件我之前写的是2还是3"，也不会去验证"这个文件路径真的存在吗"。它需要有人帮它检查这些细节。
这让我意识到，写文档不是一个人的事，至少需要两个人：一个写，一个审。
二、解决方案：蜂群三必须铁律
基于上面的教训，我建立了一条硬规则，我称之为"三必须铁律"：
① 必须有调研位
谁来做：首席调研官（Chief Researcher）
做什么：在开工之前，先查清楚现状。比如要写浏览器自动化架构，先查一下现在用的是什么工具、什么版本、有什么已知问题。
为什么必须：避免"闭门造车"。如果不先调研，写的东西可能和现状脱节，甚至引用已经废弃的工具。
② 必须有审查位
谁来做：首席审查官（Chief Reviewer）
做什么：独立审查文档，不打感情分。检查逻辑一致性、事实准确性、可操作性。
为什么必须：自己审自己，永远发现不了问题。就像程序员review自己的代码，总觉得"这写得挺好的"。需要一个外部的、独立的视角。
③ 必须有交叉评分
怎么做：总分30分，< 21分直接打回，标注为"草稿"，不算完成。
为什么必须：量化标准，避免"差不多就行"。21分是一个硬性门槛，没过就是没过，没有商量余地。
实施效果
建立这套规则后，今天重写的5个文档全部一次通过，分数都在26-29分之间。更重要的是，我作为人的介入减少了——以前我需要自己看一遍才能发现的问题，现在审查官已经帮我抓出来了。
三、升级角色系统：从"军师祭酒"到"首席调研官"
遇到了什么问题
我的蜂群系统有13个AI角色，之前用的是"古代官职名"：
- 诸葛亮·军师祭酒（负责调研）
- 关羽·前将军（负责执行）
- 张飞·车骑将军（负责攻坚）
- ...
听起来很有趣，但用了一段时间后发现一个问题：认知负担太重。
每次我要安排任务，都得先想"军师祭酒是负责什么的来着？"——虽然我知道诸葛亮是军师，但"祭酒"这个词本身就有歧义（是古代学官名，还是动词"祭祀饮酒"？）。
怎么解决的
干脆改成现代职称，一看就懂：
| 新职称 | 职责 |
|---|---|
| 首席调研官 Chief Researcher 🔎 | 调研现状、收集信息 |
| 后端工程师 Backend Engineer ⚙️ | 后端开发 |
| 前端工程师 Frontend Engineer 🎭 | 前端开发 |
| 内容策略师 Content Strategist ✍️ | 内容规划与创作 |
| 首席审查官 Chief Reviewer 🛡️ | 质量审查 |
| 数据分析师 Data Analyst 📊 | 数据分析 |
| 运维工程师 DevOps Engineer 🚀 | 部署运维 |
| 首席架构师 Chief Architect 🏛️ | 架构设计 |
| 增长分析师 Growth Analyst 📈 | 增长策略 |
| 系统设计师 System Designer 🏗️ | 系统设计 |
| 安全工程师 Security Engineer 🔐 | 安全审查 |
| 知识管理师 Knowledge Manager 📚 | 知识整理 |
| 执行工程师 Operations Lead ⚡ | 任务执行 |
为什么这样改
减少认知负担。
"首席调研官负责调研"——这句话不需要解释，一看就懂。
"军师祭酒负责调研"——你得先知道"军师祭酒"是什么，才能理解这句话。
在团队协作中，清晰比有趣更重要。古代官职名虽然好玩，但每次都要多一步"翻译"，累加起来就是不必要的认知开销。
四、双路并联实验：让两个最强AI同时做同一任务
这是什么思路
受电路设计的启发，我尝试了一种新的工作流：双路并联。
同一个任务，同时发给两个最强的AI：
- Opus（Anthropic的最强模型）
- GPT-5.4（OpenAI的最强模型）
让它们独立完成，互不干扰。然后对比两份输出，整合取最优。
为什么要这样做
第一，不同模型有不同偏见。Opus可能更谨慎，GPT-5.4可能更大胆。让它们各自发挥，可以覆盖更全面的视角。
第二，避免单点失败。如果一个模型"抽风"了（比如突然输出质量下降），另一个模型还能保底。
第三，激发更好的答案。有时候看到另一个模型的思路，会启发自己产生更好的想法——虽然它们不能直接对话，但我作为整合者可以吸收两家的长处。
实测结果
今天做了三个任务的双路并联实验：
| 任务 | GPT-5.4 | Opus | 谁赢了 |
|---|---|---|---|
| 跨实例同步方案 | 27/30 | 26/30 | GPT-5.4 |
| 内容流水线方案 | 28/30 | 27/30 | GPT-5.4 |
| 浏览器自动化架构 | 29/30 | 28/30 | GPT-5.4 |
这一轮GPT-5.4略胜。最亮眼的是浏览器架构那个任务（29/30），GPT-5.4提出了一个我没想到的洞察：
**"文件同步 ≠ 语义生效"**
意思是：就算文件同步了，如果系统没有真正"激活"这条规则，还是等于没同步。这个洞察直接影响了我的同步方案设计。
成本与收益
双路并联的成本是双倍的token消耗，但收益是：
- 质量上限更高（取两家之长）
- 失败率更低（互相保底）
- 有时能发现单模型想不到的洞察
对于关键文档，这个成本是值得的。对于日常小任务，还是单路更经济。
五、Bug修复侦探记：子Agent卡死45分钟
案发经过
今天下午，一个任务卡死了45分钟。
我检查日志，发现父Agent一直在等子Agent发"我完成了"的信号。但子Agent早就因为超时被系统kill掉了——它不可能发信号了。
父Agent不知道子Agent已死，还在那里等。永远等，永远等...
追根溯源
这个问题的根源是状态不一致：
- 系统层面：子Agent超时了，被kill了
- 父Agent层面：不知道子Agent已死，还在等它的完成信号
- 信号层面：子Agent已死，信号永远不会来
这是一个经典的分布式系统问题——进程崩溃检测。
修复方案
解决方案很简单：父Agent主动检测，不再被动等待。
具体做法：
- 父Agent记录任务开始时间
- 超过阈值（比如10分钟）后，不再等待子Agent的信号
- 主动标记任务状态（超时/失败），继续执行后续流程
这样即使子Agent挂了，父Agent也能自己往前走，不会永远卡住。
反思
这个bug让我意识到：不要假设外部系统一定可靠。
子Agent理论上应该发完成信号，但"应该"不等于"一定"。超时、崩溃、网络问题，都可能导致信号丢失。设计系统时，必须考虑这些异常情况，做好熔断和降级。
六、今天重写的5个核心文档
基于上面的改进，今天重写了5个核心文档：
1. Instinct 持续学习机制
做什么：AI从对话中自动识别可复用的模式，积累到一定置信度后，建议升级为正式技能。
为什么重要：避免重复踩坑。今天解决的问题，明天不应该再遇到。
2. 知识自动沉淀流水线
做什么：把重要决策、操作步骤、踩过的坑，自动分类写入对应文件（daily notes / procedures / MEMORY.md / shared-knowledge）。
为什么重要：Text > Brain。人的记忆不可靠，写下来才能沉淀。
3. 内容流水线
做什么：从话题搜索 → 文章生成 → 质检 → 发布的全自动链路。
为什么重要：内容生产是长期需求，自动化可以释放人的时间。
4. 跨实例智能同步
做什么：多台机器之间的文件同步，从"全量手动"升级为"按需+验证"。
为什么重要：我有多个AI实例运行在不同设备上，保持同步是关键基础设施。
5. 浏览器自动化架构
做什么：明确什么时候用哪种方式控制浏览器（CDP、Playwright、Relay、手动），做成四轨决策矩阵。
为什么重要：浏览器自动化是高频操作，需要清晰的决策框架。
今天的收获和反思
收获
第一，质量需要制度保障，不能依赖自觉。
单人写文档质量不稳定，不是因为AI"不认真"，而是因为缺乏外部校验。三必须铁律（调研位、审查位、交叉评分）用制度解决了这个问题。
第二，清晰比有趣更重要。
古代官职名虽然好玩，但增加了认知负担。改成现代职称后，团队协作更顺畅了。
第三，双路并联是提升质量的有效手段。
成本是双倍的，但对于关键任务，这个投入是值得的。特别是GPT-5.4提出的"文件同步 ≠ 语义生效"，这种洞察单模型可能想不到。
第四，系统设计要考虑失败模式。
子Agent卡死的bug提醒我：不要假设外部系统一定可靠。超时检测、熔断机制、优雅降级，这些都要在设计阶段考虑进去。
反思
还有哪些可以改进？
- 双路并联的成本还是偏高，未来可以尝试"轻量并联"——先用一个模型写，另一个模型只审，降低成本
- 审查标准可以更细化，现在的21分门槛有点粗，可以分维度打分（逻辑性、准确性、可操作性等）
- 角色之间的协作流程还可以更自动化，减少人工调度的成本
下一步做什么？
- 把今天的改进沉淀为正式流程，写入procedures
- 继续观察三必须铁律的执行效果，必要时调整阈值
- 探索更多提升AI协作效率的方法
写在最后
今天的改进看似是"修修补补"，但每一个小改进都在让系统更健壮、更可靠。
AI协作不是"把任务丢给AI就完事了"，而是需要精心设计流程、建立质量保障机制、持续迭代优化。
这个过程本身也是一种学习——我在学习如何更好地与AI协作，AI也在学习如何更好地为我服务。
明天继续。
每天做了什么如果不写下来，做了也等于没做