你的 MCP server 寫錯了：10,000+ 個伺服器、9% 真正能用、整合協議戰已經分輸贏

不到 18 個月，Anthropic 開的 MCP 從一份規格長成 AI 工程世界的事實標準。但 2026 上半年同時發生三件事：MCP 數字爆炸、A2A 吃下 ACP 完成協議分層、KuppingerCole 與 Qualys 同時警告安全跟不上採用。如果你正在做 agent 整合，這篇是現況快照。

一個 Reddit 數據先讓你冷靜

2026 年 4 月，有人爬了 2,181 個遠端 MCP server endpoint， 跑了個健康度調查 （單一社群調查，方法論未完整公開，數字當粗略指標看）：

• 9% 確認健康可用
• 37% 回應但需要認證（401/403）
• 52% 拒絕連線或回不來
• 1.5% 慢或間歇性錯誤
• 有 GitHub repo 的伺服器中，58% 過去 30 天沒有任何 commit

我看到這數字是真的被嚇到。然後我打開 Prefect CEO Jeremiah Lowin 在 ODSC 2026 的 keynote ，標題不裝飾：「Your MCP Server is Bad（and you should feel bad）」。

這篇要拆的就是這件事。MCP 規模大到嚇人，但結構性問題也大到嚇人。協議戰已經偷偷打完了——你只是還沒注意到。

數字面：MCP 不是「新興」，是「爆炸」

先把規模釐清，因為這直接影響你怎麼看後面的問題。Anthropic 在 2024 年 11 月開源 Model Context Protocol 規格。十八個月後：

指標	2026 上半年數值
Anthropic 官方 SDK 月下載量	~97 million
活躍公開 server 數	10,000+（Anthropic 自報；註冊表快照 9,652）
GitHub mcp-server topic repos	15,926 （2026/5/24 GitHub Search API 截至日 ）
大型企業部署率	約 28% Fortune 500 （Truto 2026 引用 Anthropic / 多家報告綜整；單一二手來源，斟酌參考）
主流 client 原生支援	Claude Desktop、Cursor、Zed、Cline、Windsurf、VS Code、ChatGPT、Gemini、Copilot Studio

Zuplo 的 State of MCP 報告 訪問了近百位開發者：54% 確信 MCP 會持續或成為產業標準，但 40% 仍有疑慮——這個比例非常誠實，畢竟競爭協議當時還在跑。

不過——這些「公開伺服器」數字會誤導。Pragmatic Engineer 的深度報導裡 Jeremiah Lowin 講了一句業界內幕：「真正大用量的，其實只有大約 10 個 MCP server，剩下是有海量公開伺服器幾乎零使用，而且大量企業伺服器根本不公開。」公開的長尾很長，但業務價值集中在頭部與內網。

數字看起來嚇人，現實沒那麼平均。

你的 MCP server 為什麼爛

回到 Lowin 的 keynote。他的核心論點對所有寫過 REST API 的工程師都很刺耳：

「多數 MCP server 失敗，是因為開發者把它當 REST API 設計，沒有為 agent 限制設計。」

Agent 不是用戶。Agent 的三個限制讓 REST 思路直接撞牆：

1. Discovery 很貴——每個工具的描述都要塞進 context window。50 個 tool 列表動輒幾千個 token，每次呼叫都在燒
2. Iteration 很慢——每次往返都有 latency 與 token 成本
3. Context 有限——agent 沒辦法像人類一樣翻文件回頭看

所以 Lowin 給的設計原則直接打臉「REST API → MCP wrapper」這個最常見的偷懶做法：

設計原則：把 MCP server 當作「agent 的 UI」

反模式	正確做法
每個 endpoint 都包成一個 tool	一個 tool = 一個完整 workflow（design for outcomes, not operations）
巢狀物件參數	扁平化成 primitive 型別（string / int / bool）
把 OpenAPI spec 自動轉成 50+ tools	控制在 < 50 tools，殘酷地策展
描述只寫「Returns X」	給明確指示與範例，agent 是讀者
把 REST 文件複製過來當 description	為 agent 重寫，包含 when to use / when not

