看完 Manus、Cursor 分享后的最大收獲：避免 Context 的過度工程化才是關(guān)鍵

毫無疑問，上下文工程的優(yōu)化，仍然是 Agent 創(chuàng)業(yè)公司在新一年都在「卷」的重點(diǎn)。

在實(shí)際落地開發(fā)中，上下文信息的質(zhì)量，很大程度上決定了 Agent 的表現(xiàn)。

Manus 的首席科學(xué)家季逸超在之前訪談中提到過一個(gè)觀點(diǎn)：

初創(chuàng)公司真的應(yīng)該盡可能長時(shí)間地依賴通用模型和上下文工程，而不是過早地構(gòu)建專用模型，也包括微調(diào)。上下文工程是應(yīng)用層和模型層之間最清晰、最實(shí)用的邊界。

做好上下文工程，開發(fā)者能夠在不觸及模型底層權(quán)重的前提下，靈活駕馭模型，同時(shí)還能適應(yīng)快速變化的產(chǎn)品需求。

最近，Cursor 也發(fā)表了一篇文章《Dynamic context discovery》，分享了他們是怎么做上下文管理的。

結(jié)合 Manus、Cursor 這兩家 Agent 領(lǐng)域頭部團(tuán)隊(duì)的思路，我們整理了如何做好上下文工程的一些關(guān)鍵要點(diǎn)。

Cursor 原文：https://cursor.com/cn/blog/dynamic-context-discovery

此前 Founder Park 分享的文章

??關(guān)注 Founder Park，最及時(shí)最干貨的創(chuàng)業(yè)分享

超 19000 人的「AI 產(chǎn)品市集」社群！不錯(cuò)過每一款有價(jià)值的 AI 應(yīng)用。

邀請(qǐng)從業(yè)者、開發(fā)人員和創(chuàng)業(yè)者，飛書掃碼加群：

進(jìn)群后，你有機(jī)會(huì)得到：

• 最新、最值得關(guān)注的 AI 新品資訊；
  

• 不定期贈(zèng)送熱門新品的邀請(qǐng)碼、會(huì)員碼；
  

• 最精準(zhǔn)的AI產(chǎn)品曝光渠道

01「上下文縮減」是最直接有效的策略

在 Agent 的構(gòu)建過程中，會(huì)發(fā)現(xiàn)一個(gè)現(xiàn)象：上下文會(huì)持續(xù)增長，并且是以一種非常特殊的方式增長。

Agent 每調(diào)用一次工具，就會(huì)返回一個(gè)工具的觀測(cè)結(jié)果，這個(gè)結(jié)果會(huì)被追加到聊天記錄中。隨著時(shí)間的推移，消息列表會(huì)越來越長，導(dǎo)致 Agent 在運(yùn)行時(shí)消息數(shù)量出現(xiàn)無限制的爆炸性增長。

Manus 之前提到，典型的任務(wù)大約需要調(diào)用 50 次工具。Anthropic 也提到過類似的情況，生產(chǎn)環(huán)境中的 Agent 可能會(huì)進(jìn)行長達(dá)數(shù)百輪的對(duì)話。

上下文長度的持續(xù)增長，會(huì)導(dǎo)致推理性能斷崖式的下跌。業(yè)內(nèi)叫做「上下文腐爛」（Context Rot），具體表現(xiàn)是：推理變慢、質(zhì)量下降、甚至開始無意義地重復(fù)。

如何解決？業(yè)內(nèi)目前共識(shí)的一個(gè)方法是「上下文卸載（Context Offloading）」，核心思路是別把所有東西都硬塞進(jìn) Agent 的短期記憶里，把它卸載出去。放到上下文窗口之外，但在需要時(shí)，又能被精確地檢索回來。

將信息轉(zhuǎn)移到文件系統(tǒng)中，是目前生產(chǎn)級(jí) Agent 中主流、最 Work 的一種做法。

Cursor：萬物皆可文件化

Cursor 把「卸載」這個(gè)思路，發(fā)揮到了極致。用文件作為基礎(chǔ)單元，將冗長的工具結(jié)果、終端會(huì)話、聊天記錄全部轉(zhuǎn)化成文件。

Cursor 提到，

我們不確定未來 LLM 工具的最佳接口是什么。但文件是一個(gè)簡(jiǎn)單、強(qiáng)大的基礎(chǔ)單元，比發(fā)明一套新抽象要安全得多。

