做AI智能體有一段時(shí)間的人應(yīng)該都有過(guò)這種體驗(yàn)同樣是基于LLM做出來(lái)的東西有的又準(zhǔn)又穩(wěn)就像一把趁手的扳手說(shuō)擰哪顆螺絲就擰哪顆有的則是上來(lái)就問(wèn)你“您需要什么幫助”然后一通操作猛如虎最后還答非所問(wèn)。問(wèn)題在哪很多時(shí)候不在模型能力而在于你沒(méi)有把“任務(wù)邊界”這件事想清楚。今天這篇我想圍繞LLM智能體的兩種典型形態(tài)——單任務(wù)代理與多任務(wù)代理把它們的結(jié)構(gòu)差異、適用場(chǎng)景和取舍邏輯攤開(kāi)聊一聊。如果你正在設(shè)計(jì)自己的第一個(gè)AI智能體或者已經(jīng)做了一個(gè)但又覺(jué)得哪里不對(duì)勁這篇文章應(yīng)該能幫你找到一個(gè)明確的判斷框架。我先把結(jié)論放在前面單任務(wù)代理和多任務(wù)代理的區(qū)別不僅僅是你給系統(tǒng)指派了“一件事”還是“很多件事”而是整個(gè)系統(tǒng)在決策權(quán)歸屬、任務(wù)編排方式、狀態(tài)管理邏輯這三個(gè)層面都發(fā)生了根本變化。理解不了這層你可能會(huì)做出一個(gè)看起來(lái)很強(qiáng)大、用起來(lái)卻很崩潰的“偽多任務(wù)”系統(tǒng)。1. 從“單個(gè)LLM”到“單任務(wù)代理”一個(gè)專注型執(zhí)行器是如何構(gòu)建的在很多人的理解里給一個(gè)LLM寫(xiě)一段提示詞讓它專門(mén)做某件事這就叫單任務(wù)代理。其實(shí)這個(gè)理解不算錯(cuò)但只說(shuō)對(duì)了一半。真正的單任務(wù)代理要求的是單一目標(biāo)貫穿整個(gè)運(yùn)行生命周期從接收輸入到調(diào)用外部工具再到生成最終輸出中間不做任何橫向發(fā)散。1.1 單任務(wù)代理的核心運(yùn)行邏輯一個(gè)標(biāo)準(zhǔn)的單任務(wù)代理內(nèi)部通常只有一條固定鏈路接收用戶請(qǐng)求 → 解析請(qǐng)求中的結(jié)構(gòu)化字段 → 判斷是否調(diào)用工具 → 拿到工具結(jié)果 → 生成最終回答。鏈路很短而且每一步的觸發(fā)條件都非常明確。舉個(gè)例子。我做過(guò)一個(gè)專門(mén)處理“商品庫(kù)存查詢”的小型代理輸入是“某某商品還有貨嗎”輸出是“有/無(wú) 預(yù)計(jì)補(bǔ)貨時(shí)間”。這個(gè)代理的內(nèi)部實(shí)現(xiàn)里L(fēng)LM只負(fù)責(zé)兩件事第一從用戶話術(shù)中抽取商品名和查詢意圖第二把工具返回的庫(kù)存數(shù)字翻譯成人話。其他的一切比如閑聊、推薦商品、解釋售后政策都被系統(tǒng)提示詞明確禁止了。# 一個(gè)典型單任務(wù)代理的結(jié)構(gòu)示意 class InventoryAgent: def __init__(self, llm): self.llm llm self.tools {query_stock: query_stock_api} self.system_prompt 你是一個(gè)庫(kù)存查詢助手。只處理庫(kù)存相關(guān)查詢其他內(nèi)容一律拒絕回答。 def run(self, user_input): intent self.llm.extract(user_input, schema[product_name, intent]) if intent[intent] ! stock_query: return 抱歉我只負(fù)責(zé)庫(kù)存查詢。 stock_info self.tools[query_stock](intent[product_name]) return self.llm.generate_answer(stock_info)這段代碼去掉了各種復(fù)雜的外部依賴但核心鏈路就長(zhǎng)這樣。你可以看到每一步的輸入輸出都是被定義死的LLM沒(méi)有任何自由發(fā)揮的空間。對(duì)于“把一件事做極致”的需求來(lái)說(shuō)這種結(jié)構(gòu)幾乎是最好的——準(zhǔn)確率高、響應(yīng)快、成本低且?guī)缀鯖](méi)有失控風(fēng)險(xiǎn)。1.2 為什么單任務(wù)代理容易給人“很蠢”的感覺(jué)但單任務(wù)代理也有一個(gè)天生缺陷它的能力邊界非常僵硬。一旦用戶的需求繞過(guò)了那道邊界哪怕是一句簡(jiǎn)單的“幫我順便看看這款商品的評(píng)價(jià)”代理也會(huì)直接拒絕或者報(bào)錯(cuò)。于是很多人開(kāi)始覺(jué)得這玩意兒“太笨了”接著就想往里面塞更多能力。一個(gè)典型誤區(qū)是多塞幾個(gè)工具副本把不同任務(wù)塞進(jìn)同一個(gè)提示詞里就認(rèn)為它變成了多任務(wù)代理。實(shí)際上不是。“既能查庫(kù)存、又能查物流、又能查退換貨政策”的代理如果內(nèi)部沒(méi)有真正的任務(wù)分發(fā)邏輯而只是把所有工具的說(shuō)明都寫(xiě)進(jìn)提示詞讓LLM自己選那它是一個(gè)擁有多個(gè)工具的單任務(wù)代理——因?yàn)樗瑫r(shí)還是沒(méi)有任務(wù)邊界還是憑模型“臨場(chǎng)感覺(jué)”決定該干什么。這種結(jié)構(gòu)的最大問(wèn)題在于LLM的工具選擇往往會(huì)有隨機(jī)性尤其在工具列表超過(guò)五個(gè)之后選錯(cuò)工具的概率會(huì)明顯上浮。這也是我們?cè)陧?xiàng)目里反復(fù)踩過(guò)的一個(gè)坑。2. 多任務(wù)代理的本質(zhì)不是“會(huì)的多”而是“編排好”理解了單任務(wù)代理再看多任務(wù)代理就順理成章了。多任務(wù)代理的關(guān)鍵詞不是“多”而是編排。它要對(duì)一系列子任務(wù)進(jìn)行規(guī)劃、路由、執(zhí)行和結(jié)果合并最終給用戶一個(gè)統(tǒng)一完整的響應(yīng)。2.1 多任務(wù)代理的兩種主流實(shí)現(xiàn)形態(tài)我平時(shí)接觸到的多任務(wù)代理大致可以分為兩類下面分別說(shuō)明。一類是單體多任務(wù)。整個(gè)系統(tǒng)還是一個(gè)代理內(nèi)部有多個(gè)任務(wù)處理器Handler業(yè)務(wù)流程通過(guò)一個(gè)路由器做分發(fā)。比如你輸入“把這份文檔翻譯成英文然后提取里面的三個(gè)關(guān)鍵觀點(diǎn)”代理會(huì)先調(diào)用翻譯Handler等翻譯完成后再把結(jié)果喂給觀點(diǎn)提取Handler最后把兩個(gè)結(jié)果合并輸出。這類代理的好處是全局狀態(tài)統(tǒng)一管理用戶感知是和一個(gè)“人”在對(duì)話劣勢(shì)在于任務(wù)流水線一旦變長(zhǎng)上下文會(huì)被反復(fù)注入Token消耗和新任務(wù)的干擾都會(huì)明顯上升。另一類是多智能體協(xié)作。每個(gè)子任務(wù)由一個(gè)獨(dú)立的代理負(fù)責(zé)代理之間通過(guò)消息或共享狀態(tài)互相通信。還是上面翻譯加提取的場(chǎng)景這里會(huì)有一個(gè)調(diào)度代理把任務(wù)拆開(kāi)分發(fā)給一個(gè)翻譯代理和一個(gè)提取代理再回收各自的結(jié)果排序輸出。這類形態(tài)隔離性好可以單獨(dú)升級(jí)某個(gè)子代理而不影響其他模塊調(diào)試起來(lái)非常直觀但代價(jià)是你得額外處理代理之間的通信協(xié)議、時(shí)間同步和數(shù)據(jù)一致性問(wèn)題。在需要十幾個(gè)子任務(wù)協(xié)作的復(fù)雜場(chǎng)景里這類“分布式”的調(diào)試成本會(huì)成倍增加。2.2 一個(gè)常見(jiàn)的誤導(dǎo)性說(shuō)法“用越大越聰明的模型多任務(wù)效果就越好”這個(gè)說(shuō)法部分成立但不全對(duì)。大模型的能力確實(shí)能提升單步任務(wù)的完成質(zhì)量但多任務(wù)系統(tǒng)的整體效果更多取決于任務(wù)拆解的合理性和數(shù)據(jù)流轉(zhuǎn)的完整性。我曾經(jīng)把一個(gè)四任務(wù)代理的LLM從普通規(guī)模的模型換到頂級(jí)規(guī)模的模型結(jié)果整體效果只提升了大約7%倒是成本翻了近十倍。后來(lái)我重新調(diào)整了子任務(wù)的先后順序把原本混亂的數(shù)據(jù)依賴?yán)眄槢](méi)有換模型整體正確率卻提升了近20%。這給我的觸動(dòng)特別深多任務(wù)代理的瓶頸往往不在“模型智商”而在“架構(gòu)設(shè)計(jì)”。3. 同樣的客服場(chǎng)景單任務(wù)和多任務(wù)的實(shí)現(xiàn)差異究竟有多大抽象概念說(shuō)再多都不如拿一個(gè)具體的業(yè)務(wù)場(chǎng)景來(lái)對(duì)照。我選大部分人都有感知的“售前咨詢智能體”作為例子。同樣是一個(gè)客服入口用單任務(wù)代理怎么做用多任務(wù)代理怎么做我實(shí)際對(duì)比過(guò)。單任務(wù)代理的做法很直接設(shè)置一個(gè)主題——售前產(chǎn)品介紹。工具只有商品信息庫(kù)提示詞明確要求只回答產(chǎn)品規(guī)格、價(jià)格、優(yōu)惠信息這三類問(wèn)題。一旦用戶問(wèn)“你們有什么優(yōu)惠嗎”之外的任何問(wèn)題比如“我的訂單到哪里了”單任務(wù)代理就只會(huì)機(jī)械地回復(fù)“我只負(fù)責(zé)產(chǎn)品介紹”?？雌饋?lái)體驗(yàn)很糟糕但它的優(yōu)點(diǎn)也極其鮮明響應(yīng)速度穩(wěn)定在0.8秒左右準(zhǔn)確率幾乎可以達(dá)到99%不會(huì)出現(xiàn)自說(shuō)自話亂回答的情況而且運(yùn)維成本約等于零出了問(wèn)題也極其好排查因?yàn)槁窂绞枪潭ǖ摹?duì)于企業(yè)只需要解決某一個(gè)特定問(wèn)題的場(chǎng)景單任務(wù)代理這種“偏科”反而是一種優(yōu)勢(shì)。多任務(wù)代理的做法完全不同。它內(nèi)部會(huì)有這樣一個(gè)結(jié)構(gòu)路由層先把用戶輸入歸入N個(gè)入口之一——產(chǎn)品介紹、訂單查詢、物流跟蹤、售后政策、人工轉(zhuǎn)接然后分發(fā)到各自對(duì)應(yīng)的任務(wù)處理器每個(gè)處理器完成后結(jié)果匯總層再統(tǒng)一整理語(yǔ)氣和排版輸出給用戶。這個(gè)系統(tǒng)光是路由器就需要單獨(dú)調(diào)優(yōu)更不用說(shuō)五個(gè)處理器各自的提示詞、工具配置和邊界條件。我實(shí)測(cè)算下來(lái)一個(gè)完整的五任務(wù)客服代理首版調(diào)試周期大概是單任務(wù)代理的三到五倍響應(yīng)時(shí)長(zhǎng)通常會(huì)從0.8秒漲到2秒甚至更多。那為什么還要做多任務(wù)因?yàn)橛脩魸M意度數(shù)據(jù)完全不一樣。單任務(wù)代理雖然快但“答非所問(wèn)”的體驗(yàn)會(huì)讓用戶迅速流失多任務(wù)代理會(huì)繞路但至少每個(gè)問(wèn)題都能被正確分流和響應(yīng)用戶不用在不同入口之間反復(fù)跳轉(zhuǎn)。這個(gè)取舍本身沒(méi)有絕對(duì)的對(duì)錯(cuò)取決于你的業(yè)務(wù)更看重單點(diǎn)效率還是綜合體驗(yàn)。4. 多任務(wù)代理內(nèi)部必現(xiàn)的三個(gè)關(guān)鍵機(jī)制如果你已經(jīng)決定要做一個(gè)多任務(wù)代理那么有三個(gè)機(jī)制是你繞不開(kāi)的路由機(jī)制、上下文窗口策略、記憶與狀態(tài)共享。這三個(gè)點(diǎn)處理好了系統(tǒng)的穩(wěn)定性和可擴(kuò)展性才會(huì)起來(lái)。4.1 路由機(jī)制決定“誰(shuí)來(lái)做”的第一道關(guān)路由層是多任務(wù)代理最基礎(chǔ)、也最容易被低估的部分。很多人圖省事直接讓LLM自己去判斷“用戶這句話屬于哪個(gè)任務(wù)”好一點(diǎn)的加一句“如果都不屬于回復(fù)無(wú)法處理”。但實(shí)際運(yùn)行中尤其是存在語(yǔ)義相近的任務(wù)時(shí)這種自由判斷會(huì)出現(xiàn)系統(tǒng)性偏差——比如將“退貨怎么申請(qǐng)”判到“售后政策”而不是“退貨處理”將“還沒(méi)發(fā)貨”判到“物流查詢”而不是“訂單狀態(tài)”。比較穩(wěn)妥的做法是對(duì)每個(gè)任務(wù)定義一個(gè)分類器先做一次規(guī)則匹配再做一次向量召回。常用策略如下規(guī)則優(yōu)先先匹配關(guān)鍵詞、實(shí)體、正則等強(qiáng)規(guī)則命中就不用走模型向量召回把用戶輸入和每個(gè)任務(wù)的示例問(wèn)法做向量相似度計(jì)算優(yōu)先返回相似度最高的前K個(gè)LLM兜底前面兩步都不確定的才交給LLM做最終判斷且要求返回JSON格式的分流結(jié)果。我個(gè)人的經(jīng)驗(yàn)是這樣疊加之后路由的準(zhǔn)確率能做到95%以上而且其中LLM要處理的流量可能只有20%左右成本優(yōu)勢(shì)也很明顯。你可以看這樣一個(gè)簡(jiǎn)單路由表用戶輸入示例規(guī)則匹配向量召回最終路由“怎么退貨”命中“退貨”關(guān)鍵詞退貨處理退貨處理“衣服小了能換嗎”無(wú)強(qiáng)規(guī)則換貨 / 退貨處理?yè)Q貨若配置“你們周末上班嗎”無(wú)強(qiáng)規(guī)則售后政策 / 人工人工轉(zhuǎn)接或兜底路由表本身是可以不斷迭代的。我建議每個(gè)新增的任務(wù)都提前準(zhǔn)備10條以上示例問(wèn)法這樣向量召回的效果才會(huì)穩(wěn)定。4.2 上下文窗口策略如何避免多個(gè)任務(wù)互相“污染”多任務(wù)代理最常見(jiàn)的翻車場(chǎng)景是上下文污染。舉例來(lái)說(shuō)用戶在查詢訂單之后又追問(wèn)了另一個(gè)產(chǎn)品的問(wèn)題如果系統(tǒng)直接把上一輪的訂單信息帶進(jìn)新的產(chǎn)品查詢里L(fēng)LM很可能把訂單號(hào)誤當(dāng)成產(chǎn)品編號(hào)輸出一段完全不著調(diào)的內(nèi)容。多任務(wù)代理在設(shè)計(jì)上下文時(shí)最需要關(guān)注的不是總長(zhǎng)度而是隔離性。我習(xí)慣的做法是全局上下文只保留用戶級(jí)基本信息如用戶ID、會(huì)話ID每個(gè)子任務(wù)維護(hù)一個(gè)獨(dú)立的任務(wù)上下文只存儲(chǔ)該任務(wù)相關(guān)的歷史信息任務(wù)切換后新任務(wù)不會(huì)讀取上一個(gè)任務(wù)的細(xì)節(jié)除非顯式聲明需要。同時(shí)任務(wù)結(jié)果合并階段要把不同子任務(wù)輸出放在一個(gè)結(jié)構(gòu)化的容器里并且用模板限定合并規(guī)則。你完全可以這樣理解單任務(wù)代理是只有一頁(yè)紙的記事本多任務(wù)代理則是帶標(biāo)簽的文件夾——每類任務(wù)有自己的子文件夾必要的時(shí)候才歸檔到一起。具體到實(shí)現(xiàn)上這個(gè)“隔離”就是你在調(diào)用LLM時(shí)對(duì)不同的Handler傳入不同的prompt和history片段而不是永遠(yuǎn)傳同一個(gè)session數(shù)組。當(dāng)然隔離也不是絕對(duì)的長(zhǎng)期記憶數(shù)據(jù)比如用戶的偏好標(biāo)簽、歷史訂單摘要是允許被多個(gè)任務(wù)共享的那屬于“狀態(tài)共享”層面和“上下文隔離”不能混為一談。4.3 記憶與狀態(tài)共享共享什么、不共享什么要有明確清單多任務(wù)代理越做越大記憶管理就會(huì)變成最纏人的活。共享狀態(tài)里面到底該放什么我建議只放跨任務(wù)都需要的“事實(shí)型數(shù)據(jù)”比如用戶名、會(huì)員等級(jí)、訂單編號(hào)列表而不是放“上一輪的任務(wù)過(guò)程和中間推理”。后者通常是性能殺手而且容易造成任務(wù)間干擾。有一版我做的多任務(wù)客服代理第一次上線時(shí)就把所有子任務(wù)的中間結(jié)果都放進(jìn)共享狀態(tài)里結(jié)果用戶多輪對(duì)話一多整個(gè)系統(tǒng)的召回準(zhǔn)確率就往下掉。后來(lái)把所有中間過(guò)程全部改成私有上下文只保留最終的結(jié)論數(shù)據(jù)在共享狀態(tài)問(wèn)題立刻消失了。共享狀態(tài)這里寧可多隔離也不要貪多。5. 成本、延遲和調(diào)試體驗(yàn)多任務(wù)代理被低估的三筆代價(jià)說(shuō)實(shí)話多任務(wù)代理在業(yè)務(wù)側(cè)的誘惑力很大因?yàn)樗@得“靈活、全能”。但在工程落地的過(guò)程中有幾筆賬經(jīng)常被低估我建議每個(gè)準(zhǔn)備選型的人都先算清楚。成本方面同樣是十個(gè)問(wèn)題單任務(wù)代理調(diào)用LLM的次數(shù)通常等于問(wèn)題數(shù)多任務(wù)代理可能每個(gè)問(wèn)題都要調(diào)用路由層加子任務(wù)處理層再加上結(jié)果匯總層。如果你做了二次分類或者重試機(jī)制一次用戶請(qǐng)求背后可能是三四次甚至更多的LLM調(diào)用。這不是危言聳聽(tīng)實(shí)測(cè)下來(lái)同等量級(jí)下多任務(wù)代理的Token成本往往是單任務(wù)代理的2到4倍。延遲方面更復(fù)雜的是延遲。多任務(wù)代理如果存在串行依賴比如必須先識(shí)別意圖再查庫(kù)存最后生成回答那總延遲就是各步驟延遲之和。我在測(cè)試中見(jiàn)過(guò)一個(gè)串聯(lián)了五個(gè)子任務(wù)的代理單次全鏈路延遲輕松超過(guò)8秒用戶早跑了。解決思路無(wú)非兩條能把獨(dú)立任務(wù)并行的就并行調(diào)用減少串行鏈路或者給路由器一個(gè)超時(shí)預(yù)算超過(guò)指定時(shí)間先輸出部分結(jié)果避免“干等”。這兩條建議大家可以優(yōu)先考慮。調(diào)試體驗(yàn)方面單任務(wù)代理的排查路徑非常簡(jiǎn)單報(bào)錯(cuò)了基本就是提示詞問(wèn)題、工具問(wèn)題或輸入格式問(wèn)題三選一多任務(wù)代理的報(bào)錯(cuò)則是“跨模塊聯(lián)調(diào)”你得先確認(rèn)路由是否正確再確認(rèn)數(shù)據(jù)有沒(méi)有正確傳遞再確認(rèn)是哪個(gè)Handler的問(wèn)題最后還得確認(rèn)匯總層的格式?jīng)_突。很多時(shí)候明明答案是對(duì)的匯總層卻因?yàn)镴SON格式解析失敗導(dǎo)致整個(gè)回復(fù)被攔截。這一類問(wèn)題在真實(shí)項(xiàng)目中非常常見(jiàn)。下面放一個(gè)簡(jiǎn)單的對(duì)比表方便你快速評(píng)估對(duì)比維度單任務(wù)代理多任務(wù)代理單次響應(yīng)延遲較低鏈路短偏慢鏈路疊加Token成本低高常有額外路由開(kāi)銷準(zhǔn)確性上限極高領(lǐng)域受限中等依賴路由與編排擴(kuò)展新能力需要重寫(xiě)可增量添加調(diào)試難度簡(jiǎn)單復(fù)雜跨模塊定位難適合場(chǎng)景工具型、問(wèn)題單一客服、助手型、綜合入口6. 我的選型建議不要為了“多任務(wù)”而上多任務(wù)寫(xiě)了這么多最后聊一點(diǎn)實(shí)際的體會(huì)。很多人在設(shè)計(jì)智能體時(shí)第一反應(yīng)是“多任務(wù)更高級(jí)”所以從一開(kāi)始就奔著多任務(wù)去。但如果你仔細(xì)復(fù)盤(pán)業(yè)務(wù)需求可能會(huì)發(fā)現(xiàn)其中80%的請(qǐng)求都屬于同一類固定問(wèn)題那這時(shí)候上多任務(wù)代理就是在給自己的工程和成本增加不必要的復(fù)雜度。我個(gè)人的一個(gè)判斷標(biāo)準(zhǔn)是當(dāng)用戶的輸入意圖類型只有1到2種時(shí)毫不猶豫選單任務(wù)當(dāng)意圖類型在3到5種時(shí)可以先做一個(gè)帶清晰路由的多任務(wù)單體只有當(dāng)意圖類型超過(guò)5種而且不同任務(wù)之間存在復(fù)雜的依賴關(guān)系時(shí)才值得引入多智能體協(xié)作結(jié)構(gòu)。另一個(gè)判斷依據(jù)是如果你的產(chǎn)品天然需要用戶在同一段對(duì)話里平滑切換多個(gè)主題比如綜合購(gòu)物助手那么多任務(wù)代理幾乎是唯一的正確選項(xiàng)——這時(shí)候就算延遲高一點(diǎn)、成本貴一點(diǎn)也只能接受因?yàn)閱稳蝿?wù)根本兜不住這種體驗(yàn)。最后再分享一個(gè)我調(diào)試多任務(wù)代理的習(xí)慣每增加一個(gè)子任務(wù)我都會(huì)單獨(dú)測(cè)試它的路由準(zhǔn)確率至少要穩(wěn)定超過(guò)95%才放行進(jìn)入主流程同時(shí)我會(huì)為每個(gè)子任務(wù)準(zhǔn)備一組“負(fù)面測(cè)試用例”專門(mén)用來(lái)確認(rèn)它不會(huì)搶走不該屬于它的請(qǐng)求。這樣做至少能避免那種幾個(gè)子任務(wù)互相打架、用戶輸入被反復(fù)路由到錯(cuò)誤模塊的尷尬情況。我踩過(guò)很多次坑之后才意識(shí)到很多多任務(wù)代理不是輸在模型不夠聰明而是輸在沒(méi)人認(rèn)真管理“分診”這件事。如果你正在做類似的系統(tǒng)不妨也從路由和狀態(tài)隔離這兩處入手把基礎(chǔ)打穩(wěn)再談能力擴(kuò)張。