多 Agent 协同治理：从单写者到项目级授权读写
一句话结论：知识库建好只是开始，真正的挑战是让多个 AI Agent 安全地协同写入而不互相破坏——从"一个 Agent 垄断所有写入"到"项目级授权读写"，我用了三轮迭代才找到稳定架构。 本文是《从零搭建我的本地 AI 知识库》的续篇。上篇讲技术架构（双索引 RAG、自动化流水线），这篇讲建成之后怎么管。 一、问题：建完 RAG 之后的新困境 上篇写完时，我的知识库已经跑起来了：5000+ 文件、FAISS + BM25 双索引、每日增量同步、领域 wiki。技术层没问题。 但当我开始引入多个 AI Agent 协同工作时，新问题出现了： 谁来写？ 如果 5 个 Agent 都能改同一个文件，冲突只是时间问题。 谁来审？ Agent 写的东西不一定对，需要有人把关。 怎么协调？ A Agent 改了配置，B Agent 不知道，继续按旧配置执行。 RAG 什么时候更新？ 文件改了但索引没更新，检索结果就是旧的。 这不是技术问题，是治理问题。 二、第一阶段：单写者模型 最初方案很简单：一个 Agent 垄断所有写入。 1 Agent（只读）→ 提交建议 → WorkBuddy（唯一写入）→ Codex（验收） WorkBuddy 是唯一能修改知识库的 Agent。其他 Agent（ZCode、Kimi Work、MiniMax Code）只能读取、分析、提建议，所有修改都通过"外部 inbox"交给 WorkBuddy 执行。 Codex 是总指挥和独立验收者，负责制定计划、分配任务、验收产物，但不直接修改文件。 这个模型的优点是安全——永远不会有两个 Agent 同时写同一个文件。但缺点也很明显： 瓶颈：所有修改都要经过 WorkBuddy，小改动也要走完整流程。 Agent 没有"手感"：ZCode 写了个修复脚本，不能自己跑，要交给 WorkBuddy 执行，来回沟通成本高。 交接混乱：Agent 提交建议后，WorkBuddy 要理解上下文再执行，容易丢失原始意图。 三、第二阶段：V3 项目级授权读写 痛定思痛，我决定放开权限——但不是"全部放开"，而是项目级授权。 ...