編輯 | 云昭

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

剛剛過(guò)去的周末，Devin 聯(lián)合創(chuàng)始人 Walden Yan 發(fā)布了的帖子語(yǔ)出驚人，引起了業(yè)界的關(guān)注和討論。

Walden Yan 先是在帖子中含蓄地說(shuō)道：

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

然后再博文中進(jìn)一步點(diǎn)名 OpenAI 和微軟，稱(chēng)兩者旗下的 Swarm 和 AutoGen 這兩款開(kāi)源產(chǎn)品庫(kù)正在積極推廣一些錯(cuò)誤的代理構(gòu)建理念，并明確指出是二者所推薦的多代理架構(gòu)的構(gòu)建方式是錯(cuò)誤的！

圖片

Yan 在文章開(kāi)頭直截了當(dāng)?shù)嘏u(píng)道：

“（現(xiàn)在市面上）多智能體框架的表現(xiàn)遠(yuǎn)不如預(yù)期。我想基于我們的試錯(cuò)經(jīng)驗(yàn)，分享一些構(gòu)建智能體的原則，并解釋為何一些看似誘人的構(gòu)想，在實(shí)踐中卻糟糕透頂?！?/p>

這篇文章從 Devin 的視角揭示了業(yè)內(nèi)構(gòu)建 Agent 的現(xiàn)狀：多智能體雖然看起來(lái)很酷，但 2 年多過(guò)去，除了最基本的套路外，依舊仍在匍匐式摸索。

構(gòu)建Agent，我們?nèi)匀惶幱凇霸?HTML + CSS”時(shí)代！真正的生產(chǎn)級(jí)環(huán)境，完全是另外一回事！

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

此外，Yan 還舉了幾個(gè)不錯(cuò)的有力證據(jù)，比如：Claude Code 是一個(gè)具有子任務(wù)能力的智能體，但它從不并行運(yùn)行主智能體與子智能體；子智能體通常只用來(lái)“回答問(wèn)題”，不涉及寫(xiě)代碼。

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

話不多說(shuō)，這就為大家奉上原文。 

一、背景說(shuō)明

Devin 可以說(shuō)是自 ChatGPT 誕生以來(lái)最早出圈的 AI 編程智能體。近日，Devin 團(tuán)隊(duì)發(fā)現(xiàn)：其實(shí)市面上多智能體框架的表現(xiàn)遠(yuǎn)不如預(yù)期。

許多開(kāi)發(fā)者自然而然地被多智能體（Multi-Agent）架構(gòu)所吸引，它通過(guò)將復(fù)雜任務(wù)分解給多個(gè)并行工作的子智能體來(lái)提升效率。然而，這種看似高效的架構(gòu)實(shí)則非常脆弱，容易因上下文共享不充分和決策沖突而導(dǎo)致系統(tǒng)性失敗。

Yan 表示：我想基于我們的試錯(cuò)經(jīng)驗(yàn)，分享一些構(gòu)建智能體的原則，并解釋為何一些看似誘人的構(gòu)想，在實(shí)踐中卻糟糕透頂?！?/p>

二、OpenAI 和微軟在鼓吹錯(cuò)誤的理念，現(xiàn)在的Agent還處于“HTML + CSS”的拼湊時(shí)代

“多智能體框架的表現(xiàn)遠(yuǎn)不如預(yù)期。我想基于我們的試錯(cuò)經(jīng)驗(yàn)，分享一些構(gòu)建智能體的原則，并解釋為何一些看似誘人的構(gòu)想，在實(shí)踐中卻糟糕透頂?！?/p>

本文中，我們將逐步推導(dǎo)出以下兩個(gè)個(gè)核心原則：

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

為什么要關(guān)注“原則”？

HTML 發(fā)布于 1993 年。2013 年，F(xiàn)acebook 推出了 React。到了 2025 年，React 及其后代幾乎統(tǒng)治了網(wǎng)站與 App 的開(kāi)發(fā)方式。為什么？因?yàn)?React 不只是寫(xiě)代碼的腳手架，它是一種哲學(xué)。你一旦采用 React，就等于接受了響應(yīng)式、模塊化的構(gòu)建范式。而這一點(diǎn)，對(duì)早期的網(wǎng)頁(yè)開(kāi)發(fā)者而言并非顯而易見(jiàn)。

今天，在構(gòu)建基于大模型的 AI 智能體領(lǐng)域，我們?nèi)匀惶幱凇霸?HTML + CSS”時(shí)代——還在摸索如何拼湊各種部件，才能打造出良好的體驗(yàn)。目前為止，除了最基本的套路外，還沒(méi)有一種智能體構(gòu)建方式成為真正的行業(yè)標(biāo)準(zhǔn)。

