2026 年每個人都必須使用的 AI Agent 記憶堆疊（開發者指南）

你的模型和框架已經不再重要。

真正重要的是……

你的個人背景／共享記憶

簡介

我將向你展示如何為你的程式碼 Agent 建立共享記憶……讓下一個工具能夠找到你已經做出的決定。

在 Claude 中的架構討論、在 Codex 中的除錯過程、埋在 Cursor 中的解釋……這些有用的工作成果，在你更換工具、開始新階段，或是一個月後重新回到專案時，仍然應該能夠被取用。

長話短說；如果你不想讀完這 3,845 個字，直接把這個 GitHub 儲存庫給你的 Agent 就好 ➡️ https://github.com/codejunkie99/agentic-stack-desktop

我整個都是用 Kimi K3 在 Codex Harness 中建構的。影片則是用 Kimi K3 搭配 Cua 進行電腦操作來製作和剪輯的。

這是一份給建構者的 Agentic Stack Desktop 指南，從你的第一次匯入開始，到一個 Agent 能夠復原先前的決定、根據當前程式碼進行檢查、做出有範圍的修改，並留下有用的成果的工作流程。

你將會得到：

1. 基礎：當你切換工具時，什麼會保留下來
2. 最快路徑：建立一個你可以判斷的工作區
3. 運作設定：將調查與實作分開
4. 專案練習：將一個重複出現的錯誤跑完整個流程
5. 共享層：將檢索帶入你的其他工具
6. 持久層：什麼值得成為一個教訓
7. 操作規則：簡潔、有範圍、可檢查
8. 自訂建置：圍繞一個實際的痛點來修改工作區
9. 擴展：在上一個循環暴露出的缺口處增加覆蓋
10. 建置表

1. 基礎：當你切換工具時，什麼會保留下來

想像你花了一個下午決定一個功能應該如何運作。你探索了各種方案，發現了一個限制，否決了顯而易見的解決方案，最後找到了一個合適的方案。

實作被提交了。解釋卻留在了對話中。

一週後，另一個 Agent 看著程式碼，提出了你已經否決過的同一個方法。從它可獲得的資訊來看，這甚至可能是個合理的建議。缺失的部分，就是當初讓你做出不同選擇的那場討論。

讓推理過程可以被復原

從這裡開始：讓那場討論可以被復原，然後讓下一個 Agent 在行動之前先檢查它。

Agentic Stack 提供了一個原生的 macOS 工作區，內建來自 Claude Code、Codex、OpenCode 和 Cursor 的可搜尋、精選歷史記錄。Claude Code 和 Codex 也透過它們的官方 CLI 執行；Cursor 和 OpenCode 目前僅提供上下文。儲存庫概覽

下面的工作流程是我會如何使用這些功能。這些簡報、職責劃分和專案練習是建議的操作實踐，你可以根據情況調整。

2. 最快路徑：建立一個你可以判斷的工作區

從一個你了解的儲存庫開始。選擇一個你知道重要檔案在哪裡、記得最近的一個決定，並且能夠辨識出錯誤建議的專案。

一個熟悉的專案能給你一個參考點。 如果你從不熟悉的程式碼和不熟悉的歷史記錄開始，你會同時嘗試驗證工具和學習系統。

對於原始碼建置，文件要求包括 macOS 14+、Python 3.10+、Xcode Command Line Tools 和 Swift 6 工具鏈。安裝並登入你想要執行的程式碼 CLI。需求

1git clone https://github.com/codejunkie99/agentic-stack-desktop.git
2cd agentic-stack-desktop
3./install.sh desktop --build

在應用程式中開啟你的儲存庫並完成引導設定。這是預覽版，使用臨時簽章，因此 macOS 可能在首次啟動時要求確認。設定

設定第一個驗收檢查

在匯入任何東西之前，寫下你希望第一個 Agent 回答的問題。像是：為什麼我們的匯出作業要分批處理記錄，當前的實作是否仍然需要這個限制？

