在構建多 AI 智能體系統架構時，許多現有的框架并不理想，通過我們自己的實踐經驗和試錯，提出了一些構建 AI 智能體的原則，并解釋了為什么一些看似吸引人的想法在實際中可能并不好用。

在這篇文章中，我將分享以下內容：

1. 上下文工程的原則
2. 構建長期運行 AI 智能體的架構設計
3. 應用這些架構設計原則

下文詳細剖析之。

1、上下文工程的原則

我們先來談談以下原則：

• 共享上下文
• 行為隱含決策
• 為什么需要原則？

HTML 于1993年問世。2013年，Facebook 向世界發布了 React。如今是2025年，React 及其衍生產品主導了開發者構建網站和應用的方式。為什么？因為 React 不僅僅是一個寫代碼的框架，它是一種哲學。通過使用 React，你接受了以反應式和模塊化的方式構建應用的架構設計模式，這現在被認為是標準，但早期的網絡開發者并不總是這么認為。

在 LLM 和構建 AI 智能體的時代，我們感覺像是還在用原始的 HTML 和 CSS，試圖將它們組合在一起以獲得良好的體驗。目前還沒有一種構建 AI 智能體的方法成為標準，除了最基礎 MCP 的部分。

在某些情況下，像 OpenAI 的 Swarm 和微軟的 AutoGen 這樣的庫，積極推廣我認為是錯誤的構建 AI 智能體的概念，尤其是使用多 AI 智能體架構，我會解釋為什么。

當然，如果你是 AI 智能體構建的新手，有很多資源可以教你如何搭建基本的框架。但當涉及到構建嚴肅的生產應用時，情況就大不相同了。

2、構建長期運行 AI 智能體架構設計

我們先從可靠性開始。當 AI 智能體需要長時間運行并保持連貫的對話時，為了防止錯誤的累積，你必須采取一些措施。否則，如果不小心，事情很快就會失控。可靠性的核心是上下文工程。

到了2025年，現有的大模型非常智能。但即使是最聰明的人類，如果沒有他們被要求做的事情的上下文，也無法有效地完成工作。“Prompt 工程”是一個術語，指的是為 LLM 大模型編寫理想格式的任務所需的努力。“上下文工程”是這一概念的升級版。它是在動態系統中自動完成的，需要更多的細微差別，實際上是構建 AI 智能體的工程師的首要任務。

舉一個常見類型的 AI 智能體例子：

• 這個 AI 智能體將工作分解為多個部分；
• 啟動子 AI 智能體來處理這些部分；
• 最后將這些結果合并。

這種 AI 智能體架構很有吸引力，尤其是如果你的工作領域中有許多并行的任務組件。然而，它非常脆弱。關鍵的失敗點是：

假設你的任務是“構建一個 Flappy Bird 的克隆版”。這被分解為子任務1“構建一個帶有綠色管道和碰撞框的移動游戲背景”和子任務2“構建一個可以上下移動的鳥”。

結果是，子 AI 智能體1誤解了你的子任務，開始構建一個看起來像超級馬里奧兄弟的背景。子 AI 智能體2構建了一個鳥，但它看起來并不像游戲資產，移動方式也和 Flappy Bird 中的鳥不一樣。現在，最終的 AI 智能體不得不面對將這兩個誤解結合起來的不愉快任務。

這聽起來可能有些牽強，但大多數現實世界的任務都有許多層次的細微差別，這些都有可能被誤解。你可能會認為一個簡單的解決方案是將原始任務作為上下文復制給子 AI 智能體。這樣，它們就不會誤解它們的子任務了。但請記住，在真正的生產系統中，對話很可能是多輪的，AI 智能體可能需要進行一些工具調用來決定如何分解任務，任何細節都可能影響對任務的解釋。

原則1：共享上下文，共享完整的 AI 智能體軌跡，而不僅僅是單個消息。

我們再來看看我們的 AI 智能體，這次確保每個 AI 智能體都有前一個 AI 智能體的上下文。

不幸的是，我們還沒有完全擺脫困境。當你給 AI 智能體相同的 Flappy Bird 克隆任務時，這次你可能會得到一個鳥和背景，它們的視覺風格完全不同。子 AI 智能體1和子 AI 智能體2看不到對方的工作，因此它們的工作彼此不一致。

子 AI 智能體1和子 AI 智能體2的行為是基于沖突的假設，而這些假設沒有提前規定。

原則2：行為隱含決策，沖突的決策會帶來糟糕的結果。

