作者：京東物流 趙勇萍

前言

最近隨著manus的火爆, 其實大家更關(guān)注AI-Agent的開發(fā)技術(shù)了.畢竟大模型是大腦, 而Ai-Agent才是給最強大腦重塑真身的那個蓮藕. 而我也這多半年的時間里, 研究了很多AI-Agent框架. 而在AI-Agent開發(fā)中, 其實也發(fā)現(xiàn)了一些技巧,思路和架構(gòu)思考. 比如, 我們?nèi)绾胃玫母鶯LM進行交流? 如何可以更好的優(yōu)化我們的prompt和token數(shù)量? 如何能讓LLM更快的返回我們想要的思考結(jié)果? 基于這些問題,我們一點點的展開討論。

?

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

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

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

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

?

為什么會這樣？

當(dāng)我們在系統(tǒng)提示詞中堆砌太多內(nèi)容時，會出現(xiàn)以下問題：

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

2.指令沖突：不同指令之間可能存在矛盾，導(dǎo)致模型無法判斷優(yōu)先級。

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

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

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

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

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

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

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

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

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

?誤解指令：因為信息量太大，導(dǎo)致對指令的理解出現(xiàn)偏差。

?產(chǎn)生沖突行為：不知道該遵循哪個指令，導(dǎo)致輸出混亂。

?

舉個栗子

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

場景

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

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

問題

這個提示詞看似全面，但實際上過于復(fù)雜，可能導(dǎo)致模型無法正確執(zhí)行。例如：

?模型可能無法識別用戶是抱怨還是詢問產(chǎn)品，導(dǎo)致回應(yīng)不準(zhǔn)確。

?由于指令太多，模型可能忽略了關(guān)鍵的服務(wù)流程。

解決方案

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

你是一個客服機器人，負(fù)責(zé)幫助用戶解決問題，以專業(yè)和友好的態(tài)度與用戶交流。

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

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

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

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

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

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

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

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

interface UserIntent {

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

基于以上的不同場景, 封裝對應(yīng)的AI-Service, 然后通過liteflow這種業(yè)務(wù)編排工具串聯(lián)起來即可.

其實大家有沒有發(fā)現(xiàn), 這種實現(xiàn)方式,就是prompt開發(fā)中, 大家經(jīng)常提到的思維鏈/思維樹架構(gòu)模式.

?

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

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

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

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

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

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

2.模型產(chǎn)生幻覺（Hallucination）：當(dāng)模型被賦予過多的工具時，它可能無法正確識別何時調(diào)用哪些工具，進而在不適當(dāng)?shù)那闆r下調(diào)用錯誤的工具。

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

案例分析：

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

這種情況不僅浪費了系統(tǒng)資源，還可能造成用戶數(shù)據(jù)的泄露或引發(fā)其他安全問題。

解決方案：

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

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

?設(shè)置調(diào)用條件：為工具的調(diào)用設(shè)置嚴(yán)格的條件和限制，防止模型在不適當(dāng)?shù)那闆r下使用工具.

?

RAG, 上下文避免成本高昂

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

問題分析：

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

2.響應(yīng)時間延長：模型需要處理更多的信息，導(dǎo)致響應(yīng)速度變慢，用戶需要等待更長的時間才能得到回復(fù)。

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

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

舉例說明：

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

優(yōu)化策略：

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

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

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

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

??

思考一下

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

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

?

三. 總結(jié)

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

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

?降低成本：避免不必要的模型調(diào)用，節(jié)省令牌消耗。

?提高性能：減少響應(yīng)時間，提升用戶體驗。

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

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

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

審核編輯 黃宇