寫了 17 年開源代碼，我為什么認為 Coding Agents 堆功能是在瞎折騰？

編譯 | 宇琪

策劃 | Tina

在 AI 編程工具進入大亂斗時代的今天，我們似乎已經習慣了各種功能的堆疊。但在 libGDX 創始人、17 年開源老兵 Mario Zechner 眼中，這一切正變得越來越不可控。

“當你發現 AI 在背地里偷偷修改你的上下文，而你卻對此一無所知時，這種掌控感的喪失是極其危險的。”

近日，在 Tessel 舉辦的開發者大會上，Mario 不僅公開吐槽了 Claude Code、OpenCode，更帶出了他的極簡主義“反叛之作”——pi。這是一個只有 read、write、edit、bash 四種工具，擁有主流 agent 里最短的 system prompt，卻有著極致的可擴展性、能讓開發者重拾掌控權的終端編程 agent。

本文基于該演講視頻整理，經 InfoQ 編輯。

核心觀點如下：

• Claude Code 現在就是一架宇宙飛船，它功能多到你可能只用過其中的 5%，了解的也就 10%，剩下 90% 全是 AI 和 agents 領域的“暗物質”，沒人知道它背地里到底在干嘛。

• 現有的編程框架里，很多功能可能并不是獲得好結果的必需品。不需要文件工具，不需要子 agent，不需要聯網搜素，啥都不需要。

• 我們現在正處于“一邊瞎折騰一邊看結果”的階段，沒人知道完美的編程 agent 到底該長啥樣。我們需要更好的“折騰”方式，編程 agent 必須是可自修改、可塑性極強的，這樣我們才能快速實驗新想法，看看能不能折騰出某種新的行業標準或 workflow。

• 真正需要 linting 和類型檢查的時機只有一個：那就是 agent 覺得自己徹底完活兒的時候。

1ChatGPT→Copilot→Aider→Claude Code

2025 年 4 月左右，Peter Steinberger（OpenClaw 創始人）跑來跟我還有 Armin Ronacher（Sentry 聯合創始人、Flask Web 框架創建者）說：“現在的 Coding Agents 真的進化到能干活的程度了。” 我當時的第一反應是：“噢，快給我閉嘴吧！”我是真不信這玩意兒。但一個月后，我們幾個就在公寓里閉關了 24 小時，整夜沉浸在這些 clankers、wipe coat 和 wipe slop 的世界里。

我們不停地造東西，造了一大堆，但絕大多數我們自己從來沒用過。這就是 2025 到 2026 年的新常態：我們寫了很多代碼，造了很多輪子，但真正用上的沒幾個。折騰到最后我開始想，我討厭現有的所有 Coding Agents 或開發框架，自己寫一個到底能有多難？當時 Peter 說：“我只想做一個屬于自己的小玩意兒�！焙髞淼墓适麓蠹铱赡芏贾懒恕�

今天，我要講的是我那個沒那么驚天動地的故事，但我希望能在其中分享一些我在過去幾個月里攢下的行業洞察。

先聊聊 Coding Agents 的演進史。

2025 年之前的情況基本就是：從 ChatGPT 搬運代碼，但代碼大多是碎的，通常只能寫一些你不想親自動手的簡單函數。然后有了集成在 Visual Studio Code 里的 GitHub Copilot，只需要一路 tap tap tap，雖然有時候靈，大多數時候并不。甚至有時候，它還會非�！百N心”地給你默寫一段 GPL 協議的代碼，比如 John Carmack 的那個平方根倒數速算法之類的。后來又有了 Aider，當時還有 AutoGPT。

最后，Claude Code 登場了。我記得他們在 2024 年 11 月發布了 beta 版，但真正火起來是在 2025 年 2 月或 3 月的樣子。當時我覺得這玩意兒簡直太棒了，Claude 團隊非常出色，他們在社交媒體上很活躍，人也都很天才。

說實話，他們基本上開創了整個品類。雖然之前有 Aider 和 AutoGPT 鋪路，但沒有一個能達到這種高度。這就是所謂的 agentic search（智能體搜索）范式：它不像 Cursor 那樣先進入你的 codebase 做索引、搞各種復雜的構建（雖然那樣搞也未必好使）。Claude 團隊直接通過強化訓練，讓模型學會使用文件工具和 bash 工具，通過這種方式實時探索你的 codebase，尋找理解代碼所需的信息并直接修改。這效果簡直驚人，我們直接不睡覺了，因為產出的代碼量比以前純手寫翻了不知道多少倍。

