共享知識維護
多個 AI Agent 共用知識衝突？避免覆寫與過期結論
避免多個 AI Agent 覆寫共享知識、採用缺乏證據的主張，或在來源改變後繼續使用過期結論。
文章封包
Workflows
讓多個 coding、研究或營運 Agent 讀寫同一份專案知識的團隊
8 分鐘閱讀
01
不要讓每個 Agent 直接把輸出寫成已接受的共享知識。
02
把原始證據、候選主張與已接受結論分成三個狀態。
03
在接受前辨識過期寫入、審查矛盾，並保留被取代結論的歷史。
01
先說結論：Agent 寫入只是候選主張
多個 AI Agent 共用知識時，不要採用最後寫入者自動勝出的規則。每次寫入先保留來源、寫入者、適用範圍、擷取時間與預期版本；只有重新檢查目前來源並完成審查後，候選主張才能成為已接受的共享知識。
若目標版本已變，就在呼叫 `write_page` 前停止流程並重新讀取；若兩個結論互相矛盾，就保留衝突，不用新文字靜默覆蓋舊歷史。
02
先分清五種失敗
共享檔案、向量庫或記憶服務只能讓 Agent 看到同一批資料，不能自動判斷哪一條是目前正確的知識。先把失敗分類，才能選擇版本檢查、來源重讀或人工審查。
- 覆寫：Agent B 的最後寫入把 Agent A 有證據的內容直接蓋掉。
- 過期：Agent 依照舊版來源產生結論，寫入前來源已經改變。
- 矛盾：兩個主張都看似合理，但內容、範圍或時間互不相容。
- 範圍污染：一個 Agent 的專案、角色或個人資料流入不該共享的空間。
- 假完成：Agent 記錄工作已完成，卻沒有測試、檔案或可重現結果。
03
使用候選、驗證、接受三階段流程
先指定事實或 Page 的權威來源與寫入範圍。Agent 身分本身不是權威；程式、測試、規格與維護中的第一方文件仍優先。
審查時回到原始證據，把主張標記為 supported、contradicted、stale、replaced 或 unresolved。資訊較新不代表一定正確；證據不足時，保留未解狀態。
下列斜線命令只適用於已透過 `/setup` 安裝 Wenlan Codex plugin 的 Codex。其他 Agent 可使用本機 MCP 的 `recall`、`capture`、`distill`、`lint`、`list_pending_revisions`，或本機 CLI 的 `wenlan pages`、`wenlan capture`、`wenlan lint`、`wenlan curate revisions`。
Wenlan Codex plugin：檢查、保存、整理與審查
/pages <共享主題>
/capture <候選主張 + 來源 + 為何重要>
/distill <共享主題>
/lint
/curate04
Wenlan 能做什麼，以及不能做什麼
Wenlan 把 Sources、原子 Memories 與維護型 Pages 分開。明確取代會保留 supersedes 鏈；stale Page 可依目前證據重建；機器要改寫人工擁有的內容時，會先成為可審查修訂。可選的 Reconcile 流程能把受保護衝突排入審查，但預設關閉。
Wenlan 不是 Agent 排程器、分散式鎖服務或自動共識引擎。目前公開的 MCP `write_page` 不接受 `expected_version`，所以這個流程必須在寫入前自行重讀並比較來源與版本，不能宣稱 Wenlan 會原子化拒絕過期的機器 Page 更新。人工擁有的 Page 更新會進入可審查修訂；本機 Page refresh 只支援本機 stdio MCP，語意衝突仍要靠來源與判斷處理。
05
用兩個 Agent 做最小驗收
準備一份來源與兩個互相矛盾的候選結論。讓第一個 Agent 保存有來源的主張，再修改來源或 Page；第二個 Agent 使用舊版本時，寫入前檢查應發現版本已變並停止，或把人工擁有的 Page 更新送進審查，而不是靜默蓋掉新內容。
最後從另一個 Agent 重新查詢，確認它看到已接受狀態、目前來源與未解衝突，並能追查被取代的結論及原因。即使不用 Wenlan，這組驗收也適用於其他共享知識系統。
先測一個互相矛盾的結論
讓兩個 Agent 連接 Wenlan，保存一條有來源的衝突主張，確認審查與歷史在重用前都看得見。
FAQ