作者：京東物流 趙勇萍

前言

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

?

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

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

其實(shí)，在AI-Agent的開發(fā)中，這個(gè)原則同樣適用，甚至更加重要。因?yàn)榇竽Ｐ偷哪芰﹄m然強(qiáng)大，但如果我們不加以限制和合理利用，反而會(huì)適得其反。

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

?

為什么會(huì)這樣？

當(dāng)我們?cè)谙到y(tǒng)提示詞中堆砌太多內(nèi)容時(shí)，會(huì)出現(xiàn)以下問題：

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

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

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

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

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

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

?雞蛋（有機(jī)的，12個(gè)裝，如果有促銷買24個(gè)）

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

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

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

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

?誤解指令：因?yàn)樾畔⒘刻螅瑢?dǎo)致對(duì)指令的理解出現(xiàn)偏差。

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

?

舉個(gè)栗子

下面我可能舉個(gè)實(shí)際例子會(huì)更好理解一下:

場(chǎng)景

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

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

問題

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

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

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

解決方案

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

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

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

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

? 如果檢測(cè)到用戶在抱怨或情緒激動(dòng)，添加安撫情緒的指令。

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

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

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

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

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

interface UserIntent {

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

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

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

?

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

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

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

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

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

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

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

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

案例分析：

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

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

解決方案：

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

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

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

?

RAG, 上下文避免成本高昂

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

問題分析：

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

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

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

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

舉例說明：

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

優(yōu)化策略：

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

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

?上下文緩存：對(duì)于多輪對(duì)話，合理地緩存上下文，但避免上下文長(zhǎng)度無限增長(zhǎng)。

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

??

思考一下

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

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

?

三. 總結(jié)

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

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

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

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

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

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

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

審核編輯 黃宇