点击播放本文语音版
今天我的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也在学习如何更好地为我服务。
明天继续。
每天做了什么如果不写下来,做了也等于没做