AI Agent 學習、建構與避坑指南（2026 年）

每天都有新的框架、新的基準、新的「10 倍」產品問世。問題不再是「我該如何跟上」，而是：哪些才是真正的訊號，哪些只是披著急迫外衣的雜訊。

每份路線圖在發布一個月後就過時了。你上一季精通的框架，現在已成歷史。你優化過的基準，被人鑽漏洞後又被取代。我們習慣遵循一條傳統路徑：一個有主題和層級的技術棧、一系列的工作和年資、緩慢的晉升。AI 改寫了這一切。任何擁有正確提示和良好品味的人，現在都能完成過去需要兩年經驗的工程師花一個衝刺週期才能交付的工作。

專業能力仍然重要。沒有什麼能取代親眼看過系統崩潰、在凌晨兩點除錯記憶體洩漏、為了無趣的選擇而辯護並證明自己是對的經驗。那種品味會隨著時間累積。但不再像過去那樣累積的是：知道本週框架的 API 表面。六個月後，它就會不一樣。兩年後會勝出的人，是那些早早選定持久的核心元件，並讓其他東西隨風而去的人。

我在這個領域花了兩年時間，拿到好幾個超過 25 萬美元的 offer，現在在一家隱身模式的公司負責技術。以下是我會告訴那些問「我現在到底該關注什麼」的人的話。

這不是一份路線圖。Agent 領域還沒有明確的目的地。大型實驗室都在公開迭代，向數百萬用戶推送有回歸問題的版本，撰寫事後檢討報告，並即時修補。如果 Claude Code 的團隊能推送一個效能衰退 47% 的版本，而且是在用戶社群發現後才察覺，那麼認為這一切背後有穩定地圖的想法，純屬虛構。每個人都在摸索。新創公司蓬勃發展，因為巨頭們也不知道答案。不會寫程式的人正與 Agent 合作，在週五交付 ML 博士們在週二還認為不可能的東西。

這個時刻有趣的地方在於，它對資歷問題的影響。傳統路徑讓你為資歷而優化：學位、初階職位、資深職位、主管職位，緩慢累積職等。當你腳下的領域不動時，這樣做是合理的。但現在，這個領域對每個人的變動速度都一樣。一個 22 歲、公開展示 Agent 原型的人，與一個 35 歲的資深工程師之間的差距，不再是十年累積的技術棧掌握度。22 歲的年輕人和資深工程師擁有同樣的空白畫布，對他們兩人來說，能產生複利效應的是願意交付的態度，加上那一小部分不會在一季內過時的核心元件。

這就是整篇文章的重新框架。接下來是一種思考方式，幫助你判斷哪些核心元件值得你關注，哪些產品發布可以忽略。挑選適合你的，放下不適合的。

真正有效的篩選器

你無法跟上每週的發布。你也不該嘗試。你需要的是篩選器，而不是資訊流。

過去 18 個月來，有五項測試經得起考驗。在讓一個發布影響你的技術棧之前，先用它們來檢驗。

這件事兩年後還重要嗎？ 如果它只是一個前沿模型的包裝、一個 CLI 參數、或「Devin 但針對 X」，答案幾乎總是否定的。如果它是一個核心元件（一種協定、一種記憶模式、一種沙箱方法），答案則更可能是肯定的。包裝的半衰期很短。核心元件的半衰期則是以年計算。

有你尊敬的人用它建構了真實的東西，並誠實地寫下來了嗎？ 行銷貼文不算數。事後檢討報告才算。一篇名為「我們在生產環境中嘗試了 X，這是出錯的地方」的部落格文章，價值相當於十篇產品發布公告。這個領域中好的訊號，總是來自那些為此犧牲過一個週末的人。

採用它是否要求你拋棄你的追蹤、重試、設定、認證？ 如果是，它就是一個試圖成為平台的框架。試圖成為平台的框架，死亡率高達 90%。好的核心元件能融入你現有的系統，而不會強迫你進行遷移。

跳過它六個月，你要付出什麼代價？ 對大多數發布來說，答案是零。六個月後你會知道更多。勝出的版本會更清晰。這項測試能讓你在沒有焦慮的情況下跳過 90% 的發布，而這也是大多數人拒絕執行的測試，因為跳過感覺就像落後。但事實並非如此。

