三行摘要
• 一位非工程师，在 **4 套执行系统**（Claude Code、Codex、OpenClaw、Hermes）上经营 **20 位 AI 员工**的团队——刚开始不是团队，是噪音。
• 本文记录 3 件真实事故（机器人挂了却亮绿灯、HTTP 200 陷阱、同一网站的人数写成 4 种），以及修好它们的 **5 条协作规则**。
• 结论：AI 代理协作（Agent Orchestration）拼的不是 AI 的聪明程度，而是**结构设计**——分工、闸门、帐本、交接。
这篇文章是谁写的
Bella 是从零编程经验开始的非工程师，现在的职称是 AI Agent Orchestration Architect——AI 自动化设计师、多智能体系统架构师。一句话：*设计让 AI 们真正能一起工作的团队。*文中所有数字都是 2026 年 8 月 12~15 日的实测。
背景——四套系统各跑各的，结果是噪音
我们的 AI 执行系统有 4 套。一开始想「越多越好」，结果是每套都很努力，却彼此不知道对方在做什么：同一篇文章被两个频道重复发布、机器人挂了屏幕却亮绿灯、同一个网站里团队人数被写成 16、17、18、20 四种版本。问 AI「这个团队有几个人」，答案会随资料来源而变——AEO 观点的最糟状态。
4 套系统的分工地图
🖥️ Claude Code——主力大脑。写作、分析、开发等深度工作的本体。188 个技能档（实测）加上文件化记忆，让昨天与今天的工作接力。调度器每天早上叫机器人自己上班。
🔍 Codex——交叉验证伙伴。刻意把别家公司的 AI 放在旁边，同一个问题让两个 AI 都做，结论不同时才由人来看。一个 AI 的「我很确定」不是证据。
🌙 OpenClaw——24 小时驻守舰队（Mac mini）。6 位机器人随时在 Slack 待命，关了电脑也不睡。Instagram 定期发布走 6 道闸门的签核流程。
📈 Hermes——测量线。只做不量等于不知道。专门测量 SEO、AEO、GEO 曝光。
重点不是工具清单，而是边界。没有边界时，每套系统什么都做一点，最后没有人负责。
3 件事故——规则诞生的地方
事故 1 · 机器人挂了，灯却是绿的。电子报连续 5 天没寄出，调度器上却「已登录」。结果代码全是 0x800710E0——笔记本用电池时 Windows 默认拒绝执行调度。学到：不能只确认「登录了没」，要确认「这个设置跑得动吗」。
事故 2 · 已删除的文章，服务器照样回 200。同一篇文章发了两次，帐本记下删了哪一篇——后来发现记反了，因为两个网址都回 HTTP 200。判定标准改成「RSS 清单里有没有」。
事故 3 · 同一个网站，人数有 4 种版本。用手改的数字下次一定再走样。修法：确定唯一正本文件、所有页面从正本读取、加上构建闸门——数字不一致就挡下部署。闸门第一次执行就抓到人眼漏掉的 1 笔违规。
5 条协作规则
1. **指令留在 Slack**——口头的会消失，写下的才能被接手
2. **交接用文件推送**——窗口关了，下一个工作阶段一句「同步」就能接手
3. **状态只记在一本帐**——发布与否看实物（RSS、API），不看日志
4. **事故升级成闸门**——没放进闸门的错，下次一定再犯
5. **确定要买两次**——重要结论让另一套系统反方诘问
实际运作的样子：Mac mini 上 5 位机器人在 Slack 讨论串互相把关 6 道闸门，最近一次挡下图片日期错误、重绘、再验、发布——全程 26 分钟，人类介入 0 次。
诚实的限制——目前还做不到的事
• **Hermes 测量线目前停业中**——公司电脑汰换时撤离了 5,659 个文件，等待重启。今天实际运转的是 3 套。
• **检查工具也会老化**——把正常判成失败的误报每月都有几次，闸门本身也要持续再验证。
• **机器人的回报也不能全信**——出现过抓错原因、事后重构的回报，所以更需要实物验证原则。
结语
协作拼的是设计，不是指挥。从 1 位机器人到 20 位的过程中，改变的不是 AI，是结构。数字总结：执行系统 4 套 · AI 代理 20 位 + 人类 1 位 · 技能档 188 个 · 协作规则 5 条 · 发布闸门 6 道。