国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

近年來，AIGC與多智能體系統(tǒng)成為熱門概念，產(chǎn)品人也開始幻想通過智能體分工合作解決一切問題。但在實際落地中，多智能體常常成為復(fù)雜、割裂、難以維護(hù)的噩夢。本篇文章將從產(chǎn)品角度揭示：構(gòu)建多智能體或許并不是通往智能未來的最佳路徑，反而可能拖慢協(xié)同效率、模糊交互邊界。

devin產(chǎn)品發(fā)布了一篇文章關(guān)于是否需要構(gòu)建多智能體，講述了自己的看法。以下是原文翻譯。

大語言模型（LLM）智能體的框架一直令人意外地失望。我想根據(jù)我們自己的試錯經(jīng)驗，提供一些構(gòu)建智能體的原則，并解釋為什么一些誘人的想法在實踐中實際上相當(dāng)糟糕。

上下文工程原理

我們將逐步遵循以下原則：

1. 共享上下文

2. 行動蘊含著隱含的決策

為什么要思考原則？

HTML于1993年問世。2013年，F(xiàn)acebook向世界發(fā)布了React。如今到了2025年，React（及其衍生產(chǎn)品）主導(dǎo)著開發(fā)者構(gòu)建網(wǎng)站和應(yīng)用的方式。為什么呢？因為React不只是編寫代碼的框架，更是一種理念。通過使用React，你接受了以響應(yīng)式和模塊化模式構(gòu)建應(yīng)用的方式，如今人們已將其視為標(biāo)準(zhǔn)要求，但早期的網(wǎng)頁開發(fā)者并非總能認(rèn)識到這一點。

