2025關于 AI Agent 的一些總結

2025年，大家都一致認為是AI Agent爆發的元年。

回顧整個2025以及過去幾年，我們從2022年開始專注智能體創作方向，探索AI與內容創作的無限可能，到2024年推出AI搜索引擎hellomiku，再到今年12月推出了圖文內容創作智能體01Agent。作為01Agent的聯創，這幾年在AI Agent應用落地實戰不斷的試錯探索過程中，也有自己的一些經驗和思考想在這里和大家一起分享。

站在2025年的尾聲回望，這一年來Agent的發展并非一條直線，更多是在狂熱與冷靜、通用與垂直、Tools與skills的博弈中螺旋上升。

整篇文章首先將簡單回顧一下2025年agent相關技術的發展情況，并就以下6個板塊分享我的深度復盤：

1. 1.2025 AI Agent發展概況
2. 2.MCP之后為什么會出現 Skills
3. 3.只有充分上下文的信息，才能做出正確決策
4. 4.從上下文工程到Agent工程
5. 5.Agent 落地的關鍵還是在于交付
6. 6.數據資產與memory才是真正的護城河

一、2025 AI Agent發展概況

首先我們一致達成共識的是AGI目前仍處于 新興AGI 階段。盡管大模型能力不斷在攀升，但它尚未達到全面執行人類所有智力任務的水平。相對于簡單的信息整理或歸納總結生成任務，面對一些復雜的長鏈條任務，單純依賴模型能力的提升遠遠不夠。基于LLM為基座的Agent以及RAG的深度融合，特別是上下文工程的構建，成為了這一年Agent發展的重中之重。

當然不只是在今年，早在 2024 下半年開始就已經越來越多的廠商開始加入到Agent賽道，例如2024.10.24 Anthropic 首次推出computer use 、2024.11推出的MCP server以及智譜的Autoweb glm等。到了今年3月，技術的迭代速度實在太快，大模型關鍵里程碑技術的突破又誕生出了o1以及deepseek R1 等推理模型，以及類似Manus （整合computer use ，browser use，coding agent）等的新形態agent產品。

短短兩個月，到5月份，由于manus的推出，這段時間各種類Manus的產品也相繼推出，如genspark.ai、skywork.ai、納米AI、lovartai、fowith.ai。這類agent產品大多數受Manus以及MCP server的啟發，并基于agent工程，包括任務規劃todolist，集成各類MCP工具，以及上下文等工程，組成的一個super agent。通過大量的工具，也讓agent開始可以具備感知更多環境的能力，比如基于playwright mcp server，agent可以開始自主使用瀏覽器。相比于上一階段類似基于LLM的AI搜索只能做一些信息整理生成輸出，agent執行復雜的任務能力得到顯著提升。當然這也離不開llm推理能力的不斷進步，如claude那段時間最新推出的claude 4模型等。

在那段時間，MCP的發展也非常迅速，市面上從最開始1000多個mcp工具，已經發展到13473+mcp工具。并且也出現了各種一鍵封裝集成mcp的工具，如fastmcp；谷歌也在那段時間推出了類似MCP關于Agent的A2A協議，MCP 側重于智能體與外部數據/工具的連接，而 A2A 則側重于智能體與智能體之間的協作。

隨著agent工程不斷復雜化，每一次執行任務都依賴大量的llm請求和工具調用以及不同agent的配合，其中在大模型上下文有限的情況下，如何跟蹤不同agent的狀態以及對每一次工具調用結果的管理變得至關重要，有效的管理不僅可以提升agent的任務完成率，并且也可以有效降低執行任務消耗的token成本。為此2025.06 AK在X提出了上下文工程的概念：[上下文工程是為下一步提供正確的信息填充上下文窗口的微妙藝術和科學]。

差不多到了8月份，身邊許多朋友對通用agent能力的質疑聲越來越大，特別是關于通用agent最終交付完成率，好看不好用？結果用戶是否滿意？是否愿意付費？總的來說目前整體市面上通用agent的任務交付率相對較差的。反而在垂直領域的agent表現效果突出，短短幾個月，繼cursor之后，國內字節，騰訊都推出或更新了自家的AI Coding產品，如字節的trae，騰訊的codebuddy，包括anthropic的claude code，當然AI coding效果表現出色離不開模型不斷進化的代碼編程能力，如claude sonnet 4.5 , gemini 3 pro ,glm4.7等。

