原文標題：AI 代理人（2026 年）應學習、構建和略過的內容
原文作者：Rohit
編譯：Peggy，BlockBeats

編者備注：AI 代理人領域正進入工具爆炸、共識不足的階段。

每周都有新框架、新模型、新基準和新的「10 倍效率」產品出現，但真正重要的問題，已經不是「如何跟上所有變化」，而是「哪些變化真的值得投入」。

作者認為，在技術棧不斷被重寫的當下，真正能長期複利的不是追逐最新框架，而是更底層的能力：context engineering、工具設計、eval 体系、orchestrator-subagent 模式、沙盒與 harness 思維。這些能力不會隨著模型換代迅速失效，反而會成為構建可靠 AI 代理人的基礎。

文章更進一步指出，AI 代理人也在改變「資歷」的含義。過去，學歷、職級和年限是進入行業的通行證；但在一個連巨頭都還在公開試錯的領域裡，簡歷不再是唯一憑證。你做出了什麼、交付了什麼，正在變得更重要。

因此，本文不只是討論 2026 年 AI 代理人該學什麼、用什麼、跳過什麼，更是在提醒：在噪音越來越多的時代，最稀缺的能力，是判斷什麼值得學，並持續做出真正有用的東西。

以下為原文：

每天都會冒出一個新框架、一個新基準、一個新的「10 倍效率」產品。問題不再是「我該怎麼跟上」，而是：這裡面到底什麼是真信號，什麼只是披著緊迫感外衣的噪音。

每一份路線圖，發布一個月後就可能過時。你上個季度剛掌握的框架，現在已經成了舊東西。你曾為之優化的基準，被人刷穿之後很快又被新的取代。過去，我們被訓練成沿著一條傳統路徑前進：一個技術棧，對應一組主題和層級；一串工作經歷，對應年限和頭銜；一步一步緩慢往上爬。但 AI 改寫了這張畫布。今天，只要提示詞用得對、審美判斷足夠好，一個人就能交付過去需要一名有兩年經驗的工程師花一個 sprint 才能完成的工作。

專業能力依然重要。沒有什麼可以替代你親眼見過系統崩潰，凌晨兩點調過內存洩漏，也沒有什麼能替代你曾經力排眾議選擇一個無聊但正確的方案，並最終被證明是對的。這樣的判斷力會複利增長。但不再像過去那樣複利增長的，是你對「本週熱門框架 API 表面」的熟悉程度。六個月後，它可能又變了。兩年後真正勝出的人，是那些早早選中耐用基礎能力，並讓其他噪音從身邊經過的人。

過去兩年，我一直在這個領域構建產品，拿到過多個年薪 25 萬美元以上的 offer，現在在一家隱身公司負責技術。如果有人問我：「現在到底應該關注什麼？」這就是我會發給他的內容。

這不是一張路線圖。Agent 領域還沒有明確目的地。大廠實驗室也在公開迭代，把回歸問題直接推給數百萬用戶，再寫複盤、在線修補。如果 Claude Code 背後的團隊都能發布一個造成 47% 效能回退的版本，而且直到用戶社區發現後才意識到問題，那麼所謂「底下存在一張穩定地圖」的想法就是虛構的。所有人都還在摸索。創業公司之所以有機會，正是因為巨頭也不知道答案。不會寫程式碼的人正在和 agent 搭檔，在週五交付一些週二還被機器學習博士認為不可能的東西。

這個時刻最有趣的一點，是它改變了我們對「資歷」的理解。傳統路徑優化的是資歷：學位、初級職位、高級職位、資深職位，以及緩慢積累起來的職級。這在底層領域不發生劇烈變化時是合理的。但現在，腳下的地面正在以同樣的速度從所有人腳下移動。一個 22 歲、公開發布 agent demo 的年輕人，和一個 35 歲的資深工程師之間的差距，不再只是十年技術棧熟練度的積累。這個 22 歲的人和資深工程師面對的是同一張空白畫布。對他們來說，真正會複利增長的是持續交付的意願，以及那一小部分不會在一個季度內過時的基礎能力。