在大語言模型（LLM）和構(gòu)建AI智能體的時代，感覺我們?nèi)栽跀[弄原生HTML和CSS，摸索如何將它們組合在一起以創(chuàng)造良好的用戶體驗。除了一些絕對基礎(chǔ)的內(nèi)容外，目前還沒有一種構(gòu)建智能體的單一方法成為標(biāo)準(zhǔn)。

在某些情況下，像OpenAI的https://github.com/openai/swarm和微軟的https://github.com/microsoft/autogen這樣的庫積極推廣一些概念，我認(rèn)為這些概念是構(gòu)建智能體的錯誤方式。具體來說，就是使用多智能體架構(gòu)，我將解釋原因。

話雖如此，如果你剛接觸智能體構(gòu)建，有很多關(guān)于如何搭建基礎(chǔ)框架的資源[1] [2]$。但在構(gòu)建嚴(yán)肅的生產(chǎn)應(yīng)用時，情況就不同了。

構(gòu)建長期運行智能體的理論

讓我們從可靠性開始講起。當(dāng)智能體需要在長時間運行過程中保持可靠，并維持連貫的對話時，你必須采取某些措施來控制復(fù)合錯誤的潛在風(fēng)險。否則，如果不小心，事情很快就會分崩離析?？煽啃缘暮诵脑谟谏舷挛墓こ?。

上下文工程

到2025年，現(xiàn)有的模型將極其智能。但即使是最聰明的人，如果不了解被要求做的事情的背景，也無法有效地完成工作?！疤崾竟こ獭边@個術(shù)語被創(chuàng)造出來，用于描述以理想格式為大語言模型（LLM）聊天機(jī)器人編寫任務(wù)的工作?！吧舷挛墓こ獭眲t是這一概念的更高層次。它涉及在動態(tài)系統(tǒng)中自動完成這項工作。這需要更多的細(xì)微差別，實際上是構(gòu)建AI智能體的工程師的首要任務(wù)。

以一種常見類型的代理為例。這種代理

1. 將其工作分解為多個部分

2. 啟動子代理來處理這些部分

3. 最后將這些結(jié)果整合

這是一種誘人的架構(gòu)，尤其是當(dāng)你在一個包含多個并行組件的任務(wù)領(lǐng)域中工作時。然而，它非常脆弱。關(guān)鍵的失敗點在于：

假設(shè)你的任務(wù)是“制作一個《飛揚的小鳥》克隆版”。

這會被分解為子任務(wù)1“制作一個帶有綠色管道和碰撞箱的移動游戲背景”和子任務(wù)2“制作一只可以上下移動的小鳥”。

結(jié)果發(fā)現(xiàn)子代理1實際上誤解了你的子任務(wù)，開始構(gòu)建一個看起來像《超級馬里奧兄弟》的背景。子代理2為你構(gòu)建了一只鳥，但它看起來不像游戲素材，而且其移動方式與《飛翔的小鳥》中的鳥完全不同。

現(xiàn)在，最終代理只能承擔(dān)起將這兩個溝通失誤的結(jié)果進(jìn)行整合的棘手任務(wù)。

這可能看起來有些牽強(qiáng)，但大多數(shù)現(xiàn)實世界的任務(wù)都有許多細(xì)微差別，所有這些都有可能被誤解。你可能認(rèn)為一個簡單的解決方案是將原始任務(wù)也作為上下文復(fù)制給子代理。這樣，他們就不會誤解自己的子任務(wù)。但請記住，在實際的生產(chǎn)系統(tǒng)中，對話很可能是多輪的，代理可能不得不進(jìn)行一些工具調(diào)用以決定如何分解任務(wù)，而且任何數(shù)量的細(xì)節(jié)都可能對任務(wù)的解釋產(chǎn)生影響。

原則 1

共享上下文，并共享完整的代理跟蹤信息，而不僅僅是單個消息

讓我們再對我們的代理進(jìn)行一次修訂，這次要確保每個代理都有前一個代理的上下文。

不幸的是，我們還沒有完全脫離困境。當(dāng)你給你的智能體布置同樣的《飛翔的小鳥》克隆任務(wù)時，這一次，你最終得到的小鳥和背景可能會有完全不同的視覺風(fēng)格。子智能體1和子智能體2無法看到對方在做什么，因此它們的工作最終會彼此不一致。

子智能體1采取的行動和子智能體2采取的行動是基于事先未明確規(guī)定的相互沖突的假設(shè)。

原則2

行動蘊含著隱含的決策，而相互沖突的決策會帶來不良后果

我認(rèn)為原則1和原則2至關(guān)重要，而且極少值得違背，因此默認(rèn)情況下，你應(yīng)該排除任何不遵守這些原則的智能體架構(gòu)。你可能覺得這很受限，但實際上仍有很大的空間可供你為智能體探索不同的架構(gòu)。

遵循這些原則的最簡單方法是僅使用單線程線性代理：

在這里，上下文是連續(xù)的。然而，對于非常大的任務(wù)，由于有太多子部分，上下文窗口可能會開始溢出，從而遇到問題。

老實說，簡單的架構(gòu)能讓你走得很遠(yuǎn)，但對于那些真正有長期任務(wù)且愿意付出努力的人來說，你可以做得更好。有幾種方法可以解決這個問題，但今天我只介紹一種：

在這個領(lǐng)域，我們推出了一個新的大語言模型（LLM），其主要目的是將一系列行動和對話的歷史壓縮成關(guān)鍵細(xì)節(jié)、事件和決策。這是一項難以做好的工作。這需要投入精力來確定哪些最終會成為關(guān)鍵信息，并創(chuàng)建一個擅長此任務(wù)的系統(tǒng)。根據(jù)不同的領(lǐng)域，你甚至可以考慮微調(diào)一個較小的模型（事實上，我們在認(rèn)知公司已經(jīng)這樣做了）。

你得到的好處是一個在處理較長上下文時更有效的代理。不過，最終還是會遇到限制。對于求知欲強(qiáng)的讀者，我鼓勵你們思考更好的方法來處理任意長的上下文。這最終會是一個相當(dāng)深奧的問題！

應(yīng)用原則

如果你是一名智能體構(gòu)建者，請確保你的智能體的每一個動作都能參考系統(tǒng)其他部分做出的所有相關(guān)決策的上下文。理想情況下，每個動作都應(yīng)該能看到其他所有內(nèi)容。不幸的是，由于上下文窗口有限和實際權(quán)衡，這并不總是可行的，你可能需要根據(jù)你所追求的可靠性水平來決定愿意承擔(dān)何種復(fù)雜程度。

當(dāng)你考慮設(shè)計你的智能體以避免決策沖突時，以下是一些值得思考的現(xiàn)實世界示例：

Claude代碼子代理

截至2025年6月，Claude Code是一個會生成子任務(wù)的智能體示例。不過，它從不與子任務(wù)智能體并行工作，且子任務(wù)智能體通常僅負(fù)責(zé)回答問題，而不編寫任何代碼。這是為什么呢？ 子任務(wù)智能體缺乏來自主智能體的上下文信息，而這些信息對于執(zhí)行超出回答明確定義問題之外的任何任務(wù)都是必需的。如果他們要運行多個并行子智能體，這些子智能體可能會給出相互沖突的響應(yīng)，從而導(dǎo)致我們在早期智能體示例中看到的可靠性問題。在這種情況下，擁有子智能體的好處在于，子智能體的所有調(diào)查工作不需要保留在主智能體的歷史記錄中，從而在上下文耗盡之前可以進(jìn)行更長的追蹤。Claude Code的設(shè)計者采取了一種有意簡化的方法。

編輯應(yīng)用模型

2024年，許多模型在編輯代碼方面表現(xiàn)很差。編碼代理、IDE、應(yīng)用構(gòu)建器等（包括Devin）的常見做法是使用“編輯應(yīng)用模型”。其核心思想是，給定你想要的更改的Markdown解釋，讓一個小模型重寫整個文件實際上比讓大模型輸出格式正確的差異更可靠。因此，構(gòu)建者讓大模型輸出代碼編輯的Markdown解釋，然后將這些Markdown解釋提供給小模型，由小模型實際重寫文件。然而，這些系統(tǒng)仍然存在很多問題。例如，小模型常常會誤解大模型的指令，由于指令中最細(xì)微的歧義而進(jìn)行錯誤的編輯。如今，編輯決策和應(yīng)用更多地由單個模型在一個操作中完成。

多智能體

如果我們真的想讓系統(tǒng)實現(xiàn)并行性，你可能會想到讓決策者們相互“交流”，共同解決問題。

這就是我們?nèi)祟愒谝庖姴缓蠒r（在理想世界中）會做的事情。如果工程師A的代碼與工程師B的代碼產(chǎn)生合并沖突，正確的做法是討論分歧并達(dá)成共識。然而，如今的智能體還不太能夠像單智能體那樣可靠地進(jìn)行這種長上下文的主動對話。人類在相互交流最重要的知識方面相當(dāng)高效，但這種效率需要相當(dāng)高的智能。

