作者 ｜ 王兆洋
郵箱 ｜ wangzhaoyang@pingwest.com

Manus從誕生第一天起就是一款值得關注的產品。

只不過在很長一段時間里，它的爭議蓋過了產品本身，團隊本身也并未系統地分享過自己產品背后的技術。

這逐漸造成一個有趣的矛盾：Manus誕生到今天，它做出的交互方式創新，不只塑造了外界對“AI Agent”的印象，也在受到一眾競爭對手乃至模型大廠的認可或跟隨，這些關注的焦點并非在它炮制的“概念”，而是實打實來自它的技術方案和產品思路，先是Anthropic 官方把它作為最有代表性的應用案例，然后是多個AI應用明星團隊在產品路線上讓人看到它的影子，后是最近ChatGPT Agent的發布甚至被一些實打實在一線做Agent創業的人稱為OpenAI的Manus時刻。

而另一方面，依然有很多人在好奇這款“套殼”產品的技術含量，加之技術和產品之外的各種爭議不斷，使得它對于今天AI Agent的技術和產品發展方向的嚴肅價值被進一步忽視。

而最近Manus團隊終于難得自己出來系統的分享了這個產品背后的思路，并十分直接的分享了踩過的一系列坑，和因此做出的各種技術方案的設計和產品路線的決定。

這是一個對很多AI Agent領域的開發者和創業者都有價值的技術分享。我們把這個用英文寫的技術博客也交給Manus自己做了一個編譯和備注版本。

這個版本在翻譯和解釋上完成度很高。但在我跟Manus做prompt 的過程中，一個有意思的地方是，它死活寫不對作者的名字。而這個問題反而正是這篇博客重點提到的KV Cache命中率對AI agent產品帶來的挑戰的一個體現。

多次提示后依然寫錯了名字

借用博客里的話，可能這個問題反而“諷刺地”指向了上下文工程方向的價值。

以下為Manus自己生成整理的版本：

AI Agent的上下文工程：構建Manus的經驗教訓

發布日期：2025年7月18日

作者：季逸超 'Peak' Ji

1

編者按

隨著AI Agent技術的快速發展，如何高效構建和優化 Agent系統已成為業界關注的焦點。本文是對Manus聯合創始人兼首席科學家季逸超（Yichao 'Peak' Ji）撰寫的《Context Engineering for AI Agents: Lessons from Building Manus》一文的中文編譯。并在一些關鍵信息位置做了必要背景補充，以括號內信息的形式呈現，在文末做了術語解釋和參考資料信息匯總。

季逸超是中國AI領域的知名創業者，曾開發出"猛犸"系列瀏覽器和Magi知識圖譜系統，擁有豐富的自然語言處理和AI產品開發經驗。在本文中，他分享了Manus團隊在構建AI Agent過程中關于上下文工程的寶貴經驗，包括KV緩存優化、動態動作空間管理以及利用文件系統作為擴展上下文的創新方法。

這些經驗不僅揭示了當前AI Agent開發的技術挑戰和解決思路，也為未來 Agent技術的發展提供了重要參考。無論您是AI研究者、開發者還是產品經理，相信都能從中獲得啟發。

1

文章亮點總結

以下是《AI Agent的上下文工程：構建Manus的經驗教訓》一文的10個最重要的亮點：

上下文工程的重要性：Manus選擇押注上下文工程，而非從頭訓練模型，以實現快速迭代和產品與底層模型的正交性。

KV緩存命中率是關鍵指標：對于生產階段的AI Agent，KV緩存命中率直接影響延遲和成本，是優化性能的關鍵。

保持提示前綴穩定：LLMs的自回歸特性意味著即使單個token的差異也可能使緩存失效，因此保持提示前綴穩定至關重要。

上下文僅追加原則：避免修改之前的動作或觀察結果，確保序列化確定性，以維持KV緩存的有效性。

明確標記緩存斷點：在不支持自動增量前綴緩存的框架中，手動插入緩存斷點有助于優化緩存利用。

掩碼而非移除工具：面對不斷增長的工具數量，Manus通過掩碼token logits來管理工具可用性，而非動態添加或移除工具，以避免緩存失效和模型混淆。

避免動態增刪工具：動態添加或移除工具會使KV緩存失效，并可能導致模型混淆和幻覺動作。

上下文感知狀態機：Manus使用上下文感知狀態機來管理工具可用性，通過掩碼token logits來約束動作選擇。

