編輯 | 雲昭
OpenAI 和微軟正在宣傳一些錯誤的Agent理念！OpenAI 的 Swarm 走的是一條「歧途」！
剛過去的週末，Devin 共同創辦人 Walden Yan 發布的一條貼文可謂語出驚人，引起了業界的關注和討論。
Walden Yan 先是在貼文中含蓄地說道：
我看到很多人在建構智能體時犯了同樣的錯誤，所以我們分享了一些我們常用的原則。
隨後在部落格文中進一步點名 OpenAI 和微軟，稱兩者旗下的 Swarm 和 AutoGen 這兩款開源產品庫正在積極推廣一些錯誤的代理建構理念，並明確指出是二者所推薦的多代理架構的建構方式是錯誤的！
Yan 在文章開頭直截了當地批評道：
「（現在市面上）多智能體框架的表現遠不如預期。我想基於我們的試錯經驗，分享一些建構智能體的原則，並解釋為何一些看似誘人的構想，在實踐中卻糟糕透頂。」
這篇文章從 Devin 的視角揭示了業界建構 Agent 的現況：多智能體雖然看起來很酷，但 2 年多過去，除了最基本的套路外，依舊仍在匍匐式摸索。
建構Agent，我們仍然處於「原始 HTML + CSS」時代！真正的生產級環境，完全是另外一回事！
Yan 在部落格文中解釋了原因，指出目前的大模型智能體還不具備穩定的長上下文協同對話能力，所以根本不能完成主智能體和子智能體的並行工作，並提出了「共享上下文原則」和「行為暗含決策」兩個核心原則的重要性。
此外，Yan 還舉了幾個不錯的有力證據，例如：Claude Code 是一個具有子任務能力的智能體，但它從不並行運行主智能體與子智能體；子智能體通常只用來「回答問題」，不涉及寫程式碼。
可以說，這絕對不是「蹭熱度」OpenAI、微軟，是有很多真材實料輸出給大家。
話不多說，這就為大家奉上原文。
背景說明
Devin 可以說是自 ChatGPT 誕生以來最早出圈的 AI 程式設計智能體。近日，Devin 團隊發現：其實市面上多智能體框架的表現遠不如預期。
許多開發者自然而然地被多智能體（Multi-Agent）架構所吸引，它透過將複雜任務分解給多個並行工作的子智能體來提升效率。然而，這種看似高效的架構實則非常脆弱，容易因上下文共享不充分和決策衝突而導致系統性失敗。
Yan 表示：「我想基於我們的試錯經驗，分享一些建構智能體的原則，並解釋為何一些看似誘人的構想，在實踐中卻糟糕透頂。」
OpenAI 和微軟在鼓吹錯誤的理念
現在的Agent還處於
「HTML + CSS」的拼湊時代
「多智能體框架的表現遠不如預期。我想基於我們的試錯經驗，分享一些建構智能體的原則，並解釋為何一些看似誘人的構想，在實踐中卻糟糕透頂。」
本文中，我們將逐步推導出以下兩個核心原則：
共享上下文
行為暗含決策
為什麼要關注「原則」？
HTML 發布於 1993 年。2013 年，Facebook 推出了 React。到了 2025 年，React 及其後代幾乎統治了網站與 App 的開發方式。為什麼？因為 React 不只是寫程式碼的腳手架，它是一種哲學。你一旦採用 React，就等於接受了響應式、模組化的建構範式。而這一點，對早期的網頁開發者而言並非顯而易見。
今天，在建構基於大模型的 AI 智能體領域，我們仍然處於「原始 HTML + CSS」時代——還在摸索如何拼湊各種部件，才能打造出良好的體驗。目前為止，除了最基本的套路外，還沒有一種智能體建構方式成為真正的行業標準。
更糟的是，像 OpenAI 的 Swarm 或 微軟的 Autogen 這類函式庫，竟然還在鼓吹一種我們認為錯誤的架構方式：多智能體架構。我會解釋為什麼這是一條歧途。
當然，如果你是初學者，依然有很多資源可以幫助你搭好基本結構，但建構嚴肅的生產級應用，完全是另一回事。
建構長時運行智能體
為什麼需要上下文工程
讓我們從可靠性講起。當智能體需要長時間運行、並維持連貫的對話與行為時，必須採取某些機制來避免錯誤的逐步累積——否則系統會很快崩潰。而這一切的核心，就是我們所說的：上下文工程。
到了 2025 年，大模型已經非常聰明。但即使是最聰明的人，如果沒有上下文，也無法高效完成任務。
「Prompt Engineering（提示工程）」這一術語最初是指手動設計任務提示。而「Context Engineering（上下文工程）」是它的進階版，強調在一個動態系統中自動建構上下文。這是建構 AI 智能體時最重要的工程任務。
一個常見架構的例子：
主智能體將任務拆解為多個部分
分派子智能體分別執行
最後將各個子任務結果合併
這種方式對擁有並行元件的任務看上去很誘人，但實際上非常脆弱。
例如任務是「建構 Flappy Bird 遊戲的複製版」。你拆成兩個子任務：
子任務1：製作背景與綠色管道；
子任務2：製作可上下飛的鳥。
然而子智能體 1 弄錯了，做了一個超級瑪利歐風格的背景；子智能體 2 做的鳥不但不符合遊戲資產的風格，行為也不對。最後主智能體要把這兩個「不搭調」的結果硬湊在一起，幾乎是災難。
這不是瞎編，現實世界中的任務往往充滿細節和歧義。而你可能會以為「把原始任務上下文也發給子智能體」就可以解決問題？不夠的。因為真實系統往往是多輪對話，工具調用混雜，任何一個細節都可能影響任務理解。
原則 1：共享上下文，不僅共享消息，而是完整的智能體軌跡（trace）
重新設計你的系統，確保每個子智能體都擁有前一個智能體的上下文軌跡。
但問題還沒完。如果你給同樣的任務，這次可能得到了風格完全不一致的背景和鳥。為什麼？因為子智能體之間看不到彼此的工作過程，於是預設了互相矛盾的隱含前提。
原則 2：行為暗含決策，而決策不一致將導致錯誤結果
我想強調：原則1與原則2極其關鍵，幾乎不應被打破。
任何違背這兩個原則的架構，預設都應被淘汰。
你可能會覺得這限制太多，但實際上還有很多架構設計空間可以探索。例如最簡單的一種方式：線性單執行緒智能體。
優點是上下文連續。問題是：當任務巨大、上下文視窗溢出，就會出問題。
有沒有辦法改進？當然有，只是更複雜一些。
說實話，簡單的架構已經足夠了，但對於那些真正需要處理長期任務，並且願意付出努力的人來說，還可以做得更好。解決這個問題的方法有很多，但今天我只介紹建構更強長時智能體的一種方式——
我們引入一個專門的 LLM 模型，用於「壓縮」歷史上下文，將其提煉為關鍵的事件、決策和資訊。這件事非常難，需要你理解什麼才是真正重要的資訊，並建立一個擅長提煉的系統。
有時你甚至需要微調一個小模型來做這件事——我們在 Cognition 就做過這類工作。
它的好處是：可以在更長時間尺度上保持上下文一致性。儘管最終還是會遇到極限，但這是往前邁出的一大步。
原則的實際應用：
兩個不錯的智能體設計
作為智能體建構者，你應該確保系統中每個行為，都能基於已有決策的上下文來執行。
理想狀態是：所有動作彼此可見。但由於上下文視窗與資源限制，這並不總是可行。所以你需要在「可靠性 vs 系統複雜度」之間做出權衡。
以下是一些現實現例：
Claude Code 的子智能體設計
截至 2025 年 6 月，Claude Code 是一個具有子任務能力的智能體。但它從不並行運行主智能體與子智能體。子智能體通常只用來「回答問題」，不涉及寫程式碼。
為什麼？因為子智能體缺乏主智能體的上下文，無法勝任複雜任務。若運行多個子智能體，很可能得到互相衝突的答案。
這樣設計的好處是：子智能體的查詢不會污染主智能體的歷史，可讓主智能體保留更長的上下文軌跡。
Claude Code 的設計者有意選擇了簡單可靠的設計。
Edit Apply 模型
2024 年，很多模型還不擅長修改程式碼。於是流行一種叫「Edit-Apply Model」的做法：
大模型生成「Markdown 格式」的改動說明
小模型根據這個說明，重寫整個程式碼文件
雖然這比大模型直接輸出程式碼差異更靠譜，但也有問題：小模型可能誤解說明中的歧義，從而做出錯誤修改。
到了 2025 年，越來越多的系統選擇將「改動決策 + 應用改動」合併為一個步驟，由單個模型完成，提高了整體可靠性。
目前多智能體並不擅長溝通協作
你可能會想：我們能不能讓多個決策者「交流」，像人類一樣溝通、達成一致？
理論上好，但目前的大模型智能體還不具備穩定的長上下文協同對話能力。人類的高效溝通靠的是複雜的元認知與語言技巧，這不是現在智能體擅長的。
多智能體概念早在 ChatGPT 時代就開始流行了。但截至 2025 年，這種系統仍然非常脆弱：決策分散、上下文共享困難、容錯率低。
我相信未來單智能體能力提升後，智能體之間的高效協作將「順帶實現」，那將是並行性和效率的大突破。
邁向更通用的理論
這些關於「上下文工程」的原則，可能會成為未來建構智能體的標準方法論的一部分。
我們在 Cognition 內部不斷將這些原則落實在工具和框架中，也在不斷試錯、迭代。當然，我們的理論也不是完美的，領域在發展，我們也需保持靈活性和謙遜。
員工：老闆，停止洩密好不
網友：我們還要更多
這篇文章引起了不少建構智能體的人士的共鳴。「看來不止我一個人遇到了這些問題！」
甚至 Devin 的同事也忍不住勸這位口無遮攔的老闆：嘿，老闆，別洩密呀！
也有網友認為，文中提到的一些觀點有待商榷。例如文中討論的主從代理並行處理的缺點。有網友認為：
這些缺點可能只適用於程式碼編輯領域。只要任務具有清晰的輸入和輸出、無副作用且只需有限的上下文傳遞，就應該能夠協調好它們之間的執行，這和建構資料管線和函數式程式設計是一樣的道理。
還有一位網友支持這種觀點。
「這將特定於域和子代理。但一個簡單的方法是首先傳入完整的上下文視窗，並在子代理完成時確定關鍵部分是什麼。」
用於建構特定於任務的系統提示以進行上下文壓縮。 對獲取完整提示和壓縮提示的代理運行 A/B 測試。如果發現差異，可以詢問使用完整提示的代理，是什麼導致它執行了不同的部分。並將這些差異合併到壓縮提示中。這可以透過廣泛使用 AI 來實現自動化。
最終，A/B 版本應該會趨於一致。 這樣你可以繼續使用系統提示和模型來壓縮上下文，或者您可以從此上下文壓縮工具收集樣本來微調模型並加快速度並節省一些錢。
這位網友還表示：如果你使用像 o3 這樣的模型，那麼模型對於為什麼能夠或不能完成某項任務的推理會非常好，只需向他們詢問如何改進事情的想法就可以取得很大進展。
一位網友更是直接在 Claude Research 上實際測試了一番：截圖上顯示，非程式設計任務上，大模型還是可以 hold 住 5 個並行運行的智能體的！
「嘗試了一下 Claude Research，在非程式設計任務上它會同時運行 5 個（子任務）。結論也很自然：混合式架構才是正解。」
關於這一點，Yan 有些懷疑，並解釋道：
「並行讀取（readonly）檔案的確問題不大，但我懷疑它其實只是一個傳統工具，用來收集多個資訊來源，供主智能體進行綜合。」
除此之外，網友的討論中還有兩個分歧點：其一是LLM 執行摘要提取（trace distillation）是否可靠？
網友 EddyLeeKhane 持否定態度，他認為壓縮歷史上下文容易出現「幻覺」和錯判關鍵點，反而破壞上下文。
當然，不少評論者則默認為這是向長任務擴展的可行方法。
不過據小編了解，壓縮歷史是否比「強上下文保持」更有效，尚無統一答案，依賴具體模型表現和 trace 設計。
其二，單執行緒的智能體是否過於限制性能？
網友 Adam Butler 提出質疑：單執行緒限制了並發處理的能力，未來必須依賴 o3 甚至更快模型才能實用。這也是 Yan 文中的觀點——目前單智能體的性能還不夠好和穩定。
好了，只能說現在的代理建構技術，還有很長很遠的路要走。不過也正因如此，我們也看到了前所未有的創新的機會，例如 Anthropic 的 MCP，正在解決智能體跟工具之間的調用問題，再例如谷歌的 A2A 協定，再例如今天 Devin 提到的「上下文工程」，又何嘗不是一種新希望呢？
對於此，各位大佬有哪些看法呢？歡迎評論區拍磚。
參考連結：
https://cognition.ai/blog/dont-build-multi-agents#principles-of-context-engineering
——好文推薦——
孤勇者一路對線谷歌！不靠廣告活著，更不存在SEO、數據追蹤，3年突破5萬付費用戶，實現盈利！網友：支持！這是另一種網際網路！
o3 pro一手真體驗！上下文喂到斷供！大神：o3 pro不會聊天，上帝渴望上下文，認知能力降維打擊Gemini、Claude