再到10 月 16 日 Anthropic 正式推出Agent Skills，最近openai 官方也開始支持Skills功能了，Claude的Agent Skills將徹底改變行業格局，推動在編程、客服和文檔生成等領域的深度任務集成，這也將標志著各種行業開始采用更專業、更高效的Agent。

總的來說，這一年我們見證了從 MCP 工具生態以及通用agent的‘寒武紀大爆發’，到下半年對通用 Agent 交付能力的冷靜反思，再到垂直場景（如 Coding）和引入 Skills 機制的務實演進。這種極速迭代的背后，實際上是 Agent 發展邏輯從‘連接萬物’向‘精準交付’的深刻轉型。

二、MCP之后為什么會出現 Skills？

為什么會出現 Skills？ 可以這么說Skills的出現是Agent發展的必然產物。

無論是Manus的computer use還是claude code 的coding agent，當我們將終端命令行、文件系統等底層權限交給 Agent時，這里會暴露出一個問題：工具變得更精簡了（比如filesystem、terminal、browser等），但任務的編排組合復雜度卻呈指數級上升。比如給我一臺頂配的電腦，但是我不知道怎么用不會用，再好的工具對我也沒有意義。所以Agent也是一樣的，再好的工具如果Agent不知道怎么用，怎么組合使用，那再好的工具也無濟于事。我相信這也是大多數通用Agent任務完成率低的原因之一。

當前階段的Agent 不再缺乏手腳，而是缺乏大腦中的規劃邏輯。Skills 正是填補這一空白的拼圖，它通過預設的專家經驗或者任務場景工作流，引導 Agent 在復雜的本地環境中，以更規范、更穩定的路徑去交付結果。在物理形態上，Skills它非常樸素：就是一個包含說明書（SKILL.md）和參考資料或腳本的文件夾。

如果說Mcp server Tools 是給 Agent 發了一把錘子，那么 Skills 就是塞給它一本使用手冊。這里需要注意的是，在 Agent 開發中，我們往往容易陷入“工具堆疊”的陷阱：感覺工具越多，agent的能力邊界就越大。其實，更高效的做法是將“怎么做”的經驗打包。

最好的例子就是browser_use，用戶每天都會在基于瀏覽器進行各種各樣的任務，每個任務都有對應的sop鏈條，如何將這些鏈條轉為skills，并在用戶發送指令時精準識別對應的sop并召回將變得越來越重要。比如在01agent開發設計過程中，無論是發布還是選題都有對應的skills，并且會根據不同broswer_use的任務最終自我反思成一個可復用的sop。過去可能agent完成一個自動化發布的任務，需要走很多彎路，但是現在有了自己的sop，并且這個sop會不斷自主反思進行更新的，整個browser_use的任務完成率也得到了大幅提升。

三、只有擁有充分上下文的信息，才能提高大模型做出正確決策的概率

LLM 的本質是輸入和輸出，每一次上下文的輸入決定了每一次的輸出是什么；那么你也可以理解為Agent只不過是基于上下文不斷循環的輸入輸出。

如何做出正確決策？這不經讓我思考，兩個同樣聰明的人，能讓它們拉開差距最大的因素是什么？答案很可能是解決問題的能力，而解決問題的能力關鍵在于如何圍繞問題本身盡可能獲取全面的上下文信息，并基于上下文信息做出正確的決策。只有你獲取的上下文信息足夠多，你才能做出正確決策。這里有個極端的例子，比如如果我都知道全球關于某二手車的所有賣家的信息了，那么我一定可以做出正確的決策選擇出最具性價比的那輛車。

如何做出正確的決策，關鍵在于決策環境下獲取的信息充不充分，也就是說LLM需要評估所有可用的信息，然后決定：我需要采取哪些步驟？當前我應該采取的第一步是什么？

在每一次輸入大模型上下文有限的情況下，怎么保證每一次輸入都能是最好的輸出，怎么讓agent知道用戶的需求市面哪個工具是最佳解決方案，怎么去找到這些工具，也是一個至關重要的部分。