這個問題就成為你的第一個驗收檢查。你在尋找正確的決定、正確的支援程式碼，以及對 Agent 無法確定的任何事項的誠實解釋。

2.1 第一次匯入：給它一個值得尋找的決定

開啟知識圖譜 → 圖譜 → 匯入記憶，預覽來源，然後選擇你想要包含的資料。

圖譜使用 SQLite 全文搜尋，連接基於主題、儲存庫連結和出處；原始的聊天儲存保持不變。匯入行為

我會從一個包含你記得的決定的已完成對話開始。特別是你因為一個從最終程式碼中看不出來的限制而否決了一個有吸引力的方案的那種。

匯入後搜尋那個決定。開啟結果並檢查來源。確保你看到的是你打算匯入的對話，並且有足夠的上下文解釋來理解發生了什麼。

測試你是否能再次找到它

然後，使用你下個月自然會用的詞彙進行第二次搜尋。你可能記得功能名稱，但對話中用的是內部模組名稱。現在發現這個不一致，有助於你了解以後如何檢索這些資料。

我會讓第一個集合保持足夠小，以便手動檢查。從已知來源得到的正確答案，是證明工作流程有效的有用證據。

大量的匯入數量只能告訴你系統中進入了多少資料，而其有用性則有待測試。

當另一個任務給你理由時，再擴展集合。

2.2 第一次工作階段：讓實驗小到可以完成

我會在開啟另一個設定畫面之前，為初始設定設定一個終點線。在階段結束時，你應該已經復原了一個已知的決定，根據儲存庫進行了檢查，並產生了一份你可以向其他人解釋的審查報告。

選擇一個範圍狹窄的例子。檢查單一匯出行為比檢查整個資料平台容易。驗證一個關於元件的早期選擇，比問一個關於架構是否良好的廣泛問題更容易。

在練習旁邊記一個簡短的筆記：問題、預期的來源、當前的實作，以及需要判斷的部分。這是你評估答案的參考。

診斷正確的失敗

• 如果審查者復原了錯誤的對話，那就改進檢索。
• 如果它找到了正確的對話但誤讀了程式碼，那就改進調查。
• 如果發現結果是合理的，但實作沒有達到要求，那就改進交接。

這種區分很重要，因為每種失敗都需要不同的修正。 增加更多記憶不一定能解決不明確的簡報問題，而改寫簡報也無法復原從未被匯入的來源。

完成最小的完整循環，記錄失敗之處，並使用這個證據來選擇下一個改進方向。

3. 運作設定：將調查與實作分開

我建議的第一個設定包含一個唯讀的審查者和一個具有專案編輯權限的實作者。為每個角色設定明確的交付成果，並讓交接內容在你開始任何修改之前就能夠閱讀。

Agent 設定檔支援執行器、模型、努力程度、指令和檔案存取。對話屬於專案，後續對話會恢復其底層的 CLI 階段。對話模型

1. Agent 1：審查者 獲得第一個問題：我們決定了什麼，程式碼現在做了什麼，是否有值得解決的差距？
2. Agent 2：實作者 獲得審查後的答案加上一個有範圍的請求：進行這個行為變更，在這個範圍內，並以這種方式驗證。

保持角色分明

你可以為兩個角色選擇同一個執行器。

有用的區別在於它們的責任和權限，並在調查和編輯之間進行明確的審查。

我會避免在它們中的任何一個完成有用工作之前，就建立一個專家目錄。從你實際上能夠區分的責任開始。如果你無法解釋一個角色負責什麼，或者它的最終產出看起來像什麼，請在增加另一個 Agent 之前先收緊這個角色。

3.1 審查者：讓不確定性顯而易見的簡報

選擇審查者，並使用 @Claude、@Codex、@OpenCode 或 @Cursor 附加相關的對話。選定的參考資料會成為該次執行的凍結上下文，並在任務開始時傳送給所選的 Agent。參考資料

複製這個簡報並填入空白處：

