技术 · 熟练
agent 的笔记，什么时候才配进团队库？
草稿与定稿是两种东西，混在一起就两种都不成立
大多数「给 agent 建记忆」的做法翻在同一个地方：它当场写下的东西，立刻就成了团队的事实。于是知识库里同时躺着三类内容 —— 一条已经被证伪的经验、一条只在某个项目成立的技巧、一条它自己也没验证过的猜测，而下游的 agent 读不出区别。这一页给的是「草稿 → 定稿」的晋升流水线：agent 先在自己的笔记本里写，要进正式知识库必须过一道审议并留下回链；与此同时，按实体单独记事实日志，只追加不覆盖，并定期跑一次巡检专查矛盾、过期与断链。核心判据只有一个：这条笔记是谁批准进来的、它依据什么、什么时候过期。
方法 · 一图看懂
1
先分清两个区：私有笔记本与团队知识库 — agent 当场写下的东西先进自己的笔记本，团队知识库只放已经过审议的条目；两者中间加一条晋升动作，而不是让写入直接落到定稿区
2
晋升要留三样：谁批的、什么时候、回链到草稿 — 定稿条目上挂一条指回原始笔记的链接，这样以后要复核或废止时能找到当时的上下文，而不是只看到一个孤零零的结论
3
按实体单独记事实日志，只追加不覆盖 — 每个实体（一个服务、一个客户、一个模块）一行一个事实，只往后加；定期由一个整理步骤把日志重建为该实体的简介，而不是让 agent 每次重写整段
4
到期与归档交给状态机，不靠人记 — 条目带着有效期，过期自动进归档区；这一步的价值在于「知识库会自己缩小」，否则它只会越堆越厚直到没人读
5
定期巡检只查三样：矛盾、过期、断链 — 不追求「找出所有错误」，只查这三类可机械判定的问题，并把断链明显标出来
原理 · 为什么有效
把 agent 的产出直接当事实存进共享库，问题不在「它写错了」，而在写和信被合并成了一个动作。一旦合并，库里的每一条都变成了同一种东西：看起来都像结论、都无法追溯来源、都不知道还能不能用来。拆开之后，两个区各自的判据才成立 —— 笔记本的标准是「对它自己有用」，知识库的标准是「换个人还成立」；这条判据的差别，正是那一道审议要回答的问题。同理，把「当前状态」与「历史事实」分开存（日志只追加、简介由日志重建），才能既保留证据，又不让 agent 每次都重写一遍全貌。
适用场景
适合有多个 agent 或多个人在同一个知识库上写东西的场景：团队 wiki、项目记忆目录、跨会话的长期上下文。不适合单次任务用完即弃的临时笔记 —— 那类内容本来就不该进共享库，进了才是负担。
自测 · 5 问
团队知识库里能不能查到每条结论「是谁批进来的」？
定稿条目有没有回链到它的草稿，能看到当时的上下文？
事实日志是只追加的，还是会被整体重写？整段重写等于丢掉证据
条目有没有有效期？没有过期的知识库只会一直变大
巡检跑不跑？跑的话，查的是矛盾、过期、断链这三类吗？
怎么上手 · 验证步骤
四步起手：① 划两个目录（私有笔记本 / 团队知识库），agent 的默认写入目标是前者；② 加一道晋升动作（人或另一个 agent 审议通过后，条目被移到定稿区并自动附回链）；③ 给每条定稿加两个字段（批准人 / 复查日期），到期自动移入归档；④ 写一个只做三件事的巡检脚本（查互相矛盾的条目 / 查已过期还在被引用的 / 查指向已删页面的链接），每周跑一次，把结果贴进知识库首页。
用一条真实经历做验收：从团队知识库里随机抽三条结论，逐条回答「它是谁写的、依据什么、现在还算不算数」。三条里有任何一条答不出来，说明晋升动作没留够信息；反过来，如果三条都能答出来，这套流水线就已经在按设计工作了。再补一次反向检查：找一条你已经知道是错的旧结论，看它有没有被自动标出来或归档 —— 没有的话，巡检只跑了形式。