編輯 | 云昭

OpenAI 和 微軟正在宣傳一些錯誤的 Agent 理念！OpenAI 的 Swarm 走的是一條“歧路”！

剛剛過去的周末，Devin 聯合創始人 Walden Yan 發布了的帖子語出驚人，引起了業界的關注和討論。

Walden Yan 先是在帖子中含蓄地說道：

我看到很多人在構建智能體時犯了同樣的錯誤，所以我們分享了一些我們常用的原則。

然后再博文中進一步點名 OpenAI 和微軟，稱兩者旗下的 Swarm 和 AutoGen 這兩款開源產品庫正在積極推廣一些錯誤的代理構建理念，并明確指出是二者所推薦的多代理架構的構建方式是錯誤的！

圖片

Yan 在文章開頭直截了當地批評道：

“（現在市面上）多智能體框架的表現遠不如預期。我想基于我們的試錯經驗，分享一些構建智能體的原則，并解釋為何一些看似誘人的構想，在實踐中卻糟糕透頂?！?/p>

這篇文章從 Devin 的視角揭示了業內構建 Agent 的現狀：多智能體雖然看起來很酷，但 2 年多過去，除了最基本的套路外，依舊仍在匍匐式摸索。

構建Agent，我們仍然處于“原始 HTML + CSS”時代！真正的生產級環境，完全是另外一回事！

Yan 在博文中解釋了原因，指出目前的大模型智能體還不具備穩定的長上下文協同對話能力，所以根本不能完成主智能體和子智能體的并行工作，并提出了“共享上下文原則”和“行為暗含決策”兩個核心原則的重要性。 

此外，Yan 還舉了幾個不錯的有力證據，比如：Claude Code 是一個具有子任務能力的智能體，但它從不并行運行主智能體與子智能體；子智能體通常只用來“回答問題”，不涉及寫代碼。

可以說，這絕對不是“碰瓷” OpenAI、微軟，是有很多真東西輸出給了大家。

話不多說，這就為大家奉上原文。 

一、背景說明

Devin 可以說是自 ChatGPT 誕生以來最早出圈的 AI 編程智能體。近日，Devin 團隊發現：其實市面上多智能體框架的表現遠不如預期。

許多開發者自然而然地被多智能體（Multi-Agent）架構所吸引，它通過將復雜任務分解給多個并行工作的子智能體來提升效率。然而，這種看似高效的架構實則非常脆弱，容易因上下文共享不充分和決策沖突而導致系統性失敗。

Yan 表示：我想基于我們的試錯經驗，分享一些構建智能體的原則，并解釋為何一些看似誘人的構想，在實踐中卻糟糕透頂?！?/p>

二、OpenAI 和微軟在鼓吹錯誤的理念，現在的Agent還處于“HTML + CSS”的拼湊時代

“多智能體框架的表現遠不如預期。我想基于我們的試錯經驗，分享一些構建智能體的原則，并解釋為何一些看似誘人的構想，在實踐中卻糟糕透頂?！?/p>

本文中，我們將逐步推導出以下兩個個核心原則：

• 共享上下文
• 行為暗含決策

為什么要關注“原則”？

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 系統復雜度”之間做出權衡。

以下是一些現實例子：

1.Claude Code 的子智能體設計

截至 2025 年 6 月，Claude Code 是一個具有子任務能力的智能體。但它從不并行運行主智能體與子智能體。子智能體通常只用來“回答問題”，不涉及寫代碼。

為什么？因為子智能體缺乏主智能體的上下文，無法勝任復雜任務。若運行多個子智能體，很可能得到互相沖突的答案。

這樣設計的好處是：子智能體的查詢不會污染主智能體的歷史，可讓主智能體保留更長的上下文軌跡。

Claude Code 的設計者有意選擇了簡單可靠的設計。

2.Edit Apply 模型

2024 年，很多模型還不擅長修改代碼。于是流行一種叫“Edit-Apply Model”的做法：

• 大模型生成“Markdown 格式”的改動說明
• 小模型根據這個說明，重寫整個代碼文件

雖然這比大模型直接輸出代碼 diff 更靠譜，但也有問題：小模型可能誤解說明中的歧義，從而做出錯誤修改。

到了 2025 年，越來越多的系統選擇將“改動決策 + 應用改動”合并為一個步驟，由單個模型完成，提高了整體可靠性。

五、目前多智能體并不擅長溝通協作