基于這個(gè)思路，Cursor 提出了「動(dòng)態(tài)上下文發(fā)現(xiàn)」（Dynamic Context Discovery）模式。核心是，別急著把信息塞給模型，而是讓模型在需要的時(shí)候自己去找。

Cursor 把這套模式用到了他們的多個(gè)實(shí)際場(chǎng)景中：

• 將冗長的工具結(jié)果轉(zhuǎn)化為文件

工具調(diào)用，特別是 Shell 命令或第三方 MCP（模型上下文協(xié)議），經(jīng)常返回巨大的 JSON 響應(yīng)，瞬間就能撐爆上下文。目前的編程 Agent 通常采取的簡(jiǎn)單粗暴做法是：直接截?cái)噙^長的 Shell 命令或 MCP 結(jié)果，但很可能會(huì)丟失最關(guān)鍵的信息。

Cursor 的做法是，將這些輸出直接寫入到一個(gè)文件，然后在上下文中只告訴 Agent：「結(jié)果在 output.log 里，你自己去看。」Agent 可以先用 tail 命令查看文件末尾，如果需要更多細(xì)節(jié)，再讀取整個(gè)文件。

• 在「總結(jié)」階段引用聊天記錄

當(dāng)模型的上下文窗口被填滿，Cursor 會(huì)觸發(fā)一個(gè)「總結(jié)」步驟，給 Agent 騰出一個(gè)新的上下文窗口，其中包含之前工作的摘要。

但 Agent 的知識(shí)會(huì)在這個(gè)過程中「退化」，因?yàn)椤缚偨Y(jié)」本質(zhì)上是對(duì)上下文的一種有損壓縮。 Cursor 把完整的聊天歷史記錄也看做是一個(gè)文件。當(dāng)觸發(fā)總結(jié)時(shí)，Agent 會(huì)拿到一份摘要，以及一個(gè)指向「歷史記錄文件」的引用。如果 Agent 意識(shí)到摘要中缺少某些它需要的細(xì)節(jié)，它就可以通過搜索這份歷史記錄文件來找回這些信息。

• 將所有集成終端的會(huì)話視為文件

在 Cursor 中，不再需要手動(dòng)復(fù)制粘貼滿屏的終端報(bào)錯(cuò)信息，會(huì)自動(dòng)將集成終端的所有會(huì)話輸出同步到本地文件系統(tǒng)。 提問「為什么我的命令失敗了？」時(shí)，Agent 能直接定位問題，甚至可以使用 grep 這樣的命令，在長篇的服務(wù)器日志中只搜索相關(guān)的錯(cuò)誤行。這種做法模仿了 CLI Agent 的體驗(yàn)，擁有之前的 Shell 輸出作為上下文，但不同的是，它是動(dòng)態(tài)發(fā)現(xiàn)，不是被靜態(tài)注入。

Manus ：一套結(jié)構(gòu)化的可逆、縮減系統(tǒng)

對(duì)比 Cursor「簡(jiǎn)單粗暴」的解決思路，Manus 的做法是，把「上下文縮減」設(shè)計(jì)成了一套有明確觸發(fā)機(jī)制、分階段執(zhí)行的結(jié)構(gòu)化流程。

首先，Manus 的系統(tǒng)會(huì)持續(xù)監(jiān)控上下文長度，設(shè)定一個(gè)遠(yuǎn)低于模型硬件極限的「腐爛前閾值」（Pre-rot Threshold）。

季逸超：你的模型有一個(gè)硬性的上下文限制，比如說 100 萬個(gè) Token，這在今天是相當(dāng)普遍的。但實(shí)際上，大多數(shù)模型在遠(yuǎn)低于這個(gè)值時(shí)性能就開始下降，通常可能在 20 萬個(gè) Token 左右，你會(huì)開始看到我們所說的「上下文腐爛」，比如重復(fù)、推理變慢、質(zhì)量下降等。 所以，通過大量的評(píng)估，識(shí)別出那個(gè)「腐爛前」的閾值非常重要，通常是 12.8 萬到 20 萬個(gè) Token，并將其作為觸發(fā)上下文縮減的條件。

當(dāng)信號(hào)被觸發(fā)后，系統(tǒng)會(huì)啟動(dòng)第一階段的操作：

第一步：緊湊化（Compaction）

這是一種無損、可逆的縮減。核心是，剝離掉任何能從外部狀態(tài)（比如文件系統(tǒng)）重建的信息。