你能衡量它是否真的幫助了你的 Agent 嗎？ 如果不能，你就是在猜測。沒有評估的團隊靠感覺運作，並推送有回歸問題的版本。有評估的團隊則能讓數據告訴他們，本週 GPT-5.5 或 Opus 4.7 在他們的特定工作負載上哪個表現更好。

如果你要從整篇文章中養成一個習慣，那就是這個：當有新東西發布時，寫下你需要在六個月後看到什麼，才能相信它很重要。然後回來檢查。大多數時候，問題會自行解答，而你的注意力會花在那些能產生複利的事情上。

這些測試背後的核心技能，比任何一項測試都更難命名。那就是對你沒有選擇的東西，甘於「不酷」的意願。本週在 Hacker News 上爆紅的框架，會在十四天內擁有一群啦啦隊，他們聽起來都很聰明。六個月後，其中一半的框架已無人維護，啦啦隊也轉移陣地。那些沒有參與的人，把注意力留給了那些在發布熱潮過後，經得起「無聊」考驗的事物。這種姿態——忍住、觀察、說「我六個月後再判斷」——才是這個領域真正的專業技能。每個人都能閱讀發布公告。但幾乎沒有人擅長不對它們做出反應。

該學什麼

概念。模式。事物的形狀。這些是能帶來複利回報的想法。它們能經得起模型更換、框架更換、範式轉移。深入理解它們，你就能在一個週末內掌握任何新工具。跳過它們，你就會永遠在重新學習表面的機制。

情境工程

過去兩年最重要的重新命名，就是「提示工程」變成了「情境工程」。這個轉變是真實的，不僅僅是表面功夫。

模型不再是你為其設計巧妙指令的東西。而是你在每一步為其組裝工作情境的東西。這個情境同時包含系統指令、工具架構、檢索到的文件、先前的工具輸出、暫存區狀態和壓縮後的歷史記錄。Agent 的行為是你放入視窗中的內容所產生的湧現特性。

請將此內化：情境就是狀態。每一點不相關的雜訊都會損害你的推理品質。情境腐化是真實的生產環境故障。在一個十步驟任務的第八步，原始目標可能已被工具輸出淹沒。那些能交付可靠 Agent 的團隊，會主動進行摘要、壓縮、修剪。他們會對工具描述進行版本控制。他們會快取靜態部分，並拒絕快取會變化的部分。他們思考上下文視窗的方式，就像經驗豐富的工程師思考 RAM 一樣。

一個具體的感受方式：拿起任何一個生產環境中的 Agent，開啟完整的追蹤日誌。看看第一步的情境。再看看第七步的情境。數數有多少 token 仍然在發揮作用。你第一次這樣做時，會感到尷尬。然後你會去修復它，同一個 Agent 在沒有改變模型或提示的情況下，就會變得明顯更可靠。

如果你要讀一篇相關文章，請讀 Anthropic 的「Effective Context Engineering for AI Agents」。然後讀他們的多 Agent 研究事後檢討報告，其中用數據說明了當規模擴大時，情境隔離有多重要。

工具設計

工具是 Agent 與你的業務接軌的地方。模型根據名稱和描述來選擇工具。模型根據錯誤訊息來重試。模型的成功或失敗，取決於工具的合約是否符合 LLM 擅長表達的內容。

五到十個命名良好的工具，勝過二十個平庸的工具。工具名稱應該讀起來像英文動詞片語。描述應該包含何時使用該工具以及何時不使用。錯誤訊息應該是模型可以據以行動的回饋。「超過 500 token 上限，請先嘗試摘要」遠遠勝過「錯誤：400 錯誤請求」。一個公開研究團隊報告指出，僅改寫錯誤訊息後，重試循環就減少了 40%。

Anthropic 的「Writing tools for agents」是正確的起點。之後，為你自己的工具進行檢測，並查看實際的呼叫模式。Agent 可靠性的最大提升幾乎都來自工具端。人們不斷調整提示，卻忽略了真正槓桿所在的地方。

協調器-子 Agent 模式

2024 和 2025 年的多 Agent 辯論，最終以一個現在大家都採用的綜合方案告終。天真的多 Agent 系統，多個 Agent 並行寫入共享狀態，會因為錯誤疊加而災難性地失敗。單 Agent 循環的可擴展性遠超你的預期。有一種多 Agent 形態在生產環境中有效：一個協調器 Agent 將範圍狹窄的唯讀任務委派給隔離的子 Agent，然後綜合它們的結果。

