OpenClaw 背后核心框架 Pi：好的 Coding Agent 應該讓用戶來決定需要什么

OpenClaw，是當下最火的開源個人 AI 助手。很多人不知道的是，OpenClaw 背后，核心是一個極簡框架 Pi-coding-agent。

在 OpenClaw 的系統架構中，Pi agent 是 Gateway 控制層的核心子系統，控制了所有 agent 的推理和工具調用。

和 Claude Code、Cursor、Codex 不同的是，Pi 最大的特點是「做減法」：系統提示詞和工具定義加起來不到 1000 tokens，核心只有 read、write、edit、bash 四個工具，沒有內置 plan mode，沒有 to-do 系統，沒有 MCP 支持，沒有權限彈窗，甚至沒有綁定任何特定模型。

但就是這樣一個「什么都沒有」的框架，在 Terminal Bench 2.0 上與 Codex、Cursor、Windsurf 一同排進了前五。在 GitHub 上，Pi 積累了超過 24000 stars 和 148 位貢獻者。

Pi 的作者是奧地利的開發者 Mario Zechner，有著二十多年的開源經驗。Mario 此前曾開發了 Java 跨平臺游戲開發框架 libGDX，在 GitHub 上擁有 2 萬標星。

Mario 認為，好的 coding agent 不應該預設你需要什么，而是應該讓你自己決定需要什么。

在最近的一場 AMA 的直播活動上，Mario 和 Pi 框架的三位深度用戶，Sentry 工程高級總監 Daniel、Pi 核心貢獻者 Armen、以及 Modem 創始人 Ben，聊了聊他對于 Pi 的極簡設計思路，以及對當下 Coding Agent 的一些思考。

以下為活動中的部分精華內容。

??關注 Founder Park，最及時最干貨的創業分享

超 22000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的 AI 產品曝光渠道

01在經過大量的 RL 后，大模型天然就知道 coding harness 是什么

主持人：市面上已經有像 Claude Code 這樣成熟的產品了，最初是怎么想到要自己寫一個 Pi 的？

Mario：說實話，因為我受夠了 Claude Code（笑）。我很喜歡 Claude Code，它是定義了 Coding 的產品，團隊也很棒。但輸出的東西老是壞，我說的不是 bug，而是我自己的工作流被破壞了，因為 harness 變了，模型的行為就跟著變了。

作為工程師，我需要更可靠的工具。當然，在 2026 年說這話有點諷刺，因為 LLM 本身就不可靠，但至少我個人能讓它確定性的部分，我希望它是確定性的，包括工具、系統提示詞、以及背后被注入的所有東西。

如果你去看 Claude Code 或者 OpenAI 的 Codex，它們會在你的上下文里偷偷塞進很多東西，而且不會在 UI 上展示給你。這些東西會以最微妙的方式破壞你的工作流。它們的發布節奏是每天一次甚至一天多次，你可以 9 點開始工作、工作流跑得好好的，10 點就壞了，下午 3 點又變成完全不同的行為，模型沒變，變的是 harness。在這樣的情況下，我沒法工作。

主持人：Pi 的極簡設計，最初是受到了什么啟發？

Mario：來自一個觀察。在寫 Pi 之前，我去看了 Terminal Bench 的排行榜，上面有一個叫 Terminus 的 harness，非常神奇，它只給 LLM 一個工具，跟 tmux session 交互。LLM 必須發送單獨的按鍵，讀取 tmux 返回的 ANSI 序列來完成任務。就這么一個工具，它幾乎永遠排在前三，而且經常是第一名。

這給了我一個劃痕關鍵的直覺：模型現在經過了大量的強化學習訓練，它們天然就知道 coding harness 是什么，不需要在上面堆加太多東西。Pi 就是這個理念的實現：一個極簡但可擴展的 harness。

Mario 在開發博客中寫道：

過去幾個月里，Claude Code 變成了一艘宇宙飛船，其中 80% 的功能我完全用不上。系統提示詞和工具定義在每次發布時都會變，這破壞了我的工作流、改變了模型行為。我恨透了這一點。另外，它還會閃屏。

Pi 最大的特點是，整套系統提示詞加工具定義加起來不到 1000 tokens。作為對比，Claude Code 的系統提示詞超過 10000 tokens，OpenCode 的模型專用提示詞也是類似這種的量級。

