系列說明 >> 本系列大部分 PR 來自私人或公司專案，部分程式碼、環境設定與實作細節不便公開。
我只能保證文中提到的 PR 與問題皆為真實案例，但會經過必要的匿名化與內容調整。
本系列主要分享問題如何被發現、背後的思考方式，以及解法如何形成，不會深入討論完整實作與部署細節，敬請見諒。
Base Repo： paulsha-hippo
Change Ref： PR #1－feat: repo 骨架（conventions 1.0.12＋tier shareable＋CLI stub＋lib 護欄） → PR #2－feat: #125 Phase 1 code 遷入－memory 31k LOC 平移＋quickstart 面，背景 paulshaclaw Issue #125
Issue： D23～D26 已讓 paulshaclaw/memory 能 Capture、Atomize、Dream、Search、Recall，Agent 也開始真的開啟 Knowledge；但把這套能力裝到第二台電腦時，仍得先帶入 paulshaclaw 的 Config、Path、Hooks、Service 與管理方式。只想採用 Memory 的使用者，無法把它接到自己的 Agent Manager。
Root Cause： paulshaclaw 已收斂成偏管理與操作的 Operator Shell，Memory 卻有自己的 Knowledge Lifecycle、跨 CLI Hook、Background Service 與資料 Root。兩種責任仍綁在同一個 Package／部署入口，使「使用 Memory」等同「先採用 paulshaclaw 的管理方式」，違反無痛、無縫與可組合的使用邊界。
Solution： 先建立 tier: shareable 的 Hippo Repo Skeleton、Package／Version／Import Isolation Guard，再機械平移約 31k LOC、91 個 Test Files、Fixtures 與 Capability Specs。以單一 Path Resolver 收斂 Memory Root，既有資料不搬；最後補齊 hippo CLI、Hooks、Service、Doctor 與 Dream Supervisor，讓 Memory 能獨立安裝，也能接入使用者自己的管理方式。
Evidence： PR #1 為 6 passed、Policy Check 0 Fail、hippo --version 成功；PR #2 第一刀以 872 tests 對帳，Quickstart 面完成後為 885 passed / 1 skipped，Stage 2 Integration 為 [stage2] ok。R-21 Gate 另在遷入 Fixtures 中攔到 3 處個人路徑／廠商樣態。這些證據支持 Hippo 的 Package／Runtime Boundary 已成立；它不證明 Recall 因拆 Repo 變準，也不證明 Agent 更常使用 Memory。
上一篇補完 Consumption Loop 後，帶著提心吊膽的心情，跑看來看看情況。
Session 會被 Capture，Good！！
Dream 會把內容整理成 Knowledge，Greate！！
新的 Task 進來，Agent 也真的會拿到 Shortlist，往下 Read 前面留下的筆記，おめでとう！！
它不一定每次都撈對，但至少不再是只會存、不會拿，Bravo！！
跑了一段時間後，我決定把這套東西從家裡的電腦搬到公司。
這麼好用的東西當然要放在公司每天用啊，
留下工程經驗，再交給上面的 Agent 使用，
這就是 paulshaclaw 上 memory的正確形狀。
先取得 paulshaclaw
處理它原本的 Config 與 Path
安裝三家 Agent Hooks
安排 Dream Service
確認本機 LLM Backend
最後才從裡面叫 memory
老Go看了一眼。
「你要搬的是記憶。」
「你這是連家當都一起搬過去了？」
我先把：
python -m paulshaclaw.memory.cli ...
收成比較像正常工具的入口。
接著整理 Config。
Config 一追，又看到 Path.home() 散在各處。
Path 收到一半，地端 LLM Backend 的環境假設又冒出來。
再往後還有 Hooks、Service、Dream Loop。
小bu看著清單：
「就全部包進 paulshaclaw 的 Installer。」
「第二台只要跑一次，裡面幾層不用管。」
我就照這個方向繼續做。
CLI 收進去。
Config 跟著收。
原本散在各處的 Path，開始集中到同一個安裝入口。
Hooks 與 Service 也一起接上。
清單確實愈來愈完整。
第二台也愈來愈像第一台。
它開始使用我的啟動方式、我的 Service、我的操作入口，連 Dream 怎麼活著都跟著 paulshaclaw 的生命週期走。
Memory 還沒真正裝完，管理方式倒是先複製了一份。
越做我越覺得不對，越接我越覺得這有毛病。
我只是想替第二台加上記憶。
為什麼連它怎麼管理 Agent，都開始照我的環境長？不是應該配點orypd 公司的環境長嗎？
如果第二台本來就在用 paulshaclaw，前面的包裝確實省事。
但如果使用者已經有自己的 Agent Manager、Hook 配置與 Service 呢？
他只想加上 Memory。
結果安裝文件先叫他接受我的管理方式。
老Go看著那台愈裝愈像第一台的機器。
「他要的是記憶。」
「不是被你接管。」
這時我才晃然大誤悟，問題不只是 Installer 還不夠順。
就算把整套流程壓成一條 Command，Memory 仍然只能作為 paulshaclaw 的附屬功能被採用。
所謂無痛，不只是少打幾條 Command。
是不用為了 Memory，先換掉原本的管理方式。
所謂無縫，也不是把所有東西藏進同一支 Installer。
是 Memory 能接進使用者既有的 Agent／Hook／Service，而不是要求整個環境先配合我。
我把 memory 目錄完整攤開來看。
約 31k LOC
占 paulshaclaw 全 Repo 約 88%
跨 Claude / Codex / Copilot
自己的 Tests / Hooks / Service
自己的 Knowledge Data Lifecycle
更關鍵的是，相關 Package 對 paulshaclaw.core／bot 已經沒有直接 Import；少數 tmux 互動也隔在 Protocol 介面後面。
大不代表一定要拆。
但這套東西已經能自己收資料、整理、搜尋、回灌，也能離開 Shell Core 存活。
繼續放在原地，主要只是因為以前就放在這裡。
我要拆的不是一個太大的目錄。
是把 Memory 從一種管理方式裡解開，讓別人的管理方式也接得上。
hippo --version決定拆出來後，我以為第一張 PR 會先搬一批 Memory Code。
Hippo PR #1 卻只交了一個很空的骨架：
package 0.1.0
hippo --version
version tests
lib import isolation
conventions pin
tier: shareable
Memory Runtime 一行都還沒進來。
小bu看完很不服氣。
「六個 Test。」
「這現在到底能用來幹嘛？」
我也覺得有點像替空紙箱做驗收。
但這個空箱先立了兩條規矩。
lib Import Isolation 要求底層 Library 不得反向依賴上層 Runtime。
tier: shareable 則代表 Repo 預期可以分享，個人路徑、廠商名稱與環境殘留必須在進門時就被攔下。
當時紙箱裡還是空的。
規則到底有沒有用，要等真的開始裝東西才知道。
PR #2 開始搬 Tests 與 Fixtures 後，R-21——Shareable Repo 的去識別化檢查——攔到 3 處個人路徑／廠商樣態。
而且都不在主要 Runtime Code。
是在 Fixture。
這種檔案很容易被一句話帶過：
測試資料而已。
小re看著第一輪行為測試：
「Tests 全綠，只證明 Fixture 能把測試跑完。」
「沒有證明它適合跟 Package 一起送出去。」
Fixture 會進 Git、進 Wheel，也會被下一隻 Agent 當成範例。
如果 Shareable Gate 等全部搬完才補，這三個 Finding 很可能就會排進：
之後再清。
PR #1 那六個 Test，這時才第一次不像開工儀式。
新 Repo 還沒裝滿以前，先決定什麼東西根本不准進門。
PR #2 的第一刀是機械平移：
paulshaclaw/memory/**
→ paulsha_hippo/**
Import 全面改寫，91 個 Test Files、Fixtures、12 份 Capability Specs 與 Integration Check 一起搬。
看到舊命名、重複 Helper 與不順眼的目錄，我好幾次想順手整理。
老Go提醒：
「先確認家具都有到。」
「不要搬家搬到一半順便改水電。」
Migration 與 Refactor 如果一起做，Test 紅掉時很難分辨：
是漏搬
是 Import 改錯
還是行為真的被重設計
第一輪先用 872 tests 對帳。
把 init／doctor／install hooks／service 等安裝入口補齊後，再到 885 passed / 1 skipped。
Memory Root 也改由單一 Path Resolver 決定：集中處理新舊環境的資料根目錄順序。
HIPPO_*
→ deprecated PSC_*（附 Warning）
→ config.yaml
→ ~/.agents/memory
Code 搬。
既有 Knowledge Data 不 Copy。
第二台最後要能自己走完：
安裝 hippo
hippo init
安裝 Hooks / Service
Capture Session
產出 Knowledge
把 Brief / Recall 送回 Agent
整條路徑不需要 paulshaclaw 在旁邊當房東。
這時 Hippo 才正式成立：從 paulshaclaw/memory 拆出的獨立 Learning Runtime／Repo。
paulshaclaw 可以使用它。
其他 Agent Manager 也可以。
Memory 負責記得。
管理系統負責怎麼調度。
兩者可以接在一起，不必綁售。
PR #1／#2 能支持：
Shareable／Import Boundary 在 Runtime 搬入前已成立。
約 31k LOC、Tests、Fixtures 與 Capability Specs 已進入獨立 Package。
R-21 能在 Fixture 層攔下去識別化問題。
Memory Root 有單一解析順序，既有 Data 沒有被複製成第二份。
hippo CLI、Hooks 與 Service 能離開 paulshaclaw 安裝與啟動。
它們不能支持：
Repo 一拆，Recall 就會更準，或 Agent 就會更常使用 Memory。
第二台能不帶 paulshaclaw 把 Memory 跑起來，只能證明這次沒有再把管理方式一起綁售。
Memory 被送出去後，Agent 到底有沒有讀、有沒有採用，還是另一筆帳。
下一篇，Memory 有塞給 Agent，等於 Agent 有用嗎？
Have a nice day.
iThome鐵人賽
看影片追技術