這就是 Anthropic 研究系統的運作方式。這也是 Claude Code 的子 Agent 的運作方式。這是 Spring AI 和大多數生產框架現在標準化的模式。子 Agent 獲得小而專注的情境。它們不能改變共享狀態。協調器擁有寫入權。

Cognition 的「Don't Build Multi-Agents」文章和 Anthropic 的「How we built our multi-agent research system」看起來是對立的，但實際上是用不同的詞彙表達同一件事。兩篇都讀。

預設使用單 Agent。只有在單 Agent 遇到真正的瓶頸時，才考慮使用協調器-子 Agent 模式：上下文視窗壓力、順序工具呼叫造成的延遲，或任務異質性確實需要專注的情境。在感受到痛苦之前就建構這個，只會帶來你不需要的複雜性。

評估與黃金數據集

每個能交付可靠 Agent 的團隊都有評估。沒有評估的團隊則沒有。這是這個領域中槓桿率最高的習慣，也是我在看過的所有公司中，看到投資最少的事情。

有效的方法是：收集你的生產環境追蹤記錄，標記失敗案例，將其視為回歸測試集。每當有新的失敗案例出現時，就加入其中。對於主觀部分使用 LLM 作為評判，其餘部分使用精確匹配或程式化檢查。在任何提示、模型或工具變更之前，執行這個測試套件。Spotify 的工程部落格報告說，他們的評判層在 Agent 輸出交付前，會否決大約 25% 的內容。如果沒有它，每四個不良結果中就有一個會到達用戶手中。

讓這個概念深入人心的心智模型是：評估就像一個單元測試，在一切其他事物都在變化時，讓 Agent 保持誠實。模型獲得新版本。框架發布破壞性變更。供應商棄用某個端點。你的評估是唯一能告訴你 Agent 是否仍在正常運作的東西。沒有它們，你就是在撰寫一個正確性取決於移動目標善意的系統。

評估框架（Braintrust、Langfuse evals、LangSmith）都很好。但它們都不是瓶頸。瓶頸在於首先擁有一個標記好的數據集。在第一天就建立它，在你擴展任何東西之前。前五十個範例可以在一個下午內手動標記。沒有任何藉口。

檔案系統即狀態與思考-行動-觀察循環

對於任何執行真正多步驟工作的 Agent 來說，持久的架構是：思考、行動、觀察、重複。以檔案系統或結構化儲存作為事實來源。每個動作都被記錄且可重播。Claude Code、Cursor、Devin、Aider、OpenHands、goose。它們都因為同一個原因而收斂於此。

模型是無狀態的。框架必須是有狀態的。檔案系統是每個開發者都已經理解的狀態化核心元件。一旦你接受這個框架，整個框架紀律（檢查點、可恢復性、子 Agent 驗證、沙箱執行）就會從認真對待這個模式中衍生出來。

更深層次的是，這教會你：在任何值得其運算費用的生產 Agent 中，框架所做的工作比模型更多。模型選擇下一個動作。框架驗證它、在沙箱中執行它、擷取輸出、決定回饋什麼、決定何時停止、決定何時建立檢查點、決定何時產生子 Agent。將模型換成另一個品質相似的模型，一個好的框架仍然能正常運作。將框架換成一個更差的，即使使用世界上最好的模型，產出的 Agent 仍然會隨機忘記它在做什麼。

如果你正在建構任何比單次工具呼叫更複雜的東西，框架就是你應該花時間的地方。模型只是其中的一個元件。

MCP，概念上

不要只學習如何呼叫 MCP 伺服器。要學習這個模型。Agent 能力、工具和資源之間有清晰的區隔，底下有可擴展的認證和傳輸層。一旦你理解了它，你看到的每個其他「Agent 整合框架」都會看起來像 MCP 的劣化版，你就能省下評估每個框架的時間。

Linux 基金會現在負責管理它。每個主要模型供應商都支持它。「AI 界的 USB-C」這個比喻現在比諷刺更準確。

沙箱作為核心元件

每個生產環境中的程式碼 Agent 都在沙箱中運行。每個瀏覽器 Agent 都曾遭受間接提示注入攻擊。每個多租戶 Agent 在某個時候都曾出現權限範圍錯誤。將沙箱視為核心基礎設施，而不是在客戶要求時才添加的功能。