1使用附加的對話和當前的儲存庫，審查關於 [功能或子系統] 的早期決定。
2
3解釋最初的決定及其陳述的理由。檢查相關的程式碼，並識別出哪些仍然適用、哪些已改變、以及哪些無法從現有證據中驗證。
4
5引用支持你結論的檔案。提出為達成 [期望行為] 所需的最小變更，並附上驗證計畫。
6
7不要編輯檔案。將對話視為歷史證據，並標記與當前專案指示衝突的地方。

檢查審查結果

在儲存庫開啟的狀態下閱讀答案。

1. 追蹤一個引用。
2. 檢查 Agent 聲稱仍然存在的條件。
3. 尋找對話中聲稱的內容與當前程式碼所展示的內容之間的明確區隔。

如果答案含糊不清，就縮小問題範圍。要求它識別控制該行為的確切條件，或是使先前的替代方案不適合的依賴關係。

一個有用的調查可以在證據不足的情況下結束。 這告訴你下一步需要提供什麼。一個掩蓋了差距的答案會讓下一個決定更難做。

3.2 交接：將發現轉化為可執行的簡報

一旦你同意審查結果，就圍繞可觀察的行為來撰寫實作請求。包含早期對話所建立的限制，但解釋它與這次變更的相關性。

這是我會使用的簡報：

1使用下面的審查結果，實作 [特定行為]。
2
3保持 [現有行為] 不變。將編輯限制在 [允許的範圍] 內。
4如果變更需要超出該範圍的工作，請在擴展之前解釋原因。
5
6在編輯之前檢查當前的儲存庫指示。使用 [相關測試或手動檢查] 驗證 [預期結果]，包括 [重要的失敗情況]。
7
8回傳一份簡潔的說明，說明更改了什麼、實際運行了哪些檢查、以及任何未解決的限制。不要發布或部署。
9
10審查結果：
11[貼上你檢查過的結果]

讓交接內容具體化

那些括號裡應該要有實際的答案。「讓它更好」會讓 Agent 自己去發明目標。「在保留原始錯誤的同時，顯示帶有重試動作的失敗匯出」則給了你們雙方一個具體可以檢查的東西。

將審查結果保持在接近任務的地方。如果重要的限制埋藏在一個很長的記錄中，請在簡報中明確說明，並附上支援的對話。

來源解釋了限制的由來。你當前的請求解釋了它如何指導今天的工作。

4. 專案練習：將一個重複出現的錯誤跑完整個流程

這裡有一個假設性的練習，讓工作流程更具體。想像你的專案在網路中斷後偶爾會產生重複的匯出，而一個較舊的對話中包含對重試行為的調查。

1. 步驟 1：首先，檢索那個對話。要求審查者識別早期調查確立了什麼，然後根據它檢查當前的重試路徑。
2. 步驟 2：假設舊的討論說，在不確定的回應後可以重複請求。審查者應該確定當前的實作是否仍然允許這樣做，哪個程式碼控制它，以及是否已經有一個旨在防止重複的機制。
3. 步驟 3：如果證據支持變更，則圍繞失敗情況向實作者下達簡報。指定重複請求應該做什麼、哪些現有的匯出行為必須保持不變、以及你將如何驗證中斷的回應。
4. 步驟 4：然後檢查變更並執行相關路徑。同時檢查成功的匯出和不確定性後的重試。如果環境無法重現中斷，請記錄該限制並決定需要進一步的驗證。
5. 步驟 5：最後，審查你可能保留的教訓：導致重複的條件、解決該問題的機制、以及支持修復的證據。

這個例子是一個建議的練習，而不是聲稱 Agentic Stack 中存在錯誤。用你自己專案中的一個真實失敗來替換，並保持相同的順序。

5. 共享層：將檢索帶入你的其他工具

桌面版可以透過工具 → 連線 → 在所有工具中使用 @ → 在所有四個工具中啟用來安裝整合。對應的命令是：

1agentic-stack context install

之後重新啟動工具。MCP 入口點暴露了對話搜尋、選定聊天閱讀和共享記憶搜尋。整合

選擇器行為取決於客戶端；在資源完成不可用的情況下，Agent 可以搜尋並呈現匹配的對話。客戶端行為