舉個(gè)例子，Agent 調(diào)用了一個(gè)向文件寫入內(nèi)容的工具，這個(gè)操作在歷史記錄中可能包含 path 和 content 兩個(gè)字段。一旦執(zhí)行成功，那個(gè)可能極其冗長的 content 字段就可以被安全地從上下文中剝離，只保留 path。

信息并沒有丟失，它只是被「外部化」了。如果 Agent 在 10 步之后需要再次讀取該文件，它憑借保留的 path 就能輕易將其檢索回來。

Manus 提到，這種可逆性是非常關(guān)鍵的，因?yàn)槟阌肋h(yuǎn)不知道哪個(gè)過去的動(dòng)作會(huì)成為未來的關(guān)鍵。

通常情況下，緊湊化只會(huì)用作最早的 50% 的歷史記錄，來保留最新的、完整的工具調(diào)用作為模型學(xué)習(xí)的范例（Few-shot Examples）。

但緊湊化收益有限。多輪操作后，上下文削減的收益變得微乎其微時(shí)，系統(tǒng)會(huì)啟動(dòng)第二階段：

第二步：摘要化（Summarization）

這是一種有損、但帶保險(xiǎn)的壓縮。把它當(dāng)做最后手段，在執(zhí)行時(shí)需要極其謹(jǐn)慎。

它的「保險(xiǎn)」在于：在生成摘要之前，系統(tǒng)會(huì)更激進(jìn)地將整個(gè)摘要前的完整上下文，轉(zhuǎn)儲(chǔ)（Dump）到一個(gè)文本或日志文件中。 相當(dāng)于給歷史創(chuàng)建了一個(gè)完整的快照存檔。如果模型足夠聰明，它甚至能用 grep 或 glob 自己去這個(gè)日志里撈數(shù)據(jù)。

季逸超：緊湊化是可逆的，而摘要化不是。兩者都減少了上下文長度，但它們的行為方式非常不同。

在進(jìn)行摘要化時(shí)，總是會(huì)使用完整版本的數(shù)據(jù)，不是緊湊版本。

摘要化依然會(huì)保留最后幾次完整的工具調(diào)用記錄。 這能讓模型清楚地知道自己從哪中斷，能平滑地繼續(xù)工作，保持風(fēng)格和語氣的連貫性。

兩個(gè)步驟下來，通過「緊湊化」（Compaction）剝離可重建信息，以及在「摘要化」（Summarization）之前，將完整的上下文轉(zhuǎn)儲(chǔ)（Dump）到日志文件中。實(shí)現(xiàn)上下文縮減。

02給工具搭建一套靈活的行動(dòng)空間

當(dāng) Agent 能力逐步增強(qiáng)，配備的工具集也越來越豐富。

如果將所有工具的冗長描述，都放到上下文窗口中，會(huì)帶來兩個(gè)問題：

• 一是出現(xiàn)上下文混淆（Context Confusion）的情況，工具太多，模型直接懵掉。可能會(huì)調(diào)用錯(cuò)誤的工具，甚至是幻覺出根本不存在的工具。

• 二是最直接的 Token 浪費(fèi)，大多數(shù)工具，在絕大多數(shù)時(shí)候根本不會(huì)被用到。如果，還使用了多個(gè) MCP 服務(wù)器，情況會(huì)變得更糟。

工具過載的問題怎么解決？一個(gè)核心思路是：動(dòng)態(tài)發(fā)現(xiàn)，讓 Agent 自己去找要調(diào)用哪些工具。

Cursor：把工具說明書，全部文件化

Cursor 的策略，更簡(jiǎn)單、粗暴。把所有 MCP 工具、Agent Skills 的詳細(xì)定義，全部都同步到文件夾里，讓 Agent 在需要時(shí)自己去查閱。

在 Cursor 的框架中，分成了索引層和發(fā)現(xiàn)層。

索引層，Agent 的系統(tǒng)提示詞（System Prompt）里只包含一小部分靜態(tài)信息，比如 MCP 工具或 Agent Skills 的名稱列表。

這些工具和技能的詳細(xì)描述、參數(shù)定義、使用方法，則被全部同步到一個(gè)本地文件夾中。當(dāng)模型需要時(shí)，Agent 會(huì)像一個(gè)聰明的程序員一樣，進(jìn)入發(fā)現(xiàn)層，用 grep 或語義搜索，主動(dòng)去文件夾里查找它需要的工具的詳細(xì)信息，然后拉取到上下文中來處理。