文件系統作為擴展上下文：將文件系統視為上下文窗口的擴展，可以克服固定大小上下文窗口的限制，處理更復雜、更長的任務。

虛擬文件系統的優勢：Manus的虛擬文件系統能夠高效存儲檢索信息、分層組織信息、在 Agent間共享信息以及支持版本控制。

1

正文

在Manus項目的最初階段，我和我的團隊面臨一個關鍵決策：我們應該使用開源基礎模型訓練一個端到端的Agent模型，還是在前沿模型的上下文學習（in-context learning）能力之上構建Agent？

回顧我在自然語言處理（NLP）領域的第一個十年（季逸超出生于1992年，高中時期便開始獨立開發蘋果應用程序，并在高三時推出了備受矚目的"猛犸1"瀏覽器。大一時他推出"猛犸4"瀏覽器，并獲得了Macworld Asia 2011的特等獎，在業界嶄露頭角），我們沒有這種選擇的奢侈。

遙想BERT時代（已是 7 年前）（注：BERT 2018 年發布，代表“預訓練+微調”范式），模型必須先微調、再評估才能遷移到新任務；一次迭代常常要幾周——盡管那些模型和今日 LLM 相比小得多。對于節奏很快、特別是仍在尋找 PMF（Product-Market Fit）的應用，這種緩慢反饋循環簡直是“判死刑”。

這是我上一個創業公司的痛苦教訓（季逸超的創業之路始于Peak Labs，他獲得了真格基金和紅杉中國的早期投資，致力于打造創新產品。其中，Magi系統被稱為"中文互聯網最大通用知識圖譜"，顯示了他在知識圖譜和語義搜索領域的積累）。當時我從零開始訓練開放信息抽取（open information extraction，從非結構化文本中自動提取結構化信息的技術）和語義搜索模型。然后GPT-3和Flan-T5（Google的指令微調T5模型）出現了，我的內部模型一夜之間變得無關緊要。具有諷刺意味的是，正是這些模型標志著上下文學習的開始——以及一條全新的前進道路。

那段來之不易的教訓讓方向變得清晰：Manus 要押注 context engineering（上下文工程：系統性設計、組織、操控 LLM 讀取的上下文結構與內容以驅動行為）。這樣我們能在“數小時”而不是“數周”里交付改進，并保持產品與底層模型“正交”。也就是，模型進步是“上漲潮水”，Manus 要做漂浮的船，而不是被釘在海床的柱子。

然而，context engineering 并不簡單。它更像“實驗科學”：我們重寫（rebuild）了四次 Agent 框架——每次都是發現了更好的上下文塑造的方式。

我們把這種架構搜索、prompt 微調、經驗猜測的手工過程（manual process）戲稱為 “Stochastic Graduate Descent”（注，這里是一個雙關自嘲，Manus翻譯的版本里，AI Agent沒有get到這個意思，它影射 Stochastic Gradient Descent，隨機梯度下降，而Graduate 暗指“靠研究生體力/腦力不斷試”，把 Gradient梯度換成 Graduate研究生，諷刺地說明：它不是數學自動優化，而是一群工程師/研究生手動做大量、帶噪聲的小實驗，逐步逼近更好的 Agent 架構）。

是的，它不優雅，但有效。

這篇文章分享了我們通過自己的"SGD"達到的局部最優解。如果你正在構建自己的AI Agent，我希望這些原則能幫助你更快地收斂。

設計圍繞KV緩存

如果我必須選擇一個指標，我認為KV緩存命中率是生產階段AI Agent最重要的單一指標（KV-cache hit rate，鍵值緩存是Transformer模型中存儲注意力計算結果的機制，命中率高意味著可以重用之前的計算結果）。它直接影響延遲和成本。為了理解原因，讓我們看看典型 Agent是如何運作的：

收到用戶輸入后， Agent通過一系列工具使用來完成任務。在每次迭代中，模型根據當前上下文從預定義的動作空間中選擇一個動作。然后在環境中執行該動作（例如，Manus的虛擬機沙盒環境，這是Manus提供的隔離執行環境，確保代碼安全運行）以產生觀察結果。動作和觀察結果被附加到上下文中，形成下一次迭代的輸入。這個循環持續到任務完成。