更糟的是，像 OpenAI 的 Swarm 或 微軟的 Autogen 這類(lèi)庫(kù)，居然還在鼓吹一種我們認(rèn)為錯(cuò)誤的架構(gòu)方式：多智能體架構(gòu)。我會(huì)解釋為什么這是一條歧路。

當(dāng)然，如果你是初學(xué)者，依然有很多資源可以幫助你搭好基本結(jié)構(gòu)，但構(gòu)建嚴(yán)肅的生產(chǎn)級(jí)應(yīng)用，完全是另一回事。

三、構(gòu)建長(zhǎng)時(shí)運(yùn)行智能體為什么需要上下文工程 

讓我們從可靠性講起。當(dāng)智能體需要長(zhǎng)時(shí)間運(yùn)行、并維持連貫的對(duì)話與行為時(shí)，必須采取某些機(jī)制來(lái)避免錯(cuò)誤的逐步積累——否則系統(tǒng)會(huì)很快崩潰。而這一切的核心，就是我們所說(shuō)的：上下文工程。

到了 2025 年，大模型已經(jīng)非常聰明。但即使是最聰明的人，如果沒(méi)有上下文，也無(wú)法高效完成任務(wù)。

“Prompt Engineering（提示工程）”這一術(shù)語(yǔ)最初是指手動(dòng)設(shè)計(jì)任務(wù)提示。而“Context Engineering（上下文工程）”是它的進(jìn)階版，強(qiáng)調(diào)在一個(gè)動(dòng)態(tài)系統(tǒng)中自動(dòng)構(gòu)建上下文。這是構(gòu)建 AI 智能體時(shí)最重要的工程任務(wù)。

一個(gè)常見(jiàn)架構(gòu)的例子：

• 主智能體將任務(wù)拆解為多個(gè)部分
• 分派子智能體分別執(zhí)行
• 最后將各個(gè)子任務(wù)結(jié)果合并

圖片

這種方式對(duì)擁有并行組件的任務(wù)看上去很誘人，但實(shí)際上非常脆弱。

比如任務(wù)是“構(gòu)建 Flappy Bird 游戲的克隆版”。你拆成兩個(gè)子任務(wù)：

子任務(wù)1：制作背景與綠色管道；

子任務(wù)2：制作可上下飛的鳥(niǎo)。

然而子智能體 1 弄錯(cuò)了，做了一個(gè)超級(jí)馬里奧風(fēng)格的背景；子智能體 2 做的鳥(niǎo)不但不符合游戲資產(chǎn)的風(fēng)格，行為也不對(duì)。最后主智能體要把這兩個(gè)“不搭調(diào)”的結(jié)果硬拼在一起，幾乎是災(zāi)難。

這不是瞎編，現(xiàn)實(shí)世界中的任務(wù)往往充滿(mǎn)細(xì)節(jié)和歧義。而你可能會(huì)以為“把原始任務(wù)上下文也發(fā)給子智能體”就可以解決問(wèn)題？不夠的。因?yàn)檎鎸?shí)系統(tǒng)往往是多輪對(duì)話，工具調(diào)用混雜，任何一個(gè)細(xì)節(jié)都可能影響任務(wù)理解。

原則 1：共享上下文，不僅共享消息，而是完整的智能體軌跡（trace）

重新設(shè)計(jì)你的系統(tǒng)，確保每個(gè)子智能體都擁有前一個(gè)智能體的上下文軌跡。

圖片

但問(wèn)題還沒(méi)完。如果你給同樣的任務(wù)，這次可能得到了風(fēng)格完全不一致的背景和鳥(niǎo)。為什么？因?yàn)樽又悄荏w之間看不到彼此的工作過(guò)程，于是默認(rèn)了互相矛盾的隱含前提。

原則 2：行為暗含決策，而決策不一致將導(dǎo)致錯(cuò)誤結(jié)果

我想強(qiáng)調(diào)：原則1與原則2極其關(guān)鍵，幾乎不應(yīng)被打破。

任何違背這兩個(gè)原則的架構(gòu)，默認(rèn)都應(yīng)被淘汰。

你可能會(huì)覺(jué)得這限制太多，但實(shí)際上還有很多架構(gòu)設(shè)計(jì)空間可以探索。比如最簡(jiǎn)單的一種方式：線性單線程智能體。

圖片

優(yōu)點(diǎn)是上下文連續(xù)。問(wèn)題是：當(dāng)任務(wù)巨大、上下文窗口溢出，就會(huì)出問(wèn)題。

圖片