Cursor 做了一次 A/B 測(cè)試，結(jié)果發(fā)現(xiàn)，對(duì)于調(diào)用了 MCP 工具的運(yùn)行任務(wù)，這種策略把Token 的總消耗降低了 46.9%。

同時(shí)，Cursor 提到，這種全部文件化的方式，還解鎖了一個(gè)意想不到的能力：向 Agent 傳達(dá)工具的狀態(tài)。

例如，以前如果一個(gè) MCP 服務(wù)器需要重新認(rèn)證，Agent 可能會(huì)直接「忘記」這些工具的存在。但現(xiàn)在，Agent 可以主動(dòng)發(fā)病、告知用戶去重新認(rèn)證。

Manus：設(shè)計(jì)了一套分層的行動(dòng)空間

Manus 認(rèn)為，常見的方法對(duì)工具描述進(jìn)行動(dòng)態(tài)的 RAG，不可行。 因?yàn)閯?dòng)態(tài)加載工具定義，會(huì)「干掉」KV 緩存，且歷史記錄里的舊調(diào)用會(huì)成為陷阱。

季逸超：目前一個(gè)常見的方法是對(duì)工具描述進(jìn)行動(dòng)態(tài)的 RAG，比如，根據(jù)當(dāng)前任務(wù)或狀態(tài)按需加載工具。 但會(huì)導(dǎo)致兩個(gè)問題：首先，由于工具定義位于上下文的開頭，每次變動(dòng)都會(huì)導(dǎo)致你的 KV 緩存重置；最重要的是，模型過去對(duì)那些已被移除的工具的調(diào)用記錄仍然存在于上下文中，這可能會(huì)誤導(dǎo)模型去調(diào)用無效的工具或使用無效的參數(shù)。

為了解決這個(gè)問題，Manus 設(shè)計(jì)了一套分層行動(dòng)空間。把 Agent 的能力劃分為三個(gè)層次：函數(shù)調(diào)用、沙盒工具、軟件包和 API。

• 第一層：原子函數(shù)調(diào)用（Function Calling）

核心層，只包含極少數(shù)固定的、正交的原子函數(shù)，比如：讀寫文件、執(zhí)行 shell 命令、在文件和互聯(lián)網(wǎng)中搜索。因?yàn)檫@層是固定的，所以對(duì) KV 緩存友好，且功能邊界清晰，不會(huì)導(dǎo)致混淆。

• 第二層：沙盒工具（Sandbox Tools）

卸載層。Manus 將絕大多數(shù)工具，格式轉(zhuǎn)換器、語音識(shí)別工具，甚至 MCP 調(diào)用本身（通過一個(gè) MCP CLI 命令行工具），都作為預(yù)裝軟件放在一個(gè)定制的 Linux 虛擬機(jī)沙箱里。 Agent 不在上下文中「看到」這些工具的詳細(xì)定義，更像是一個(gè)真正的開發(fā)者，通過第一層的 shell 命令來動(dòng)態(tài)地與它們交互。比如，它可以用 ls /bin 來查看有哪些可用的工具，或者用 mcp_cli --help 來學(xué)習(xí)如何使用 MCP 命令行工具。

• 第三層：軟件包與API（Packages & APIs）

代碼層。對(duì)于需要大量內(nèi)存計(jì)算或者需要與復(fù)雜第三方服務(wù)交互的任務(wù)，允許 Agent 編寫并執(zhí)行 Python 腳本。比如，分析一整年的股票數(shù)據(jù)，Agent 不會(huì)把原始數(shù)據(jù)加載到上下文中，而是會(huì)寫一個(gè)腳本去完成計(jì)算，只把摘要結(jié)果返回。

季逸超：在這一層，Manus 可以編寫 Python 腳本來調(diào)用預(yù)先授權(quán)的 API 或自定義軟件包。例如，Manus 可能會(huì)使用一個(gè) 3D 設(shè)計(jì)庫進(jìn)行建模，或者調(diào)用一個(gè)金融 API 來獲取市場(chǎng)數(shù)據(jù)。實(shí)際上，我們已經(jīng)代表用戶購買了所有這些 API 并支付了費(fèi)用，這都包含在訂閱里。 所以，我們基本上在 Manus 中預(yù)裝了大量的 API 密鑰，Manus 可以用這些密鑰訪問 API。我認(rèn)為這對(duì)于需要大量內(nèi)存計(jì)算，但又不需要將所有數(shù)據(jù)都推送到模型上下文的任務(wù)來說是完美的。