學習基礎知識。程序隔離。網路出口控制。機密範圍界定。Agent 和工具之間的認證邊界。那些在客戶安全審查後才補上這個的團隊，就是會失去訂單的團隊。那些從第一週就內建它的團隊，可以在不緊張的情況下通過企業採購流程。

該用什麼來建構

具體的選擇，2026 年 4 月。這些會變化，但速度緩慢。在這裡要選擇無趣的。

協調

LangGraph 是生產環境的預設選擇。大約三分之一使用 Agent 的大型公司都在使用它。它的抽象概念與 Agent 系統的真實形態相符：型別狀態、條件邊緣、持久化工作流程、人機互動檢查點。缺點是冗長。優點是，這種冗長與 Agent 進入生產環境後你實際需要控制的東西相符。

如果你使用 TypeScript，Mastra 是事實上的選擇。該生態系統中最清晰的思維模型。

如果你的團隊喜歡 Pydantic 並希望型別安全成為一級公民，Pydantic AI 是一個合理的全新選擇。它在 2025 年底達到 v1.0，而且動能是真實的。

對於供應商原生工作（電腦使用、語音、即時），請在你的 LangGraph 節點內部使用 Claude Agent SDK 或 OpenAI Agents SDK。不要試圖讓其中任何一個成為異質系統的頂層協調器。它們是針對其特定領域最佳化的。

協定層

MCP，就是它。將你的工具整合建構為 MCP 伺服器。以同樣的方式使用外部整合。註冊表已經超過了某個臨界點，你幾乎總能在需要建構之前找到一個伺服器。在 2026 年編寫自訂的工具管道，只會白白付出代價。

記憶

根據自主程度來選擇，而不是根據炒作。

Mem0 用於聊天風格的個人化。用戶偏好、輕量歷史記錄。Zep 用於生產環境中的對話系統，其中狀態會演化，你需要實體追蹤。Letta 用於 Agent 需要在數天或數週的工作中維持連貫性的情況。大多數團隊不需要這個。需要的團隊，則確實需要這個。

錯誤在於在遇到記憶問題之前就使用記憶框架。從你的上下文視窗能容納的內容加上一個向量儲存開始。只有當你能清楚說明它解決的故障模式時，才添加記憶系統。

可觀測性與評估

Langfuse 是開源預設選擇。可自託管、MIT 授權、涵蓋追蹤、提示版本控制和基本的 LLM 作為評判評估。如果你已經是 LangChain 的使用者，LangSmith 整合得更緊密。Braintrust 是研究型評估工作流程的正確選擇，需要嚴格的比較。如果你需要在多語言技術棧中使用供應商中立的 OpenTelemetry 檢測，OpenLLMetry / Traceloop 就是答案。

你需要追蹤和評估兩者。追蹤回答「Agent 實際做了什麼？」評估回答「Agent 比昨天更好還是更差？」不要在不具備兩者的情況下交付。盲目運行的成本，是第一天就正確配置這個的成本的十倍。

運行時與沙箱

E2B 用於一般的沙箱程式碼執行。Browserbase（與 Stagehand 搭配）用於瀏覽器自動化。Anthropic Computer Use 用於需要真實作業系統層級桌面控制的情況。Modal 用於短暫的爆發性工作。絕對不要執行未經沙箱處理的程式碼。一個被注入提示的 Agent 在你的生產環境中造成的影響範圍，是你不想面對的故事。

模型

基準測試的追逐令人筋疲力盡，而且基本上沒有幫助。實際上，在 2026 年 4 月：

Claude Opus 4.7 和 Sonnet 4.6 用於可靠的工具使用、多步驟連貫性和優雅的故障恢復。Sonnet 是大多數工作負載的成本效能最佳點。GPT-5.4 和 5.5 在你需要最強的 CLI/終端機推理能力或你使用 OpenAI 基礎設施時使用。Gemini 2.5 和 3 用於長上下文或大量多模態任務。DeepSeek-V3.2 或 Qwen 3.6 在成本比頂尖效能更重要時使用，特別是對於狹義、定義明確的任務。

將模型視為可互換的。如果你的 Agent 只適用於一個模型，那是一個警訊，而不是護城河。使用評估來決定部署什麼。每季重新評估一次，而不是每週。