自ChatGPT推出后不久，人們就一直在探索多個智能體相互協(xié)作以實現(xiàn)目標(biāo)的想法[3][4]。雖然我對智能體之間長期的協(xié)作可能性持樂觀態(tài)度，但很明顯，在2025年，多個智能體協(xié)作運行只會導(dǎo)致系統(tǒng)脆弱。決策最終過于分散，智能體之間也無法充分共享上下文信息。目前，我沒看到有誰在專門努力解決這個棘手的跨智能體上下文傳遞問題。我個人認(rèn)為，隨著我們讓單線程智能體在與人類溝通方面變得更加出色，這個問題將迎刃而解。當(dāng)這一天到來時，它將釋放出更大的并行性和效率。

邁向更通用的理論

這些關(guān)于上下文工程的觀察僅僅是我們有朝一日可能會視為構(gòu)建智能體標(biāo)準(zhǔn)原則的開端。還有許多挑戰(zhàn)和技術(shù)未在此處討論。在Cognition，構(gòu)建智能體是我們思考的關(guān)鍵前沿領(lǐng)域。我們圍繞這些原則構(gòu)建內(nèi)部工具和框架，而這些原則是我們反復(fù)重新學(xué)習(xí)的，以此來強(qiáng)化這些理念。但我們的理論可能并不完美，并且我們預(yù)計隨著該領(lǐng)域的發(fā)展情況會發(fā)生變化，因此也需要一定的靈活性和謙遜態(tài)度。

歡迎您在app.devin.ai試用我們的產(chǎn)品。如果您希望與我們一同探索這些智能體構(gòu)建原則，請聯(lián)系walden@cognition.ai

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