這就是整篇文章的核心重構。接下來，我會提供一種判斷方式：哪些基礎能力值得你投入注意力，哪些發布可以直接讓它過去。適合你的就拿走，不適合的就放下。

真正有效的過濾器

你不可能跟上每週的新發布，也不應該這麼做。你需要的不是信息流，而是過濾器。

過去 18 個月裡，有五個測試一直有效。在讓某個新東西進入你的技術棧之前，先用這五個問題過一遍。

兩年後它還重要嗎？
如果它只是某個前沿模型外面套的一層殼、一個 CLI 參數，或者「某某版 Devin」，答案幾乎總是否定的。如果它是一個基礎原語，比如協議、記憶模式、沙盒方法，答案就更可能是肯定的。套殼產品的半衰期很短，基礎原語的半衰期可以按年計算。

有沒有你尊重的人，已經基於它做出了真實產品，並且誠實寫過經驗？
營銷文章不算，複盤文章才算。一篇題為「我們在生產環境裡試了 X，結果這裡出問題了」的部落格，比十篇發布公告更有價值。這個領域裡真正有用的信號，永遠來自那些為此失去過一個週末的人。

採用它，是否意味著你要丟掉現有的 tracing、重試機制、配置、認證系統？
如果是，那它就是一個試圖把自己做成平台的框架。試圖成為平台的框架，死亡率大約有 90%。好的基礎原語，應該能嵌入你現有系統，而不是逼你遷移。

如果你跳過它六個月，代價是什麼？
對大多數發布來說，答案是什麼都沒有。六個月後你會知道更多，勝出的版本也會更清楚。這一條測試，可以讓你毫無焦慮地跳過 90% 的發布。但也是最多人拒絕使用的一條，因為跳過某個東西會讓人感覺自己落後了。實際上並不是。

你能否衡量它是否真的讓你的 agent 變好了？
如果不能，那你只是在猜。沒有 eval 的團隊靠感覺運行，最終會把回歸問題發到線上。有 eval 的團隊，則可以讓數據告訴自己：在本周這個具體工作負載上，到底是 GPT-5.5 更好，還是 Opus 4.7 更好。

如果你只從這篇文章裡帶走一個習慣，那就是：每當一個新東西發布時，寫下你需要在六個月後看到什麼，才會相信它真的重要。然後六個月後回來檢查。大多數時候，問題自己已經給出了答案，而你的注意力也會被用在那些真正能複利增長的事情上。

這些測試背後真正的能力，比任何一條測試都更難命名。它是一種願意「不趕時髦」的能力。這個星期在 Hacker News 爆火的框架，會在十四天內擁有一支啦啦隊，他們聽起來都會很聰明。但六個月後，其中一半框架已經無人維護，那些啦啦隊也早已轉向下一個熱點。沒有參與其中的人，把注意力省下來，留給那些在發布熱潮過去後依然經受住「變得無聊」考驗的東西。克制、觀望、說一句「六個月後我就知道了」，才是這個領域真正的職業技能。所有人都會讀發布公告，但幾乎沒人擅長不對它們做反應。

該學什麼

概念、模式、事物的形狀。真正帶來複利回報的是這些東西。它們能穿越模型替換、框架替換和範式轉移。深刻理解它們，你就能在一個週末內上手任何新工具。跳過它們，你就會永遠在重新學習表層機制。

Context Engineering

過去兩年裡，最重要的一次改名，是「Prompt Engineering」變成了「Context Engineering」。這個變化是真的，不只是換個說法。

模型不再是一個你給它寫一條聰明指令的東西。它變成了一個你需要在每一步為其組裝可工作上下文的東西。這個上下文同時包含系統指令、工具 schema、檢索到的文檔、之前的工具輸出、scratchpad 狀態，以及壓縮後的歷史記錄。Agent 的行為，是你放進上下文視窗裡的所有內容共同湧現出來的結果。

你需要內化這一點：上下文就是狀態。每一個無關 token 都會消耗推理質量。上下文腐爛，是一種真實的生產故障。到一個十步任務的第八步時，最初目標可能已經被工具輸出埋掉了。能交付可靠 agent 的團隊，會主動總結、壓縮、裁剪上下文。他們會給工具描述做版本管理，會緩存靜態部分，也會拒絕緩存會變化的部分。他們看待上下文視窗的方式，就像一個有經驗的工程師看待內存。