這套思路，和 CodeAct *論文類似。

代碼是可組合的，可以在一步內(nèi)做很多事。但它同樣不是模式安全的，在代碼上做約束解碼非常非常困難。所以我們認(rèn)為你應(yīng)該為這些功能找到合適的場(chǎng)景。對(duì)我們來說，所有能在一個(gè)編譯器或解釋器運(yùn)行時(shí)內(nèi)處理的事情，我們都用代碼來做；否則，我們就用沙箱工具或函數(shù)調(diào)用。

CodeAct *：《Executable Code Actions Elicit Better LLM Agents》：

https://arxiv.org/pdf/2402.01030

Manus 這套分層設(shè)計(jì)非常優(yōu)雅，而且高效。從模型的角度看，無論想使用第二層還是第三層的復(fù)雜工具，最終都會(huì)通過 L1 的那幾個(gè)原子函數(shù)執(zhí)行。這種接口設(shè)計(jì)，對(duì)模型極度簡(jiǎn)潔，且緩存穩(wěn)定。

03多 Agent 協(xié)作，

需要反復(fù)使用模式、結(jié)構(gòu)化輸出

多個(gè) Agent 之間如何協(xié)作，也是個(gè)難題。

Cognition 之前在博客中提到：不要濫用多 Agent 設(shè)置，因?yàn)楫?dāng)你有很多 Agent 時(shí)，它們之間的信息同步會(huì)成為一場(chǎng)噩夢(mèng)。

怎么利用多 Agent，實(shí)現(xiàn)「上下文隔離」，讓每個(gè)子 Agent 都有自己獨(dú)立的上下文窗口，從而實(shí)現(xiàn)關(guān)注點(diǎn)分離。是一個(gè)核心問題。

Manus 的解決思路是，借鑒 Go 語言：不要通過共享內(nèi)存來通信，而是通過通信來共享內(nèi)存。

把這句話里的「內(nèi)存」替換為「上下文」，就是兩種截然不同的 Agent 協(xié)作模式。

兩種 Agent 協(xié)作模式

• 任務(wù)委托模式：「通過通信」實(shí)現(xiàn)隔離

這是經(jīng)典的主-子 Agent（Master-Sub-agent）設(shè)置。主 Agent 將一個(gè)任務(wù)封裝成一條簡(jiǎn)短、清晰的指令，然后發(fā)送給子 Agent。子 Agent 的上下文是完全獨(dú)立的，從零開始，只包含這條指令。

簡(jiǎn)單來說，主 Agent 發(fā)任務(wù)，子 Agent 交結(jié)果，中間過程免打擾。

這個(gè)模式，適用于「過程不重要，只關(guān)心結(jié)果」的任務(wù)。舉個(gè)例子，主 Agent 需要在一個(gè)大型代碼庫中搜索特定的代碼片段。它只需要委托子 Agent：「在 A 項(xiàng)目中找到所有調(diào)用了 some_function 的地方」，然后等待返回結(jié)果列表即可。主 Agent 不關(guān)心子 Agent 是如何使用 grep 或其他工具完成搜索的。

在內(nèi)部，Manus 將這種模式叫做「Agent 即工具」。從主 Agent 視角，它只是調(diào)用了 advanced_search 函數(shù)，但背后實(shí)際上是另一個(gè)擁有獨(dú)立工作流的子 Agent 在執(zhí)行。

• 信息同步模式：「通過共享上下文」實(shí)現(xiàn)協(xié)作

但對(duì)于更復(fù)雜、需要完整歷史記錄的場(chǎng)景，簡(jiǎn)單的任務(wù)委托是遠(yuǎn)遠(yuǎn)不夠的。

Manus 的思路是，通過共享上下文來實(shí)現(xiàn)協(xié)作。子 Agent 被創(chuàng)建時(shí)，能夠看到主 Agent完整的先前上下文，包括所有的歷史工具調(diào)用和觀察。但這個(gè)子 Agent 擁有自己獨(dú)立的系統(tǒng)提示詞和新的行動(dòng)空間。

這種模式，更適用于高度依賴歷史信息、需要綜合分析的任務(wù)。比如，在進(jìn)行一項(xiàng)深度研究任務(wù)時(shí)，最終的研究報(bào)告需要綜合大量的中間搜索結(jié)果和筆記。