你可能會想：我們能不能讓多個決策者“交流”，像人類一樣溝通、達成一致？

理論上好，但目前的大模型智能體還不具備穩定的長上下文協同對話能力。人類的高效溝通靠的是復雜的元認知與語言技巧，這不是現在智能體擅長的。

多智能體概念早在 ChatGPT 時代就開始流行了。但截至 2025 年，這種系統仍然非常脆弱：決策分散、上下文共享困難、容錯率低。

我相信未來單智能體能力提升后，智能體之間的高效協作將“順帶實現”，那將是并行性和效率的大突破。

六、邁向更通用的理論

這些關于“上下文工程”的原則，可能會成為未來構建智能體的標準方法論的一部分。

我們在 Cognition 內部不斷將這些原則落實在工具和框架中，也在不斷試錯、迭代。當然，我們的理論也不是完美的，領域在發展，我們也需保持靈活性和謙遜。

七、員工：老板，停止泄密好不

網友：我們還要更多

這篇文章引起了不少構建智能體的人士的共鳴?！翱磥聿恢刮乙粋€人遇到了這些問題！”

圖片

圖片

甚至以為以為Devin的同事忍不住勸這位口無遮攔的老板：嘿，老板，別泄密呀！

圖片

也有網友認為，文中提到的一些觀點有待商榷。比如文中討論的主從代理并行處理的缺點。有網友認為：

這些缺點可能只適用于代碼編輯領域。只要任務具有清晰的輸入和輸出、無副作用且只需有限的上下文傳遞，就應該能夠協調好它們之間的執行，這和構建數據流水線和函數式編程是一樣的道理。

圖片

還有一位網友支持這種觀點。

圖片

“這將特定于域和子代理。但一個簡單的方法是首先傳入完整的上下文窗口，并在子代理完成時確定關鍵部分是什么。”

用于構建特定于任務的系統提示以進行上下文壓縮。 對獲取完整提示和壓縮提示的代理運行 A/B 測試。如果發現差異，可以詢問使用完整提示的代理，是什么導致它執行了不同的部分。并將這些差異合并到壓縮提示中。這可以通過廣泛使用 AI 來實現自動化。

最終，A/B 版本應該會趨于一致。  這樣你可以繼續使用系統提示和模型來壓縮上下文，或者您可以從此上下文壓縮工具收集樣本來微調模型并加快速度并節省一些錢。  

這位網友還表示：如果你使用像 o3 這樣的模型，那么模型對于為什么能夠或不能完成某項任務的推理會非常好，只需向他們詢問如何改進事情的想法就可以取得很大進展。

一位網友更是直接在 Claude Research 上實際測試了一番：截圖上顯示，非編程任務上，大模型還是可以 hold 住 5 個并行運行的智能體的！

圖片

“嘗試了一下 Claude Research，在非編程任務上它會同時運行 5 個（子任務）。結論也很自然：混合式架構才是正解。”

關于這一點，Yan 有些懷疑，并解釋道：

“并行讀?。╮eadonly）文件的確問題不大，但我懷疑它其實只是一個傳統工具，用來收集多個信息源，供主智能體進行綜合?！?/p>

圖片

除此之外，網友的討論中還有兩個分歧點：其一是LLM 執行摘要提?。╰race distillation）是否可靠？

網友 EddyLeeKhane 持否定態度，他認為壓縮歷史上下文容易出現“幻覺”和錯判關鍵點，反而破壞上下文。

當然，不少評論者則默認為這是向長任務擴展的可行方法。

不過據小編了解，壓縮歷史是否比“強上下文保持”更有效，尚無統一答案，依賴具體模型表現和 trace 設計。

其二，單線程的智能體是否過于限制性能？

網友Adam Butler 提出質疑：單線程限制了并發處理的能力，未來必須依賴 o3 甚至更快模型才能實用。這也是 Yan 文中的觀點——目前單智能體的性能還不夠好和穩定。

好了，只能說現在的代理構建技術，還有很長很遠的路要走。不過也正因如此，我們也看到了前所未有的創新的機會，比如 Anthropic 的 MCP，正在解決智能體跟工具之間的調用問題，再比如谷歌的 A2A 協議，再比如今天 Devin 提到的“上下文工程”，又何嘗不是一種新希望呢？

參考鏈接：https://cognition.ai/blog/dont-build-multi-agents#principles-of-context-engineering