一個具體的感受方式是：拿任意一個生產環境裡的 agent，打開完整 trace 日誌。看看第一步時的上下文，再看看第七步時的上下文。數一數還有多少 token 仍然在發揮作用。第一次做這件事時，你大概率會感到尷尬。然後你會去修它，而同一個 agent 會在不更換模型、不改 prompt 的情況下，明顯變得更可靠。

如果你只讀一篇相關內容，就讀 Anthropic 的《Effective Context Engineering for AI Agents》。然後再讀他們關於多 agent 研究系統的複盤，那篇文章用數字說明了當系統規模擴大後，上下文隔離有多重要。

工具設計

工具是 agent 與你的業務發生接觸的地方。模型會根據工具名稱和描述來選擇工具，會根據錯誤信息來決定如何重試。工具的契約是否符合 LLM 擅長表達的方式，決定了模型是成功還是失敗。

五到十個命名良好的工具，勝過二十個平庸的工具。工具名稱應該像自然英文裡的動詞片語。描述應該寫清楚什麼時候該用，什麼時候不該用。錯誤訊息應該是模型可以據此行動的反饋。「超過 500 個 token 上限，請先總結再嘗試」遠勝於「Error: 400 Bad Request」。公開研究中有一個團隊報告稱，他們僅僅重寫錯誤訊息，就讓重試迴圈減少了 40%。

Anthropic 的《Writing tools for agents》是很好的起點。讀完之後，給你自己的工具加上觀測，看看真實呼叫模式。Agent 可靠性最大的提升，幾乎總是發生在工具側。很多人不斷調 prompt，卻忽視了真正槓桿所在的位置。

Orchestrator-Subagent 模式

2024 年和 2025 年關於多 agent 的爭論，最終收斂成了一個如今大家都在採用的綜合方案。天真的多 agent 系統，也就是多個 agent 並行寫入共享狀態的系統，會災難性失敗，因為錯誤會不斷複合。單 agent 迴圈能擴展到的程度，往往比你想象中更遠。真正能在生產環境裡工作的多 agent 形態只有一種：一個 orchestrator agent，把範圍狹窄、只讀的任務委派給隔離的 subagent，然後再綜合它們的結果。

Anthropic 的研究系統是這樣工作的。Claude Code 的 subagents 也是這樣工作的。Spring AI 和多數生產框架現在也在標準化這一模式。Subagent 擁有小而聚焦的上下文，不能修改共享狀態。寫入由 orchestrator 負責。

Cognition 的《Don't Build Multi-Agents》和 Anthropic 的《How we built our multi-agent research system》看起來像是相反觀點，但其實只是用不同詞彙在說同一件事。兩篇都值得讀。

默認使用單 agent。只有當單 agent 確實撞到真實邊界時，再考慮 orchestrator-subagent：比如上下文視窗壓力、順序工具呼叫帶來的延遲，或者任務異質性確實能從聚焦上下文中獲益。在還沒有感受到痛點之前就構建這套東西，只會交付你並不需要的複雜性。

Evals 與黃金資料集

每一個能夠交付可靠 agent 的團隊都有 eval。沒有 eval 的團隊，通常也交付不出可靠 agent。這是這個領域槓桿最高的習慣，也是我在每家公司裡看到的最被低估的事情。

有效做法是：收集生產環境 trace，標註失敗案例，把它們當作回歸集。每當新的失敗上線，就把它加進去。主觀部分使用 LLM-as-judge，其他部分使用精確匹配或程序化檢查。在任何 prompt、模型或工具變更之前，都跑一遍測試套件。Spotify 工程部落格報告稱，他們的 judge 層會在輸出上線前攔下大約 25% 的 agent 輸出。如果沒有它，每四個壞結果中就會有一倵抵達用戶面前。

讓這件事真正紮根的心智模型是：eval 就是一個單元測試，用來在其他所有東西都不斷變化時，確保 agent 沒有偏離職責。模型會出新版本，框架會發布破壞性變更，供應商會廢棄某個端點。你的 eval 是唯一能告訴你 agent 是否還在正常工作的東西。沒有 eval，你就在寫一個正確性取決於移動目標善意的系統。

