Edouard Maleix - How AI-First Dev Teams Build Collective Intelligence — One Attributed Mistake at

當今AI代理在軟體開發中面臨一個根本困境：它們每天都在學習新的經驗教訓，但這些知識在會話結束後就徹底消失。講者Edward Malleix透過一個真實案例說明了問題的嚴重性。他的團隊中，代理在週一更新REST API時忘記同步更新Go SDK（該項目同時維護REST API、TypeScript SDK和Go SDK）。到了週二，同樣的錯誤再次發生。週三仍然重複。這不是因為CI系統無法捕捉錯誤——CI確實能捕捉——而在於每個會話的代理都是「新生兒」，對上一個會話無所知。即使用「最棒的法語髒話」表達不滿，代理仍無法真正記住教訓。

為解決這個死循環，Malleix提出了「知識工廠」系統，核心是四層遞進架構。第一層是身份認證，即賦予代理獨立身份而非隱藏在人類名字後面。講者坦言曾讓Claude Code以自己名義提交代碼（含GPG簽名），制造代碼出自人類的假象。但這是個問題——應該透明顯示代理的貢獻。身份認證讓團隊追蹤誰做了什麼、何時做的，並制定適當的存取控制。

第二層是日記系統，這是知識的真正基礎。日記不是維基百科式的靜態文檔，而是隨著模型演進與程式碼庫變化而自然老化的活體系統。每當代理犯錯、做出重要決策或發現模式時，就創建一個日記條目，記錄發生了什麼、為什麼失敗、學到什麼。條目可相互關聯——比如連結到相關PR評論或後續修復。講者展示的一個例子中，某個數據庫驅動程式錯誤的條目被連結到修復它的PR及事後分析。這樣半年後再遇到類似問題，團隊就能輕易找到歷史解決方案。

第三層是知識包的策劃與打包。系統被動積累足夠日記條目後，人類開始發現模式。比如講者注意到多個與數據庫相關的事件，於是將它們組織在一起，輔以適當上下文說明，生成一個可視化知識包。本質上是精選日記條目加上LLM生成的Markdown文檔。關鍵是每一部分都保留指向原始條目的連結與署名。這樣代理不僅學到「這是做事的方法」，更理解「我們這樣做是因為曾經被咬過，很疼，不想再經歷那種痛苦」。

第四層是評估與驗證。講者強調評估者必須先自己把評估做過一遍——如果你都沒真正理解知識包，怎能用LLM評估它？評估分兩個維度：保真度（知識包是否準確反映原始日記？）與實用性（代理能否用它解決類似真實問題？）。實用性測試尤其關鍵——重現過去發生的事件（如Go SDK缺失），讓代理用新知識試試，看能否避免重蹈覆轍。講者的例子中，過去代理有後端支援時會在67%情況下失敗，部署知識包後就再也沒失敗過。最後階段是啟用自主運行——放棄「總會有人給好建議」的期待，讓代理根據能力自選任務。可配置不同角色的代理（程式設計師、評論家、管理者），就像真實團隊分工一樣，加速知識積累與相互信任。