四、從上下文工程到Agent工程

在構建 LLM 應用程序時，我們需要管理哪些類型的上下文？上下文工程作為適用于幾種不同上下文類型：

• 指令說明：系統提示詞、 few?shot示例、工具描述等
• 知識 ：事實、記憶等
• 工具 ：來自工具調用的反饋，更多是讓LLM感知更多環境，比如browse_use（最終也是把環境轉為上下文的形式）

長時間運行的任務和工具調用的累積反饋意味著Agent經常使用大量token，會導致許多問題：它可能會超出上下文窗口大小、token成本/延遲或降低Agent性能。在一篇文章中Drew Breunig 很好概述了較長上下文可能導致執行問題的許多具體方式，包括：

• 語境中毒：當幻覺進入語境時
• 上下文分散注意力：當上下文壓倒了培訓時
• 上下文混淆：當多余的上下文影響響應時
• 上下文沖突：當上下文的某些部分不一致時

上下文工程作為今年的核心，以下是lanchain官方中分享的一些關于上下文工程比較好的策略，可以參考：

Agent經常進行跨越數百個回合的對話，需要仔細的上下文管理策略。我們將Agent上下文工程的常見策略分為四個部分—— 寫入、選擇、壓縮和隔離

Write Context：編寫上下文意味著將其保存在上下文窗口之外，以幫助Agent執行任務。

• Scratchpads ：當人類解決任務時，我們會做筆記并記住未來相關任務。Agent也正在獲得這些功能！通過“ 暫存器 ”記筆記是在Agent執行任務時保留信息的一種方法。這個想法是將信息保存在上下文窗口之外，以便Agent可以使用它。暫存器可以通過幾種不同的方式實現。它們可以是簡單地寫入文件的工具調用。它們也可以是運行時狀態對象中的字段，在會話期間保留。無論哪種情況，暫存器都可以讓Agent保存有用的信息以幫助他們完成任務。
• Memories：暫存本幫助Agent解決給定會話（或線程 ）中的任務，但有時Agent會從記住多個會話中的事情中受益！ 反射引入了在每次Agent回合后進行反思并重復使用這些自我生成的記憶的想法。 生成智能體創建了從過去智能體反饋的集合中定期合成的記憶。

Select Context：選擇上下文意味著將其拉入上下文窗口以幫助Agent執行任務。

• Scratchpads ：從暫存器中選擇上下文的機制取決于暫存器的實現方式。如果它是一個工具 ，那么Agent可以通過進行工具調用來簡單地讀取它。如果它是Agent運行時狀態的一部分，則開發人員可以選擇在每個步驟中向Agent公開哪些狀態部分。這為在以后的回合中向 LLM 公開暫存器上下文提供了細粒度的控制級別。
• Memories：如果Agent有能力保存記憶，他們還需要能夠選擇與他們正在執行的任務相關的記憶。這可能很有用，原因有幾個。Agent可能會選擇少量示例（ 情景記憶 ）作為所需行為的示例，選擇指令（ 程序記憶 ）來引導行為，或選擇事實（ 語義記憶 ）作為任務相關上下文。

• Tools：Agent使用工具，但如果為他們提供過多的工具，可能會變得過載。這通常是因為工具描述重疊，導致模型對使用哪個工具感到困惑。一種方法是將 RAG（檢索增強生成）應用于工具描述 ，以便僅獲取與任務最相關的工具。最近的一些論文表明，這可以將刀具選擇的準確性提高 3 倍。
• Knowledge：RAG 是一個豐富的主題， 它可能是一個核心的上下文工程挑戰 。代碼Agent是大規模生產中 RAG 的一些最佳示例。Windsurf 的 Varun 很好地抓住了其中一些挑戰：

Compressing Context：壓縮上下文涉及僅保留執行任務所需的令牌

• Context Summarization：座席交互可以跨越數百個回合 ，并使用令牌密集型工具調用。摘要是管理這些挑戰的一種常見方法。如果您使用過 Claude Code，您就會看到這一點。Claude Code 在您超過 95% 的上下文窗口后運行“ 自動壓縮 ”，它將總結用戶與Agent交互的完整軌跡。這種跨Agent軌跡的壓縮可以使用各種策略，例如遞歸或分層摘要。