測試跨工具的連續性

我的第一個檢查是要求另一個工具找到你剛剛審查過的相同決定。給它主題，要求它呈現匹配的來源，並在要求分析之前確認選擇。

然後將結果與你在桌面版中檢查的來源進行比較。你是在測試跨工具的上下文連續性，所以在改變提問地點的同時，保持問題穩定。

我也會在任何決策對工作產生實質影響時，將來源包含在最終任務簡報中。「我們之前討論過這個」給了 Agent 一個搜尋問題。「使用這個審查過的對話，並驗證這個條件」則給了它一個具體的責任。

6. 持久層：什麼值得成為一個教訓

檢索能讓舊資料重新進入視野。你仍然需要決定這些資料應該具有什麼權威性。

一個對話可能包含一個被放棄的計畫、一個錯誤的診斷、或者在專案改變之前是合理的答案。保留它可以讓你之後檢查推理過程；接受一個教訓則是一個單獨的決定。

任務持有執行記錄。知識 → 教訓支援暫存、接受、拒絕和重新審視帶有理由的教訓，而匯入的歷史記錄與已接受的教訓保持分離。審查生命週期

撰寫一個可以被挑戰的教訓

我會撰寫一個包含足夠細節以便被挑戰的建議教訓：它適用的條件、它建議的行為、理由和證據。

對於假設的匯出錯誤，「總是安全地重試」過於模糊而沒有幫助。一個有用的筆記會識別什麼使重試不確定，以及這個專案的實作應該如何識別重複的工作。

然後問什麼會使這個教訓過時。不同的後端、改變的合約或替換的子系統可能會移除原始的限制。包含那個邊界，以便未來的審查有地方可以開始。

這就是我如何讓一個有用的修正，不會變成一條比它的理由更長壽的規則。

6.1 記憶結構：將每種知識放在適當的位置

在桌面版之下，可攜帶的 .agent/ 架構將工作狀態、先前的案例、持久的模式和個人偏好分開。技能提供可重複使用的程序，而協議則描述權限和委派。架構

• 當前的調查屬於進行中的工作。
• 其完成的記錄成為發生過的事情的證據。
• 一個經過驗證的模式可以成為一個持久的教訓。
• 關於你希望結果如何呈現的偏好，則屬於你的偏好。

保持這些意義清晰，可以使後續的審查更容易。一個臨時的解決方案應該說明何時可以移除它。一個個人寫作偏好不應該意外地成為一個架構規則。

將一個經過驗證的程序轉變為技能

這同樣適用於技能。我會在一個程序足夠有用值得重複，並且足夠具體可以遵循時，建立一個技能。包含它需要的輸入、重要的步驟、預期的輸出以及需要另一個決定的條件。

對於匯出範例，調查可能會產生一個有用的回歸檢查程序。只有在確認這些步驟在你的專案上有效之後，才保存它。一個複製的記錄給了下一個 Agent 一個故事；一個經過審查的程序給了它一個你可以評估的方法。

7. 操作規則：簡潔、有範圍、可檢查

以下是從第一個專案開始，我會圍繞工作流程設定的規則。

1. 規則 1：每個簡報都要指明交付成果。 審查回傳帶有證據的發現。實作回傳帶有檢查的行為變更。教訓提案回傳一個你可以接受或拒絕的主張。
2. 規則 2：權限跟隨工作。 調查從唯讀權限開始；實作獲得同意變更所需的範圍。保持發布、部署和其他重要行動在請求中明確說明。
3. 規則 3：要求實際的驗證。 報告應該說明運行了什麼以及發生了什麼。如果某個檢查無法進行，請讓它可見，而不是悄悄地將缺失的結果視為成功。
4. 規則 4：保持歷史上下文從屬於當前證據和適用的專案指示。 一個檢索到的對話可以解釋一個早期的決定，但仍然可能是過時的。
5. 規則 5：在保留結論之前審查結果。 Agent 對自己工作的解釋，是需要與 diff 和觀察到的行為一起檢查的東西。