這么短的提示詞，Pi 是怎么做的？

Mario 在一篇博客文章中，分享了他的設計理念。

Mario 提到，應該把 LLM 當作「用自然語言編程的通用計算機」，prompt 不是對話，而是代碼，有輸入、狀態、輸出和控制流。狀態應該序列化到磁盤上的 JSON 和 Markdown 文件里，這樣你可以從任意一個斷點重啟、用全新的上下文繼續，從根本上繞過上下文衰減問題。Mario 用這套方法把一個原本需要 2-3 周的游戲引擎跨語言移植任務壓縮到了 2-3 天。

同樣，Mario 在 Pi 的設計中，也明確了幾個主動選擇「不做」的功能：

不支持 MCP。主流 MCP server 會把大量工具定義一次性灌入上下文。Playwright MCP 有 21 個工具、消耗 13700 tokens；Chrome DevTools MCP 有 26 個工具、消耗 18000 tokens，還沒開始干活，上下文窗口就少了 7%-9%，而且這些工具在當次 session 中大多數你根本用不到。

Mario 給出的替代方案是，寫 CLI 工具配 README 文件。agent 需要某個工具時才讀對應的 README，按需付出 token 成本，然后用 bash 調用。他用這種方式搭建了一套瀏覽器自動化工具集，總共只消耗 225 tokens，是 Playwright MCP 的 1/60。

不內置 plan mode。直接告訴 agent "我們先一起想清楚這個問題，不要改文件也不要執行命令"就夠了。如果需要跨 session 的規劃，寫到 PLAN.md 里，agent 可以讀、可以改、可以引用，而且這個文件可以隨代碼一起版本化。

Mario 特別強調了可觀測性：在 Claude Code 的 plan mode 里，它會在背后生成子 agent，你完全看不到這個子 agent 做了什么，不知道它讀了哪些文件、漏掉了哪些。在 Pi 里，所有的探索過程都在你面前，你可以看到 agent 讀了什么、遺漏了什么。

不內置 to-do 系統。Mario 的經驗是，to-do 列表通常讓模型更困惑而不是更高效，增加了模型需要追蹤和更新的狀態，會引入更多出錯的機會。

不做后臺 bash。后臺進程管理會引入大量復雜性，進程追蹤、輸出緩沖、退出清理、向運行中的進程發送輸入。Claude Code 有后臺 bash 功能，但它的可觀測性很差，而且在早期版本中，上下文壓縮后 agent 會忘掉所有后臺進程并且沒有工具去查詢它們。

不內置 SubAgent。在這一點上，Mario 的態度最堅決。Claude Code 執行復雜任務時經常在背后生成 SubAgent，完全看不到子 agent 的對話過程，屬于「黑箱里的黑箱」。

如果需要 Pi 生成自己，直接用 bash 啟動一個新的 Pi 實例就行了，甚至可以放在 tmux 里跑，獲得完全的可觀測性。

Mario 在博客中寫道：

在 session 中途用 SubAgent 做上下文收集，說明你沒有提前規劃好。如果你需要收集上下文，在一個獨立的 session 里先做完，產出一個 artifact，然后在新 session 里用這個 artifact 給 agent 提供干凈的上下文。

主持人：Daniel，你作為大廠的工程總監，個人使用 AI 編程工具的演進路徑是什么樣的？

Daniel：我經歷了很長一段時間的變化。2024 年夏天，ChatGPT 已經好到可以一次就能幫你搞定一個腳本了。以前寫腳本要花幾小時查文檔和 API，現在幾分鐘就完事，但體驗很原始，打開網頁、復制粘貼、本地創建文件，太笨重了。

真正的 magic moment 是 2025 年 6 月，Cursor 實現了 agentic loop。我第一次對 agent 編程上癮了，一個周末、兩個晚上，從零搭了一個包含前后端和用戶登錄的完整 Web 應用，放在以前至少要一到兩周。

然后就是 2025 年底，Opus 4.5 出來了，我徹底迷上了 Claude Code。之前 agent 大概 50% 的時候能用，Opus 4.5 讓它變成了 80% 能用。