• Context Trimming：摘要通常使用 LLM 來提煉最相關的上下文片段，而修剪通常可以過濾，或者正如 Drew Breunig 指出的那樣，“ 修剪 ”上下文。這可以使用硬編碼啟發式方法，例如從列表中刪除較舊的消息 。Drew 還提到了普羅旺斯，一個訓練有素的問答上下文修枝剪。

Isolating Context ：隔離上下文涉及將其拆分以幫助Agent執行任務

• Multi-agent：隔離上下文的最流行方法之一是將其拆分為子Agent。OpenAI Swarm 庫的動機是關注點分離 ，Agent團隊可以處理特定的子任務。每個Agent都有一組特定的工具、說明和自己的上下文窗口。Anthropic 的多智能體研究人員對此提出了一個理由：許多具有隔離上下文的智能體的性能優于單智能體，這主要是因為每個子智能體上下文窗口都可以分配給更窄的子任務。正如博客所說：
• Context Isolation with Environments：HuggingFace 的深入研究者展示了上下文隔離的另一個有趣的例子。大多數Agent使用工具調用 API，它返回 JSON 對象（工具參數），這些對象可以傳遞給工具（例如搜索 API）以獲取工具反饋（例如搜索結果）。HuggingFace 使用 CodeAgent，該 CodeAgent 輸出包含所需工具調用的輸出。然后，代碼在沙盒中運行。然后，從工具調用中選定的上下文（例如，返回值）被傳遞回 LLM。
• State：值得指出的是，Agent的運行時狀態對象也可以是隔離上下文的好方法。這可以起到與沙盒相同的作用。狀態對象可以使用具有可以寫入上下文的字段的架構來設計。模式的一個字段（ 例如消息） 可以在Agent的每個回合向 LLM 公開，但模式可以隔離其他字段中的信息，以便更有選擇性地使用。

隨著Agent的不斷發展，目前的趨勢看來，如果需要為每個agent都配一臺電腦，當 Agent 的能力從對話擴展到如編寫代碼、分析數據、生成文件時，我們實際上是在為每個 Agent 分配一臺“云端電腦”。當前01Agent也為每個用戶的專屬Agent配置了一臺云端電腦。這標志著開發重點從單一的Prompt/Context 工程轉移到了全棧Agent基礎設施工程的構建。

這一階段的挑戰和工程重點主要體現在以下三個維度：

1.Sandbox基礎設施的構建與編排

如果說上下文工程解決的是“大腦”怎么思考的問題，那么沙箱工程解決的就是“雙手”在何處工作的問題。

環境隔離與安全性：當 Agent 執行 Python 代碼或 Shell 命令時，必須在嚴格隔離的沙箱中運行，以防止對主機造成安全威脅（如 rm -rf / 這種容易造成安全事故的指令）。

• 環境一致性Agent 需要預裝特定的依賴庫。如何快速啟動一個帶有特定環境的“電腦”，成為了工程難題。
• 冷啟動與延遲為每個任務瞬間啟動一個虛擬機是有延遲的。Agent 工程需要通過熱池或快照技術來最小化 Agent 啟動時間，保證用戶體驗的流暢性。

在上下文窗口之外，文件系統是 Agent 最重要的“外掛硬盤”。

生成文件的生命周期管理：Agent 在執行任務過程中會產生大量中間文件（圖片、代碼文件、Pdf等）。如何存儲這些文件？何時清理？如何讓用戶下載？這涉及到底層的對象存儲與臨時文件系統的協同。

持久化工作區：對于長時間運行的任務，Agent 需要一個持久的“工作臺”。即使用戶關閉了瀏覽器，Agent 所在的環境狀態和文件也應該被保留，以便下次喚醒時能“接上斷點”繼續工作。比如01Agent關于用戶瀏覽器cookie數據的持久化管理，方便用戶下次執行相關任務不再需要登錄，這實際上是在構建一個云端的 OS 文件管理系統。

3.成本控制與資源調度

“給每個 Agent 配一臺電腦”意味著計算成本的指數級上升。

Token 成本 vs. 計算成本：以前主要關注 LLM 的 Token 消耗，現在必須關注sandbox的運行時間。長時間運行的 Agent會帶來成本上更大的消耗。