那時候它簡單、可預測，完美契合我的 workflow。但后來，他們掉進了一個我們很多人都會掉進去的陷阱：既然這些 clankers 能寫這么多代碼，為什么不讓它把所有能想到的 feature 都寫了呢？這主意聽起來不錯吧？咱們加這個功能，加那個功能，加加加……最后搞出了一個類似 Homer Simpson 設計的那種怪物。Claude Code 現在就是一架宇宙飛船，它功能多到你可能只用過其中的 5%，了解的也就 10%，剩下 90% 全是 AI 和 agents 領域的“暗物質”，沒人知道它背地里到底在干嘛。

2Claude Code 不是一個穩定的好工具

我個人覺得這并沒什么用，因為我始終認為開發者需要知道 agent 到底在做什么。我們現在在 Tessel 的活動現場，他們也喜歡搞 context management/engineering。但我最終發現，Claude Code 在可觀測性和上下文管理方面并不是一個好工具。而且，誰受得了 Claude Code 的那種沒完沒了的、莫名其妙的閃爍？

Anthropic 的開發者關系專家 Thariq Shihipar 有時候會在 Twitter 上說些讓人摸不著頭腦的話，比如：“我們的 terminal user interface 現在是一個游戲引擎了�！�

我是做游戲開發出身的，那是我的老本行。當我看到這種話時，心真的會滴血。那只是個終端界面，你之所以覺得它是游戲引擎，是因為你在終端界面里用了 React，結果導致重新渲染整個 UI 樹要花掉 12 毫秒。別這么干好嗎？它真不是游戲引擎。

后來寫 Ghostty 的 Mitchell 也忍不住了，他說：“這聽起來有點冒犯。別把鍋甩給 Ghostty 或者其他終端，純粹是因為你的代碼太爛了。”終端渲染一幀只需要不到 1 毫秒，每秒能跑幾百幀，所以別拿這個當借口。

雖然后來他們修好了閃爍，但別的問題接踵而至。你會感覺到他們徹底倒向了所謂的 vibe coding，這種感覺在你每天使用 Claude Code 時尤為明顯。我并不是要貶低他們的努力和成果，Claude Code 依然是這個品類的領頭羊，他們開創了這一切且做得非常棒。我只是個喜歡簡單、可預測工具的老頭子，而它已經不再契合我的 workflow 和需求了。

而且，他們在后臺偷偷對你的 context 做了很多手腳。2025 年夏天，我寫了一堆工具去攔截 Claude Code 發往后端的請求，想看看他們在背地里往我的 context 里塞了哪些額外的文字。結果發現這些操作非常多余，而且每天都在變�？赡芙裉彀l個版本，明天又發個版本，注入內容的時機和方式變來變去，這會直接搞亂你現有的 workflow。它不是一個穩定的工具。

我理解他們的立場，他們需要實驗，而且用戶基數巨大，在龐大用戶群的基礎上做實驗確實很難。但他們并不在意用戶的感受，所以我們都得跟著受罪：你正用著這個新工具，努力構建可預測的 workflow，然后工具廠商在引擎蓋下改了個不起眼的小細節，就導致 LLM 在處理你現有任務時直接發瘋。這根本沒法持續，我需要掌控感，我不能指望他們給我提供一個所謂的“穩定環境”。

作為 UI 設計的代價，他們不得不降低可觀測性。我個人不喜歡這樣，但這只是個人偏好，我知道大多數人對于 Claude Code 展示的信息量已經很滿意了。另外，它顯然沒有模型選擇權，因為它是 Anthropic 的原生工具。這不算壞處，但它幾乎沒有任何擴展性。雖然他們有一套 hook 系統，但如果你對比一下 pi 能實現的功能，你會發現他們的集成度并不深。而且它基本是基于在 hook 事件觸發時運行一個進程，如果你需要反復啟動那個進程，開銷真的非常昂貴。

后來，我徹底對 Claude Code 下頭了。倒不是說它做得爛，只是它不再適合我了。在那段時間里，它變得適合更多的大眾用戶，這說明他們路子走對了，只是不適合我這種老古董。

3OpenCode 的底層設計讓我失去信心