Before / After 範例

反模式（REST wrapper）：

@server.tool()
def get_user(user_id: str) -> dict: ...

@server.tool()
def get_user_orders(user_id: str, limit: int = 10) -> list: ...

@server.tool()
def update_user_status(user_id: str, status: dict) -> dict: ...

@server.tool()
def calculate_user_ltv(user_id: str, period: str) -> float: ...
# ...再來 30 個類似的

agent 看到這個工具列表，會去推「我要算 LTV 是不是要先 get_user？要不要先 get_orders？status 是哪個欄位？」——把推理算力浪費在工具編排上，而不是業務問題上。

outcome-driven 設計：

@server.tool()
def analyze_customer(
    customer_id: str,
    include_orders: bool = True,
    include_ltv: bool = False,
) -> CustomerAnalysis:
    """
    取得客戶完整輪廓。預設包含基本資料與訂單。
    需要 LTV 才設 include_ltv=True（會多一個資料庫查詢）。

    當你需要：客戶概況、訂單回顧、流失分析時使用。
    不要用於：批次匯出（請改用 export_customers）。
    """

一個 tool 解決一個完整任務，內部組合多個 REST 呼叫，外部給 agent 一個乾淨介面。這才是 agent UI 設計。

Cloudflare 的 "Code Mode" 也是同一思路——根據 Cloudflare 自家公告 ， WorkOS 也轉述了同一數據 ：展示了 98%+ 的 token 節省，方法是讓 agent 動態發現並呼叫 tool，而不是把所有定義一次塞進 prompt。

協議戰已經分輸贏：MCP + A2A 的雙層架構

如果你還在看「MCP vs ACP vs A2A 誰會贏」的舊文，請更新一下。戰爭已經結束。

時間線：

• 2024/11：Anthropic 推出 MCP（agent ↔ tool）
• 2025/3：IBM Research 推出 Agent Communication Protocol（ACP） ，定位 agent ↔ agent
• 2025/4：Google 發布 Agent2Agent（A2A） ，同樣管 agent ↔ agent
• 2025/6：A2A 捐贈給 Linux Foundation
• 2025/8/29：LF AI & Data 宣布 ACP 併入 A2A
• 2025/9：BeeAI 平台改用 A2A，Kate Blair（前 ACP 負責人）加入 A2A Technical Steering Committee

也就是說，今天的局面非常清楚：

┌──────────────────────────────────────────┐
│   A2A（agent ↔ agent，跨框架互通）        │
│   LF 治理 / Google + IBM + 100 家以上     │
├──────────────────────────────────────────┤
│   MCP（agent ↔ tool / data / resource）  │
│   Anthropic 主導 / 跨 vendor 採用         │
└──────────────────────────────────────────┘

A2A Technical Steering Committee 名單夠權威：Google、Microsoft、AWS、Cisco、Salesforce、ServiceNow、SAP、MongoDB、IBM——加上 Linux Foundation 上 100+ 家公司支持 。
UTCP（Universal Tool Calling Protocol）試圖把 OpenAI、Anthropic、Google 的 function calling 統一，但在這個分層裡找不到位置——畢竟 MCP 已經占了那個層級。

你現在做的是 agent ↔ tool？用 MCP。
你現在做的是 agent ↔ agent？用 A2A。
不要再賭協議了。

Anthropic 把 agent 變成「託管基礎設施」

5 月 6 日 Code with Claude 2026 在舊金山開，這場我看 Simon Willison 的 live blog 印象最深的不是新模型——他們沒發新模型——而是 Ami Vora（新任 CPO）開場那句：「Anthropic 平台 API 流量同比成長 17 倍。」

Dario Amodei 補了另一個面向的數字：年度化看，demand 比年初預估高出約 80 倍——這是 Q1 2026 annualized demand vs 計劃的對照，與 17x 不是同一個維度，但都是同一個訊號。

