作者：京東物流 趙勇萍

前言

最近隨著manus的火爆, 其實大家更關注AI-Agent的開發技術了.畢竟大模型是大腦, 而Ai-Agent才是給最強大腦重塑真身的那個蓮藕. 而我也這多半年的時間里, 研究了很多AI-Agent框架. 而在AI-Agent開發中, 其實也發現了一些技巧,思路和架構思考. 比如, 我們如何更好的跟LLM進行交流? 如何可以更好的優化我們的prompt和token數量? 如何能讓LLM更快的返回我們想要的思考結果? 基于這些問題,我們一點點的展開討論。

?

一. 不要讓“大塊頭”嚇倒你：拆分才是王道

還記得我們第一次寫代碼的情景嗎？那時候，我們可能會寫出一個上百行的main方法，恨不得把所有邏輯都塞進去。結果調試起來頭昏腦漲，連自己都看不懂寫的是什么。從那時起，我們就明白了一個道理：復雜的邏輯需要拆分成更小的部分。將代碼分成多個方法、類和模塊，不僅讓代碼更易讀、易維護，也更容易調試和測試。

其實，在AI-Agent的開發中，這個原則同樣適用，甚至更加重要。因為大模型的能力雖然強大，但如果我們不加以限制和合理利用，反而會適得其反。

很多人覺得，既然LLM（大型語言模型）這么智能，那我就把所有可能的指令都塞進系統提示詞里（System Prompt），讓它自己處理所有情況。結果呢？模型懵了，該執行的不執行，不該執行的到處亂跑，輸出的結果讓人哭笑不得.

?

為什么會這樣？

當我們在系統提示詞中堆砌太多內容時，會出現以下問題：

1.信息過載：模型需要處理的信息量過大，可能會忽略其中一些指令。

2.指令沖突：不同指令之間可能存在矛盾，導致模型無法判斷優先級。

3.上下文混亂：提示詞過長，模型可能會混淆指令之間的關系，理解出現偏差。

4.令牌限制：過長的提示詞會占用大量的令牌（Tokens），增加成本和響應時間。

想象一下，你在超市里拿著一長串購物清單，上面還有各種刪改和備注，例如：

?牛奶（脫脂，如果沒有就買全脂）

?雞蛋（有機的，12個裝，如果有促銷買24個）

?面包（全麥，不要買白面包，除非打折）

是不是覺得頭暈眼花？一不小心就可能買錯。

模型也是一樣的，當提示詞過于繁雜時，它可能會：

?忽略重要指令：只關注最顯眼或最前面的指令，忽略后面的。

?誤解指令：因為信息量太大，導致對指令的理解出現偏差。

?產生沖突行為：不知道該遵循哪個指令，導致輸出混亂。

?

舉個栗子

下面我可能舉個實際例子會更好理解一下:

場景

一位開發者希望構建一個智能客服機器人，能夠處理各種用戶需求。他在系統提示詞中加入了大量的指令"

你是一個客服機器人，需要以友好和專業的態度與用戶交流。首先，向用戶問好。如果用戶提出技術問題，提供詳細的解決方案。
如果用戶抱怨，請安撫他們的情緒，并提供折扣券。如果用戶詢問商品信息，提供最新的商品詳情和價格。
如果用戶要求與人工客服對話，禮貌地詢問他們的具體需求，并嘗試解決問題。
所有回應必須簡潔明了，同時體現個性化和溫暖。 

問題

這個提示詞看似全面，但實際上過于復雜，可能導致模型無法正確執行。例如：

?模型可能無法識別用戶是抱怨還是詢問產品，導致回應不準確。

?由于指令太多，模型可能忽略了關鍵的服務流程。

解決方案

首先, 需要簡系統提示詞, 只需要將模型的基本角色和行為描述清楚即可, 避免過多的細節.例如:

你是一個客服機器人，負責幫助用戶解決問題，以專業和友好的態度與用戶交流。

其次, 需要上下文的動態添加指令.我們以langchain4J的框架為例, 可以將這些指令通過封裝多個AI Service實現, 然后串并聯這些模塊,實現整體的業務需求, 這里一般引入一個業務編排框架會使得架構更清晰, 比如liteflow這種.

然后回歸這個案例, 我們可以如下拆分指令:

? 如果檢測到用戶在抱怨或情緒激動，添加安撫情緒的指令。

?如果用戶提出技術問題，添加提供解決方案的指令。

?如果用戶詢問商品信息，添加提供商品詳情的指令。

最后, 在這種業務場景下,我們可以引入一個中間層（如意圖識別模塊），先對用戶的輸入進行分析，然后根據分析結果決定模型需要執行的操作。

比如如下代碼: 我們封裝一個用戶意圖識別的AI Service, 先讓大模型判斷客戶的意圖, 然后決定下里該執行哪個指令.

public enum UserIntentEnum {
    @Description("問候語, 例如:你好|您好|嗨|早上好|晚上好")
    GREETING,
    @Description("技術問題, 例如:技術問題|無法使用|出錯|故障")
    TECHNICAL_ISSUE,
    @Description("客戶抱怨評價, 例如:差評|不好用|生氣|投訴|抱怨")
    COMPLAINT,
    @Description("客戶商品咨詢, 例如:價格|多少錢|商品信息|詳情")
    PRODUCT_INQUIRY,
     @Description("客戶想轉人工, 例如:人工客服|真人")
    REQUEST_HUMAN
}

interface UserIntent {

    @UserMessage("Analyze the priority of the following issue? Text: {{it}}")
    UserIntentEnum analyzeUserIntent(String text);
}

基于以上的不同場景, 封裝對應的AI-Service, 然后通過liteflow這種業務編排工具串聯起來即可.

