昨天剛介紹了探索 Anthropic 的多智能體研究系統(tǒng)：揭秘Agent工程與創(chuàng)新的融合，今天的文章從另外一個(gè)角度分析多智能體的構(gòu)建原則，編譯自海外AI公司Cognition發(fā)布的內(nèi)容 在大語言模型（LLM）智能體框架領(lǐng)域，許多看似誘人的想法在實(shí)際應(yīng)用中卻表現(xiàn)糟糕。今天，我們將基于實(shí)際的試錯(cuò)經(jīng)驗(yàn)，分享構(gòu)建可靠智能體的核心原則，并解釋為什么多智能體架構(gòu)并不是最佳選擇。 ?? 當(dāng)前AI智能體開發(fā)的現(xiàn)狀HTML于1993年問世，2013年Facebook向世界發(fā)布了React。如今已是2025年，React及其衍生框架主導(dǎo)著開發(fā)者構(gòu)建網(wǎng)站和應(yīng)用的方式。為什么？因?yàn)镽eact不僅僅是編寫代碼的腳手架，更是一種哲學(xué)。通過使用React，你擁抱了響應(yīng)式和模塊化的應(yīng)用構(gòu)建模式，這些現(xiàn)在被認(rèn)為是標(biāo)準(zhǔn)要求，但對(duì)早期web開發(fā)者來說并非顯而易見。  在LLM和AI智能體時(shí)代，我們?nèi)匀幌裨跀[弄原始的HTML和CSS，試圖弄清楚如何將這些組合在一起以創(chuàng)造良好的體驗(yàn)。除了一些絕對(duì)基礎(chǔ)的方法外，還沒有單一的智能體構(gòu)建方法成為標(biāo)準(zhǔn)。 在某些情況下，OpenAI的https://github.com/openai/swarm 和 Microsoft 的 https://github.com/microsoft/autogen 等庫(kù)會(huì)積極推動(dòng)我認(rèn)為是構(gòu)建代理的錯(cuò)誤方式的概念。也就是說，使用多代理架構(gòu)，本文將解釋原因。 ?? 構(gòu)建長(zhǎng)期運(yùn)行智能體的理論基礎(chǔ)可靠性是核心當(dāng)智能體需要在長(zhǎng)時(shí)間運(yùn)行中真正可靠，并維持連貫的對(duì)話時(shí)，你必須采取某些措施來控制錯(cuò)誤復(fù)合的可能性。否則，如果不小心，事情會(huì)很快分崩離析?？煽啃缘暮诵氖?/span>上下文工程。 什么是上下文工程？2025年，現(xiàn)有的模型極其智能。但即使是最聰明的人，如果沒有他們被要求做什么的上下文，也無法有效地完成工作。'提示工程'這個(gè)術(shù)語是為了描述為L(zhǎng)LM聊天機(jī)器人以理想格式編寫任務(wù)所需的努力。'上下文工程'是這個(gè)概念的下一個(gè)層次——在動(dòng)態(tài)系統(tǒng)中自動(dòng)完成這項(xiàng)工作。它需要更多的細(xì)節(jié)處理，實(shí)際上是構(gòu)建AI智能體的工程師的首要工作。 ?? 多智能體架構(gòu)的致命缺陷讓我們看一個(gè)常見智能體類型的例子：
這是一個(gè)誘人的架構(gòu)，特別是如果你在一個(gè)有多個(gè)并行組件的任務(wù)領(lǐng)域工作。然而，它非常脆弱。關(guān)鍵的失敗點(diǎn)是這樣的： 假設(shè)你的任務(wù)是'構(gòu)建一個(gè)Flappy Bird克隆版'。這被分為子任務(wù)1'構(gòu)建一個(gè)帶有綠色管道和碰撞盒的移動(dòng)游戲背景'和子任務(wù)2'構(gòu)建一個(gè)可以上下移動(dòng)的鳥'。
結(jié)果子智能體1實(shí)際上誤解了你的子任務(wù)，開始構(gòu)建一個(gè)看起來像超級(jí)馬里奧兄弟的背景。子智能體2為你構(gòu)建了一只鳥，但它看起來不像游戲資產(chǎn)，移動(dòng)方式也與Flappy Bird中的完全不同?，F(xiàn)在最終智能體面臨著合并這兩個(gè)誤解的不理想任務(wù)。 這可能看起來是人為的，但大多數(shù)現(xiàn)實(shí)世界的任務(wù)都有許多層次的細(xì)節(jié)，所有這些都有被誤解的可能。你可能認(rèn)為一個(gè)簡(jiǎn)單的解決方案是將原始任務(wù)作為上下文復(fù)制給子智能體。但請(qǐng)記住，在真實(shí)的生產(chǎn)系統(tǒng)中，對(duì)話很可能是多輪的，智能體可能必須進(jìn)行一些工具調(diào)用來決定如何分解任務(wù)，任何數(shù)量的細(xì)節(jié)都可能對(duì)任務(wù)的解釋產(chǎn)生影響。 ?? 構(gòu)建可靠智能體的核心原則原則1：共享上下文共享上下文，并共享完整的智能體跟蹤，而不僅僅是單個(gè)消息 讓我們重新審視我們的智能體，這次確保每個(gè)智能體都有前一個(gè)智能體的上下文。 不幸的是，我們還沒有完全脫離困境。當(dāng)你給智能體相同的Flappy Bird克隆任務(wù)時(shí)，這次你可能會(huì)得到完全不同視覺風(fēng)格的鳥和背景。子智能體1和子智能體2看不到對(duì)方在做什么，所以他們的工作最終彼此不一致。 原則2：行動(dòng)承載隱含決策行動(dòng)承載隱含決策，沖突的決策產(chǎn)生糟糕的結(jié)果 子智能體1采取的行動(dòng)和子智能體2采取的行動(dòng)基于事先未規(guī)定的沖突假設(shè)。 我認(rèn)為原則1和2如此關(guān)鍵，如此少有違反的價(jià)值，以至于你應(yīng)該默認(rèn)排除任何不遵守它們的智能體架構(gòu)。你可能認(rèn)為這是限制性的，但實(shí)際上你仍然可以為你的智能體探索各種不同架構(gòu)的廣闊空間。
?? 推薦的智能體架構(gòu)單線程線性智能體遵循這些原則的最簡(jiǎn)單方法是使用單線程線性智能體：在這里，上下文是連續(xù)的。然而，對(duì)于非常大的任務(wù)，有這么多子部分，你可能會(huì)遇到上下文窗口開始溢出的問題。 老實(shí)說，簡(jiǎn)單的架構(gòu)會(huì)讓你走得很遠(yuǎn)，但對(duì)于那些有真正長(zhǎng)期任務(wù)，并愿意付出努力的人，你可以做得更好。有幾種方法可以解決這個(gè)問題，但今天我只提出一種： 帶壓縮機(jī)制的高級(jí)架構(gòu)在這個(gè)方案中，我們引入一個(gè)新的LLM模型，其關(guān)鍵目的是將行動(dòng)和對(duì)話的歷史壓縮成關(guān)鍵細(xì)節(jié)、事件和決策。這很難做對(duì)。它需要投資來弄清楚什么最終成為關(guān)鍵信息，并創(chuàng)建一個(gè)擅長(zhǎng)此事的系統(tǒng)。根據(jù)領(lǐng)域，你甚至可以考慮微調(diào)一個(gè)較小的模型（這實(shí)際上是我們?cè)贑ognition所做的事情）。
你得到的好處是一個(gè)在更長(zhǎng)上下文中有效的智能體。不過你仍然會(huì)最終達(dá)到極限。對(duì)于熱心的讀者，我鼓勵(lì)你思考管理任意長(zhǎng)上下文的更好方法。這最終是一個(gè)相當(dāng)深的兔子洞！ ?? 原則的實(shí)際應(yīng)用如果你是智能體構(gòu)建者，確保你的智能體的每個(gè)行動(dòng)都由系統(tǒng)其他部分做出的所有相關(guān)決策的上下文來指導(dǎo)。理想情況下，每個(gè)行動(dòng)都只是看到其他一切。不幸的是，由于有限的上下文窗口和實(shí)際權(quán)衡，這并不總是可能的，你可能需要決定你愿意為你追求的可靠性水平承擔(dān)什么復(fù)雜性水平。 實(shí)際案例分析Claude Code子智能體截至2025年6月，Claude Code是一個(gè)生成子任務(wù)的智能體示例。然而，它從不與子任務(wù)智能體并行工作，子任務(wù)智能體通常只被賦予回答問題的任務(wù)，而不是編寫任何代碼。為什么？子任務(wù)智能體缺乏來自主智能體的上下文，否則就需要這些上下文來做除了回答明確定義的問題之外的任何事情。 編輯應(yīng)用模型2024年，許多模型在編輯代碼方面真的很糟糕。編碼智能體、IDE、應(yīng)用構(gòu)建器等（包括Devin）的常見做法是使用'編輯應(yīng)用模型'。關(guān)鍵思想是，給定你想要的更改的markdown解釋，讓小模型重寫你的整個(gè)文件實(shí)際上比讓大模型輸出正確格式的差異更可靠。 然而，這些系統(tǒng)仍然會(huì)非常有缺陷。例如，小模型經(jīng)常會(huì)誤解大模型的指令，由于指令中最輕微的歧義而進(jìn)行錯(cuò)誤的編輯。今天，編輯決策制定和應(yīng)用更經(jīng)常由單個(gè)模型在一個(gè)行動(dòng)中完成。 ?? 為什么多智能體協(xié)作還不成熟如果我們真的想從我們的系統(tǒng)中獲得并行性，你可能會(huì)想讓決策者彼此'交談'并解決問題。這是我們?nèi)祟愒谝庖姴缓蠒r(shí)所做的（在理想世界中）。如果工程師A的代碼與工程師B造成合并沖突，正確的協(xié)議是討論分歧并達(dá)成共識(shí)。 然而，今天的智能體還不能進(jìn)行這種長(zhǎng)上下文主動(dòng)話語的風(fēng)格，其可靠性比你用單個(gè)智能體獲得的要高得多。人類在向彼此傳達(dá)我們最重要的知識(shí)方面相當(dāng)高效，但這種效率需要非凡的智力。 自ChatGPT發(fā)布后不久，人們一直在探索多個(gè)智能體相互交互以實(shí)現(xiàn)目標(biāo)的想法。雖然我對(duì)智能體彼此協(xié)作的長(zhǎng)期可能性持樂觀態(tài)度，但很明顯，在2025年，運(yùn)行多個(gè)智能體協(xié)作只會(huì)導(dǎo)致脆弱的系統(tǒng)。決策制定最終變得過于分散，上下文無法在智能體之間充分共享。 目前，我沒有看到任何人致力于解決這個(gè)困難的跨智能體上下文傳遞問題。我個(gè)人認(rèn)為，當(dāng)我們讓單線程智能體在與人類交流方面變得更好時(shí)，這將免費(fèi)到來。當(dāng)這一天到來時(shí)，它將解鎖更大程度的并行性和效率。 ?? 邁向更通用的理論這些關(guān)于上下文工程的觀察只是我們有朝一日可能考慮的構(gòu)建智能體標(biāo)準(zhǔn)原則的開始。還有許多這里沒有討論的挑戰(zhàn)和技術(shù)。在Cognition，智能體構(gòu)建是我們思考的關(guān)鍵前沿。我們圍繞這些我們反復(fù)發(fā)現(xiàn)自己重新學(xué)習(xí)的原則構(gòu)建我們的內(nèi)部工具和框架，作為強(qiáng)化這些想法的方式。 但我們的理論可能并不完美，我們期望隨著領(lǐng)域的發(fā)展事情會(huì)發(fā)生變化，因此也需要一些靈活性和謙遜。 ?? 核心要點(diǎn)總結(jié)?? 寫在最后構(gòu)建可靠的AI智能體需要深入理解上下文工程的重要性。雖然多智能體架構(gòu)看起來很誘人，但在2025年的技術(shù)現(xiàn)狀下，單線程智能體配合適當(dāng)?shù)纳舷挛墓芾砣匀皇亲羁煽康倪x擇。 隨著技術(shù)的不斷發(fā)展，我們期待看到更成熟的多智能體協(xié)作方案出現(xiàn)。但在那之前，讓我們專注于構(gòu)建真正可靠、可投入生產(chǎn)的智能體系統(tǒng)。 |
|
|
