Agent 基礎設施正在重寫 AI

2024 年，SWE-agent 直接把話講白了。Agent 表現，不只看模型本身。工具怎麼接、狀態怎麼存、任務怎麼排，結果差很多。

接著，Anthropic 又把這件事往前推。它用 Model Context Protocol（MCP），把工具連接變成公開標準。這下子，AI 基礎設施的重心真的開始變了。

講白了，以前大家在拼 Token 成本。現在更像在拼 Agent 能不能穩穩做事。能不能呼叫工具。能不能記住前一步。能不能在多個系統間協作。

2024 為什麼改變了 Agent 討論

以前的框架很簡單。模型越大，效果越好。參數越多，分數越高。很多人就以為，AI 工程的核心只剩推論服務。

但 Agent 出現後，這套說法開始漏氣。只要模型能規劃、能呼叫 API、能讀檔、能重試，周邊基礎設施就立刻變重要。說真的，模型只是大腦。環境才是整個身體。

SWE-agent 是很好的例子。它把軟體工程任務拿來測，結果很清楚：Agent-computer interface 會直接影響成功率。提示詞格式、工具輸出格式、回饋迴圈，這些都不是小事。

Anthropic 的 Agent 指南也在講同一件事。生產環境裡，簡單、可組合的模式通常更穩。這句話很刺耳，但很真。很多團隊還在幻想大框架能解決一切，結果只是把失敗包裝得比較漂亮。

• Agent 品質 = 模型能力 + 介面設計。
• 工具呼叫會把問題變成系統協作。
• 越複雜的框架，越容易藏 bug。
• 標準化介面，能少寫很多接線碼。

AI 基礎設施不再只管 Serving

傳統 AI 基礎設施，重點是 serving。像是 batching、quantization、延遲控制、GPU 利用率。這些還是重要，但不夠了。

Agent 會帶來第二層需求。系統要處理工具呼叫、狀態更新、重試、分支流程，甚至多個 worker 同時跑。這就不是單純的推論服務問題了。

你可以把它想成三種成本一起冒出來。模型推論成本。協調成本。失敗重試成本。很多團隊只看前者，最後卻被後兩者拖垮。

所以現在的 Agent infra，很像 runtime、workflow engine、資料協調層的混血。模型只是其中一塊。真正的產品價值，常常在模型外面。

你可能會想問，那實作上要注意什麼？我整理成幾個很實際的點：

• Agent 何時要 checkpoint 狀態。
• 哪些動作要同步，哪些可背景執行。
• 工具失敗後，怎麼重試才不會重複寫入。
• 哪些資料能快取，哪些一定要重算。

MCP 把工具連接往標準化推

MCP 在 2024 年 11 月公開後，重點不在名字。重點是，它試著把 Agent 和外部工具、外部資料的連接方式標準化。

這件事很實際。每多一個自訂 connector，就多一種 schema。多一種 auth 流程。多一種 tool description。多一種失敗模式。最後整個系統會變成一坨手工接線。

MCP 的價值，就是讓開發者用一致的協定暴露能力。不是每個 app 都要跟每個 model 單獨對接。這對想保留模型選擇權的團隊，很有感。

它也會改變整合成本。內部工具如果能講同一種 protocol，團隊就少花時間改 adapter，多花時間調整 Agent 行為。這種看起來很無聊的基礎工作，往往才是能不能上線的差別。

“The future of AI is not about one model to rule them all. It is about many models, many tools, and a standard way for them to talk.” — Dario Amodei

這句話很直白。價值中心，正在從模型存取，移到連接層。

狀態與排程變成第一級問題

Agent 一旦真的開始做事，state 就不再是細節。你要知道它看過什麼。試過什麼。哪些工具輸出可信。任務卡住後要從哪裡接回來。

這會把 AI 系統往分散式系統工程拉。不是只有 LLM 問答。還有 checkpoint、recovery、task history、memory pressure。說真的，這些比 prompt engineering 更像正經工程。

排程也一樣重要。單一 request 的 Agent，queue 也許就夠了。可是如果你跑上百個長壽命 Agent，就要管 priority、concurrency、worker 分配、工具衝突。

這時候，Agent infra 通常會拆成四層：

• Serving：推論、batching、延遲、成本。
• State：記憶、checkpoint、任務歷史、復原。
• Scheduling：佇列、worker、重試、平行執行。
• Tooling：connector、權限、schema、protocol。

這些方向也能從工具生態看出來。LangGraph 主打 graph-based workflow。OpenAI Agents SDK 則偏向結構化多步驟應用。路線不同，但方向很一致。

再看數據比較，就更清楚了。傳統 LLM 服務，常常只看 latency 和 cost。Agent 系統還要多看三個指標：工具成功率、狀態恢復率、重試後完成率。少一個，產品就可能卡住。

• 傳統 serving：看 TPS、P95 latency、GPU 利用率。
• Agent infra：再加工具成功率、狀態恢復率。
• 單次失敗的代價，常常高於一次推論費用。
• 標準 protocol 會降低整合與維護成本。

這對現在的建置團隊代表什麼

如果你現在在做 Agent 產品，最直接的建議很簡單。不要再把模型當整個 stack。真正的差距，常常出現在協調失敗有沒有被處理好。

工具契約要清楚。狀態要能持久化。流程要能重試。失敗要能復原。這些聽起來很土，但產品能不能穩，通常就卡在這裡。

我也想吐槽一下。很多 Agent demo 很會秀。流程拉得很長。抽象層堆得很高。看起來像魔法。可是一進 production，就開始出現各種鬼故事。

真正能活下來的系統，通常控制流很清楚。介面很明白。狀態很可追。不是因為它比較酷，是因為它比較不容易炸。

AI 工程正在往哪裡走

這波變化背後，其實是 AI 工程成熟化。早期大家在比模型分數。後來開始比推論成本。現在輪到 Agent 的協調層。

這也很像雲端時代的演進。先是 VM。再來是容器。接著是編排。AI 也在走類似路線。模型還是核心，但真正拉開差距的，變成周邊系統設計。

所以如果你是工程師、產品人、或創業者，現在該看的不是「哪個模型最強」。而是「哪個 Agent 架構最穩」。差別很大。

我自己的判斷很直接。接下來 12 個月，會有更多團隊把重點放在 stateful runtime、protocol support、task orchestration。這些東西會比單純換更大的模型更有感。你如果還在只盯參數量，可能會錯過真正的戰場。