寫了 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，雖然有時候靈，大多數時候并不。甚至有時候，它還會非常“貼心”地給你默寫一段 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 里塞了哪些額外的文字。結果發現這些操作非常多余，而且每天都在變。可能今天發個版本，明天又發個版本，注入內容的時機和方式變來變去，這會直接搞亂你現有的 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 后來的態度邏輯很通順：“你們不能這么搞。”雖然這事兒沒公開鬧大，但道理很簡單：如果你去健身房卻不守規矩，濫用人家的基礎設施，你肯定會被拉黑。雖然我沒證據，但我猜這就是為什么 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 模式（默認直接執行，不向用戶確認，全自動跑到底）。現在大多數 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，這樣所有輸入輸出都在你掌控之中，每一步發生了什么都一清二楚。現在 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，期待與你同行。