• Serverless Agent 架構為了降低成本，Agent 工程趨勢向 Serverless 靠攏——即“用完即走”。當 Agent 等待 LLM 思考時，暫停計算資源；當 Agent 執行代碼時，毫秒級喚醒計算資源。這種精細化的調度是控制大規模 Agent 部署成本的關鍵。

在 Agent 工程中，“記憶”不再僅僅是塞進 Prompt 里的文字片段，而是變成了結構化的數據庫系統。

記憶的存儲層：短期記憶可能在內存或 Redis 中，長期記憶（如用戶偏好、歷史任務結果）則需要存入向量或圖數據庫。目前這一過程也是最容易被忽視的，但非常重要。

索引與檢索：在工程層面，這意味著需要構建高效的檢索引擎，無論是memory還是SKills，讓 Agent 能夠像訪問硬盤一樣，快速從海量歷史數據中提取關鍵信息，而無需依賴昂貴的上下文窗口。

隨著 Agent 的進化，上下文工程正在成為Agent 工程的一個子集。上下文工程 關注的是如何最優化 LLM 的輸入輸出，Agent 工程則關注的是如何構建一個穩定、安全、低成本的Agent計算機系統，讓這個“大腦”能夠真正地在數字世界中通過使用工具產生實際價值。這標志著我們從單純的“調優模型”時代，正式邁入了“構建智能體操作系統”的軟件工程深水區。

五、Agent 落地的關鍵還是在于交付

Agent 關鍵還是在于交付率，交付率高了用戶自然愿意付費。相比于通用Agent，coding Agent場景為什么交付率那么高，關鍵是滿足三個條件任務明確，場景封閉，結果可驗證。

1. 1.任務明確：指的是Agent 需要解決的問題或執行的操作是具體、清晰且定義良好的；Coding Agent 用戶提出的需求通常是直接的編程任務，比如修改這個bug，很少有直接生成xxxapp。相比于開放域的對話或任務（如“幫我生成一個xxx旅游攻略”），Coding任務的目標和成功標準通常更少歧義，也更方便于驗證。
3. 2.場景封閉：Agent 的操作環境是受限的、邊界清晰的。它主要在集成開發環境內部工作，與代碼文件、項目結構等直接相關的元素交互。場景封閉的優勢關鍵在于能獲取盡可能豐富的上下文信息（代碼，報錯信息等），以及coding場景的規則相對固定，代碼等語法規則相對固定，重要的是這些LLM都擅長理解。
5. 3.結果可驗證：生成的代碼可以立即編譯、運行進行驗證。運行成功還是報錯一下就驗證了。這種即時、客觀的反饋循環極大地促進了 Agent 的成功。但類似旅游攻略，報告這種人為主觀的驗證，多多少少會增加結果可驗證的不確定性。如何量化一個結果的驗證機制至關重要。

對于像 Cursor 這樣的Coding Agent，“任務明確”意味著它處理的是具體的、可定義的編碼問題；“場景封閉”意味著它在 IDE 這個邊界清晰、信息結構化、規則相對固定的環境中工作。這兩個特性極大地縮小了問題域，讓大模型能夠高度聚焦其能力，特別是Claude這種擅長Coding以及支持長上下文的LLM，其充分利用可獲取的精確上下文信息，并產生易于驗證的結果，克服了通用Agent 常面臨的模糊性、復雜性和難以驗證的問題，最終實現了高交付率。也正是因為Agent執行任務高的交付率，解決了用戶實質問題，用戶覺得它有價值從而愿意付費。目前01Agent剛上線不到一周時間，大量的付費用戶也一定程度證明了這一點：用戶只為Agent交付的結果是否滿意而決定是否買單。

六、數據資產與memory才是真正的護城河

如果說高交付率是 Agent 產品的敲門磚，那么用戶數據沉淀與個性化記憶則是真正的護城河。隨著 LLM 本身日益成為一種水電般的基礎設施，不同 Agent 產品在模型能力上的差距終將縮小。在 2026 年，區分一個 Agent 是否具備不可替代性的核心，將取決于它有多懂它的用戶。

1. 1.資產沉淀：從一次性交互到長期資產積累