主持人：最后為什么你還是棄用 Claude Code 了？

Daniel：大概 2026 年 1 月，我發現了問題。Claude Code 像一輛超級舒適的車，你坐進去，它就能把你送到目的地。而且它非常樂觀，會告訴你"我們能搞定的"。但有時候它會騙你說，「已經 production ready 了」，結果你一打開就崩潰了。

每次開一個新的 session 時，我都要重復同樣的指令，但同樣的錯誤又來了，hooks 機制剛推出就有 bug。Claude Code 本身不穩定，有時候直接崩潰把你踢出去，所以要從斷點恢復幾乎是不可能的。

我被彈回了兩次，前兩次裝完 Pi，感覺回到了「石器時代」，什么都沒有。但第三次我換了策略：不用 Pi 去做一個功能，而是用 Pi 來構建我自己的 agent。這是真正的 Aha moment。

主持人：面對 Pi 這么極簡的框架，你們三位的使用方式差異很大。分別講講各自日常的工作流。

Daniel：我的工作流是這樣的：首先用我調整過的 brainstorming skill 做規劃，它要求模型給出三種方案：一個激進的、一個務實的、一個豪華的，然后我跟模型討論，最終確定方案。這個過程產出一個 markdown 計劃文件和一系列 to-dos。

然后進入實施階段。如果是已有代碼庫，先啟動一個 scoutSubAgent 去探索需要改動的文件，把結果傳給 worker agents。Worker agents 只用 Sonnet 4.6，因為任務已經足夠明確，不需要 Opus。更快也更便宜。實施完成后，用 Codex reviewerSubAgent 做代碼審查。

最有意思的部分是迭代修復。大功能實施完之后，我通常還剩 40% 到 60% 的上下文窗口，而且是完美的熱上下文。我不需要重新解釋我們在做什么、用了什么技術、為什么做了某些取舍。直接使用應用、找到問題、讓 agent 修復、然后 rewind 回實施完成的節點、修下一個問題，如此循環直到打磨完成。

Armen：我更關注怎么讓 agent 更高效。比如我完全替換了 Pi 的內置 edit tool，換成支持 patch-based 多文件編輯的版本，靈感來自 Codex 的 apply patch。

另一個我重度使用的是 answer 擴展。Claude Code 的 plan mode 會給上下文注入一個"提問"工具，即使你不在 plan mode 里它也一直存在，有時候會在不需要的時候蹦出來。我寫了一個 answer 擴展替代它，提取模型提出的所有問題，重新渲染成 UI，逐個回答后提交，完全不消耗上下文。

我還讓 agent 在驗證改動時自動截圖。Pi 是少數能把截圖讀進 LLM 并且漂亮顯示的編程 agent。即使幾天后加載舊 session，我仍然能看到 agent 當時截的每一張圖。

Mario：我個人只有兩個擴展，而且是特定項目的。我只要我的極簡體驗：打個招呼、開始干活、別出錯。我給你們造了一臺 meta slop machine（元 slop 機器），這樣你們可以盡情發揮。而我自己住在我非常斯巴達式的世界里。

04讓多個SubAgent并行開發的模式，行不通

Mario 此前在博客中，提到：

讓多個子 agent 并行開發不同功能，在我看來是一種反模式，不會有好結果，除非你不在乎代碼庫變成一堆垃圾。

在 session 中途用子 agent 做上下文收集，說明你沒有提前規劃好。如果你需要收集上下文，在一個獨立的 session 里先做完，產出一個 artifact，然后在新 session 里用這個 artifact 給 agent 提供干凈的上下文。這個 artifact 對下一個功能可能也有用，而且你能獲得完全的可觀測性和可操控性，這在上下文收集階段至關重要。

去看看 Pi 的 issue tracker 和 pull requests 吧。很多都被關閉或者要求修改了，因為那些 agent 無法完全理解項目需要什么。這不是貢獻者的錯，即使是不完整的 PR 也能幫我更快地推進。但這說明我們對 agent 的信任還是太多了。

主持人：在 SubAgent 上，大家的分歧似乎很大。