如果使用第一種通信模式，主 Agent 需要將所有中間產(chǎn)物寫入文件，再讓子 Agent 去一一讀取，這會(huì)造成巨大的延遲和額外的 Token 消耗。在這種情況下，直接讓子 Agent 繼承完整的上下文反而會(huì)更高效。

但 Manus 也提到，共享上下文的模式成本是相當(dāng)昂貴的。因?yàn)槊總€(gè)子 Agent 啟動(dòng)時(shí)都需要 Prefill 一個(gè)非常大的輸入，并且因?yàn)橄到y(tǒng)提示詞不同，無法復(fù)用主 Agent 的 KV 緩存，所以必須支付全價(jià)。

所以，需要根據(jù)任務(wù)的性質(zhì)，靈活地在這兩種模式中間進(jìn)行選擇。

多 Agent 通信，發(fā)信息不難，難的是收結(jié)果

多 Agent 通信的一個(gè)難點(diǎn)是「接收」，如何從多個(gè)并行工作的子 Agent 那里，獲得結(jié)構(gòu)一致、內(nèi)容準(zhǔn)確的輸出？

Manus 設(shè)計(jì)了一套內(nèi)部代號(hào)叫做「Agent 化的 MapReduce」的系統(tǒng)。簡(jiǎn)單來說，

• 共享沙箱

每個(gè) Manus 會(huì)話都在一個(gè)完整的虛擬機(jī)沙箱中運(yùn)行。當(dāng)主 Agent 創(chuàng)建子 Agent 時(shí)，共享同一個(gè)沙箱。這意味著，共享同一個(gè)文件系統(tǒng)，信息的傳遞可以簡(jiǎn)單到只傳遞不同的文件路徑，解決了輸入信息同步的問題。

• 輸出模式（Schema）

這是關(guān)鍵。主 Agent 在創(chuàng)建子 Agent 之前，必須先定義一個(gè)輸出的 Schema。這個(gè)模式就是一份強(qiáng)制執(zhí)行的 API 合同，規(guī)定了子 Agent 最終必須返回什么樣的數(shù)據(jù)結(jié)構(gòu)。

• 約束解碼

子 Agent 有一個(gè)專用工具 submit_result。Manus 使用約束解碼（Constrained Decoding）技術(shù)，強(qiáng)制子 Agent 提交的結(jié)果，必須嚴(yán)格符合主 Agent 定義的 Schema。

這套設(shè)計(jì)的核心思路是，無論是做摘要還是 Agent 間通信，都反復(fù)使用模式和結(jié)構(gòu)化輸出作為一種「契約」，來保證信息以結(jié)構(gòu)化、完整的方式傳遞。

04最后，聊聊兩家的設(shè)計(jì)哲學(xué)

最后，回到原點(diǎn)，聊聊這兩家的上下文工程設(shè)計(jì)哲學(xué)。

Cursor 的「Dynamic Context Discovery」，強(qiáng)調(diào)：少即是多。Cursor 認(rèn)為，在最開始提供給模型的細(xì)節(jié)越少，效果反而越好，因?yàn)槟茏?Agent 更輕松地自行抓取相關(guān)的上下文。

Manus 的思路是：「少構(gòu)建，多理解」，避免上下文的過度工程化。上下文工程的目標(biāo)是讓模型的工作變得更簡(jiǎn)單，而不是更難。

季逸超：回顧 Manus 發(fā)布以來的六七個(gè)月，我們見過的最大的飛躍，不是來自增加了更多花哨的上下文管理層或巧妙的檢索技巧，它們都來自于簡(jiǎn)化，來自于移除不必要的技巧，以及對(duì)模型多一點(diǎn)的信任。 每一次我們簡(jiǎn)化架構(gòu)，系統(tǒng)都會(huì)變得更快、更穩(wěn)定、更智能。上下文工程的目標(biāo)是讓模型的工作變得更簡(jiǎn)單，而不是更難。

兩家的實(shí)踐大方向都是，從「如何把更多信息塞進(jìn)上下文」，變成「怎么給 Agent 創(chuàng)建一個(gè)信息豐富、易于探索的外部環(huán)境」。

引用寶玉老師的一句話：未來，隨著基模能力的提升，把主動(dòng)權(quán)交給模型會(huì)是一個(gè)趨勢(shì)。

轉(zhuǎn)載原創(chuàng)文章請(qǐng)?zhí)砑游⑿牛篺ounderparker