有沒(méi)有辦法改進(jìn)？當(dāng)然有，只是更復(fù)雜一些。

說(shuō)實(shí)話，簡(jiǎn)單的架構(gòu)已經(jīng)足夠了，但對(duì)于那些真正需要處理長(zhǎng)期任務(wù)，并且愿意付出努力的人來(lái)說(shuō)，還可以做得更好。解決這個(gè)問(wèn)題的方法有很多，但今天我只介紹構(gòu)建更強(qiáng)長(zhǎng)時(shí)智能體的一種方式——

圖片

我們引入一個(gè)專(zhuān)門(mén)的 LLM 模型，用于“壓縮”歷史上下文，將其提煉為關(guān)鍵的事件、決策和信息。這件事非常難，需要你理解什么才是真正重要的信息，并建立一個(gè)擅長(zhǎng)提煉的系統(tǒng)。

有時(shí)你甚至需要微調(diào)一個(gè)小模型來(lái)做這件事——我們?cè)?Cognition 就做過(guò)這類(lèi)工作。

它的好處是：可以在更長(zhǎng)時(shí)間尺度上保持上下文一致性。盡管最終還是會(huì)遇到極限，但這是往前邁出的一大步。

四、原則的實(shí)際應(yīng)用：兩個(gè)不錯(cuò)的智能體設(shè)計(jì)

作為智能體構(gòu)建者，你應(yīng)該確保系統(tǒng)中每個(gè)行為，都能基于已有決策的上下文來(lái)執(zhí)行。

理想狀態(tài)是：所有動(dòng)作彼此可見(jiàn)。但由于上下文窗口與資源限制，這并不總是可行。所以你需要在“可靠性 vs 系統(tǒng)復(fù)雜度”之間做出權(quán)衡。

以下是一些現(xiàn)實(shí)例子：

1.Claude Code 的子智能體設(shè)計(jì)

截至 2025 年 6 月，Claude Code 是一個(gè)具有子任務(wù)能力的智能體。但它從不并行運(yùn)行主智能體與子智能體。子智能體通常只用來(lái)“回答問(wèn)題”，不涉及寫(xiě)代碼。

為什么？因?yàn)樽又悄荏w缺乏主智能體的上下文，無(wú)法勝任復(fù)雜任務(wù)。若運(yùn)行多個(gè)子智能體，很可能得到互相沖突的答案。

這樣設(shè)計(jì)的好處是：子智能體的查詢(xún)不會(huì)污染主智能體的歷史，可讓主智能體保留更長(zhǎng)的上下文軌跡。

Claude Code 的設(shè)計(jì)者有意選擇了簡(jiǎn)單可靠的設(shè)計(jì)。

2.Edit Apply 模型

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

• 大模型生成“Markdown 格式”的改動(dòng)說(shuō)明
• 小模型根據(jù)這個(gè)說(shuō)明，重寫(xiě)整個(gè)代碼文件

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

到了 2025 年，越來(lái)越多的系統(tǒng)選擇將“改動(dòng)決策 + 應(yīng)用改動(dòng)”合并為一個(gè)步驟，由單個(gè)模型完成，提高了整體可靠性。

五、目前多智能體并不擅長(zhǎng)溝通協(xié)作

你可能會(huì)想：我們能不能讓多個(gè)決策者“交流”，像人類(lèi)一樣溝通、達(dá)成一致？

理論上好，但目前的大模型智能體還不具備穩(wěn)定的長(zhǎng)上下文協(xié)同對(duì)話能力。人類(lèi)的高效溝通靠的是復(fù)雜的元認(rèn)知與語(yǔ)言技巧，這不是現(xiàn)在智能體擅長(zhǎng)的。

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

我相信未來(lái)單智能體能力提升后，智能體之間的高效協(xié)作將“順帶實(shí)現(xiàn)”，那將是并行性和效率的大突破。

六、邁向更通用的理論

這些關(guān)于“上下文工程”的原則，可能會(huì)成為未來(lái)構(gòu)建智能體的標(biāo)準(zhǔn)方法論的一部分。

我們?cè)?Cognition 內(nèi)部不斷將這些原則落實(shí)在工具和框架中，也在不斷試錯(cuò)、迭代。當(dāng)然，我們的理論也不是完美的，領(lǐng)域在發(fā)展，我們也需保持靈活性和謙遜。

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

網(wǎng)友：我們還要更多

這篇文章引起了不少構(gòu)建智能體的人士的共鳴?！翱磥?lái)不止我一個(gè)人遇到了這些問(wèn)題！”

圖片

圖片

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

圖片