這些是我正在描述的設定的操作實踐。根據你的專案進行調整，但保持責任足夠清晰，以便另一個人能夠判斷一個任務是否達到了它的簡報要求。

7.1 審查佇列：讓工作易於接受或退回

我會要求每個實作都以相同的格式完成：

• 更改了什麼，
• 驗證了什麼，
• 仍然不確定什麼，
• 以及它是否提出了一個可重複使用的教訓。

這給了你一個一致的方式來閱讀已完成的工作，而無需每次都重建整個對話。支援細節可以保留，供你需要檢查的部分使用。

當你退回某項工作時，將修正附加到它遺漏的要求上。「這是錯的」會開始另一輪猜測。「重試在這種條件下建立了第二個匯出；保留原始請求身份並重新執行這個檢查」則指出了差距。

決定什麼值得保留下來

在修正通過後，決定它代表一個重複出現的限制，還是該任務的一個細節。前者在有證據支持時保存下來。後者可以留在任務的歷史記錄中。

我會避免將每個審查意見都變成永久記憶。有些修正只用一次就有用。其他的則揭示了應該塑造後續工作的規則。 做出這個區分是維護系統的一部分。

審查結束時有用的問題是：在嘗試類似任務之前，未來的 Agent 應該知道什麼，以及它可以在哪裡驗證這些知識？

7.2 成本紀律：為每次執行設定停止條件

我會在任何可能不斷擴展的任務中包含一個停止條件。對於審查，這可能是一個關於相關行為和未解決問題的書面說明。對於實作，這可能是同意的變更通過了其指定的檢查。

如果 Agent 發現了一個更大的問題，要求在將該工作吸收到當前變更之前，解釋該發現及其與原始任務的關係。

決定這是否屬於當前任務。

比較結果並執行限制

使用你帳戶中實際可用的選項來選擇執行器和模型，然後在你自己的有限範例上對它們進行評判。我會在將一個配置設為預設值之前，比較發現的品質、所需的修正和提供的驗證。

透過保持任務和來源資料穩定來確保實驗公平。如果每次試驗都改變問題、上下文和驗收標準，那麼比較將難以解釋。

並且將任何支出控制放在你的工具或提供者實際執行的地方。 要求 Agent 節省的一句話只是一個偏好；在依賴限制之前，檢查可用的控制項。

8. 自訂建置：圍繞一個實際的痛點來修改工作區

一旦你完成了基本循環，你會更清楚你想從桌面版本身得到什麼。也許一個重複的導航步驟讓你感到困擾，或者一個任務檢視讓某個欄位比需要的更難檢查。

在提出功能之前，先寫下這個痛點。描述你正在嘗試採取的動作、你在哪裡浪費了時間、以及改進後的行為能讓你做什麼。

然後開啟原始碼儲存庫，並給你的 Agent 一個有範圍的變更請求。包含你打算如何在應用程式中檢查結果。

建置並檢查變更

儲存庫記錄了這些開發和打包命令：

1python3 -m pytest -q
2swift build --package-path apps/macos -c release
3python3 scripts/check-desktop-connection.py
4bash scripts/build-macos-app.sh --output ./apps/macos/dist

開發命令

SwiftUI 變更需要重建和重新啟動才能檢查。桌面工作流程

我會測試促使變更的互動，以及一個可能被破壞的鄰近案例。如果你改進了任務過濾，請檢查過濾後的結果、一個空的結果集、以及返回完整列表的路徑。

使用你應用於匯出練習的相同標準：一個具體的之前，一個有範圍的變更，和一個觀察到的之後。

8.1 遠端選項：決定工作應該放在哪裡

在本地工作流程運作之後，你可能希望在持久伺服器上執行。自託管路徑將原生應用程式連接到一個單一擁有者的服務，該服務擁有自己的專案、記憶、任務歷史和 CLI 登入；切換主機不會自動轉移你 Mac 的資料或憑證。託管指南

