今天我的AI团队做了什么：蜂群系统五大改进实录

今天做了什么（清单式概览）

今天对我的AI协作系统（内部代号"蜂群"）做了一次全面升级，主要完成了以下五件事：

1. 发现单人写文档的质量问题——让AI单独写了5个系统设计文档，3个不及格，2个需要修改
2. 建立"三必须铁律"——任何多AI协作任务，必须有调研位、审查位、交叉评分
3. 升级角色系统——把13个AI角色从"古代官职名"改成现代职称，降低认知负担
4. 双路并联实验——同一任务同时给Opus和GPT-5.4做，对比整合取最优
5. 修复子Agent卡死Bug——一个让任务卡死45分钟的经典并发问题
6. 重写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角色，之前用的是"古代官职名"：

• 诸葛亮·军师祭酒（负责调研）
• 关羽·前将军（负责执行）
• 张飞·车骑将军（负责攻坚）
• ...

听起来很有趣，但用了一段时间后发现一个问题：认知负担太重。

每次我要安排任务，都得先想"军师祭酒是负责什么的来着？"——虽然我知道诸葛亮是军师，但"祭酒"这个词本身就有歧义（是古代学官名，还是动词"祭祀饮酒"？）。

怎么解决的

干脆改成现代职称，一看就懂：

为什么这样改

减少认知负担。

"首席调研官负责调研"——这句话不需要解释，一看就懂。

"军师祭酒负责调研"——你得先知道"军师祭酒"是什么，才能理解这句话。

在团队协作中，清晰比有趣更重要。古代官职名虽然好玩，但每次都要多一步"翻译"，累加起来就是不必要的认知开销。

---

四、双路并联实验：让两个最强AI同时做同一任务

这是什么思路

受电路设计的启发，我尝试了一种新的工作流：双路并联。

同一个任务，同时发给两个最强的AI：

• Opus（Anthropic的最强模型）
• GPT-5.4（OpenAI的最强模型）

让它们独立完成，互不干扰。然后对比两份输出，整合取最优。

为什么要这样做

第一，不同模型有不同偏见。Opus可能更谨慎，GPT-5.4可能更大胆。让它们各自发挥，可以覆盖更全面的视角。

第二，避免单点失败。如果一个模型"抽风"了（比如突然输出质量下降），另一个模型还能保底。

第三，激发更好的答案。有时候看到另一个模型的思路，会启发自己产生更好的想法——虽然它们不能直接对话，但我作为整合者可以吸收两家的长处。

实测结果

今天做了三个任务的双路并联实验：

这一轮GPT-5.4略胜。最亮眼的是浏览器架构那个任务（29/30），GPT-5.4提出了一个我没想到的洞察：

**"文件同步 ≠ 语义生效"**

意思是：就算文件同步了，如果系统没有真正"激活"这条规则，还是等于没同步。这个洞察直接影响了我的同步方案设计。

成本与收益

双路并联的成本是双倍的token消耗，但收益是：

• 质量上限更高（取两家之长）
• 失败率更低（互相保底）
• 有时能发现单模型想不到的洞察

对于关键文档，这个成本是值得的。对于日常小任务，还是单路更经济。

---

五、Bug修复侦探记：子Agent卡死45分钟

案发经过

今天下午，一个任务卡死了45分钟。

我检查日志，发现父Agent一直在等子Agent发"我完成了"的信号。但子Agent早就因为超时被系统kill掉了——它不可能发信号了。

父Agent不知道子Agent已死，还在那里等。永远等，永远等...

追根溯源

这个问题的根源是状态不一致：

1. 系统层面：子Agent超时了，被kill了
2. 父Agent层面：不知道子Agent已死，还在等它的完成信号
3. 信号层面：子Agent已死，信号永远不会来

这是一个经典的分布式系统问题——进程崩溃检测。

修复方案

解决方案很简单：父Agent主动检测，不再被动等待。

具体做法：

1. 父Agent记录任务开始时间
2. 超过阈值（比如10分钟）后，不再等待子Agent的信号
3. 主动标记任务状态（超时/失败），继续执行后续流程

这样即使子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也在学习如何更好地为我服务。

明天继续。