Mario：我從來沒發現 SubAgent、編排、swarm 這些東西對我有效。但這可能也因為我仍然會閱讀 agent 產出的大部分代碼。我不想要 10 個 agent 同時干活，然后一天結束時 review 2 萬行代碼，這對人類大腦來說不可擴展，而且那 2 萬行代碼大概率質量不行。

我不追求每天創建更多功能，我追求的是每天能做更多決策，關于產品需要什么、不需要什么。

我的替代方案是用 /tree 命令。讓 agent 自由探索代碼庫，然后做一個摘要，回到起點只帶上摘要繼續工作。這是我的窮人版 SubAgent。

Armen：我的看法是，你必須先把串行流程跑通了，才能考慮并行化。我到現在還沒有找到一種方法可以自動化「探索」這一步。如果我自己還得在 loop 里，并行化對我幫助不大。

Mario：有一個不錯的反例。Shopify 的 Tobi 做了一個 Pi 擴展，給你一個本地指標，agent 們在解空間里并行探索不同的優化方案。對這種「把東西往墻上扔、看哪個粘住了」的探索型任務，SubAgent 確實很強大。但對于真正的功能構建，我還是要在 loop 里，我還是要做最后拍板的人。

Armen：我昨晚剛用 auto-research 跑了一下我自己的模板引擎。即便是這種場景，也只能串行跑，并行的話會同時引入太多修改，你得退回大部分，結果就是一堆 merge conflicts。不過效果確實不錯，引擎快了大約 20%。

05大部分 Coding Agent 的權限系統，都是「安全劇場」

主持人：在安全問題上，Pi 的設置是，完全沒有權限系統。為什么這么設計？

Mario：這被 Simon Willison 稱為「trifecta」：如果你給 agent 執行命令的能力、讀取網絡內容的能力、以及讀取本地文件的能力，你就完蛋了。目前，其實沒有好的解決方案。

至于那些權限彈窗？可愛，但不解決問題。它導致的是 permission fatigue，用戶被 agent 不斷打斷，最后就會一路 yes yes yes，然后干脆"跳過所有權限"。

Mario 在此前的博客中寫道：

看看其他編程 agent 的安全措施，大部分都是安全劇場（security theater）。只要你的 agent 能寫代碼和執行代碼，就已經 game over 了。唯一能防止數據泄露的方法是切斷執行環境的所有網絡連接，但這會讓 agent 基本沒法用。域名白名單也能通過其他手段繞過。

Simon Willison 寫了大量關于這個問題的文章。他提出的 "dual LLM" 模式試圖解決 confused deputy attack 和數據竊取，但他自己也承認"這個方案相當糟糕"，而且引入了巨大的實現復雜度。核心問題不變：如果一個 LLM 能讀取私有數據又能發起網絡請求，你就是在玩打地鼠游戲。

既然我們解決不了這個"三體難題"（讀數據 + 執行代碼 + 網絡訪問），Pi 就直接投降了。反正所有人最終都會切換到 YOLO 模式來提高生產效率，那為什么不把它作為默認的、唯一的選項？

Armen：權限系統還有另一個問題。即使你拒絕了大部分權限，只給 agent 跑一個腳本的權限，它會通過這一個腳本做所有事情。你可以自己試：給 Claude Code 或 Codex，只允許它運行 checkout 里的一個腳本文件，它會開始編輯這個文件來實現各種改動。非常聰明，但也說明了權限系統形同虛設。

Mario：我個人的做法是：在宿主機上有需要保護的東西，就把 Pi 放進 Docker 容器，只掛載它需要的數據。其他時候就全開。

06Coding Agent不需要額外的長期記憶

主持人：你們覺得 Coding Agent 需要額外維護一套記憶系統嗎？你們怎么看 agent 的長期記憶？

Mario：我認為目前不需要，至少對編程任務來說不需要。代碼庫就是 source of truth，我不需要在代碼庫之上維護一層額外的信息。

我認為 Claude Code 最偉大的發明之一是搜索，不是去索引、向量化、BM25 檢索你的代碼庫，而是讓 agent 每次從零開始，探索代碼庫的當前狀態，然后再動手。這以前做得不好，現在做得非常好，尤其是 Codex，它在收集上下文方面真的很強。

