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

編譯 | 宇琪

策劃 | Tina

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

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

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

本文基于該演講視頻整理，經(jīng) InfoQ 編輯。

核心觀點如下：

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

• 現(xiàn)有的編程框架里，很多功能可能并不是獲得好結(jié)果的必需品。不需要文件工具，不需要子 agent，不需要聯(lián)網(wǎng)搜素，啥都不需要。

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

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

1ChatGPT→Copilot→Aider→Claude Code

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

我們不停地造東西，造了一大堆，但絕大多數(shù)我們自己從來沒用過。這就是 2025 到 2026 年的新常態(tài)：我們寫了很多代碼，造了很多輪子，但真正用上的沒幾個。折騰到最后我開始想，我討厭現(xiàn)有的所有 Coding Agents 或開發(fā)框架，自己寫一個到底能有多難？當(dāng)時 Peter 說：“我只想做一個屬于自己的小玩意兒。”后來的故事大家可能都知道了。

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

先聊聊 Coding Agents 的演進(jìn)史。

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

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

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

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

2Claude Code 不是一個穩(wěn)定的好工具

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

Anthropic 的開發(fā)者關(guān)系專家 Thariq Shihipar 有時候會在 Twitter 上說些讓人摸不著頭腦的話，比如：“我們的 terminal user interface 現(xiàn)在是一個游戲引擎了。”

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

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

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

而且，他們在后臺偷偷對你的 context 做了很多手腳。2025 年夏天，我寫了一堆工具去攔截 Claude Code 發(fā)往后端的請求，想看看他們在背地里往我的 context 里塞了哪些額外的文字。結(jié)果發(fā)現(xiàn)這些操作非常多余，而且每天都在變。可能今天發(fā)個版本，明天又發(fā)個版本，注入內(nèi)容的時機(jī)和方式變來變?nèi)ィ@會直接搞亂你現(xiàn)有的 workflow。它不是一個穩(wěn)定的工具。

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

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

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

3OpenCode 的底層設(shè)計讓我失去信心

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

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

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

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

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

這時候如果你跑去問 LSP 服務(wù)：“嘿，我剛改了這一行，代碼崩了嗎？”LSP 肯定會說：“是的，徹底崩了。”然后這個功能就會把報錯信息直接塞進(jìn) tool call 后面，反饋給模型：“你剛才干錯了。”模型一臉懵逼：“搞什么？我還沒改完呢！你現(xiàn)在跟我說這個？”這種事發(fā)生得多了，模型最后就會直接罷工，導(dǎo)致產(chǎn)出的結(jié)果非常糟糕。所以我特別反感在 agent 工作時掛 LSP。真正需要 linting（代碼檢查）和類型檢查的時機(jī)只有一個：那就是 agent 覺得自己徹底完活兒的時候。

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

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

這就是我對現(xiàn)有 coding harnesses 的觀察。AMP 其實不錯，但我沒有掌控權(quán)，它甚至?xí)Q定你用哪個模型處理哪類任務(wù)，這不符合我的性格。

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

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

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

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

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

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

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

4Pi：讓 Coding Agent 適應(yīng)你的需求

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

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

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

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

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

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

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

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

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

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

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

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

社區(qū)里已經(jīng)有不少有趣的 extension。比如有人用 5 分鐘就在 pi 里復(fù)刻了 Claude Code ships，而且功能更多。

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

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

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

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

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

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

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

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

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

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

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

以上就是 pi，去試試吧。

演講原鏈接：

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

聲明：本文為 InfoQ 翻譯整理，不代表平臺觀點，未經(jīng)許可禁止轉(zhuǎn)載。

會議推薦

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

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

誠摯邀請你登臺分享實戰(zhàn)經(jīng)驗。AICon 2026，期待與你同行。