Eval 框架，比如 Braintrust、Langfuse evals、LangSmith，都還不錯。但它們都不是瓶頸。真正的瓶頸，是你首先有沒有一個已標註的資料集。第一天就該開始做，在擴展任何東西之前就做。最初的 50 個樣本，一個下午就能手工標完。沒有藉口。

把檔案系統當作狀態，以及 Think-Act-Observe 循環

對於任何執行真實多步驟工作的 agent 來說，耐用的架構都是：思考、行動、觀察、重複。檔案系統或結構化存儲，是事實來源。每個動作都被記錄，並且可以重放。Claude Code、Cursor、Devin、Aider、OpenHands、goose 都收斂到這一點，不是沒有原因的。

模型本身是無狀態的。運行框架必須是有狀態的。檔案系統是每個開發者都已經理解的有狀態基礎原語。一旦接受這個框架，整套 harness 紀律都會自然展開：checkpoint、可恢復性、sub-agent 驗證、沙箱執行。

這裡更深的一層啟發是：在任何值得為其支付算力帳單的生產 agent 中，harness 做的工作都比模型更多。模型選擇下一步行動，harness 驗證它，在沙盒中運行它，捕獲輸出，決定把什麼反饋回去，決定什麼時候停止，決定什麼時候 checkpoint，決定什麼時候生成 subagent。把模型換成另一個同等質量的模型，一個好的 harness 仍然能交付產品。把 harness 換成一個更差的，即使是世界上最好的模型，也會產出一個會隨機忘記自己在做什麼的 agent。

如果你構建的東西比一次性工具調用更複雜，那麼你真正應該投入時間的地方是 harness。模型只是其中的一個組件。

從概念上理解 MCP

不要只是學習怎麼調用 MCP server。要學習它的模型。它在 agent 能力、工具與資源之間建立了清晰分離，並在底層提供了可擴展的認證與傳輸方案。一旦理解了這一點，你看到的其他「agent 集成框架」，都會像是 MCP 的低配版，你也就省下了逐個評估它們的時間。

Linux Foundation 現在負責托管 MCP。所有主要模型提供商都支持它。把它比作「AI 的 USB-C」，現在已經比諷刺更接近事實。

沙盒化是一種基礎原語

每一個生產級 coding agent 都運行在沙盒裡。每一個瀏覽器 agent 都遭遇過間接 prompt injection。每一個多租戶 agent，某個階段都出現過權限範圍 bug。你應該把沙盒化當作基礎設施原語，而不是等客戶提出要求後才添加的功能。

要學基礎知識：進程隔離、網路出口控制、密鑰範圍管理、agent 與工具之間的認證邊界。那些等客戶安全審查後才臨時補上的團隊，往往會丟掉交易。那些從第一周就把它做進去的團隊，才會在企業採購流程中輕鬆通過。

該用什麼構建

以下是截至 2026 年 4 月的具體選擇。這些選擇會變化，但不會變化得太快。在這一層，盡量選「無聊但穩」的東西。

編排層

LangGraph 是生產環境裡的預設選擇。大約三分之一運行 agent 的大型公司都在用它。它的抽象方式符合 agent 系統的真實形態：類型化狀態、條件邊、持久化工作流，以及 human-in-the-loop 檢查點。缺點是寫起來囉嗦；優點是，當一個 agent 真正進入生產環境後，你確實需要控制這些東西，而它的囉嗦正好對應了這些控制需求。

如果你主要使用 TypeScript，Mastra 是事實上的選擇。它是這個生態裡心智模型最清晰的方案。

如果你的團隊喜歡 Pydantic，並且希望把類型安全作為一等公民，Pydantic AI 是一個合理的 greenfield 選擇。它在 2025 年底發布了 v1.0，勢頭確實存在。

如果是 provider-native 的工作，比如 computer use、語音、實時互動，可以在 LangGraph 节點裡使用 Claude Agent SDK 或 OpenAI Agents SDK。不要試圖讓它們成為異構系統的頂層編排器。它們是為各自擅長的場景優化的。