在過去，我們使用工具產生的數據往往是割裂的。但在 Agent 時代，用戶在使用過程中產生的所有交互、創作的內容（無論是文章還是海報），都不應僅僅是歷史記錄，而應轉化為用戶的數字資產。 以01Agent的內容創作為例，01Agent 不僅是在幫用戶寫一篇文章，設計一個海報，這些都可以作為你日后不斷累積的數字資產，甚至是可以進行變現的資產。這種資產的沉淀，使得遷移成本變得極高——用戶無法輕易離開一個已經存儲了他們大量作品的系統。

1. 2.個性化與默契：打造“最懂你”的超級助手

通用 Agent 往往給人一種“千人一面”的感覺。但真正的超級助手，應該具備深度的個性化能力。這種個性化不僅僅是記住你的名字，而是基于長期記憶形成的默契。這種默契體現在 Agent 能夠預判你的需求。例如，在創作場景中，一個懂你的 Agent 不需要你每次都提示“請使用xxx風格”，因為它從你過去修改的內容中已經學到了這些偏好。隨著數據的不斷沉淀，Agent 的每一次輸出都更貼合用戶的心意，從而形成一個正向的數據飛輪：

Agent 越懂用戶 -> 用戶體驗越好 -> 用戶使用頻率越高 -> 沉淀數據越多 -> Agent 越懂用戶

1. 3.信任階梯：建立社會化關系 Agent 的終極形態，是與用戶建立起一種類社會的信任關系。

用戶對 Agent 的信任通常經歷三個階段：

• 懷疑期： 用戶嘗試性使用，不僅要檢查結果，還要像防賊一樣盯著每一步操作（如早期的 AI coding）。
• 驗證期： 用戶發現 Agent 在特定領域非常靠譜，開始在這些垂類任務上放權，但核心決策仍需人工介入。
• 依賴期： 當 Agent 通過長期的個性化服務證明了自己的穩定性后，用戶開始產生絕對信任。

這種信任關系一旦建立，就是最高的壁壘。就像現實生活中，你可能因為哪個工具好用就換哪一個工具，但你很難因為好用一點就換掉一個跟隨你十年、這懂你每一個眼神含義的助理。未來的 Agent 產品，競爭的不再是誰的模型參數更大，而是誰能更快地攀爬上用戶的信任階梯，成為用戶數字生命中不可或缺的伙伴。

回顧 2025，這是 AI Agent 從玩具走向工具的關鍵一年。我們見證了從提示詞工程到上下文工程的范式轉移，也深刻體會到了 MCP、Skills 以及上下文工程在提升交付率中的決定性作用。

但正如我在文中提到的，技術的演進終將拉平模型能力的差距。當所有的 Agent 都擁有了類似的“手腳”（Tools）和“大腦”（LLM）時，2026 年真正的爆發機會，將屬于那些能夠構建扎實Agent工程以及信任壁壘的產品，2026年的01Agent也將重點朝著這個方向去努力。

Coding Agent 的成功不僅僅是因為它寫代碼快，更因為它通過每一次成功的編譯、每一次精準的修復，建立起了用戶敢于放手讓它去干的信任。這種信任，建立在極高的交付率之上，固化在用戶沉淀的私有數據與 Skills 之中。

未來的 Agent 競爭，不再是單純的算力比拼，而是一場關于誰更懂用戶的競賽。2026 年，能夠爆發的 Agent，一定不是那個聲稱無所不能的通用天才，而是那個在特定領域里，有著極高業務 Know-how，能像老伙計一樣理解你、預判你，并穩定交付結果的Agent。

Agent 的探索之路注定不是一條直線。但幸運的是，我們已經走過了盲目狂熱的階段，正腳踏實地地邁向深水區。2026，愿我們都能打造出那個真正從0到1能真正落地交付的Agent。

2026，我們不再需要向世界證明“Agent 能做什么”，而是直接用一個 Case 告訴用戶“Agent 能為你解決什么”。從連接萬物回歸到精準交付，從炫技工具進化為可信賴的伙伴，這不僅是技術的螺旋上升，更是 AI Agent 從0到1真正走向成熟的必經之路。

讓我們在 2026 年，繼續在實戰中尋找答案。