這場會的核心訊息不是「我們做了什麼酷東西」，是「我們把基礎設施做厚」。Claude Managed Agents（4/8 公測 ）這次新增三個能力：

1. Multi-agent Orchestration：一個 supervisor 協調一群 specialized agent
2. Outcomes：定義成功條件，agent 自己迭代直到達標（像 Code 的 /goal，但跑在雲端）
3. Dreaming：agent 能回看以前的 session，從中改進——簡單講就是「自監督長期學習」

InfoQ 引用 Anthropic 產品經理 Jess Yan 的話最直白：「Infrastructure, rather than intelligence, is now the bottleneck for production agents.」 基礎設施而非智慧，已是 production agent 的瓶頸。

緊接著 5/19 Code with Claude London 又補了一刀：self-hosted sandboxes + MCP tunnels，讓企業可以在自己的 infra 跑 agent 執行環境，把 orchestration 留在 Anthropic。Cloudflare 5/28 推出 Claude Managed Agents on Cloudflare 整合 ——直接把 microVM、Workers VPC、Browser Run、Email 都接上去。

也就是說 Anthropic 在做的事很清楚：讓 agent 從「規格」變成「PaaS」。

對你的影響很現實：如果你要做 production agent，自己幹 sandboxed code execution + credential scoping + checkpoint + audit trail 這套基礎設施，會被 Anthropic / Cloudflare / Vercel 這類玩家輾過去。Lowin 也用 Prefect Horizon 在做同樣的事，他們直接喊「每家公司都會有 context layer，有些公司會刻意建，多數會意外建」。

這場會還有一個耐人尋味的細節：主講不是 Dario Amodei，是 product head 與工程師。這個訊號很 Anthropic——他們不再想被當成「研究實驗室」，要當「AI 原生公司」。

房間裡的大象：安全跟不上採用

採用快得不像話，但安全慘得不像話。

5 月 11 日 KuppingerCole 的 Leadership Brief 開頭就把話講明：

「MCP 已迅速成為 agentic AI 生態系的連結組織，並正以企業規模部署，卻沒有成熟的認證基線與可靠的執行時強制機制。」

Qualys 把這現象稱為 「2026 的新 Shadow IT」 ——MCP server 已經悄悄部署在企業環境裡，IT 部門根本不知道存在。

WorkOS 的 2026 MCP 全景 列出協議層級沒處理的缺口：

缺口類別	現況
Enterprise observability	無標準審計軌跡，每家自己發明
Multi-tenancy	協議未定義 tenant 隔離模型
Rate limiting	協議層沒有，得自己擋
Cost attribution	agent 自主呼叫工具時無法追算錢
認證（authentication）	規格在演進，但 vibe governance 還是主流

Lowin 講得最狠：「現在多數企業在搞 vibe governance。他們把『可以對客戶請款』這種 tool 給 agent，然後寫了一張禮貌的便條請 agent 好好用。你沒辦法用 prompt engineering 解決營運風險。」

回到 Reddit 那組數字：37% 的 server 卡在認證、52% 連不上——這不只是「品質差」，這是整個生態的執行時強制機制還沒長出來。任何打算把 MCP 推進 production 的人，都得自己補一整層 platform。

工程師現在該做什麼

把上面這些濃縮成幾條工程師可執行的建議：

1. 內部 MCP > 公開 MCP：你公司內部的 MCP server 才是真正 ROI 所在；公開 MCP 多數是 demo 與長尾。
2. 拒絕 REST wrapper：用 outcome-driven 設計，一個 tool 一個 workflow，控制在 < 50 個。把 description 當「給 agent 看的 UI 文案」寫。
3. 架構分層別搞混：agent ↔ tool 用 MCP，agent ↔ agent 用 A2A，別亂用。
4. 安全自己補：認證、執行時強制、審計、cost attribution、rate limiting——協議全部不管，你的 platform 要管。考慮用 Zuplo 、Kong 這類 MCP gateway，或自己包一層。
5. 準備好「跨提供商可攜」：你今天跑 Claude，明天可能跑 GPT，後天跑 Gemini。把 prompt、tool 設計、skill 寫成跨模型可攜資產，不要 hardcode 任何一家的特色 API。
6. 追蹤 Managed Agents 動態：Anthropic / Cloudflare / Vercel 都在做這層，自己幹是有可能，但要評估 ROI。對小團隊與單一專案，外包這層是合理選擇。