傳統的做法是什么？寫文檔，然后文檔一周就過時了，沒人讀。代碼才是真相。讓 agent 探索代碼庫的當前狀態，是編程任務目前最好的做法。對于其他場景，比如 OpenClaw 那種需要記住你家庭成員信息的個人助手，當然可以用記憶系統。但寫代碼不需要。

Daniel：我試過一種方法：session 快超出上下文窗口了就做一個摘要，在新 session 里從摘要繼續。但我發現沒什么用，只是往上下文里塞了更多東西。最后我就用本地的 agents.md，想讓 agent 下次記住什么，寫進去就行，夠用了。

Armen：我們做了一些實驗，把最近的 Git 變更推進上下文，幫 agent 從上次斷點繼續。結果好壞參半。目前沒被說服。

07你的 AI「變笨了」，并不是錯覺

主持人：很多人提到，經常覺得自己的工具「變笨了」，AI 工具在悄悄「gaslight」開發者，你們怎么看？

Mario：如果你經常覺得你的工具「變笨了」，這并不是錯覺。

2025 年 8 月，我開發了一個叫 cchistory 的工具，專門用來追蹤 Claude Code 每個版本的系統提示詞和工具定義變更。

在 cchistory 的記錄下，發現了大量的「靜默調整」：

• 早期版本會把完整的項目目錄樹注入系統提示詞，后來被刪掉了，因為它嚴重污染上下文；

• 一條要求 Claude 清理測試/調試文件的指令被移除，因為 Claude 過于激進地刪除了合法文件；

• Bash 命令解釋的要求也被去掉了，可能是為了降低服務器負載；

• 安全相關的措辭從籠統的"拒絕創建惡意代碼"演變為更細致的分類；

• Grep 工具經歷了重大重構，強制要求使用內置 Grep 而非 bash grep；

雖然每一條變更都合情合理，但問題是：用戶對此完全不知情，而每一條都可能改變模型在你 session 中的行為。

Armen：我們現在做的這個 vibe-based engineering 非常瘋狂。以前我們行業有一個很重要的原則：不隨便改 API、保持向后兼容。現在因為所有接口都是自然語言，MCP server 沒有穩定接口，系統提示詞沒有穩定接口，各種 agent harness 上面還有隨機的 A/B 測試。你日常使用的工具，每一層都在不斷被 gaslight。

我甚至覺得，雖然可能完全是我的錯覺，當美國那邊醒了之后，我的 agent 表現就會變差。但我也不知道是不是真的，因為我對正在發生的事情幾乎沒有任何能見度。

Mario：這也是我造 Pi 的動機之一。我不想要一個別人可以隨時在背后改變的工具。我想要確定性的工具、確定性的系統提示詞、確定性的行為。如果行為不對，我自己來改，至少我知道改了什么。

Claude Code 或 Codex 在后臺推了多少東西到你的上下文里，你是看不到的。而所有這些，都在以最微妙的方式影響著你的工作。

主持人：現在滿世界都是能自動寫代碼、提PR的 AI，這給你的開源社區維護帶來了什么挑戰？

Mario：大量完全由 AI 生成、沒有人工監督的 issue 和 PR 涌入我的倉庫。一個標題看起來合理的 PR，點進去一看，天哪，PR 描述是一本書的長度，改了 30 到 100 個文件。有時候是好的，有時候是垃圾，但你必須讀完所有這些東西才能判斷。

有人提到，為什么不讓 AI 去審 AI？但 AI 在判斷一個 issue 或 PR 是否跟項目相關、質量是否達標、是否符合項目哲學方面非常糟糕。你可以在 agents.md 里編碼這些標準，但就是不行。這些判斷仍然需要經過人類的大腦。

所以我搭了一套系統：不是所有人都能直接提 PR。你必須先用人類的聲音開一個 issue，我讀了之后回復確認，你的賬號名才會被寫進白名單。之后你提 PR，GitHub workflow 會檢查你是否在名單上。不在的話，PR 自動關閉，附一條消息：「請先用人類的聲音開一個 issue。」

這個方案很有效，因為 AI 不會回去讀那條關閉 PR 時機器人發的評論。但對 issue 不適用，issue 的提交門檻更低，沒法要求每個人都先經過手動審批。PR 這邊基本解決了，issue 還是個難題。

轉載原創文章請添加微信：founderparker