于是我開始到處找替代方案。首先是 Codex CLI，剛開始我挺不喜歡它的，無論是界面還是模型，不過現在它的模型表現確實挺驚艷的。接著是 AMP，這個團隊的核心成員以前在 Sourcegraph 工作，后來出來單干了，都是極其頂尖的工程師。他們居然做出了一款非常商業化的 coding harness，而且是靠“砍功能”而不是“堆功能”來贏得市場，他們的很多設計邏輯跟我簡直不謀而合。如果你想要個商業化的編程框架，我絕對推薦 AMP。Factory 也是類似的思路，做得很扎實，只是沒像 AMP 那么激進和富有實驗精神。

然后就是 OpenCode 了，很多人都在用的開源框架。我這人有開源情懷，在開源圈摸爬滾打了 17 年，大大小小的項目都管過，開源對我來說意義非凡。所以我當時想，既然 OpenCode 離我這么近，那就試試吧。而且說實話，除了 AMP，OpenCode 的團隊是這個圈子里最接地氣、最務實的，他們不會整天拿那些你八輩子用不上的功能來忽悠你，而是努力維持一個非常穩定的核心體驗。他們對“編程 agent 對我們職業意味著什么”的思考，我也非常認同。

但 OpenCode 的問題在于：它在上下文管理上做得一塌糊涂。比如，它每一輪對話都會調用一個叫 SessionCompaction.prune 的函數，把最后 4 萬個 token 之前的記錄全給刪了。大家應該都知道 prompt caching（提示詞緩存）吧？它這么干意味著把你的 cache 全毀了。

OpenCode 和 Anthropic 之間有一段挺有意思的過節。在我看來，Anthropic 后來的態度邏輯很通順：“你們不能這么搞�！彪m然這事兒沒公開鬧大，但道理很簡單：如果你去健身房卻不守規矩，濫用人家的基礎設施，你肯定會被拉黑。雖然我沒證據，但我猜這就是為什么 Anthropic 和 OpenCode 之間關系緊張的原因。我完全站在 Anthropic 這邊，別去糟蹋人家的基礎設施。

還有些別的坑，比如 OpenCode 自帶了 LSP（語言服務器協議）支持。假設你給 agent 下了個任務，讓它改一堆文件。實際操作中它會怎么干？它會一個接一個地改。你覺得它改完第一輪，代碼能編譯通過的概率有多大？當你一行一行改代碼時，得花多久才能讓它重新回到編譯通過的狀態？答案是根本回不去�？赡芨耐甑谝惶�、第二處，代碼還是崩的。

這時候如果你跑去問 LSP 服務：“嘿，我剛改了這一行，代碼崩了嗎？”LSP 肯定會說：“是的，徹底崩了。”然后這個功能就會把報錯信息直接塞進 tool call 后面，反饋給模型：“你剛才干錯了�！蹦Ｐ鸵荒樸卤疲骸案闶裁�？我還沒改完呢！你現在跟我說這個？”這種事發生得多了，模型最后就會直接罷工，導致產出的結果非常糟糕。所以我特別反感在 agent 工作時掛 LSP。真正需要 linting（代碼檢查）和類型檢查的時機只有一個：那就是 agent 覺得自己徹底完活兒的時候。

而且 OpenCode 最近有個變化：在一個 session 里，每一條消息居然都會被保存為一個獨立的 JSON 文件。這在我看來，說明它在整個架構設計上缺乏深度思考。一旦我對這種底層設計失去信心，我就不想再用這個工具了。

此外，OpenCode 默認帶了一個 server 架構，客戶端連接到服務端，終端界面只是其中一個客戶端。這原本挺高端，結果卻爆出了一個默認自帶的遠程代碼執行（RCE）安全漏洞。如果你對自己的服務器架構那么自豪，我默認你應該是一群成熟的工程師，至少考慮過安全性吧？但顯然他們沒考慮，而且這個洞開了很久。我也不是要指責誰，在現在這種前所未有的、快到讓人頸椎骨折的行業節奏下，出錯難免，但我是不想用這種存在隱患的工具。

這就是我對現有 coding harnesses 的觀察。AMP 其實不錯，但我沒有掌控權，它甚至會決定你用哪個模型處理哪類任務，這不符合我的性格。

后來因為一些別的原因，我開始研究 Benchmark（基準測試），結果發現了 TerminalBench。簡單來說，它是一個專門針對 agent 的評估 harness，包含了大量和計算機操作、編程相關的任務。它有大約 82 個非常多樣化的任務，從“修好我的 Windows 設置”到“幫我寫一個蒙特卡洛模擬”。它有個排行榜，上面列出了各種 agent 框架和模型的組合。