該跳過什麼

你會被告知要學習並使用所有這些東西。你不需要。跳過的成本很低。省下的時間很多。

用於生產環境的 AutoGen 和 AG2。 Microsoft 的框架已轉為社群維護，發布停滯，抽象概念不符合生產團隊的實際需求。適合學術探索。不要將產品建立在它之上。

用於新生產環境建置的 CrewAI。 它無所不在，因為它很容易展示原型。建構真實系統的工程師已經不再使用它。如果你想要，可以用它來做原型。不要對它做出承諾。

Microsoft Semantic Kernel，除非你被鎖定在 Microsoft 企業技術棧中，而且你的買家在乎這一點。這不是生態系統發展的方向。

DSPy，除非你特別是在大規模最佳化提示程式。有哲學價值，但受眾狹窄。不是一個通用的 Agent 框架。不要把它當作一個來選擇。

將獨立的程式碼編寫 Agent 作為你的架構選擇。 程式碼即動作是很有趣的研究。但它還不是一個生產環境的預設模式，你會遇到你的競爭對手沒有的工具和安全問題。

「自主 Agent」的宣傳。 AutoGPT 和 BabyAGI 的產品形式已經死亡。業界達成的誠實框架是「Agent 工程」：受監督、有邊界、經過評估。在 2026 年還在推銷部署後就不管的自主 Agent 的人，是在推銷 2023 年的東西。

Agent 應用程式商店和市集。 從 2023 年就開始承諾，但從未獲得企業採用。企業不購買通用的預建 Agent。他們購買與成果相關的垂直 Agent，或者自己建構。不要圍繞應用程式商店的夢想來建構你的業務。

作為客戶的橫向「建構任何 Agent」企業平台（Google Agentspace、AWS Bedrock Agents、Microsoft Copilot Studio 層級）。它們最終會有用。現在它們令人困惑、出貨緩慢，而且購買與建構的數學計算仍然傾向於你自己建構狹義的 Agent 或購買垂直的 Agent。Salesforce Agentforce 和 ServiceNow Now Assist 是例外，因為它們透過嵌入你已經使用的工作流程系統而獲勝。

追逐 SWE-bench 和 OSWorld 排行榜。 Berkeley 的研究人員在 2025 年記錄到，幾乎每個公開基準測試都可以在不解決底層任務的情況下被鑽漏洞。團隊現在使用 Terminal-Bench 2.0 和自己的內部評估作為真正的訊號。預設對單一數字的基準測試飛躍持懷疑態度。

天真的並行多 Agent 架構。 五個 Agent 透過共享記憶體聊天在演示中看起來令人印象深刻，但在生產環境中會崩潰。如果你無法在餐巾紙上畫出一個帶有讀/寫邊界的清晰協調器-子 Agent 圖表，就不要交付它。

新 Agent 產品的按席位 SaaS 定價。 市場已轉向基於成果和用量。按席位定價會留下金錢在桌上，並向買家發出訊號，表示你不信任自己的產品能交付成果。

本週你在 Hacker News 上看到的下一個框架。 等六個月。如果它仍然重要，它會很明顯。如果它不重要，你就省了一次遷移。

如何實際行動

如果你想採用 Agent，而不只是跟上它們，這個順序有效。它很無聊。但它有效。

選擇一個已經很重要的成果。 不是一個登月計畫。不是一個橫向的「Agent 平台」專案。一些你的業務已經關心的、可衡量的東西。處理支援工單。起草初稿法律審查。篩選潛在客戶。生成月度報告。當那個成果有所進展時，Agent 就成功了。這在第一天就成為你的評估目標。

這個步驟比任何其他步驟都重要的原因是，它限制了後續的每一個決定。有了具體的成果，「該選哪個框架」的問題就不再是哲學問題。你選擇能最快交付你成果的那個。「該選哪個模型」的問題不再是基準測試的爭論。你選擇你的評估顯示在這個特定工作上表現最好的那個。「我們需要記憶體 / 子 Agent / 自訂框架嗎？」的問題不再是思想實驗。你只添加你的特定故障模式所需的東西。跳過這個步驟的團隊，最終會建構出沒人要求的橫向平台。認真對待這個步驟的團隊，最終會交付一個單一狹義的 Agent，它能在一個季度內回本，而這個單一交付的 Agent 教會他們的東西，比兩年的閱讀還要多。

