個人學習記錄 · STAGE 03
這一階段要解決的問題 弄清工作階段樹、長期記憶、壓縮、Token 與提示快取之間的關係。
這一階段只有七篇，卻是整條學習路線的轉折點。建議按時間順序閱讀，先看快取與壓縮，再看工作階段 Tree，最後回到“上下文越小是否越省錢”這次認識修正。
本頁收錄 7 篇原文。正文來自個人 Google Drive 原文庫，已移除 x.com 地址和 t.co 媒體短鏈。原文涉及的版本與產品狀態以釋出日期為準。
2026-08-25 11:29:28 · 小墨同學原文
Pi 還有一個大家容易忽視的點，那就是快取命中率🔥
現在很多人還在比誰Agent更好用，模型更強，我更多時候關心的是，API的話帳單能省多少。
有人用 Pi 接 DeepSeek V4 Flash，跑了接近 10 億 input token，快取命中 99.93%，最後只花了 2.65 美元。按官方說法，如果沒有快取，差不多得 132 美元。
同一模型在別的代理框架（Agent Harness）裡，快取命中常見是 94% 到 97%。到了 Pi Agent，能穩住 99% 以上。差的這幾個點，量一大，錢是指數級拉開的。
原因其實不神秘。Pi 系統提示詞短，預設工具少，請求前能看、能改上下文。快取字首不容易被修改，命中率自然就高了。
更多時候我想說的是，可能AI使用成本才是新手小白學習Agent最大的障礙，畢竟不是所有人都能開通20或者200刀每個月的方案。
希望以後Pi 可以越做越好，畢竟是實打實的幫我省錢👍🏻
2026-08-25 13:58:06 · 小墨同學原文
Pi 為什麼省 Token？其實沒有什麼神奇快取技術🔥
核心就一件事：它對上下文（Context）很剋制。
它的五大殺招：
字首穩定：System Prompt、工具定義、AGENTS.md 等儘量少變化，Prompt Cache 更容易持續命中。
預設內容少：Pi 的 System Prompt 很薄，預設工具也少，所以基礎上下文本身就小。
歷史以追加為主：工作階段通常是在舊上下文後繼續追加新訊息，而不是每輪重新拼 Prompt，更利於複用快取。
按需載入：技能（Skill）等能力只先暴露名稱和描述，需要時再讀取全文，避免一開始把大量無關內容塞進上下文。
長對話再壓縮（Compaction）：只有上下文太長時才壓縮舊歷史；壓縮會暫時破壞快取，但之後又會重新形成穩定字首。
這裡也糾正一下我前面的錯誤，Pi 不一定比其他的Agent快取效率高，但是它透過這些方式最佳化對應的上下文，總體下來消耗的Token會比其他的Agent使用的更少。
整體Token消耗最佳化也非常重要，而不是隻追求一個高快取命中率。
2026-08-25 15:55:06 · 小墨同學原文
Pi 處理上下文壓縮的方式，比我想象中有意思！
先簡單說一下，Pi 原生的上下文壓縮邏輯，其實非常簡單：
上下文快滿了 → 總結舊上下文 → 保留最近訊息 → 繼續工作。
但是社群已經出現了好幾種不同的思路：
- pai-acp：遺忘流派，讓 AI 自己決定忘掉什麼
不再是等上下文滿了再統一壓縮，而是讓 Agent 主動去判斷哪些歷史已經沒價值，然後提前壓掉；需要時還能搜尋甚至恢復。
pi-smart-compact：它會重點保留當前目標、修改過的檔案、錯誤、關鍵決策、未完成事項，更像是一個留給自己的備忘錄。
pi-context：把上下文當成 Git 管，可以主動 checkpoint、檢視 timeline，再選擇性 compact。
Hypa：設計思路是，最好的壓縮，是就是從一開始就不讓垃圾進入上下文，這樣比單純的上下文到達上限之後在壓縮更省token。
pi-press：把壓縮流程前置，上下文接近閾值時就提前生成摘要，真正需要 Compact 時可以直接切換，減少 Agent 因壓縮產生的停頓。
其實看了這麼多外掛程式的設計思路，總結下來就是在合適的實際完成合適的內容選擇，可能一開始就不讓垃圾資料進入上下文是對的。
也有可能是提前就完成壓縮操作，對你來說無感知才是最舒服的，但是需要解決的還是一個最根本的問題，Agent記憶到底是怎麼樣的。
現在還沒有一個蓋棺定論的結論，但是這些啟發和思路都是一直都在的。
2026-08-26 18:52:45 · 小墨同學原文
研究完Pi 長期記憶，結果比我想象的更復雜🔥
Pi 原生更偏向於管理Session和Context，沒有類似Hermes Agent Memory記憶系統，但是社群卻有類似Hermes一樣的記憶實現。
社群現在已經長出好幾種完全不同的方案。
如果你想研究，我會推薦這四個專案：
1、pi-memory 最簡單的檔案記憶。MEMORY.md、Daily Log、Scratchpad，再加語義搜尋。記憶就是真實檔案，能開啟、能改、能備份，不交給一個黑盒系統養著。
2、pi-hermes-memory 這套我比較熟。除了長期 Memory，還有工作階段 Search、失敗記憶、使用者偏好、自動整理和 Procedural 技能。它不只想讓 Pi 記住東西，而是希望 Agent 能從失敗、糾正和工作經歷裡慢慢長經驗。
3、pi-honcho 更像獨立的長期記憶層。使用者記憶和專案記憶分開，習慣和偏好可以跨工作階段、跨專案留著，專案知識又能單獨維護。適合真把 Pi 當長期 Agent 用，而不是隻當 Coding CLI。
4、pi-hindsight 思路比較有意思。不是每句話都往長期 Memory 塞，而是在上下文要被壓縮、工作階段要結束這些節點，把真正值得留下的決策、經驗、坑和專案知識提煉出來再存。
有段時間我自己也一直在研究Agent的長期記憶，而且還針對Hermes的記憶系統做了最佳化和魔改。
最主要不是學會了用什麼，而是在學習過程中受到了很多啟發，研究Pi的這些記憶外掛程式也是一樣的道理。
可能你的Pi Agent你不需要長期記憶，畢竟簡介高效才是Pi的必殺技
2026-08-28 08:05:54 · 小墨同學原文
我把Pi 上下文壓縮，具象成了一款遊戲🔥
學習Pi 不要再乾巴巴的看理論基礎了，可以結合遊戲一起學習
我就把Pi 上下文處理相關的內容做成了一款遊戲，把上下文處理的特點都包含在裡面。
1、隔一段時間會有一個上下文壓縮能量條點選可以清除旁邊的Token
2、接觸對應的Token，上下文就會增加
3、預設上下文是根據時間再增加的，只有預設撿起道具才可以維持上下文不變
這些核心其實就是Pi 對上下文的處理和理解，也是我想把知識具象化的原因
在遊戲中學，邊學邊玩，邊玩邊學🔥
原帖包含圖片或影片，媒體素材待後續整理。
2026-08-28 23:26:45 · 小墨同學原文
Pi 的上下文其實不是一條聊天記錄，而是從工作階段 Tree 裡面臨時構建出來的一條路徑。
最近在研究Pi的原始碼，發現Pi儲存的上下文在Session，只是模型的其中一個視角。
我現在才發現以前對 Agent 上下文的理解還是太簡單了。
1、Pi 儲存的工作階段本身就是一棵樹
Pi 的每條工作階段 Entry 都會記錄自己的 id 和 parentId，所以一次任務並不是只能一直往後聊。
比如你已經嘗試了一套方案，做到一半發現方向不對，可以直接回到前面的某個節點重新開始。之前那條路線不會被刪除，而是繼續保留在工作階段裡面，新的方案則形成另外一個分支。
這裡最有意思的一點是，Pi 儲存的不是最終答案，而是 Agent 完整的工作過程。
2、但是模型每次並不會看到整棵樹
這也是我覺得設計比較巧的地方。
Pi 會根據當前所在的節點，一路往前尋找父節點，最後得到當前這條分支真正有效的歷史，再用這些內容去構建本輪上下文。
所以工作階段和上下文其實不是同一個東西。
工作階段更像完整的歷史資產，而上下文是從這些歷史裡面臨時選擇出來，給模型使用的一份工作記憶。
3、壓縮本質上也沒有修改這些經歷
當上下文越來越長以後，Pi 會把比較早的一部分內容總結成壓縮 Summary，然後繼續保留最近的原始訊息。
但是原來那些 Tool Call、對話、檔案探索並沒有因此從工作階段消失，被壓縮掉的其實不是“記憶”，而只是模型當前檢視這些記憶的方式。
這也是我現在越來越喜歡把工作階段和上下文分開理解的原因。
4、甚至一條失敗的分支，也不一定毫無價值
Pi 在切換工作階段 Tree 分支的時候，還可以對即將離開的路線生成 Branch Summary。
也就是說前面雖然走錯了，但是找到的 Bug、試過的方法、修改過哪些檔案、哪些方案已經證明不可行，這些經驗依然可以被帶到新的路線裡面。
看到這裡我才慢慢意識到，工作階段 Tree 這個設計真正有價值的地方，可能不是讓你可以隨時 /tree 回去。
研究下來，我發現我研究的還是太淺薄了，有一些地方一定要深入到原始碼，或者是配合ai的解析，才能讀懂裡面的內容。
如果只是簡單的知道概念，但是具體的實現不去了解，很難有較深的感悟。推薦大家，如果想深度學習，一定要去拆解原始碼。
原帖包含圖片或影片，媒體素材待後續整理。
2026-09-08 15:23:03 · 小墨同學原文
Pi 有一個很反常識，上下文越小，不一定越省錢
我最近在重新看 Earendil 那篇《提示快取（Prompt Caching） In Agents》，我才看懂了Agent快取沒有那麼簡單。
以前我在使用 Agent 的時候，也會很自然地覺得，上下文越短越好。不使用的工具和結果能刪了就刪了，處理好上下文越少，越省Token。
但 Prompt Cache會讓這個問題變得完全不一樣。
Pi Agent 每一輪請求模型，並不是只傳送你剛輸入的新內容，而是會把 System Prompt、Tools、歷史對話、Tool Call 等內容一起帶上，然後把最新的訊息追加到尾巴上。
但是有一個最重要的點： 需要保持Prefix 穩定，快取才能高效的利用上。
假設一個對話已經積累了十幾萬 Token，其中大部分的對話格上下文都已命中了快取。
但是你的Harness 為了節省Token清除了中間的一些無用內容，或者動態修改了前面的 Tool Definition、System Prompt，表面上看確實省掉了一部分Token消耗。
但是因為 Prefix 發生了變化，後面的幾十萬Token快取可能直接失效，導致後面的上下文都需要重新快取，消耗的Token成本反而更高。
最後你得到的結果，大機率是本末導致。
為了省幾千 Token，重新計算了後面幾萬甚至十幾萬 Token。
完成這一階段後，繼續閱讀第 4 階段 搭建自己的技能與擴充功能（Extension）。