協議層

MCP，沒別的。

把你的工具集成做成 MCP server。外部集成也用同樣方式消費。現在 MCP registry 已經越過了臨界點：大多數情況下，在你需要自己構建之前，已經能找到一個現成 server。2026 年還在手寫自定義工具 plumbing，基本是在白交稅。

記憶層

選擇記憶系統時，不要按熱度選，要按 agent 的自主程度選。

Mem0 適合聊天式個性化：用戶偏好、輕量歷史記錄。Zep 適合生產級對話系統，尤其是狀態會持續演化、需要實體追蹤的場景。Letta 適合那些需要在幾天甚至幾周工作周期裡保持一致性的 agent。大多數團隊不需要這個；但真正需要的團隊，需要的正是它。

常見錯誤是：還沒有記憶問題，就先上記憶框架。先從上下文窗口能容納的內容，加一個向量數據庫開始。只有當你能清楚說出它要解決的失敗模式時，再加入記憶系統。

可觀測性與 evals

Langfuse 是開源預設選擇。它可以自托管，採用 MIT 許可證，涵蓋 tracing、prompt 版本管理，以及基礎的 LLM-as-judge evals。如果你已經是 LangChain 用戶，LangSmith 集成會更緊密。Braintrust 適合研究型 eval 工作流，尤其是需要嚴謹比較的場景。OpenLLMetry / Traceloop 則適合需要 vendor-neutral OpenTelemetry instrumentation 的多語言技術棧。

你需要同時擁有 tracing 和 evals。Tracing 回答的是：「agent 到底做了什麼？」Evals 回答的是：「agent 比昨天變好了，還是變差了？」沒有這兩樣，不要上線。第一天就把這些東西接好，成本遠低於在盲跑之後再補救。

運行時與沙箱

E2B 適合通用的沙箱代碼執行。Browserbase 搭配 Stagehand，適合瀏覽器自動化。Anthropic Computer Use 適合需要真實操作系統級桌面控制的場景。Modal 適合短時突發任務。

永遠不要運行未沙箱化的代碼執行。一個被 prompt injection 攻破的 agent，如果直接在生產環境中運行，其爆炸半徑會變成一個你絕不想講給別人聽的故事。

模型

追 benchmark 很累，而且大多數時候沒太大幫助。務實地看，截至 2026 年 4 月：

·Claude Opus 4.7 和 Sonnet 4.6 適合可靠的工具調用、多步驟一致性，以及優雅的失敗恢復。對大多數工作負載·來說，Sonnet 是成本與性能之間的甜點位。

·GPT-5.4 和 GPT-5.5 適合需要最強 CLI / terminal 推理能力，或者你本身就生活在 OpenAI 基礎設施裡的場景。

·Gemini 2.5 和 3 適合長上下文密集型，或者多模態密集型任務。

·當成本比頂級性能更重要時，尤其是處理邊界清晰、定義狹窄的任務，可以考慮 DeepSeek-V3.2 或 Qwen 3.6。

把模型視為可替換元件。如果你的 agent 只能在某一個模型上工作，這不是護城河，而是壞味道。用 evals 決定部署什麼模型。每個季度重新評估一次，不要每週都追著換。

什麼可以跳過

你會不斷被人勸去學習、使用下面這些東西。其實不需要。跳過它們的代價很低，省下的時間很多。

AutoGen 和 AG2，不要用於生產。
Microsoft 的這個框架已經轉向社區維護，發布節奏停滯，抽象方式也不符合生產團隊真正需要的形態。做學術探索可以，但不要把產品押在上面。

CrewAI，不要用於新的生產構建。
它到處都能看到，因為它很適合做 demo。真正構建生產系統的工程師已經在遷出它。你想用它做原型可以，但不要長期綁定。

Microsoft Semantic Kernel，除非你已經深度鎖定在 Microsoft 企業技術棧裡，而且你的買方也在意這一點。
它不是生態系統正在走向的方向。

DSPy，除非你專門在大規模優化 prompt 程式。
它有哲學價值，但受眾很窄。它不是通用 agent 框架，也不要把它當成通用框架來選。