在交付任何東西之前，先設定好追蹤和評估。 選擇 Langfuse 或 LangSmith。連接起來。如果必要的話，手動建立一個小的黃金數據集。五十個標記範例就足夠開始。你無法改善你無法衡量的東西。以後再建構這個的成本，大約是現在建構它的成本的 10 倍。

從單 Agent 循環開始。 選擇 LangGraph 或 Pydantic AI。選擇 Claude Sonnet 4.6 或 GPT-5 作為模型。給 Agent 三到七個設計良好的工具。給它檔案系統或資料庫作為狀態。交付給一小群用戶。觀察追蹤記錄。

將 Agent 視為產品，而不是專案。 它會以你無法預測的方式失敗。那些失敗就是你的路線圖。從真實的生產環境追蹤記錄中建立回歸測試集。每次提示變更、每次模型更換、每次工具變更，在部署前都要通過評估。這是大多數團隊投資不足的地方。這也是大多數可靠性來源的地方。

只有在你贏得了擴展範圍的權利時，才增加範圍。 當上下文成為瓶頸時，才引入子 Agent。當單一視窗的上下文無法容納你需要的內容時，才引入記憶框架。當底層 API 真的不存在時，才引入電腦使用或瀏覽器使用。不要預先設計這些架構。讓故障模式把它們拉進來。

選擇無趣的基礎設施。 MCP 用於工具。E2B 或 Browserbase 用於沙箱。Postgres 或你已經在運行的任何資料儲存用於狀態。你現有的認證和可觀測性技術棧。奇特的基礎設施很少是致勝關鍵。紀律才是。

從第一天起關注你的單位經濟效益。 每次動作的成本。快取命中率。重試循環成本。模型呼叫分佈。Agent 在概念驗證階段看起來很便宜，但在 100 倍規模下會爆炸，除非你從一開始就衡量每次成果的成本。一個每次運行 0.50 美元的概念驗證，在中等規模下會變成每月 5 萬美元。沒有預見這一點的團隊，會迎來一場他們不喜歡的 CFO 會議。

每季重新評估模型，而不是每週。 鎖定一個季度。在季度結束時，針對當前的前沿模型運行你的評估套件，如果數據顯示應該更換，就更換。你既能獲得模型改進的好處，又不必追逐每次發布所帶來的混亂。

解讀潮流

具體的跡象表明某件事是訊號：

一個備受尊敬的工程團隊會用數據而非單純的採用宣稱來撰寫事後檢討報告。它是基礎元件（協定、模式、基礎設施），而非包裝或套件。它能與你現有運行的系統互通，而非取代它們。它的訴求描述的是它解決的失敗模式，而非它啟用的能力。它存在的時間夠長，足以讓人寫出「什麼沒用」的部落格文章。

以下是判斷某事物為雜訊的具體跡象：

上線三十天後仍只有展示影片，沒有實際生產案例。基準測試的躍進幅度過於完美，不像是真的。使用「自主」、「Agent OS」或「建構任何 Agent」等詞彙卻未加說明的宣傳。框架文件假設你會拋棄現有的追蹤、驗證和設定。星星數快速增長，但提交次數、版本發佈和貢獻者人數卻未同步增長。Twitter 聲量高，但 GitHub 活躍度低。

一個有用的每週習慣：在星期五保留三十分鐘關注這個領域。閱讀三樣東西：Anthropic 的工程部落格、Simon Willison 的筆記、Latent Space。如果有新的事後檢討報告，快速瀏覽一兩篇。這週其他東西都跳過。你會知道哪些才是真正重要的事。

值得關注的事

未來兩季值得關注的事項，不是因為它們保證成功，而是因為「這是訊號嗎？」這個問題尚未完全明朗：

Replit Agent 4 的平行分叉模型。 第一個認真嘗試「多個 Agent 平行運作」且不會在共享狀態上出錯的方案。如果它在規模化時能站穩腳跟，協調器-子 Agent 的預設模式可能會改變。

基於成果的定價模式成熟度。 Sierra 和 Harvey 的收入軌跡在狹窄的垂直領域內驗證了這個模式。問題在於它能否推廣到其他領域，還是只會停留在垂直專用模式。

