原文標題：2026 年 AI 代理人應學什麼、建構什麼、跳過什麼
原文作者：Rohit
編譯：Peggy，BlockBeats

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

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

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

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

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

以下為原文：

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

每一份路線圖，發布一個月後就可能過時。你上個季度剛掌握的框架，現在已經成了舊東西。你曾經為之優化的 benchmark，被人刷穿之後很快又被新的取代。過去，我們被訓練成沿著一條傳統路徑前進：一個技術棧，對應一組主題和層級；一串工作經歷，對應年限和頭銜；一步一步緩慢往上爬。但 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 programs。
它有哲學價值，但受眾很窄。它不是通用 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 講的是它解決了什麼失敗模式，而不是它開啟了什麼能力；它已經存在了足夠長時間，長到有人