正如你可以想象的，上下文隨著每一步而增長，而輸出——通常是結構化的函數調用——保持相對較短。這使得 Agent中預填充（prefilling，將輸入token一次性處理的階段）和解碼（decoding，逐個生成輸出token的階段）之間的比例與聊天機器人相比高度傾斜。例如，在Manus中，平均輸入與輸出token比例約為100:1。

幸運的是，具有相同前綴的上下文可以利用KV緩存，這大大減少了首token時間（TTFT，Time-To-First-Token）和推理成本——無論你使用的是自托管模型還是調用推理API。我們談論的不是小幅節省：例如，使用Claude Sonnet時，緩存的輸入token成本為0.30美元/百萬token，而未緩存的成本為3美元/百萬token——相差10倍。

從上下文工程的角度來看，提高KV緩存命中率涉及幾個關鍵實踐：

保持提示前綴穩定（Keep your prompt prefix stable）。由于LLMs的自回歸（autoregressive，模型按順序生成token，每個token的生成都依賴于之前的所有token）特性，即使是單個token的差異也可能使該token之后的緩存失效。一個常見錯誤是在系統提示的開頭包含時間戳——特別是精確到秒的時間戳。當然，這讓模型能告訴你當前時間，但也會殺死你的緩存命中率。

使你的上下文僅追加（append-only）。避免修改之前的動作或觀察結果。確保你的序列化是確定性的。許多編程語言和庫在序列化JSON對象時不保證穩定的鍵排序，這可能會悄無聲息地破壞緩存。

在需要時明確標記緩存斷點。一些模型提供商或推理框架不支持自動增量前綴緩存，而是需要在上下文中手動插入緩存斷點。分配這些斷點時，要考慮潛在的緩存過期，至少確保斷點包含系統提示的結尾。

此外，如果你使用vLLM（一個高性能的LLM推理框架）等框架自托管模型，請確保啟用前綴/提示緩存，并使用會話ID等技術在分布式工作節點間一致地路由請求。

掩碼，而非移除（Mask, Don't Remove）

隨著你的 Agent承擔更多能力，其動作空間自然變得更加復雜——簡單來說，工具數量爆炸式增長。MCP最近的流行只是火上澆油。（Model Context Protocol，Anthropic提出的模型上下文協議，用于標準化AI模型與外部工具的交互）如果你允許用戶可配置的工具，相信我：總會有人將數百個神秘工具插入你精心策劃的動作空間。結果，模型更可能選擇錯誤的動作或采取低效路徑。簡而言之，你高度武裝的Agent變得更愚蠢了。

自然的反應是設計動態動作空間——也許使用類似RAG（Retrieval-Augmented Generation，檢索增強生成，通過檢索相關信息來增強模型生成能力的技術）的方式按需加載工具。我們在Manus中也嘗試過這種方法。但我們的實驗表明一個明確的規則：除非絕對必要，避免在迭代中動態添加或移除工具。

主要有兩個原因：

在大多數LLMs中，工具定義在序列化后位于上下文的前部，通常在系統提示之前或之后。因此任何更改都會使所有后續動作和觀察的KV緩存失效。

當之前的動作和觀察仍然引用當前上下文中不再定義的工具時，模型會感到困惑。沒有約束解碼（constrained decoding，限制模型輸出必須符合特定格式或規則的技術），這通常導致模式違規或幻覺動作。

為了解決這個問題同時仍然改進動作選擇，Manus使用上下文感知狀態機（state machine，根據當前狀態和輸入確定下一個狀態的計算模型）來管理工具可用性。它不是移除工具，而是在解碼過程中掩碼token logits（模型輸出的原始概率分布）以防止（或強制）基于當前上下文選擇某些動作。

實際上，大多數模型提供商和推理框架都支持某種形式的響應預填充，這允許你在不修改工具定義的情況下約束動作空間。通常有三種函數調用模式（我們將使用NousResearch的Hermes格式作為示例）：

?自動– 模型可以選擇調用函數或不調用。通過僅預填充回復前綴實現：<|im_start|>assistant

?必需– 模型必須調用函數，但選擇不受約束。通過預填充到工具調用token實現：<|im_start|>assistant