技能作為包裝層。 GitHub 上 AGENTS.md 和技能目錄的激增，顯示出一種新興的包裝 Agent 能力的方式。它能否像 MCP 對工具所做的那樣標準化，仍是個開放問題。

Claude Code 2026 年 4 月的品質衰退及其事後檢討。 一個業界領先的 Agent 出現了 47% 的效能衰退，而且是被用戶發現，而非內部監控系統。這說明了生產環境中的 Agent 評估實務有多不成熟，即使是在領導者身上也是如此。如果這能推動整個產業投資更好的線上評估，那麼這次修正就是健康的。

語音成為預設支援介面。 Sierra 的語音頻道在 2025 年底超越了文字。如果這個模式在其他垂直領域也成立，那麼設計限制（延遲、中斷、即時工具使用）就會成為首要考量，許多現有架構都需要重新設計。

開放模型 Agent 能力正在縮小差距。 DeepSeek-V3.2 將原生思考整合到工具使用中。Qwen 3.6。更廣泛的開放生態系。狹義 Agent 任務的成本效能正在轉變。封閉原始碼的預設地位並非永久。

以上每一項都有一個明確的「六個月後我需要看到什麼才能相信它」的答案。這就是考驗。追蹤答案，而不是追蹤公告。

非傳統的賭注

你沒有採用的每個框架，都是一筆你不需要承擔的遷移成本。你沒有追逐的每個基準測試，都是一季你可以保留的專注力。在這個週期中勝出的公司（Sierra、Harvey、Cursor 在各自的領域）選擇了狹窄的目標，建立了無聊的紀律，並讓領域中的雜訊從身邊流過。

傳統的路徑是：選擇一個技術棧，精通它多年，爬升階梯。當技術棧穩定十年時，這套方法行得通。但現在技術棧每季都在變。勝出的人不再優化技術棧精通，而是開始優化品味、基礎元件和出貨速度。他們公開地打造小東西。他們透過出貨來學習。他們因為已經做出的成果而被邀請進入會議室。憑證就是成品。

好好思考這一點，因為這才是整篇文章的重點。我們大多數人都是在一個假設世界靜止不動、讓憑證可以累積的工作模式下長大的。你去上學。你拿到學位。你爬升階梯。這裡兩年，那裡三年，慢慢地履歷變成了能打開大門的東西。整個機制假設另一邊是一個穩定的產業。

但 Agent 領域目前沒有穩定的另一邊。你可能想為之工作的公司才成立六個月。它們所基於的框架才十八個月大。底層的協定才兩年。這個領域中被引用最多的文章，有一半是三年前還不在這個領域的人寫的。沒有階梯可以爬，因為建築物一直在改變樓層。當階梯不管用時，剩下的是更古老的方法：做出一個東西，放到網路上，讓作品來介紹你。這條路非傳統，因為它忽略了憑證系統。但它也是在一個變動的領域中唯一能累積的方法。

這就是這個時代從內部看起來的樣子。即使是巨頭也在公開迭代、出貨衰退、撰寫事後檢討、即時修補。今年出貨最有趣東西的團隊中，包括十八個月前還不在這個領域的人。非程式設計師正在與 Agent 配對，出貨真正的軟體。博士們正在被那些選對了基礎元件並開始行動的建造者超越。大門是敞開的。但大多數人仍在試圖尋找申請表。

你現在真正需要發展的技能不是「Agent」。而是在一個表面不斷變化的領域中，判斷哪些工作能累積的紀律。情境工程能累積。工具設計能累積。協調器-子 Agent 模式能累積。評估紀律能累積。駕馭心態能累積。知道星期二推出的框架的 API 則不能。一旦你能區分這些，每週的發布潮就不再像是壓力，而像是你可以忽略的雜訊。

你不需要學會一切。你需要學會那些能累積的東西，跳過那些不能的。選擇一個成果。在出貨前先設定好追蹤和評估。使用 LangGraph 或你團隊的等效工具。使用 MCP。沙盒化你的執行環境。預設使用單一 Agent。當失敗模式引入時才增加範圍。每季重新評估模型。星期五閱讀三樣東西。

這就是劇本。剩下的就是品味、出貨速度，以及不追逐無關緊要事物的耐心。打造東西。把它們放到網路上。這個時代獎勵那些做出東西的人，勝過那些能描述東西的人。從來沒有比現在更好的窗口，讓你成為那個做出東西的人。