3个Agent协作：一位高级用户如何用7天搭建『自我体检』的个人知识操作系统
一位对多 Agent 协作有深入理解的高级用户搭建了名为『OB三脑OS』的个人知识管理系统，7天内连续活跃，产生20个 Session 和689个事件（82条消息中81条集中在前两天）。他通过 SOUL.md 规则文件为3个 Agent 制定类似『宪法』的协作规则：john 负责策略判断和最终审核，tom 负责执行命令与查询数据，Codex 负责代码实现和技术评审——『事实查询交给 tom，判断和决策交给 john』。
背景
个人系统运维需要全栈能力：内存监控、知识库服务、监控脚本、数据一致性检查，涉及查询、判断、编码多种技能。而多个 Agent 无序叠加还会产生新问题：编辑失败却误报成功、不同 Agent 重复修改同一模块、文件写入不同目录、修复结果缺乏独立复核导致『修完又坏』。
核心痛点
个人系统运维需要全栈能力
单人维护需要在查询、判断、编码多种技术上下文间频繁切换。
多Agent协作缺乏秩序
缺乏任务归属和冲突处理机制时，多个 Agent 同时操作容易重复修改、互相冲突。
问题优先级难以快速判定
系统异常出现时，哪些需要立即修复（P0）、哪些可以延后（P4），单靠经验容易误判。
多入口消息形成信息孤岛
不同 Agent 通过飞书等入口接入时彼此无法看到对方的消息，协作链条断裂，用户需要手动中转信息。
落地过程
第一阶段：制定『宪法』与系统诊断（第1-2天）
SOUL.md 明确每个 Agent 的权限边界：tom 收集内存占用、运行进程、知识库服务状态和监控脚本等实际数据；john 基于收集结果按 P0—P4 划分修复优先级，决定哪些立即处理、哪些延后。规则先行、数据驱动、决策分级——前两天集中的81条消息正是搭建协作框架和启动诊断的投入。
第二阶段：执行修复与代码开发（第2-5天）
Codex 只执行经 john 审核确认的任务：修复知识库服务端口和依赖问题、调整系统监控脚本减少错误提醒、检查并修复知识库与本地文档的数据差异。同时3个 Agent 共同设计飞书 ACP 消息中继方案，打通不同入口 Agent 之间的信息孤岛。
第三阶段：结果审核与收尾（第5-7天）
修复完成后，john 作为审核 Agent 复查修复结果，判断问题是否真正解决；后期用户主要是零散查看和收尾，系统进入相对稳定的运行状态。
工作空间实景
实际效果
系统运维从『单人全栈』变成『三权分立协作』
tom 查数据、john 做判断、Codex 写代码，用户从同时扮演运维、开发和架构师中解放出来，只需监督协作规则和审核关键节点。
问题处理有了明确的优先级和审核机制
P0—P4 分级让系统问题不再『眉毛胡子一把抓』，john 的终审环节让修复结果有独立复核，降低『修完又坏』的概率。
代码修复与决策审核分离，降低误操作风险
Codex 只执行经 john 审核确认的任务，避免 Agent 在没有明确授权的情况下随意修改系统配置。
消息中继打通了多入口信息孤岛
飞书 ACP 消息中继方案让不同入口的 Agent 可以互相感知消息，协作链条从断裂恢复为连贯，用户不再手动中转。
结语
7天、3个角色分明的 Agent、一套『宪法』级协作规则——个人知识操作系统通过『执行—决策—终审』的协作闭环完成了自我体检和修复。这个案例更深的启示在于：当多 Agent 协作进入实际场景，权限边界、任务归属、冲突处理和复核机制，与 Agent 本身的能力同样重要。