我會基於具體理由才這麼做，例如將專案及其執行環境保留在你已維護的機器上。在投入部署工作前，先把那個理由寫下來。

按照託管指南進行支援的配置、驗證和驗證步驟。將伺服器視為另一個工作環境，有其自身的狀態可供檢查。

驗證所選的環境

然後在該環境中重複一項熟悉的任務。檢查所選的專案，確認 Agent 可以存取預期的來源，並驗證結果屬於你所選擇的伺服器環境。

使用已知的任務能讓評估轉換過程變得更容易。如果你同時變更主機、專案和工作流程，就更難判斷是哪個變更導致了意外的結果。

本機環境足以學習核心模式。當工作給你理由時，再擴展基礎設施。

9. 擴展規模：在上一個週期暴露缺口的地方增加覆蓋範圍

我會根據在實際任務中遇到的缺失資訊來擴展這個設定。

• 如果審查需要更早的架構討論，就匯入該討論。
• 如果實作反覆需要相同的程序，就開發並驗證一個技能。
• 如果某個決策不斷被重新提出，就撰寫一份範圍明確的課程，並附上支持該決策的證據。

保留一小組你已經知道答案的問題。在變更你的匯入內容或工作流程後使用它們：找出這個決策、解釋這個限制、識別實作它的程式碼，並標記出已不再適用的部分。

當工作證明有必要時再擴展

我只有在某個 Agent 角色的職責從工作中明確顯現時，才會新增它。反覆出現的文件審查可能值得一個專門的簡報。一次性請求則可能完全適合現有的角色。

擴展那些已經證明其價值的部分。 其餘部分保持簡單，以便在出問題時能夠理解。

9.1 維護習慣：當系統變更時重新審視知識

每當子系統的變更足以改變課程的假設時，我就會審查相關的課程。以變更本身作為觸發點：新的依賴項、更換的儲存層、不同的部署環境，或修訂後的產品需求。

詢問哪些現有課程依賴舊的行為，然後在變更的同時檢查這些來源。保留仍然成立的內容，修訂需要更狹窄範圍的內容，並透過可用的審查工作流程淘汰不再適用的內容。

重要的是保留解釋。未來的建構者應該能夠理解為什麼先前的規則存在，以及發生了什麼變化足以取代它。

更新程序並解決衝突

對於技能，在影響其輸入或命令的變更發生後，重新執行該程序。如果某個步驟不再有效，根據觀察到的失敗更新程序，並重複相關檢查。

這能讓維護與專案中的實際事件保持連結。你正在審查最可能已過時的知識，而當前的證據就在你面前。

當某個任務發現相互矛盾的筆記時，將解決該衝突納入審查的一部分。識別哪個陳述適用於當前版本，並留下足夠清晰的結果，以便下一個 Agent 能夠遵循推理過程，而無需重複整個調查。

留下有用的交接資訊

在下一個工作階段之前，留下一份簡短的交接資訊，描述已驗證的結果、未解決的問題，以及另一個 Agent 應優先閱讀的來源。讓它具體針對你實際檢查過的專案狀態。

這能為明天的工作提供一個可追溯的起點，尤其是當你透過不同的工具或在一段時間後返回時，原始的推理過程仍然可用。

10. 建置清單

1. 選擇一個你熟悉的儲存庫和一個你能識別的決策。
2. 建置桌面端，完成設定，並匯入一個包含該決策的已完成對話。
3. 搜尋它，檢查來源，並將其附加到當前程式碼的唯讀審查中。
4. 自行檢查發現，然後簡報一個具有可見接受條件的有限實作。
5. 檢查差異並執行相關驗證，包括促使這項工作的失敗案例。
6. 僅在結果支持時才建立課程，並記錄其範圍和理由。
7. 當你驗證某個程序值得重複時，將其轉變為技能。
8. 嘗試從另一個工具進行相同的檢索，然後在實際任務需要時擴展你的上下文或基礎設施。

從本週的一個決策開始，並在匯入你的整個歷史記錄之前，讓它完成整個週期。

下一個 Agent 應該繼承你的判斷。