其中有一個叫 Terminus 的 agent 讓我覺得非常驚艷，它是排行榜上表現最好的框架之一。它是怎么做的呢？模型拿到的只有一個 tmux session，它唯一能做的就是發送按鍵，然后讀取返回的 VT 序列碼。這是模型和電腦之間最極簡、最原始的接口了。然而，它的表現卻是頂級的。

這說明了什么？我們真的需要那些花里胡哨的功能來讓模型干活嗎？

對我個人而言，這不只是模型好不好的問題，還有作為用戶的“人”該如何與 agent 交互。Terminus 的用戶體驗或開發者體驗顯然不是我想要的，但它證明了一點：現有的編程框架里，很多功能可能并不是獲得好結果的必需品。不需要文件工具，不需要子 agent，不需要聯網搜素，啥都不需要。

基于這些發現，我總結了兩個核心論點：第一，我們現在正處于“一邊瞎折騰一邊看結果”的階段，沒人知道完美的編程 agent 到底該長啥樣。大家都在嘗試，有人走極簡路線，有人走“宇宙飛船”路線，搞什么 agent 集群、完全自治。我覺得這事兒還沒定論，行業標準還沒出現。

第二，我們需要更好的“折騰”方式，編程 agent 必須是可自修改、可塑性極強的，這樣我們才能快速實驗新想法，看看能不能折騰出某種新的行業標準或 workflow。

所以我的基本思路非常簡單：剝離掉一切冗余，構建一個極簡且可擴展的核心，再稍微加點讓人用著舒服的小功能。它不是一張純粹的白紙，但也絕對不臃腫。

4Pi：讓 Coding Agent 適應你的需求

pi 的核心理念很簡單：讓你的 Coding Agent 去適應你的需求，而不是反過來。

整個系統只由四個 package 組成。首先是 AI package，本質上是對多種 provider 的一個輕量抽象層。因為不同 provider 使用不同的 transport protocol，這一層幫你把復雜性都抹平了。你可以在同一個 context 或 session 里非常輕松地和不同 provider 對話、隨時切換。接下來是 agent core，一個通用的 agent loop，包含 tooling、定位、驗證等等基礎能力。然后是 TUI，大概只有 600 行代碼，但出奇地好用，可能因為不是某個 clanker 寫的。最后是 Coding Agent 本身，它既可以作為一個 SDK，在 headless 模式下使用，也可以作為一個完整的終端交互式 Coding Agent。

系統 prompt 就這么多，全部都在這了。和其他 coding harness 那種動輒一大堆 token 的 system prompt 相比，這里幾乎是“空”的。原因其實很直白：frontier models 已經通過大量 RL 訓練，早就“知道”什么是 Coding Agent 了。所以反復告訴它“你是一個 Coding Agent”“你應該怎么寫代碼”？其實沒有必要。

默認就是 YOLO 模式（默認直接執行，不向用戶確認，全自動跑到底）�，F在大多數 Coding Agent harness 基本分兩種模式：要么 agent 想干嘛就干嘛，要么每一步都要問你：“你確定要刪這個文件嗎？”“你確定要列出這個目錄嗎？”……看似安全，但現實是，這種機制只會帶來疲勞。用戶要么直接關掉這些確認，開啟 YOLO 模式，要么就無腦按回車，根本不會看提示。所以這并不是一個真正有效的解決方案。

至于 containerization（容器化），如果你擔心數據泄露或提示詞注入，它也不是萬能解。但相比那些確認對話框式的“guardrail（護欄）”，它至少是一個更合理的基礎。

pi 只提供四個工具：read、write、edit，以及 bash。沒有 MCP，沒有 sub-agents，沒有 plan mode，沒有 background bash，也沒有內置的 to-do 系統。但重點在于，你完全可以用更簡單、更透明的方式自己實現這些。

沒有 MCP？可以用 CLI tools 加上 skills，或者直接寫一個 extension，一天之內就能搞定。沒有 sub-agents？因為它們不可觀察。你可以用 tmux 去 spawn agent，這樣所有輸入輸出都在你掌控之中，每一步發生了什么都一清二楚�，F在 Claude Code 的 team mode，本質上也在做類似的事情。

沒有 plan mode？那就寫一個 plan.md 文件。它是一個持久化的 artifact，比那些塞不進 terminal viewport 的“蹩腳 UI”實用多了，而且還能跨 session 復用。沒有 background bash？tmux 已經幫你解決了。沒有內置 to-dos？寫一個 todo.md 就行。