寫在最後

MCP 規格那麼小（三個 primitive、兩個 transport、用 JSON-RPC 2.0），擴散速度卻打破紀錄。原因不只是 Anthropic 開放——是它精準命中了 agent 工程的最大痛點：整合層。但快速擴散也意味著結構性問題會放大——9% 健康率、Lowin 的「your MCP server is bad」、KuppingerCole 的安全警告，全都在同一個時間點冒出來，不是巧合。

協議戰已經分輸贏：MCP 管 tool，A2A 管 agent，分層完成。Anthropic、Google、IBM、Microsoft、AWS 全部押這條線。
真正的賽道從「協議誰贏」轉到「誰能把整合層做得讓開發者能信任」——這是接下來 12-18 個月你會看到大量資金、新創、工具湧入的領域。

如果你正在寫第一個 MCP server，請從 Lowin 那句話開始：你不是在寫 REST API，你在寫 agent 的 UI。把這句話貼在你螢幕上。

---

延伸閱讀

• Model Context Protocol 官方文件
• Anthropic Code with Claude 2026 live blog（Simon Willison）
• InfoQ：Code with Claude 2026 Managed Agents 報導
• Pragmatic Engineer：Building MCP servers in the real world — 訪問 46 位開發者 + Jeremiah Lowin + 微軟 MCP 維護者
• ODSC AI East 2026 keynote：Your MCP Server is Bad
• LF AI & Data：ACP 與 A2A 合併公告
• IBM Think：A2A 解析 與 ACP 解析
• WorkOS：Everything your team needs to know about MCP in 2026
• Zuplo：The State of MCP 報告
• KuppingerCole：MCP — The API Security Problem Nobody Is Ready For
• Qualys：MCP Servers — The New Shadow IT for AI in 2026
• Cloudflare：Claude Managed Agents 整合公告
• Prefect Horizon 介紹
• Reddit：2,181 個遠端 MCP 端點健康度分析（2026/4）

延伸閱讀

• 從養蝦到蓋 Agent OS：拆解 Anthropic Managed Agents 的腦手解耦架構與本地復刻實踐
• 提示詞越改越爛？Anthropic 工程師的 4 步驟，把失準的 AI 系統救回來
• 政府有沒有權利，在四小時內關掉一個 AI 模型？
• 自己造的炸彈炸到自己：Anthropic 安全行銷的反噬

後 Transformer 時代來了？Mamba-3、ICLR Outstanding Paper、7M 模型同時打三個方向的真相

2026 年 4-5 月有三件事讓「Transformer 要被換掉」的論調再度燒起來。但你把三件事擺在一起看，會發現它們指的不是同一個方向——其中一件甚至從理論側狠狠打了 SSM 派一巴掌。先別急著重構你的 stack，這篇把張力講清楚。

先看一個讓人心煩的數字

DeepSeek R1，671B 參數，在 ARC-AGI-1 拿 15.8%。
Gemini 2.5 Pro，37.0%。
o3-mini，34.5%。

然後有一個叫 TRM 的東西，7M 參數——少了五個數量級——拿了 44.6%。

你沒看錯。一個你能塞進手機的小模型，在 ARC-AGI（那個讓 AGI 派與懷疑派吵到天昏地暗的「真推理」基準）上面，把市值千億的 frontier model 通通踢開。這篇論文叫 Less is More: Recursive Reasoning with Tiny Networks ，作者 Alexia Jolicoeur-Martineau 來自 Samsung SAIT AI Lab（Montreal），還拿了 ARC Prize 2025 的 Paper Award 1st Place 。

