GitHub 上有人開了一個 PR，解了我每次新增 agent 都要手動維護 allowlist 的問題，看到的當下整個人鬆了一口氣。

我家 NAS 上面跑了一個 OpenClaw gateway，Telegram group 裡面開了好幾個 topic，每個 topic 對應一個不同任務的 agent，有負責股票監控的、有負責早報整理的、有負責 smart home 通知的。Active Memory 是我很依賴的功能，因為我希望每個 agent 都能記得之前的對話脈絡，不用每次都重頭解釋。

問題是，只要我新增一個 agent，我就得去 config 裡面找到 plugins.entries.active-memory.config.agents，然後手動把新 agent 的名字加進去。有幾次忘記加，新 agent 跑起來之後怎麼問它都像失憶一樣，搞了半天才發現是 allowlist 沒更新。

這個維護方式說穿了就很像在修水管，每次裝了新的出水口，你還得跑去總閘那邊說「對對對，這個管子也要通」。忘記通一次就卡住，煩。

這個 PR 做的事情很單純：如果你省略 config.agents 不填，或者填成空陣列，以前的行為是 normalize 成 []，結果 Active Memory 直接對所有 agent 都失效。修完之後，空的就代表「套用到全部已配置的 agents」，只有你明確填了 non-empty allowlist，才會限定那幾個名字。

我的 use case 完全是 default-all 那種，根本不需要精細控制誰能用 memory，就是希望所有 agent 都有記憶就對了。以前反而要把每個 agent 名字手動列出來，等於多做了一件沒必要做的事。

作者還說他在 Linux host 上實際驗證過，把硬編碼的 allowlist 拿掉之後 gateway 還是好好的，openclaw memory search 回傳結果正常，之後新增 agent 也不用再手動同步名單。這個我信，因為「拿掉一個設定之後反而壞掉」是我最怕的情境，他有跑 regression coverage 這點蠻reassuring 的。

說到 regression，他補了四個測試案例：default-all normalization、empty-list normalization、explicit allowlist、還有真實 command/hook path 跑到 secondary agent 的那條路。這種覆蓋方式我蠻喜歡的，不只是 unit test 確認 config parse 邏輯，還驗了實際執行路徑。

這種改動的影響面其實不小，因為之前「有填 agents 的」行為不變，沒填的才會改變。如果你以前是用空陣列想要「停用 Active Memory」，升級之後行為會反過來。這點要注意，不過我猜大部分人空陣列都是無意間造成的，並不是刻意要停用。

我的 config 現在打算這樣改：直接把 config.agents 那行整個刪掉，讓它走 default。以後新增 agent 就真的只要加 agent 定義本身，memory 設定這邊完全不用動。感覺像是有人終於把水管的設計從「每個出水口要手動登記」改成「接上去就通」。

如果你有跑 multi-agent setup 而且沒有特別需要限制哪些 agent 用 memory，這個 PR merge 之後可以考慮清理一下 config，刪掉那個 allowlist，讓 default 行為幫你維護。🔧