其實大家有沒有發現, 這種實現方式,就是prompt開發中, 大家經常提到的思維鏈/思維樹架構模式.

?

二. 工具和上下文，不是越多越好

在構建智能對話系統時，開發者常常希望模型能夠具備盡可能多的功能和信息。他們可能會認為，為模型提供更多的工具和更豐富的上下文，模型就能表現得更出色。然而，事實并非如此。過多的工具和上下文不僅不會提升模型性能，反而可能導致一系列問題，如成本飆升、響應速度變慢，甚至模型產生幻覺（hallucination）。因此，我們需要理性地看待工具和上下文的使用，避免陷入“越多越好”的誤區.

Fuction Call工具, 避免模型“消化不良”

現代大型語言模型（LLM）的**函數調用（Function Call）**功能，為我們在聊天機器人中集成各種工具提供了可能。通過這種功能，模型可以調用外部API、數據庫查詢、計算器等，實現復雜的任務處理。這聽起來令人興奮，許多開發者也因此產生了“我有這么多工具，干脆都給模型用吧！”的想法。

然而，這種貪多求全的做法可能會導致模型的“消化不良”。具體來說，過多的工具會引發以下問題：

1.成本飆升：每增加一個工具，都會增加對話的復雜性。模型需要在生成回復時考慮更多的可能性，這會消耗更多的計算資源和令牌（tokens），直接導致使用成本的增加。

2.模型產生幻覺（Hallucination）：當模型被賦予過多的工具時，它可能無法正確識別何時調用哪些工具，進而在不適當的情況下調用錯誤的工具。

3.用戶體驗受損：模型的不當行為會讓用戶感到困惑或不滿，影響對產品的整體評價。

案例分析：

想象一下，用戶簡單地對聊天機器人說了一句：“你好。”本來機器人只需要回一句問候即可。然而，由于模型被賦予了過多的工具，它可能會過度解讀用戶意圖，結果調用了數據庫查詢、訪問外部API，甚至替用戶訂了一份外賣。這樣的響應顯然是令人費解的。

這種情況不僅浪費了系統資源，還可能造成用戶數據的泄露或引發其他安全問題。

解決方案：

?精選工具：只為模型提供在當前場景下必要的工具。通過對用戶需求的分析，明確哪些工具是真正需要的。

?意圖識別：在模型調用工具之前，先進行用戶意圖識別，確保只有在確實需要的情況下才調用相關工具。

?設置調用條件：為工具的調用設置嚴格的條件和限制，防止模型在不適當的情況下使用工具.

?

RAG, 上下文避免成本高昂

RAG技術使得模型可以根據提供的上下文生成更準確的回答。這對于需要提供具體信息、背景知識的場景非常有用。然而，過度提供上下文同樣會帶來負面影響。

問題分析：

1.令牌消耗巨大：大量的上下文意味著更多的令牌消耗。模型的成本通常與令牌數量直接相關，過多的上下文會顯著提高使用成本。

2.響應時間延長：模型需要處理更多的信息，導致響應速度變慢，用戶需要等待更長的時間才能得到回復。

3.注意力分散：過多的上下文可能使模型無法專注于最相關的信息，反而降低了回答的準確性。

4.增加錯誤風險：上下文信息越多，模型可能在不相關的信息中“迷路”，生成與用戶需求不符的回答。

舉例說明：

如果用戶問：“你能告訴我今天的天氣嗎？”模型只需要提供當前的天氣信息即可。但如果為模型提供了大量的氣象數據、歷史天氣記錄等上下文，不僅增加了無謂的成本，還可能讓模型給出冗長的回答，影響用戶體驗。

優化策略：

?動態上下文管理：根據用戶的具體需求，動態地提供最相關的上下文信息，而不是一股腦地全部塞給模型。

?上下文精簡：對提供的上下文進行篩選，只保留與當前對話高度相關的部分。

?上下文緩存：對于多輪對話，合理地緩存上下文，但避免上下文長度無限增長。

?用戶引導：設計對話流程，引導用戶提供更精確的信息，減少對大段上下文的依賴。

??

思考一下

在使用工具和上下文時，關鍵在于適度和相關性。過多的工具和上下文不僅不會提升模型的表現，反而可能適得其反。我們應該以用戶需求為核心，合理配置模型的能力，既滿足功能要求，又控制成本.

所以啊，下次再想給模型塞一大堆工具和上下文的時候，不妨先問問你的錢包：“還能撐得住嗎？”畢竟，模型“消化不良”可不是鬧著玩的，錢包“消瘦”了，也別怪它不給你打聲招呼。總而言之，在構建智能對話系統時，我們需要堅持“適度”原則。工具和上下文的使用，應當服務于模型性能的提升和用戶體驗的優化，而不是一味地追求數量。只有精心設計和合理配置，我們才能打造出高效、可靠、令人滿意的聊天機器人.

?

三. 總結

在大型模型AI-Agent的開發中，我們需要像傳統軟件開發一樣，遵循模塊化、可測試、易維護的原則。不要迷信模型的強大能力，而忽視了架構設計的重要性。

通過將復雜的邏輯拆解成更小的組件，我們可以：

?降低成本：避免不必要的模型調用，節省令牌消耗。

?提高性能：減少響應時間，提升用戶體驗。

?提高可靠性：模塊化的設計更容易測試和維護，減少錯誤。

最后，希望大家在AI-Agent的開發中，既能發揮模型的強大能力，又能保持對架構的掌控。這樣，我們就不會被“大塊頭”嚇倒，而是能駕馭它，為我們所用。

俗話說得好，“不要試圖一口吃成個胖子”，即使是AI-Agent，也是需要慢慢“調教”的。祝大家在AI的浪潮中，乘風破浪，勇往直前！

審核編輯 黃宇