把獨立 code-writing agent 當作架構選擇。
Code-as-action 是有趣的研究方向，但它還不是生產環境裡的默認模式。你會遇到許多工具鏈和安全問題，而你的競爭對手可能根本不用處理這些。

「Autonomous agent」式推銷。
AutoGPT 和 BabyAGI 那條產品形態上的路線已經死了。行業最終接受的誠實說法是「agentic engineering」：有監督、有邊界、有評估。2026 年還在賣「部署後就不用管」的 autonomous agent 的人，本質上是在賣 2023 年的東西。

Agent app store 和 marketplace。
從 2023 年開始就有人承諾這件事，但從未真正獲得企業 traction。企業不會購買通用的預製 agent。它們要麼買和具體結果綁定的垂直 agent，要麼自己構建。不要圍繞一個 app store 夢想來設計你的業務。

作为客户，謹慎選擇橫向的「build any agent」企業平台。
例如 Google Agentspace、AWS Bedrock Agents、Microsoft Copilot Studio 這一層。它們以後可能會有用，但現在仍然混亂、發版慢，而且 buy-versus-build 的帳通常仍然傾向於：自己構建一個窄 agent，或者購買一個垂直 agent。Salesforce Agentforce 和 ServiceNow Now Assist 是例外，因為它們贏在已經嵌入你正在使用的工作流系統裡。

不要追 SWE-bench 和 OSWorld 排行榜。
Berkeley 研究人員在 2025 年記錄到，幾乎所有公開 benchmark 都可以被刷榜，而不需要真正解決底層任務。現在團隊會把 Terminal-Bench 2.0 和自己的內部 evals 當作更真實的信號。默認對單一數字的 benchmark 飛躍保持懷疑。

天真的並行多 agent 架構。
五個 agent 圍繞共享記憶聊天，在 demo 里看起來很厲害，到了生產環境就會散架。如果你不能在餐巾紙上畫出一張清晰的 orchestrator-subagent 圖，並標明讀寫邊界，就不要上線。

新 agent 產品不要用 per-seat SaaS 定價。
市場已經轉向 outcome-based 和 usage-based。按席位收費不僅會讓你少賺，還會向買方釋放一個信號：你自己都不相信產品能交付結果。

這個週期你在 Hacker News 上看到的下一個框架。
等六個月。如果它到時候還重要，你會很清楚。如果它不重要，你就省下了一次遷移。

具體該怎麼推進

如果你不是只想「跟上 agent」，而是真的想採用 agent，下面這個順序是有效的。它很無聊，但有用。

先選一個已經重要的結果。不要選 moonshot，不要一上來做一個橫向的「agent platform」項目。選一個你的業務本來就關心、而且可以衡量的事情：減少客服工單、生成第一版法律審查意見、篩選 inbound leads、生成月度報告。Agent 是否成功，取決於這個結果是否改善。它從第一天起就是你的 eval target。

這一步之所以比其他任何步驟都重要，是因為它會約束後續所有決策。有了具體結果，「選哪個框架」就不再是哲學問題，你會選擇最快能交付這個結果的框架。「選哪個模型」也不再是 benchmark 爭論，而是選擇你的 evals 證明在這項具體工作上有效的模型。「我們需不需要記憶、subagents、定制 harness」也不再是思維實驗，而是只在具體失敗模式需要時才添加。

跳過這一步的團隊，最後往往會做出一個沒人要的橫向平台。認真對待這一步的團隊，通常會交付一個狹窄但能在一個季度內回本的 agent。而這個真正上線的 agent，會教會他們比讀兩年文章更多的東西。

在上線任何東西之前，先設置 tracing 和 evals。選 Langfuse 或 LangSmith，把它接好。必要時手工構建一個小型 golden dataset。50 個標註樣本就足夠開始。你無法改進自己無法衡量的東西。以後再補這套系統，成本大約是現在就做的 10 倍。

從一個單 agent 迴圈開始。選擇 LangGraph 或 Pydantic AI。模型選擇 Claude Sonnet 4.6 或 GPT-5。給 agent 三到七個設計良好的工具。讓它用文件系統或資料庫作為狀態。先發給小範圍用戶，觀察 traces。