?指定– 模型必須從特定子集調用函數。通過預填充到函數名開頭實現：<|im_start|>assistant {"name": "browser_

使用這種方法，我們通過直接掩碼token logits來約束動作選擇。例如，當用戶提供新輸入時，Manus必須立即回復而不是采取動作。我們還故意設計了具有一致前綴的動作名稱——例如，所有瀏覽器相關工具都以browser_開頭，命令行工具以shell_開頭。這使我們能夠輕松強制 Agent在給定狀態下只從某組工具中選擇，而無需使用有狀態的logits處理器。

這些設計有助于確保Manus Agent循環保持穩定——即使在模型驅動的架構下。

將文件系統用作上下文（Use the File System as Context）

現代的前沿大語言模型（LLM）現在提供 128K 甚至更多的 token 上下文窗口。但在真實的 Agent（agentic）場景中，這通常是不夠的，有時甚至是一種負擔。這里有三個常見的痛點：

觀測（Observations）可能非常龐大，特別是當 Agent與網頁或 PDF 等非結構化數據交互時，很容易就會超出上下文限制。

模型性能在超過一定上下文長度后會下降，即使其上下文窗口在技術上支持更長的長度。

長輸入（Long inputs）的成本很高，即使有前綴緩存（prefix caching，一種技術，通過緩存已處理過的前綴 token 來加速后續請求的處理），你仍然需要為傳輸和預填充（prefill）每個 token 付費。

為了解決這個問題，許多 Agent系統采用了上下文截斷（truncation）或壓縮（compression）策略。但過于激進的壓縮不可避免地會導致信息丟失。這個問題是根本性的： Agent的天性決定了它必須基于所有先前的狀態來預測下一步行動——而你無法可靠地預測哪個觀測（observation）在十步之后可能會變得至關重要。從邏輯上講，任何不可逆的壓縮都帶有風險。

這就是為什么我們將文件系統視為 Manus 中最終極的上下文：它的大小無限，本質上是持久的，并且可以由 Agent自己直接操作。模型學會了按需讀寫文件——將文件系統不僅用作存儲，還用作結構化的、外部化的記憶。

我們的壓縮策略始終被設計為可恢復的。例如，只要保留了 URL，網頁的內容就可以從上下文中丟棄；只要其路徑在沙箱（sandbox，一個隔離的計算環境）中仍然可用，文檔的內容就可以被省略。這使得 Manus 可以在不永久丟失信息的情況下縮減上下文長度。

在開發這個功能時，我發現自己開始想象，要讓一個狀態空間模型（SSM）（State Space Model，一種與 Transformer 不同的序列模型架構，以其高效處理長序列而聞名）在 Agent場景中有效工作需要什么。

與 Transformer 不同，SSM 缺乏完全的注意力機制，并且難以處理長距離的反向依賴關系。但如果它們能夠掌握基于文件的記憶——將長期狀態外部化，而不是保存在上下文中——那么它們的速度和效率可能會開啟一類新的 Agent。 Agent化的 SSM（Agentic SSMs）可能成為神經圖靈機（Neural Turing Machines，一種早期的嘗試，旨在通過外部記憶來增強神經網絡能力的模型）的真正繼承者。

通過“復述”來操控注意力（Manipulate Attention Through Recitation）

如果你使用過 Manus，你可能已經注意到一個有趣的現象：在處理復雜任務時，它傾向于創建一個 todo.md 文件，并隨著任務的進展逐步更新它，勾掉已完成的項目。

這不僅僅是一種可愛的行為——它是一種有意操控注意力的機制。

在 Manus 中，一個典型的任務平均需要大約 50 次工具調用。這是一個很長的循環——而且由于 Manus 依賴大語言模型進行決策，它很容易偏離主題或忘記早期的目標，尤其是在長上下文或復雜任務中。

通過不斷重寫待辦事項列表，Manus 正在將其目標“復述”到上下文的末尾。這將全局計劃推入模型的近期注意力范圍，避免了“迷失在中間”（lost-in-the-middle，指大模型在處理長上下文時，容易忽略中間部分信息的現象）的問題，并減少了目標偏離。實際上，它是在使用自然語言來引導自己的注意力偏向任務目標——而無需特殊的架構更改。

保留錯誤的內容（Keep the Wrong Stuff In）

Agent會犯錯。這不是一個 bug——這是現實。語言模型會產生幻覺，環境會返回錯誤，外部工具會行為異常，意想不到的邊緣情況（edge cases）也時常出現。在多步驟任務中，失敗不是例外，而是循環的一部分。

然而，一種常見的沖動是隱藏這些錯誤：清理痕跡（trace），重試操作，或者重置模型的狀態，然后把它交給神奇的“溫度參數”（temperature，一個控制模型輸出隨機性的參數）。這感覺更安全、更可控。但這是有代價的：抹去失敗就移除了證據。沒有證據，模型就無法適應。

根據我們的經驗，改進 Agent行為最有效的方法之一簡單得令人意外：將走錯的彎路保留在上下文中。當模型看到一個失敗的操作——以及由此產生的觀測或堆棧跟蹤（stack trace，一種顯示程序出錯時函數調用序列的報告）——它會含蓄地更新其內部信念。這會使其先驗（prior，指模型在看到新證據之前的既有信念）偏離類似的操作，從而減少重復同樣錯誤的機會。

事實上，我們相信錯誤恢復是真正 Agent行為最清晰的指標之一。然而，在大多數學術工作和公開基準測試中，它仍然沒有得到充分的體現，這些工作和測試通常關注在理想條件下的任務成功率。

不要被“少樣本”所困（Don't Get Few-Shotted）

少樣本提示（Few-shot prompting）是改進大語言模型輸出的常用技術。但在 Agent系統中，它可能會以微妙的方式適得其反。

語言模型是出色的模仿者；它們會模仿上下文中的行為模式。如果你的上下文中充滿了相似的過往“行動-觀測”對，模型將傾向于遵循這種模式，即使它已不再是最佳選擇。

在涉及重復性決策或行動的任務中，這可能很危險。例如，當使用 Manus 幫助審查一批 20 份簡歷時， Agent常常會陷入一種節奏——僅僅因為它在上下文中看到了這些行為，就重復類似的操作。這會導致偏離（drift）、過度泛化（overgeneralization），有時還會產生幻覺。

解決方法是增加多樣性。Manus 在行動和觀測中引入了少量結構化的變體——不同的序列化模板、替代性的措辭、順序或格式上的微小噪音。這種受控的隨機性有助于打破模式，并調整模型的注意力。

換句話說，不要讓自己陷入“少樣本”的窠臼。你的上下文越統一，你的 Agent就越脆弱。

結論

上下文工程（Context engineering）仍然是一門新興的科學——但對于 Agent系統來說，它已經至關重要。模型可能正在變得更強、更快、更便宜，但再強的原始能力也無法取代對記憶、環境和反饋的需求。你如何塑造上下文，最終定義了你的 Agent的行為方式：它的運行速度、恢復能力以及擴展的程度。

在 Manus，我們通過反復的重寫、走過的死胡同以及對數百萬用戶的真實世界測試，學到了這些教訓。我們在此分享的一切都不是普適的真理——但這些是為我們奏效的模式。如果它們能幫助你哪怕避免一次痛苦的迭代，那么這篇文章就完成了它的使命。

Agent的未來將由一個個上下文構建而成。請精心設計它們。

1

引用文章介紹

在原文中，作者引用了一些重要的概念和技術，以下是對這些引用的簡要介紹：

Manus：Manus是一個基于AI的自主 Agent平臺，旨在執行復雜的多步驟任務。它能夠模擬人類操作計算機，通過一系列工具使用來完成從信息收集到數據分析，再到內容創作等多種任務。Manus的核心理念是"交付成果"，而非僅僅提供想法，旨在成為人機協作的下一代范式。

in-context learning：上下文學習（In-context learning）是指大型語言模型（LLMs）在推理時，通過在輸入中提供少量示例（few-shot examples）來學習新任務的能力，而無需進行模型參數的更新或重新訓練。這種能力極大地提高了LLMs的靈活性和適應性，使其能夠快速適應新的任務和領域。

BERT：BERT（Bidirectional Encoder Representations from Transformers）是Google在2018年發布的一種預訓練語言模型。它通過雙向訓練Transformer編碼器來學習語言的上下文表示，極大地推動了自然語言處理領域的發展，并在多項NLP任務中取得了突破性進展。BERT的出現標志著預訓練模型時代的到來，但其應用仍需進行微調。

open information extraction：開放信息抽?。∣pen Information Extraction, Open IE）是一種從非結構化文本中自動提取結構化信息（如實體、關系和事件）的技術。與傳統的需要預定義模式的信息抽取不同，Open IE旨在發現文本中所有可能的、自包含的事實，而無需人工干預或預先構建的本體。

GPT-3：GPT-3（Generative Pre-trained Transformer 3）是OpenAI在2020年發布的一款大型語言模型。它擁有1750億個參數，是當時最大的語言模型之一。GPT-3在生成高質量文本、完成各種語言任務方面表現出色，其強大的上下文學習能力更是引發了廣泛關注，被認為是AI發展史上的一個里程碑。

Flan-T5：Flan-T5是Google在T5模型基礎上進行指令微調（instruction tuning）的系列模型。通過在大量不同任務的指令格式數據上進行訓練，Flan-T5展現出更強的零樣本（zero-shot）和少樣本（few-shot）泛化能力，能夠更好地理解和遵循用戶指令，從而在多種NLP任務中取得優異表現。

KV-cache：KV緩存（Key-Value Cache）是Transformer模型中用于優化推理速度的一種機制。在自回歸生成過程中，模型會重復計算注意力機制中的鍵（Key）和值（Value）矩陣。KV緩存通過存儲這些計算結果，避免了在生成每個新token時重復計算，從而顯著減少了推理時間和計算成本，尤其是在處理長序列時。

autoregressive：自回歸（Autoregressive）是指模型在生成序列時，當前時間步的輸出依賴于之前所有時間步的輸出。在大型語言模型中，這意味著模型會逐個生成token，每個新生成的token都基于其前面已生成的所有token。這種特性使得模型能夠生成連貫且有邏輯的文本，但也意味著對序列前部的任何修改都可能影響后續的生成和緩存效率。

vLLM：vLLM是一個用于大型語言模型推理的高吞吐量和服務框架。它通過PagedAttention等創新技術，顯著提高了LLM的服務吞吐量和效率，并降低了延遲。vLLM支持多種模型和推理優化，是自托管LLM推理的流行選擇。

prefix/prompt caching：前綴/提示緩存（Prefix/prompt Caching）是vLLM等推理框架中的一項優化技術，它允許模型緩存輸入提示（prompt）的KV值。當后續請求具有相同的前綴時，可以直接從緩存中加載這些KV值，從而避免重復計算，顯著提高推理速度和效率，尤其適用于 Agent等場景中重復使用相同系統提示的情況。

MCP：MCP（Model Context Protocol，模型上下文協議）是Anthropic提出的一種標準化AI模型與外部工具交互的協議。它旨在為AI模型提供一種統一的方式來理解和使用工具，從而簡化 Agent系統的開發和集成。MCP的流行反映了AI Agent對外部工具調用能力日益增長的需求。

RAG：檢索增強生成（Retrieval-Augmented Generation, RAG）是一種結合了信息檢索和文本生成的技術。它允許大型語言模型在生成回答之前，從外部知識庫中檢索相關信息，然后利用這些信息來生成更準確、更豐富、更少幻覺的回答。RAG在處理需要最新信息或特定領域知識的任務時尤其有效。

constrained decoding：約束解碼（Constrained Decoding）是一種在大型語言模型生成文本時，強制其輸出符合特定格式、語法規則或預定義模式的技術。通過在解碼過程中限制模型可以選擇的token，可以確保生成的文本滿足特定的結構化要求，例如生成有效的JSON、代碼或函數調用。

state machine：狀態機（State Machine），或有限狀態機（Finite-State Machine, FSM），是一種數學模型，用于描述系統在不同狀態之間轉換的行為。它根據當前狀態和接收到的輸入，決定下一個狀態以及可能執行的動作。在AI Agent中，狀態機可以用于管理工具的可用性，根據 Agent的當前任務和上下文來動態調整其行為。

Hermes format：Hermes格式通常指的是NousResearch開發的Hermes系列模型所使用的指令遵循和函數調用格式。這些模型經過特殊訓練，能夠理解并執行復雜的指令，包括結構化的函數調用。在本文中，它被用作演示不同函數調用模式的示例。

Neural Turing Machines：神經圖靈機（Neural Turing Machines, NTMs）是DeepMind在2014年提出的一種神經網絡架構，它結合了神經網絡的學習能力和圖靈機的外部記憶能力。NTMs旨在解決傳統神經網絡在處理長序列和需要外部記憶的任務時的局限性，為構建更通用、更強大的AI系統提供了新的思路。

temperature：在大型語言模型中，temperature是一個用于控制生成文本隨機性和創造性的參數。較高的temperature值會使模型輸出更具多樣性和隨機性，可能產生更具創造性但有時不那么連貫的文本；較低的值則會使模型輸出更具確定性和保守性，更傾向于選擇概率最高的token。在 Agent錯誤恢復中，有時會通過調整temperature來影響模型的行為。

Few-shot prompting：少樣本提示（Few-shot prompting）是一種提示工程技術，通過在給模型的問題中提供少量完成任務的示例，來引導模型生成符合期望的輸出。這種方法利用了大型語言模型的上下文學習能力，使其能夠在沒有額外訓練的情況下，快速適應新的任務。

1

參考文獻

[1] Manus Blog. Context Engineering for AI Agents: Lessons from Building Manus. https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

[2] Wikipedia. KV cache.https://en.wikipedia.org/wiki/KV_cache

[3] 百度百科. 季逸超.https://baike.baidu.com/item/%E5%AD%A3%E9%80%B8%E8%B6%85/3787689

[4] Wikipedia. In-context learning.https://en.wikipedia.org/wiki/In-context_learning

[5] Wikipedia. BERT (language model).https://en.wikipedia.org/wiki/BERT_(language_model)

[6] Wikipedia. Open information extraction.https://en.wikipedia.org/wiki/Open_information_extraction

[7] Wikipedia. GPT-3.https://en.wikipedia.org/wiki/GPT-3

[8] arXiv. Flan-T5.https://arxiv.org/abs/2210.11416

[9] YouTube. Introducing Manus: The General AI Agent.https://www.youtube.com/watch?v=K27diMbCsuw

[10] Gamigion. China's AI Revolution: Manus, the Game-Changer.https://www.gamigion.com/chinas-ai-revolution-manus-the-game-changer/

[11] Pandayoo. China's Revolutionary AI Agent Set to Disrupt Global Industries.https://pandayoo.com/post/manus-ai-chinas-revolutionary-ai-agent-set-to-disrupt-global-industries/

[12] Fortune. China's Manus follows DeepSeek in challenging U.S. AI lead.https://fortune.com/asia/2025/03/11/china-manus-follows-deepseek-ai/

[13] MSN. Manus AI: China's second DeepSeek moment.https://www.msn.com/en-in/money/news/manus-ai-china-s-second-deepseek-moment/ar-AA1AAsSN

[14] ChinaZ. Manus創始人季逸超：Manus產品基于阿里千問大模型開發.https://www.chinaz.com/ainews/16140.shtml

[15] Facebook. Ji Yichao, co-founder of Manus, disclosed that the ...https://www.facebook.com/nbdnews/videos/ji-yichao-co-founder-of-manus-disclosed-that-the-manus-product-employs-various-f/1229904471997770/

[16] AInvest. Manus responds to the freeze of his X account: He claims ...https://www.ainvest.com/news/manus-responds-freeze-account-claims-involved-cryptocurrency-projects-2503/

[17] Hugging Face. Nous-Hermes-2-Mixtral-8x7B-SFT.https://huggingface.co/NousResearch/Nous-Hermes-2-Mixtral-8x7B-SFT

[18] Yicai Global. The AI agent concept plate is up and down! Netizens left a message ...https://www.yicaiglobal.com/star50news/2025_03_066801167325711040518

[19] AI Magazine. Manus AI is Here. But What's Behind the Hype?https://aimagazine.com/articles/manus-ai-is-here-but-whats-behind-the-hype

[20] Wikipedia. Autoregressive model.https://en.wikipedia.org/wiki/Autoregressive_model

[21] vLLM. vLLM GitHub.https://github.com/vllm-project/vllm

[22] vLLM. Prefix/prompt Caching.https://vllm.ai/docs/concepts/prefix_caching.html

[23] Anthropic. Model Context Protocol.https://www.anthropic.com/news/model-context-protocol

[24] Wikipedia. Retrieval-augmented generation.https://en.wikipedia.org/wiki/Retrieval-augmented_generation

[25] Hugging Face. Constrained Decoding.https://huggingface.co/blog/constrained-decoding

[26] Wikipedia. Finite-state machine.https://en.wikipedia.org/wiki/Finite-state_machine

[27] Wikipedia. Neural Turing machine.https://en.wikipedia.org/wiki/Neural_Turing_machine

[28] Hugging Face. GenerationConfig.temperature.https://huggingface.co/docs/transformers/main_classes/text_generation#transformers.GenerationConfig.temperature

[29] prompting Guide. Few-shot prompting. https://www.promptingguide.ai/techniques/fewshot

點個愛心，再走 吧