當知識層彼此矛盾：Context Files 與 Memory，以及編譯時的 衝突來源

問題#

兩個 #oq/now 項目指向同一個根本問題——代理程式的知識基底彼此矛盾時，哪一種說法才算數？

1. Agent Context Files — Context files 與有界限的 memory files 意見不一時，應如何互動？Memory 有資訊損失，而且快取更新有延遲；context file 具權威性，但內容固定。哪一方優先，又在什麼情況下？
2. LLM-as-Compiler Knowledge Base — 編譯期間，如何處理不同來源之間的資訊衝突？

共通主軸#

兩個答案都建立在同一項原則上，而語料庫分別從安全性與知識論層面獨立確立了這項原則：主張的效力取決於其通道與來源脈絡，絕不取決於內容是否看似可信，或內容是否新近。 安全性部分是 TMA-NM 分離定理——依據 memory 內容或沿革判定權限，在可證明的意義上並不可靠，因為看似可信的內容可能遭到洗白；權限必須在寫入時綁定來源（Non-Malleable Memory Authority (TMA-NM)）。知識論部分則是方向不穩定結果——相同的遙測資料，在合理的分析選擇下會支持彼此相反的標題，因此不能用表面內容裁決（Review as the Control Point、Pearl 所說的「資料本身非常愚鈍」）。兩個答案都採用同一項推論：歧異本身就是一級訊號——Garry Tan 的衛生守則（「新資訊與舊資訊衝突時要檢查矛盾」；「沒有人整理的大腦，最後會變成搜尋功能很強的垃圾場」），以及此知識庫自身的編譯規則：明確標示矛盾（LLM-as-Compiler Knowledge Base）。

答案一：Context file 與 memory——依歧異類型區分，記錄所有衝突#

控制平面的配置已經指定兩者角色：context files 是政策平面——有版本控制、由人審查、可供檢視，並以確定性方式載入；memory files 則是有界限的回想——「供參考，不具權威性」（Agent Context Files、Agent Control Plane Patterns: Tickets, Loops, Specs, and Memory Files）。衝突處理規則取決於相互矛盾的主張屬於哪一類：

• 政策歧異：一律以 context file 為準。 Context file 是完整性高的通道——由人撰寫或審查、透過 git 管理版本，且只能經由有人核准的差異修改。Memory 由代理程式撰寫，天生會遺失資訊（Hermes 將 MEMORY.md 限制在約 2,200 個字元），而且可透過會受不可信內容影響的路徑寫入——因此「memory 的說法不同」無從分辨究竟是過時資訊，還是遭到投毒；洗白定理指出，光檢查內容無法區分兩者（Non-Malleable Memory Authority (TMA-NM)）。新近程度不能帶來權限。若代理程式讓 memory 項目覆寫 context file 規則，就等於讓完整性較低的通道向上寫入——這正是 Biba 框架所禁止的失效模式。
• 事實歧異：兩者都不優先，以真實狀態為準。 兩個層級都是現實狀態的快取；Code as Source of Truth 指明真正的事實來源是 repo 與即時狀態，因為它們就是透過實際變更而保持最新的產物。若 context file 說建置使用 X，而 memory 記得是 Y，正確做法不是在兩個快取之間仲裁，而是對照即時狀態查證，再修正過期的快取——直接重寫 memory；透過審查通道更新 context file。問題中「具權威性但內容固定」的矛盾到此便化解了：context file 對政策具權威性；對事實而言，它只是更新較慢、審查較嚴格的快取。
• 每項衝突都要記錄，不能默默裁決。 歧異要交由維護迴圈處理——也就是 lint／精簡程序；它是唯一合理的政策平面寫入者（Agent Context Files 的精簡規範；Tan 所說「實際工作就是精簡」的圖書管理員）。任務進行期間的做法是記入偏差紀錄：採取保守解讀繼續進行，並在方便人類檢視的地方記下衝突（Unknowns as the Agentic Bottleneck 的 implementation-notes.md Deviations 區段）。Context 與 memory 之間反覆出現的衝突，代表其中一個檔案需要修改——在工作階段中把它吞下不提，保證同樣的問題會再次發生。