我認為原則1和原則2至關重要，而且很少值得違反，因此你應該默認排除任何不遵守這些原則的 AI 智能體架構。你可能會覺得這很受限，但實際上，你仍然可以探索許多不同的 AI 智能體架構。

遵循這些原則的最簡單方法是使用單線程線性 AI 智能體：

在這里，上下文是連續的。然而，你可能會遇到一些非常大的任務，它們有許多子部分，上下文窗口開始溢出。

說實話，簡單的架構可以讓你走得非常遠，但對于那些真正長期的任務，以及愿意付出努力的人來說，你可以做得更好。有幾種方法可以解決這個問題，今天我介紹其中一種：

在這個世界中，我們引入了一個新的 LLM 模型，其主要目的是將行動和對話的歷史壓縮成關鍵細節、事件和決策。這很難做好。它需要投入精力去弄清楚什么是關鍵信息，并創建一個擅長于此的系統。根據領域，你甚至可以考慮微調一個較小的模型。

你得到的好處是一個在更長上下文中有效的 AI智能體。但你最終還是會遇到限制。我鼓勵你思考更好的管理任意長上下文的方法。這最終會成為一個很深的兔子洞！

3、應用這些架構設計原則

如果你是一個 AI 智能體構建者，確保你的 AI 智能體的每一個行為都受到系統其他部分所做所有相關決策的上下文的指導。理想情況下，每一個行為都能看到其他所有內容。不幸的是，由于上下文窗口有限和實際的權衡，這并不總是可能的，你可能需要決定你愿意承擔多大的復雜性，以實現你所追求的可靠性水平。

當你思考如何架構你的 AI 智能體以避免沖突的決策制定時，這里有一些現實世界的例子供你思考：

第一、Claude Code 子 AI 智能體

截至2025年6月，Claude Code 是一個會生成子任務的 AI 智能體的例子。然而，它從未與子任務 AI 智能體并行工作，子任務 AI 智能體通常只被要求回答一個問題，而不是編寫任何代碼。為什么？子任務 AI 智能體缺乏來自主 AI 智能體的上下文，否則它將需要做任何超出回答一個明確定義的問題的事情。如果它們運行多個并行的子 AI 智能體，它們可能會給出沖突的回應，導致我們之前看到的 AI 智能體的可靠性問題。在這種情況下擁有一個子 AI 智能體的好處是，子 AI 智能體的所有調查工作不需要保留在主 AI 智能體的歷史中，這允許在上下文耗盡之前有更長的追蹤。Claude Code 的設計者采取了一種有意識的簡單方法。

第二、編輯應用模型

2024年，許多模型在編輯代碼方面真的很糟糕。編碼 AI 智能體、IDE、應用構建器等（包括 Devin）的常見做法是使用“編輯應用模型”。關鍵思想是，實際上，讓一個小模型根據你想要的更改的 markdown 解釋來重寫你的整個文件，比讓一個大模型輸出一個格式正確的 diff 更可靠。因此，構建者讓大模型輸出代碼編輯的 markdown 解釋，然后將這些 markdown 解釋輸入到小模型中，以實際重寫文件。然而，這些系統仍然會有很多故障。例如，小模型經常因為指令中的最輕微的歧義而誤解大模型的指令，并做出錯誤的編輯。今天，編輯決策和應用通常更多地由一個單一模型在一個動作中完成。

4、多 AI 智能體系統架構

如果我們真的想從我們的系統中獲得并行性，你可能會認為讓決策者“交談”并解決問題。

這就是我們在意見不合時（在一個理想的世界里）人類所做的。如果工程師 A 的代碼與工程師 B 的代碼發生合并沖突，正確的協議是討論差異并達成共識。然而，今天的 AI 智能體并不能像單個 AI 智能體那樣可靠地進行這種長上下文的主動討論。人類在相互傳達最重要的知識方面相當高效，但這種效率需要非平凡的智能。

自從 ChatGPT 推出以來不久，人們就一直在探索多個 AI 智能體相互交互以實現目標的想法。雖然我對 AI 智能體相互協作的長期可能性持樂觀態度，但很明顯，在2025年，運行多個 AI 智能體進行協作只會導致脆弱的系統。決策過于分散，上下文無法在 AI 智能體之間充分共享。目前，我沒有看到任何人致力于解決這個困難的跨 AI 智能體上下文傳遞問題。我個人認為，隨著我們讓單線程 AI 智能體更擅長與人類溝通，這個問題會自動解決。當這一天到來時，它將釋放出更多的并行性和效率。

本文轉載自??玄姐聊AGI??  作者：玄姐