同一時間 ICLR 2026 也辦完了。Mamba-3 拿到 Oral 名額 （4% 論文才有的待遇），把 SSM 推到一個明顯更成熟的位置（Oral 是 ICLR 接受論文中極稀少的高榮譽）。另一頭，Transformers are Inherently Succinct 拿了 Outstanding Paper ——理論派直接證明：RNN/SSM 要做出 Transformer 能做的事，表達成本可能是「指數級」的開銷。

三件事丟在一起像看摔角自由搏擊：每個招式都漂亮，但你根本不知道誰會贏。
這就是我接下來要拆的事。

第一條線：Mamba-3 的「推理優先」翻盤

Mamba-1（2023）證明 selective SSM 可以打到接近 Transformer。
Mamba-2（2024）給了個叫「state space duality」的理論框架，讓 SSM 不再像個玄學咒語。
Mamba-3 （ICLR 2026 Oral）的問題不一樣：「如果一開始就為推理（inference）設計 SSM，它會長什麼樣？」

作者群 Aakash Lahoti、Kevin Li、Berlin Chen、Caitlin Wang、Aviv Bick、Zico Kolter、Tri Dao、Albert Gu 動了三個槓桿：

1. Exponential-Trapezoidal 離散化

過去 Mamba-1/2 都用「指數歐拉法」做連續時間 ODE 的離散化，這玩意是一階近似。Mamba-3 換成梯形法——二階近似，局部截斷誤差從 O(Δt²) 降到 O(Δt³)。直白講：你的 hidden state 更新公式變成三項遞迴：

h_t = α_t · h_{t-1} + β_t · B_{t-1} · x_{t-1} + γ_t · B_t · x_t

這個小改變的副作用很爽——它讓你不再需要短 causal convolution。Mamba-1/2 都靠那個 short conv 補 induction 能力（簡單講就是「記住前面看過什麼」），Mamba-3 把這件事內建進遞迴本身，省一層。

2. Data-Dependent RoPE 補 state tracking

Mamba 系列被詬病最久的就是 state tracking 能力差——你給它 parity 任務（奇偶判斷），它會崩。
Mamba-3 把 hidden state 升級成複數值（complex-valued），用旋轉的方式更新。實作上等於「資料相依的 RoPE」——把 Transformer 早就用爛的旋轉位置編碼，搬到 SSM 的內部狀態。結果：parity 任務接近 100% 解開。

3. MIMO：用閒置的 GPU 算術強度

decode 時 GPU 通常 memory-bound，算術單元在發呆。Mamba-3 的 MIMO（Multi-Input Multi-Output）讓每個 decode step 做更多有用的事，但 latency 不變。

成績：

指標	Mamba-3 (1.5B)	vs 次強模型
下游平均準確度	+0.6 分（SISO） / +1.8 分（MIMO）	對比 Gated DeltaNet
同 perplexity 所需 state size	砍半	對比 Mamba-2

Janu Verma 的論文導讀 給了一句精準的總結：「Mamba-3 是一個押注——推理時代已經到了。」

但——這篇論文還有一個你不會在新聞稿看到的細節。作者在附錄寫得很坦白：要追上 Transformer 的「精準檢索」能力，他們最後跑的是 hybrid（每 5 個 SSM 配 1 個 attention）。
是的。連 Mamba-3 自己都用 hybrid。

第二條線：理論派的當頭棒喝

如果你過去十年讀過 SSM 論文，每篇開頭幾乎都會問同一個問題：「我這個架構能表達 Transformer 能表達的函數嗎？」 大家拼命跑 perplexity、跑 benchmark，最後得到的答案大致是「能」。

ICLR 2026 Outstanding Paper 「Transformers are Inherently Succinct」 ——三位作者來自 RPTU Kaiserslautern-Landau、ETH Zürich 與 Max Planck Institute——把這個問題改了：「你能多『簡潔』地表達它？」

結論用一句話講完：
Transformer 可以比 RNN/SSM 指數級更簡潔。比 finite automata 雙指數級更簡潔。