也有網(wǎng)友認(rèn)為，文中提到的一些觀點(diǎn)有待商榷。比如文中討論的主從代理并行處理的缺點(diǎn)。有網(wǎng)友認(rèn)為：

這些缺點(diǎn)可能只適用于代碼編輯領(lǐng)域。只要任務(wù)具有清晰的輸入和輸出、無(wú)副作用且只需有限的上下文傳遞，就應(yīng)該能夠協(xié)調(diào)好它們之間的執(zhí)行，這和構(gòu)建數(shù)據(jù)流水線和函數(shù)式編程是一樣的道理。

圖片

還有一位網(wǎng)友支持這種觀點(diǎn)。

圖片

“這將特定于域和子代理。但一個(gè)簡(jiǎn)單的方法是首先傳入完整的上下文窗口，并在子代理完成時(shí)確定關(guān)鍵部分是什么?！?/p>

用于構(gòu)建特定于任務(wù)的系統(tǒng)提示以進(jìn)行上下文壓縮。 對(duì)獲取完整提示和壓縮提示的代理運(yùn)行 A/B 測(cè)試。如果發(fā)現(xiàn)差異，可以詢(xún)問(wèn)使用完整提示的代理，是什么導(dǎo)致它執(zhí)行了不同的部分。并將這些差異合并到壓縮提示中。這可以通過(guò)廣泛使用 AI 來(lái)實(shí)現(xiàn)自動(dòng)化。

最終，A/B 版本應(yīng)該會(huì)趨于一致。  這樣你可以繼續(xù)使用系統(tǒng)提示和模型來(lái)壓縮上下文，或者您可以從此上下文壓縮工具收集樣本來(lái)微調(diào)模型并加快速度并節(jié)省一些錢(qián)。  

這位網(wǎng)友還表示：如果你使用像 o3 這樣的模型，那么模型對(duì)于為什么能夠或不能完成某項(xiàng)任務(wù)的推理會(huì)非常好，只需向他們?cè)儐?wèn)如何改進(jìn)事情的想法就可以取得很大進(jìn)展。

一位網(wǎng)友更是直接在 Claude Research 上實(shí)際測(cè)試了一番：截圖上顯示，非編程任務(wù)上，大模型還是可以 hold 住 5 個(gè)并行運(yùn)行的智能體的！

圖片

“嘗試了一下 Claude Research，在非編程任務(wù)上它會(huì)同時(shí)運(yùn)行 5 個(gè)（子任務(wù)）。結(jié)論也很自然：混合式架構(gòu)才是正解?！?/p>

關(guān)于這一點(diǎn)，Yan 有些懷疑，并解釋道：

“并行讀取（readonly）文件的確問(wèn)題不大，但我懷疑它其實(shí)只是一個(gè)傳統(tǒng)工具，用來(lái)收集多個(gè)信息源，供主智能體進(jìn)行綜合?！?/p>

圖片

除此之外，網(wǎng)友的討論中還有兩個(gè)分歧點(diǎn)：其一是LLM 執(zhí)行摘要提?。╰race distillation）是否可靠？

網(wǎng)友 EddyLeeKhane 持否定態(tài)度，他認(rèn)為壓縮歷史上下文容易出現(xiàn)“幻覺(jué)”和錯(cuò)判關(guān)鍵點(diǎn)，反而破壞上下文。

當(dāng)然，不少評(píng)論者則默認(rèn)為這是向長(zhǎng)任務(wù)擴(kuò)展的可行方法。

不過(guò)據(jù)小編了解，壓縮歷史是否比“強(qiáng)上下文保持”更有效，尚無(wú)統(tǒng)一答案，依賴(lài)具體模型表現(xiàn)和 trace 設(shè)計(jì)。

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

網(wǎng)友Adam Butler 提出質(zhì)疑：?jiǎn)尉€程限制了并發(fā)處理的能力，未來(lái)必須依賴(lài) o3 甚至更快模型才能實(shí)用。這也是 Yan 文中的觀點(diǎn)——目前單智能體的性能還不夠好和穩(wěn)定。

好了，只能說(shuō)現(xiàn)在的代理構(gòu)建技術(shù)，還有很長(zhǎng)很遠(yuǎn)的路要走。不過(guò)也正因如此，我們也看到了前所未有的創(chuàng)新的機(jī)會(huì)，比如 Anthropic 的 MCP，正在解決智能體跟工具之間的調(diào)用問(wèn)題，再比如谷歌的 A2A 協(xié)議，再比如今天 Devin 提到的“上下文工程”，又何嘗不是一種新希望呢？

對(duì)一次，各位大佬有哪些看法呢？

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

本文轉(zhuǎn)載自??51CTO技術(shù)棧??，作者：云昭