規則中還有一項不對稱性：memory 絕不可修改 context file，但 context file 可以正當地約束 memory——例如保留規則、可持久保存的內容，以及大小上限。寫入路徑只能順著完整性層級由高往低流動，這正是 TMA-NM 證明必要的寫入時來源綁定原則，應用到檔案層的結果。

答案二：編譯時的衝突——知識庫已在實行的五步驟流程#

知識庫的做法明確化後，可由三個已整理的矛盾案例作為依據：

1. 先對齊構念，再判定衝突。 許多表面矛盾其實不可比較。實例：Faros 與 CMU 在審查中看似「相反」的發現，實際比較的是數量差異與占比水準、企業與開放原始碼、橫斷面與日曆趨勢，以及不同的作者身分單位——「資料集從未互相矛盾，只有論述框架不同」（The Under-Review Divergence: Faros's Widening Crisis vs. CMU's Convergence）。未對齊指標、母體、時間軸與單位就宣告衝突，只會憑空製造不存在的矛盾。
2. 為每項主張附上來源脈絡與證據層級；依方法和誘因衡量，絕不取平均。 知識庫採用 empirical > vendor-claim > practitioner-opinion 的層級，並在旁註明誘因（「Faros 銷售這個平台……結論剛好有利於廠商的產品」——Telemetry vs. Survey Measurement）。Tan 所說「每項事實都要有來源脈絡」也是同一條規則；TMA-NM 則提供了這條規則在對抗情境下的證明（LLM-as-Compiler Knowledge Base、Non-Malleable Memory Authority (TMA-NM)）。
3. 在每個受影響頁面明確呈現真正的衝突，並建立雙向連結。 在兩個頁面都設置具名的張力段落，並互相連結——Faros 與 CMU 的矛盾同時記載於Review as the Control Point及 Faros 相關頁面；Ng 與 Fung 的歧異則「保持可見，而非取平均消除」。默默選邊，就是編譯時的洗白：它抹去歧異的來源脈絡，讓後續查詢拿到一個自信卻看不見異議的答案。
4. 將已呈現的衝突轉成受追蹤的開放問題。 若現有來源無法解決矛盾，就建立 #oq 項目，並說明解決條件（「值得持續追蹤未來的 DORA 版本」）——開放問題的生命週期，會把歧異轉成查詢／研究工作清單，而不是永久擱置。
5. 在編譯／lint 時解決，而非在查詢時處理。 新資訊與舊資訊衝突時，便執行矛盾檢查（Tan 的圖書管理員；此知識庫的 lint 程序）。查詢會繼承已呈現的衝突——可以在權重清楚可見的前提下綜合分析（例如遙測與調查的分析），但每次查詢都重新裁決，會重新引入逐次推導；消除這種重複推導正是編譯式儲存架構的目的（LLM-as-Compiler Knowledge Base 所說的「探索總是會累積」）。

這套流程的效益展現在知識庫自身的歷程中：被標示而非抹平的矛盾（ATLAS↔AEI、Faros↔DORA、Ng↔Fung），後來正是靠新的工具與綜合分析得到解決，因為歧異的結構——誰主張什麼、採用何種方法、帶有何種誘因——獲得保留，而不是被平均成一團模糊資訊。

整合結論#

兩個問題都在問「哪一方優先？」；語料庫給出的答案是，「勝出」不是正確的處理方式。 對代理程式運作中的知識基底而言，權限依通道而定（政策 → context file；事實 → 真實狀態），衝突則向上回報。對編譯後的知識庫而言，衝突會先對齊、衡量、呈現、追蹤，並只在新證據出現時由維護迴圈解決。兩種情況下的失效模式都是默默選邊——在任務或編譯進行中挑出一個看似可信的內容當贏家；禁止這麼做的理由也相同：可信外觀可以被洗白，來源脈絡則不能。