把 agent 當作產品，而不是項目。它會以你沒預料到的方式失敗，而這些失敗就是你的路線圖。用真實生產 trace 構建 regression set。每一次 prompt 變更、模型替換、工具修改，都要在部署前通過 evals。大多數團隊都低估了這裡的投入，而大多數可靠性也正是從這裡來的。

只有當你已經「賺到了」擴展範圍的資格，再增加複雜度。上下文成為瓶頸時，再引入 subagents。單窗口上下文無法承載所需內容時，再引入記憶框架。底層 API 真不存在時，再引入 computer use 或 browser use。不要提前設計這些東西。讓失敗模式把它們拉進來。

選擇無聊的基礎設施。工具用 MCP。沙盒用 E2B 或 Browserbase。狀態用 Postgres，或者你們已經在運行的數據存儲。認證和可觀測性也盡量沿用現有系統。奇特的基礎設施很少是真正的勝負手，真正的勝負手是紀律。

從第一天就盯著單位經濟模型。每次 action 成本、快取命中率、重試循環成本、模型呼叫分佈。Agent 在 PoC 階段看起來很便宜，但如果你一開始沒有按 outcome 監控成本，規模擴大 100 倍時成本會爆炸。一個 0.50 美元一次運行的 PoC，在中等規模下就可能變成每月 5 萬美元。沒提前看到這一點的團隊，會迎來一場他們並不喜歡的 CFO 會議。

每個季度重新評估模型，而不是每週重新評估。鎖定一個季度。季度結束時，用你的 eval suite 跑一遍當前前沿模型。如果數據說明該換，就換。這樣你能獲得模型進步的收益，同時避免追逐每次發布帶來的混亂。

如何判斷潮流

下面是一些具體信號，說明某件事可能是真的 signal：一個受尊重的工程團隊寫了帶數字的 postmortem，而不只是宣稱有多少人採用；它是一個基礎原語，比如協議、模式或基礎設施，而不是套殼或打包；它能和你已經運行的系統互操作，而不是替代它；它的 pitch 講的是它解決了什麼失敗模式，而不是它開啟了什麼能力；它已經存在了足夠長時間，長到有人能寫出一篇「哪些地方沒奏效」的博客。

下面是一些具體信號，說明某件事可能只是噪音：發布 30 天後仍然只有 demo 視頻，沒有生產案例；benchmark 跃升乾淨得不像真的；pitch 裡不加限定地使用「autonomous」「agent OS」或「build any agent」；框架文檔默認你會扔掉現有的 tracing、auth 和 config；star 數增長很快，但 commits、releases 和 contributors 沒有同步增長；Twitter 速度很快，但 GitHub 速度跟不上。

一個有用的每周習慣是：週五留出 30 分鐘看這個領域。讀三樣東西：Anthropic 工程博客、Simon Willison 的筆記、Latent Space。如果這一周有 postmortem，再掃一兩篇。其他都可以跳過。真正重要的東西，你不會錯過。

接下來值得觀察什麽

未來兩個季度值得關注的事情，不是因為它們一定會贏，而是因為「這到底是不是 signal」這個問題還沒有完全解決。

Replit Agent 4 的 parallel forking 模型。
这是第一批认真尝试「多个 agent 并行工作」但又不被共享状态绊倒的方案之一。如果它能在规模化后站住脚，orchestrator-subagent 这个默认模式可能会发生变化。

Outcome-based pricing 的成熟度。
Sierra 和 Harvey 的收入轨迹，已经在狭窄垂直领域验证了这一模式。问题是，它是否能推广到其他领域，还是只适用于垂直场景。

Skills 作为能力封装层。
GitHub 上 AGENTS.md 和 skills directories 的增多，说明一种封装 agent 能力的新方式正在出现。它是否会像 MCP 标准化工具那样标准化能力层，这是一个开放问题。

Claude Code 2026 年 4 月质量回退及其复盘。
一个行业领先的 agent 发布了一个造成 47% 性能回退的版本，而且是用户先发现，内部监控后发现。这说明即使在领先者那里，生产级 agent eval 实践仍然很不成熟。如果这件事推动整个行业投资更好的 online evals，那么这次纠偏是健康的。