當然，你也可以選擇把這些全部按自己的方式重新實現，這正是 pi 的價值所在：極致的可擴展性。你可以擴展工具，給 LLM 提供你自己定義的能力。目前幾乎沒有其他 Coding Agent harness 支持這一點，除非你去 fork OpenCode。但在 pi 里，你只需要寫一個簡單的 TypeScript 文件，它就會自動加載。

你還可以寫自定義 UI、skills、prompt templates、themes，然后打包發布到 npm 或 git，通過一條命令安裝。更關鍵的是，所有東西都支持 hot reload。我平時會在項目內部開發一些 task-specific 的 extension，當 agent 修改這些 extension 后，我只需要 reload，一切就即時生效，整個運行中的系統會立刻更新，體驗非常順滑。

這在實踐中意味著很多事情都可以自己動手做。比如 custom compaction，這是我覺得大家應該多嘗試的方向，現在所有的 compaction 實現都不太理想。permission gates？50 行代碼就能寫一個，覆蓋市面上大多數 agent harness 的能力。custom providers？無論是注冊 proxy 還是接 self-hosted models，都不用等我來做，你自己甚至可以讓 clanker 幫你寫。

你甚至可以重寫內置工具，改變 read、edit、bash 的行為。我自己就有一套版本，是通過 SSH 在遠程機器上執行的，5 分鐘就實現了，而且很好用。再加上完整的 TUI 訪問能力，你可以在 Coding Agent 里直接構建完全自定義的界面。

社區里已經有不少有趣的 extension。比如有人用 5 分鐘就在 pi 里復刻了 Claude Code ships，而且功能更多。

pi-messenger，是多個 pi agent 的聊天室，它們可以互相通信，還有自定義 UI，可以實時觀察它們的行為，而且確實能跑。

甚至還有一些更“離譜”的玩法，比如 pi-nes，你可以在 agent 運行的時候順手打個游戲。

pi-annotate，可以直接打開你正在開發的網站，在前端界面上做標注，把反饋原地喂回給 agent，再讓它修改代碼。

還有我自己常用的 pi-files-widget，不用切到 IDE，就能快速查看剛剛被修改的文件。

關鍵在于，這些都不是內置功能，全都是 extension。而大多數人只需要幾分鐘到一個下午，就能把這些東西按自己的習慣搭出來。

pi 的 session 是樹結構，而不是線性的聊天記錄。你可以在一個分支里讓 agent 讀取目錄、總結內容，然后回到主對話，把總結帶回來繼續工作，本質上就是一種更可控的 sub-agent。系統不會在你背后偷偷注入任何東西，agent、skills、調用成本，全都是透明可追蹤的。這一點很多 harness 都沒做好。此外還支持 HTML 導出、JSON 格式、headless JSON streaming 等等。

Pi 真的有用嗎？terminal bench 的結果顯示：pi 緊跟在 Terminus 2 后面，使用的是 Claude Opus 4.5。而那還是在去年 10 月，當時 pi 甚至還沒有 compaction。

最后說一點現實問題。如果你參與這個項目，很可能會有大量來自 OpenClaw 的用戶涌進你的倉庫，用 clanker 批量提交 issue 和 PR，直接把你淹沒。

所以我不得不搞了一些“防御機制”。比如我發明了一個叫 OSS Vacation 的策略：直接把 issue 和 PR 關掉幾周，自己專心開發。真正重要的問題，總會有人在之后重新提出來，或者在 Discord 里說。

另外我還做了一個簡單的訪問控制：倉庫里有一個 markdown 文件，如果有人提交 PR，但用戶名不在這個文件里，PR 會被自動關閉。規則也很簡單，先用“人類的聲音”寫一個 issue，自我介紹一下，而且不要超過一屏，因為太長的大概率是 clanker 寫的。通過之后，你的名字會被加入列表，就可以正常提 PR 了。本質上，我只是在做一件事：驗證你是人類。

后來 Ghostty 的 Mitchell 也基于這個思路做了一個項目，叫 vouch，可以更方便地應用在你自己的開源倉庫里。

以上就是 pi，去試試吧。

演講原鏈接：

https://www.youtube.com/watch?v=Dli5slNaJu0

聲明：本文為 InfoQ 翻譯整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態智能突破、Agent 架構與工程化實踐、Agent 安全與可信治理、企業級研發體系重構。14 個專題全面開放征稿。

誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。