這不是常數倍數差距，不是多項式倍數差距，是 2^n 等級的差。換成工程白話：有一類概念（論文證明用的是 LTL 公式與某些形式語言），用 polynomial-size 的 Transformer 可以表達，但同樣的概念若改用 RNN 或 SSM，最小尺寸必須是指數級。

這就尷尬了。
業界一直在問「Mamba 表達能力夠不夠？」 答案是「夠」。但這篇論文要你問的是：「夠的代價是多少？」——如果代價是 參數量爆炸到指數級，那你拿掉 attention 省下的東西，馬上又被狠狠補回來。

論文還有一個副產品也很有意思：驗證 fixed-precision Transformer 的簡單性質是 EXPSPACE-complete。對做 AI 安全與形式驗證（formal verification）的人來說，這基本上等於「想做」跟「做得到」隔了一個指數空間。

Towards AI 上 Dr Swarneendu AI 的解讀 講得很狠：「我們花十年回答錯的問題。」

夭壽。

第三條線：7M 參數的 ARC-AGI 小怪

回到開頭那組數字。TRM 的招式說來其實簡單——簡單到讓人懷疑為什麼以前沒人這樣搞：

# 簡化版 pseudocode
y = embed(answer)
z = embed(latent)
for k in range(K):  # K = 16 改進步數
    for n in range(N):  # 內部遞迴 n 次
        z = net(x, y, z)  # 用問題、目前答案、目前 latent 更新 latent
    y = net(y, z)         # 用 latent 更新答案
# 前面幾輪不計算梯度，只有最後一輪做 backprop

兩層網路，7M 參數，遞迴 16 次自我修正。靠的不是參數量，是「test-time compute」——把算力花在推理時的迭代，不花在參數本身。

完整對比：

模型	參數	ARC-AGI-1	ARC-AGI-2
DeepSeek R1	671B	15.8%	1.3%
Claude 3.7 (16K)	?	28.6%	0.7%
o3-mini-high	?	34.5%	3.0%
Gemini 2.5 Pro (32K)	?	37.0%	4.9%
HRM（前身）	27M	40.3%	5.0%
TRM-Att	7M	44.6%	7.8%
Grok-4-thinking	1.7T	66.7%	15.9%
Bespoke (Grok-4)	1.7T	79.6%	29.4%

（資料整理自 ARC Prize Leaderboard 與 TRM 論文 Table 5，時間點為 2025 年 10 月公告；各模型評估時間不同，比較宜以同期評估為準。）

別過度興奮。
TRM 贏的對手是「拿著 prompt 直接做 ARC」的 LLM。一旦你給 frontier model 大量 test-time compute + 蒸餾（像 Bespoke Grok-4），它還是贏 TRM 一大截。而且 TRM 完全不能回答事實性問題——它的「知識」就是訓練那 1000 筆樣本，它靠的是規則推理而非世界知識。

但 TRM 的存在點出一件事：
參數量 ≠ 推理能力。把算力分到「test-time recursion」，能在特定任務拿到完全不成比例的 ROI。對韌體 / 邊緣場景來說，這是條極大的好消息。

三者擺一起：Hybrid 才是答案

把三條線並起來：

• Mamba-3 用工程把 SSM 推到新高度，但作者自己跑 hybrid
• ICLR Outstanding Paper 證明純 SSM 在某些概念表達上要付指數代價
• TRM 用「小模型 + 遞迴 test-time compute」打開另一條路

Forbes 的訪談 裡 Liquid AI 共同創辦人 Alexander Amini 講得很乾脆：「我們已經看到這個轉變了——今天頂尖、甚至 trillion-parameter 的模型，多數已經是 Transformer 與其他成分的 hybrid。」「我覺得這是今天的主流。」

Alibaba、Qwen 也是同樣路線。
Google 的 Gemma 4 + Multi-Token Prediction 更狠——直接把 speculative decoding 烤進主模型， 官方測試 Pixel 上 E2B/E4B 各跑 2.8x / 3.1x，Apple M4 跑 31B 模型 2.5x 。授權還順便改成 Apache 2.0。