语音成为默认客服界面。
Sierra 的语音渠道在 2025 年底已经超过文本渠道。如果这一模式在其他垂直领域延續，那么延遲、打斷、實時工具調用等設計約束會變成一階問題，很多現有架構都需要重做。

開源模型 agent 能力繼續縮小差距。
DeepSeek-V3.2 原生支持 thinking-into-tool-use，Qwen 3.6 以及更廣泛的開源模型生態都值得關注。狹窄 agent 任務上的成本性能比正在變化。閉源模型默認占優的局面不會永久存在。

這些事情中的每一件，都可以對應一個清晰問題：「六個月後，我需要看到什麼，才會相信它真的重要？」這就是測試。追踪答案，而不是追踪公告。

反常識的賭注

每一個你沒有採用的框架，都是一次你不欠未來的遷移。每一個你沒有追逐的 benchmark，都是一個季度的專注力。這個周期裡正在贏的公司——Sierra、Harvey、Cursor，各自在自己的領域中——都選擇了狹窄目標，建立了無聊的紀律，然後讓這個領域的噪音從身邊經過。

傳統路徑是：選一個技術棧，花很多年掌握它，然後沿著階梯往上爬。這在技術棧能穩定十年的時候是有效的。但現在，技術棧每個季度都在變。真正贏的人，不再優化「掌握某個技術棧」的能力，而是在優化品味、基礎原語和交付速度。他們公開構建小東西，通過交付來學習。別人是因為他們已經做出來的東西，而把他們拉進房間。作品本身就是資歷。

請認真想一想這一點，因為這正是整篇文章真正想說的。我們大多數人接受的工作模型，都假定這個世界會穩定足夠久，讓資歷能夠複利增長。你去上學，拿學位，爬梯子。這裡待兩年，那裡待三年，簡歷慢慢變成能打開門的東西。整個機器的前提，是它對面的行業足夠穩定。

但 agent 領域現在沒有一個穩定的「對面」。你想加入的公司可能只有六個月大。它們構建所用的框架可能只有十八個月歷史。底層協議可能也只有兩年。這個領域裡一半最常被引用的文章，作者三年前甚至還不在這個領域裡。沒有梯子可爬，因為這棟樓一直在變樓層。當梯子失效時，剩下的是一種更古老的方法：做出一個東西，放到互聯網上，讓作品替你介紹自己。這是一條反常識路徑，因為它繞開了資歷認證系統。但在一個不斷移動的領域裡，它也是唯一真正能複利增長的路徑。

這就是從內部看到的時代樣貌。連巨頭也在公開迭代，發布回歸問題，寫復盤，在線修補。今年交付最有趣的東西的團隊裡，有些人 18 個月前還不在這個領域。不會寫程式碼的人正在和 agent 搭檔，交付真實軟體。博士可能會被那些選對基礎原語並開始快速出手的建造者超越。大門已經打開。大多數人卻還在找申請表。

你現在真正需要培養的技能，不是「agents」。而是在一個表層不斷變化的領域裡，判斷哪些工作會複利增長的紀律。Context engineering 會複利增長。工具設計會複利增長。Orchestrator-subagent 模式會複利增長。Eval 紀律會複利增長。Harness 思維會複利增長。週二剛發布的框架 API 不會。一旦你能區分它們，每周一波又一波的新發布就不再像壓力，而會變成你可以忽略的噪音。

你不需要學會所有東西。你需要學會那些會複利增長的東西，並跳過那些不會複利增長的東西。選一個 outcome。在上線前接好 tracing 和 evals。使用 LangGraph，或者你團隊裡的等價工具。使用 MCP。把 runtime 放進沙盒。默認從單 agent 開始。只有當失敗模式把複雜度拉進來時，再擴大範圍。每個季度重新評估模型。週五讀三樣東西。

這就是 playbook。剩下的，是品味、交付速度，以及不追逐無關緊要之物的耐心。

去構建東西。把它們放到互聯網上。這個時代獎勵的是做出東西的人，而不是只會描述東西的人。現在是成為那個「真正做出來的人」的最好窗口。

[原文鏈接]

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia