首先我們回顧下智能體的本質是什么？

如上圖所示，智能體的核心在于其如何接收指令、執行任務并做出決策。以下是其關鍵組成部分：

1. Prompt（提示）Prompt 是指導大語言模型（LLM）如何行動的指令，它定義了 LLM 可以使用的“工具”。Prompt 的輸出是一個 JSON 對象，用于描述工作流程中的下一步操作，例如“工具調用”或“函數調用”。
2. Switch 語句Switch 語句根據 LLM 返回的 JSON 內容決定后續操作。這是整個流程中的一個重要環節，用于解析 LLM 的輸出并執行相應的動作。
3. 累積的上下文累積的上下文用于記錄已執行的操作步驟及其運行結果。這一部分是智能體決策的重要依據，幫助其跟蹤任務的進展。
4. For 循環For 循環是整個流程的驅動機制。它循環執行以下操作，直至 LLM 返回終止信號（例如標記為“Terminal”的工具調用或自然語言響應）：將 switch 語句的執行結果加入上下文窗口，并讓 LLM 決定下一步動作。

這種設計使得智能體能夠高效地執行任務，同時具備靈活性和適應性。

下面我們詳細剖析下 AI 智能體架構設計的12條原則。

1、AI 智能體架構設計的12條原則

架構設計原則一：自然語言轉工具調用

將自然語言轉換為結構化的工具調用是構建 AI 智能體的常見模式之一。這種模式功能強大，能夠使智能體具備推理和執行任務的能力。

這種模式的核心在于實現自然語言與結構化指令之間的精準轉換。

架構設計原則二：自主掌控提示詞

避免直接使用框架自動生成的提示詞。

一些框架會提供這種“黑箱式”方案：

這種方案雖然能讓你快速上手并應用頂尖的提示詞模板，但后期很難進行精準調整或實施逆向工程，難以確保模型接收到的指令完全符合預期。

相反，你應該像對待核心業務代碼一樣對待提示詞：

架構設計原則三：自主掌控上下文窗口

在與大語言模型交互時，上下文傳遞不必局限于標準消息格式。對于 AI 智能體而言，每次向 LLM 提供輸入的本質是：“這是當前情況，接下來該怎么做？”一切皆為上下文工程。大語言模型本質上是無狀態函數，其作用是將輸入轉化為輸出。要獲得優質輸出，就必須提供優質的輸入。

構建優質上下文需要包含以下要素：

1. 提示詞與指令：為模型提供明確的操作指引。
2. 外部數據源：檢索到的文檔或知識（比如：使用 RAG 技術）。
3. 歷史狀態：過往的工具調用記錄、執行結果等操作痕跡。
4. 記憶系統：與當前對話或事件相關但獨立的歷史記錄。
5. 輸出結構化指令：規定模型返回數據的格式規范。

通過優化上下文輸入，可以顯著提升大語言模型的輸出質量和任務執行效率。

架構設計原則四：「工具」本質上只是 LLM 生成的結構化輸出

“工具”的設計無需過于復雜。其核心是大語言模型生成的結構化輸出，用于觸發確定性的代碼執行。

以 ??CreateIssue ???和 ??SearchIssues ??這兩個工具為例，讓大語言模型（LLM）“調用工具”，本質上是讓它輸出一個可解析的 JSON 對象，該對象對應要執行的具體操作。

這種模式非常簡潔，包含以下三個步驟：

1. LLM生成結構化的 JSON 輸出。
2. 使用確定性代碼執行對應操作（例如：調用外部 API）。
3. 捕獲執行結果并反饋到上下文中。

這種設計實現了 LLM 決策邏輯與應用程序執行邏輯的清晰分離：LLM 負責決定“做什么”，而代碼則掌控“怎么做”。即使 LLM 調用了某個工具，具體的執行方式也不必每次都嚴格對應單一函數。

架構設計原則五：執行狀態與業務狀態的統一

即使在 AI 領域之外，許多基礎設施系統也在嘗試分離“執行狀態”與“業務狀態”。對于 AI 應用來說，這種分離可能需要復雜的抽象機制來跟蹤當前步驟、下一步驟、等待狀態、重試次數等信息。雖然這種分離帶來的復雜性在某些情況下可能是值得的，但對你的具體使用場景來說，可能是一種過度設計。

你可以根據自己的需求來決定最適合的方案。不要認為必須將這兩者分開管理。

更清晰的定義如下：

• 執行狀態（Execution state）：包括當前步驟、下一步驟、等待狀態、重試次數等。
• 業務狀態（Business state）：指智能體工作流中已發生的事件，例如 OpenAI 消息列表、工具調用及結果列表等。

如果可能的話，盡量簡化設計——盡可能將執行狀態和業務狀態統一起來。

實際上，通過精心的工程設計，你可以直接從上下文窗口推斷出所有執行狀態。在大多數情況下，執行狀態（如當前步驟、等待狀態等）本質上只是已發生事件的元數據（metadata）。

當然，有些信息（如會話 ID、密碼上下文等）可能無法放入上下文窗口，但你的目標應該是盡量減少這類例外。通過遵循架構設計原則3，你可以精準地控制哪些信息真正輸入給 LLM。

架構設計原則六：通過簡單的 API 實現啟動/暫停/恢復

智能體本質上是一種程序，其生命周期管理應符合我們對普通程序的期望：能夠方便地啟動、查詢、恢復和終止。

必須確保終端用戶、應用程序、業務流程以及其他智能體都可以通過輕量級 API 接口快速部署新的智能體實例。此外，智能體及其編排的確定性代碼應具備長期運行時的自動暫停能力。

架構設計原則七：通過工具調用實現人機協同

默認情況下，LLM AP I在生成模型響應時，首先需要做出一個關鍵且高風險的選擇：是返回純文本內容，還是返回結構化數據？

系統會將大量決策權重集中在首個詞元的選擇上。例如，在查詢“東京天氣”時，首個詞元可能是：

• “東京”

而在 ??fetch_weather??（獲取天氣）功能中，則可能是表示 JSON 對象開頭的特殊詞元：

• ??|JSON>??

更優的方案是讓大語言模型始終輸出 JSON 結構化數據，然后通過自然語言詞元（??如 request_human_input ???或 ??done_for_now ???）來聲明意圖，而不是依賴類似 ??check_weather_in_city ??這樣的“標準”工具。

需要注意的是，這種方案可能不會直接提升系統的性能指標，但它必須通過持續實驗來驗證。工程師應該保留嘗試非常規手段的自由度，這是找到最優解的必經之路。

架構設計原則八：掌控你的控制流

如果你能夠掌控控制流，就能實現更靈活、更強大的功能。

根據具體應用場景構建專屬的控制邏輯，精準匹配業務需求。當特定類型的工具調用需要中斷循環以等待人工響應或執行長時任務（例如訓練流水線）時，你可以設計靈活的中斷機制。建議集成以下自定義功能：

• 工具調用結果的摘要與緩存：快速檢索和復用結果，避免重復計算。
• 使用 LLM 對結構化輸出進行校驗和評估：確保輸出的準確性和可靠性。
• 上下文窗口壓縮或其他內存管理方案：優化內存使用，提升系統效率。
• 全鏈路日志追蹤與性能監控：實時監控系統運行狀態，快速定位問題。
• 客戶端速率限制策略：防止過載，保障系統穩定運行。
• 持久化的休眠/暫停/事件等待機制：支持長時間任務的靈活暫停與恢復。

通過這些自定義功能，你可以構建出更高效、更可靠的智能體系統，滿足復雜多變的業務需求。

架構設計原則九：將錯誤信息壓縮至上下文窗口

這一點雖然簡短，但值得一提。智能體的優勢之一在于“自我修復”--對于短任務，大語言模型（LLM）可能會調用某個失敗的工具。優秀的 LLM 通常能夠讀取錯誤信息或 Stack Trace 信息，并在后續工具調用中調整策略。

大多數框架已實現這一功能，但你也可以只做到這一點。

架構設計原則十：小型化、功能聚焦的智能體

與其構建一個試圖包辦一切的大型智能體，不如開發專注于某一單一功能的小型智能體。智能體只是更大系統中的一個基礎組件，而這個系統主要由確定性因素驅動。

關鍵在于大語言模型（LLM）的局限性：任務越龐大復雜，所需步驟就越多，上下文窗口也就越長。隨著上下文的增長，大語言模型更容易迷失方向或偏離重點。通過將智能體的功能限定在特定領域（3-10個步驟，最多20個任務步驟），我們可以保持上下文窗口的可管理性，從而確保大語言模型的高效運行。

架構設計原則十一：智能體系統支持多入口觸發，且響應與觸發渠道保持一致

在落實了原則 6 和原則 7 之后，你可以無縫集成這一原則的方案。

支持用戶通過 Slack、郵件、短信等任意渠道喚醒智能體，并確保響應始終在原對話流中完成。

優勢：

• 滿足用戶需求：打造擬人化的 AI 應用體驗，讓用戶感受到如同真人協作般的自然交互，至少達到數字同事的交互水平。
• 外循環智能體：支持非人工觸發（如系統事件、定時任務、故障告警等），智能體可自主運行 5-90 分鐘，并在關鍵決策節點自動請求人工介入（如需審批、獲取反饋或請求協助）。
• 高風險操作授權機制：通過快速人工復核機制，授權智能體執行高風險操作（如外發郵件、生產數據更新等）。明確且標準化的管控體系既能保障操作的可追溯性，又能提升智能體執行復雜任務的可靠性。

架構設計原則十二：將智能體設計為符合“無狀態化歸并器”模式

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