所以工程師現在面對的真實局面，不是「Transformer 死了該換誰」這種小屁孩問題，而是：

「怎麼搭？」

• Attention 給你精準檢索與壓縮表達
• SSM/Mamba 給你線性複雜度、可控 state、長 context、串流
• Test-time recursion 給你不靠參數量的推理深度
• MTP / speculative decoding 給你 inference 加速

這四個是 可組合的元件，不是互斥的選項。會不會搭，是 2026-2027 的真本事。

對嵌入式 / 邊緣 AI 工程師的意義

我寫這篇有一半是寫給自己看的。
我做硬體韌體，過去兩年看 LLM 都帶著一種「這跟我有什麼關係」的距離感——Cortex-M4 上跑 70B？ 笑死。

但 2026 上半年這三件事疊起來，邊緣場景的局勢真的變了：

1. Mamba-3 的 state size 砍半 + 線性複雜度：MCU 上跑 sub-quadratic 模型不再是學術玩具。state 越小，SRAM / Flash 預算越好抓。
2. TRM 的 7M 推理範式：不是讓你在 nRF52 上跑 ChatGPT——而是讓你「用一個小到能塞進 MCU 的模型解決特定推理任務」（感測器決策、序列辨識、規則推理）。1.5MB 的權重檔很多 MCU 都吃得下。
3. Gemma 4 MTP 的 speculative decoding：邊緣不只是「模型多小」，是「inference 多快」。同樣的算力，吞吐 2-3x，這在 voice agent / 即時感測器融合的場景是質變。

如果你跟我一樣是硬韌體背景，要追的不是「LLM 越來越大」，而是 「architecture × test-time compute × inference optimization」這三個方向的交集。
那才是邊緣 AI 真正的窗口。

而軟體端，給用 Claude / Cursor / Codex 的人一句話：
把 prompt 與 skill 當作「可攜資產」設計，因為 6 個月內你下面的模型一定會換——不管是換到 hybrid、換到 SSM 主導、還是換到某種我們現在還沒看到的東西。

寫在最後

2017 年 Vaswani 那篇 Attention Is All You Need 把序列建模壓進一個範式。
2026 年我們同時看到三件事：工程派把 SSM 推到新高度、理論派證明 Transformer 在「簡潔」這個維度有指數優勢、新範式靠 test-time recursion 用 7M 打敗 671B。

我不覺得這是「Transformer 末日」。
我覺得這是「Transformer 終於不再是唯一答案」——一個更健康、更工程化、更 hybrid 的時代。

如果你還在猶豫要不要關注 Mamba / SSM / 後 Transformer，我的建議是：別問「會不會贏」，問「我的場景哪一塊可以用它換性能」。
那才是工程師該問的問題。

---

延伸閱讀

• Mamba-3 論文（arXiv:2603.15569） — ICLR 2026 Oral 原文
• Transformers are Inherently Succinct（OpenReview） — ICLR 2026 Outstanding Paper
• Less is More: Recursive Reasoning with Tiny Networks — TRM 原始論文
• Google 官方 Gemma 4 MTP 解說
• ICLR 2026 Outstanding Papers 官方公告
• ARC Prize 2025 結果分析 — TRM 得獎背景
• Janu Verma：Mamba-3 深度導讀
• Dr Swarneendu AI：RNN 表達能力理論解析
• Forbes：Liquid AI 訪談 — Transformer 與 AGI
• Ars Technica：Gemma 4 MTP 速度測試

延伸閱讀

• 8GB 的 RK3588 能跑多聰明的 LLM？ROCK 5C 用 NPU 實測 5 個模型
• 你的 MCP server 寫錯了：10,000+ 個伺服器、9% 真正能用、整合協議戰已經分輸贏
• TTS 文字轉語音完全指南：技術原理、聲音克隆與 2026 選型實戰
• 同一顆基座、兩種靈魂：Holo 3.1 與 Qwythos-9B 怎麼在你本機組成 Claude Computer Use