轉載自：https://mp.weixin.qq.com/s/rY5yqB3TE0o7LcnC4vkfpQ
作者：PingCAP 聯合創始人兼 CTO 黃東旭

這兩天密集使用了 opencode + oh-my-opencode，在一個並不輕量的真實任務中，我對 Agent 系統的理解發生了一次明顯的變化。

我的任務很具體：

為 TiKV 重新實現一層兼容 PostgreSQL 協議的 SQL 層。能夠跑起簡單的測試，例如 dvdrental 的兼容性測試以及 TPCC。

這個任務相當於重寫一遍 TiDB 的 SQL 層，我知道這個任務不容易，哪怕只是跑起來簡單的 TPCC 我們就大概花了 2 個月的時間，注意這還是一個團隊的工作。

最終的結果讓我出了一身冷汗。成果在這裏：https://github.com/c4pt0r/tipg，我就不展開説了。

我本來預想它能幹，但是可能需要花很長時間以及很多調教，但是結果卻驚出我一身冷汗：不到一個下午，燒掉了大概 100多萬 token，因為我是各種 Agent 的 Pro Max 會員，甚至都沒有額外花錢。。。

我第一次清晰地意識到： 寫代碼的成本已經幾乎可以忽略不計了，哪怕是數據庫，操作系統，編譯器這樣的複雜項目（對於 AI 來説這些其實算是簡單項目）。

寫一點這個旅程的體驗。

Context Engineering 並不是堆 Prompt

在切換到 opencode 之前，我已經重度使用過 Claude Code、Gemini Pro、Codex 這類工具。

從形態上看，它們都已經是 agentic loop + tool use 的 CLI。

坦率説，底層模型能力本身已經沒有本質差距，都是各家的頂級模型。

但實際體驗中，成品差異卻非常明顯。

原因並不在模型，而在 context engineering。大家總有一些幻覺，好像套殼沒有技術含量似的，但是我的體驗是這裏面的門道大了去了。。。

真正有效的 context engineering，是把以下內容持續、結構化、穩定地注入系統中：

• 明確但不過度具體的目標（人）

• 清晰的計劃（Agent）

• 工程邊界與約束 （人）

• 歷史決策與隱含假設 （Agent）

• 讓模型在長上下文中不亂飛的穩定中間結構 （Agent）

例如，當我切換到 opencode + oh-my-opencode 後，模型還是同一個模型，但行為完全不同了。 同樣是 agentic loop， 同樣是 tool use， 複雜工程的交工質量卻完全不在一個量級。

oh-my-opencode 裏一個讓我很舒服的設計是：

它並不執着於“用哪個最強模型”，相反它把多個一線模型組織進同一個工作流中。其實這個也不難想到，3 個臭皮匠頂過諸葛亮，況且 3 個諸葛亮

這帶來的效果明顯超過預期。

未來的上限，不一定來自更大的模型本身，而更可能來自： 多模型（最強的那檔）協同 + context engineering + 穩定 loop 的整體設計。

不中斷，比“更聰明”重要

另一個關鍵但常被忽略的點是：

不中斷的體驗（non-interruptive flow）。

很多 agent 系統在 “思考 → 執行 → 報錯 → 等人確認” 之間頻繁打斷。 也就是上下文是存在的，但工作流是斷裂的。

我目前通過 ralph-loop 來解決這個問題 ：讓 agent 在一個穩定的 loop 中持續無限推進（燃燒 token），

人只在必要的位置介入（通常是最後驗收），而不是被迫扮演“下一步指揮官”。

一旦中斷減少，變化非常明顯，首先是工程節奏開始接近真實連續開發，人的認知負擔明顯下降。其實 AI 目前已經足夠聰明，工具也足夠好用，效率的瓶頸在人。

給人的界面同樣重要

同樣是 TUI，opencode 的體驗明顯的比 CC 好，我覺得主要來自一個點：

而人需要的是掌控感（sense of control）。

好的體驗是讓人始終清楚：

• 系統現在在做什麼（thinking 和 todo 的展示）

• 為什麼這麼做

• 我何時、以什麼方式可以介入

一旦人被迫向 agent 發指令等結果， 體驗一定是糟糕的。

真正好的 agent 系統，應該把複雜性留在代碼和 loop 裏，

把決策權、節奏感和信任感通過精心設計的界面交還給人。

當前最差的體驗：Infra

如果一定要指出當前體驗中最差的部分，

那仍然是 infra：

• sandbox / runtime 配置

• 數據庫與依賴服務的啓動

• 測試環境、fixture、數據準備

• 本地與 CI 的一致性

這些事情高度重複、上下文破碎、且極度不 agent-friendly。即使模型已經能把“寫代碼”這件事做到很好，一旦卡在 infra 上，節奏還是會被硬生生拖慢。

下一階段真正決定體驗上限的， 不是 opencode 這樣的工具本身，

而是 opencode + infra abstraction。

當 sandbox、數據庫、測試，CICD，都能作為一等上下文被系統管理，而不是一堆需要人手動 glue 的腳本時，agent 才能真正從“寫代碼的助手”， 進化成持續推進工程的系統。

opencode for XXX，很快就會到來

程序員可以説是第一批感受到 AGI 到來的羣體，不管我們願不願接受，職業寫代碼這件事情很快就不存在了，不過也不用過度擔心，人類不用靠體力狩獵以後，現代的人類仍然會去健身房鍛鍊，作為一個愛好和思維遊戲，古法編程會持續存在的。

但是從最近編程 Agent 迭代情況來看，我認為：

• Context engineering 是可遷移的

• 模型能力正在標準化

• More tokens, more intelligence

也就是同樣的食材（LLM）配合不一樣的廚子（Claude Code / Open Code），你會得到截然不同的效果。但是你本人的 init prompt （目的）也許並沒變化。

我們很快會看到 opencode for XXX、opencode for YYY 這樣的系統出現。

底層模型可以完全相同，但通過不同的上下文組織方式，它們會表現得像完全不同的專業系統。

那時“通用大模型是否足夠強”將不再是關鍵問題，真正重要的是：

誰更懂得如何構建一個長時間可持續穩定工作的上下文。